БЕЗОПАСНЫЙ ТРАНСПОРТ ЗАШИФРОВАННЫХ ВИРТУАЛЬНЫХ МАШИН С НЕПРЕРЫВНЫМ ДОСТУПОМ ВЛАДЕЛЬЦА

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

[0001] Взаимная связь вычислительных систем содействовала появлению распределенных вычислительных систем, например так называемых «облачных» компьютерных систем. В данном описании «облачные вычисления» могут быть системами или ресурсами для обеспечения повсеместного удобного сетевого доступа по требованию к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, хранилищ, приложений, служб и т.д.), которые могут быть обеспечены и выделены при сокращенных трудозатратах на управление или на взаимодействие с провайдером услуг. Облачная модель может состоять из различных характеристик (например, самообслуживание по требованию, широкий доступ к сети, объединение ресурсов, быстрая адаптация, измеряемые услуги и т.д.), моделей обслуживания (например, программное обеспечение как услуга («SaaS»), платформа как услуга («PaaS»), инфраструктура как услуга («IaaS») и моделей развертывания (например, частное облако, общественное облако, общее облако, гибридное облако и т.д.).

[0002] Облачные и удаленные сервисные приложения являются преобладающими. Такие приложения размещаются на общих или частных удаленных системах, таких как облака, и обычно предлагают набор сетевых служб для обратной и прямой связи с клиентами.

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

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

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

Краткое описание

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

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

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

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

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

[0010] Фиг. 1 показывает зашифрованный набор данных и пакет с зашифрованными ключами для дешифрирования зашифрованного набора данных;

[0011] Фиг. 2 показывает развертывание зашифрованных виртуальных машин;

[0012] Фиг. 3 показывает аттестационные операции для хостов и целевых объектов;

[0013] Фиг. 4 показывает процесс развертывания виртуальной машины на хосте;

[0014] Фиг. 5 показывает процесс миграции виртуальной машины; и

[0015] Фиг. 6 показывает способ управления зашифрованными наборами данных.

Подробное описание

[0016] Простая иллюстрация варианта осуществления настоящего изобретения показана со ссылкой на Фиг. 1. Фиг. 1 показывает зашифрованный набор 101 данных. Этот зашифрованный набор 101 данных может быть может быть дешифрирован с использованием транспортного ключа 102. В показанном примере множественные копии транспортного ключа 102 зашифрованы с использованием схем шифрования, специфичных для конкретного пользователя. Так, например, первая копия 102-0 зашифрована для владельца таким образом, что владелец набора 101 данных может дешифрировать копию, а другие субъекты не могут. Фиг. 1 далее показывает дополнительные копии, где каждая из n дополнительных копий со 102-1 до 102-n зашифрованы для хранителей (например, субъектов, которые могут принимать или хранить набор данных для владельца), так что каждый хранитель может дешифрировать свою копию, а другие субъекты не могут. В некоторых вариантах осуществления это может быть достигнуто путем использования асимметричных технологий шифрования. Так, например, первая копия 102-0 зашифрована с использованием общего ключа для владельца, так что владелец может использовать свой закрытый ключ для дешифрирования первой копии 102-0. Похожим образом копия 102-1 может быть дешифрирована с использованием общего ключа для первого хранителя, так что первый хранитель может дешифрировать копию 102-1 с использованием закрытого ключа хранителя. Похожее шифрование и дешифрирование может быть выполнено для остальных копий хранителей.

[0017] Эти копии упаковываются вместе и подписываются защитной подписью 103 с использованием криптографического ключевого хеширования или цифровой подписью, чтобы гарантировать, что пакет не был подделан. Охранник - субъект, который подписывает копии - может быть, например, владельцем или хранителем, и может меняться при передаче или перешифровании зашифрованного набора 101 данных. Защитная подпись может криптографически связывать пакет вместе, чтобы гарантировать, что набор 101 данных не может быть предоставлен неавторизованным субъектам. Пакет также включает в себя подпись 104 транспортного ключа, которая является формой аутентификации, создаваемой путем выполнения криптографического хеширования или другой функцией (такой как функция кода аутентификации сообщения (КАС)) транспортного ключа, который может быть использован как доказательство знания транспортного ключа хранителем.

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

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

[0020] Пример виртуальной машины, показанный на Фиг. 2, показывает арендатора 200, облачную службу 201, диспетчера 202 виртуальной машины, хранилище 203 виртуальной машины, агента 205 миграции, KDS 206 и хост 207. В показанном примере виртуальная машина 204 зашифрована, как показано поперечной штриховкой виртуальной машины в хранилище 203 виртуальной машины. Хранилище 203 виртуальной машины является системой хранения, обслуживаемой провайдером 201 облачных услуг. Арендатор 200 предоставляет виртуальные машины провайдеру 201 облачных услуг, который может хранить их в хранилище 203 машин. Арендатор 200 может шифровать виртуальные машины, либо виртуальные машины могут быть зашифрованы другими субъектами.

[0021] Агент 205 миграции (или другой подходящий субъект, например, арендатор 200) предоставляет две копии ключа, необходимые для дешифрирования зашифрованной виртуальной машины 204. Ключи могут предоставляться агенту миграции арендатором 200 или KDS 206, либо другими доверенными субъектами. Одна копия 209 ключа 208 шифруется с использованием общего ключа арендатора 200, в то время как другая копия 210 ключа 208 шифруется с использованием общего ключа KDS 206. Могут быть реализованы различные альтернативные варианты.

[0022] Ключ 208 может быть использован для дешифрирования VM 204 самостоятельно. Как альтернатива, ключ 208 может быть использован для дешифрирования модуля виртуальной доверенной платформы (vTPM) (как будет подробнее разъяснено ниже), который может быть использован для дешифрирования VM 204. Однако, это все еще попадает в объем того, что было описано, когда шифруется VM. В некоторых вариантах осуществления VM 204 может быть зашифрована путем шифрования виртуального жесткого диска (VHD) и/или метаданных виртуальной машины 204.

[0023] Если арендатор 200 желает извлечь и прочитать зашифрованную VM 204, арендатор 200 может просто запросить зашифрованную VM 204 обратно из хранилища 203 виртуальной машины и использовать ее закрытый ключ для дешифрирования первой копии 209 ключа 208, а затем использовать ключ 208 для доступа к VM 204.

[0024] Для развертывания VM 204 на хосте 207, VM 204 посылается на хост 207. Дополнительно, пакет 212, содержащий зашифрованные копии 209 и 210 ключа 208, посылается на хост 207.

[0025] Пакет 212 подписан и защитной подписью, и подписью для ключа 208.

[0026] Хост 207 посылает запрос 211 и пакет 212 на KDS 206. В качестве альтернативы, одновременно с посылкой запроса 211 на KDS 206 хост 207 может также послать вторую копию 210 ключа 208 на KDS. В качестве альтернативы, KDS 206 может принять вторую копию 210 из другой службы и может хранить вторую копию 210 в ожидании запроса 211.

[0027] В некоторых вариантах осуществления может быть сделано определение, что хост 207 соответствует определенным характеристикам, и если хост 207 соответствует определенным характеристикам, тогда KDS 206 может получить доступ к ключу 208, и он может быть отправлен обратно на хост 207. Например, варианты осуществления могут потребовать, чтобы хост 207 соответствовал определенным медицинским требованиям, например, что на хосте может потребоваться работа определенного программного обеспечения (или определенной версии программного обеспечения), что он должен иметь определенные настройки конфигурации, иметь соответствующую загрузочную запись. Хост затем может использовать свой ключ 208 для отпирания VM 204, позволяя VM 204 быть развернутой на хосте 207 (как показано при помощи незаштрихованной версии VM 207).

[0028] Следующее иллюстрирует еще одну дополнительную деталь. В процессах, требующих использования Службы распределения ключей, используется структура данных, называемая «дескриптор защиты», или PD. Главной функцией дескрипторов защиты является криптографическая упаковка ключа шифрования (например, ключа 208), называемого транспортным ключом. Эта упаковка гарантирует, что доступ к этому ключу предоставляется только авторизованным субъектам. KDS не знает или не заботится, какие данные защищает транспортный ключ.

[0029] В качестве иллюстрации владелец виртуальной машины (VM) может желать развернуть VM на хосте. Эта VM содержит два набора данных - секцию метаданных и набор виртуальных жестких дисков (VHD). Виртуальные жесткие диски зашифрованы с использованием соответствующей технологии шифрования, такой как BitLocker от компании Microsoft Corporation из Редмонда, Вашингтон. Полный ключ шифрования (FVEK), используемый для дешифрирования первичного VHD, защищен модулем виртуальной доверенной платформы (vTPM), состояние которого зашифровано и хранится как часть метаданных вместе с PD. Состояние vTPM непосредственно зашифровано с использованием ключа, упакованного PD. Это позволяет владельцу защитить VM от несанкционированного доступа к VM.

[0030] Когда хосту у провайдера услуг размещения (хостера) требуется развернуть VM, он извлекает PD для vTPM из метаданных и посылает его в KDS. Если хост авторизован для ключа vTPM, KDS возвратит в окружение службы доверенного выполнения (TEE), например, в подсистему безопасности хоста, ключ, с которым может быть дешифрирован vTPM. Множество различных подсистем безопасности могут использоваться совместно или альтернативно. В одном варианте осуществления эта подсистема может быть реализована как функции, выполняемые в ядре VM хоста. В другой реализации она может выполняться в гипервизоре. В других вариантах осуществления она может быть реализована как отдельное адресное пространство, выделяемое гипервизором с использованием возможностей адресации памяти процессора (иногда упоминаемая здесь как режим виртуальной безопасности (VSM)). В других вариантах осуществления она может быть реализована как отдельная область исполнения, обеспечиваемая процессором (такая как TrustZone в ARM-архитектуре, возникающая SGX-способность, описанная корпорацией Интел из Санта Клара, Калифорния, или технология модуля доверенной платформы (TPM). Эти различные реализации могут предложить схожую функциональность, такую как способность выполнять криптографические операции, хранить учетные данные, проверять целостность кода или данных и защищать секреты. Однако они могут различаться по свойствам безопасности, которую они предлагают.

[0031] Как альтернатива, в некоторых вариантах осуществления, если к виртуальной машине произведен доступ из окружения VM владельца, KDS не задействуется в выпуске ключа, поскольку PD содержит упаковку транспортного ключа, который позволяет выполнять прямой доступ владельцем VM. Примечательно, что KDS может в некоторых вариантах осуществления поддерживаться облачной службой 201, но в других вариантах осуществления может поддерживаться третьей стороной.

[0032] Субъекты, авторизованные для получения ключа, являются либо «владельцем», либо нулем, либо множеством «хранителей». Главное различие между двумя в том, что в некоторых вариантах осуществления владельцам дано создавать оригинальный PD; также в некоторых вариантах осуществления только владельцы могут быть отражены в PD при помощи самоподписанных сертификатов. Конструкция PD уделяет внимание обнаружению мошенников: уделяется внимание, чтобы гарантировать, что неавторизованный субъект не может представиться как владелец или как хранитель PD. Наконец, приняты резервные меры для восстановления после компрометации ключа. Например, это может быть достигнуто путем использования ключей с различным временем жизни, где владелец представлен долговременным ключом с высокой степенью защиты, и этот ключ используется для подписи более кратковременных ключей пользователя, которые не должны предлагать такой же уровень защиты. Эти кратковременные ключи становятся фактически охранными (т.е. владелец как хранитель).

[0033] Варианты осуществления могут также включать автоматический оборот ключей. Каждый раз, когда KDS 206 запрашивается вскрыть PD, это происходит потому, что некоторый субъект (например, хост Fabric) пытается читать зашифрованную часть данных. Такая операция ассоциируется с процессом «входа», таким как миграция в VM или создание новой VM из некоторых зашифрованных «данных настройки». KDS 206 отвечает на такие запросы с требуемым ключом, также как и с другим PD - тем, который используется в последовательном процессе «выхода», обычно означая миграцию VM к другому хосту 213 или к автономному хранилищу (например, к хранилищу 203 машин). Такая настройка гарантирует, что с KDS 206 необходимо будет контактировать только однажды - при входе, и это происходит тогда, когда оценивается здоровье хоста. Дополнительная оценка хоста при выходе не производится, если с KDS не было контактирования более одного раза. Однако варианты осуществления могут разрешать множество круговых путей к KDS 206, когда при этом не случается никакого вреда. Оценка хоста может выполняться каждый раз, когда варианты осуществления контактируют с KDS. Так, если с KDS не было контакта при выходе, также не было и оценки хоста при выходе.

[0034] В некоторых вариантах осуществления в любой момент времени только один субъект, владелец или хранитель, обозначается «хранителем» PD - субъектом, который создал и подписал PD (например, как показано на 103). Когда PD перемещается от владельца к хранителю и от одного хранителя к другому, изменяется опека. Однако опека будет оставаться той же самой, пока та же KDS 206 обрабатывает данный PD. Любой хранитель или владелец может «захватить» существующий PD (стать его опекуном) без привлечения текущего хранителя.

[0035] Следующее показывает математически строгую иллюстрацию одного примера. Данный раздел будет использовать следующую систему обозначений:

K₀, K_i, ST, TT - субъекты, задействованные в процессах (арендатор K₀, хранитель K_i, источник ST TEE, объект TT TEE)

N_EPub, N_EPri - общие и закрытые ключи шифрования некоторого субъекта N; N_E является сокращением N_EPub )

N_SPub, N_SPri - общие и закрытые ключи шифрования некоторого субъекта N; N_S является сокращением N_SPub )

- сертификат субъекта N (владельца или хранителя), определяющий имя субъекта SN и его общий ключ (подписи или шифрования) N_K, выпущенный субъектом M путем подписывания своим закрытым ключом N_SPri (ключ подписи может подписывать соответствующий общий ключ для самоподписанного сертификата)

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

ε(K)[M] - сообщение M, зашифрованное с помощью ключа K; K может быть симметричным или асимметричным в зависимости от контекста

α(K)[M] - сообщение M, аутентифицированное с помощью симметричного ключа K

σ(K)[M] - сообщение M, подписанное с помощью асимметричного ключа K

- каскадное соединение сообщений M1 и M2.

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

TK-e:= KDF(TK, «e») -полученный код шифрования (KDF означает функцию получения ключа (KDF, Key Derivation Function). «е» является входом в KDF, используемой для, например, различения получения ключа шифрования от получения, например, ключа подписи. Однако необходимо заметить, что это только один пример, и также может быть использован любой другой подходящий вход).

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

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

TK-a:= KDF(TK, «a») - полученный код аутентификации

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

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

- зашифрованная и аутентифицированная полезная нагрузка P

Зашифрованная и аутентифицированная полезная нагрузка P (такая как состояние vTPM), созданная с использованием ключа шифрования и его компаньона - ключа аутентификации - в соответствии с транспортным ключом TK

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

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

- ключ, упакованный владельцем

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

Только запись владельца может содержать неделегированный (самоподписанный) сертификат поверх ключа подписи

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

() - ключ, упакованный хранителем

Это тот же транспортный ключ, зашифрованный для хранителя VM

K_j - это «текущий» хранитель, для которого зашифрован транспортный ключ

K_i - это «предыдущий» хранитель в цепочке (i=0 для владельца), который делегирует K_j права хранителя

Для VM может быть ноль или более хранителей, и таким образом ноль и более сообщений типа C внутри PD.

[0039] Различные упаковки транспортного ключа комбинируются в комплект, показанный ниже как матрица, где каждая строка содержит число связанных информационных записей, соответствующих владельцу или хранителю. Владельцы идентифицируются как таковые (с использованием буквы «о»). Текущий хранитель как таковой помечен звездочкой. В показанном ниже примере PD стоит в форме, в которой он существует при создании владельцем для использования KDS 206. Комбинация различных упаковок этого ключа является сообщением типа D. Сообщение, сгенерированное владельцем для одного хранителя, будет выглядеть как:

KDS 206 может использовать это сообщение и добавить дополнительного хранителя(ей), в результате в PD будет выглядеть как:

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

,

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

[0041] Наконец, сообщение типа F является собственно «PD» - объединение сообщений D и E:

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

[0043] Типичный процесс включения PD поверх некоторой полезной нагрузки включает посылку хостом PD F_i входного ключа TK_i на KDS и ответа KDS двумя порциями информации:

1) упаковка двух транспортных ключей (входа и выхода - TK_i и TK_e) для использования TEE хоста. Эта упаковка включает аутентифицированное шифрование объединения ключей входа и выхода:

TW - ключ упаковки, сгенерированный KDS

TW-e, TW-a - ключи аутентификации и шифрования, полученные из TW

2) Ключ выхода PD F_e, построенный вокруг TK_e для включения с входной полезной нагрузкой. Это не предназначено в TEE хоста и может быть вскрыто только владельцем или одним из хранителей.

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

[0045] Как уже упоминалось, KDS 206 не знает тип полезной нагрузки, которую защищает большой двоичный объект типа F. Эта полезная нагрузка может быть состоянием vTPM, обеспечивая информацию для VM, или чем-то совершенно иным. В некоторых вариантах осуществления полезная нагрузка зашифрована с использованием ключа шифрования, полученного из транспортного мастер-ключа, и аутентифицирована с использованием соответствующего ключа аутентификации (как показано сообщениями типа A). Однако могут быть сконструированы другие механизмы получения ключа для получения того же или сходного общего эффекта.

[0046] В некоторых вариантах осуществления каждый хост (например, хосты 207 и 213) завершают аттестацию до того, как они смогут либо разместить VM, либо участвовать в процессе миграции. После успешного завершения аттестации службой 214 аттестации хоста (HAS) для этого хоста выпускается сертификат здоровья. В некоторых вариантах осуществления ключ в этом сертификате является общим ключом шифрования TEE для доверенной подсистемы хоста. Хост впоследствии предоставляет сертификат здоровья в KDS 206, которая отвечает путем шифрования чувствительных данных (например, ключ шифрования vTPM) на TEE хоста. Заметим, что в этом случае нет аутентификации с сертификатом здоровья и KDS 206 не требуется никакого доказательства владения для аутентификации хоста. Проще говоря, хост свободен представить любой сертификат, который он желает, но если он не имеет соответствующего закрытого ключа, он не сможет распознать ответ, который он принимает от СРВ.

[0047] Ссылка теперь сделана на Фиг. 3, который иллюстрирует процесс 300 для одного очень специфичного примера. Применительно к Фиг. 3:

1. Хост инициирует аттестацию путем обращения к службе аттестации

2. Служба аттестации выдает запрос. В вариантах осуществления, использующих технологию TPM, это может быть запрос чтения регистра конфигурации платформы (PCR). На Фиг. 3 это показано как единичный обмен запрос/ответ, но на практике он скорее всего будет иметь два этапа: один для установления сессии и другой - для удовлетворения запроса.

В вариантах осуществления, использующих устройства TPM 2.0, возможны два различных режима аттестации - один является традиционной ссылкой доверенной группы компьютеров (TCG) через одноразовый номер, и другой - «прямое чтение PCR» через сессию с добавленной аутентификацией. Заметим, что это просто один пример. В других вариантах осуществления, например, может быть использован TPM 1.2, хотя функция прямого чтения PCR может быть не доступна.

3. Устройство удовлетворяет запрос чтения PCR путем предоставления значений требуемых PCR вместе с журналом TCG.

4. Устройство соединяет «запрос аттестации», который содержит ответ на запрос чтения PCR.

5. Служба проверяет предоставленный журнал TCG, значения PCR и дополнительно консультирует политики для определения того, является ли здоровым содержимое журнала TCG, предоставленного хостом (в дополнение к простому соответствию значений PCR).

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

7. Этот аттестат здоровья хранится хостом для последующего использования при достижении VM и процессах миграции.

[0048] Хостинг и миграция виртуальной машины

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

От одного хоста к другому в области одного и того же хранителя

От владельца к хранителю

От одного хранителя к другому

От хранителя обратно к владельцу.

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

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

ключи шифрования vTPM

состояние vTPM

метаданные VM

один или более VHD

состояние памяти VM

состояние устройства VM.

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

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

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

[0055] Предполагается, что VHD должен быть зашифрован с использованием FVEK, защищенным vTPM, поэтому архитектура миграции не делает дополнительной попытки для их защиты. В дополнение, для арендатора 200 возможно загрузить с провайдера 201 услуг VM, которая принадлежит этому арендатору и выполняет это непосредственно, т.е. без включения KDS 206.

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

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

1. (ОПЦИОНАЛЬНО - только для случаев, где память 202 VM (VMM) организует процесс миграции). Служба управления VMM, такая как SCVMM, доступная от Корпорации Майкрософт из Редмонда, Вашингтон, готова и выполняется, доступная серверам источника и приемника.

2. Служба 206 распределения ключей и служба 214 аттестации хоста готовы.

3. Сервер хоста-источника (например, хост 207) имеет готовую и работающую гостевую виртуальную машину 204.

4. В случае миграции сервер хоста-получателя (например, хост 213) является способным для TEE, готов и работает.

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

1. И хост источника (например, хост 207), и хост получателя (например, хост 213) закончили аттестацию (например, как описано выше).

2. Хост получателя (например, хост 213) удовлетворяет входной миграционной политике, в противном случае он не подходит для принятия состояния VM - лучше установить это заранее, хотя строгое следование хостом миграционной политике будет проверено KDS 206 во время реальной миграции.

3. Успешная аттестация позволяет создавать безопасное соединение между корневой TEE источника и хостами-получателями (в частности, трастлет (доверенную сеть) агента миграции, работающую внутри корневой TEE) и KDS 206 на основании шифрования данных между субъектами.

[0059] Конвертирование существующей VM в защищенную VM.

[0060] Виртуальная машина в окружении арендатора может быть конвертирована в состояние «защищенная VM» путем связывания ее с vTPM. Затем обычно ожидается миграция VM в структуру провайдера услуг. В некоторых вариантах осуществления для создания защищенной VM из обычной VM имеет место следующее:

1. Создается PD для VM и заселяется корректным пользователем и хранителем(ями)

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

3. Технология шифрования, такая как BitLocker, включается на VM и ее VHD полностью шифруются.

[0061] Как только VHD VM полностью зашифрованы, VM становится «достаточно безопасной» для миграции в структуру провайдера услуг.

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

[0063] Некоторые варианты осуществления могут загружать процесс вокруг создания нового PD путем старта с «нулевым» PD - известный входной ключ упаковывается пользователем и любым разрешенным арендатором. Хранителем этого нулевого PD является сам владелец. Этот PD доступен любым хостам арендатора, включенным в создание VM. Для создания PD для новой VM хост предоставляет нулевой PD в KDS, которая возвращает два ключа (известный входной ключ плюс новый выходной ключ), а также PD вокруг выходного ключа. Этот выходной ключ используется хостом для миграции VM за пределы хранилища 203 машин (или другого хранилища) или к провайдеру услуг.

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

[0065] Запуск VM на хосте.

[0066] До того, как хост сможет отпустить VM для миграции, он сначала должен ее загрузить и выполнить. Это достигается путем скачивания VM из автономного хранилища. VHD VM предполагается зашифрованным (например, при помощи BitLocker) и ключ запечатанным внутри vTPM VM. Состояние этой vTPM упаковано с использованием транспортного ключа TK_i (сообщение A_i) и ассоциированных данных, чтобы помочь KDS распаковать ключ TK_i для хоста (PD F_i). И A_i, и F_i являются частью метаданных VM. Со ссылкой на Фиг. 4 шаг за шагом процесс 400 запуска VM выглядит так:

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

2. Хост принимает запрос

3. Хост обращается к автономному хранилищу для скачивания VM

4. После скачивания VM хост выполняет поиск в метаданных VM и переходит к конструированию запроса к KDS:

Извлекает большие двоичные объекты A_i (упакованное состояние vTPM) и F_i (PD для ключей шифрования vTPM, упакованных посредством KDS)

Посылает в KDS PD F_i, сопровождаемый сертификатом здоровья, который содержит свой общий ключ TEE ST_EPub

5. KDS принимает запрос и аутентифицирует сертификат здоровья

Сертификат не устарел

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

(ОПЦИОНАЛЬНО) Политика выпуска, закодированная в сертификате, соответствует здоровому хосту согласно текущей политике здоровья хоста

ПРИМЕЧАНИЕ: KDS не подтверждает, что запрос пришел с хоста, в собственности которого находится закрытый ключ, соответствующий сертификату здоровья; его ответ будет зашифрован с использованием общего ключа TEE инициатора запроса и таким образом будет бесполезным для атакующей стороны

6. KDS вскрывает большой двоичный объект F_i и вычисляет ответ:

Обрабатывает входной PD для извлечения входного транспортного ключа:

Из F_i извлекает E_i и D_i

Из D_i извлекает B_i, а также ноль или более сообщений типа C_i

Среди сообщений B_i и C_i обнаруживает строку, соответствующую KDS

Выстраивает цепочку сертификации начиная с сертификата подписи хранителя, чтобы быть уверенным, что все сертификаты ключей подписи в цепочке сворачиваются к сертификату подписи владельца (единственным, который может быть самоподписанным, и если он не самоподписан, проверяет, что он подписан доверенным органом, таким как, например, Verisign в Рестоне, Вирджиния)

Может быть полезным проверить все сообщения B_i и C_i

Из сообщений B_i и C_i, соответствующих KDS, дешифрирует TK_i

Из TK_i извлекает TK_i-a

Используя TK_i-a, проверяет HMAC внутри E_i, а также подпись хранителя поверх PD

Генерирует выходной транспортный ключ TK_e

Генерирует PD для TK_e:

Из T_EPub (полученного из B_i) и TK_e генерирует B_e

Из K_EPub и TK_e генерирует C_e (это выполняется для всех C-сообщений, которых может быть ноль или более)

Из B_e и C_e генерирует D_e; помечает себя при этом как хранитель

Аутентифицирует D_e при помощи TK_e-a, получая в результате сообщение E_e

Подписывает D_e при помощи своего ключа подписи

Объединяет D_e и E_e во входной PD F_e

Готовится послать TK_i и TK_e обратно хосту

Генерирует TW и из него TW-e и TW-a

Из TW, TW-a, TW-e, TK_i, TK_e и ST_EPub генерирует H

Ответ хосту содержит объединенные сообщения: H||F_e

7. Хост принимает ответ от KDS и передает сообщение H в TEE наряду с A_i

8. TEE обрабатывает ответ от KDS:

Из H с использованием ST_EPri дешифрирует TW

Из TW получает TW-e и TW-a

Используя TW-e, дешифрирует TK_i и TK_e

Аутентифицирует шифрование TK_i и TK_e с использованием TW-a, таким образом аутентифицируя способность KDS вскрывать PD (и таким образом аутентичность KDS)

Из TK_i получает ключи шифрования и аутентификации - TK_i-e и TK_i-a

С использованием TK_i-e дешифрирует состояние vTPM из A_i

С использованием Из TK_i-a шифрование состояние vTPM

9. Как только состояние vTPM дешифрировано, TEE развертывает vTPM

TEE удерживает значение TK_e до тех пор, пока не истечет время, за которое должна мигрировать vTPM, т.е. составляет сообщение Ae и посылает A_e||F_e получателю

10. Теперь хост может завершить последовательность запуска VM.

[0067] Реальная миграция.

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

[0069] Один возможный механизм для миграции, включающий состояние TEE, показан на Фиг. 5. Поток 500, показанный на Фиг. 5, использует несколько служб: «служба управления» (такая как SCVMM), «служба аттестации» и «служба распределения ключей». Служба аттестации и Служба распределения ключей могут быть размещены совместно, поскольку они в равной степени доверенные (и более доверенные, чем SCVMM).

[0070] Реальная миграция начинается с «ключевого соглашения», за которым следует реальная передача данных.

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

2. Хост источника пересылает запрос миграции хосту получателя вместе с выходным транспортным ключом PD F_e; с точки зрения получателя, это входной PD.

3. Хост получателя принимает запрос миграции

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

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

6. KDS делает похожие вычисления ключей шифрования состояния, как было сделано для описанного выше запуска VM, только в это время он возвращает ключи TK_e и TK_eʹ вместо TK_i и TK_e.

7. Хост получателя принимает этот ответ и передает его своей TEE для распаковки.

8. TEE хоста-получателя дешифрирует ключ TK_e с использованием своего закрытого TEE-ключа TT_EPri.

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

[0071] Это завершает фазу ключевого соглашения и устанавливает этап на последний шаг - реальную безопасную передачу данных.

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

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

[0072] Резервное копирование и восстановление VM.

[0073] Процесс резервного копирования и восстановления с точки зрения управления ключами и потока данных очень похож на миграцию от сервера-источника к некоторому объекту хранения данных в состоянии покоя, сопровождаемый миграцией тех же данных на сервер-получатель. Копирование данных в состоянии покоя не требует дополнительной защиты, поскольку этот процесс уже разработан для пересечения небезопасной территории. Единственное требование состоит в том, что ID VM и зашифрованный (при помощи KDS) ключ миграции должны храниться в том же состоянии VM, поскольку они используются службой распределения ключей, чтобы распечатать ключ дешифрирования, необходимый для восстановления.

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

[0075] Отказоустойчивость виртуальной машины внутри кластера.

[0076] Отказоустойчивость VM внутри кластера также может рассматриваться как специальный случай миграции; в этом случае все узлы делят одни и те же метаданные VM для каждого ID VM, размещенной в этом кластере, и таким образом могут получить ключи миграции из KDS перед отработкой отказа. Узлы в кластере делят хранилище, где размещены данные VM; так как все узлы в кластере согласны, какой упакованный ключ VM использовать, ключевое соглашение также легко установить, чтобы гарантировать быструю и легкую отработку отказа. В частности, сценарии отработки отказов не требуют прямой секретности, поэтому ключ, при помощи которого зашифрована vTPM, не изменяется, пока VM находится внутри этого кластера.

[0077] Миграция виртуальной машины между датацентрами

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

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

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

[0081] Способ 600 далее включает в себя шифрование первого ключа дешифрирования вторым механизмом шифрования (действие 604). Второй механизм шифрования ассоциирован со вторым ключом дешифрирования, используемым первым субъектом, так что второй ключ дешифрирования может быть использован первым субъектом для дешифрирования этого набора данных путем дешифрирования сначала ключа, зашифрованного первым ключом, с использованием второго ключа дешифрирования, и затем используя дешифрированный первый ключ для дешифрирования этого набора данных.

[0082] Способ 600 дополнительно содержит шифрование первого ключа дешифрирования третьим механизмом шифрования (действие 606). Третий механизм шифрования ассоциирован с третьим ключом дешифрирования, используемым вторым субъектом, так что третий ключ дешифрирования может быть использован вторым субъектом для дешифрирования этого набора данных путем дешифрирования сначала ключа, зашифрованного первым ключом, с использованием третьего ключа дешифрирования, а затем используя дешифрированный первый ключ для дешифрирования этого набора данных.

[0083] Способ 600 дополнительно включает создание пакета, содержащего по меньшей мере первый ключ дешифрирования, зашифрованный с использованием второго способа шифрования, и первый ключ дешифрирования, зашифрованный третьим способом шифрования (действие 608).

[0084] Данный способ дополнительно включает подписывание этого пакета защитной подписью (действие 610) и подписывание этого пакета подписью, созданной из первого ключа дешифрирования (действие 612).

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

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

[0087] Физическая машиночитаемая среда хранения включает оперативную память (RAM), постоянную память (ROM), электрически перепрограммируемую постоянную память (EEPROM), постоянную память на оптическом диске (CD-ROM) или другое хранилище на оптическом диске (например, CD-диски, DVD-диски и т.п.), хранилище на магнитном диске или другие магнитные устройства хранения, или любую другую среду, которая может быть использована для хранения требуемых средств программного кода в форме выполняемых компьютером инструкций или структур данных, к которым можно получить доступ при помощи компьютерной системы общего назначения или специального назначения.

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

[0089] Далее, по достижении различных компонентов компьютерной системы средства программного кода в форме выполняемых компьютером инструкций или структур данных могут быть автоматически переданы из машиночитаемой среды передачи на машиночитаемую физическую среду хранения (и наоборот). Например, выполняемые компьютером инструкции или структуры данных, принятые по сети или соединению данных, могут быть буферизованы в RAM внутри модуля сетевого интерфейса (например, «NIC») и затем со временем переданы в RAM компьютерной системы и/или на более постоянную машиночитаемую физическую среду хранения на компьютерной системе. Таким образом, машиночитаемая физическая среда хранения может быть включена в компоненты компьютерной системы, которые также (и даже в первую очередь) используют среду передачи.

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

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

[0092] Как альтернатива, или в дополнение, описанная здесь функциональность может быть реализована, по меньшей мере частично, одним или более компонентами аппаратной логики. Например, но без ограничения, иллюстративные типы компонентов аппаратной логики, которые могут быть использованы, включают программируемые пользователем вентильные матрицы (ППВМ), специализированные интегральные микросхемы (ASIC), системы на кристалле (SoC), программируемые логические интегральные схемы (ПЛИС) и т.д.

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