Адресация доверенной среды исполнения с использованием ключа подписи

Группа изобретений относится к области защиты информации. Техническим результатом является увеличение безопасности. Система выполнена с возможностью принимать запрос на защищенные данные от запрашивающей стороны, ассоциированной с вложенной TrEE, заключение об аттестации безопасного ядра и заключение о сертификации ключа, при этом вложенная TrEE содержит доверенное приложение, исполняющееся поверх безопасного ядра, причем заключение о сертификации ключа связывает общедоступный ключ шифрования доверенного приложения и ID доверенного приложения; извлекать защищенные данные из упомянутой системы, в которой хранятся секреты, в ответ на данный запрос; зашифровывать защищенные данные с помощью общедоступного ключа шифрования доверенного приложения и посылать зашифрованные защищенные данные запрашивающей стороне. 3 н. и 17 з.п. ф-лы, 14 ил.

 

ОБЛАСТЬ ТЕХНИКИ

[0001] Это раскрытие в общем относится к доверенным и/или изолированным средам исполнения в вычислительных устройствах и, более конкретно, к безопасной доставке одного или нескольких секретов или ключей в доверенную среду исполнения.

УРОВЕНЬ ТЕХНИКИ

[0002] Система управления ключами (key management system, KMS) является хранилищем секретов. Секрет, как правило, имеет публичный ID, защищаемое значение и политику, управляющую тем, кто может получить это значение. В некоторых случаях секрет также может иметь срок действия и другие метаданные и т.д. В типичном варианте использования инициатор запроса аутентифицируется в KMS, устанавливает защищенный канал, запрашивает секретное значение путем обеспечения секретного ID и ожидает, что KMS вернет ему секретное значение в виде открытого текста. Это значение защищено от несанкционированного подслушивания и вмешательства защищенным каналом между инициатором запроса и KMS.

[0003] Доверенная среда исполнения (Trusted Execution Environment, TrEE) в настоящем документе может включать в себя любое из: доверенное приложение (trustlet, трастлет) виртуального безопасного режима (virtual secure mode, VSM), приложение SGX, приложение ARM TrustZone или некоторое другие аналогичные средства. Существуют некоторые уникальные свойства, которыми, как правило, обладают все TrEE. TrEE, как правило, будет иметь полный криптографический стек (другими словами, можно предположить большое разнообразие криптографических примитивов по всему спектру, от безопасной генерации случайных чисел до полного меню хеширования, шифрования и подписывания библиотек с помощью секретных ключей). TrEE также, как правило, будет иметь или будет ассоциирован с немногими или ограниченными средствами ввода-вывода (I/O), как правило, ограниченными управляемой запросами архитектурой, в которой запросы инициируются недоверенным «внешним миром». Например, доверенное приложение VSM может использовать неаутентифицированные вызовы удаленной процедуры (Remote Procedure Call, RPC). TrEE также могут иметь доступ к материалам ключа или данным, которые недоступны за пределами TrEE. Это позволяет TrEE, среди прочего, сохранять данные с помощью недоверенных операций ввода-вывода (I/O), и затем считывать их обратно, обеспечивая защиту от несанкционированного доступа и конфиденциальность состояния. TrEE также, как правило, будет иметь или будет ассоциирована с аттестируемым кодом, конфигурацией и ключевым материалом. В частности, аттестируемый материал ключа позволяет TrEE принимать зашифрованные сообщения от третьих сторон и подписывать сообщения для третьих сторон как поступающие от TrEE.

[0004] Как и с другими приложениями, использование KMS с TrEE может иметь ограничения по обеспечению безопасности. Соответственно, могут быть сделаны улучшения для повышения безопасности с использованием ключей, полученных от KMS с помощью или в TrEE.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0005] Иллюстративные примеры раскрытия включают в себя, без ограничения, способы, системы и различные устройства. В одном аспекте способ для доставки защищенных данных во вложенную доверенную среду исполнения (Trusted Execution Environment, TrEE), ассоциированную с недоверенным инициатором запроса, может выполняться по меньшей мере частично адресующим блоком управления протокола или другим посредником между инициатором запроса и системой управления ключами или другим хранилищем защищенных данных. Вложенная TrEE может включать в себя доверенное приложение, исполняющееся поверх безопасного ядра. Адресующий блок управления протокола может принимать запрос на защищенные данные от потенциально недоверенного инициатора запроса, заключение об аттестации безопасного ядра и заключение о сертификации ключа. Заключение о сертификации ключа может связывать открытый (общедоступный) ключ шифрования доверенного приложения и ID доверенного приложения. Адресующий блок управления протокола может извлекать защищенные данные и зашифровывать защищенные данные с помощью открытого ключа шифрования доверенного приложения. Адресующий блок управления протокола затем может посылать зашифрованные защищенные данные инициатору запроса.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0007] Далее будут более полно описаны варианты осуществления настоящего раскрытия со ссылкой на прилагаемые чертежи, на которых:

[0008] Фиг. 1А, 1B и 1C изображают три примера системы и процесса для обмена ключами между инициатором запроса и системой управления ключами.

[0009] Фиг. 2 изображает иллюстративную схему монитора управляющей программы, реализующего изолированную область или доверенную среду исполнения (Trusted Execution Environment, TrEE).

[0010] Фиг. 3 изображает иллюстративный процесс для доставки защищенных данных в доверенную TrEE с использованием промежуточного адресующего блока управления протокола.

[0011] Фиг. 4А и 4B изображают другой иллюстративный процесс для доставки защищенных данных в TrEE с использованием промежуточного адресующего блока управления протокола.

[0012] Фиг. 5А и 5B изображают иллюстративный процесс для доставки защищенных данных во вложенную TrEE с использованием промежуточного адресующего блока управления протокола.

[0013] Фиг. 6 изображает иллюстративную систему, в которой может быть реализован один или несколько описанных процессов.

[0014] Фиг. 7 изображает пример структуры данных, используемой для безопасной доставки транспортного ключа и/или защищенных данных в TrEE.

[0015] Фиг. 8 изображает другой иллюстративный процесс для доставки защищенных данных во вложенную TrEE с использованием промежуточного адресующего блока управления протокола, основанного на ключе шифрования внешней TrEE.

[0016] Фиг. 9 изображает другой иллюстративный процесс для доставки защищенных данных во вложенную TrEE с использованием промежуточного адресующего блока управления протокола, основанного на ключе шифрования внутренней TrEE.

[0017] Фиг. 10 изображает иллюстративную универсальную вычислительную среду, в которой могут быть воплощены методики, описанные в настоящем описании.

ПОДРОБНОЕ ОПИСАНИЕ ИЛЛЮСТРАТИВНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

[0018] В настоящем описании описываются системы и методики для безопасной доставки по меньшей мере одного ключа (например, ключа подписи или ключа шифрования) или защищенных данных/секрета в доверенную среду исполнения (Trusted Execution Environment, TrEE) вычислительного устройства, такого как одно или несколько физических или виртуальных вычислительных устройств. В одном аспекте может быть реализован посредник между инициатором запроса ключа и системой управления ключами или субъектом, обладающим защищенными данными. Посредник может называться в настоящем описании адресующим блоком управления протокола. Инициатор запроса ключа может быть ассоциирован с безопасной средой исполнения или TrEE, которая может включать в себя одно или несколько из: доверенное приложение VSM, приложение SGX, приложение ARM TrustZone или некоторое другое аналогичное средство. TrEE может быть изолирована от инициатора запроса. Инициатор запроса может запросить доставку одного или нескольких секретов в TrEE или конкретному доверенном приложению, выполняющемуся в TrEE, от адресующего блока управления протокола. Адресующий блок управления протокола в ответ на запрос может связаться с системой управления ключами или другим субъектом, который хранит секреты, для получения одного или нескольких секретов для доставки в TrEE. Адресующий блок управления протокола может конкретно адресовать защищенные данные TrEE так, чтобы защищенные данные не были доступны инициатору запроса или злоумышленнику.

[0019] В некоторых аспектах реализация адресующего блока управления протокола может устранять необходимость в защищенном канале между инициатором запроса и системой управления ключами. Адресующий блок управления протокола, с помощью методик адресации TrEE, описанных в настоящем описании, также может позволять посылать один или несколько секретов или данные в TrEE или вложенную TrEE (например, доверенному приложению, выполняющемуся поверх безопасного ядра) таким образом, что секреты/данные не доступны инициатору запроса. В некоторых случаях инициатор запроса может быть недоверенным или потенциально недоверенным, так что владелец защищенных данных может пожелать сохранить защищенные данные недоступными инициатору запроса по любой из множества причин. В некоторых случаях может быть сложно или обременительно установить, что инициатор запроса заслуживает доверия, или гарантировать, что инициатор запроса остается заслуживающим доверия. Многие из этих проблем могут быть устранены, если предположить, что инициатор запроса не заслуживает доверия, и изолировать TrEE от инициатора запроса. Эта изоляция может значительно улучшить защиту от различных типов атак и может обеспечить другие выгоды и преимущества, как будет описано более подробно ниже.

[0020] Фиг. 1А изображает иллюстративную систему и процесс 100a для обмена ключами между инициатором запроса и системой управления ключами. Как показано, инициатор запроса или запрашивающее устройство 120, ассоциированное с клиентским устройством или клиентской стороной 110, может связаться с системой управления ключами или держателем некоторого желаемого секрета(ов) 115, ассоциированного с сервером или серверной стороной 105. Инициатор запроса 120 может запросить один или несколько секретов или частей защищенных данных из системы 115 управления ключами, например, чтобы получить доступ к некоторым защищенным данным, выполнить один или несколько защищенных процессов и т.п. Инициатор 120 запроса и система 115 управления ключами (KMS) может использовать систему безопасности с открытым ключом и закрытым (конфиденциальным) ключом или другой протокол ключей, как известно в данной области техники, для обмена желаемыми секретами/данными.

[0021] Инициатор 120 запроса может сначала выполнить аутентификацию в KMS 115 и установить безопасный канал связи в операции 125 с помощью любой из известных в данной области техники методик. Операция 125 может включать в себя использование системы с открытым ключом и т.п. Затем, используя защищенный канал, установленный с помощью операции 125, инициатор 120 запроса в операции 130 может отправить запрос к KMS 115 на один или несколько секретов/защищенные данные. После верификации запроса KMS 115 в операции 135 может передать секрет или запрошенные данные обратно инициатору 120 запроса по безопасному каналу связи. Согласно стандартам в данной области техники, секрет/запрошенные данные могут быть переданы в операции 135 по защищенному каналу без какой-либо дополнительной защиты поверх защищенного канала. В результате секрет/данные, которые передаются в операции 135, могут быть доступны запрашивающему устройству 120.

[0022] Фиг. 1B изображает иллюстративную систему и процесс 100b для более безопасного обмена одним или несколькими секретами или защищенными данными между инициатором 120 запроса и KMS 115 от имени доверенной среды 140 исполнения (Trusted Execution Environment, TrEE), анклава или другого компонента, используемого для указания изолированной среды исполнения, ассоциированной с инициатором 120 запроса. TrEE 140 может быть изолирована от инициатора 120 запроса, так что код и/или данные, содержащиеся в TrEE 140, могут быть недоступны (например, для чтения и/или записи) инициатору 120 запроса. Фиг. 2 изображает пример 200 доверенной среды исполнения, в которой вычислительное устройство 205 может включить в себя логику 210 (например, код) и информацию 220 о состоянии, такую как данные. Информация 220 о состоянии может храниться или располагаться в изолированной области 215, например, может быть защищена от несанкционированного доступа. В некоторых случаях данные 220 внутри изолированной области 215 не могут быть прочитаны или записаны напрямую любым субъектом, кроме логики 210, ассоциированной с изолированной областью 215. Изолированная логика 210 решает, какие типы доступа она позволит к какому типу или части данных 220. В одном примере логика 210 может позволять постепенно увеличивать и считывать значение, ассоциированное с данными 220, но не изменять иным образом данные 220. В другом примере логика 210 может позволять криптографические операции с помощью ключа, не предоставляя ни на каком этапе доступ к значению самого ключа. В показанном примере логика или код 210 могут находиться в общей или доступной области CPM 205; однако следует понимать, что в некоторых случаях логика 210 также может быть расположена в той же самой или другой изолированной области в виде информации 220 о состоянии.

[0023] Возвращаясь к системе 100b, адресующий блок управления протокола (Targeting Protocol Head, TPH) 150 может быть реализован на серверной стороне 105 для того, чтобы служить в качестве посредника между инициатором 120 запроса/TrEE 140 и KMS 115. Блоком управления протокола может называться программная реализация обработчика протокола, как правило, расположенного перед системой, которая изначально не может общаться на конкретном протоколе. Адресацией может называться криптографическая адресация среды исполнения. Если взять это вместе, данный термин может обозначать программное обеспечение и/или аппаратное обеспечение, реализующее протокол для получения секретов, который адресует ответы в TrEE. В некоторых аспектах адресующий блок 150 управления протокола может быть реализован, например, как виртуальный или облачный ресурс, который может быть запущен на другом аппаратном обеспечении, программном обеспечении и/или отдельно от KMS 115. В некоторых аспектах субъект, такой как центр обработки данных, может размещать и/или обеспечивать адресующий блок 150 управления протокола, например, как услугу. Адресующий блок 150 управления протокола может выполнять две основных функции: 1) осуществлять связь с KMS 115/получать секрет или защищенные данных от внешнего субъекта и 2) адресовать ответы доверенной среде 140 исполнения (Trusted Execution Environment, TrEE) инициатора запроса 120. В результате использования адресующего блока 150 управления протокола инициатор 120 запроса не должен аутентифицироваться в KMS 115 напрямую. KMS 115 передает свои секреты адресующему блоку 150 управления протокола, а не инициатору 120 запроса. Функцией адресующего блока 150 управления протокола является адресация ответов в TrEE 140 инициатора 120 запроса, тем самым гарантируя, что инициатор 120 запроса не может получить секрет/защищенные данные в виде открытого текста. Адресующий блок 150 управления протокола может вместо этого выполнять аутентификацию в KMS 115 от имен инициатора 120 запроса, но может делать это с использованием или не используя идентификационную информацию инициатора 120 запроса. В некоторых случаях может потребоваться убедить адресующий блок 150 управления протокола в том, что секрет, который он собирается вернуть TrEE 140 инициатора 120 запроса, будет находиться в «надежных руках». В этом случае инициатор 120 запроса может предоставить аттестируемую информацию адресующему блоку 150 управления протокола о состоянии TrEE 140, которая может включать в себя проверяемый материал ключа, ассоциированный с TrEE 140, для которого могут быть зашифрованы ответы.

[0024] В некоторых случаях несколько различных процессов, например, обеспеченных одним или несколькими доверенными приложениями, могут работать одновременно в безопасном ядре, где каждое доверенное приложение и безопасное ядро рассматриваются как TrEE 140 (например, это является примером вложенной TrEE). В этом сценарии каждое отдельное доверенное приложение может быть ассоциировано с ID сеанса, типом доверенного приложения и/или другим ID, который может использоваться для идентификации отдельного доверенного приложения в безопасном ядре (например, оба из которых представлены как TrEE 140). Ответ от адресующего блока 150 управления протокола может быть адресован узко конкретному доверенному приложению в пределах TrEE 140, идентифицированному в запросе, как будет описано более подробно ниже.

[0025] В случае адресации TrEE 140 нет никакой необходимости в защищенном канале между инициатором 120 запроса и адресующим блоком 150 управления протокола, так как самому инициатору 120 запроса не доверяют ответ. Однако следует понимать, что защищенный канал между инициатором 120 запроса и адресующим блоком 150 управления протокола может быть добавлен посредством операции 160 аутентификации, например, для защиты доступа к самому запросу (какой секрет хочет инициатор запроса), что может привести к нежелательному раскрытию информации. После или вместо аутентификации в операции 160 инициатор 120 запроса, от имени TrEE 140, может отправить запрос на один или несколько секретов или секретных или защищенных данных в адресующий блок 150 управления протокола, например, для доставки в TrEE 140, в операции 155. В некоторых аспектах запрос может быть ассоциирован с или может идентифицировать TrEE 140. Адресующий блок 150 управления протокола может определить, является ли TrEE 140 доверенным. В одном аспекте аутентификация инициатора 120 запроса может полагаться на инициализацию "чистой комнаты". В другом аспекте аутентификация может полагаться на аттестацию.

[0026] Инициализация "чистой комнаты" может использоваться, когда устройство инициатора 120 запроса, например, совершенно новое и обоснованно предполагается не содержащим вредоносного программного обеспечения. Иллюстративный процесс для доставки защищенных данных в TrEE, ассоциированную с инициатором запроса, с использованием инициализации "чистой комнаты" будет описан более подробно ниже со ссылкой на фиг. 3. Иллюстративный процесс для доставки защищенных данных в TrEE, ассоциированную с инициатором запроса, с использованием аттестации (например, службы аттестации) будет описан более подробно ниже со ссылкой на фиг. 4.

[0027] В любом случае, после того как TPH 150 аутентифицировал инициатора 120 запроса и/или установил степень доверия к TrEE 140, TPH 150 может аутентифицировать и установить безопасный канал связи с KMS 115 в операции 165. В некоторых аспектах KMS 115 может включать в себя или быть ассоциирован с любым субъектом, содержащим один или несколько секретов или защищенные данные, такие как лицензии, разрешения, пароли и так далее. После установления безопасного канала связи с KMS 115 TPH 150 может отправить запрос на защищенные данные в операции 170. KMS 115 может вернуть запрошенный секрет в операции 175. TPH 150 может адресовать секрет(ы) или защищенные данные в TrEE 140 и послать один или несколько секретов в операции 180.

[0028] В некоторых аспектах доставка защищенных данных в TrEE 140 в операции 180 может использовать по меньшей мере одну из следующих структур данных: идентификационный ключ шифрования, который может быть создан на основе идентификационной информации TrEE, или процесса аттестации, или журнала аттестации, или в примере вложенной TrEE (например, доверенного приложения, выполняющегося поверх безопасного ядра) идентификационный ключ подписи, который также может быть создан на основе процесса аттестации, как будет описано более подробно ниже.

[0029] Фиг. 1C изображает другую иллюстративную систему и процесс 100c для безопасного обмена одним или несколькими секретами или защищенными данными между инициатором 120 запроса и KMS 115 от имени доверенной среды 140 исполнения (TrEE). Система 100c может быть конкретным примером системы 100b, описанной выше. В системе 100c адресующим блоком 150 управления протокола может быть служба 150a защиты хоста (Host Guardian Service, HGS). В системе 100c HGS 150a может принимать средство 190 защиты ключей (key protector, KP), например, от облачного хоста 185 или другого субъекта, который может инстанцировать или иным образом управлять TrEE 140. В системе 100c инициатор 120 запроса может быть ассоциирован с виртуальной машиной, например, обеспеченной облачным хостом 185. KP 190 может включать в себя один или несколько аспектов средства защиты ключей, описанного в связанной заявке на патент США №14/481,399, озаглавленной «Безопасный транспортный протокол зашифрованных виртуальных машин с непрерывным доступом владельца», поданной 9 сентября 2014. KP 190 может содержать один или несколько секретов, используемых TrEE 140, например, транспортный ключ. KP 190 может, в сущности, обернуть транспортный ключ так, чтобы он был доступен только ряду блоков защиты, которым разрешен доступ к транспортному ключу. KP 190 может быть зашифрован таким образом, что для того, чтобы считать содержание KP 190 и извлечь транспортный ключ, HGS 150a может запрашивать ключ дешифрования от KMS 115 в операции 170a после аутентификации и установления безопасного канала связи с KMS 115 в операции 165. KMS 115 в ответ может послать ключ дешифрования в HGS в операции 175a. Затем HGS 150a может использовать ключ дешифрования для дешифрования KP 190 и извлечения одного или нескольких секретов (например, транспортного ключа) для отправки в TrEE 140. Затем HGS 150a может отправить секреты или транспортный ключ в TrEE в операции 180 с помощью одной или нескольких методик адресации, которые будут описаны более подробно ниже. В некоторых аспектах TrEE 140 может быть адресована на основе данных от KP 190.

[0030] Следует понимать, что в некоторых случаях HGS 150a и KMS 115 могут быть одним субъектом, так что между ними не требуется устанавливать канал связи и не требуется аутентификация.

[0031] В системе 100c не требуется аутентификация между инициатором 120 запроса и HGS 150a. Пока облачный или матричный (fabric) хост 180 исправен, не имеет значения, какой матричный хост осуществляет связь с HGS 150a, если он является одним из серверов в матрице (это можно верифицировать с помощью аттестации).

[0032] Фиг. 3 изображает иллюстративный процесс 300 для доставки защищенных данных в TrEE инициатора запроса, при этом предполагается, что инициатор запроса является заслуживающим доверия (например, не содержит вредоносного программного обеспечения). В настоящем документе пунктирные линии прямоугольника или операции на любой фигуре указывают, что операция является опциональной, так что она может быть опущена. Процесс 300 может использовать ключ шифрования, ассоциированный с TrEE, например, открытый ключ пары закрытый ключ-открытый ключ (например, пары ключей асимметричного шифрования), сгенерированный TrEE или безопасным ядром инициатора запроса, инициирующего TrEE. В других случаях ключ шифрования может быть симметричным. В настоящем документе безопасным ядром может называться любая часть вычислительного устройства, которая ассоциирована с более высоким уровнем безопасности, как известно в данной области техники.

[0033] В этом сценарии TrEE 140 может запускаться или инициироваться в операции 302, и один или несколько закрытых ключей (например, закрытых ключей шифрования) и соответствующие открытые ключи могут генерироваться в TrEE 140 в операции 304. Затем соответствующий открытый ключ может быть зарегистрирован в TPH 150 и ассоциирован с идентификационной информацией инициатора запроса и/или запрашивающего устройства в операции 306. В некоторых случаях открытый ключ TrEE 140 должен быть зарегистрирован только один раз, так что после того, как открытый ключ зарегистрирован, процесс 300 может начинаться с операции 308. Затем инициатор 120 запроса может выполнить в операции 308 аутентификацию в TPH 150 с помощью любой известной методики аутентификации. Затем TPH 150 может выполнить поиск открытого ключа, чтобы использовать его для доставки ответа в TrEE 140, например, на основе зарегистрированного открытого ключа TrEE 140, который может быть ассоциирован с идентификационной информацией инициатора 120 запроса. Этот процесс может называться инициализацией «чистой комнаты», потому что безопасно он может выполняться только тогда, когда инициатор 120 запроса находится в известном-хорошем или заслуживающем доверия состоянии. В этом примере нет необходимости в аутентификации на основе сертификатов, когда инициатор 120 запроса посылает сертификат работоспособности TrEE (TrEE Health Certificate, THC) в TPH 150, потому что инициатор 120 запроса заслуживает доверия. При отсутствии общедоступных служб аттестации это является жизнеспособным вариантом проверки, что правильный TrEE 140 адресуется TPH 150.

[0034] Затем в операции 312 TPH 150 может получить защищенные данные для доставки в TrEE 140, например, от KMS 115, как было описано выше. Используя открытый ключ TrEE, к которому получили доступ в операции 310, TPH 150 затем в операции 314 может создать сообщение для отправки в TrEE 140, включающее в себя полученные защищенные данные. TPH 150 может послать сообщение инициатору 120 запроса в операции 316.

[0035] После приема сообщения инициатор 120 запроса может передать его TrEE 140 в операции 318. Поскольку инициатор 120 запроса не имеет доступа к закрытому ключу TrEE, инициатор 120 запроса не может дешифровать сообщение для доступа к защищенным данным. TrEE 140 может использовать свой закрытый ключ для дешифрования сообщения и получения доступа к защищенным данным в операции 320.

[0036] Фиг. 4А изображает иллюстративный процесс 400 для доставки защищенных данных в TrEE недоверенного инициатора запроса. Процесс 400 может использовать ключ шифрования, ассоциированный с TrEE, например, открытый ключ пары закрытый ключ-открытый ключ, сгенерированный TrEE или безопасным ядром инициатора запроса, который инициирует TrEE, например, в случае вложенной TrEE, который может называться в настоящем описании доверенным приложением. Процесс 400 дополнительно или альтернативно может использовать ключ подписи безопасного ядра, которое можно считать внешней TrEE, с доверенным приложением, вложенным или исполняющимся поверх безопасного ядра, ассоциированного с TrEE, которая может использоваться для сертификации открытого ключа пары ключей, сгенерированной TrEE, как будет описано более подробно ниже.

[0037] В соответствии с процессом 400 после инициализации TrEE в операции 402 инициатор 120 запроса может запросить отчет или заключение об аттестации у службы аттестации в операции 406. Фиг. 4B изображает иллюстративный процесс для получения заключения или отчета об аттестации у службы 424 аттестации. В примере на фиг. 4B инициатор 120 запроса может создать журнал аттестации (журнал TCG) при начальной загрузке, содержащий открытый ключ (IDK_E) TrEE 140 (доверенного приложения) или ключ подписи (IDK_S) TrEE (безопасного ядра) в операции 426. Затем инициатор 120 запроса может предоставить журнал TCG службе 424 аттестации в операции 428. В некоторых случаях TPH 150 может направить, или инициатор 120 запроса может выбрать службу аттестации, которой доверяет TPH 150. Служба 424 аттестации может проверить журнал TCG и выдать сертификат работоспособности TrEE (TrEE Health Certificate, THC) на основе ключа шифрования (IDK_E) и/или ключа подписи (IDK_S) TrEE 140 (безопасного ядра) в операции 430. Затем служба 242 аттестации может послать THC (также называемый в настоящем описании заключением об аттестации) обратно инициатору 120 запроса в операции 432.

[0038] После получения заключения об аттестации в операции 406, инициатор 120 запроса может послать заключение об аттестации и запрос на защищенные данные в TPH 150 от имени TrEE 140 в операции 408. THC или заключение об аттестации могут содержать имя инициатора 120 запроса (для создания привязки между идентификационной информацией инициатора запроса, установленной во время аутентификации, и сертификатом) и ключ, который ответчик (TPH 150) должен использовать при формировании ответа (например, ключ шифрования или ключ подписи).

[0039] В некоторых аспектах защищенная от несанкционированного использования идентификационная информация, такая как ключ шифрования (Encryption Key, EK) доверенного платформенного модуля (Trusted Platform Module, TPM), ассоциируется с инициатором 120 запроса. Аттестация инициатора 120 запроса может выполняться с помощью EK TPM, как известно в данной области техники.

[0040] В некоторых аспектах либо за пределами полосы, либо через идентификатор объекта (Object Identifier, OID) политики выдачи (Issuance Policy, IP), который может быть частью THC, TrEE через инициатора 120 запроса может осуществлять связь с TPH 150 независимо от того, является ли ключ ключом шифрования или ключом подписи. Выбор между тем, какой ключ используется, может влиять на выбор механизма, используемого для структурирования ответа, как было описано выше. Критически важно, что TPH 150 не требует доказательства владения закрытым ключом, поддерживающим сертификат, просто потому, что если дается неправильный сертификат, инициатор 120 запроса в любом случае будет не в состоянии понять ответ, так как он не имеет доступа к соответствующему закрытому ключу.

[0041] Фиг. 5А и 5B изображают иллюстративный процесс 500 для доставки защищенных данных во вложенную TrEE недоверенного инициатора запроса. В некоторых аспектах два или более TrEE могут быть вложенными, так что одна TrEE содержится в другой TrEE. В настоящем описании доверенное приложение является вложенной TrEE, содержащейся во внешней TrEE. В одном примере внешняя TrEE может включать в себя безопасное ядро доверенной части операционной системы, например, конкретную область памяти, ассоциированную с виртуальным доверительным уровнем, как будет описано более подробно ниже со ссылкой на фиг. 6. Процесс 500 может использоваться, например, когда доступен только ключ шифрования внешней TrEE, которая в некоторых случаях может быть безопасным ядром машины, инстанцирующим доверенное приложение.

[0042] Процесс 500 может начинаться с операции 502, в которой инициатор 120 запроса запускает доверенное приложение с «идентификатором сеанса», который определяется инициатором 120 запроса, который может включать в себя любой тип идентификатора, например, относящийся к или идентифицирующий, с каким контентом или данными будет работать доверенное приложение, относящийся к пользователю доверенного приложения и т.д. (например, «доверенное приложение потокового контента для воспроизведения 'конкретного произведения'»). В одном примере ID сеанса может быть 32-байтовым значением. Это значение может быть сохранено, доступно только для чтения в течение срока жизни доверенного приложения и доступно безопасному ядру при приеме адресного сообщения к доверенному приложению. Значение может отсутствовать (не указано при запуске процесса), в этом случае ID сеанса может считаться равным нулю.

[0043] Затем в операции 504 инициатор 120 запроса может выполнить аутентификацию в TPH 150 (опционально, как было описано выше, но только при очень ограниченных обстоятельствах, например, когда действительно нет разницы между инициаторами запроса). Один пример, где желательна привязка между TrEE (например, ключом TrEE) и идентификационной информацией инициатора запроса, например, когда воспроизведение элемента контента, такого как фильм, ограничено лицензией или проверкой абонента (например, пользователь Netflix хочет получить лицензию на воспроизведение фильма, но Netflix хочет удостовериться, что это именно тот абонент, который принимает лицензию на фильм (в их TrEE)).

[0044] Инициатор 120 запроса может получить заключение об аттестации, например, в соответствии с процессом 406, описанным выше со ссылкой на фиг. 4B, от службы аттестации, которой доверяет TPH 150, в операции 506. Затем инициатор 120 запроса может представить TPH 150 заключение об аттестации в операции 508. Следует понимать, что в примере инициализации «чистой комнаты», описанном выше, который может быть применим здесь, нет необходимости в аттестации.

[0045] После приема заключения об аттестации TPH 150 может верифицировать заключение об аттестации (или, в случае примера инициализации «чистой комнаты» выше, выполнить поиск ключа инициатора запроса на основе его идентификационной информации) в операции 510. В этой точке процесса 500 инициатор 120 запроса знает, какой использовать ключ для адресации внешней TrEE. В некоторых аспектах указание, что ключ, полученный из заключения об аттестации или запроса, является ключом шифрования внешней TrEE или безопасного ядра (а не их внутреннего доверенного приложение), может быть включено в запрос или заключение об аттестации, передано другим образом или за пределами полосы в TPH 150, установлено как процедура по умолчанию и т.д. Затем в операции 511 TPH 150 может получить защищенные данные, указанные в запросе, например, от KMS 115 или от любого другого субъекта, содержащего защищенные данные, таких как одна или несколько служб, содержащих лицензии, пароли, разрешения и/или другую информацию.

[0046] TPH 150 может определить, какой тип доверенного приложения адресовать, например, на основе запроса или на основе самого TPH 150 (например, каждый TPH 150 может быть разработан специально для некоторой цели или приложения, например, Netflix) в операции 512. В примере, использующем KP, таком как описано со ссылкой на фиг. 1C выше, тип доверенного приложения может быть закодирован в KP. В некоторых других примерах тип доверенного приложения может быть задан по умолчанию или жестко задан, например, в реализациях, использующих HGS 150a. В случае HGS, HGS 150a может всегда адресовать доверенное приложение безопасного процесса виртуального режима (Virtual Mode Secure Process, VMSP), тип которого может быть жестко задан (поскольку KP может не содержать эту информацию).

[0047] После определения типа доверенного приложения для адресации TPH 150 может создать сообщение, включающее в себя защищенные данные для отправки в TrEE, в операции 514. Более подробный пример операции 514 изображен на фиг. 5B.

[0048] В некоторых аспектах операция 514 может дополнительно включать в себя операцию 536, в которой TPH 150 генерирует два случайных симметричных ключа: ключ передачи (transfer key, TX) и ключ упаковки (wrapping key, TW). Затем TPH 150 может зашифровать TX с помощью открытого ключа в THC (который является частью заключения об аттестации) в операции 538 (например, полагая, что THC основан на ключе шифрования, а не ключе подписи). В некоторых аспектах операция 538 может включать в себя шифрование TX с помощью IDK хоста с использованием шифрования RSA и заполнения OAEP. В некоторых аспектах TPH 150 может верифицировать ID сеанса доверенного приложения в операции 540, например, для верификации, что доверенное приложение авторизовано или имеет корректное разрешение на получение доступа к защищенным данным (например, заплачено за онлайн-услугу или элемент контента). В некоторых случаях ID сеанса может включать в себя тип доверенного приложения; однако в других случаях тип доверенного приложения может быть закодирован в KP или даже жестко задан. TPH 150 может затем зашифровать TW с помощью TX, а тип доверенного приложения и ID сеанса доверенного приложения могут быть конкатенированы и использованы в качестве «аутентификационной метки» в операциях 542 и 544. Следует отметить, что использование аутентификационной метки является артефактом протокола AES-GCM; другие криптографические протоколы могут использовать другую схему с тем же самый эффектом. Идея, стоящая за аутентификационной меткой, состоит в том, чтобы связать TW с типом доверенного приложения и ID сеанса таким образом, чтобы они не могли быть распутаны злоумышленником при передаче. Существует много других способов достижения этого криптографически; AES-GCM описывается в настоящем описании потому, что он обеспечивает эту функциональность изначально и, поэтому, является предпочтительным.

[0049] TPH 150 может затем послать зашифрованный TX и аутентифицированное шифрование TW инициатору 120 запроса в операции 546. Возвращаясь к фиг. 5А, после приема сообщения 516, которое может генерироваться с помощью операций на фиг. 5B и/или может включать в себя защищенные данные, зашифрованные аналогичным образом, что и TW, инициатор 120 запроса может перенаправить сообщение доверенному приложению в операции 518. Поскольку доверенное приложение неспособно расшифровать сообщение (оно пытается получить TW), доверенное приложение может передать сообщение безопасному ядру в операции 520. Альтернативно, инициатор 120 запроса может послать ответ безопасному ядру, минуя доверенное приложение, и безопасное ядро сообщит доверенному приложению новую информацию, когда оно дешифрует TW.

[0050] Затем в операции 522 безопасное ядро может дешифровать TX с помощью своего закрытого ключа шифрования, а затем дешифровать TW с помощью TX, используя аутентификационную метку, чтобы гарантировать, что правильный тип доверенного приложения с корректным ID сеанса запрашивает дешифрацию сообщения. Если аутентификационная метка верифицируется, безопасное ядро может вернуть TW доверенному приложению в операции 524. Доверенное приложение затем может использовать принятый TW для дешифрования всего того, что еще шифрует TW, например, защищенных данных, которые могут иметь любой размер.

[0051] В некоторых аспектах безопасное ядро может реализовывать один или несколько процессов, например, заданных одним или несколькими API, для приема, дешифрования и передачи адресованных сообщений правильному доверенному приложению. API может принимать зашифрованное сообщение, предназначенное для конкретного доверенного приложения, и дешифровывать TX с помощью закрытой части IDK (идентификационного ключа шифрования безопасного ядра). API может создавать свою собственную аутентификационную метку с помощью конкатенации типа доверенного приложения и ID сеанса вызывающего доверенного приложения в качестве метки (не может использовать предоставленную аутентификационную метку из очевидных соображений безопасности). Затем могут быть получены тип доверенного приложения и ID сеанса. Если аутентификация была успешной, API затем может дешифровать TW с помощью TX. Если дешифрование было успешным, API затем может вернуть TW доверенному приложению.

[0052] В одном примере принятое сообщение может включать в себя следующую информацию: номер версии (например, 0); ID протокола шифрования ключа передачи (например, RSA 2048); ID заполнения для шифрования ключа передачи (например, OAEP); ID протокола шифрования ключа упаковки (например, AES-GCM); длину зашифрованного текста ключа передачи; длину ключа упаковки аутентификационной метки (игнорируется); длину зашифрованного текста ключа упаковки; и зашифрованный текст ключа передачи, ключ упаковки аутентификационной метки (игнорируется) и зашифрованный текст ключа упаковки. Следует понимать, что это лишь один способ из множества, с помощью которых может быть создано сообщение.

[0053] В некоторых аспектах одна или несколько описанных выше систем или процессов, процесс 100, 300, 400 или 500/система 100, могут быть реализованы в ресурсах или виртуальной машине, реализующей виртуальный безопасный режим (Virtual Secure Mode, VSM). VSM и связанные с ним концепции в контексте виртуальных машин описываются в заявке на патент США №14/186,415, озаглавленной «Виртуальный безопасный режим для виртуальных машин», поданной 21 февраля 2014. Фиг. 6 изображает систему или операционную систему 600 хоста, включающую в себя вычислительную среду VSM, разделенную на различные виртуальные уровни доверия, VTL0 610 и VTL1 615. Система 600 может быть более конкретной реализацией одного или нескольких аспектов систем 100a, 100b или 100c, таким как облачный хост 180, включающий в себя вычислительную среду, работающую в VSM. VTL0 610 может включать в себя пользовательский режим 620 и нормальный режим 630 ядра, а VTL1 615 может включать в себя пользовательский режим 625 и безопасный режим 635 ядра. Различные VTL могут обеспечиваться гипервизором, например, выполняющимся поверх физических вычислительных компонентов или виртуальных вычислительных ресурсов (например, одной или нескольких виртуальных машин), которые взаимодействуют и задают VTL0 610 и VTL1 615 через ограничения на доступ к памяти для некоторых процессов и т.п. В изображенном примере VTL1 615 может быть более безопасным, чем VTL0 610, так что требуется более высокий уровень доступа для чтения и/или записи данных или кода, ассоциированных с VTL1. VTL0 610 может соответствовать инициатору 120 запроса, тогда как VTL1 615 может соответствовать TrEE 140. Ниже система 600 описывается как использующая KP 700. Однако следует понимать, что это дано лишь в качестве примера; система 600 может использовать схемы аттестации/аутентификации, описанные выше, без использования KP, с аналогичным эффектом.

[0054] Как описано со ссылкой на систему 600, клиентское приложение 650/VTL0 610 хоста 600 может соответствовать инициатору 120 запроса, тогда как VTL1 615 и более конкретно безопасное ядро 635 VTL1 615 может соответствовать TrEE 140. В некоторых аспектах доверенные приложения 640 могут соответствовать вложенному доверенному приложению, описанному со ссылкой на процесс 500. В некоторых аспектах система 600 может реализовывать процесс 500, описанный выше. В других случая система 600 может реализовывать процесс 800 и/или 900, описанные ниже со ссылкой на фиг. 8 и 9, при этом основная разница между процессами 500 и 800 заключается в использовании KP для инициализации доверенного приложения и использовании конкретной реализации HGS 150a вместо более универсального TPH 150.

[0055] Как проиллюстрировано, одна или несколько TrEE или доверенных приложений 640 могут находиться в пользовательском режиме 625 VTL1 615. В некоторых аспектах к одному или нескольким доверенным приложениям 640 может получить доступ безопасный процесс витруальной машины (Virtual Machine Secure Process, VMSP) 645, или они могут быть ассоциированы с VMSP 645. Клиентская операция, приложение, программа и т.д. 650 (клиент) может работать в пользовательском режиме 620 VTL0 610. Сервер 655, находящийся в пользовательском режиме 625 VTL1 615, может осуществлять связь с клиентом 650 через RPC 660. Как проиллюстрировано, клиент 650 может запросить инициирование доверенного приложения 640 на выполнение одной или нескольких безопасных операций, например, с использованием VMSP 645 с помощью одного или нескольких RPC 660. В других аспектах сервер 655 может инициировать доверенное приложение 640, не принимая явный запрос от клиента 650. В любом случае сервер 655 может инициировать доверенное приложение(я) 640, при этом конкретный тип доверенного приложения идентифицирует параметры доверенного приложения, и ID сеанса идентифицирует конкретную копию доверенного приложения 640. В некоторых аспектах тип доверенного приложения может быть инициализирован с помощью структуры данных, включающей в себя KP 405, такой как было описано выше в системе 100c со ссылкой на фиг. 1C. Иллюстративная структура данных, включающая в себя KP, такую как KP 700, изображена на фиг. 7.

[0056] Структура 700 данных может включать в себя средство 705 защиты ключа (key protector, KP), которое является криптографической оберткой ключа шифрования (здесь транспортного ключа (transport key, TK)), как описано в заявке на патент США № 14/481,399, озаглавленной «Безопасный транспортный протокол зашифрованных виртуальных машин с непрерывным доступом владельца», поданной 9 сентября 2014. KP 705 гарантирует, что доступ к TK 710 и/или другим защищенным данным предоставляется только авторизованным субъектам. TK 710, который является ключом, который должен быть доставлен в TrEE 140, может быть обернут с помощью KP 705, или в некоторых случаях с помощью ключа упаковки или TW. TK 710 может считаться секретом высокой ценности. В некоторых случаях TK 710 может быть дешифрован в KMS 115.

[0057] Структура данных 700 также может включать в себя данные виртуальной машины (Virtual Machine Data, VMD) 730, которые могут включать в себя данные для инициализации доверенного приложения. VMD 730 может быть зашифрован с помощью подходящей технологии шифрования, такой как BitLocker, доступный от компании Microsoft Corporation, Редмонд, штат Вашингтон. Ключ шифрования всего тома (Full Volume Encryption Key, FVEK) 725, который может использоваться для дешифрования VMD 730 и который может быть защищен виртуальным доверенным платформенным модулем (Virtual Trusted Platform Module, V_TPM), состояние которого (725) шифруется и сохраняется как часть метаданных вместе с KP 705. В некоторых аспектах FVEK 725 может быть зашифрован с помощью главного ключа тома (Volume Master Key, VMK) 720. Само по себе состояние 725 V_TPM шифруется с помощью ключа, обернутого с помощью KP 705. В некоторых аспектах состояние 725 V_TPM может шифроваться с помощью TK 710 (секрета высокой ценности), а данные «запечатываться» в значения PCR (например, PCR7), так что если значение PCR находится в ожидаемом состоянии, TPM предоставит доступ, например дешифрует, к ключевому материалу. В этом случае средство защиты TPM является структурой данных, которая подается в TPM для распечатывания некоторого секрета, если один или несколько PCR находятся в ожидаемых состояниях. В других случаях также могут использоваться не-TPM средства защиты.

[0058] Главный ключ тома (Volume Master Key, VMK) 720 может быть распечатан с помощью состояния 725 V_TPM. Состояние 725 V_TPM может быть зашифровано с помощью TK 710 внутри KP 705. В некоторых случаях VMK 720 может быть главным ключом тома Bitlocker и может быть помечен как секрет низкой ценности.

[0059] Каждое поле или блок KP 700 также может быть описан с точки зрения того, что он шифрует, например такого сокращения, как «шифрует(ключ, данные)»:

VMD_DISK шифрует(FVEK, дисковые данные в формате открытого текста (ClearText))

FVEK_DISK шифрует(VMK, FVEK)

VMK_DISK шифрует(VMK)

V_TMP.DISK шифрует(TK, V_TMP)

TK_DISK шифрует(KP, TK)

KP ассоциирован с VM, и доверенное приложение на самом деле никогда не видит его. KP идет в KMS, которая дешифрует его и возвращает TK доверенному приложению (с помощью механизма адресации, описанного выше). TK дешифрует vTPM, vTPM распечатывает VMK, давая FVEK.

[0060] В одном примере KP 405, состояние 415 V_TMP, VMK 420 и VMD 430 могут быть данными, хранящимися на диске. Состояние 415 V_TMP может быть инициализировано, когда V_TMP создается, и можно гарантировать, что оно будет уникальным. Для уникальности во время выполнения, например, генерируемых секретов или защищенных данных, V_TMP полагается на безопасность RNG, предлагаемого ему безопасным ядром. После того, как доверенное приложение дешифрует состояние 415 V_TMP с использованием дешифрованного TK 710, оставшиеся операции для доступа к VMD 730 могут быть такими же или аналогичными операциям, выполняемым между физической машиной и физическим TPM. Эти операции могут включать в себя выполнение V_TMP измерений для VSM, использование V_TMP измерений для распечатывания VMK (результатом чего является обеспечение FVEK 725 загрузчику операционной системы), и использование операционной системой FVEK 725 для дешифрования VMD 730.

[0061] Для запуска доверенного приложения клиент 650 может запросить и/или принять структуру 700 данных. Клиент 650 может послать KP 705 или целиком структуру 700 данных в TPH 150 (или в некоторых реализациях HGS 150a), который может связаться с KMS 115 для дешифрования TK 710. Затем TPH может адресовать TK 710 в безопасном ядре 635, ассоциированном с доверенным приложением 640, например, с помощью процесса 800, описанного ниже, используя IDK_pub 665. Безопасное ядро 635 может получить IDK_pub и IDK_pri во время запуска. Безопасное ядро 635 может использовать свой закрытый ключ 675 (например, IDK_pri), чтобы дешифровать и вернуть TK 710 серверу 655. Затем сервер 655 может доставить TK 710 доверенному приложению 640. В некоторых случаях безопасное ядро 635 может вернуть TK 710 напрямую доверенному приложению 640. В некоторых аспектах защищенные данные могут быть доставлены доверенному приложению 640 с TK 710 и могут быть зашифрованы с помощью TK 710. Таким образом, доверенное приложение 640 может дешифровать защищенные данные с помощью TK 710.

[0062] Фиг. 8 изображает иллюстративный процесс 800 для адресации транспортного ключа и/или защищенных данных, зашифрованных транспортным ключом, TrEE или конкретному доверенному приложению с помощью идентификационного ключа TrEE или доверенного приложения. Более конкретно, процесс 800 изображает способ адресации доверенного приложения с помощью ключа шифрования безопасного ядра доверенного приложения.

[0063] OS хоста или облачного матричного хоста (например, OS 600 хоста) выполняет последовательность этапов для приема транспортного ключа. Облачный матричный хост сначала может получить сертификат работоспособности TrEE (TrEE Health Certificate, THC), например, созданный на основе идентификационного ключа шифрования (Encryption Identity Key, IDK_E) безопасного ядра, ассоциированного с TrEE или доверенным приложением, в операции 602, например, в соответствии с процессом, описанным со ссылкой на фиг. 4B выше. В одном аспекте операция 602 может включать в себя создание хостом журнала аттестации (журнала TCG) при начальной загрузке, который содержит открытую версию IDK_E, закрытая часть которого находится в безопасном ядре (Secure Kernel, SK) VSM, ассоциированном с доверенным приложением. Журнал аттестации может быть представлен службе аттестации (Attestation Service, AS). AS может проверить журнал аттестации и выдать THC хосту, созданный на основе IDK_E (например, открытой части асимметричного ключа). В некоторых аспектах аналогично IDK_E также может быть создан «Идентификационный ключ подписи» (Signing Identity Key, IDK_S), и он может иметь отдельный THC, созданный на его основе, как будет описано более подробно ниже со ссылкой на фиг. 9. Решение проблемы доставки ключа может быть получено с помощью как IDK_E, так и IDK_S, как описано ниже.

[0064] Когда наступает время для загрузки новой защищенной VM, хост получает KP VM в операции 804 и инициирует общение с TPH (например, TPH 150), целью которого является инъекция TK, зашифрованного с помощью KP, в доверенное приложение VMSP.

[0065] Для обмена KP на TK хост может представить TPH, такой как TPH 150, KP и «идентификационную информацию доверенного приложения» вместе с THC в операции 806. Облачный матричный хост также может запустить доверенное приложение или TrEE с «ID сеанса», полученным из KP (KPSID) в операции 808. В некоторых аспектах принятый KP будет формировать основу значения ID сеанса путем применения к нему хеш-функции SHA-2 или использования других необратимых функций. TPH может проверить THC в операции 822 и связаться с KMS, таким как KMS 115, или другим субъектом, владеющим или имеющим доступ к защищенным данным и/или ключу дешифрования для KP, для дешифрования KP для доступа к TK в операции 824. В операции 826 TPH может использовать специальную криптографическую конструкцию для адресации доверенного приложения с помощью вычисленного KPSID, например, как было описано выше со ссылкой на процесс 500.

[0066] Инициатор запроса или клиент 650 могут принять ответ от TPH и передать его доверенному приложению с данным KPSID. Доверенное приложение или сервер могут попросить безопасное ядро VSM дешифровать ответ и вернуть ему TK в операции 810. Безопасное ядро в операции 812 изучает ответ, проверяет, что он адресует тип доверенного приложения и ID сеанса доверенного приложения, и в операции 818 возвращает ключ, только если имеется соответствие. Таким образом, если ответ TPH окажется в чужих руках, криптографически его невозможно понять. После приема ключа хост может дешифровать ключ и предоставить его TrEE в операции 820, на этом процесс 800 может завершаться.

[0067] Фиг. 9 изображает другой иллюстративный процесс 900 для адресации транспортного ключа и/или защищенных данных, зашифрованных транспортным ключом, доверенному приложению с помощью ключа подписи безопасного ядра. Более конкретно, процесс 900 изображает способ адресации доверенного приложения с помощью ключа шифрования доверенного приложения, сертифицированного ключом подписи безопасного ядра.

[0068] Процесс 800 иллюстрировал, как ответ может быть адресован доверенному приложению косвенно через идентификационный ключ шифрования, совместно используемый всеми доверенными приложениями. Однако если TrEE имеет аттестуемый идентификационный ключ подписи, также может использоваться другой подход. Здесь каждое доверенное приложение может генерировать свою собственную пару ключей шифрования, а безопасное ядро будет сертифицировать с помощью IDK_S часть с открытым ключом пары. Следует отметить, что такая сертификация также должна криптографически связывать ключ с типом доверенного приложения и ID сеанса доверенного приложения:

Сертификация ключа=σ IDK_S (Открытый_Ключ_Шифрования_Доверенного_Приложения, Тип_Доверенного_Приложения, ID_Сеанса)

где σ IDK_S обозначает конкатенацию его входных данных () с последующей подписью этих входных данных с помощью данного ключа.

В этом случае инициатор запроса представляет TPH ключ доверенного приложения вместе с THC и сертификацией ключа, а TPH отвечает путем шифрования транспортного ключа в ключ шифрования доверенного приложения, что отличается от операций 822 и 824 процесса 800.

[0069] В некоторых аспектах также может использоваться или указываться «номер версии безопасности» (Security Version Number, SVN) в сертификации ключа для предотвращения других типов атак, чтобы гарантировать, что TrEE не имеет более старую и потенциально уязвимую версию. В некоторых случаях, когда безопасное ядро аттестовано, а внутреннее доверенное приложение нет (например, доверенное приложение загружается по требованию после того, как аттестация уже выполнена), включение SVN доверенного приложения может дать TPH 150 указание отказываться от адресации более старых, уязвимых доверенных приложений, даже если с THC все в порядке.

[0070] Одно отличие между двумя подходами процессов 800 и 900 заключается в том, кто осуществляет привязку между доверенным приложением или ID TrEE, ID сеанса и транспортным ключом: в процессе 800 это безопасное ядро, а в процессе 900 это TPH 150. Другое основное отличие состоит в том, как ответ структурируется криптографически. В предыдущем случае он адресуется безопасному ядру, которое в свою очередь решает, какому доверенному приложению разрешено его видеть, а в этом случае ответ адресован непосредственно доверенному приложению, при этом ключ доверенного приложения сертифицирован ключом безопасного ядра.

[0071] В некоторых аспектах описанные выше методики могут быть реализованы для обеспечения полной изоляции учетных данных для контейнеров. Фундаментальная проблема та же самая, так что контейнер может запросить учетные данные у своего хоста. Хост затем может запросить учетные данные от имени контейнера у некоторого KMS. Если запрошенные учетные данные возвратятся хосту незашифрованные (например, учетные данные поступают по запросу и не являются частью образа контейнера), это приведет к «поздней привязке учетных данных». Эта привязка является ценной, но не обеспечивает изоляцию учетных данных, так что если хост скомпрометирован, учетные данные раскрываются.

[0072] В одном варианте осуществления раскрытые варианты осуществления могут быть реализованы как вычислительная система, содержащая:

[0073] процессор; и

[0074] память, соединенную с возможностью связи с процессором, хранящую инструкции, которые при исполнении процессором обеспечивают выполнение вычислительной системой следующих операций:

[0075] приема запроса на защищенные данные от инициатора запроса, ассоциированного с вложенной TrEE, заключения об аттестации безопасного ядра и заключения о сертификации ключа, при этом вложенная TrEE содержит доверенное приложение, выполняющееся поверх безопасного ядра, при этом заключение о сертификации ключа связывает открытый ключ шифрования доверенного приложения и ID доверенного приложения;

[0076] получения защищенных данных;

[0077] шифрования защищенных данных с помощью открытого ключа шифрования доверенного приложения; и

[0078] отправки зашифрованных защищенных данных инициатору запроса.

[0079] В одном варианте осуществления заключение о сертификации ключа генерируется с помощью ключа подписи безопасным ядром.

[0080] В одном варианте осуществления ключ подписи сертифицирует открытый ключ шифрования доверенного приложения пары закрытый ключ-открытый ключ, сгенерированной доверенным приложением.

[0081] В одном варианте осуществления ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

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

[0083] В одном варианте осуществления инструкции при исполнении процессором обеспечивают выполнение вычислительной системой операций, содержащих:

[0084] сравнение ID доверенного приложения со списком ID авторизованных доверенных приложений; и

[0085] шифрование защищенных данных с помощью открытого ключа шифрования доверенного приложения только тогда, когда ID доверенного приложения имеется в списке ID авторизованных доверенных приложений.

[0086] В одном варианте осуществления может быть реализован способ доставки защищенных данных вложенной доверенной среде исполнения (TrEE), содержащей доверенное приложение, выполняющееся поверх внешней TrEE, при этом как доверенное приложение, так и внешняя TrEE ассоциированы с недоверенным инициатором запроса, способ, содержащий:

[0087] прием адресующим блоком управления протокола запроса на защищенные данные от инициатора запроса, ассоциированного с вложенной TrEE, заключения об аттестации внешней TrEE и заключения о сертификации ключа, при этом заключение о сертификации ключа связывает открытый ключ шифрования доверенного приложения и ID доверенного приложения;

[0088] извлечение адресующим блоком управления протокола защищенных данных;

[0089] шифрование защищенных данных с помощью открытого ключа шифрования доверенного приложения; и

[0090] отправку зашифрованных защищенных данных инициатору запроса.

[0091] В одном варианте осуществления заключение о сертификации ключа генерируется с использованием ключа подписи внешней TrEE.

[0092] В одном варианте осуществления ключ подписи сертифицирует открытый ключ шифрования доверенного приложения пары закрытый ключ-открытый ключ, сгенерированной доверенным приложением.

[0093] В одном варианте осуществления ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

[0094] В одном варианте осуществления заключение о сертификации ключа генерируется с использованием ключа подписи внешней TrEE и связывает открытый ключ доверенного приложения, тип доверенного приложения и ID сеанса.

[0095] В одном варианте осуществления способ дополнительно содержит:

[0096] сравнение адресующим блоком управления протокола ID доверенного приложения со списком ID авторизованных доверенных приложений; и

[0097] шифрование адресующим блоком управления протокола защищенных данных с помощью открытого ключа шифрования доверенного приложения только тогда, когда ID доверенного приложения имеется в списке ID авторизованных доверенных приложений.

[0098] В одном варианте осуществления способ дополнительно содержит:

[0099] отправку инициатором запроса зашифрованных защищенных данных доверенному приложению; и

[00100] дешифрование доверенным приложением зашифрованных защищенных данных с использованием закрытого ключа шифрования доверенного приложения, соответствующего открытому ключу шифрования доверенного приложения.

[00101] В одном варианте осуществления защищенные данные содержат ключ упаковки.

[00102] В одном варианте осуществления может быть реализован машиночитаемый носитель данных, содержащий инструкции для доставки защищенных данных вложенной доверенной среде исполнения (TrEE), содержащей доверенное приложение, выполняющееся поверх безопасного ядра, носитель данных содержит инструкции, которые при исполнении на компьютерной системе заставляют компьютерную систему по меньшей мере:

[00103] принимать запрос на защищенные данные от инициатора запроса, ассоциированного с вложенной TrEE, заключение об аттестации безопасного ядра и заключение о сертификации ключа, при этом заключение о сертификации ключа связывает открытый ключ шифрования доверенного приложения и ID доверенного приложения;

[00104] извлекать защищенные данные;

[00105] зашифровывать защищенные данные с помощью открытого ключа шифрования доверенного приложения; и

[00106] посылать зашифрованные защищенные данные инициатору запроса.

[00107] В одном варианте осуществления заключение о сертификации ключа генерируется с помощью ключа подписи безопасным ядром.

[00108] В одном варианте осуществления ключ подписи сертифицирует открытый ключ шифрования доверенного приложения пары закрытый ключ-открытый ключ, сгенерированной доверенным приложением.

[00109] 18. Машиночитаемый носитель данных по п. 15, в котором ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

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

[00111] В одном варианте осуществления инструкции дополнительно содержат инструкции, которые при исполнении в вычислительной системе заставляют вычислительную систему по меньшей мере:

[00112] сравнивать ID доверенного приложения со списком ID авторизованных доверенных приложений; и

[00113] зашифровывать защищенные данные с помощью открытого ключа шифрования доверенного приложения, только если ID доверенного приложения имеется в списке ID авторизованных доверенных приложений.

[00114] Методики, описанные выше, могут быть реализованы на одном или нескольких вычислительных устройствах или средах, как описано ниже. Фиг. 10 изображает иллюстративную универсальную вычислительную среду, например, которая может воплощать одно или несколько из: инициатора 120 запроса, TrEE 140, TPH 150, OS 600 хоста, AS 424, KMS 115, в которой могут быть воплощены некоторые методики, описанные в настоящем описании. Среда 1002 вычислительной системы является лишь одним примером подходящей вычислительной среды и не накладывает какие-либо ограничения относительно объема использования или функциональности раскрытого здесь предмета изобретения. Вычислительная среда 1002 также не должна интерпретироваться как имеющая какую-либо зависимость или требование, относящееся к любому одному или комбинации компонентов, изображенных в иллюстративной операционной среде 1002. В некоторых вариантах осуществления различные изображенные вычислительные элементы могут включать в себя схемы, выполненные с возможностью реализации конкретных аспектов настоящего раскрытия. Например, термин «схема», используемый в раскрытии, может включать в себя специализированные аппаратные компоненты, выполненные с возможностью выполнения функции(ий) микропрограммным обеспечением или переключателями. В других иллюстративных вариантах осуществления термин «схема» может включать в себя универсальный процессорный блок, память и т.д., конфигурируемые с помощью программных инструкций, которые воплощают логику, используемую для выполнения функции(ий). В иллюстративных вариантах осуществления, в которых схема включает в себя комбинацию аппаратного и программного обеспечения, лицо, осуществляющее реализацию, может записать исходный код, воплощающий логику, и исходный код может быть скомпилирован в машиночитаемый код, который может быть обработан универсальным процессорным блоком. Поскольку специалисту в данной области техники понятно, что существующий уровень техники развился до такой степени, что имеется небольшая разница между аппаратным обеспечением, программным обеспечением или комбинацией аппаратного обеспечения/программного обеспечения, выбор аппаратного обеспечения по сравнению с программным обеспечением для реализации конкретных функций является проектным решением, оставленным лицу, осуществляющему реализацию. Более конкретно, специалисту в данной области техники будет понятно, что программный процесс может быть преобразован в эквивалентную аппаратную структуру, и аппаратная структура в свою очередь может быть преобразована в эквивалентный программный процесс. Таким образом, выбор аппаратной реализации по сравнению с программной реализацией является одним из проектных решений и оставлен лицу, осуществляющему реализацию.

[00115] Компьютер 1002, который может включить в себя любое мобильное устройство или смартфон, планшет, ноутбук, настольный компьютер или набор сетевых устройств, облачных вычислительных ресурсов и т.д., как правило, включает в себя множество машиночитаемых носителей. Машиночитаемые носители могут быть любым доступным носителем, к которому может получить доступ компьютер 1002, они включают в себя как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители. Системная память 1022 включает в себя машиночитаемые носители данных в форме энергозависимой и/или энергонезависимой памяти, такие как постоянная память (ROM) 1023 и оперативная память (RAM) 1060. Базовая система 1024 ввода-вывода (BIOS), содержащая базовые алгоритмы, которые помогают передавать информацию между элементами в компьютере 1002, например, во время запуска, как правило, хранится в ROM 1023. RAM 1060, как правило, содержит данные и/или программные модули, которые непосредственно доступны и/или в настоящее время обрабатываются процессорным блоком 1059. В качестве примера, а не ограничения, фиг. 10 изображает операционную систему 1025, прикладные программы 1026, другие программные модули 1027, в том числе адресующее TrEE приложение 1065 и данные 1028 программ.

[00116] Компьютер 1002 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации. Только лишь в качестве примера, фиг. 10 изображает привод 1038 жесткого диска, который производит считывание или запись на несъемные, энергонезависимые магнитные носители, привод 1039 магнитного диска, который производит считывание или запись на съемный, энергонезависимый магнитный диск 1054, и привод 1004 оптического диска, который производить считывание или запись на съемный, энергонезависимый оптический диск 1053, такой как CD-ROM или другие оптические носители. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации, которые могут использоваться в иллюстративной операционной среде, включают в себя, но не ограничиваются только этим, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, ленту цифрового видео, твердотельную RAM, твердотельную ROM и т.п. Привод 1038 жесткого диска, как правило, соединен с системной шиной 1021 через интерфейс несъемной памяти, такой как интерфейс 1034, а привод 1039 магнитного диска и привод 1004 оптического диска, как правило, соединены с системной шиной 1021 через интерфейс съемной памяти, такой как интерфейс 1035 или 1036.

[00117] Приводы и их соответствующие компьютерные носители информации, обсуждавшиеся выше и изображенные на фиг. 10, обеспечивают хранение машиночитаемых инструкций, структур данных, программных модулей и других данных для компьютера 1002. На фиг. 10, например, привод 1038 жесткого диска изображен хранящим операционную систему 1058, прикладные программы 1057, другие программные модули 1056 и данные 1055 программ. Следует отметить, что эти компоненты могут быть такими же или отличающимися от операционной системы 1025, прикладных программ 1026, других программных модулей 1027 и данных 1028 программ. Операционной системе 1058, прикладным программам 1057, другим программным модулям 1056 и данным 1055 программ даны здесь другие номера, чтобы проиллюстрировать, что как минимум они являются другими копиями. Пользователь может ввести команды и информацию в компьютер 1002 через устройства ввода, такие как клавиатура 1051 и указательное устройство 1052, обычно называемое мышью, шаровым манипулятором или сенсорной панелью. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровой планшет, спутниковую тарелку, сканер, сканер сетчатки глаз и т.п. Эти и другие устройства ввода часто соединяются с процессорным блоком 1059 через пользовательский интерфейс ввода 1036, который связан с системной шиной 1021, но могут соединяться через другие интерфейсы и шинные структуры, такие как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 1042 или другой тип устройства отображения также соединяется с системной шиной 1021 через интерфейс, например, видеоинтерфейс 1032. В дополнение к монитору компьютеры также могут включать в себя другие периферийные устройства вывода, такие как громкоговорители 1044 и принтер 1043, которые могут быть подключены через выходной периферийный интерфейс 1033.

[00118] Компьютер 1002 может работать в сетевом окружении с использованием логических соединений с одним или несколькими удаленными компьютерами, такими как удаленный компьютер 1046. Удаленный компьютер 1046 может быть персональным компьютером, сервером, маршрутизатором, сетевым PC, одноранговым устройством или другим общим сетевым узлом и, как правило, включает в себя множество или все элементы, описанные выше в отношении компьютера 1002, несмотря на то, что на фиг. 10 изображено только запоминающее устройство 1047. Логические соединения, изображенные на фиг. 10, включают в себя локальную сеть (LAN) 1045 и глобальную сеть (WAN) 1049, но также могут включать в себя другие сети. Такие сетевые среды распространены в офисах, общекорпоративных компьютерных сетях, внутренних сетях, Интернете и облачных вычислительных ресурсах.

[00119] При использовании в сетевой среде LAN, компьютер 1002 соединяется с LAN 1045 через сетевой интерфейс или адаптер 1037. При использовании в сетевой среде WAN, компьютер 1002, как правило, включает в себя модем 1005 или другое средство для установления связи по WAN 1049, например, Интернет. Модем 1005, который может быть внутренним или внешним, может быть соединен с системной шиной 1021 через пользовательский интерфейс 1036 ввода или другой подходящий механизм. В сетевом окружении программные модули, изображенные в отношении компьютера 1002, или их части могут храниться в удаленном запоминающем устройстве. В качестве примера, а не ограничения, фиг. 10 изображает удаленные прикладные программы 1048 находящимися на запоминающем устройстве 1047. Следует понимать, что показанные сетевые соединения являются примером, и могут использоваться другие средства установления канала связи между компьютерами.

[00120] В некоторых аспектах другие программы 1027 могут включать в себя адресующий TrEE компонент или приложение 1065, включающее в себя функциональность, как было описано выше. В некоторых случаях адресующее TrEE приложение 1065 может исполнять некоторые или все операции процессов 300, 400, 500, 800 и/или 900.

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

[00122] Также следует понимать, что различные элементы изображены сохраненными в памяти или в хранилище во время использования, и что эти элементы или их части могут передаваться между памятью и другими устройствами хранения в целях управления памятью и целостности данных. Альтернативно, в других вариантах осуществления некоторые или все программные модули и/или системы могут выполняться в памяти на другом устройстве и осуществлять связь с изображенными вычислительными системами посредством межкомпьютерной связи. Кроме того, в некоторых вариантах осуществления некоторые или все системы и/или модули могут быть реализованы или обеспечены иным образом, например, по меньшей мере частично в микропрограммном обеспечении и/или аппаратном обеспечении, включая, но не ограничиваясь только этим, одну или несколько специализированных интегральных схем (ASIC), стандартных интегральных схем, контроллеров (например, путем выполнения соответствующих инструкций и включая микроконтроллеры и/или встроенные контроллеры), программируемых пользователем вентильных матриц (FPGA), сложных программируемых логических интегральных схем (CPLD) и т.д. Некоторые или все модули, системы и структуры данных также могут храниться (например, как программные инструкции или структурированные данные) на машиночитаемом носителе, таком как жесткий диск, память, сеть или портативный носитель, который должен быть считан посредством подходящего привода или подходящего соединения. В этом патентном описании и формуле изобретения фраза «машиночитаемый носитель данных» и ее вариации не включают в себя волны, сигналы и/или другую коммуникационную среду кратковременного хранения и/или нематериальную коммуникационную среду. Системы, модули и структуры данных также могут передаваться как сгенерированные сигналы данных (например, как часть несущей волны или другого аналогового или цифрового распространяющегося сигнала) во множестве машиночитаемых сред передачи, в том числе беспроводных и проводных/кабельных сред, и могут принимать множество форм (например, в виде части отдельного или мультиплексированного аналогового сигнала, или как несколько дискретных цифровых пакетов или кадров). Такие компьютерные программные продукты также могут принимать другие формы в других вариантах осуществления. Соответственно, настоящее раскрытие может быть реализовано на практике с другими конфигурациями компьютерной системы.

[00123] Условный язык, используемый в настоящем описании, такой как, среди прочего, «может», «мог», «мог бы», «например» и т.п., если специально не указано иное или иным образом не понятно из используемого контекста, в общем предназначен для указания того, что некоторые варианты осуществления включают в себя, в то время как другие варианты осуществления не включают в себя некоторые признаки, элементы и/или этапы. Таким образом, такой условный язык, в общем, не подразумевает, что признаки, элементы и/или этапы всегда требуются для одного или нескольких вариантов осуществления, или что один или несколько вариантов осуществления обязательно включают в себя логику для определения, с помощью или без входных данных или запроса у автора, должны ли включаться или выполняться эти признаки, элементы и/или этапы в каком-либо конкретном варианте осуществления. Термины «содержащий», «включающий», «имеющий» и т.п. являются синонимами и используются включительно, открытым образом и не исключают дополнительные элементы, признаки, действия, операции и т.д. Кроме того, термин «или» используется в его включающем смысле (а не в его исключающем смысле), так что при использовании, например, для соединения элементов списка термин «или» означает один, некоторые или все элементы в списке.

[00124] Хотя были описаны некоторые иллюстративные варианты осуществления, эти варианты осуществления были представлены только в качестве примера и не предназначены для ограничения объема изобретения, раскрытого в настоящем описании. Таким образом, ничто в приведенном выше описании не подразумевает, что какой-то конкретный признак, характеристика, этап, модуль или блок является необходимым или обязательным. Действительно, новые способы и системы, описанные в настоящем описании, могут быть воплощены во множестве других форм; кроме того, могут быть сделаны различные исключения, замены и изменения в форме способов и систем, описанных в настоящем описании, не отступая от сущности изобретения, раскрытого в настоящем описании. Прилагаемая формула изобретения и ее эквиваленты предназначены для охвата таких форм или модификаций, которые попадают в пределы объема и сущности изобретения, раскрытого в настоящем описании.

1. Вычислительная система, сконфигурированная для доставки защищенных данных во вложенную доверенную среду исполнения (TrEE), при этом вычислительная система содержит:

процессор и

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

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

извлекать защищенные данные из упомянутой системы, в которой хранятся секреты, в ответ на данный запрос;

зашифровывать защищенные данные с помощью общедоступного ключа шифрования доверенного приложения и

посылать зашифрованные защищенные данные запрашивающей стороне.

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

3. Вычислительная система по п.2, при этом ключ подписи сертифицирует общедоступный ключ шифрования доверенного приложения пары конфиденциальный ключ - общедоступный ключ, сгенерированной доверенным приложением.

4. Вычислительная система по п.1, при этом ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

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

6. Вычислительная система по п.1, в которой инструкции при их исполнении процессором предписывают вычислительной системе выполнять операции, чтобы:

сравнивать ID доверенного приложения со списком ID авторизованных доверенных приложений и

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

7. Способ доставки защищенных данных во вложенную доверенную среду исполнения (TrEE), содержащую доверенное приложение, исполняющееся поверх внешней TrEE, причем как доверенное приложение, так и внешняя TrEE ассоциированы с недоверенной запрашивающей стороной, при этом способ содержит этапы, на которых:

принимают посредством адресующего блока управления протокола, который служит в качестве посредника между запрашивающей стороной и системой, в которой хранятся секреты, запрос на защищенные данные от запрашивающей стороны, ассоциированной с вложенной TrEE, заключение об аттестации внешней TrEE и заключение о сертификации ключа, при этом заключение о сертификации ключа связывает общедоступный ключ шифрования доверенного приложения и ID доверенного приложения;

извлекают посредством адресующего блока управления протокола защищенные данные из упомянутой системы, в которой хранятся секреты, в ответ на прием данного запроса;

зашифровывают защищенные данные с помощью общедоступного ключа шифрования доверенного приложения и

посылают зашифрованные защищенные данные запрашивающей стороне.

8. Способ по п.7, в котором заключение о сертификации ключа генерируется с помощью ключа подписи внешней TrEE.

9. Способ по п.8, в котором ключ подписи сертифицирует общедоступный ключ шифрования доверенного приложения пары конфиденциальный ключ - общедоступный ключ, сгенерированной доверенным приложением.

10. Способ по п.7, в котором ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

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

12. Способ по п.7, дополнительно содержащий этапы, на которых:

сравнивают посредством адресующего блока управления протокола ID доверенного приложения со списком ID авторизованных доверенных приложений и

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

13. Способ по п.7, дополнительно содержащий этапы, на которых:

посылают посредством запрашивающей стороны зашифрованные защищенные данные доверенному приложению и

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

14. Способ по п.7, в котором защищенные данные содержат ключ упаковки.

15. Машиночитаемый носитель данных, содержащий инструкции для обеспечения выполнения процессорной системой операций, чтобы доставлять защищенные данные во вложенную доверенную среду исполнения (TrEE), содержащую доверенное приложение, исполняющееся поверх безопасного ядра, каковые операции содержат:

прием, посредством адресующего блока управления протокола, служащего в качестве посредника между запрашивающей стороной и системой, в которой хранятся секреты, запроса на защищенные данные от запрашивающей стороны, ассоциированной с вложенной TrEE, заключение об аттестации безопасного ядра и заключение о сертификации ключа, при этом заключение о сертификации ключа связывает общедоступный ключ шифрования доверенного приложения и ID доверенного приложения;

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

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

отправку зашифрованных защищенных данных запрашивающей стороне.

16. Машиночитаемый носитель данных по п.15, при этом заключение о сертификации ключа генерируется с помощью ключа подписи безопасным ядром.

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

18. Машиночитаемый носитель данных по п.15, при этом ID доверенного приложения содержит тип доверенного приложения или тип доверенного приложения и ID сеанса.

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

20. Машиночитаемый носитель данных по п.15, при этом операции дополнительно содержат:

сравнение ID доверенного приложения со списком ID авторизованных доверенных приложений и

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