Кросс-платформенная идентификационная информация анклава

Изобретение относится к области безопасности вычислительных систем. Техническим результатом является защита содержимого анклава от небезопасного программного обеспечения. Технический результат заявляемого технического решения достигается тем, что в нем предусмотрен прием отчетов аттестации из анклавов, реализованных на нативных платформах анклавов, извлечение значений идентификаторов анклавов, ассоциированных с типом идентификаторов анклавов; определение того, что значения идентификаторов анклава из разных отчетов являются одинаковыми; а также на основе данного определения, осуществляют операции путем частичного выполнения операции в первом анклаве и частичного выполнения операции во втором анклаве. 3 н. и 20 з.п. ф-лы, 23 ил.

 

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

[0001] Настоящее изобретение относится к безопасным вычислительным системам.

Предшествующий уровень техники

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

[0003] Системы анклава, такие как Виртуальный безопасный режим (VSM) от Microsoft и Расширения защиты программного обеспечения (SGX) от Intel обеспечивают безопасность частично путем изолирования анклава от другого кода, работающего либо в пользовательском режиме, либо в режиме ядра. Гарантии целостности и конфиденциальности могут обеспечивать анклав более высоким уровнем доверия в отношении аутентичности кода, работающего в анклаве, и доверия в отношении безопасного исполнения кода анклава. Гарантия целостности может быть обеспечена аттестацией программного обеспечения конкретного анклава. Аттестация программного обеспечения может включать в себя криптографически подписанный хеш содержимого (инструкций и данных) внутри анклава и может комбинироваться с данными о среде анклава. Когда анклав используется в комбинации с модулем безопасности аппаратных средств (HSM), таким как аппаратные средства, согласующиеся со стандартом Доверенного платформенного модуля (TPM) Доверенной вычислительной группы (TCG), анклав может обеспечить дополнительный уровень гарантий безопасности и конфиденциальности.

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

Краткое описание сущности изобретения

[0005] Представлены способы и системы для абстрагирования платформы анклава. Способ может содержать прием, платформой абстракции анклава, первого запроса использовать анклав от клиента анклава. Первый запрос может соответствовать протоколу абстракции клиента. Первый запрос может быть преобразован во второй запрос, который соответствует нативному протоколу анклава, ассоциированному с нативной платформой анклава. Второй запрос может затем быть отправлен на нативную платформу анклава. Первый запрос может представлять собой, например, запрос создать экземпляр (реализовать) анклава, запрос верифицировать отчет аттестации анклава, запрос вызвать в анклав или запрос распределить память, которая совместно используется как анклавом, так и клиентом анклава. Нативная платформа может соответствовать архитектуре анклава Расширений защиты программного обеспечения (SGX) от Intel, и нативная платформа может соответствовать архитектуре анклава Виртуального безопасного режима (VSM) от Microsoft.

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

[0006] Фиг. 1 изображает пример блок-схемы высокого уровня системы анклава.

[0007] Фиг. 2 изображает примерный процесс для пересылки сообщений с гарантией конфиденциальности.

[0008] Фиг. 3 изображает примерный процесс для пересылки сообщений с гарантией целостности.

[0009] Фиг. 4 изображает примерный процесс для пересылки сообщений с гарантией свежести.

[0010] Фиг. 5 изображает примерный процесс для аттестации программного обеспечения анклава.

[0011] Фиг. 6 изображает примерный протокол обмена ключами Диффи-Хеллмана (DKE).

[0012] Фиг. 7 изображает примерную цепочку доверия для аттестации программного обеспечения.

[0013] Фиг. 8 представляет собой блок-схему интерфейсов компонентов программного обеспечения для примерной локальной системы анклава.

[0014] Фиг. 9 представляет собой блок-схему интерфейсов компонентов программного обеспечения для примерной локальной системы анклава с уровнем абстракции.

[0015] Фиг. 10 представляет собой блок-схему интерфейсов компонентов программного обеспечения, например, удаленной системы анклава с уровнем абстракции.

[0016] Фиг. 11 изображает примерную универсальную вычислительную среду.

[0017] Фиг. 12 изображает примерную блок-схему последовательности операций для способа абстрагирования нативной платформы анклава.

[0018] Фиг. 13 изображает примерную блок-схему последовательности операций для способа абстрагирования нативной платформы анклава.

[0019] Фиг. 14 изображает примерную блок-схему последовательности операций для способа выполнения операции анклава с абстрактной идентичностью (идентификатором) анклава.

[0020] Фиг. 15 изображает примерную блок-схему последовательности операций для способа 1500 выполнения операции анклава с абстрактной идентичностью анклава.

[0021] Фиг. 16 изображает примерную систему с эквивалентностью абстрактной идентичности анклава.

[0022] Фиг. 17 изображает примерную блок-схему последовательности операций для параллельной обработки с двумя эквивалентными анклавами.

[0023] Фиг. 18 изображает примерную блок-схему последовательности операций для последовательной обработки с двумя эквивалентными анклавами.

[0024] Фиг. 19 представляет собой блок-схему примерной системы распределенного запечатывания данных.

[0025] Фиг. 20 представляет собой примерную блок-схему последовательности операций для распределенного запечатывания и распечатывания данных.

[0026] Фиг. 21 представляет собой блок-схему примерного анклава хранилища ключей.

[0027] Фиг. 22 представляет собой примерную блок-схему последовательности операций для нескольких операций анклава хранилища ключей.

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

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

[0029] Раскрыта модель абстракции для анклавов, которая упрощает разработку клиентов анклава и программного обеспечения, которое работает внутри анклава. Модель абстракции может представлять собой упрощение и унификацию архитектур нативных платформ анклава, таких как SGX от Intel и VSM от Microsoft. Компонент программного обеспечения уровня абстракции может переводить коммуникацию между клиентом анклава и одной или несколькими нативными платформами, между программным обеспечением внутри анклава и одной или несколькими нативными платформами анклава и между программным обеспечением внутри анклава и клиентом анклава. Такая платформа абстракции может обеспечивать выгоду, заключающуюся в обеспечении возможности одной версии программного обеспечения анклава и программного обеспечения клиента анклава работать поверх нескольких нативных платформ анклава, таких как SGX и VSM. В дополнение к упрощению задачи написания программного обеспечения для анклавов и клиентов анклава, это позволяет конечным пользователям анклавов запускать программное обеспечение анклава и клиента анклава на компьютере, который поддерживает любую поддерживаемую нативную архитектуру анклава без необходимости находить версии программного обеспечения как анклава, так и клиента анклава, которые приспособлены к нативной платформе анклава конкретного компьютера.

[0030] Модель абстракции анклава может, например, включать в себя простейшие примитивы для: администрирования срока жизни анклава, локальной и удаленной аттестации анклава, запечатывания данных в анклав, управления переносом программы в и из анклава и других характеристик безопасности, таких как монотонные счетчики и доверенное время. Также представлена абстрактная или многоуровневая идентичность анклава, которая абстрагирует идентичность анклава за пределами одного двоичного кода или одного хеша содержимого анклава. Интерфейсы компонентов программного обеспечения, такие как интерфейс программирования приложения (API) или интерфейс приложения двоичного кода (ABI), представлены для разработки анклавов и программ клиента анклава с использованием примитивов модели абстракции.

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

[0032] Любой уровень абстрактной идентичности может использоваться для различных криптографических операций, таких как запечатывание данных, аттестация анклава или гарантирование свежести данных (посредством монотонных счетчиков). Например, путем запечатывания данных, созданных одним экземпляром анклава, в идентичность более высокого уровня, эти данные могут затем позже безопасно потребляться другим экземпляром анклава с той же самой идентичностью анклава более высокого уровня. Путем запечатывания данных, например, в семейство анклавов, любой экземпляр анклава, который является членом этого семейства, и только члены этого семейства, будут способны распечатать (вскрыть) данные. Аттестация идентичности семейства из экземпляра анклава гарантирует, что экземпляр анклава является членом этого семейства. Монотонные счетчики, привязанные к абстракции идентичности, могут обеспечивать гарантии свежести, связанные со всеми экземплярами анклава, которые являются членами идентичности абстракции.

[0033] Раскрытая модель абстракции включает в себя интерфейсы компонентов программного обеспечения, такие как интерфейс программирования приложения (API) или интерфейс двоичного кода приложения (ABI), которые могут упрощать разработку программного обеспечения анклавов и хостов анклавов. API представляет собой набор определений, протоколов и инструментов подпрограммы программирования для создания программного обеспечения. API может определять вводы и выводы компонента программного обеспечения, типы данных, используемые компонентом программного обеспечения, и функциональность или операцию компонента программного обеспечения, независимых от любой конкретной реализации компонента программного обеспечения. API может определяться на компьютерном языке высокого уровня, таком как C, C++, C# и т.п. Формализованное определение API может облегчить взаимодействие между компонентами программного обеспечения, например, двумя компонентами программного обеспечения, написанными в разное время или разными авторами. API может быть формализован частично при помощи языка описания интерфейса (IDL), такого как Язык описания интерфейса Microsoft (MIDL) или IDL Группы управления объектами (OMG). ABI также представляет собой интерфейс между компонентами программного обеспечения, но представляет собой интерфейс объектного кода. Например, ABI может представлять собой точки входа (или адреса инструкций) объектного кода, являющегося результатом компилирования реализации исходного кода API совместно с протоколами для использования этих точек входа, такими как протоколы, специфицирующие регистры машины, которые хранят аргументы, когда вызываются точки входа.

[0034] В дополнение к обеспечению возможности взаимодействия с разными уровнями идентичности анклава, как описано выше, API анклава может абстрагировать отличия между архитектурами платформы анклава, например, между архитектурами для безопасного изолированного исполнения, обеспечиваемого Расширениями защиты программного обеспечения (SGX) от Intel, Виртуальным безопасным режимом (VSM) от Microsoft и ARM TrustZone, Безопасной зашифрованной виртуализацией (SEV) от AMD, и архитектурами на основе программируемых вентильных матриц (FPGA). API включают в себя интерфейсы для платформы анклава, которая абстрагирует некоторые подробности абстрагированных архитектур анклава. Эти интерфейсы платформы анклава включают в себя API хоста анклава, API платформы анклава и API удаленной аттестации. API хоста анклава может использоваться небезопасным процессом хостирования, чтобы администрировать срок жизни анклава и обеспечивать связь на/от анклава. API платформы анклава может быть обеспечен доверенной платформой анклава к анклаву и может включать в себя примитивы безопасности для аттестации, запечатывания и связи с небезопасным кодом, исполняющимся на компьютере, хостирующем компьютер анклава, а также поддержки для времени выполнения ядра, такой как администрирование памяти и планирование треда. API удаленной аттестации может использоваться, чтобы выполнять удаленную аттестацию, где анклав и его клиент хостируются на том же компьютере. Например, API удаленной аттестации может использоваться локальным клиентом, чтобы верифицировать, что данные исходили (или были отправлены) из анклава с определенной идентичностью, работающего при изоляции, обеспечиваемой платформой анклава на удаленном компьютере. Более обобщенно, API удаленной аттестации может использоваться, чтобы устанавливать каналы безопасной связи между локальным клиентом и удаленным анклавом.

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

[0036] Фиг. 1 изображает блок-схему высокого уровня системы анклава совместно с некоторыми доверенными отношениями. Система 100 анклава включает в себя анклав 176 (альтернативно называемый контейнером анклава или безопасной средой исполнения), который включает в себя безопасную изолированную область памяти, которая содержит код 180 и данные 182. Код 180 может быть открытым или частным, и данные 182 могут быть открытыми или частными. Например, частные данные или код могут принадлежать владельцу 142 данных (или быть конфиденциальными для него), в то время как открытые данные или код могут быть обеспечены другой стороной, такой как провайдер 148 программного обеспечения. В одном варианте осуществления, код, который исполняется в контейнере 176 анклава, может быть полностью открытым, а не частным, в то время как данные, которые открытый код анклава использует в качестве ввода или создает как вывод, могут быть частными. В другом варианте осуществления, возможно обратное, где код является частным, в то время как данные являются открытыми. В еще одном варианте осуществления, как код, так и данные ввода могут быть открытыми, в то время как вывод исполняющегося кода с данными ввода может быть частным. Возможны другие открытые и частные комбинации кода, данных ввода и данных вывода.

[0037] Контейнер анклава 176 хостируется на доверенных аппаратных средствах 172, которые могут одновременно хостировать небезопасное программное обеспечение 174. Первичная цель системы 100 анклава может включать в себя по меньшей мере один аспект, выбранный из списка, состоящего из: поддержания целостности кода 180, поддержания конфиденциальности кода 180, поддержания целостности данных 182 и поддержания конфиденциальности данных 182. Целью может быть защита содержимого анклава 176 от небезопасного программного обеспечения 174 (например, раскрытия небезопасному программному обеспечению, модификации посредством небезопасного программного обеспечения или т.п.). Доверенные аппаратные средства создаются производителем 162 и находятся во владении и администрировании владельца 152 инфраструктуры.

[0038] Клиент 104 анклава может представлять собой процесс или программу вне контейнера анклава, для которых анклав 176 выполняет вычисления при помощи кода 180 и данных 182. В варианте осуществления локального анклава, клиент 104 анклава может также работать на доверенных аппаратных средствах 172. В варианте осуществления удаленного анклава, клиент анклава может работать на одном компьютере, в то время как доверенные аппаратные средства 172 представляют собой другой, удаленный компьютер, соединенный с компьютером клиента анклава посредством сети. В случае локального анклава, процесс клиента анклава может также представлять собой процесс хоста анклава контейнера 176 анклава, при этом процесс клиента анклава может администрировать создание локального анклава 176. В случае удаленного анклава, анклав 176 может, например, работать на облачном компьютере Интернета, где владелец 152 инфраструктуры представляет собой провайдера услуги облачных вычислений, и облачный компьютер включает в себя доверенные аппаратные средства 172, которые произведены производителем 162.

[0039] Клиент 104 анклава может включать в себя способ установки 106, чтобы устанавливать запрошенное вычисление при помощи анклава 176. Способ установки 106 может включать в себя побуждение создания безопасного контейнера анклава 176, побуждение реализации анклава (например, путем отправки запроса на небезопасное программное обеспечение 174, чтобы запросить реализацию анклава), что может включать в себя копирование двоичного кода в безопасный контейнер, и побуждение или запрашивание вычисления в анклаве, например, путем вызова способа в коде, скопированном в безопасный контейнер. Запрошенное вычисление может включать в себя исполнение кода 180, и данные 182 могут вводиться в запрошенное вычисление или могут быть его результатом. Данные, введенные в запрошенное вычисление, могут быть зашифрованы при нахождении вне анклава, и зашифрованные данные ввода могут быть дешифрованы перед использованием внутри анклава. Когда анклав 176 завершил запрошенную задачу, данные, представляющие результат задачи, зашифровываются и отправляются обратно на клиент 104 анклава. Когда клиент 104 анклава принимает зашифрованные результаты, способ верификации 108 может подтвердить целостность и свежесть принятых результатов. Один провайдер 148 программного обеспечения может обеспечить код 180 для работы внутри анклава 176 и по меньшей мере часть способа верификации 108, который выполняется как часть клиента 104 анклава.

[0040] Доверие владельца данных в отношении конфиденциальности приватной части данных 182 и приватной части кода 180, а также доверие в отношении корректности результатов, произведенных анклавом 176, может быть основано на доверенных отношениях. Например, владелец 142 данных может доверять клиенту 104 анклава, который может не работать в пределах самого контейнера анклава. Владелец данных может дополнительно доверять провайдеру 148 программного обеспечения самого анклава. И владелец данных может доверять производителю доверенных аппаратных средств 172. Доверенные аппаратные средства 172 могут принимать множество форм в зависимости от используемой архитектуры анклава и могут включать в себя модуль безопасности аппаратных средств (HSM), где HSM соответствует, например, стандарту модуля доверенной платформы (TPM). Доверенные аппаратные средства 172 могут включать в себя, например, TPM и могут содержать только аппаратные средства. Например, реализация доверенных аппаратных средств 172 с использованием архитектуры анклава VSM от Microsoft может включать в себя серийный процессор с инструкциями для инструкций виртуализации операционной системы и TPM. Архитектура анклава VSM от Microsoft может включать в себя гипервизор для администрирования гостевых разделов (виртуальных процессоров), и гипервизор может предоставлять интерфейсы гипервызова гостевым разделам, чтобы разрешать гостевым разделам взаимодействовать с гипервизором. Контейнер анклава в архитектуре VSM от Microsoft может быть реализован как особый тип гостевого раздела. Пример доверенных аппаратных средств 172 с архитектурой анклава SGX от Intel может включать в себя процессор со специальными специфическими для анклава инструкциями и функциональностью безопасности.

[0041] Анклав, такой как анклав 176, может обеспечивать изолированную среду исполнения, которая может защищать код или данные, такие как код 180 и данные 182, путем обеспечения области памяти с ограничениями на считывание, запись или исполнение из этой защищенной области. Эта защищенная область памяти представляет собой безопасный контейнер для конфиденциального кода и данных. Ограничения на исполнение из защищенной области памяти анклава могут включать в себя ограничения на переносы исполнения, такие как инструкции вызова или перехода, между кодом вне анклава и кодом внутри анклава, и наоборот. Разные ограничения могут приводиться в исполнение между вызовом в анклав извне анклава и вызовом вне анклава изнутри анклава. Задействование этих переносов исполнения между областями внутри и вне анклава может быть обеспечено аппаратными средствами, например при помощи стандартной технологии виртуализации аппаратных средств или при помощи специальных аппаратных средств, таких как платформа SGX от INTEL.

[0042] Фиг. 2 изображает примерный процесс 200 для пересылки сообщений с гарантией конфиденциальности. Гарантия конфиденциальности обеспечивает некоторый уровень гарантии того, что связь между двумя сторонами, такими как Анна 210 и Бен 230 в этом примере, остается скрытой от третьих сторон, когда сообщения пересылаются через общедоступную или незащищенную среду связи, такую как сеть 218. В этом примере, Анна 212 желает отправить конфиденциальное сообщение Бену 230. Блок 212 сообщения, содержащий конфиденциальные данные, зашифровывается с использованием открытого (общедоступного) ключа 216 посредством операции шифрования 214. Операция шифрования 214 может представлять собой, например, режим Галуа/счетчика стандарта расширенного шифрования (AES-CGM), но может также представлять собой любую операцию шифрования, известную специалистам в области цифровой криптографии. Зашифрованный блок 220 может пройти через сеть 218 к Бену, где зашифрованный блок 234 дешифруется при помощи частного (конфиденциального) ключа 236, чтобы сформировать незашифрованный блок 232 сообщения для Бена. При помощи тщательного выбора ключей и алгоритмов шифрования, как известно в области компьютерного шифрования данных, сообщение может оставаться конфиденциальным даже при прохождении через общедоступную сеть.

[0043] Фиг. 3 изображает примерный процесс 300 для пересылки сообщений с гарантией целостности. Гарантия целостности обеспечивает некоторый уровень гарантии того, что коммуникация между двумя участниками, такими как Анна 310 и Бен 350 этом примере, не подвергается вмешательству или иным изменениям, когда сообщения пересылаются через общедоступную или незащищенную среду связи, такую как сеть 340. В примере на фиг. 3, Анна 310 отправляет сообщение 314 Бену 350, так что существует уверенность в том, что в сообщение 314 не подвергается вмешательству или иным искажениям, когда Бен 350 принимает его. Чтобы обеспечить эту гарантию целостности, процесс безопасного хеширования 316 работает на сообщении 314, чтобы сформировать значение 318 хеша. Значение 318 хеша затем подписывается посредством процесса подписания 320 с использованием частного ключа Анны, чтобы сформировать подпись 342. Подпись 342 может быть отправлена по общедоступной сети 340 или посредством другого процесса незащищенной связи совместно с копией сообщения 314 в качестве сообщения 344. Бен затем принимает сообщение 354, для которого Бен желает верифицировать целостность, так что Бен может иметь уверенность в том, что сообщение 354 является тем же самым, что и сообщение 314, которое отправила Анна, после пересылки через небезопасную сеть 340. Чтобы верифицировать целостность, принятое сообщение 354 обрабатывается безопасным хешированием 356, которое идентично безопасному хешированию 316, чтобы сформировать значение 358 хеша. Принятая подпись 342 верифицируется посредством процесса верификации 360 подписи с использованием открытого ключа Анны. Значение 318 хеша, которое извлекается из подписи 342, затем сравнивается со значением 358 хеша, чтобы верифицировать 380, что подписи являются одними и теми же. Если они являются одними и теми же, сообщение принимается 384, как имеющее целостность. С другой стороны, если сообщение 314 было изменено каким-либо образом до приема в качестве сообщения 354, то подпись не будет корректной, и сообщение будет отклонено 388.

[0044] В некоторых вариантах осуществления, безопасное хеширование 316 и безопасное хеширование 356 могут представлять собой криптографическую хеш-функцию. Криптографическая хеш-функция представляет собой одностороннюю функцию, которая отображает данные произвольного размера на битовую строку (обычно намного меньшего) фиксированного размера. Вывод хеш-функции может называться значением хеша или просто хешем. Хорошая хеш-функция будет односторонней в том, что будет сложно определить ввод произвольного размера при наличии только вывода хеша. При хорошей хеш-функции, даже малое изменение во вводе будет создавать изменение в выводе.

[0045] Система связи может комбинировать гарантии конфиденциальности и целостности. Например, шифрование блока сообщения согласно фиг. 2 может комбинироваться с подписанием хеша сообщения согласно фиг. 3. Система комбинации может потребовать двух наборов пар открытого/частного ключей, один для отправителя и один для получателя. Система комбинации может использовать один частный ключ у получателя, чтобы дешифровать сообщение (частный ключ Бена, как на фиг. 2), в то же время используя другой частный ключ, чтобы подписать хеш сообщения (частный ключ Анны, как на фиг. 3).

[0046] Фиг. 4 изображает примерный процесс 400 для пересылки сообщений с гарантией свежести. Гарантия свежести обеспечивает некоторый уровень уверенности в том, что когда несколько сообщений отправлены от одного участника к другому, например, от Анны 410 к Бену 450 в этом примере, сообщение, принятое в получателе, представляет самое последнее сообщение. Гарантия свежести может строиться на гарантии целостности и может предотвращать атаку повторением перехваченных данных. При обеспечении гарантии целостности, для третьей стороны с мошенническим намерением будет трудно создать свое собственное сообщение и отправить его Бену так, чтобы Бен понимал это сообщение как созданное Анной. Однако третья сторона может взять сообщение, действительно созданное Анной, возможно, перехваченное в момент, когда оно отправлялось по общедоступной сети, и третья сторона может повторно отправить его Бену в другое более позднее время (т.е. повторить перехваченное сообщение). Бен определит, что сообщение было действительно создано Анной (поскольку оно было), но Бен не будет знать, что Анна не является тем лицом, которое отправило его в этот раз. Это может определяться как атака путем повтора перехваченных данных на Бена или Анну третьей стороной. Фиг. 4 представляет собой примерное решение для предотвращения атак повтором перехваченных данных путем обеспечения гарантии свежести с использованием случайных (контрольных) слов и временных меток. Случайное слово представляет собой одноразовое случайное число, связанное с системой, для обеспечения того, что то же самое число никогда не используется в качестве случайного слова более одного раза. В некоторых системах случайное слово может представлять собой просто монотонно возрастающее число, так что каждое используемое число выше, чем все числа, которые шли до него.

[0047] На фиг. 4, сообщение 414 Анны может быть отправлено по общедоступной сети 430 как сообщение 436 вместе со случайным словом 434 и временной меткой 432. Случайное слово 434 генерируется криптографически безопасным генератором 426 псевдослучайных чисел (CSPRNG), и временная метка 432 создается синхронизированным тактовым сигналом 424. Существует много систем CSPRNG, которые известны специалистам в области цифровой криптографии. Синхронизированный тактовый сигнал (часы) 424 на стороне Анны сети 430 синхронизирован с синхронизированным тактовым сигналом (часами) 480 на стороне Бена сети. На стороне Бена, когда сообщение 454 принято, прилагаемое случайное слово 434 сохраняется в кэше последних случайных слов 470. Свежесть этого принятого сообщения 450 может быть верифицирована при помощи двух проверок. Сначала, случайное слово 434 проверяется в блоке 460 путем сравнения случайного слова 434 с кэшем последних случайных слов 470, чтобы определить, наблюдалось ли раньше принятое в настоящее время случайное слово 434. Если принятое случайное слово 434 наблюдалось раньше, сообщение 454 отклоняется как сообщение повтора перехваченных данных в блоке 468. Если принятое случайное слово 434 не наблюдалось раньше, сообщение определяется как OK в блоке 464 для этой первой проверки. Во-вторых, принятая временная метка 432 сравнивается с локальным синхронизированным тактовым сигналом 490. Если временная метка является недавней, сообщение 454 определяется как приемлемое в блоке 494, в ином случае сообщение 454 отклоняется как истекшее в блоке 498. Величина задержки, допустимой при определении, является ли недавняя временная метка недавней, в блоке 490, может зависеть от ожидаемого рассогласования тактовых сигналов между синхронизированным тактовым сигналом 424 и синхронизированным тактовым сигналом 480 и временных задержек при обработке и передаче сообщения через сеть 430.

[0048] Система связи может комбинировать гарантию свежести с одной или обеими из гарантии конфиденциальности, как на фиг. 2, и гарантии целостности, как на фиг. 3. В системе, комбинирующей все три, сообщение 436, отправляемое по сети 430, будет представлять собой зашифрованную версию исходного сообщения 414 Анны, и подпись, содержащая подписанный хеш сообщения 414, будет включена совместно с временной меткой 432, случайным словом 434 и сообщением 436.

[0049] Фиг. 5 изображает примерный процесс 500 для аттестации программного обеспечения анклава. Аттестация программного обеспечения, при комбинировании с протоколом согласования ключей, таким как протокол согласно фиг. 6, может уверить верификатора, что он установил совместно используемый секрет с конкретным элементом программного обеспечения, которое хостируется внутри изолированного контейнера, созданного доверенными аппаратными средствами. В варианте осуществления согласно фиг. 5, клиент 510 анклава (верификатор аттестации) может желать использовать услуги безопасного вычисления анклава на доверенной платформе 530. Доверенная платформа 530 хостируется на компьютере (не изображен), так что доверенная платформа 530 может содержать поднабор хостирующего компьютера. Доверенная платформа 530 может содержать элементы аппаратных средств и элементы программного обеспечения хостирующего компьютера. Анклав содержит безопасный контейнер 536 анклава, и код и данные внутри него, такие как открытый код и данные 538 и секретный код и данные 542.

[0050] Три процесса комбинируются в примерном процессе 500: процесс обмена ключами, который создает совместно используемый ключ SK; процесс аттестации для аттестации клиента 510 анклава для анклава на доверенной платформе 530; и безопасное вычисление. Совместно используемый ключ SK из первого процесса используется для коммуникации вводов и выводов безопасного вычисления. При обмене ключами, клиент анклава вычисляет gA, хранящийся в блоке 512, из частного ключа A клиента анклава и функции g генератора, например, как описано ниже для протокола обмена ключами Диффи-Хеллмана (DKE) на фиг. 6. Вычисленный gA затем отправляется в сообщении 520 на доверенную платформу 530. Сообщение 520 может быть безопасно отправлено без шифрования и до завершения аттестации. Программное обеспечение внутри безопасного контейнера 536 анклава может использовать частный ключ B анклава, чтобы вычислить gB с использованием той же самой функции g генератора. Как B, так и gB могут храниться в контейнере анклава в блоке 540.

[0051] Чтобы аттестовать идентичность анклава (чтобы обеспечить уверенность в том, какой код работает внутри безопасного контейнера 536 анклава), сообщение 522 аттестации отправляется на клиент 510 анклава. Сообщение аттестации может представлять собой специальное сообщение, подписанное для обеспечения целостности как на фиг. 3. Специальное сообщение может содержать информацию идентичности об анклаве. При комбинировании с DKE, как в варианте осуществления на фиг. 5, специальное сообщение может также включать в себя параметры обмена ключами. В варианте осуществления согласно фиг. 5, начальное состояние 538 безопасного контейнера 536 анклава открытого кода и открытых данных используется в качестве идентичности анклава, хотя возможны другие идентичности. Вместо отправки всего начального состояния 538 в сообщении аттестации, хеш начального состояния, M=Hash(Initial State), отправляется взамен. Сообщение 522 аттестации включает в себя содержимое сообщения (M и gB) и подпись содержимого сообщения (SignAK(Hash(gB), M)). Подпись содержимого сообщения может создаваться, например, программным обеспечением внутри безопасного контейнера 536 анклава, запрашивая доверенную платформу 530, хостирующую анклав, аттестовать хеш вычисленного gB и идентичности анклава. Доверенная платформа 530 может сделать это путем обеспечения подписи с использованием ключа аттестации платформы (AK) 532, чтобы создать SignAK(Hash(gB), M). В этом примере, идентичность анклава представляет собой хеш M начального состояния 538, но возможны другие формулировки (отчеты) идентичности. Эта подпись SignAK(Hash(gB), M) аттестации связывает значение gB с идентичностью M анклава и также связывает gB и M с доверенной платформой 530. Клиент 510 анклава может затем верифицировать сообщение аттестации путем верифицирования подписи аттестации и идентичности анклава. Подпись может быть верифицирована как на фиг. 3 с использованием открытого ключа, соответствующего ключу AK аттестации. Верифицирование подписи может обеспечивать гарантию целостности идентичности анклава в сообщении аттестации. Идентичность анклава может быть верифицирована путем сравнения информации идентичности в сообщении аттестации с независимо известным значением идентичности. Например, если информация идентичности в сообщении аттестации представляет собой хеш начального состояния анклава, клиент 510 анклава может знать хеш начального состояния или может быть способен вычислить такой хеш из известного начального состояния, и это значение может затем сравниваться со значением идентичности, обеспеченным в сообщении аттестации.

[0052] Чтобы создать совместно используемый ключ SK, как клиент 510 анклава, так и код внутри безопасного контейнера 536 могут сгенерировать gAB (функция g генератора, примененная к произведению A на B), которая может служить как совместно используемый ключ SK. Совместно используемый ключ SK может использоваться для шифрования сообщений для конфиденциальности между клиентом 510 анклава и анклавом, например для отправки данных ввода на, и данных вывода из, код(а) внутри контейнера 536 анклава. Отметим, что совместно используемый ключ создается независимо на каждой стороне канала связи в блоках 540 и 514, ни клиент анклава, ни анклав при этом не знают частный ключ друг друга. Например, в варианте осуществления на фиг. 5, секретный код и данные могут быть безопасно обеспечены клиентом 510 анклава путем шифрования секретного кода и данных при помощи ранее установленного совместно используемого ключа SK, создавая EncSK(секретный код/данные) перед отправкой его в сообщении 524 на доверенную платформу 530. В других вариантах осуществления, секретный код и данные 542, исполняемые в безопасном контейнере 536 анклава или используемые в нем, могут исходить из других местоположений. Безопасное вычисление может выполняться внутри безопасного контейнера 536 анклава с использованием секретного кода и/или данных 542, чтобы создать результат 544 вычисления. Результаты 516 вычисления могут затем безопасно сообщаться обратно клиенту 510 анклава путем шифрования результатов с помощью совместно используемого ключа SK (EncSK(results)) перед отправкой их на клиент анклава в сообщении 526.

[0053] Процесс согласно фиг. 5, описанный выше, обеспечивает клиенту анклава гарантию того, что он осуществляет связь с ʺреальнымʺ анклавом определенной идентичности, и что анклав защищен платформой анклава. Он не обеспечивает коду внутри контейнера анклава каких-либо гарантий об объекте на другой стороне канала связи. В альтернативном варианте осуществления (не изображен), такая гарантия о клиенте анклава может быть обеспечена посредством работы клиента анклава в качестве самого анклава. В этом альтернативном варианте осуществления, клиент анклава может запросить у доверенной платформы анклава подпись на хеше gA, которая может затем быть верифицирована другим анклавом.

[0054] Аттестация может совершаться локально или удаленно. На фиг. 5, клиент 510 анклава может или не может находиться на том же самом компьютере, что и доверенная платформа 530, так что коммуникации между клиентом 510 анклава и доверенной платформой 530 могут происходить в пределах одного компьютера (например, путем пересылки буферов данных между разными процессами на одном и том же компьютере) или могут происходить по компьютерной сети, которая соединяет клиент 510 анклава с доверенной платформой 530. Локальная аттестация может выполняться, когда клиент 510 анклава и доверенная платформа 530 хостируются на одном и том же локальном компьютере. Артефакт, или результат, локальной аттестации называется отчетом аттестации и представляет собой SignAK(Hash(gA), M) в примере согласно фиг. 5. Удаленная аттестация может происходить, когда клиент 510 анклава и доверенная платформа 530 хостируются на разных компьютерах. Артефакт, или результат, удаленной аттестации называется котировкой (оценкой) аттестации, которая в некоторых случаях может быть очень сходной с отчетом локальной аттестации или идентичной ему. В других случаях котировка аттестации может включать в себя дополнительный артефакт доверия, связанный с компьютером или нативной платформой, обеспечивающей котировку. Такой дополнительный артефакт доверия может включать в себя сертификат работоспособности хоста, такой как TCG log, ассоциированный с TPM. Аттестация анклава может выполняться на любом уровне идентичности анклава. Анклав может иметь вложенную или иерархическую идентичность, и аттестация на более высоких уровнях идентичности может аттестовать, что реализованный анклав является членом прогрессивно большей группы потенциальных реализаций (экземпляров) анклава с возрастанием уровня идентичности. Более высокие уровни могут соответствовать расширенному набору потенциальных реализаций анклава более низкого уровня. Примерная иерархия идентичностей может включать в себя, начиная с самого низкого, наиболее конкретного уровня до более высоких, менее конкретных уровней: ExactHash, InstanceHash, ImageID, FamilyID и AuthorID.

[0055] Идентичность анклава может быть получена из двоичных файлов (двоичных кодов анклава), загруженных на безопасный контейнер анклава. Двоичный код анклава может быть подписан его собственным автором с использованием частного ключа автора. Для аттестации уровня ExactHash, начальное состояние 538, используемое для вычисления отчета аттестации (ввод в хеш-функцию для создания отчета аттестации), может включать в себя все содержимое каждого двоичного файла, загруженного в безопасный контейнер 536, за исключением двоичных кодов, ассоциированных с доверенной платформой 530.

[0056] Аттестация на уровне идентичности InstanceHash может включать в себя поднабор начального состояния 538. Поднабор может быть специфицирован во время, когда двоичные файлы анклава (двоичные файлы), которые загружены в безопасный контейнер 536, были исходно подписаны автором этих двоичных файлов анклава. Например, первый (или первичный) двоичный файл анклава может включать в себя список идентичностей других двоичных файлов анклава, от которых зависит первый двоичный файл анклава. Для каждой перечисленной идентичности, флаг может быть включен в первый двоичный файл, чтобы указывать, измерен или нет каждый перечисленный двоичный файл посредством хеш-функции, чтобы создать отчет аттестации InstanceHash.

[0057] Аттестация до более высоких уровней ID анклава может не включать в себя прогон всего содержимого любых двоичных кодов анклава через хеш-функцию. Вместо этого, только структура данных ID может прогоняться через хеш-функцию. Например, двоичный файл анклава может включать в себя список идентификаторов анклава более высокого уровня, таких как универсально уникальные идентификаторы (UUID), указывающие: ID образа (изображения) (ImageID), уникальный для этого конкретного двоичного файла анклава; ID семейства (FamilyID), уникальный для группы двоичных файлов анклава, которая включает в себя этот конкретный двоичный файл анклава и которые разработаны одним и тем же автором; и ID автора (AuthorID), уникальный для группы семейств двоичных файлов анклава, которые все разработаны одним и тем же автором. ImageID, FamilyID и AuthorID могут быть назначены автором двоичного кода анклава во время, когда двоичный код исходно подписывается. Обманные действия (спуфинг) над идентичностями анклава можно предотвратить, при этом клиент анклава может осуществлять доступ к двоичным кодам анклава и верифицировать подпись автора на этих двоичных кодах с использованием открытого ключа автора (или открытого ключа, ассоциированного с автором). Это верифицирует целостность двоичных кодов анклава, включая любые идентичности более высокого уровня, назначенные автором, как созданные автором этого анклава.

[0058] Фиг. 6 изображает примерный протокол 600 обмена ключами Диффи-Хеллмана (DKE). DKE представляет собой один примерный процесс для установления совместно используемого ключа K по каналу связи, имеющему только гарантию целостности; могут использоваться другие процессы для создания совместно используемых ключей, известные в области цифровой криптографии. В примере DKE на фиг. 6, секретный ключ K совместно используется между Анной 610 и Беном 650 без какой-либо коммуникации K явно по общедоступной (незащищенной) среде связи между Анной 610 и Беном 650. До того, как процесс начинается, 1) большое простое число p и 2) генератор g в Zp могут быть установлены и известны как Анне, так и Бену. Затем начинается процесс, где Анна и Бен выбирают произвольное число между 1 и p. Произвольное число Анны представляет собой A, выбранное в блоке 612, и произвольное число Бена представляет собой B, выбранное в блоке 652. Анна использует свое произвольное число, чтобы вычислить gA mod p в блоке 614, и передает эту величину в блоке 616, которая принимается Беном в блоке 656. Бен использует свое произвольное число, чтобы вычислить gB mod p в блоке 654, которое передается в блоке 656 к Анне и принимается в блоке 618. Анна может создать совместно используемый ключ K как (gB mod p)A=gAB mod p в блоке 620, и Бен может создать совместно используемый ключ K как (gA mod p)B= gAB mod p в блоке 660. Чтобы предотвратить атаки через посредника, связь между Анной и Беном по незащищенной сети от блоков 616 и 658 может включать в себя гарантию целостности сообщения, например, созданную с использованием процесса, такого как процесс на фиг. 3.

[0059] Фиг. 7 изображает примерную цепочку доверия 700 для аттестации программного обеспечения. Цепочка доверия в отношении аттестации программного обеспечения может брать начало в ключе подписи, которым владеет производитель доверенной платформы, такой как доверенная платформа 530 на фиг. 5. Доверенная платформа может включать в себя компоненты аппаратных средств, такие как безопасный процессор или аппаратный модуль безопасности (HSM), и таким образом производитель может представлять собой провайдера компьютерных аппаратных средств и может также обеспечивать программное обеспечение для доверенной платформы. Производитель может быть доверенным верификатором 702, и верификатор может знать открытый ключ PubRK 732 корневого ключа 736 производителя. Клиент 510 анклава на фиг. 5 представляет собой пример верификатора 702, которому может быть желательно иметь уверенность в безопасном контейнере 708. Производитель может действовать как орган сертификации и обеспечивать каждый экземпляр доверенной платформы, который создает, например, каждый безопасный процессор, уникальным ключом 722 аттестации, который используется, чтобы создать подписи аттестации. Производитель также выпускает сертификат 728 подтверждения для каждого ключа 722 аттестации. Корневой ключ 736 производителя включает в себя частный ключ PrivRK 734, который используется, чтобы подписывать сертификат 728 подтверждения. Подписывание сертификата подтверждения обеспечивает гарантию целостности, например, как показано на фиг. 3.

[0060] Сертификат 728 подтверждения включает в себя открытый ключ PubAK 724 ключа 722 аттестации. Сертификат 728 подтверждения может указывать, что ключ 722 аттестации следует использовать для аттестации программного обеспечения, и может сообщаться верификатору 702. Верификатор может представлять собой любой объект, желающий верифицировать аттестацию безопасного контейнера 708, например, верификатор 702 может представлять собой клиента 510 анклава на фиг. 5, которому желательно, чтобы безопасное вычисление было выполнено внутри безопасного контейнера 708. Верификатор 702 может проверить сертификат подтверждения с использованием PubRK 732, чтобы верифицировать целостность и происхождение сертификата подтверждения. Верификатор может также извлекать PubAK 724 из сертификата подтверждения. Сертификат подтверждения может быть ассоциирован с политикой сертификации, что может требовать, чтобы ключ 722 аттестации использовался только для создания подписей аттестации и чтобы частный ключ PrivAK 726 ключа 722 аттестации содержался исключительно в хранилище, которое отделено от обычно доступной памяти компьютера доверенной платформы, например, в хранилище защищенных от несанкционированного вмешательства аппаратных средств 730. Защищенные от несанкционированного вмешательства аппаратные средства могут быть, например, аппаратными средствами, соответствующими стандарту модуля доверенной платформы (TPM).

[0061] Безопасный контейнер 708 может быть реализован на доверенной платформе 736. Реализация безопасного контейнера 708 может включать в себя определение изолированного пространства памяти для безопасного контейнера, который ограничен от доступа небезопасной обработкой. Небезопасная обработка может включать в себя, например, доступ извне доверенной платформы, но на компьютере, хостирующем доверенную платформу, или доступ изнутри других безопасных контейнеров внутри доверенной платформы. Реализация безопасного контейнера 708 может также включать в себя загрузку открытого кода и данных в безопасный контейнер, например, начальное состояние 535 на фиг. 5.

[0062] Реализованный безопасный контейнер 708 может обмениваться ключами с верификатором 702, чтобы установить совместно используемый ключ для конфиденциальной связи. Процесс обмена ключами может представлять собой процесс обмена ключами согласно фиг. 5 или процесс DKE согласно фиг. 6. Верификатор отправляет сообщение 1 704 обмена ключами на доверенную платформу 736, например, как в блоке 616 на фиг. 6, и доверенная платформа 736 отправляет сообщение 2 706 обмена ключами обратно на верификатор 702, например, как в блоке 658 на фиг. 6.

[0063] Подпись 710 аттестации может создаваться после того, как безопасный контейнер 708 реализован и обмен ключами завершен. Реализованный безопасный контейнер 708 может быть измерен путем запуска криптографической хеш-функции на всем или части безопасного контейнера. Это может включать в себя прогон хеш-функции по содержимому изолированной памяти, и двоичным файлам, которые загружены в изолированную память, любую другую память, ассоциированную с доверенной платформой, которая используется или испытывает воздействие во время реализации безопасного контейнера, или любой их поднабор или часть. Вывод прогона этой хеш-функции представляет собой измерение 712, которое является частью подписи 710 аттестации. Криптографический хеш сообщений 704 и 706 обменов ключами может также быть включен в процедуру с подписью 710 аттестации и изображен как данные 714. Измерение 712 и данные 714 могут быть подписаны с использованием частного ключа PrivAK 726 аттестации. Подпись аттестации может затем быть отправлена на верификатор 702 совместно с измерением 712 и данными 714. Верификатор может верифицировать целостность подписи аттестации с использованием PubAK 724 из сертификата подтверждения, что, в примере на фиг. 7, также разрешает осуществить верификацию целостности измерения 712 и данных 714. Верификатор 702 может верифицировать целостность безопасного контейнера 708 путем сравнения измерения 712 с ожидаемым результатом (ожидаемым результатом, определяемым, например, путем локального выполнения того же самого хеша измерения 712) и верифицировать, что подпись аттестации была создана для этого конкретного экземпляра пути коммуникации верификатора 702, путем проверки данных 714 (например, поскольку хеш данных 714 привязан к сообщению 2 706 обмена ключами). После этих операций верификации и верификации сертификата подтверждения, описанного выше, верификатор теперь имеет некоторую уверенность в том, что он может установить связь, имеющую как конфиденциальность, так и целостность, с безопасным контейнером 708 с использованием установленного совместно используемого ключа, что доверенная платформа аппаратных средств может быть доверенной в соответствии с ее производителем, и что состояние программного обеспечения доверенной платформы, используемой для создания безопасного контейнера, известно. Верификатор 702 теперь готов запросить безопасную обработку в пределах безопасного контейнера 708 с использованием частного кода и/или частных данных.

Платформа абстракции и примитивы анклава

[0064] Фиг. 8 представляет собой блок-схему интерфейсов компонентов программного обеспечения для примерной локальной системы анклава. Система 800 анклава включает в себя компьютер 810 с нативной платформой 812 анклава, хостирующей анклав 814, и клиент 816 анклава. Нативная платформа 812 может представлять собой компонент аппаратных средств и/или программного обеспечения на основе, например, SGX от Intel или VSM от Microsoft. Анклав 810 может представлять собой анклав 176 согласно фиг. 1. Нативный протокол 844 для анклавов может использоваться для связи между анклавом 814, клиентом 816 и нативной платформой 812. Как изображено на фиг. 8, нативный протокол 844 включает в себя интерфейс 820 в анклаве 814, интерфейсы 822 и 824 в нативной платформе и интерфейс 826 в клиенте. Эти интерфейсы могут представлять собой API или ABI в компонентах программного обеспечения.

[0065] Использование этих интерфейсов 820, 822, 824 и 826 программного обеспечения может включать в себя перенос управления исполнения между компонентами программного обеспечения. Перенос управления может включать в себя исполнение инструкции вызова или перехода в точку входа (адрес инструкции) в компоненте программного обеспечения, на который переносится управление. Например, если нативная платформа 812 представляет собой компонент программного обеспечения, перенос управления из нативной платформы 812 на клиент 816 может происходить посредством интерфейса 826 программного обеспечения, когда инструкция вызова или перехода в нативной платформе 812 исполняется, задавая адрес в пределах клиента 816 для вызова или перехода. Задаваемый адрес внутри клиента 816 может представлять собой точку входа для функции или способ в интерфейсе 816. Перенос управления указан стрелкой на фиг. 8, например: из нативной платформы 812 на анклав 814 через интерфейс 820; из анклава 814 на нативную платформу 812 через интерфейс 822; из клиента 816 на нативную платформу 812 через интерфейс 824 и из нативной платформы 812 на клиент 816 через интерфейс 826. Нативный протокол 844 может включать в себя шаблоны связи через интерфейсы 820, 822, 824 и 826.

[0066] В некоторых вариантах осуществления, нативная платформа 812 может быть реализована по меньшей мере частично как компонент аппаратных средств, например, со специальными процессорными инструкциями для администрирования анклава. Такая специальная инструкция аппаратных средств может исполняться как часть компонента программного обеспечения нативной платформы 812. В альтернативных вариантах осуществления может не существовать компонента программного обеспечения для некоторых или всех из функций нативной платформы 812. В этих альтернативных вариантах осуществления, интерфейсы 822 и 824 нативной платформы могут представлять собой инструкции аппаратных средств вместо точек входа программного обеспечения, поэтому функция нативной платформы 812 может использоваться анклавом 814 или клиентом 816 или может использоваться путем исполнения специальной инструкции аппаратных средств в анклаве 814 или клиенте 816, соответственно, вместо исполнения инструкции вызова или перехода.

[0067] В некоторых вариантах осуществления, клиент 816 анклава 814 может сам представлять собой анклав. Например, клиент 816 анклава может использовать интерфейс 824, чтобы запросить создать анклав 814. В этих вариантах осуществления, связь между анклавом 814 и клиентом 816 через нативную платформу 812 в действительности представляет собой связь между двумя анклавами. Когда клиент 816 также представляет собой анклав, клиент 816 анклава может также использовать интерфейс 822 и предоставлять интерфейс, аналогичный 820 (не изображен).

[0068] Фиг. 9 представляет собой блок-схему интерфейсов компонента программного обеспечения, например, локальную систему анклава с уровнем абстракции. Система 900 анклава включает в себя платформу 912 абстракции для перевода между нативным протоколом 944 и протоколами 940, 942 абстракции. Нативная платформа 918 может быть аналогична платформе 812 абстракции на фиг. 8, и интерфейсы 928 и 930 могут комбинировать функции интерфейсов 820, 822, 824 и 825 на фиг. 8. Протокол 940 абстракции анклава включает в себя интерфейсы 920, 922 для анклава 914, в то время как протокол 942 абстракции клиента включает в себя интерфейсы 924, 926 для клиента 916. Как на фиг. 8, клиент 916, работающий на компьютере 910, может запросить создание анклава 914 посредством интерфейса 924. Уровень 912 абстракции может вызвать создание анклава 914 с использованием нативного протокола 944 и интерфейсов 928, 930 с нативной платформой 918. Клиент 916 и анклав 914 могут использовать протоколы 940 и 942 абстракции, когда нативная платформа 918 и нативный протокол 944 основаны на разных архитектурах анклава, таких как SGX от Intel или VSM от Microsoft. Как на фиг. 8, клиент 916 анклава 914 может сам представлять собой анклав, и нативная платформа 918 может включать в себя компоненты аппаратных средств и/или программного обеспечения.

[0069] Анклав 914 и клиент 916 могут не осуществлять связь напрямую и могут вместо этого осуществлять связь только посредством платформы 912 абстракции. Прямая связь может быть невозможной или нежелательной, например, из-за изоляции памяти анклава 914. Изоляция памяти анклава может предотвращать считывание из, запись в или исполнение (переход в или из) изолированной памяти анклава.

[0070] Анклав 914 может включать в себя инструкции, находящиеся внутри безопасного контейнера анклава компьютера 910. Клиент 916 может включать в себя инструкции, расположенные в адресном пространстве памяти компьютера 910, но вне безопасного контейнера анклава 914. Платформа 912 абстракции может быть реализована различными способами, включая инструкции, которые находятся внутри или вне безопасного контейнера анклава 914, и может также включать в себя инструкции, исполняемые из гипервызовов. В случае, где платформа 912 абстракции включена по меньшей мере частично в безопасный контейнер анклава 914, код платформы абстракции внутри безопасного контейнера может быть разработан отдельно от остатка кода анклава 914 и может взаимодействовать только с другим кодом анклава посредством общедоступных API/ABI. Такой код платформы абстракции может быть статически связан или динамически связан с остатком кода внутри безопасного контейнера анклава. Статически связанный код платформы абстракции может представлять собой объектный код, который ассоциирован с платформой абстракции и включен (статически связан), совместно с кодом, который является более специфическим для анклава 914, в двоичное изображение, из которого может быть реализован анклав 914. В случае динамически связанной платформы абстракции, код анклава, который является более специфическим для анклава 914, и код, ассоциированный в более общем виде с платформой абстракции, могут исходить из отдельных двоичных изображений. Что касается динамически связанного примера, см. фиг. 14.

[0071] Фиг. 10 представляет собой блок-схему интерфейсов компонента программного обеспечения для примерной удаленной системы анклава с уровнем абстракции. Удаленная система 1000 анклава включает в себя анклав 1014 на компьютере 1010 и клиент 1056 анклава 1014 на отдельном компьютере 1050. Комбинация клиентской заглушки 1016 и удаленной (дистанционной) платформы 1052 абстракции может облегчать взаимодействие между анклавом 1014 и клиентом 1056. Множество элементов в компьютере 1010 могут быть идентичны или аналогичны идентично названным элементам компьютера 910 на фиг. 9. Конкретно, платформа 1012 абстракции, протоколы 1040, 1042, 1044, и нативная платформа 1018 могут быть аналогичны или идентичны соответствующим элементам 912, 940, 942, 944 и 918, соответственно.

[0072] Клиентская заглушка 1016 может осуществлять связь с удаленной платформой 1052 абстракции посредством сетевой связи 1080. Удаленный протокол 1082 клиента и интерфейсы 1064, 1066 могут быть аналогичны протоколу 1042 абстракции клиента и интерфейсам 1024, 1026. Однако удаленный протокол клиента может включать в себя дополнительную функциональность для дистанционного взаимодействия. Например, способ в интерфейсе 1064, такой как CreateEnclave, чтобы запросить создание анклава, может дополнительно включать в себя способность специфицировать компьютер хоста анклава, такой как компьютер 1010, где запрашивается создание анклава. Котировка (оценка) аттестации анклава 1014, обеспеченная клиенту 1056 посредством удаленного протокола клиента, может быть обеспечена вместо отчета аттестации или в дополнение к нему. Компьютер 1050 с клиентом 1056 может или не может включать в себя нативную платформу 1058 анклава. Если представлена нативная платформа 1058, она может или не может соответствовать примерной нативной платформе 1018 архитектуры анклава, и тем самым нативный протокол 1044 и удаленный нативный протокол 1084 могут не быть одними и теми же.

[0073] В альтернативном варианте осуществления (не показан), клиентская заглушка 1016 может не существовать, и платформа 1012 абстракции может напрямую осуществлять связь с удаленной платформой 1052 абстракции по сети.

[0074] Протоколы абстракции анклава, такие как 940, 942, 1040, 1042, 1082 на фиг. 9 и 10, могут включать в себя множество способов интерфейса или точек входа, чтобы администрировать и использовать анклавы, которые построены на нескольких нативных платформах, таких как SGX от Intel и VSM от Microsoft. Эти способы могут обеспечивать примитивы анклава, которые могут быть реализованы на нескольких нативных платформах, тем самым обеспечивая ʺабстракциюʺ нативных платформ. Примитивы анклава, раскрытые здесь, включают в себя администрирование срока жизни анклава, аттестацию, запечатывание данных, перенос управления, монотонные счетчики и доверенное время.

[0075] Примитивы для администрирования срока жизни анклава могут включать в себя способы для побуждения реализации или завершения анклава, такого как анклав 914. Примитивы администрирования срока жизни могут быть частью протокола 942 абстракции клиента, и, более конкретно, могут быть реализованы платформой 912 абстракции в качестве части интерфейса 924 для использования клиентом 916.

[0076] Способ для реализации или создания анклава может включать в себя специфицирование исполняемого изображения кода и/или данных, подлежащих загрузке в изолированную память безопасного контейнера анклава. Этот код, до или после того, как он загружен в контейнер анклава, может стать частью начального состояния, используемого для аттестации реализованного анклава (как объяснено выше в отношении фиг. 5). Например, исполняемое изображение анклава (двоичный код анклава) может быть специфицировано клиентом анклава путем обеспечения указателя на буфер в памяти, содержащей исполняемое изображение. Альтернативно, изображение анклава может быть определено путем указания файла в файловой системе, содержащей двоичный код анклава. В некоторых вариантах осуществления, специфицированное изображение анклава может быть зашифровано; в других вариантах осуществления, анклав может быть не зашифрован; в других вариантах осуществления, анклав может быть частично зашифрован. Измерение двоичного кода анклава для аттестации может происходить по зашифрованному исполняемому изображению или после дешифрования.

[0077] Код и/или данные, подлежащие загрузке первоначально в анклав, могут быть указаны специфицированием файла, содержащего первичное изображение анклава. В дополнение к этому коду и/или данным, первичное изображение анклава может включать в себя дополнительные метаданные, такие как желательный размер анклава (объем памяти, требуемый внутри контейнера анклава), местоположения точек входа внутри кода в файле и список файлов зависимых изображений. Файлы зависимых изображений представляют собой файлы других (не-первичных) изображений, которые могут также загружаться в анклав совместно с кодом и данными в файле первичного изображения. Файлы зависимых изображений могут сами содержать списки дополнительных файлов зависимых изображений. В случае локальной системы анклава согласно фиг. 9, первичное и зависимые изображения могут наполнять любое доступное устройство хранения, например, посредством локально доступной файловой системы. В случае системы удаленного анклава согласно фиг. 10, файл первичного изображения может находиться в любом устройстве хранения, доступном компьютеру 1010 или компьютеру 1050. Если клиент 1056 запрашивает создание анклава на компьютере 1010 с использованием первичного изображения, расположенного на компьютере 1050, удаленная платформа абстракции и клиентская заглушка 1016 могут действовать согласованно, чтобы скопировать заданный файл первичного изображения на компьютер 1010.

[0078] CreateEnclave представляет собой примерный способ для реализации анклава. Способ CreateEnclave может быть описан при помощи псевдокода:

[0079] Псевдокод, используемый для описания способов в настоящем документе, может использовать несколько соглашений псевдокода для определения интерфейсов API. Например, параметры функции, такие как enclavePath выше, могут быть оформлены с ʺ_In_ʺ или ʺ_Out_ʺ, чтобы указывать, что параметр представляет собой параметр ввода или вывода, соответственно. ʺ_Out_opt_ʺ может указывать опциональный параметр вывода. Написанные заглавными буквами слова могут указывать тип данных. HANDLE может представлять собой номер, такой как 32-битный номер 32, используемый, чтобы косвенным образом ссылаться на что-то. Например, вышеуказанный способ CreateEnclave возвращает HANDLE вызывающему CreateEnclave, и этот HANDLE может представлять собой дескриптор анклава, который был создан; PCWSTR может представлять собой указатель на определенный тип текстовой строки; DWORD может представлять собой неподписанную 32-битную величину; PCVOID может представлять собой указатель на данные не-специфицированного типа; BOOL может представлять собой двоичное значение.

[0080] CreateEnclave может разрешать клиенту, такому как клиент 916, создавать анклав и загружать первичное изображение в анклаве. Любая информация конфигурации анклава в этом изображении может быть ассоциирована с реализованным анклавом. CreateEnclave может включать в себя следующие параметры:

lpEnclaveName: может специфицировать путь к первичному изображению анклава, который в реализациях может представлять собой некоторый другой тип идентификатора для идентифицирования кода и/или данных первичного изображения анклава, такой как дескриптор для открытого файла, универсальный идентификатор ресурса (URI) или идентификатор, который используется при внешнем поиске. Например, глобально уникальный идентификатор (GUID) может использоваться в качестве ключа в базу данных первичных изображений. В других реализациях, этот параметр может идентифицировать область памяти, которая содержит первичное изображение анклава.

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

enclaveInformation: может представлять собой дополнительные параметры ввода для конфигурации среды исполнения анклава.

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

[0081] После успешного завершения, CreateEnclave может возвратить дескриптор на анклав. При ошибке, может быть возвращен NULL. Другие идентификаторы (GUID, URI и т.д.) могут также возвращаться без отклонения от объема настоящего раскрытия. Для простоты, настоящая спецификация будет описывать API с использованием дескриптора. Создание анклава может быть безуспешным, например, из-за недостатка памяти анклава, недостатка поддержки специфицированного типа анклава в платформе абстракции или нативной платформе, или создание может быть безуспешным из-за явных политик конфигурации, препятствующих исполнению на системе анклава конкретного типа.

[0082] Реализации CreateEnclave и другого способа API, описанные ниже, могут исключать один или несколько описанных параметров способа. Например, касательно CreateEnclave, могут быть исключены lpEnclaveName, flEnclaveType, dwFlags и enclaveInformation, используя конкретное предопределенное значение для данного конкретного API. Аргумент lpEnclaveError может также исключаться из API, и альтернативные способы проверки на ошибки в вызове API могут быть опционально реализованы.

[0083] CreateEnclave может отвечать за загрузку всех зависимых модулей, как специфицировано в первичном изображении анклава. Первичное изображение анклава может представлять собой файл переносимого исполнения (PE), который специфицирует другие файлы двоичного изображения, от которых зависит первичное изображение. CreateEnclave может также выполнять конкретную инициализацию нативной платформы, такую как финализация измерений для аттестации, распределение структур для безопасности транспортного уровня (TLS) и/или других протоколов согласования ключей и связи и т.д. Интерфейсы 920, 922 протокола абстракции анклава (включая способы, например, для запечатывания и аттестации данных) могут применяться, когда инициализация анклава завершена.

[0084] TerminateEnclave представляет собой примерный способ для завершения анклава:

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

[0086] Платформа 912 абстракции анклава может включать в себя примитивы переноса управления исполнением, которые могут использоваться, например, чтобы перенести управление между анклавом и его клиентом. Примитивы переноса управления исполнения могут обеспечить возможность связи между анклавом 914 и клиентом 916 путем запуска исполнения кода в точке входа в другом компоненте. Примитивы переноса управления исполнения разрешают пересылку данных в/из анклавов, позволяя параметрам ассоциироваться с запросом переноса управления; параметры могут специфицировать индивидуальные элементы данных (сами параметры сообщаются), или параметры могут быть указателями на области памяти (сообщаются буферы, указываемые параметрами). Эти примитивы могут задействовать перенос управления несмотря на ограничения на прямой вызов или переход между анклавом 914 и клиентом 916 из-за ограничений безопасности на контейнере анклава.

[0087] Для вызова в анклав, интерфейс 924 может включать в себя механизмы, чтобы разрешать клиенту 916 вызывать в анклав 914 через интерфейс 920. Например, интерфейс 924 может включать в себя способы GetProcAddress и CallEnclave:

[0088] Клиент анклава, такой как клиент 916, может вызывать в анклав, такой как анклав 914, с использованием указателя функции, возвращенного посредством GetProcAddress(). Параметр lpProcName может сопоставить функцию, экспортируемую в первичное изображение анклава. Например:

[0089] В других вариантах осуществления GetProcAddress, lpProcName может представлять собой другой идентификатор конкретной экспортируемой функции, такой как номер, такой как выбор из нумерации точек входа, экспортируемых из изображения анклава, или другой не-текстовый идентификатор, соответствующий функции. Другие варианты осуществления CallEnclaveIn могут дополнительно брать параметр ввода, специфицирующий анклав, подлежащий вызову в анклав, например, возвращаемое дескриптором CreateEnclave.

[0090] При вызове в анклав, тред в процессе клиента может приостанавливаться, и тред анклава (с отдельным ID треда) может использоваться, чтобы обслуживать вызов в запросе. Код анклава, исполняющийся на треде анклава, может затем иметь доступ к памяти, которая была ранее доступна клиенту анклава перед вызовом в анклав. Например, клиент может поместить данные в буфер, указанный посредством pParameter, перед вызовом способа абстракции CallEnclaveIn, и затем анклав может иметь доступ к буферу, указанному посредством pParameter, при обслуживании вызова в запросе. После вызова вовне, тред исходного (клиентского) вызова может использоваться для обслуживания вызова вовне. Может поддерживаться повторный вход (например, вызов вовне в хост может снова вызывать в анклав).

[0091] Для вызова из анклава, интерфейс 922 может включать в себя способы, относящиеся к вышеописанным способам CallEnclaveIn, которые разрешают анклаву 914 вызывать вовне на клиент 916 анклава. Например, анклав 914 может вызвать вовне в любую функцию в процессе хоста конкретного типа, например типа функции ENCPROC. Указатель функции для этого может пересылаться с использованием параметров вызова в анклав.

Интерфейс 920 может включать в себя точки входа, зарегистрированные как функция ʺCallinExampleʺ выше, и интерфейс 926 может включать в себя точки входа, зарегистрированные как функции ʺCalloutʺ выше. Например, в случае, где первичное изображение анклава находится в формате переносимого исполняемого (PE) изображения, точки входа функции в изображении могут быть перечислены как точки входа ʺэкспортаʺ, и каждая такая экспортируемая точка входа может включать в себя текстовое имя, такое как ʺCallinExample,ʺ чтобы идентифицировать и отличать точки входа в этом РЕ изображении анклава; в других реализациях точки входа функции могут быть маркированы дополнительными метаданными, такими как один бит, указывающий, что функция может представлять собой точку входа для анклава. В примере выше для вызова вовне анклава, адрес функции вызова вовне задается как 0xF00 и является только примером. Действительный адрес функции вызова вовне может определяться множеством способов. Например, адрес функции вызова вовне внутри клиента может пересылаться в анклав как параметр для функции вызова внутрь. В другом примере, адрес функции вызова вовне может быть зарегистрирован клиентом с использованием функции, такой как RegisterCallOut:

Код внутри анклава может получать адрес функции вызова вовне путем вызова комплементарной функции, такой как GetCallOut:

[0092] В других вариантах осуществления, способы CallEnclaveIn и CallEnclaveOut могут в действительности представлять собой тот же самый способ. Например, один способ CallEnclave может использоваться для вызова в анклав и вызова из анклава. В ситуациях, где клиент 916 анклава также представляет собой анклав, вызов из анклава 914 на клиента 916 будет также представлять собой вызов в анклав.

[0093] Платформа 912 абстракции может обеспечивать примитивы для запечатывания данных в анклав. Например, интерфейс 922 может предоставлять услуги на анклав 914, такие как запечатывание и распечатывание (вскрытие) данных на идентичность анклава. Как объяснено выше, анклав может иметь несколько вложенных идентичностей, и данные могут быть запечатаны на любую такую идентичность. Когда данные запечатаны на идентичность, которая соответствует набору возможных реализаций анклава, запечатанные данные могут распечатываться любой из этого соответствующего набора реализаций анклава. Например:

[0094] Для каждого значения enclaveIdType, анклав будет запечатывать на ID отображения. Возможные типы идентичности анклава (и значения enclaveIdType) включают в себя:

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

[0096] Платформа 912 абстракции может обеспечивать примитивы для аттестации, таких как для создания отчетов и котировок аттестации, и для верификации отчетов и котировок. Например:

[0097] VerifyReport() может использоваться анклавом для подтверждения целостности отчета и того, что отчет был сгенерирован анклавом на той же машине.

[0098] В CreateQuote, quoteType может отображаться на провайдер котировки, который может представлять собой источник доверия, чтобы сгенерировать конкретную котировку. В CreateQuote, authData может представлять собой указатель на данные, которые созданы вызывающим CreateQuote, и в формате, определенном им. Отметим, что authData не обязательно должно пониматься платформой 912 абстракции. authData может быть упаковано в результирующую котировку. Можно ожидать, что провайдеры котировки будут поддерживать это.

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

[00100] Методы, описанные выше, могут быть реализованы на одном или нескольких вычислительных устройствах или средах, как описано ниже. Фиг. 11 изображает примерную универсальную вычислительную среду, например, которая может воплощать одно или несколько из доверенных аппаратных средств 172, доверенной платформы 736 или компьютеров 810, 910, 1010 и 1050, в которых могут быть реализованы некоторые из методов, описанных в настоящем документе. Среда 1102 вычислительной системы представляет собой только один пример подходящей вычислительной среды и не подразумевается, чтобы предлагать какое-либо ограничение на объем использования или функциональность представленного раскрытого предмета. Вычислительная среда 1102 не должна интерпретироваться как имеющая какую-либо зависимость или требование, относящееся к любому одному или комбинации компонентов, проиллюстрированных в примерной операционной среде 1102. В некоторых вариантах осуществления, различные изображенные вычислительные элементы могут включать в себя схемы, сконфигурированные для реализации конкретных аспектов настоящего изобретения. Например, термин ʺсхемаʺ, используемый в раскрытии, может включать в себя специализированные аппаратные компоненты, сконфигурированные, чтобы выполнять функцию(и) с помощью встроенного программного обеспечения или переключателей. В других примерных вариантах осуществления, термин ʺсхемаʺ может включать в себя блок обработки общего назначения, память и т.д., сконфигурированные программными инструкциями, которые воплощают логику, приводимую в действие, чтобы выполнять функцию(и). В примерных вариантах осуществления, где схема включает в себя комбинацию аппаратных средств и программного обеспечения, разработчик может написать исходный код, воплощающий логику, и исходный код может компилироваться в машиночитаемый код, который может быть обработан с помощью блока обработки общего назначения. Поскольку специалист в данной области техники может понимать, что уровень техники получил такое развитие, что существует незначительное различие между аппаратными средствами, программным обеспечением или комбинацией аппаратных средств/программного обеспечения, выбор аппаратных средств по сравнению с программным обеспечением для осуществления конкретных функций является выбором на этапе проектирования, который оставлен за разработчиком. Более конкретно, специалист в данной области техники может понимать, что программный процесс может быть трансформирован в эквивалентную структуру аппаратных средств, и структура аппаратных средств сама может быть трансформирована в эквивалентный программный процесс. Таким образом, выбор аппаратной реализации по сравнению с реализацией программного обеспечения является выбором при проектировании, оставленным за разработчиком.

[00101] Компьютер 1102, который может включать в себя любое из мобильного устройства или смартфона, планшета, ноутбука, настольного компьютера или совокупности сетевых устройств, облачных вычислительных ресурсов и т.д., как правило, включает в себя множество считываемых компьютером носителей. Считываемые компьютером носители могут быть любыми доступными носителями, к которым можно получить доступ с помощью компьютера 1002, и включают в себя как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители. Системная память 1022 включает в себя компьютерные носители хранения в форме энергозависимой и/или энергонезависимой памяти, такие как постоянная память (ROM) 1123 и память с произвольной выборкой (RAM) 1160. Базовая система ввода/вывода (BIOS) 1124, содержащая основные подпрограммы, которые способствуют переносу информации между элементами внутри компьютера 1102, например, во время запуска, обычно хранится в ROM 1123. RAM 1160 обычно содержит данные и/или программные модули, которые непосредственно доступны и/или в данный момент обрабатываются блоком обработки 1159. В качестве примера, а не ограничения, фиг. 11 иллюстрирует гипервизор 1130, операционную систему 1125, прикладные программы 1126, другие программные модули 1127, включая клиента 1165 анклава и анклав 1128.

[00102] Компьютер 1102 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения. В качестве примера, фиг. 11 иллюстрирует накопитель 1138 на жестком диске, который считывает или записывает на несъемные, энергонезависимые магнитные носители, накопитель 1139 на магнитном диске, который считывает или записывает на съемный, энергонезависимый магнитный диск 1154, и накопитель 1104 на оптическом диске, который считывает или записывает на съемный, энергонезависимый оптический диск 1153, такой как CD-ROM или другие оптические носители. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения, которые могут быть использованы в примерной операционной среде, включают, но без ограничения указанным, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельную ROM, твердотельную RAM и тому подобное. Накопитель 1138 на жестком диске обычно соединен с системной шиной 1121 через интерфейс несъемной памяти, такой как интерфейс 1134, и накопитель 1139 на магнитном диске и накопитель 1104 на оптическом диске обычно соединены с системной шиной 1121 посредством интерфейса съемной памяти, такого как интерфейс 1135 или 1136.

[00103] Накопители и ассоциированные с ними компьютерные носители хранения, описанные выше и показанные на фиг. 11, обеспечивают хранение считываемых компьютером инструкций, структур данных, программных модулей и других данных для компьютера 1102. На фиг. 11, например, накопитель 1138 на жестком диске проиллюстрирован как хранящий операционную систему 1158, прикладные программы 1157, другие программные модули 1156, такие как приложения клиента анклава и двоичные файлы анклава, и программные данные 1155. Отметим, что эти компоненты могут либо быть такими же, либо отличаться от операционной системы 1125, прикладных программ 1126, других программных модулей 1127 и программных данных 1128. Операционная система 1158, прикладные программы 1157, другие программные модули 1156 и программные данные 1155 обозначены другими ссылочными позициями для иллюстрации того, что, как минимум, они являются различными копиями. Пользователь может вводить команды и информацию в компьютер 1102 через устройства ввода, такие как клавиатура 1151 и указательное устройство 1152, обычно упоминаемое как мышь, трекбол или сенсорная панель. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер, сканер сетчатки глаза или тому подобное. Эти и другие устройства ввода часто соединяются с блоком 1159 обработки через интерфейс 1136 пользовательского ввода, который связан с системной шиной 1121, но могут быть соединены посредством других интерфейсов и шинных структур, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 1142 или другой тип устройства отображения также соединен с системной шиной 1121 через интерфейс, такой как видео интерфейс 1132. В дополнение к монитору, компьютеры могут также включать в себя другие периферийные устройства вывода, такие как динамики 1144 и принтер 1143, которые могут быть подсоединены через интерфейс 1133 периферийных устройств вывода.

[00104] Компьютер 1102 может работать в сетевой среде, используя логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер 1146. Удаленный компьютер 1146 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой РС, одноранговое устройство или другой общий сетевой узел, и обычно включает в себя многие или все из элементов, описанных выше относительно компьютера 1102, хотя только устройство 1147 хранения памяти было проиллюстрировано на фиг. 11. Логические соединения, изображенные на фиг. 11, включают в себя локальную сеть (LAN) 1145 и глобальную сеть (WAN) 1149, но могут также включать в себя другие сети. Такие сетевые среды являются обычным явлением в офисах, компьютерных сетях предприятий, интранетах, Интернете и облачных вычислительных ресурсах.

[00105] При использовании в сетевой среде LAN, компьютер 1102 подключен к локальной сети 1045 через сетевой интерфейс или адаптер 1137. При использовании в сетевой среде WAN, компьютер 1102 обычно включает в себя модем 1105 или другие средства для установления связи через WAN 1149, такую как Интернет. Модем 1105, который может быть внутренним или внешним, может быть подключен к системной шине 1121 через интерфейс 1136 пользовательского ввода или другой соответствующий механизм. В сетевой среде, программные модули, изображенные по отношению к компьютеру 1102, или их части, могут храниться в удаленном устройстве хранения памяти. В качестве примера, а не ограничения, фиг. 11 иллюстрирует удаленные прикладные программы 1148, как находящиеся на устройстве памяти 1147. Следует понимать, что показанные сетевые соединения являются примером, и могут быть использованы другие средства установления линии связи между компьютерами.

[00106] Фиг. 12 изображает примерную блок-схему последовательности операций для способа 1200 абстрагирования нативной платформы анклава. Платформа абстракции, такая как 912 на фиг. 9, может принимать запрос для платформы анклава в блоке 1202. Запрос может исходить от клиента анклава, такого клиента 914, или от анклава, такого как анклав 916.

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

[00108] Запрос от клиента анклава может представлять собой запрос выполнить примитив платформы абстракции и может включать в себя, например, запрос, чтобы: реализовывать анклав; верифицировать отчет аттестации анклава; вызывать функцию внутри анклава (вызов в анклав); и распределять память, которая может совместно использоваться между анклавом и его клиентом.

[00109] Запрос платформы абстракции может переводиться в запрос нативной платформы в операциях 1204-1208. Параметры, включенные или предполагаемые в принятом запросе, могут быть преобразованы в дополнительном этапе 1204, если это определено, например, что формат данных параметра в исходном запросе не является тем же самым, что и формат данных для этого параметра в нативной платформе. Например, если запрос от анклава или клиента включает в себя параметр, выведенный из отчета аттестации формата абстракции, такой как идентичность абстракции анклава, он будет преобразован в параметр, используемый в отчете аттестации нативного формата, такой как нативная идентичность анклава.

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

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

[00112] В блоке 1208, преобразованный запрос отправляется на нативную платформу, чтобы вызвать выполнение запроса нативной платформой. Например, в случае, где нативная платформа соответствует архитектуре анклава Расширений безопасности программного обеспечения (SGX) от Intel, нативная платформа может включать в себя инструкции процессора для анклавов. В этом случае, отправка запроса в блоке 1208 может включать в себя исполнение одной или нескольких инструкций процессора для анклавов. В другом примере, нативная платформа может соответствовать архитектуре анклава Виртуального безопасного режима (VSM) от Microsoft, которая может включать в себя гипервизор с гипервызовами для анклавов. Гипервызов представляет собой программное прерывание кода гипервизора, и гипервызов может вызывать изменение контекста процессора на контекст, в котором могут быть разрешены привилегированные операции. В этом примере VSM, отправка запроса в блоке 1208 может включать в себя выполнение гипервызовов в гипервизор и/или другие механизмы, чтобы переключить контекст исполнения на контекст, в котором могут быть разрешены привилегированные операции.

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

[00114] Примитив CreateEnclave может использоваться, чтобы реализовать анклав. Запрос CreateEnclave, чтобы реализовать анклав, может побудить платформу абстракции создать безопасный контейнер (например, путем распределения некоторой памяти и установления границы безопасности или изоляции для этой памяти), копировать код анклава в этот безопасный контейнер (например, из изображения анклава) и конфигурировать или задействовать точки входа в код анклава (например, в соответствии с метаданными точек входа в изображении анклава).

[00115] Отправка запроса CreateEnclave на нативную платформу при помощи обеспеченного анклавом гипервизора (гипервизора, который обеспечивает функции администрирования анклава, такого как VSM), может включать в себя распределение памяти и побуждение гипервызовов устанавливать таблицы страниц процессора для памяти таким образом, чтобы предотвратить доступ кода вне контейнера анклава к этой памяти. Гипервызовы создания анклава из платформы абстракции могут также побуждать гипервизор устанавливать информацию конфигурации для переноса управления в анклав в назначенных точках входа. Затем, код вне безопасного контейнера может осуществлять гипервызовы переноса управления, чтобы перенести исполнение в назначенных точках входа внутри безопасного контейнера.

[00116] Отправка запроса CreateEnclave на нативную платформу при помощи задействованного анклавом процессора (процессора с процессорными инструкциями администрирования анклава, такого как SGX), может включать в себя исполнение платформой абстракции инструкции, такой как ECREATE, чтобы информировать CPU, что определенную область памяти следует создать в качестве безопасного контейнера анклава, и исполнение инструкции, такой как EADD, чтобы добавить страницы данных в этот контейнер анклава. Специальные процессорные инструкции могут также использоваться, чтобы создавать специальные страницы в памяти для назначения точек входа в анклаве для переноса управления в анклав. Затем, код вне безопасного контейнера может исполнить инструкцию, такую как EENTER, специфицирующую одну из назначенных точек входа, чтобы перенести управление исполнением в эту точку входа анклава.

[00117] Примитив CreateReport может использоваться, чтобы создавать отчет аттестации. Запрос CreateReport создать отчет аттестации анклава может выполняться уровнем абстракции, как пояснено выше в отношении фиг. 5 и 7. При помощи задействованного анклавом гипервизора, уровень абстракции может отправлять запрос на нативную платформу путем осуществления гипервызова, который изменяет состояние исполнения, например, на контекст контроля безопасности, который имеет доступ к секретному ключу, такому как PrivAK726 согласно фиг. 7, который может использоваться, чтобы подписывать отчеты. Этот секретный ключ может быть доступным только контексту контроля безопасности, если компьютер был загружен в работоспособной конфигурации, как верифицировано на основе TCG log в TPM. Контроль безопасности может маркировать данные отчета идентичностью удостоверяемого анклава.

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

[00119] Примитив EnclaveSeal может использоваться, чтобы запечатывать данные в анклав. Запечатывание данных в анклав зашифровывает данные таким способом или при помощи ключа, который ассоциирован с анклавом. Запрос EnclaveSeal может представлять собой запрос запечатать данные, находящиеся внутри анклава, такие как все или часть состояния анклава, в анклаве с использованием политики запечатывания. Политика запечатывания, такая как SEALING_POLICY, описанная выше, может специфицировать тип идентичности анклава, который указывает, какие анклавы должны иметь возможность распечатывать (вскрывать) данные. Сами процессы запечатывания могут использовать ключ шифрования, ассоциированный с идентичностью анклава, специфицированной в политике запечатывания. Затем, реализация нового анклава может быть способна вскрывать данные, если значение идентичности нового анклава в специфицированном типе идентичности является тем же самым, что и значение идентичности анклава запечатывания в специфицированном типе идентичности.

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

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

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

[00123] При помощи задействованного анклавом гипервизора, уровень абстракции может отправить запрос EnclaveSeal на нативную платформу путем осуществления гипервызова. Гипервызов может изменять состояние исполнения на контекст, например, контекст контроля безопасности, который будет иметь доступ к секретному ключу запечатывания, ассоциированному с анклавом, который может использоваться, чтобы запечатывать или распечатывать данные. Ключ запечатывания может извлекаться из комбинации идентичности анклава и секретного ключа платформы, способной только контролировать безопасность. Этот ключ платформы может быть доступен только контролю безопасности, когда машина загружается в работоспособной конфигурации, и конфигурация загрузки верифицируется при помощи TCG log на основе TPM. В этом варианте осуществления обеспеченного анклавом гипервизора, код анклава никогда не имеет доступа к ключу запечатывания.

[00124] При помощи задействованного анклавом процессора, запрос EnclaveSeal может быть отправлен на нативную платформу путем исполнения инструкции, такой как EGETKEY, чтобы получить ключ шифрования. Этот алгоритм может генерировать ключ запечатывания, который является уникальным для анклава. Ключ запечатывания может быть выведен из идентичности анклава и секрета, встроенного в процессор. Код внутри анклава может затем зашифровывать данные при помощи ключа запечатывания. Данные могут быть запечатаны путем шифрования при помощи ключа запечатывания, например, кодом внутри анклава, платформой абстракции или нативной платформой. EnclaveUnseal может аналогично использовать EGETKEY, чтобы сгенерировать ключ распечатывания.

[00125] Запрос на перенос управления может представлять собой запрос перенести управление исполнением процессора из инструкций внутри анклава на точку входа вне анклава (например, CallEnclaveOut) или обратно из инструкций вне анклава в точку входа внутри анклава (например, CallEnclaveIn). Это может быть сделано, например, для безопасной операции базы данных. После реализации анклава базы данных, клиент анклава может запросить, чтобы анклав выполнил конкретную операцию, такую как запрос базы данных с использованием примитива CallEnclaveIn, чтобы перенести управление в точку входа внутри анклава базы данных, который выполнит запрос. После того, как анклав завершает запрос, результат запроса может быть возвращен (возможно, после шифрования результата) на клиента при помощи примитива CallEnclaveOut, чтобы перенести управление обратно на клиента в точке входа в клиента, который может принять результат запроса. Примитивы CallEnclaveIn и CallEnclaveOut могут брать указатель на буфер памяти, который может совместно использоваться между анклавом и его клиентом (буфер может быть считываемым, записываемым и/или исполняемым анклавом или его клиентом).

[00126] При помощи задействованного анклавом гипервизора, уровень абстракции может отправить запрос CallEnclaveIn на нативную платформу путем выполнения гипервызова. Гипервызов может изменять состояние исполнения на контекст, например, контекст контроля безопасности, который сохранит регистры CPU, восстановит ранее сохраненный набор значений регистров CPU анклава (возможно, из памяти анклава), изменит конфигурацию таблицы страниц, чтобы разрешить доступ к защищенной памяти анклава, и вызовет точку входа функции внутри анклава. Аналогично, когда платформа абстракции принимает запрос CallEnclaveOut, запрос может быть отправлен на нативную платформу посредством гипервызова, который сохранит регистры CPU анклава (возможно, путем сохранения в память анклава) и восстановит сохраненные ранее регистры CPU для клиента анклава, изменит конфигурацию таблицы страниц, чтобы предотвратить доступ к памяти анклава, и перенесет управление процессором в точку входа в клиенте анклава вне анклава.

[00127] При помощи задействованного анклавом процессора, запрос CallEnclaveIn может быть отправлен на нативную платформу путем исполнения инструкции, такой как EENTER, которая может побудить CPU восстановить набор регистров CPU анклава (возможно, из памяти анклава) и вызвать функцию (перенести управление в точку входа) внутри анклава. Примитив CallEnclaveOut может исполнять инструкцию, такую как EEXIT, которая может переносить управление на инструкции вне анклава и/или вызывать сбой, который переносит управление вне анклава.

[00128] Монотонный счетчик имеет множество применений. Например, анклав может пожелать ограничить то, насколько далеко назад его состояние может быть реверсировано. Монотонные счетчики могут использоваться, например, в качестве случайного слова, чтобы гарантировать свежесть сообщений, как обсуждалось выше в отношении фиг. 4. Монотонные счетчики обычно имеют возможность считывания и приращения, но не могут уменьшать значение. Чтобы ограничить возврат или реверсирование состояния анклава, код внутри анклава может сообщать приращение ассоциированному монотонному счетчику и затем сохранять значение счетчика совместно с внутренним состоянием анклава. Состояние и значение счетчика могут быть сохранены, например, при помощи примитива EnclaveSeal. Далее, при восстановлении состояния анклава, например с использованием примитива EnclaveUnseal, код внутри анклава может считать текущее значение монотонного счетчика и сравнивает его со значением счетчика с незапечатанным состоянием. Если значение счетчика с незапечатанным состоянием меньше, чем текущее значение счетчика, анклав может предотвратить использование незапечатанного состояния.

[00129] При помощи задействованного анклавом гипервизора, уровень абстракции может отправить запрос на нативную платформу, чтобы считать или сообщить приращение монотонному счетчику путем выполнения гипервызова, который предоставлен анклаву. Когда вызывается гипервызов, чтобы считать или сообщить приращение счетчику, процессор изменит состояние исполнения на контекст, такой как контроль безопасности, который будет верифицировать идентичность анклава, выполняющего гипервызов, и затем выполнять считывание или приращение, соответственно, соответствующего монотонного счетчика, сохраненного, например, в энергонезависимом хранилище, таком как чип TPM. Альтернативно, контроль безопасности может выполнять считывание или приращение счетчика, сохраненного на удаленном доверенном сервере или наборе удаленных доверенных серверов, путем установления канала безопасной связи с таким сервером и запрашивания его выполнить считывание или приращение заданного монотонного счетчика. Удаленный доверенный сервер или серверы могут поддерживать счетчик внутри анклава, чтобы изолировать его от остальной части кода в компьютере-хосте.

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

[00131] Фиг. 13 изображает примерную блок-схему последовательности операций для способа 1300 абстрагирования нативной платформы анклава. Платформа абстракции анклава может принимать запрос от анклава или клиента анклава в блоке 1302. В блоке 1304, платформа абстракции может определять, включает ли в себя нативная платформа инструкции процессора анклава, например, путем определения, соответствует ли нативная платформа SGX. Если она соответствует, то инструкции процессора анклава исполняются в блоке 1306. В блоке 1308, платформа абстракции может определить, включает ли в себя нативная платформа гипервызовы анклава, например, путем определения, соответствует ли нативная платформа VSM. Если она соответствует, то нативная платформа выполняет гипервызовы анклава. Результаты исполнения инструкций анклава или вызова гипервызовов анклава очищаются в блоке 1312. Очистка может включать в себя, например, преобразование параметров вывода или обработку исключения инструкций процессора анклава или гипервызовов анклава в формат или протокол интерфейса уровня абстракции. Преобразованные параметры вывода затем возвращаются на исходный запросчик (анклав или клиент) в блоке 1314.

Абстрактная идентичность анклава

[00132] Фиг. 14 изображает примерные двоичные изображения анклава, используемые, чтобы реализовать анклав. Анклав может быть реализован путем создания безопасного контейнера, такого как контейнер 1490 анклава, и копирования частей одного или нескольких изображений анклава в контейнер. Контейнер 1490 анклава может быть создан со ссылкой на первичное изображение 1410 анклава. Первичное изображение может включать в себя ссылки на другие зависимые изображения анклава. В этом примере, первичное изображение 1410 включает в себя зависимость1 (Dependency1) и зависимость2 (Dependency2) в качестве ссылок на зависимые изображения 1420 и 1450 анклава, соответственно. Изображение 1420 включает в себя дополнительно зависимости от изображений 1430 и 1440, в то время как изображение 1450 зависит от изображения 1460. Когда все эти изображения (или их части) скопированы в контейнер 1490, результирующий анклав может включать в себя не-платформенные изображения 1402, которые могут включать в себя код и данные, которые являются уникальными или конкретными для реализованного анклава, изображения платформы 1404 абстракции и изображения 1406 нативной платформы.

[00133] Каждое изображение анклава, такое как первичное изображение 1410, может включать в себя ID, зависимости, код, данные и подпись автора изображения. В примере изображения 1410, включены два ID 1410.1 и 1410.2. Эти ID могут представлять собой UUID, которые задают, например, значение абстрактной идентичности, соответствующее значению ImageID, FamilyID или AuthorID, которые, по отдельности или вместе, могут использоваться, чтобы идентифицировать любой анклав, реализованный при помощи этого изображения анклава. Как изображено, изображение 1410 имеет два ID, но возможно меньше или больше ID. Код в изображении 1410 может представлять собой двоичные инструкции, исполняемые процессором компьютера, хостирующего контейнер 1490 анклава. Данные в изображении 1410 могут использоваться любым кодом, загруженным в контейнер 1410. Изображение 1410 может также включать в себя подпись Sig 1410, чтобы обеспечить целостность любого или всех из других содержимых изображения, таких как ID, ссылки зависимостей, код и данные. Другие изображения 1420-1460 могут аналогично содержать ID, ссылки зависимостей, код, данные и подписи.

[00134] Указатель зависимости, такой как зависимость1 и зависимость 2, или изображение 1410, зависимость1 и зависимость 2 изображения 1420, и зависимость 1 изображения 1450, может быть задан множеством способов. Если изображения 1410-1460 хранятся в компьютерной памяти системы, указатель зависимости может просто представлять собой адрес в памяти. Если изображения анклава представляют собой файлы в файловой системе, ссылки могут представлять собой имена файлов. В некоторых вариантах осуществления, ссылки могут представлять собой логический идентификатор. Логический идентификатор может представлять собой уникальное число, такое как UUID, или может представлять собой другие данные, такие как текстовая строка, которая иначе идентифицирует изображение зависимости. Например, текстовая строка может указывать автора, источник, имя продукта, семейство продукта и/или номер версии зависимого двоичного изображения. Логический идентификатор включает в себя веб- или интернет-местоположение, такое как местоположение, откуда может извлекаться копия зависимого двоичного кода.

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

[00136] В некоторых вариантах осуществления, указатель зависимости может представлять собой криптографически безопасный идентификатор, такой как криптографический хеш предполагаемого зависимого двоичного изображения анклава. Такой хеш может включать в себя весь зависимый двоичный код или только его часть. Часть зависимого двоичного кода, включенная в указатель зависимости, может включать в себя значения абстрактной идентичности, такие как ID 1410.1 или ID 1420.2, и может представлять собой значения абстрактной идентичности. Услуга разрешения для криптографически безопасного идентификатора может не обязательно быть настолько же доверенной, что и для логического идентификатора, поскольку объект, определяющий зависимости анклава, может быть способен верифицировать, что корректное зависимое изображение было найдено вычислением хеша самого зависимого двоичного кода.

[00137] Фиг. 15 изображает примерную блок-схему последовательности операций для способа 1500 выполнения операции анклава с абстрактной идентичностью анклава. Значение абстрактной идентичности для анклава может обеспечивать основу для определения эквивалентности между двумя анклавами, которые имеют некоторое общее свойство, но не являются абсолютно идентичными. Значение идентичности может быть включено в отчет аттестации и может быть ассоциировано с типом абстрактной идентичности (таким ExactHash, InstanceHash, ImageID, FamilyID или AuthorID). Два анклава, которые не являются абсолютно одинаковыми, могут иметь одно и то же значение абстрактной идентичности для типа абстрактной идентичности. Дополнительно, идентичный код анклава, реализованный в безопасных контейнерах на двух разных нативных платформах анклава, может также иметь то же самое значение абстрактной идентичности. Способ 1500 может выполняться, например, уровнем платформы абстракции между нативной платформой анклава и либо анклавом, либо клиентом анклава.

[00138] В блоке 1502, анклав реализуется из изображения анклава, такого как первичное изображение 1410 анклава на фиг. 14. Изображение анклава может представлять собой первичное изображение, включающее в себя код анклава, данные, список идентичностей, список любых зависимых изображений анклава и подпись. Чтобы обеспечить целостность изображений анклава, изображения могут быть подписаны при помощи частного ключа, который может соответствовать автору изображения анклава. Список ID идентичностей анклава в изображении анклава может соответствовать типам абстрактной идентичности, таким как ImageID, FamilyID и AuthorID, каждый из которых предназначен, чтобы идентифицировать изображение анклава сообща совместно с другими связанными изображениями анклава. Список зависимых изображений анклава может ссылаться на другие изображения анклава, содержащие код анклава, от которых зависит код в первичном изображении анклава. Зависимое изображение анклава может быть или может не быть создано тем же самым автором, и некоторые зависимые изображения анклава могут быть в общем виде ассоциированы с платформой анклава (платформой абстракции или нативной платформой), а не конкретно ассоциированы с первичным изображением анклава или автором первичного изображения анклава. Анклав может быть реализован путем создания безопасного контейнера анклава с использованием любой нативной платформы анклава и копированием всего или части первичного изображения и любых зависимых изображений анклава в безопасный контейнер.

[00139] В блоке 1503, запрашивается операция анклава, например, анклавом или клиентом анклава, совместно с типом идентичности анклава. Тип идентичности может задавать тип абстрактной идентичности, такой как Image ID или AuthorID, и быть связан с конкретным реализованным анклавом, но не задает значение AuthorID для этого анклава. Остальная часть способа 1500, следующая за блоком 1503, описывает операции для выполнения операции (такой как аттестация, запечатывание данных или использование монотонного счетчика и т.д.) с реализованным анклавом с использованием значения идентичности, полученного для этого типа идентичности реализованного анклава. Идентичность может определяться с использованием хеша поднабора изображения(й) анклава. То, какой поднабор изображения(й) анклава используется в качестве ввода в хеш, может быть основано частично на типе идентичности, желательном для использования в операции анклава.

[00140] В блоке 1504, часть изображения анклава, называемая здесь частью идентичности, определяется на основе типа идентичности. Часть идентичности может включать в себя все, часть или ничего из различных двоичных изображений анклава, используемых, чтобы реализовывать анклав в блоке 1502. Часть идентичности может включать в себя все, часть или ничего из кода анклава, содержащегося в изображении анклава. Часть идентичности может также включать в себя ноль, одну или несколько идентичностей ID, перечисленных в не-кодовой части включенных изображений анклава. Часть идентичности может или не может также включать в себя данные анклава, содержащие изображения анклава. Часть идентичности может включать в себя любую комбинацию этих различных частей изображений анклава. Например, часть идентичности может включать в себя весь код, ничего из данных и две или четыре доступных идентичности ID. В опциональном блоке 1506 определяется, какие зависимые изображения анклава должны быть включены в часть идентичности, и определяется часть идентичности каждого включенного изображения.

[00141] Часть идентичности зависимых изображений может быть или может не быть той же самой, что и часть идентичности первичного изображения анклава. Например, весь код и ImageID включены в часть идентичности первичного изображения, в то время как код не может, и только FamilyID зависимого изображения может включаться в часть идентичности зависимого изображения.

[00142] Когда код анклава включен в часть идентичности, части кода анклава в части идентичности могут определяться комбинацией типа идентичности и указания того, какие зависимости должны быть включены в часть идентичности. Тип идентичности InstanceHash может включать в себя, например, код анклава в первичном изображении, но не в зависимых изображениях, в то время как тип идентичности ExactHash может включать в себя код анклава во всех зависимых изображениях, которые не являются рассматриваемой частью платформы анклава. Например, все зависимые изображения анклава, которые не подписаны частным ключом автора платформы анклава, могут рассматриваться как не являющиеся частью платформы анклава. Альтернативно или дополнительно, первичное изображение может включать в себя список того, какие зависимые изображения анклава должны быть включены или исключены в части идентичности для типов идентичности InstanceHash или ExactHash.

[00143] ID идентичности анклава, которые могут быть включены в качестве метаданных в изображении анклава, могут быть включены в часть идентичности изображения анклава вместо кода анклава или дополнительно к нему. Например, часть идентичности для типов идентичности ImageID, FamilyID и AuthorID может включать в себя соответствующие метаданные ID из изображения анклава. Когда типы идентичности вложены или упорядочены по уровням, часть идентичности для типов более низкого уровня может включать в себя данные ID для типов более высокого уровня. Например, часть идентичности для ImageID может включать в себя данные ID для ImageID, FamilyID и AuthorID, в то время как часть идентичности для AuthorID может включать в себя только данные ID для AuthorID.

[00144] Типы идентичности, которые включают в себя код анклава, такие как InstanceHash и ExactHash, обеспечивают более высокий уровень уверенности, например, клиенту анклава посредством аттестации, что определенный код анклава работает внутри анклава. Однако идентичность анклава обязательно изменится, когда изменяется любая часть идентичности кода анклава. Например, если дилемма с безопасностью или другая неполадка зафиксирована в новой версии изображения анклава, результирующее значение идентичности, основанное на новом коде, также изменится. Путем обеспечения механизма для исключения определенных частей кода анклава из вычисления хеша идентичности, идентичность анклава может быть отделена от изменений в исключенных частях кода анклава. Например, когда один код анклава автора зависит от кода анклава, обеспеченного платформой анклава, идентичность анклава может быть отделена от пересмотренных версий зависимой платформы.

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

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

[00147] Наконец, в блоке 1512, операция, связанная с реализованным анклавом, может выполняться с использованием значения идентичности. Например: отчет аттестации реализованного анклава может генерироваться или верифицироваться для типа идентичности; данные могут быть запечатаны в или распечатаны из реализованного анклава с идентичностью; и могут быть использованы монотонный счетчик или доверенное время, привязанное к реализованному анклаву и типу идентичности.

[00148] Операции анклава с использованием типов идентичности более высокого уровня обеспечивают возможность взаимодействий между группами возможных реализаций анклава. Аттестация для типа идентичности высокого уровня может обеспечивать эквивалентность отчетов аттестации для всех анклавов с той же самой идентичностью высокого уровня. Например, отчет аттестации для типа идентичности AuthorID может быть эквивалентным отчету аттестации от всех анклавов, реализованных из первичного изображения, содержащего те же самые метаданные AuthorID. Данные, запечатанные на тип идентичности высокого уровня, могут быть распечатаны любым анклавом с тем же самым значением идентичности высокого уровня. Например, данные, запечатанные в реализованный анклав с типом идентичности AuthorID, могут быть распечатаны любым другим реализованным анклавом с теми же самыми метаданными AuthorID в его первичном изображении анклава.

Эквивалентность идентичности анклава

[00149] Фиг. 16 изображает примерную систему с эквивалентностью абстрактной идентичности анклава. Клиент 1602 анклава может осуществлять связь с первым анклавом 1612, реализованным в безопасном контейнере анклава первой нативной платформы 1616 посредством платформы 1614 абстракции, и клиент 1602 может также осуществлять связь со вторым анклавом 1622, реализованным в безопасном контейнере анклава второй нативной платформы 1626 посредством платформы 1624 абстракции. Первая нативная платформа 1616 может или не может находиться на том же самом компьютере, что и вторая нативная платформа. Клиент 1602 анклава может находиться на том же самом компьютере, что и одна из нативных платформ, или может находиться на отдельном третьем компьютере. Первая нативная платформа 1616 может быть не той же самой, что и вторая нативная платформа 1626. Например, первая нативная платформа 1616 может быть более ранней версией второй нативной платформы от того же самого производителя нативной платформы. Альтернативно, первая нативная платформа 1616 и вторая нативная платформа 1626 могут соответствовать полностью различным архитектурам анклава, такими как VSM и SGX.

[00150] Клиент анклава может безопасно определять, что анклавы являются эквивалентными, путем сравнения значений идентичности, полученных из отчетов аттестации. Клиент 1602 анклава может безопасно идентифицировать каждый из анклавов путем приема отдельных отчетов аттестации от первого анклава 1612 и второго анклава 1622. Значение идентичности может быть включено в (или получено из) каждый(ого) из этих отчетов аттестации. Если значения идентичности являются одинаковыми, клиент 1602 анклава может иметь уверенность в том, что первый анклав 1612 и второй анклав 1622 эквивалентны в некотором смысле. Значения идентичности из отчетов аттестации могут представлять собой значения абстрактной идентичности, соответствующие конкретному типу абстрактной идентичности (такому как ExactHash, InstanceHash, ImageID, FamilyID или AuthorID) или хешам таких значений абстрактной идентичности. В этом случае, эквивалентность может определяться, когда анклавы не абсолютно идентичны. Два анклава могут не быть абсолютно идентичными, но все еще определяться как эквивалентные, например, когда изображения анклава, загруженные в контейнер анклава, представляют собой разные версии той же самой функциональности или первичные изображения с разными зависимыми изображениями или те же самые изображения анклава, загруженные в контейнеры анклава разных архитектур анклава.

[00151] Первый анклав 1612 может рассматриваться эквивалентным, но не идентичным второму анклаву 1622 для множества ситуаций. В первом примере, только поднабор кода, изначально загруженного в контейнеры анклава, является тем же самым (например, эквивалентным для типов ExactHash или InstanceHash абстрактной идентичности). Во втором примере, автор кода анклава мог включить идентичный ID в два разных двоичных изображения анклава, даже хотя код в двух двоичных изображениях является разным (например, эквивалентным для типов идентичности ImageID, FamilyID или AuthorID). В третьем примере, код в каждом анклаве является полностью тем же самым, но загружен (реализован) на различные нативные платформы. В этом третьем примере, первая нативная платформа 1616 и вторая нативная платформа 1626 могут быть произведены разными производителями, и тем самым доверие в отношении разных отчетов аттестации основывается на разных органах сертификации (см. фиг. 7, элемент 738) разных производителей. Примером, где две нативных платформы различаются, является нахождение в группе серверов или в облачном вычислении, где серверы, распределенные для обработки рабочих нагрузок первого и второго анклавов, представляют собой серверы, которые не поддерживают одну и ту же нативную платформу анклава.

[00152] В альтернативном варианте осуществления, первый анклав может представлять собой клиент второго анклава, так что блоки 1602 и 1612 комбинируются. Определение эквивалентности анклава в этом варианте осуществления может включать в себя определение, в пределах первого анклава, что значение идентичности из отчета аттестации второго анклава является тем же самым, что и собственное значение идентичности первого анклава (на конкретном уровне абстрактной идентичности).

[00153] Фиг. 17 изображает примерную блок-схему последовательности операций для параллельной обработки с двумя эквивалентными анклавами. Процесс 1700 может выполняться, например, клиентом двух или более разных анклавов. В блоке 1702, два анклава реализованы на разных экземплярах нативной платформы, например, как изображено на фиг. 16. Анклавы могут быть реализованы клиентом анклава, специфицирующим двоичное изображение анклава (такое как первичное изображение 1410 на фиг. 14) посредством способа CreateEnclave платформ 1614 и 1624 абстракции. Двоичное изображение анклава, специфицированное, чтобы реализовывать два анклава, может быть тем же самым или различным. Отчет аттестации для каждого реализованного анклава создается в блоке 1704. Отчеты аттестации могут создаваться, например, в запросе клиента анклава или в запросе самих анклавов. Объект, желающий доказать эквивалентность двух анклавов, такой как клиент анклава, получает копии обоих отчетов аттестации. Отчеты аттестации могут быть дополнительно верифицированы в блоке 1706. Например, целостность отчета может быть верифицирована путем верифицирования подписи аттестации при помощи сертификата подтверждения (такого как на фиг. 7, элемент 728) нативной платформы, которая создала отчет аттестации. Дополнительно, сертификат подтверждения может быть верифицирован при помощи открытого ключа производителя нативной платформы (такого как на фиг. 7, элемент 732). Значения идентичности (или их хеш) могут извлекаться из каждого отчета аттестации в блоке 1708, и эквивалентность двух анклавов может определяться путем верифицирования, что извлеченные значения идентичности являются теми же самыми для каждого анклава. Эти значения идентичности могут представлять собой значения абстрактной идентичности (или их хеши), ассоциированные с типом идентичности.

[00154] Когда клиент анклава доказал эквивалентность двух реализаций анклава из операций в блоках 1708 и 1710, два анклава могут использоваться взаимозаменяемо, в соответствии с типом показанной эквивалентности. Блоки 1712-1720 изображают примерный способ использования эквивалентных анклавов для использования двух реализованных эквивалентных анклавов путем параллельной обработки. В блоках 1712 и 1716, часть набора данных ввода, такая как часть базы данных или часть файла цифрового изображения, копируется в первый и второй анклав. Часть скопированного набора данных может быть идентичной или различной в соответствии с решаемой задачей обработки. Операция обработки может безопасно выполняться параллельно путем одновременного выполнения операции частично в первом анклаве в блоке 1714 и выполнения операции частично во втором анклаве в блоке 1718. Операцией может быть, например, выполнение поиска в базе данных или выполнение операции обработки изображения. Первый анклав может выполнять поиск в первой половине базы данных или выполнять операцию обработки изображения на первой половине изображения, в то время как второй анклав может выполнять поиск во второй половине базы данных или выполнять операцию обработки изображения на второй половине изображения. Наконец, в блоке 1720, результаты параллельной обработки в первом и втором анклаве могут комбинироваться, например, путем комбинирования двух отсортированных половин базы данных или сведения двух половин изображения вместе.

[00155] Фиг. 18 изображает примерную блок-схему последовательности операций для последовательной обработки при помощи двух эквивалентных анклавов. Как изображено на фиг. 18, операция анклава, такая как операция базы данных или операция обработки изображения, создается безопасно в двух последовательных частях в двух отдельных анклавах. Процесс 1800 может выполняться, например, клиентом 1602 анклава согласно фиг. 16. В блоке 1802, первый анклав создается на первой нативной платформе анклава, и отчет аттестации первого анклава создается в блоке 1804. Этот первый отчет аттестации (первого анклава) может быть верифицирован в блоке 1806, например, как описано выше в отношении блока 1706 на фиг. 17. В блоке 1808, безопасная операция начинается в первом анклаве, но не завершается. Состояние первого анклава может дополнительно быть запечатано для безопасного удаления из первого анклава в блоке 1810. Например, первое состояние анклава может быть запечатано на тип идентичности первого анклава. Когда состояние анклава сохранено, первый анклав может быть завершен (не изображено).

[00156] Второй анклав используется, начиная с блока 1812. В блоке 1812, второй анклав реализуется на второй нативной платформе. Как на фиг. 16 и 17, вторая нативная платформа может или не может хостироваться на том же самом компьютере, что и первая нативная платформа, и первая и вторая нативные платформы могут быть одними и теми же или разными. Отчет аттестации второй нативной платформы создается в блоке 1814, и, дополнительно, этот второй отчет аттестации может быть верифицирован в блоке 1816. Значение идентичности из первого и второго отчетов аттестации может сравниваться в блоке 1818, чтобы верифицировать эквивалентность первого и второго анклавов. В альтернативных вариантах осуществления, второй анклав может быть реализован, и эквивалентность верифицирована (блоки 1812-1818) до того, как безопасная операция начинается в первом анклаве в блоке 1808. Чтобы продолжить безопасную операцию, начатую в первом анклаве, запечатанное состояние из первого анклава может копироваться во второй анклав и распечатываться в блоке 1820. В блоке 1822, безопасная операция завершается во втором анклаве (с использованием состояния анклава, безопасно скопированного из первого анклава, если состояние было скопировано).

Распределенное запечатывание данных

[00157] Фиг. 19 представляет собой блок-схему примерной системы распределенного запечатывания данных. Запечатывание данных может распределяться по нескольким анклавам, где эти анклавы хостируются на отдельных нативных платформах анклава и/или на отдельных компьютерах. Как объяснено выше, примитивы EnclaveSeal и EnclaveUnseal абстракции могут запечатывать и распечатывать данные для анклава с использованием ключа, привязанного к нативной платформе анклава или физическому компьютеру, на котором работает анклав. Это может ограничить распечатывание только до анклавов, хостируемых на одном и том же компьютере или одном и том же экземпляре нативной платформы анклава. Фиг. 19 изображает систему распределенного запечатывания данных, где запечатывание или распечатывание данных может происходить на нативной платформе или компьютере, отличных от нативной платформы и компьютера, хостирующих анклав. Система 1900 включает в себя компьютеры 1910, 1930, 1950 с сетью 1902, соединяющей компьютеры 1910 и 1930, и сетью 1904, соединяющей компьютеры 1930 и 1950. Компьютер 1910 хостирует исходный анклав 1912, из которого могут исходить данные, подлежащие запечатыванию; компьютер 1930 хостирует анклав распределенного запечатывания (DSE) 1932 для обслуживания запросов распределенного запечатывания и распечатывания; и компьютер 1950 хостирует анклав 1952 места назначения, где распечатываются ранее запечатанные данные. Как объяснено выше в отношении фиг. 9, анклавы 1912, 1932, 1952 могут осуществлять связь с платформами 1914, 1934, 1954 абстракции, соответственно, посредством протокола абстракции анклава, и платформы 1914, 1934, 1954 абстракции могут осуществлять связь с нативными платформами 1916, 1936 и 1956, соответственно, посредством нативного протокола. В альтернативных вариантах осуществления, один или несколько анклавов 1912, 1932, 1950 могут хостироваться непосредственно на нативных платформах 1961, 1936, 1956 без промежуточной платформы абстракции. Запечатанные данные 1938 могут представлять собой данные, запечатанные в DSE 1932 с использованием ключа, ассоциированного с DSE 1932 или хостирующей его нативной платформой 1936. Запечатанные данные 1938 могут храниться в менее защищенном местоположении, например, на компьютере 1930 вне безопасного контейнера анклава DSE 1932, например, где-то в пространстве памяти компьютера 1930 или в файловой системе жесткого диска.

[00158] Распределенное запечатывание данных может включать в себя аутентификацию DSE 1930 для исходного анклава, например, путем аттестации DSE 1932 по сети 1902. Когда исходный анклав 1912 доверяет DSE 1932, исходный анклав 1912 может отправить конфиденциальные данные по каналу безопасной связи на DSE 1932 совместно с политикой запечатывания для запечатывания посредством DSE 1932. DSE 1932 может затем запечатать данные из анклава 1912 в него самого и сохранить запечатанные данные в небезопасном хранилище. Далее, анклав 1952 места назначения может запросить ранее запечатанные данные. Для распечатывания данных, DSE 1932 может аутентифицировать анклав 1952 места назначения, например, путем аттестации по сети 1904, и верифицировать, что распечатывание для анклава 1952 места назначения разрешено в соответствии с политикой запечатывания, обеспеченной исходным анклавом 1912. DSE 1932 может распечатать ранее запечатанные данные из исходного анклава 1912 и затем отправить распечатанные данные по каналу безопасной связи на анклав 1952 места назначения. Данные анклава могут сообщаться безопасно на и от DSE 1932 путем шифрования данных анклава по сетям 1902 и 1904. Например, данные анклава, отправленные по сети 1902, могут быть зашифрованы при помощи ключа, сгенерированного во время аттестации DSE 1932, в исходный анклав 1912, и данные, отправленные по сети 1904, могут быть зашифрованы при помощи ключа, сгенерированного во время аттестации анклава 1952 места назначения, в DSE 1932. Возможны другие каналы безопасной связи, такие как шифрование при помощи открытого ключа места назначения, например, открытого ключа, ассоциированного с DSE, или открытого ключа, ассоциированного с анклавом места назначения.

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

[00160] В некоторых вариантах осуществления, нативные платформы 1916, 1936, 1956 представляют собой отдельные нативные платформы, поскольку они хостируются на разных компьютерах 1910, 1930, 1950, даже если нативные платформы 1916, 1936, 1956 соответствуют той же самой версии той же самой архитектуры нативной платформы анклава. В других вариантах осуществления, нативные платформы 1916, 1936, 1956 могут соответствовать разным архитектурам платформы или разным версиям той же самой архитектуры нативной платформы анклава. Использование абстрактных идентичностей в политике запечатывания может облегчать хостирование анклавов источника и места назначения на разных архитектурах нативной платформы.

[00161] В других вариантах осуществления распределенного запечатывания данных, не изображенных на фиг. 19, может не существовать трех отдельных компьютеров (таких как отдельные компьютеры 1910, 1930, 1950). Например, анклавы источника и места назначения могут находиться на одном компьютере (и возможно на одной нативной платформе), в то время как DSE находится на другом компьютере. С другой стороны, DSE может хостироваться на том же самом компьютере, что и компьютер, хостирующий исходный анклав, или компьютер, хостирующий анклав места назначения. В этих вариантах осуществления распределенного запечатывания данных, запечатывание и распечатывание данных не является полностью локальным для одного компьютера, как описано выше в отношении примитивов абстракции EnclaveSeal и EnclaveUnseal.

[00162] Распределенное запечатывание данных может быть реализовано в уровне абстракции API, например, платформами 1914, 1934, 1954 абстракции. Например, примитивы DistributedEnclaveSeal и DistributedEnclaveUnseal аналогичны примитивам EnclaveSeal и EnclaveUnseal локального запечатывания данных, обсуждаемым выше.

[00163] DistributedEnclaveSeal расширяет EnclaveSeal путем взятия дополнительного параметра SetOfTargetEnclaves, который разрешает вызов анклава, такого как анклав 1910, чтобы задавать набор идентичностей анклава, которые авторизованы для распечатывания данных, обеспеченных посредством параметра pPlaintext. Если идентичности не обеспечены посредством SetOfTargetEnclaves, авторизованная идентичность анклава по умолчанию может предполагаться как идентичность анклава запечатывания, например ExactHash или InstanceHash анклава запечатывания.

[00164] Реализация DistributedEnclaveSeal, например, как способа платформы 1914 абстракции на компьютере исходного анклава, может включать в себя установление безопасного канала связи с DSE, например, путем шифрования сообщения по сети 1902. Ключ(и) для этого шифрования может, например, генерироваться во время процесса аттестации, как описано выше, или может представлять собой любой открытый ключ, ассоциированный с DSE 1932.

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

[00166] DistributedEnclaveUnseal может быть реализован в платформе 1954 абстракции и может работать в ответ на запрос из анклава 1952 места назначения. DistributedEnclaveUnseal может устанавливать безопасный канал связи с DSE 1932, например, путем шифрования сообщений при помощи ключа, сгенерированного во время аттестации анклава 1952 места назначения для DSE 1932, или путем шифрования сообщений, отправленных на анклав места назначения, при помощи открытого ключа анклава места назначения. DSE может верифицировать идентичность анклава запрашивания (места назначения), например, путем аттестации, распечатать запрошенные запечатанные данные и безопасно отправить распечатанные данные на анклав запрашивания. В вариантах осуществления, где анклав запрашивания имеет несколько идентичностей, конкретная идентичность может быть указана в параметре идентичности. В вариантах осуществления, где несколько наборов данных анклава хранятся для одной идентичности анклава, параметр KeyForData может указывать, какой набор запечатанных данных (для указанной идентичности) запрашивается, с использованием того же самого значения KeyForData, использованного в DistributedEnclaveSeal, когда набор данных запечатывался.

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

[00168] В вариантах осуществления, не изображенных на фиг. 19, функции анклава 1932 распределенного запечатывания (DSE) могут сами быть распределены по нескольким DSE. Например, функциональность DSE может быть распределена по нескольким DSE на нескольких компьютерах для избыточности и устойчивости к отказам. В этом примере, любой дублированный DSE может обслуживать запрос запечатать или распечатать. Отметим, что запечатанные данные 1938, как только они запечатаны/зашифрованы, могут безопасно храниться в любом месте, включая дублирование по облачным серверам хранения.

[00169] Распределенное запечатывание данных может разрешить перемещение рабочих нагрузок анклава между компьютерами. Например, данные исходного анклава, запечатанные посредством DSE, могут представлять собой данные состояния исходного анклава на первом облачном сервере, которые могут загружаться в анклав места назначения на втором облачном сервере после распечатывания. Это может делаться аналогично тому, как описано выше в отношении фиг. 18. Безопасная операция может начинать исполнение в исходном анклаве. Далее, возможно после того, как исполнение в исходном анклаве прервано, состояние исходного анклава может быть запечатано на DSE и затем распечатано для анклава места назначения, когда анклав места назначения готов продолжить безопасную операцию, которая была начата в исходном анклаве.

[00170] Фиг. 20 представляет собой примерную блок-схему последовательности операций для распределенного запечатывания и распечатывания данных, как может выполняться анклавом запечатывания или DSE. Блоки 2002-2006 соответствуют распределенному запечатыванию данных, в то время как блоки 2008-2010 соответствуют распределенному распечатыванию данных. В ответ на запрос запечатать набор данных анклава, исходящий из исходного анклава, анклав запечатывания (или DSE) может выполнить аттестацию самого себя для исходного анклава, путем отправки отчета или котировки аттестации на исходный анклав в блоке 2002. Исходный анклав может верифицировать идентичность анклава запечатывания как подлинного и доверенного анклава запечатывания, путем проверки значения и подписи идентичности в отчете аттестации анклава запечатывания. В блоке 2004, анклав запечатывания принимает разрешенный список и данные анклава, подлежащие запечатыванию. Они могут быть приняты посредством безопасного канала, как описано выше в отношении фиг. 19. В опциональном блоке 2006, анклав запечатывания может запечатать данные исходного анклава в него самого, например, если данные хранятся вне безопасного контейнера анклава запечатывания, например, в файловой системе компьютера. Чтобы распечатать данные для анклава места назначения, анклав места назначения может выполнить аттестацию себя самого для анклава запечатывания, например, путем предоставления отчета или котировки аттестации, в блоке 2008. В блоке 2010, идентичность анклава места назначения может быть верифицирована, например, путем проверки отчета аттестации анклава места назначения. В блоке 2012, анклав запечатывания определяет, разрешено ли анклаву места назначения распечатывать данные из исходного анклава, путем верифицирования того, что аутентифицированная идентичность анклава места назначения включена в разрешенный список, принятый с данными. Как только разрешение было подтверждено, данные анклава могут быть распечатаны, если они были запечатаны, и затем отправлены на анклав места назначения посредством безопасного канала в блоке 2014.

Анклав хранилища ключей

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

[00172] Фиг. 21 представляет собой блок-схему примерного анклава хранилища ключей. Анклав 2122 представляет собой хранилище ключей внутри безопасного контейнера анклава второй нативной платформы 2126 анклава. В примере на фиг. 21, клиент 2112 анклава 2122 хранилища ключей также представляет собой анклав и хостируется внутри безопасного контейнера анклава первой нативной платформы 2116 анклава. Анклавы 2112, 2122 могут взаимодействовать с их соответственными нативными платформами 2116, 2126 посредством соответственных платформ 2114, 2124 абстракции анклава. В других вариантах осуществления, одна или обе платформы 2114, 2124 абстракции могут не существовать там, где анклавы 2112 и/или 2122 взаимодействуют напрямую с нативными платформами 2116, 2126.

[00173] Анклав 2122 хранилища ключей может осуществлять связь с клиентом 2112 хранилища посредством канала 2150 связи. В некоторых вариантах осуществления, канал 2112 связи может представлять собой безопасный канал связи, обеспечивающий уверенность в конфиденциальности, целостности и/или свежести сообщений, отправляемых по каналу 2150 связи. Конфиденциальность и целостность такого безопасного канала связи могут быть установлены, например, при помощи шифрования и подписей, как на фиг. 2 и 3, с применением совместно используемых ключей, генерируемых как часть процесса аттестации, как на фиг. 5 и 6.

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

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

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

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

StoreKey([in] Keyname, [in] KeyType, [in] KeyValue, [in] Policy)

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

[00178] Примерный прототип функции GenerateKey представляет собой:

GenerateKey([in] keyName, [in] keyType, [in] Policy)

[00179] GenerateKey генерирует новый ключ определенного типа и сохраняет его внутри хранилища ключей, т.е., ключ никогда не покидает хранилище ключей.

[00180] Примерный прототип функции GetKey представляет собой:

GetKey([in] KeyName, [out] KeyValue)

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

[00182] Примерный прототип функции DeleteKey представляет собой:

DeleteKey([in] keyName)

[00183] DeleteKey удаляет ключ из хранилища ключей.

[00184] Примерный прототип функции DeriveKey представляет собой:

DeriveKey([in] newKeyName, [in] KeyName, [in] kdfIdentifier, [in] AdditionalData)

[00185] DeriveKey использует криптографическую функцию получения (вывода) ключа (KDF), идентифицированную посредством kdfIdentifier, чтобы вывести новый ключ на основе ключа, идентифицированного посредством keyName, и данных, пересланных в AdditionalData.

[00186] Примерный прототип функции Encrypt представляет собой:

Encrypt([in] KeyName, [in] algorithm, [in] data, [out]encryptedData)

[00187] Encrypt зашифровывает данные при помощи ключа, идентифицированного посредством keyName, с использованием запрошенного алгоритма.

[00188] Примерный прототип функции Decrypt представляет собой:

Decrypt([in] KeyName, [in] algorithm, [in] encrytedData, [out]data)

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

[00190] Примерный прототип функции Sign представляет собой:

Sign([in] KeyName, [in] algorithm, [in] data, [out] signature)

[00191] Sign подписывает данные при помощи ключа, идентифицированного посредством keyName, с использованием запрошенного алгоритма.

[00192] Примерный прототип функции VerifySignature представляет собой:

VerifySignature([in]KeyName, [in] algorithm, [in] signature, [out} bool signatureIsCorrect)

[00193] VerifySignature верифицирует подпись при помощи ключа, идентифицированного посредством keyName, с использованием запрошенного алгоритма.

[00194] Все из названных выше примитивов хранилища ключей могут быть реализованы путем установления безопасного канала с KVE. Канал может быть установлен с использованием аттестации и выполнения обмена ключами Диффи-Хеллмана, как описано выше в отношении фиг. 5 и 6. После того, как канал связи установлен, запрос безопасно отправляется по каналу, и ответ считывается из канала. Канал может обеспечивать гарантии конфиденциальности и целостности обмениваемых данных.

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

[00196] Фиг. 22 представляет собой примерную блок-схему последовательности операций для некоторых операций хранилища ключей анклава. Процесс 2200 начинается в блоке 2202 путем безопасного хранения, в анклаве хранилища ключей, ключа, используемого в системе шифрования. Ключ может использоваться, например, чтобы зашифровывать или дешифровывать данные, генерировать криптографическую подпись, или может только использоваться как корневой ключ, из которого следует извлекать другие ключи. Ключ может безопасно храниться в анклаве хранилища ключей путем, например, хранения ключа в пространстве памяти безопасного контейнера анклава. В других вариантах осуществления, ключ может храниться безопасно вне безопасного контейнера анклава путем запечатывания данных ключа в анклав хранилища ключей или может храниться безопасно путем удаленного запечатывания при помощи анклава распределенного запечатывания, как описано в отношении фиг. 19 и 20.

[00197] В блоке 2204, анклав хранилища ключей выполняет процесс аттестации для аттестации идентичности анклава хранилища ключей для клиента хранилища. Это может давать клиенту уверенность, что хранилище ключей не является самозванцем и ему можно доверять секреты, такие как ключ или данные, подлежащие шифрованию. Аттестация анклава хранилища ключей может включать в себя отправку, на клиента хранилища, отчета аттестации или котировки аттестации анклава хранилища ключей. Клиент хранилища ключей может затем верифицировать целостность отчета аттестации путем верифицирования подписи в отчете аттестации при помощи открытого ключа, ассоциированного с нативной платформой анклава для анклава хранилища ключей. Например, отчет аттестации хранилища 2122 ключей может быть сгенерирован второй нативной платформой 2126, и клиент 2112 хранилища может верифицировать подпись в отчете с использованием открытого ключа, ассоциированного со второй нативной платформой 2126. Этот процесс аттестации может также генерировать ключи, используемые для безопасного канала связи между клиентом хранилища и анклавом хранилища ключей, например, как показано на фиг. 5 и 6. Отчет аттестации может включать в себя идентичность анклава хранилища ключей, которая может определяться различными способами, как описано выше, например, в отношении фиг. 14 и 15. Идентичность может, например, быть основана на хеше всего содержимого безопасного контейнера анклава хранилища ключей, хеше только уникального идентификатора, назначенного автором/создателем анклава хранилища ключей, или хеше комбинации части содержимого контейнера и уникального идентификатора.

[00198] Некоторые операции хранилища ключей анклава могут также требовать уверенности в идентичности клиента хранилища. Например, дешифрование данных или разглашение ключа (например, при помощи примитивов Decrypt или GetKey) может требовать такой уверенности. В этих ситуациях, если клиент хранилища также представляет собой анклав, дополнительный блок 2208 включает в себя процесс аттестации для верифицирования, анклавом хранилища ключей, идентичности клиента хранилища. Процесс аттестации блока 2208 может включать в себя прием, в анклаве хранилища ключей, отчета или котировки аттестации клиента хранилища.

[00199] В дополнительном блоке 2210, безопасный канал связи может быть установлен между хранилищем ключей и анклавом хранилища ключей. Безопасная связь может требоваться для пересылки секретов между клиентом хранилища и анклавом хранилища ключей, таких как ключи или данные, подлежащие шифрованию. Процесс аттестации блока 2004 или 2008 может генерировать ключи, которые могут использоваться, чтобы создавать безопасный канал связи между клиентом хранилища и анклавом хранилища ключей, например, как показано на фиг. 5 и 6. С другой стороны, любой известный открытый ключ места назначения сообщения может использоваться, чтобы безопасно отправлять сообщение.

[00200] В блоке 2212, операция ключа, такая как операция одного из примитивов хранилища ключей, описанных выше, может выполняться внутри анклава хранилища ключей. Во время этой операции, данные ключа могут храниться только в адресном пространстве безопасного контейнера анклава хранилища ключей. Примерные примитивы включают в себя DeriveKey, Decrypt, Sign и другие.

[00201] Процесс 2200 предполагает, что анклав хранилища ключей уже знает ключ. Отметим, что для некоторых операций или примитивов анклава хранилища ключей, таких как StoreKey или GenerateKey, порядок операций может отличаться от изображенного в процессе 2200. Например, для GenerateKey, операция генерации ключа (как в блоке 2212) будет происходить до операции безопасного хранения блока 2202. Такой порядок операций изображен на фиг. 23, блоки 2302-2308.

[00202] Фиг. 23 представляет собой примерную блок-схему последовательности операций для создания и использования анклава хранилища ключей с запертым в хранилище ключом. В блоках 2302-2308 процесса 2300, новый ключ выводится в анклаве хранилища ключей. В блоках 2310-2316, заново выведенный ключ используется, чтобы выполнять операцию дешифрования. Это представляет собой примерное использование запертого в хранилище ключа, причем все операции ключа выполняются при помощи анклава хранилища ключей, и ключ никогда не предоставляются клиенту хранилища. Дополнительно, новый ключ в этом примере никогда не может существовать вне анклава хранилища ключей, поскольку он был создан (выведен) из самого анклава хранилища ключей, и никогда не предоставлялся анклаву хранилища ключей из клиента хранилища или откуда-либо еще. Для некоторых вариантов осуществления и политик использования ключа, запертый в хранилище ключ может быть недолговечным в том, что он никогда не покидает безопасный контейнер анклава хранилища ключей, даже после запечатывания ключа в анклав хранилища ключей. Подобный недолговечный ключ, такой как может иметь место с выведенным ключом, используемым, чтобы временно защищать канал связи, может переставать существовать где-либо, когда контейнер анклава хранилища ключей разрушен или завершен. Хотя процесс на фиг. 23 иллюстрирует то, как может использоваться запертый в хранилище ключ, процесс на фиг. 23 может также использоваться с ключом, который не заперт в хранилище, например, если политика использования ключа разрешала возвратить ключ на клиента, который запросил его создание.

[00203] В блоке 2302, анклав хранилища ключей выполняет аттестацию себя для клиента хранилища. Это может потребоваться клиенту, поскольку клиент будет предоставлять секрет, подлежащий шифрованию, в блоке 2312. В блоке 2304, анклав хранилища ключей может принимать, например, от клиента хранилища, указание политики использования ключа. Указание может, например, представлять собой структуру данных, задающую политику, или может представлять собой идентификатор, подлежащий использованию с регистром политик использования ключа. Политика использования ключа сама может указывать, что этот ключ никогда не должен быть предоставлен какому-либо клиенту хранилища. В блоке 2306, новый ключ выводится из ранее известного корневого ключа, например, при помощи примитива DeriveKey, описанного выше. Запрос (не изображен) вывести новый ключ может быть принят анклавом хранилища ключей, например, от клиента хранилища. В блоке 2308, заново выведенный ключ может храниться безопасно в соответствии с принятой политикой использования ключа.

[00204] Клиент хранилища может выполнить аттестацию себя по отношению к анклаву хранилища ключей в блоке 2310. Процесс аттестации может включать в себя прием, в анклаве хранилища ключей, отчета или котировки аттестации клиента хранилища. Принятая политика использования ключа может ограничивать некоторые или все использования нового ключа до запросов от запросчиков, которые аутентифицированы посредством аттестации программного обеспечения. В блоках 2312-2316, операция дешифрования, такая как для примитива Decrypt, описанного выше, выполняется с использованием ключа, выведенного в блоке 2306. В других вариантах осуществления, другие операции могут выполняться при помощи запертого в хранилище ключа, такие как шифрование, подписывание, верифицирование подписи и вывод другого нового ключа из ключа, выведенного в блоке 2306 (вывод ключа второго поколения из корневого ключа). В блоке 2312, буфер зашифрованных данных принимается от клиента хранилища. Принятые зашифрованные данные дешифруются при помощи выведенного ключа в блоке 1314, и результирующие дешифрованные данные (в буфере дешифрованных данных) отправляются на клиента хранилища посредством безопасного канала связи в блоке 2316.

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

[00206] прием первого отчета аттестации из первого анклава, реализованного на первой нативной платформе анклава;

[00207] извлечение первого значения идентичности анклава, ассоциированного с типом идентичности анклава, из первого отчета аттестации;

[00208] прием второго отчета аттестации из второго анклава, реализованного на второй нативной платформе анклава, причем первая нативная платформа анклава и вторая нативная платформа анклава являются разными;

[00209] извлечение второго значения идентичности анклава, ассоциированного с типом идентичности анклава, из второго отчета аттестации;

[00210] определение, что первое значение идентичности анклава является тем же самым, что и второе значение идентичности анклава; и

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

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

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

[00214] копирование запечатанных данных из первого анклава во второй анклав; и

[00215] распечатывание запечатанных данных во второй анклав.

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

[00217] копирование первой части набора данных в первый анклав;

[00218] копирование второй части набора данных во второй анклав; и

[00219] причем вычислительная операция частично завершается в первом анклаве с использованием первой части и частично завершается во втором анклаве с использованием второй части.

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

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

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

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

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

[00225] создание подписи для первого отчета аттестации путем выполнения по меньшей мере одной операции первой нативной платформы; и

[00226] создание подписи для второго отчета аттестации путем выполнения по меньшей мере одной операции второй нативной платформы.

[00227] В варианте осуществления, первая нативная платформа анклава соответствует архитектуре анклава Расширений безопасности программного обеспечения (SGX) от Intel и вторая нативная платформа анклава соответствует архитектуре анклава Виртуального безопасного режима (VSM) от Microsoft.

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

[00229] генерирование первого отчета аттестации путем выполнения по меньшей мере одной операции нативного SGX; и

[00230] генерирование второго отчета аттестации путем выполнения по меньшей мере одной операции нативного VMS.

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

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

[00233] верифицирование первой подписи первого отчета аттестации при помощи открытого ключа, ассоциированного с первой нативной платформой анклава; и

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

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

[00236] верифицирование первого сертификата подтверждения первой нативной платформы при помощи первого открытого ключа, ассоциированного с производителем первой нативной платформы анклава; и

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

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

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

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

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

[00242] прием первого отчета аттестации из первого анклава, реализованного на первой нативной платформе анклава;

[00243] извлечение первого значения идентичности анклава, ассоциированного с типом идентичности анклава, из первого отчета аттестации;

[00244] прием второго отчета аттестации из второго анклава, реализованного на второй нативной платформе анклава, причем первая нативная платформа анклава и вторая нативная платформа анклава являются разными;

[00245] извлечение второго значения идентичности анклава, ассоциированного с типом идентичности анклава, из второго отчета аттестации;

[00246] сравнение первого значения идентичности анклава со вторым значением идентичности анклава; и

[00247] выполнение вычислительной операции путем частичного завершения вычислительной операции в первом анклаве и частичного завершения вычислительной операции во втором анклаве.

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

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

[00250] копирование запечатанных данных из первого анклава во второй анклав; и

[00251] распечатывание запечатанных данных во второй анклав.

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

[00253] копирование первой части набора данных в первый анклав;

[00254] копирование второй части набора данных во второй анклав; и

[00255] причем вычислительная операция частично завершается в первом анклаве с использованием первой части и частично завершается во втором анклаве с использованием второй части.

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

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

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

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

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

[00261] создание подписи для первого отчета аттестации путем выполнения по меньшей мере одной операции первой нативной платформы; и

[00262] создание подписи для второго отчета аттестации путем выполнения по меньшей мере одной операции второй нативной платформы.

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

[00264] генерирование первого отчета аттестации путем выполнения по меньшей мере одной операции нативного SGX; и

[00265] генерирование второго отчета аттестации путем выполнения по меньшей мере одной операции нативного VMS.

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

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

[00268] верифицирование первой подписи первого отчета аттестации при помощи открытого ключа, ассоциированного с первой нативной платформой анклава; и

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

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

[00271] верифицирование первого сертификата подтверждения первой нативной платформы при помощи первого открытого ключа, ассоциированного с производителем первой нативной платформы анклава; и

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

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

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

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

[00276] В варианте осуществления, система содержит:

[00277] средство для приема первого отчета аттестации из первого анклава, реализованного на первой нативной платформе анклава;

[00278] средство для извлечения первого значения идентичности анклава, ассоциированного с типом идентичности анклава, из первого отчета аттестации;

[00279] средство для приема второго отчета аттестации из второго анклава, реализованного на второй нативной платформе анклава, причем первая нативная платформа анклава и вторая нативная платформа анклава являются разными;

[00280] средство для извлечения второго значения идентичности анклава, ассоциированного с типом идентичности анклава, из второго отчета аттестации;

[00281] средство для сравнения первого значения идентичности анклава со вторым значением идентичности анклава; и

[00282] средство для выполнения вычислительной операции путем частичного завершения вычислительной операции в первом анклаве и частичного завершения вычислительной операции во втором анклаве.

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

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

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

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

1. Способ определения эквивалентности анклавов, содержащий:

прием первого отчета аттестации из первого анклава, реализованного на первой нативной платформе анклава;

извлечение первого значения идентификатора анклава, ассоциированного с типом идентификатора анклава, из первого отчета аттестации;

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

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

определение того, что первое значение идентификатора анклава является тем же самым, что и второе значение идентификатора анклава; и

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

2. Способ по п.1, в котором вычислительная операция осуществляется последовательно с первым и вторым анклавами, при этом способ дополнительно содержит:

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

копирование запечатанных данных из первого анклава во второй анклав; и

распечатывание запечатанных данных во второй анклав.

3. Способ по п.1, в котором вычислительная операция осуществляется параллельно с первым и вторым анклавами, при этом способ дополнительно содержит:

копирование первой части набора данных в первый анклав;

копирование второй части набора данных во второй анклав; и

причем вычислительная операция частично выполняется в первом анклаве с использованием первой части и частично выполняется во втором анклаве с использованием второй части.

4. Способ по п.1, в котором:

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

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

5. Способ по п.1, в котором:

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

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

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

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

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

7. Способ по п.1, в котором первая нативная платформа анклава соответствует архитектуре анклава Расширений безопасности программного обеспечения (SGX) от Intel, и вторая нативная платформа анклава соответствует архитектуре анклава Виртуального безопасного режима (VSM) от Microsoft, при этом способ дополнительно содержит:

генерирование первого отчета аттестации путем осуществления по меньшей мере одной операции нативной SGX; и

генерирование второго отчета аттестации путем осуществления по меньшей мере одной операции нативной VMS.

8. Способ по п.1, в котором первая нативная платформа анклава и вторая нативная платформа анклава представляют собой разные версии одной и той же архитектуры анклава.

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

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

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

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

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

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

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

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

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

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

принимать первый отчет аттестации из первого анклава, реализованного на первой нативной платформе анклава;

извлекать первое значение идентификатора анклава, ассоциированного с типом идентификатора анклава, из первого отчета аттестации;

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

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

сравнивать первое значение идентификатора анклава со вторым значением идентификатора анклава; и

осуществлять вычислительную операцию путем частичного выполнения вычислительной операции в первом анклаве и частичного выполнения вычислительной операции во втором анклаве.

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

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

копировать запечатанные данные из первого анклава во второй анклав; и

распечатывать запечатанные данные во второй анклав.

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

копировать первую часть набора данных в первый анклав;

копировать вторую часть набора данных во второй анклав; и

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

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

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

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

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

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

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

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

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

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

18. Вычислительная система по п.12, при этом первая нативная платформа анклава соответствует архитектуре анклава Расширений безопасности программного обеспечения (SGX) от Intel, и вторая нативная платформа анклава соответствует архитектуре анклава Виртуального безопасного режима (VSM) от Microsoft, причем машиноисполняемые инструкции при их исполнении одним или более процессорами дополнительно предписывают вычислительной системе:

генерировать первый отчет аттестации путем осуществления по меньшей мере одной операции нативной SGX; и

генерировать второй отчет аттестации путем осуществления по меньшей мере одной операции нативной VMS.

19. Вычислительная система по п.12, при этом первая нативная платформа анклава и вторая нативная платформа анклава представляют собой разные версии одной и той же архитектуры анклава.

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

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

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

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

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

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

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

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

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

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

прием первого отчета аттестации от первого анклава, реализованного на первой нативной платформе анклава;

извлечение первого значения идентификатора анклава, ассоциированного с типом идентификатора анклава, из первого отчета аттестации;

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

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

сравнение первого значения идентификатора анклава со вторым значением идентификатора анклава; и

осуществление вычислительной операции путем частичного выполнения вычислительной операции в первом анклаве и частичного выполнения вычислительной операции во втором анклаве.