Развертывание образа микропрограммы при наличии множества собственников

Развертывание образа микропрограммы при наличии множества собственников

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится в основном к развертыванию базовой системы ввода/вывода (BIOS, БИОС) и другого кода микропрограммы в компьютерных системах.

Уровень техники

Первоначально разработанная для IBM PC совместимых компьютеров базовая система ввода/вывода (БИОС), известная также как Система БИОС, фактически является стандартом, определяющим интерфейс микропрограммы. БИОС является начальной загрузкой микропрограммы, спроектированной таким образом, чтобы быть первым кодом, запускаемым персональным компьютером (ПК) после включения. Первоначальная функция БИОС состоит в том, чтобы идентифицировать, протестировать и инициализировать системные устройства, такие как плата устройства отображения, жесткий диск, гибкий диск и другие аппаратные средства. Эта инициализация подготавливает машину к переходу в рабочее состояние, таким образом, такое программное обеспечение, как операционная система, сохраняемая на совместимом носителе, может быть загружена, выполнена и отдана под управление ПК. Этот процесс известен как начальная загрузка системы или программа начального пуска, которая является короткой и служит для инициализации путем самозагрузки.

Программы БИОС обеспечивают маленькую библиотеку базовых функций ввода/вывода, которые могут быть вызваны для управления и контроля периферийными устройствами, такими как клавиатура, текстовые функции дисплея и т.д. Когда система обеспечивается питанием, БИОС проверяет установки конфигурации системы и загружает программы, которые действуют как трансляторы между аппаратными компонентами и операционной системой в запоминающем устройстве. Например, когда пользователь нажимает кнопку на клавиатуре, сигнал посылается к программе обработки прерываний клавиатуры, которая сообщает процессору, что она существует, и пропускает ее к операционной системе.

БИОС разрабатывался для компьютеров IBM PC в то время, когда процессоры функционировали в 16-битовом режиме работы процессора и адресуемая память была ограничена размером в один мегабайт, а код БИОС отражал аппаратную зависимость компьютеров IBM PC AT. Позже операционные системы были разработаны для 32-битных процессоров, и начали включать в себя драйверы устройств, чтобы обрабатывать вводы/выводы в большей степени, чем позволяла зависимость от активизации 16-битового исполняемого интерфейса, обеспечиваемого системой БИОС. Эти драйверы устройств часто обеспечиваются микропрограммной платформой и загружаются в память во время инициализации системы БИОС перед загрузкой операционной системы. В связи с тем что существует большое количество периферийных устройств, с которыми операционная система может взаимодействовать, такая микропрограммная платформа часто обеспечивается субъектами, которые не являются производителями системы. Поскольку многочисленные стороны становятся вовлеченными в процесс, распределение образа микропрограммы становится сложным.

С распространением плохих продуктов производства в сегодняшней компьютерной среде важность верификации микропрограмм также увеличилась. Цифровая электронная подпись или схема цифровой подписи является математической схемой для демонстрации подлинности цифрового сообщения или документа. Действительная цифровая подпись дает основание получателю верить, что сообщение было создано известным отправителем и что оно не было изменено при передаче. Цифровые подписи обычно используются для распределения программного обеспечения и поэтому желательно, чтобы цифровые подписи были использованы для распределения образа микропрограммы.

Краткое описание чертежей

Фиг.1 является блок-схемой подписанного образа микропрограммы предшествующего уровня техники.

Фиг.2А является блок-схемой образа микропрограммы, подписанного собственником корневого микропрограммного кода, в соответствии с одним вариантом осуществления изобретения.

Фиг.2В является блок-схемой образа микропрограммы фиг.2А, показывающей список управления доступом для собственника корневого микропрограммного кода в соответствии с одним вариантом осуществления изобретения.

Фиг.2С является блок-схемой образа микропрограммы, подписанного как собственником корневого микропрограммного кода, так и собственником микропрограммного кода производителя комплексного оборудования (OEM-изготовитель), в соответствии с одним вариантом осуществления изобретения.

Фиг.2D является блок-схемой образа микропрограммы фиг.2С, показывающей список управления доступом для собственника микропрограммного кода производителя комплексного оборудования, в соответствии с одним вариантом осуществления изобретения.

Фиг.2Е является блок-схемой образа микропрограммы, подписанного собственником корневого микропрограммного кода, собственником микропрограммного кода производителя комплексного оборудования и собственником микропрограммного кода канального распределителя в соответствии с одним вариантом осуществления изобретения.

Фиг.2F является блок-схемой образа микропрограммы фиг.2Е, показывающей список управления доступом для собственника микропрограммного кода канального распределителя в соответствии с одним вариантом осуществления изобретения.

Фиг.3 является диаграммой последовательности процесса, показывающей процесс подписания и делегирования полномочий для обновления подписанного образа микропрограммы, в соответствии с фиг.2A-2F.

Фиг.4 является диаграммой последовательности процесса способа обновления списка управления доступом для подписанного образа микропрограммы фиг.2A-2F и 3 в соответствии с одним вариантом осуществления изобретения.

Фиг.5 является диаграммой последовательности процесса способа обновления для подписанного образа микропрограммы фиг.2A-2F и 3 в соответствии с одним вариантом осуществления изобретения.

Фиг.6 является блок-схемой системы, сконфигурированной таким образом, чтобы позволить подписание образа микропрограммы множеством владельцев, в соответствии с одним вариантом осуществления изобретения.

Подробное описание

Варианты осуществления настоящего изобретения могут обеспечить способ, устройство, систему и компьютерный программный продукт для развертывания подписанного корневого образа микропрограммы, который включает в себя кодовые модули, подписываемые различными субъектами в канале распределения системы.

В одном варианте осуществления изобретения способ включает в себя получение подписанного образа микропрограммы, который содержит первый кодовый модуль, подписанный собственником первого кода, и второй кодовый модуль, подписанный собственником второго кода. Способ дополнительно включает в себя получение обновленного первого кодового модуля, содержащего обновленный код для первого кодового модуля, подтверждающего, что обновленный первый кодовый модуль подписывается собственником первого кода, и обновление подписанного образа микропрограммы с обновленным кодом для первого кодового модуля в ответ на подтверждение, что обновленный первый кодовый модуль подписывается собственником первого кода. Подписанный образ микропрограммы может дополнительно содержать список управления доступом, который санкционирует обновления к первому кодовому модулю, выполненные собственником первого кода, и обновления ко второму кодовому модулю, выполненные собственником второго кода.

Способ может дополнительно включать в себя получение маркера управления доступом, при этом маркер управления доступом содержит открытый ключ для собственника третьего кода и авторизацию для собственника третьего кода, чтобы обновлять третий кодовый модуль подписанного образа микропрограммы; подтверждение того, что маркер управления доступом подписывается авторизованным собственником кода из списка управления доступом; подтверждение того, что авторизованный собственник кода является авторизованным, чтобы обновлять третий кодовый модуль; и обновление списка управления доступом, чтобы включить в него открытый ключ для собственника третьего кода и авторизацию для собственника третьего кода, чтобы обновлять третий кодовый модуль. Способ может дополнительно включать в себя прием обновленного третьего кодового модуля от собственника третьего кода в подтверждение того, что обновленный третий кодовый модуль подписывается владельцем третьего кода, и обновление подписанного образа микропрограммы с обновленным третьим кодовым модулем в ответ на подтверждение, что обновленный третий кодовый модуль подписывается владельцем третьего кода.

Настоящее изобретение улучшает традиционную БИОС/микропрограммную платформу для процесса обновления монолитного образа и позволяет различным пользователям подписывать индивидуальные микропрограммные кодовые модули. Настоящее изобретение позволяет выполнять обновления, которые должны быть выполнены для специфических микропрограмм БИОС/платформы кодового модуля/драйвера или приложения. С микропрограммной платформой, которая становится все более сложной и обеспечивающей критическую функциональность, такую как защитные функции, дефекты в системе БИОС и микропрограммной платформе сейчас могут быть немедленно исправлены и обеспечены учрежденческими управляющими серверами в большей степени, чем необходимо в соответствии с требованиями производителей комплексного оборудования, чтобы обеспечить новый монолитный образ для всей области БИОС/микропрограммной платформы флэш-памяти для системы.

Ссылка в описании на «один вариант осуществления изобретения» или «вариант осуществления изобретения» в настоящем изобретении означает, что отдельный признак, структура или характеристика, описанные в связи с вариантом осуществления изобретения, включены, по меньшей мере, в один вариант осуществления изобретения. Таким образом, появления фраз «в одном варианте осуществления изобретения», «согласно одному варианту осуществления изобретения» или появление подобных фраз в различных местах по всему описанию необязательно свидетельствует о том, что все они ссылаются на тот же самый вариант осуществления изобретения.

С целью объяснения формулируются специфические конфигурации и подробности, для того чтобы обеспечивать исчерпывающее понимание настоящего изобретения. Однако специалисту с обычным уровнем квалификации будет очевидно, что варианты осуществления настоящего изобретения могут быть практически применены и без специфических подробностей, приведенных здесь. Кроме того, хорошо известные признаки могут быть пропущены или упрощены, для того чтобы не вносить неопределенности в настоящее изобретение. Различные примеры могут быть приведены на протяжении всего описания. Здесь присутствуют только описания специфических вариантов осуществления изобретения. Объем изобретения не ограничивается приведенными примерами.

С продвижением вредоносных программ и увеличением их изощренности для провайдеров системного программного обеспечения, такого как образ микропрограмм, желательно сертифицировать данную версию образа микропрограммы на предмет его подлинности и убедиться, что он не был предметом для фальсификации. Такая сертификация часто обеспечивается как цифровая подпись файла с образом программы в соответствии с криптографической схемой, такой как алгоритм кодирования RSA (Rivest Shamir Adieman), который обеспечивает открытый и секретный ключи, чтобы кодировать и подписывать данные. Специалист в данной области техники понимает, что описанное здесь изобретение не ограничивается цифровой подписью с использованием алгоритма кодирования RSA, но любой способ обеспечения цифровой подписи для удостоверения подлинности находится в пределах объема изобретения.

Схема цифровой подписи обычно состоит из трех алгоритмов: (1) алгоритм генерирования ключа, который выбирает секретный ключ равномерно в случайном порядке из набора возможных секретных ключей. Этот алгоритм выводит секретный ключ и соответствующий открытый ключ. (2) Алгоритм подписания, который при заданном сообщении и секретном ключе производит подпись. (3) Алгоритм подтверждения подписи, который при заданном сообщении, открытом ключе и подписи или принимает, или отвергает утверждение о подлинности сообщения. Здесь требуются два главных свойства. Первое, подпись, генерированная из фиксированного сообщения, и фиксированный секретный ключ должны подтверждать подлинность этого сообщения за счет использования соответствующего открытого ключа. Второе, должно быть недопустимым генерировать по возможности вычисления действительную подпись для стороны, которая не обладает секретным ключом.

Фиг.1 является блок-схемой подписанного образа микропрограммы предшествующего уровня техники. Корневой образ микропрограммы 110 подписывается единственным секретным ключом 120 субъекта. Только владелец секретного ключа 120 может обновить корневой образ микропрограммы 110. Например, предположим, что производитель системы имеет подписанный корневой образ микропрограммы 110 с использованием секретного ключа 120 производителя системы. Если обновления для модулей, содержащихся внутри корневого образа микропрограммы 110, необходимы другим субъектам в цепи развертывания после того, как подписывается корневой образ микропрограммы 110, например таким, как клиенты производителя комплексного оборудования (OEM) и клиенты канала, то эти субъекты должны обеспечить изготовленные по техническим условиям заказчика кодовые модули образа микропрограммы владельцев секретного ключа 120, которые должны быть включены в последующий выпуск корневого образа микропрограммы 110. Такое применение требует наличие инфраструктуры для поддержки изготовленных по техническим условиям заказчика кодовых модулей образа микропрограммы и развертывание обновленного корневого образа микропрограммы 110 в соответствии с графиками сторонних субъектов.

Брешь в системе защиты, позволенная изготовленным по техническим условиям заказчика кодовым модулем образа микропрограммы, обеспеченного для другого субъекта, не являющегося владельцем секретного ключа 120, компрометирует безопасность всего корневого образа микропрограммы 110. Такая брешь в системе защиты может быть исправлена только владельцем секретного ключа 120. По этой причине большая часть применений в настоящее время подписывается только субъектами на нижнем конце канала распределения. Кодовые модули корневого образа микропрограммы, обеспечиваемые производителем системы и/или производителем комплексного оборудования, часто являются неподписанными, чтобы избежать описанных выше проблем. Однако без цифровой подписи, сделанной провайдером многих кодовых модулей образа микропрограммы, конечные пользователи системы могут заключить, что образ микропрограммы является в меньшей степени заслуживающим доверия.

Фиг.2А является блок-схемой образа микропрограммы, подписанного собственником корневого микропрограммного кода, в соответствии с одним вариантом осуществления изобретения. В этом примере первоначальный владелец корневого образа микропрограммы, такой как производитель системы (определяемый здесь как корневой "Root"), подписал каждый из кодовых модулей образа микропрограммы в пяти томах (FV1 211, FV2 213, FV3 215, FV4 217, и FV5 219) микропрограммы с корневым секретным ключом 220. Подписание кодового модуля может вызвать прикрепление цифровой подписи к кодовому модулю. В показанных здесь примерах подпись для кодового модуля иллюстрируется как подпись, связанная с томом микропрограмм, содержащим кодовый модуль. Аналогичным образом, полномочия на обновление заданного кодового модуля описываются как полномочия на обновление тома микропрограмм, содержащего кодовый модуль. Специалист в данной области техники поймет, что в заданном томе микропрограмм может содержаться более чем один кодовый модуль и что различные кодовые модули внутри тома микропрограмм могут иметь различные подписи и/или полномочия на обновление, но для простоты кодовый модуль и том микропрограмм здесь описываются как имеющие соотношение один к одному.

Таблица 230А обеспечивает информацию по безопасности, включающую в себя открытый ключ 231 для собственника "Root" корневого кода и список 232 управления доступом (Access Control List - ACL) для собственника "Root" корневого кода. Список 232 ACL обозначает кодовые модули образа микропрограммы (т.е. тома микропрограмм), находящиеся в собственности посредством открытого ключа 231. Дополнительные подробности о списке 232 управления доступом приводятся на фиг.2В.

Фиг.2В является блок-схемой образа микропрограммы фиг.2А, показывающей список управления доступом для собственника "Root" корневого кода микропрограмм, в соответствии с одним вариантом осуществления изобретения. В показанном примере список 232 ACL содержит указатели от 232А до 232Е к кодовым модулям в каждом из пяти томов FV1 211, FV2 213, FV3 215, FV4 217, и FV5 219 микропрограмм. Эти указатели более подробно показываются и объясняются ниже со ссылкой на фиг.3.

Фиг.2С является блок-схемой образа микропрограммы, подписанного как собственником корневого микропрограммного кода, так и собственником микропрограммного кода производителя комплексного оборудования (рассматриваемого здесь как «OEM»), в соответствии с одним вариантом осуществления изобретения. В этом примере второй владелец кодовых модулей образа микропрограммы, такой как OEM заказчик изготовителя системы, удерживающий открытый ключ 220 на фиг.2А, обеспечил изготовленные по техническим условиям заказчика корневые микропрограммные модули. Например, собственник микропрограммного кода производителя OEM комплексного оборудования может предложить компьютерную систему как продукт, являющийся компактным серверным модулем, при этом кодовые модули образа микропрограммы, обеспеченные собственником микропрограммного кода «OEM», могут конфигурировать микропрограмму, чтобы работать в конфигурации компактного серверного модуля.

На фиг.2С вторичный собственник «OEM» подписал выбранные тома микропрограмм внутри образа микропрограммы, сейчас рассматриваемые как образ микропрограммы 210 В OEM, с секретным ключом 240 OEM. В этом примере тома FV3 215 и FV5 219 микропрограмм были подписаны с помощью секретного ключа 240 OEM. Таблица 230 В обеспечивает новую информацию безопасности, включающую в себя открытый ключ 241 для собственника кода «OEM» и список 242 управления доступом (Access Control List - ACL), обозначающий кодовые модули образа микропрограммы (т.е. тома микропрограмм), находящиеся в собственности владельца открытого ключа 241. Дополнительные подробности о списке 242 управления доступом (ACL) приводятся на фиг.2D.

Фиг.2D является блок-схемой образа микропрограммы фиг.2С, показывающей список управления доступом для собственника микропрограммного кода производителя комплексного оборудования («OEM»), в соответствии с одним вариантом осуществления изобретения. В показанном примере список 242 управления доступом (ACL) содержит соответствующие указатели 242С и 242Е для каждого из двух томом FV3 215 и FV5 219 микропрограмм. Эта новая информация по безопасности является частью таблицы 230 В, которая также включает в себя открытый ключ 231 и ACL 232 для собственника "Root" корневого кода микропрограмм, как описывалось со ссылкой на фиг.2А и 2В. Однако владелец "Root" корневого кода микропрограмм делегирует полномочия для собственника микропрограммного кода производителя комплексного оборудования («OEM»), чтобы обновлять тома FV3 215 и FV5 219, кроме того, указатели 232С и 232Е ACL 232 перезаписываются с помощью указателей 242С и 242Е ACL 242. Процесс делегирования полномочий для обновления кодовых модулей микропрограмм ниже описывается дополнительно со ссылками на фиг.3-5.

Фиг.2Е является блок-схемой образа микропрограммы, подписанного собственником "Root" корневого микропрограммного кода, собственником «OEM» микропрограммного кода производителя комплексного оборудования и собственником "Chni" микропрограммного кода канального распределителя, в соответствии с одним вариантом осуществления изобретения. В этом примере третий собственник кодовых модулей образа микропрограммы, такой как клиент канала OEM блокирующего секретного ключа 240 на фиг.2В, обеспечил изготовленные по техническим условиям заказчика корневые микропрограммные модули. Третий собственник "Chni" подписал один том микропрограмм внутри образа микропрограммы, который сейчас определяется как образ микропрограммы 21 ОС клиента канала, с помощью канального (Chni) секретного ключа 250. В этом примере том FV5 219 микропрограмм был подписан с помощью канального (Chni) секретного ключа 250. Таблица 230С обеспечивает новую информацию по безопасности, включающую в себя открытый ключ 251 для собственника "Chni", являющегося клиентом канала, и список 252 управления доступом (ACL), обозначающий кодовые модули образа микропрограммы (т.е. тома микропрограмм), находящийся в собственности посредством открытого ключа 251.

Фиг.2F является блок-схемой образа микропрограммы фиг.2Е, показывающей список управления доступом для собственника "Chni" микропрограммного кода канального распределителя, в соответствии с одним вариантом осуществления изобретения. В показанном примере ACL 252 содержит указатель 252Е для тома FV5 219 микропрограмм. Эта новая информация по безопасности является частью таблицы 230С, которая также включает в себя открытый ключ 231 и ACL 232 для собственника "Root" корневого кода микропрограмм, как описывалось со ссылкой на фиг.2А и 2В, открытый ключ 241 и ACL 242 для собственника "OEM" кода микропрограмм, как описывалось со ссылкой на фиг.2С и 2D. Указатель 252Е заменяет оба указателя: как 232Е списка ACL 232 для собственника "Root" кода микропрограмм, так и 242Е списка ACL 242 для собственника "OEM" кода микропрограмм.

Фиг.3 является диаграммой последовательности процесса, показывающей процесс подписи и делегирования полномочий для обновления подписанного образа микропрограммы для фиг.2A-2F. Первоначально корневой образ микропрограммы 310А был подписан собственником "Root" корневого кода микропрограмм, как описывалось со ссылкой на корневой образ микропрограммы 210А фиг.2А. Таблица 330А показывает, что субъект с открытым ключом 331 (который соответствует собственнику "Root" с секретным ключом 320) имеет список 332 управления доступом, содержащий указатели от 332А до 332Е, позволяющие собственнику открытого ключа 331 обновлять кодовые модули, содержащиеся в каждом из томов FV1 311, FV2 313, FV3 315, FV4 317, и FV5 319 микропрограмм.

Во время действия 3.1 собственник секретного ключа 320 "Root" создает подписанный маркер 360, для того чтобы санкционировать последующие обновления корневого образа микропрограммы 310А. За счет подписания маркера 360 собственник секретного ключа 320, собственник "Root" кода микропрограмм, ассоциирует открытый ключ 321 "Root" с маркером 360. Маркер 360 создается для того, чтобы включать в себя информацию, для которой были делегированы полномочия, например такую, как открытый ключ 362 субъекта, который является авторизованным для обновления корневого образа микропрограммы 310А, при этом список 364 управления доступом, обозначающий модули микропрограмм внутри корневого образа микропрограммы 310А, который может быть обновлен с помощью соответствующего открытого ключа 362. В этом случае открытый ключ 362 для собственника "OEM" кода микропрограмм был включен в состав маркера 360 с помощью списка 364 управления доступом, позволяющего собственнику "OEM" открытого ключа 362 обновлять тома FV3315 и FV5 319 микропрограмм.

Во время действия 3.2 перед тем, как корневой образ микропрограммы 310А обновляется, проверяются запрашиваемые полномочия, которые должны быть делегированы с помощью маркера 360. Корневой образ микропрограммы 310А консультирует таблицу 330А, чтобы гарантировать, что собственник открытого ключа для маркера 360, т.е. собственник маркерного открытого ключа 321 "Root", является авторизованным, чтобы обновлять тома микропрограмм, которые содержатся внутри маркера 360. В этом примере производится консультирование таблицы 330А, чтобы гарантировать, что собственник открытого ключа 321 для маркера 360 ("Root") появляется в таблице 330А и что собственник открытого ключа 321 для маркера 360 ("Root") имеет полномочия для обновления томов FV3 315 и FV5 319 микропрограмм.

Во время действия 3.3 после подтверждения того, что собственник открытого ключа 321 для маркера 360 ("Root") имеет полномочия для обновления томов FV3 315 и FV5 319 микропрограмм, код в томах FV3 315 и FV5 319 обновляется, чтобы сформировать OEM образа микропрограммы 310 В. Таблица 330 В внутри OEM образа микропрограммы 310 В также обновляется, чтобы включить в себя открытый ключ для собственника "OEM" кода микропрограмм как открытый ключ 333 и соответствующий список (ACL) 334 управления доступом. В результате обновления таблицы 330 В список (ACL) управления доступом сейчас включает в себя три указателя для собственника "Root" кода микропрограмм, указатели 332А для FV1 311, 332 В для FV2 313 и 332D для FV4 317, а также два указателя для собственника "OEM" кода микропрограмм, указатели 334С для FV3 315 и 334Е для FV5 319.

Во время действия 3.4 собственник "OEM" кода микропрограмм (собственник открытого ключа 340) создает подписанный маркер 370, для того чтобы санкционировать последующие обновления OEM образа микропрограммы 310 В. За счет подписания маркера 370 собственник открытого ключа 340, собственник "OEM" кода микропрограмм ассоциирует "OEM" открытый ключ 341 с маркером 370. Маркер 370 создается таким образом, чтобы включать в себя информацию, для которой делегируются полномочия, такую как открытый ключ 372 субъекта, который имеет полномочия для обновления OEM образа микропрограммы 310 В и списка 374 (ACL) управления доступом, обозначающего модули микропрограмм внутри OEM образа микропрограммы 310 В, который может быть обновлен с помощью соответствующего открытого ключа 372. В этом примере открытый ключ 372 для собственника "Chni" микропрограммного кода был включен в состав маркера 370 со списком 374 управления доступом, позволяющим собственнику Chni открытого ключа 372 обновлять том FV5 319 микропрограмм.

Во время действия 3.5 перед тем, как будет обновлен OEM образ микропрограммы 310 В, проверяются запрашиваемые полномочия, которые должны делегироваться с помощью маркера 370. OEM образ микропрограммы 310 В консультирует таблицу 330 В, чтобы гарантировать, что собственник открытого ключа 341 для маркера 370 является авторизованным, чтобы обновлять тома микропрограмм, содержащиеся внутри маркера 370. В этом примере таблица 330 В консультируется для того, чтобы гарантировать, что собственник открытого ключа 341 для маркера 370 («OEM») появляется в таблице 330 В и что собственник открытого ключа 341 для маркера 370 («OEM») имеет полномочия для обновления тома FV5 319 микропрограмм.

Во время действия 3.6 после подтверждения того, что собственник открытого ключа для маркера 360 («OEM») имеет полномочия для обновления тома FV5 319, код в FV5 319 обновляется, чтобы формировать образ микропрограмм 310С клиента канала (Channel Customer). Таблица 33 ОС внутри образа микропрограммы 31 ОС клиента канала также обновляется, чтобы включить в себя открытый ключ для собственника "Chni" микропрограммного кода как открытый ключ 335 и соответствующий список 336 (ACL) управления доступом. В результате обновления таблицы 330С список управления доступом теперь включает в себя три указателя для собственника "Root" микропрограммного кода, указатели 332А для FV1 311, 332 В для FV2313 и 332D для FV4 317; один указатель для собственника "OEM" кода микропрограмм, указатель 334С для FV3315, а также один указатель для собственника "Chni" кода микропрограмм, указатель 336Е для FV5 319.

Фиг.4 является диаграммой последовательности процесса способа обновления списка управления доступом для подписанного образа микропрограммы фиг.2A-2F и 3 в соответствии с одним вариантом осуществления изобретения. Шаги, описанные на фиг.4, выполняются собственником существующего образа микропрограммы, такого как подписанный корневой образ микропрограммы 310А, показанный на фиг.3, чтобы делегировать полномочия другому субъекту для обновления подписанного образа микропрограммы. Субъект, делегирующий полномочия для обновления образа микропрограммы, определяется здесь как «делегирующий субъект». В предыдущих примерах, показанных на фиг.2A-2F, шаги, описываемые на фиг.4, будут выполняться собственником "Root" микропрограммного кода, чтобы делегировать полномочия собственнику "OEM" кода микропрограмм во время действий 3.2 и 3.3. Аналогичным образом, шаги, описываемые на фиг.4, будут выполняться собственником "OEM" кода микропрограмм, чтобы делегировать полномочия собственнику "Chni" кода микропрограмм во время действий 3.5 и 3.6. Шаги, описываемые на фиг.4, будут работать таким образом, чтобы обновлять список управления доступом существующего образа микропрограммы, такого как список 330А управления доступом корневого образа микропрограммы 310А или список 330 В управления доступом образа микропрограммы OEM 310 В.

Во время шага 410 «Получение прямого маркера управления доступом (АС)» маркер управления доступом, такой как маркер 360 или маркер 370, показанные на фиг.3, получаются от делегирующего субъекта. Как описывалось ранее со ссылками на фиг.2A-2F и фиг.3, маркер управления доступом, такой как маркер 360 или маркер 370, показанные на фиг.3, могут быть созданы одним субъектом в канале распределения, чтобы авторизовать последующего субъекта в канале распределения для изменения заданной версии образа микропрограммы. Маркер управления доступом подписывается с использованием секретного ключа субъекта, делегирующего полномочия, и поэтому открытый ключ делегирующего субъекта взаимосвязан с маркером управления доступом. Как только маркер управления доступом получен от делегирующего субъекта в канале распределения, управление продолжается и переходит к шагу 420 «Идентификация субъекта, делегирующего полномочия, и совпадение подписи открытого ключа (PubKey) субъекта, делегирующего полномочия со списком (ACL) управления доступом».

Во время шага 420 «Идентификация субъекта, делегирующего полномочия, и совпадение подписи открытого ключа (PubKey) субъекта, делегирующего полномочия, со списком (ACL) управления доступом» делегирующий субъект идентифицируется как субъект, имеющий подписанный маркер управления доступом. В показанном на фиг.3 примере в точке выполнения исполнительного действия 3.2 субъектом, делегирующим полномочия, является собственник "Root" микропрограммного кода. Открытый ключ, взаимосвязанный с маркером управления доступом, сопоставляется с открытыми ключами, появляющимися в списке управления доступом образа микропрограммы, для которого должно быть делегировано обновление полномочий. Если открытый ключ, взаимосвязанный с маркером управления доступом, появляется в списке управления доступом образа микропрограммы, то управление продолжается и переходит к шагу 430 «Подтверждение подписи прямого маркера управления доступом (АС)».

Во время шага 430 «Подтверждение подписи прямого маркера управления доступом (АС)» открытый ключ для делегирующего субъекта используется для подтверждения подписи маркера управления доступом. Чтобы выполнить подтверждение этой подписи, значение хеш-функции может быть вычислено из подписанного маркера управления доступом. Открытый ключ также может быть использован для расшифровки цифровой подписи и подписанных данных, а затем другое значение хеш-функции может быть вычислено из расшифрованных данных. Если два вычисленных значения хеш-функции совпадают, то в этом случае цифровая подпись может рассматриваться как действительная. После того как подпись маркера управления доступом была подтверждена, управление продолжается и переходит к шагу 440 «Модули идентификационного кода, требующие обмена для списка (ACL) управления доступом».

Во время шага 440 «Модули идентификационного кода, требующие обмена для списка (ACL) управления доступом», идентифицируются тома микропрограмм, для которых должны быть делегированы полномочия. В примере действия 3.2 тома микропрограмм, идентифицированные в маркере 360 управления доступом, были томами FV3 315 и FV5 319 микропрограмм. Как только тома микропрограмм идентифицируются, управление продолжается и переходит к шагу 450 «Подтверждение, что субъект, делегирующий полномочия, является авторизованным для изменения управления доступом (АС)».

Во время шага 450 «Подтверждение, что субъект, делегирующий полномочия, является авторизованным для изменения управления доступом (АС)» выполняется определение, является ли субъект, делегирующий полномочия, авторизованным для изменения списка управления доступом существующего образа микропрограммы. Как описывалось выше, делегирующий субъект, собственник "Root" кода микропрограмм, был обозначен как собственник списка управления доступом для томов с FV1 311 по FV5 319 микропрограмм. Следовательно, субъект, делегирующий полномочия, является авторизованным для изменения списка управления доступом для этих томов микропрограмм. Затем управление продолжается и переходит к шагу 460 «Обновление списка (ACL) управления доступом: вход в новый открытый ключ субъекта и обновление списков управления доступом для кодовых модулей».

Во время шага 460 «Обновление списка (ACL) управления доступом: вход в новый открытый ключ субъекта и обновление списков управления доступом для кодовых модулей» открытый ключ для субъекта, которому делегируются полномочия, собственник "OEM" кода микропрограмм в этом примере, добавляется в список управления доступом и в результате списки управления доступом для томов FV3 315 и FV5 319 микропрограмм обновляются. Полномочия для обновлений к томам FV3 315 и FV5 319 микропрограмм были делегированы собственнику "OEM" кода микропрограмм.

Фиг.5 является диаграммой последовательности процесса способа обновления для подписанного образа микропрограммы фиг.2A-2F и 3 в соответствии с одним вариантом осуществления изобретения. Во время шага 510 «Обработка подписанного модуля» существующий образ микропрограммы, такой как корневой образ микропрограммы 310А, принимает запрос на обработку подписанного модуля. Обработка подписанного модуля может вовлекать разворачивание информации, такой как количество томов микропрограмм, включенных в состав подписанного модуля, и/или разворачивание ключа, используемого для подписи подписанного модуля. Каждый подписанный кодовый модуль будет обрабатываться в соответствии с шагами, показанными на фиг.5. Управление продолжается и переходит к шагу 520 «Сопоставление подписи открытого ключа со списком (ACL) управления доступом и идентификация обновляющего субъекта».

Во время шага 520 «Сопоставление подписи открытого ключа со списком (ACL) управления доступом и идентификация обновляющего субъекта» открытый ключ, соответствующий секретному ключу, используемый для подписи подписанного модуля, сравнивается со списком управления доступом существующего образа микропрограммы и обновляющий субъект идентифицируется. Если открытый ключ для подписанного модуля появляется в списке управления доступом существующего образа микропрограммы, то после этого управление продолжается и переходит к шагу 530 «Подтверждение подписи модуля».

Во время шага 530 «Подтверждение подписи модуля» подтверждается подпись модуля. Для того чтобы выполнить это подтверждение подписи, значение хеш-функции может быть вычислено из подписанного модуля. Открытый ключ также может быть использован для расшифровки цифровой подписи и подписанных данных, а затем другое значение хеш-функции может быть вычислено из расшифрованных данных. Если два вычисленных значения хеш-функции совпадают, то цифровая подпись может рассматриваться как действительная. После того как подпись модуля была подтверждена, управление продолжается и переходит к шагу 540 «Идентификация кодовых модулей для обновления».

Во время шага 540 «Идентификация кодовых модулей для обновления» кодовые модули в томах микропрограмм, которые должны быть обновлены в существующем образе микропрограммы, идентифицируются. Как только кодовые модули в томах микропрограмм идентифицируются, управление продолжается и переходит к шагу 550 «Подтверждение того, что субъект, выполняющий обновление, является авторизованным для обновления требуемых кодовых модулей».

Во время шага 550 «Подтверждение того, что субъект, выполняющий обновление, является авторизованным д