Запечатывание данных с помощью анклава запечатывания

Авторы патента:

КОСТА, Мануэль (US)

H04L63/061 - Передача дискретной информации, например телеграфная связь (пишущие машины B41J; телеграфные системы G08B; оптические телеграфные аппараты G08B,G08C; фототелеграфные системы G08C; шифровальные или дешифровальные устройства как таковые G09C; кодирование, декодирование или преобразование кода вообще H03M; устройства, применяемые как для телеграфной, так и для телефонной связи H04M; избирательные устройства H04Q)

G06F21/62 - Обработка цифровых данных с помощью электрических устройств (вычислительные машины, в которых часть вычислений осуществляется гидравлическими или пневматическими устройствами G06D; оптическими средствами G06E; автономные внешние вводные и выводные устройства G06K; компьютерные системы, основанные на специфических вычислительных моделях G06N; цепи полного /активного и реактивного/ сопротивления H03H)

G06F12/1408 - Выборка, адресация или распределение данных в системах или архитектурах памяти (хранение информации как таковое G11)

Владельцы патента RU 2759329:

МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи (US)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0028] Фиг. 23 является примерной блок–схемой для операции анклава хранилища ключей с закрытым в хранилище (vault–locked) ключом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] В примерном процессе 500 объединяется три процесса: процесс обмена ключами, который создает совместно используемый ключ SK; процесс аттестации для подтверждения клиенту 510 анклава того, что анклав на доверенной платформе 530; и выполняются безопасные вычисления. Совместно используемый ключ SK из первого процесса используется для сообщения ввода и вывода безопасных вычислений. При обмене ключами клиент анклава вычисляет 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) и подпись содержимого сообщения (Подпись_AK(Хеш(g^B), M)). Подпись содержимого сообщения может быть создана, например, программным обеспечением в безопасном контейнере 536 анклава, запрашивая доверенную платформы 530, на которой размещается анклав, для аттестации хеша из вычисленного g^B и удостоверения анклава. Доверенная платформа 530 может сделать это посредством предоставления подписи, используя ключ 532 аттестации (AK) платформы, чтобы создавать (Подпись_AK(Хеш(g^B), M)). В данном примере, удостоверением анклава является хеш M первоначального состояния 538, но возможны другие формулировки удостоверения. Данная подпись аттестации Подпись_AK(Хеш(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, создавая Зашифрованный_SK(секретный код/данные) перед отправкой их в сообщении 524 доверительной платформе 530. В других вариантах осуществления серверный код и данные 542, исполняемые в или используемые безопасным контейнером 536 анклава, могут происходить из других местоположений. Безопасные вычисления могут быть выполнены внутри безопасного контейнера 536 анклава, используя секретный код и/или данные 542, чтобы создавать результат 544 вычисления. Результаты 516 вычисления затем могут быть безопасно сообщены обратно клиенту 510 анклава посредством шифрования результатов с помощью совместно используемого ключа SK (Зашифрованные_SK(результаты)) до отправки их клиенту анклава в сообщении 526.

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

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

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

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

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

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

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

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

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

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

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

ПЛАТФОРМА И ПРИМИТИВЫ ПЛАТФОРМЫ АБСТРАКЦИИ АНКЛАВА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HANDLE

CreateEnclave(

_In_ PCWSTR enclavePath,

_In_ DWORD flEnclaveType,

_In_ DWORD dwFlags,

_In_reads_bytes_(dwInfoLength)

PCVOID enclaveInformation,

_In_ DWORD dwInfoLength,

_Out_opt_ PDWORD enclaveError

)

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

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

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

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

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

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

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

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

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

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

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

VOID

TerminateEnclave(

_In_ HANDLE hEnclave

)

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

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

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

typedef PVOID (*ENCPROC)(PVOID);

ENCPROC

GetProcAddress(

_In_ HMODULE hEnclave,

_In_ LPCTSTR lpProcName

)

BOOL

CallEnclaveIn(

_In_ ENCPROC pCallin,

_In_ PVOID pParameter,

_Out_ PVOID pReturn

)

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

// Вызов функции Callin для анклава.

ENCPROC pCallin=(ENCPROC) GetProcAddress(hEnclave,

«CallinExample»);

PVOID pParameter; // Указатель на память

if (NULL != pCallin)

{

CallEnclaveIn(pCallin, pParameter);

}

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

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

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

BOOL

CallEnclaveOut(

_In_ ENCPROC pCallout,

_In_ PVOID pParameter,

_Out_ PVOID pReturn

)

// Исхдящий вызов функции в хост–процессе

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

PVOID pParameter=// Указатель на память

CallEnclaveOut(pCallout, pSharedMemory);

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

BOOL RegisterCallOut(

_In_ ENCPROC pCallout,

_In_ LPCTSTR IpProcName)

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

BOOL GetCallOut(

_Out_ ENCPROC *pCallout,

_In_ LPCTSTR lpProcName)

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

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

struct SEALING_POLICY

{

ENCLAVE_ID_TYPE enclaveIdType;

};

[0094] Для каждого значения enclaveIdType анклав будет запечатан в ID отображения. Возможные типы удостоверения анклава (и значения 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

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

DWORD

EnclaveSeal(

_In_ SEALING_POLICY sealingPolicy,

_In_reads_bytes_opt_(dwPlaintextSize) LPCVOID pPlaintext,

_In_ DWORD dwPlaintextSize,

_In_reads_bytes_opt_(dwAuthdataSize) LPCVOID pAuthdata,

_In_ DWORD dwAuthdataSize,

_Out_writes_bytes_to_(dwSealedtextSize) LPVOID pSealedtext,

_Inout_ DWORD *dwSealedtextSize

)

DWORD

EnclaveUnseal(

_In_reads_bytes_opt_(dwSealedtextSize) LPCVOID pSealedtext,

_In_ DWORD dwSealedtextSize,

_In_reads_bytes_opt_(dwAuthdataSize) LPCVOID pAuthdata,

_In_ DWORD dwAuthdataSize,

_Out_writes_bytes_to_(dwPlaintextSize) LPCVOID pPlaintext,

_Inout_ DWORD *dwPlaintextSize

)

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

DWORD

CreateReport(

_In_reads_bytes_opt_(dwTargetInfoSize) PCVOID pTargetInfo,

_In_ DWORD dwTargetInfoSize,

_In_reads_bytes_opt_(dwAuthData) PCVOID pAuthData,

_In_ DWORD dwAuthData,

_Out_writes_bytes_opt_(*pReportSize) PVOID pReport,

_Inout_ PDWORD pReportSize,

_Out_opt_ PDWORD lpEnclaveError

)

DWORD

VerifyReport(

_In_reads_bytes_(dwReportSize)PCVOID pReport,

_In_ DWORD dwReportSize,

_Out_opt_ LPDWORD lpEnclaveError

)

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

DWORD CreateQuote(

_In_ GUID quoteType,

_In_ DWORD authDataSize,

_In_reads_bytes_opt_(authDataSize) const BYTE* authData,

_Out_ DWORD* quoteSize,

_Outptr_result_bytebuffer_opt_(*quoteSize) BYTE** quote

)

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

DWORD VerifyQuote(

_In_ DWORD quoteSize,

_In_reads_bytes_(quoteSize) const BYTE* quote,

_Out_ DWORD* reportSize,

_Outptr_result_bytebuffer_all_(*reportSize) BYTE** report

)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0117] Примитив CreateReport может быть использован, чтобы создавать отчет аттестации. Запрос CreateReport на создание отчета аттестации анклава может быть выполнен слоем абстракции как объяснено выше в отношении Фиг. 5 и 7. Касательно гипервизора с поддержкой анклава, слой абстракции может отправлять запрос нативной платформе посредством выполнения гипервызовов, которые меняют состояние исполнения на, например, контекст монитора безопасности, который имеет доступ к секретному ключу, такому как PrivAK 726 на Фиг. 7, который может быть использован для подписанных отчетов. Данный секретный ключ может быть доступен только для контекста монитора безопасности, если компьютер был загружен в работоспособной конфигурации как верифицируется с помощью журнала TCG на основе TPM. Монитор безопасности может сопровождать данные отчета удостоверением анклава, в отношении которого осуществляется аттестация.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

АБСТРАКТНОЕ УДОСТОВЕРЕНИЕ АНКЛАВА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЭКВИВАЛЕНТНОСТЬ УДОСТОВЕРЕНИЯ АНКЛАВА

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

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

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

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

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

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

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

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

РАСПРЕДЕЛЕННОЕ ЗАПЕЧАТЫВАНИЕ ДАННЫХ

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

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

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

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

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

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

DWORD

DistributedEnclaveSeal (

_In_ SEALING_POLICY sealingPolicy,

_In_reads_bytes_opt_(dwPlaintextSize) LPCVOID pPlaintext,

_In_ DWORD dwPlaintextSize,

_In_reads_bytes_opt_(dwAuthdataSize) LPCVOID pAuthdata,

_In_ DWORD dwAuthdataSize,

_Out_writes_bytes_to_(dwSealedtextSize) LPVOID pSealedtext,

_Inout_ DWORD dwSealedtextSize,

Set<EnclaveIdentity> SetOfTargetEnclaves

)

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

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

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

DWORD

DistributedEnclaveUnseal(

_In_reads_bytes_opt_(dwSealedtextSize) LPCVOID pSealedtext,

_In_ DWORD wSealedtextSize,

_In_reads_bytes_opt_(dwAuthdataSize) LPCVOID pAuthdata,

_In_ DWORD dwAuthdataSize,

_Out_writes_bytes_to_(dwPlaintextSize) LPCVOID pPlaintext,

_Inout_ DWORD dwPlaintextSize

Key KeyForData,

EnclaveIdentity Identity

)

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

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

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

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

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

АНКЛАВ ХРАНИЛИЩА КЛЮЧЕЙ

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

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

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

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

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

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

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

StoreKey([in] Keyname, [in] KeyType, [in] Key Value, [in] Policy)

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

[0178] Примерным прототипом функции GenerateKey является:

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

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

[0180] Примерным прототипом функции GetKey является:

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

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

[0182] Примерным прототипом функции DeleteKey является:

DeleteKey([in] keyName)

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

[0184] Примерным прототипом функции DeriveKey является:

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

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

[0186] Примерным прототипом функции Encrypt является:

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

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

[0188] Примерным прототипом функции Decrypt является:

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

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

[0190] Примерным прототипом функции Sign является:

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

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

[0192] Примерным прототипом функции VerifySignature является:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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] частично выполнять безопасную операцию обработки в анклаве–источнике; и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

принимают отчет аттестации источника для анклава–источника; и

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

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

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

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

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

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

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

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

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

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

частично выполняют безопасную операцию обработки в анклаве–источнике;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

принимать отчет аттестации источника для анклава–источника; и

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

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

осуществлять процесс аттестации между анклавом–источником и анклавом запечатывания; и

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

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

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

17. Система по п.11, при этом данные анклава включают в себя данные состояния анклава–источника.

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

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

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

частично выполнять безопасную операцию обработки в анклаве–источнике;

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

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

19. Система по п.18, в которой инструкции дополнительно предписывают, по меньшей мере:

осуществлять процесс аттестации между анклавом запечатывания и анклавом–источником;

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

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

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

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

Способ маскирования структуры сети связи // 2759152

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

Обновление конфигурации сетевых сегментов // 2759094

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

Автоматическая инициализация iot-устройств // 2759011

Изобретение относится к технологии Интернет вещей ("IoT"), которая является применимой при инициализации IoT-устройств автоматическим способом без ручных действий. Технический результат заключается в обеспечении возможности автоматического обновления микропрограммного обеспечения, принятого из IoT-концентратора, без необходимости привязки к пользователю.

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

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

Служба iot-инициализации // 2758594

Изобретение относится к технологии, направленной на инициализацию устройств в IoT-окружении. Техническим результатом является обеспечение возможности инициализации IoT-устройств в IoT-концентраторе.

Обнаружение критических линий связи в ячеистых сетях bluetooth // 2758593

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

Способ формирования сигнатуры для обнаружения спама // 2758358

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

Система управления защитой информации // 2757927

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

Способ адаптивного выбора маршрута в узле беспроводной ячеистой сети связи, соответствующее устройство для выполнения способа адаптивного выбора маршрута и соответствующая компьютерная программа // 2757663

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

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

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