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

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

 

Область техники

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

[0003] Доверенная среда исполнения (TrEE), как используется здесь, может включать в себя любое одно из: доверенного приложения (trustlet, трастлета) виртуального безопасного режима (VSM), приложения SGX, приложения ARM TrustZone или какого-либо другого аналогичного носителя. Имеются некоторые уникальные свойства, которые TrEE обычно имеют в общем. TrEE, как правило, имеет полный крипто-стек (другими словами, можно предположить широкое многообразие криптографических примитивов по всему спектру, от безопасной генерации случайных чисел до полного меню библиотек хеширования, шифрования и подписи с использованием секретных ключей). TrEE будет также, как правило, иметь или быть ассоциированной с немногим или ограниченным оборудованием I/O, как правило, ограниченным приводимой в действие запросом архитектурой, где запросы инициируются небезопасным (недоверительным) ʺвнешним миромʺ. Например, VSM трастлет может использовать неаутентифицированные вызовы удаленных процедур (RPC). TrEE могут также иметь доступ к ключевому материалу или данным, которые недоступны вне TrEE. Это позволяет TrEE, среди прочего, хранить данные с использованием небезопасного I/O, а затем считывать их обратно, обеспечивая защиту от несанкционированного вмешательства и конфиденциальность состояния. TrEE будет также, как правило, иметь или быть ассоциированной с подтверждаемым кодом, конфигурацией и ключевым материалом. В частности, подтверждаемый ключевой материал позволяет TrEE принимать сообщения, зашифрованные к ней от 3-их сторон, и подписывать сообщения к 3-им сторонам, как поступающие из TrEE.

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

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробное описание иллюстративных вариантов осуществления

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

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

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

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

[0022] Фиг. 1B иллюстрирует примерную систему и процесс 100b для более безопасного обмена одним или несколькими секретами или защищенными данными между запросчиком 120 и KMS 115, от имени доверенной среды исполнения (TrEE) 140, анклава или объекта в другой терминологии, используемой для обозначения изолированной среды исполнения, ассоциированной с запросчиком 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 может быть в общей или доступной области СРМ 205; однако, следует иметь в виду, что в некоторых случаях, логика 210 может быть также расположена в той же или другой изолированной области в качестве информации 220 состояния.

[0023] Возвращаясь к системе 100b, адресующий блок управления протокола (ТРН) 150 может быть реализована на серверной стороне 105, чтобы служить в качестве посредника между запросчиком 120/140 TrEE и KMS 115. Блок управления протокола может относиться к программной реализации обработчика протокола, обычно противостоя системе, которая изначально не исполняет конкретный протокол. Таргетинг может относиться к криптографическому таргетингу среды исполнения. Рассматривая в комбинации, данный термин может указывать на программное обеспечение и/или аппаратные средства, которые реализует протокол для извлечения секретов, который имеет целью ответы в TrEE. В некоторых аспектах, адресующий блок 150 управления протокола может быть реализована как виртуальный или облачный ресурс, например, который может исполняться на разных аппаратных средствах, программном обеспечении и/или отдельно от KMS 115. В некоторых аспектах, субъект, такой как центр обработки данных, может хостировать и/или обеспечивать адресующий блок 150 управления протокола в качестве услуги, например. Адресующий блок 150 управления протокола может выполнять две основные функции: 1) осуществлять связь с KMS 115/получать секрет или защищенные данные от внешнего субъекта, и 2) нацеливать ответы на TrEE 140 запросчика 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 управления протокола может определить, является ли 140 TrEE заслуживающей доверия. В одном аспекте, аутентификация запросчика 120 может полагаться на тип обеспечения чистой комнаты. В другом аспекте, аутентификация может полагаться на аттестацию.

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

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

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

[0029] Фиг. 1С иллюстрирует другую примерную систему и процесс 100с, для безопасного обмена одним или несколькими секретами или защищенными данными между запросчиком 120 и KMS 115, от имени доверенной среды исполнения (TrEE) 140. Система 100c может быть конкретным примером системы 100b, описанной выше. В системе 100c, адресующий блок 150 управления протокола может быть службой хоста-хранителя (HGS) 150a. В системе 100c, HGS 150a может получить протектор ключа (KP) 190, например, из облачного хоста 185 или другого субъекта, который может создать экземпляр или иным образом контролировать TrEE 140. В системе 100c, запросчик 120 может быть ассоциирован с виртуальной машиной, например, обеспеченной облачным хостом 185. KP 190 может включать в себя один или несколько аспектов протектора ключа, описанного в связанной патентной заявке США № 14/481,399, озаглавленной ʺSecure Transport of Encrypted Virtual Machines with Continuous Owner Accessʺ, поданной 9 сентября, 2014. KP 190 может содержать один или несколько секретов, используемых в TrEE 140, таких как транспортный ключ. KP 190 может, по существу, упаковывать (помещать в оболочку) транспортный ключ, чтобы он был доступен только набору хранителей, которые авторизованы для доступа к транспортному ключу. KP 190 может быть зашифрован таким образом, что для того, чтобы считать содержимое KP 190 и извлечь транспортный ключ, HGS 150a может запросить ключ дешифрования из KMS 115, в операции 170а, после аутентификации и установления безопасного канала связи с KMS-115 в операции 165. KMS 115, в ответ, может послать ключ дешифрования на HGS в операции 175а. HGS 150a может затем использовать ключ дешифрования для дешифрования KP 190 и извлечь один или несколько секретов (например, транспортный ключ), чтобы отправить на TrEE 140. HGS 150a может затем отправить секреты или транспортный ключ на TrEE в операции 180, посредством одного или нескольких методов адресации, которые будут описаны более подробно ниже. В некоторых аспектах, TrEE 140 может адресоваться на основе данных из KP 190.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0044] Запросчик 120 может получить отчет аттестации, например, в соответствии с процессом 406, описанным выше со ссылкой на фиг. 4В, от службы аттестации, доверенной для ТРН 150, в операции 506. Затем запросчик 120 может представить на ТРН 150 отчет аттестации, в операции 508. Следует иметь в виду, что в примере обеспечения чистой комнаты, описанном выше, который может быть применимым здесь, аттестация не требуется.

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

[0046] ТРН 150 может определить, какой тип трастлета целенаправленно выбирать, к примеру, на основе запроса или на основе самой ТРН 150 (например, каждая ТРН 150 может быть предназначена специально для определенной цели или приложения, такого как NetFlix), в операции 512. В примере, использующем KP, например, как описано со ссылкой на фиг. 1С выше, тип трастлета может быть закодирован в KP. В некоторых других примерах, тип трастлета может быть установлен по умолчанию или жестко закодирован, например, в реализациях с использованием HGS 150а. В примере HGS, HGS 150а всегда может быть ориентирован на трастлет безопасного процесса виртуального режима (VMSP), тип которого может быть жестко закодирован (так как KP может не содержать эту информацию).

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

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

[0049] ТРН 150 может затем отправить зашифрованный TX и аутентифицированное шифрование TW запросчику 120 в операции 546. Возвращаясь к фиг. 5А, после приема сообщения 516, которое может быть сгенерировано посредством операций согласно фиг. 5В и/или может включать в себя защищенные данные, зашифрованные аналогичным образом как 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 могут быть реализованы в ресурсах или виртуальной машине, реализующей виртуальный безопасный режим (VSM). VSM и родственные концепции, в контексте виртуальных машин, описаны в патентной заявке США № 14/186,415, озаглавленной ʺVirtual Secure Mode for Virtual Machinesʺ, поданной 21 февраля 2014. Фиг. 6 иллюстрирует операционную систему 600 системы или хоста, включающую в себя вычислительную среду VSM, разделенную на различные виртуальные доверенные уровни, VTL0 610 и VTL1 615. Система 600 может быть более конкретной реализацией одного или нескольких аспектов систем 100а, 100b или 100с, такой как как облачный хост 180, включающей в себя вычислительную среду, работающую в VSM. VTL0 610 может включать в себя пользовательский режим 620 и режим 630 нормального ядра, и VTL1 615 может включать в себя пользовательский режим 625 и режим 635 безопасного ядра. Различные VTL могут быть обеспечены гипервизором, например, работающим поверх физических вычислительных компонентов или виртуальных вычислительных ресурсов (например, одной или более виртуальных машин), который взаимодействует и определяет VTL0 610 и VTL1 через ограничения на доступ к памяти для некоторых процессов и тому подобного. В показанном примере, 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 для инициализации трастлета и использовании конкретной реализации 150а HGS вместо более общей ТРН 150.

[0055] Как показано на чертеже, одна или более TrEE или трастлетов 640 могут постоянно находиться в пользовательском режиме 625 VTL1 615. В некоторых аспектах, один или более трастлетов 640 могут быть доступными или ассоциированными с безопасным процессом виртуальной машины (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 со ссылкой на фиг. 1С. Пример структуры данных, включающей в себя KP, например, KP 700 показан на фиг. 7.

[0056] Структура 700 данных может включать в себя протектор ключа (KP) 705, который является криптографической упаковкой ключа шифрования (здесь транспортного ключ TK), как описано в патентной заявке США № 14/481,399, озаглавленной ʺSecure Transport of Encrypted Virtual Machines with Continuous Owner Accessʺ, поданной 9 сентября, 2014. KP 705 обеспечивает то, что доступ к TK 710 и/или другим защищенным данным предоставляется только для авторизованных субъектов. TK 710, который является ключом, подлежащим доставке к TrEE 140, может быть упакован посредством KP 705 или в некоторых случаях посредством ключа упаковки или TW. TK 710 может рассматриваться как секрет высокого значения. В некоторых случаях, TK 710 могут быть дешифрован в KMS 115.

[0057] Структура 700 данных может также включать в себя данные виртуальной машины (VMD) 730, которые могут включать в себя данные для инициализации трастлета. VMD 730 могут быть зашифрованы с использованием соответствующей технологии шифрования, например BitLocker от Microsoft Corporation, Редмонт, шт. Вашингтон. Ключ шифрования полного тома (FVEK) 725, который может быть использован для дешифрования VMD 730, может быть защищен с помощью модуля виртуальной доверенной платформы (V_TPM), состояние которого (725) шифруется и хранится как часть метаданных, наряду с KP 705. В некоторых аспектах, FVEK 725 может быть зашифрован с помощью главного ключа тома (VMK) 720. Cостояние 725 V_TPM само зашифровывается с использованием ключа, упакованного посредством KP 705. В некоторых аспектах, состояние 725 V_TPM может быть зашифровано посредством TK 710 (секрета высокого значения) и ʺзапечатыватьʺ данные в значения PCR (например, PCR7) таким образом, что если значение PCR находится в ожидаемом состоянии, ТРМ будет разрешать доступ, например, чтобы дешифровать ключевой материал. В этом случае протектор TPM представляет собой структуру данных, которая подается в ТРМ, чтобы вскрыть некоторый секрет, если одно или несколько PCR находятся в ожидаемых состояниях. В других случаях, могут быть также использованы не-ТРМ протекторы.

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

[0059] Каждое поле или блок KP 700 может также быть описан в терминах того, что он шифрует, в виде условной записи Encrypt(key, data) (Шифровать (ключ, данные)):

VMD_DISK Encrypt(FVEK, данные диска открытого текста)

FVEK_DISK Encrypt(VMK, FVEK)

VMK_DISK Encrypt(VMK)

V_TPM.DISK Encrypt(TK, V_TPM)

TK_DISK Encrypt(KP, TK)

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

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

[0061] Для того, чтобы запустить трастлет, клиент 650 может запрашивать и/или принимать структуру 700 данных. Клиент 650 может послать KP 705 или всю структуру 700 данных на ТРН 150 (или в некоторых реализациях HGS 150а), которая может взаимодействовать с KMS 115 для дешифрования TK 710. ТРН затем может целенаправленно выбирать 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 (THC), например, сформированный на основе ключа идентификационной информации шифрования (IDK_E) безопасного ядра, ассоциированного с TrEEм или трастлетом, в операции 602, например, в соответствии со способом, описанным со ссылкой на фиг. 4В выше. В одном аспекте, операция 602 может включать в себя создание хостом журнала аттестации (TCG log) при загрузке, который содержит открытую версию IDK_E, закрытая (секретная) часть которого находится в безопасном ядре (SK) VSM, ассоциированном с трастлетом. Журнал аттестации может быть представлен в службу аттестации (AS). AS может проверить журнал аттестации и выдать на хост THC, созданный на основе IDK_E (например, открытой части асимметричного ключа). В некоторых аспектах, подобно IDK_Е, ʺИдентификационный ключ подписиʺ (IDK_S) также может быть создан и может иметь отдельный THC, созданный на его основе, как будет описано более подробно ниже со ссылкой на фиг. 9. Решение проблемы доставки ключа может быть создано с использованием либо IDK_E, либо IDK_S, как описано ниже.

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

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

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

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

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

Key_certification = σ IDK_S(Трастлет_Encryption_Key_Pub, Trustlet_Type, Session_ID)

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

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

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

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

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

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

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

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

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

[0076] шифрование ключа шифрования передачи с помощью второго ключа шифрования, полученного из отчета аттестации;

[0077] извлечение защищенных данных;

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

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

[0080] 2. Вычислительная система по п. 1, причем ID трастлета содержит тип трастлет и ID сеанса. 2. Вычислительная система по п.1, причем

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

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

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

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

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

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

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

[0088] шифрование ключа шифрования передачи с помощью второго ключа шифрования, полученного из отчета аттестации;

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

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

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

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

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

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

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

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

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

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

[0099] В варианте осуществления, безопасное ядро подтверждает, что аутентифицированные зашифрованные защищенные данные предназначены для трастлета на основе типа трастлета и ID сеанса, и посылает дешифрованные защищенные данные в трастлет на основе типа трастлета и ID сеанса.

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

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

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

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

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

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

[00106] шифровать ключ шифрования передачи с помощью второго ключа шифрования, полученного из отчета аттестации;

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

[00108] шифровать защищенные данные с помощью ключа шифрования передачи и тега аутентификации, причем тег аутентификации связывает запросчика с ID трастлета; и

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

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

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

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

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

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

[00115] сравнивать ID трастлета со списком ID авторизованных трастлетов; и

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

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

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

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

[00120] Накопители и ассоциированные с ними компьютерные носители хранения, описанные выше и показанные на фиг. 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 периферийных устройств вывода.

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

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

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

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

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

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

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

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

процессор и

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

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

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

извлечение защищенных данных;

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

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

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

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

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

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

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

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

6. Вычислительная система по п.1, при этом защищенные данные содержат ключ упаковки.

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

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

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

извлечение, посредством по меньшей мере одного процессора процессорной системы, защищенных данных;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20. Машиночитаемый носитель информации по п.15, в котором упомянутые инструкции дополнительно содержат инструкции, которые при их исполнении в компьютерной системе, предписывают компьютерной системе, по меньшей мере:

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

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