РАСПЕЧАТЫВАНИЕ ДАННЫХ С ЗАПЕЧАТЫВАЮЩИМ АНКЛАВОМ Российский патент 2021 года по МПК G06F21/62 

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

[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] Раскрыта модель абстрагирования для анклавов, которая упрощает разработку клиентов анклава и программного обеспечения, которое исполняется в анклаве. Модель абстрагирования может представлять собой упрощение и унификацию нативных анклавных платформенных архитектур, таких как Intel SGX и Microsoft VSM. Программный компонент уровня абстрагирования может транслировать связь между клиентом анклава и одной или более нативными платформами, между программным обеспечением в анклаве и одной или более нативными анклавными платформами и между программным обеспечением в анклаве и клиентом анклава. Такая платформа абстрагирования может обеспечивать выгоду, заключающуюся в предоставлении возможности исполнения одной версии программного обеспечения анклава и клиентского программного обеспечения анклава поверх нескольких нативных анклавных платформ, таких как SGX и VSM. В дополнение к упрощению задачи написания программного обеспечения для анклавов и клиентов анклава, она обеспечивает возможность конечным пользователям анклавов выполнять анклав и клиентское программное обеспечение анклава на компьютере, который поддерживает любую поддерживаемую нативную анклавную архитектуру, без необходимости находить версии как анклава, так и клиентского программного обеспечения анклава, которые индивидуально адаптированы к нативной анклавной платформе конкретного компьютера.

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

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

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

[0033] Раскрытая модель абстрагирования включает в себя интерфейсы программных компонентов, такие как интерфейс прикладного программирования (API) или двоичный интерфейс приложений (ABI), которые могут упрощать разработку программного обеспечения анклавов и хостов анклава. API представляет собой набор определений вложенных процедур программирования, протоколов и инструментов для создания программного обеспечения. API может задавать вводы и выводы программного компонента, типы данных, используемые посредством программного компонента, и функциональность или операцию программного компонента, независимо от конкретной реализации программного компонента. API может задаваться на высокоуровневом машинном языке, таком как C, C++, C# и т.п. Формализованное определение API может упрощать взаимодействие между программными компонентами, например, двумя программными компонентами, написанные в различные моменты времени или посредством различных авторов. API может быть формализован частично с языком описания интерфейса (DDL), таким как язык описания интерфейса 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 для передачи сообщений с гарантией конфиденциальности. Гарантия конфиденциальности предоставляет некоторый уровень гарантии того, что связь между двумя сторонами, такими как Anne 210 и Ben 230 в этом примере, остается скрытой от третьих сторон, когда сообщения проходят через открытую или незащищенную среду связи, такую как сеть 218. В этом примере, Anne 212 хочет отправлять конфиденциальное сообщение Ben 230. Блок 212 сообщений, содержащий конфиденциальные данные, шифруется с использованием открытого (общедоступного) ключа 216 посредством операции шифрования 214. Операция шифрования 214, например, может представлять собой счетчик с аутентификацией Галуа по усовершенствованному стандарту шифрования (AES-CGM), но также может представлять собой любую операцию шифрования, известную специалистам в области техники цифровой криптографии. Зашифрованный блок 220 может проходить через сеть 218 к Ben, у которого зашифрованный блок 234 дешифруется с помощью закрытого (конфиденциального) ключа 236, чтобы формировать незашифрованный блок 232 сообщений для Ben. За счет тщательного выбора ключей и алгоритмов шифрования, как известно в области техники шифрования компьютерных данных, сообщение может оставаться конфиденциальным при прохождении через открытую сеть.

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

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

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

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

[0047] На фиг. 4, сообщение 414 Anne может отправляться по открытой сети 430 в качестве сообщения 436 наряду с одноразовым номером 434 и временной меткой 432. Одноразовый номер 434 формируется посредством криптографически защищенного генератора 426 псевдослучайных чисел (CSPRNG), и временная метка 432 формируется посредством синхронизированного тактового генератора 424. Предусмотрено множество CSPRNG-систем, которые известны для специалистов в области техники цифровой криптографии. Синхронизированный тактовый генератор 424 на стороне Anne сети 430 синхронизируется с синхронизированным тактовым генератором 480 на стороне Ben сети. На стороне Ben, когда сообщение 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 Anne, и подпись, содержащая подписанный хеш сообщения 414, должна быть включена наряду с временной меткой 432, одноразовым номером 434 и сообщением 436.

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

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

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

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

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

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

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

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

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

[0058] Фиг. 6 иллюстрирует примерный протокол 600 обмена ключами Диффи-Хеллмана (DKE). DKE представляет собой один примерный процесс для установления совместно используемого ключа K через канал связи, имеющий только гарантию целостности; могут использоваться другие процессы для создания совместно используемых ключей, известных в области техники цифровой криптографии. В примере DKE по фиг. 6, секретный ключ K совместно используется между Anne 610 и Ben 650 вообще без передачи K явно по открытой (незащищенной) среде связи между Anne 610 и Ben 650. До того, как процесс начинается, 1) большое простое число p и 2) генератор g в Zp могут устанавливаться и быть известными для Anne и Ben. Процесс затем начинается с выбора, посредством Anne и с Ben, случайного числа между 1 и p. Случайное число Anne составляет A, выбранное в поле 612, и случайное число Ben составляет B, выбранное в поле 652. Anne использует свое случайное число, чтобы вычислять g^A mod p в поле 614, и передает эту величину в поле 616, которая принимается посредством Ben в поле 656. Ben использует свое случайное число, чтобы вычислять g^B mod p в поле 654, которое передается в поле 656 в Anne и принимается в поле 618. Anne может формировать совместно используемый ключ K в качестве (g^B mod p)^A=g^AB, mod p в поле 620, и Ben может формировать совместно используемый ключ K в качестве (g^A mod p)^B=g^AB mod p в поле 660. Чтобы предотвращать атаки по технологии "злоумышленник посередине", связь между Anne и Ben по незащищенной сети из полей 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] Платформа и примитивы абстрагирования анклава

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

[0066] Использование этих программных интерфейсов 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.

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

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

[0069] Фиг. 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 основаны на различных анклавных архитектурах, таких как Intel SGX или Microsoft VSM. Как показано на фиг. 8, клиент 916 анклава 914 может непосредственно представлять собой анклав, и нативная платформа 918 может включать в себя аппаратные и/или программные компоненты.

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

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

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

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

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

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

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

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

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

[0079] CreateEnclave представляет собой примерный метод для создания экземпляра анклава. Метод CreateEnclave может описываться с помощью псевдокода:

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

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

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

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

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

- EnclaveInformation: могут быть предусмотрены необязательные входные параметры для конфигурации во время выполнения анклава.

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

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

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

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

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

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

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

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

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

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

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

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

//Внешний вызов в функцию в хост-процессе

ENCPROC pCallout=(ENCPROC) 0xF00; //адрес в некоторой функции в хосте

PVOID pParameter=//указатель на запоминающее устройство

CallEnclaveOut(pCallout, pSharedMemory);

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

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

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

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

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

ENCLAVE_EXACTHASH

ENCLAVE_INSTANCEHASH://запечатывание с использованием MRENCLAVE для SGX, IMAGE HASH для VSM

ENCLAVE_IMAGEIDS://не поддерживается в SGX, использует IMAGE IDS для VSM

ENCLAVE_FAMILYID://использует PRODUCTID для SGX, FAMILY ID для VSM

ENCLAVE_AUTHORID://использует MRSIGNER для SGX, AUTHOR ID для VSM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Абстрактные идентификационные данные анклава

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эквивалентность идентификационных данных анклава

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

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

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

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

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

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

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

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

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

[0158] Фиг. 19 является блок-схемой примерной системы распределенного запечатывания данных. Запечатывание данных может быть распределено по нескольким анклавам, причем эти анклавы размещены на отдельных нативных анклавных платформах и/или на отдельных компьютерах. Как пояснено выше, примитивы абстрагирования EnclaveSeal и EnclaveUnseal могут запечатывать и распечатывать данные для анклава с использованием ключа, привязанного к нативной анклавной платформе или к физическому компьютеру, на котором выполняется анклав. Это может ограничивать распечатывание только анклавами, размещенными на одном и том же компьютере или одном и том же экземпляре нативной анклавной платформы. Фиг. 19 иллюстрирует систему распределенного запечатывания данных, в которой запечатывание или распечатывание данных может иметь место на нативной платформе или компьютере, отличной от нативной платформы и компьютера, размещающих анклав. Система 1900 включает в себя компьютеры 1910, 1930, 1950, при этом сеть 1902 соединяет компьютеры 1910 и 1930, и сеть 1904 соединяет компьютеры 1930 и 1950. Компьютер 1910 размещает исходный анклав 1912, из которого могут получаться данные, которые должны запечатываться; компьютер 1930 размещает распределенный запечатывающий анклав 1932 (DSE) для обслуживания запросов на распределенное запечатывание и распечатывание; и компьютер 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 или в файловой системе жесткого диска.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GenerateKey([in] keyName, [in] key Type, [in] Policy)

[0180] Generate Key формирует новый ключ определенного типа и поддерживает его сохраненным в хранилище ключей, т.е. ключ вообще не выходит из хранилища ключей.

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

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

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

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

DeleteKey([in] keyName)

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

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

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

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

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

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

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

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

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

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

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

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

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

[0193] Примерный прототип функции Verify Signature является следующим:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0209] - извлечение целевых идентификационных данных целевого анклава из целевого отчета об аттестации;

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

[0211] - отправку данных анклава из запечатывающего анклава в целевой анклав.

[0212] В варианте осуществления, первая нативная анклавная платформа находится на первом компьютере, и вторая нативная анклавная платформа размещается на втором компьютере.

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

[0214] - прием исходного отчета об аттестации исходного анклава; и

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

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

[0217] В варианте осуществления, отправленные данные анклава шифруются, и дополнительно содержит:

[0218] - процесс аттестации между запечатывающим анклавом и целевым анклавом;

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

[0220] - при этом данные анклава, отправленные в целевой анклав, представляют собой зашифрованные данные анклава.

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

[0222] - прием, из целевого анклава, ключа выбора, указывающего один из множества наборов данных анклава.

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

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

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

[0226] В варианте осуществления, первая нативная анклавная платформа находится на первом компьютере, и вторая нативная анклавная платформа размещается на втором компьютере.

[0227] В варианте осуществления, принимаемые данные анклава шифруются, и дополнительно содержит:

[0228] - процесс аттестации между запечатывающим анклавом и целевым анклавом; и

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

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

[0231] - продолжение операции защищенной обработки в целевом анклаве с использованием данных состояния исходного анклава.

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

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

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

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

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

[0237] - извлечение целевых идентификационных данных целевого анклава из целевого отчета об аттестации;

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

[0239] - отправку данных анклава из запечатывающего анклава в целевой анклав.

[0240] В варианте осуществления, первая нативная анклавная платформа находится на первом компьютере, и вторая нативная анклавная платформа размещается на втором компьютере.

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

[0242] - прием исходного отчета об аттестации исходного анклава; и

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

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

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

[0246] - процесс аттестации между запечатывающим анклавом и целевым анклавом;

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

[0248] - при этом данные анклава, отправленные в целевой анклав, представляют собой зашифрованные данные анклава.

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

[0250] - прием, из целевого анклава, ключа выбора, указывающего один из множества наборов данных анклава.

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

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

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

[0254] В варианте осуществления, первая нативная анклавная платформа находится на первом компьютере, и вторая нативная анклавная платформа размещается на втором компьютере.

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

[0256] - процесс аттестации между запечатывающим анклавом и целевым анклавом; и

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

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

[0259] - продолжение операции защищенной обработки в целевом анклаве с использованием данных состояния исходного анклава.

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

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

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

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

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

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

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

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

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

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

извлекают целевой идентификатор целевого анклава из целевого отчета об аттестации;

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

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

2. Способ по п.1, в котором первая нативная анклавная платформа находится на первом компьютере и вторая нативная анклавная платформа размещается на втором компьютере.

3. Способ по п.1, в котором разрешенный список представляет собой список типов абстрактных идентификаторов, при этом способ дополнительно содержит этапы, на которых:

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

извлекают разрешенное значение идентификатора из исходного отчета об аттестации исходного анклава и тип абстрактного идентификатора в разрешенном списке; и

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

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

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

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

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

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

7. Способ по п.6, в котором первая нативная анклавная платформа находится на первом компьютере, а вторая нативная анклавная платформа размещается на втором компьютере.

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

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

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

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

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

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

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

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

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

12. Система по п.11, в которой первая нативная анклавная платформа находится на первом компьютере, а вторая нативная анклавная платформа размещается на втором компьютере.

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

приема исходного отчета об аттестации исходного анклава; и

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

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

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

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

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

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

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

17. Система по п.16, в которой первая нативная анклавная платформа находится на первом компьютере, а вторая нативная анклавная платформа размещается на втором компьютере.

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

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

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