Поделиться через

Виртуализация ресурсов

  • Статья

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

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

Вся виртуализация в TBS выполняется от имени определенного контекста. Каждому контексту разрешен доступ только к виртуальным ресурсам, созданным специально от его имени, а также к физическим ресурсам доверенного платформенного модуля, соответствующим этим виртуальным ресурсам. По умолчанию общее количество всех виртуализированных ресурсов ограничено 500. Это число можно изменить, создав или изменив значение реестра DWORD с именем MaxResources в разделе HKEY_LOCAL_MACHINE\Software\Microsoft\TPM. Использование ресурсов TBS в режиме реального времени можно отслеживать с помощью средства Монитор производительности для отслеживания количества ресурсов TBS. Это ограничение устарело в Windows 8 и Windows Server 2012.

Ограниченные ресурсы TPM, которые не виртуализированы с помощью TBS (например, счетчики и хранилище NV), должны совместно использоваться между программными стеками.

Примечание

Эта виртуализация дескрипторов приводит к сбою команд, включающих дескрипторы ключей при вычислении параметров авторизации HMAC. В результате многие команды, устаревшие в TPM версии 1.2, не могут использоваться программным обеспечением приложения в среде TBS.

 

Ограничения ресурсов

TPM позволяет вызывающим абонентам запрашивать свои возможности, чтобы определить, сколько пространства доступно для определенных типов ресурсов. Некоторые из этих ограничений ресурсов, такие как объем свободного места для ключей, сеансов авторизации и транспортных сеансов, эффективно расширяются TBS за счет виртуализации. Ограничения TBS, которые управляются параметром реестра MaxResources , обычно гораздо больше, чем фактические ограничения базового оборудования TPM. Не предоставляется никакого механизма для запроса ограничений TBS отдельно от аппаратных ограничений доверенного платформенного модуля. Это ограничение TBS устарело с Windows 8 и Windows Server 2012.

Ключи

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

  • Создание ключей с помощью TPM_LoadKey2

    Если ключ создается с помощью команды TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load или TPM2_LoadExternal, tbS заменяет дескриптор в возвращаемом потоке байтов виртуальным маркером ключа по своему выбору. В результате TBS гарантирует, что каждый виртуальный дескриптор является уникальным. Если TBS обнаруживает столкновение (крайне маловероятное событие), TBS выгружает ключ из доверенного платформенного модуля и сообщает вызывающей программе. Затем программное обеспечение может повторно отправить операцию. Этот процесс можно повторять до тех пор, пока TBS не получит уникальный дескриптор ключа.

  • Очистка ключей

    TBS делает дескриптор виртуального ключа недействительным при получении сообщения TPM_FlushSpecific или TPM2_FlushContext для этого виртуального дескриптора из контекста клиента. Если ключ физически присутствует в TPM при получении сообщения о сбросе, tbS сбрасывает ключ из доверенного платформенного модуля в это время.

  • Временное удаление ключей

    При удалении ключа из доверенного платформенного модуля, чтобы освободить место для нового элемента, TBS выполняет команду TPM_SaveContext или TPM2_ContextSave ключа, прежде чем вытеснить его.

  • Восстановление ключей

    Когда команда, ссылающаяся на загруженный ключ, отправляется в TBS, она гарантирует физическое наличие ключа в TPM. Если ключ отсутствует, служба TBS восстанавливает его с помощью вызова TPM_LoadContext или TPM2_ContextLoad. Если ключ не может быть восстановлен в доверенном платформенный платформенный модуль, служба TBS возвращает TPM_E_INVALID_KEYHANDLE в качестве результата TPM.

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

Сеансы авторизации

Сеансы авторизации создаются путем вызова TPM_OIAP, TPM_OSAP или TPM_DSAP. В каждом случае возвращаемый поток байтов содержит физический дескриптор доверенного платформенного модуля только что созданного сеанса авторизации. TBS заменяет его виртуальным дескриптором. При последующей ссылке на сеанс авторизации служба TBS заменяет виртуальный дескриптор в потоке команд физическим дескриптором сеанса авторизации. TBS гарантирует, что время существования виртуального сеанса авторизации совпадает с временем существования физического сеанса авторизации. Если клиент пытается использовать просроченный виртуальный дескриптор, TBS форматирует поток ошибок с TPM_INVALIDAUTHHANDLE ошибок.

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

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

  • Флаг continue-use, связанный с сеансом авторизации в потоке команд, возвращаемом из доверенного платформенного модуля, имеет значение FALSE.

  • Команда, использующая сеанс авторизации, завершается сбоем.

  • Выполняется команда, которая делает недействительным сеанс авторизации, связанный с командой (например, TPM_CreateWrapKey).

  • Ключ, связанный с сеансом OSAP или DSAP, удаляется из доверенного платформенного модуля с помощью вызова TPM_FlushSpecific или TPM2_FlushContext (независимо от того, исходила ли эта команда в TBS или в программном обеспечении более высокого уровня).

    ПОСЛЕ успешного выполнения некоторых недетерминированных команд TBS автоматически повторно синхронизирует сеансы авторизации, чтобы убедиться, что состояние TBS остается согласованным с состоянием доверенного платформенного модуля. Затронутые команды:

    • TPM_ORD_Delegate_Manage
    • TPM_ORD_Delegate_CreateOwnerDelegation
    • TPM_ORD_Delegate_LoadOwnerDelegation

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

  • Создание сеансов авторизации

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

  • Очистка сеансов авторизации

    TBS делает сеанс виртуальной авторизации недействительным, если он получает TPM_FlushSpecific или команду TPM2_FlushContext для виртуального дескриптора из контекста клиента. Если сеанс авторизации физически присутствует в TPM при получении команды очистки, TBS немедленно очищает физический сеанс из доверенного платформенного модуля.

  • Временное удаление сеансов авторизации

    При удалении сеанса авторизации из доверенного платформенного модуля, чтобы освободить место для новой сущности, TBS выполняет TPM_SaveContext или TPM2_ContextSave в этом сеансе авторизации.

  • Восстановление сеансов авторизации

    Когда авторизованная команда доверенного платформенного модуля отправляется в TBS, служба TBS гарантирует, что все виртуальные сеансы авторизации, упомянутые в команде, физически присутствуют в TPM. Если какой-либо из сеансов авторизации отсутствует, служба TBS восстанавливает их с помощью вызова TPM_LoadContext или TPM2_ContextLoad. Если сеанс авторизации не может быть восстановлен в TPM, tbS возвращает TPM_E_INVALID_HANDLE в качестве результата TPM.

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

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

Сеансы транспорта

Примечание

Обработка сеансов транспорта, как описано здесь, относится к Windows Vista и Windows Server 2008.

 

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

Важно!

Шифруются только полезные данные. Выполняемые команды по-прежнему можно идентифицировать.

 

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

TBS блокирует следующие команды в сеансе транспорта:

  • TPM_EstablishTransport
  • TPM_ExecuteTransport
  • TPM_Terminate_Handle
  • TPM_LoadKey
  • TPM_EvictKey
  • TPM_SaveKeyContext
  • TPM_LoadKeyContext
  • TPM_SaveAuthContext
  • TPM_LoadAuthContext
  • TPM_SaveContext
  • TPM_LoadContext
  • TPM_FlushSpecific

Если любая из этих команд охватывается сеансом транспорта, TBS возвращает TPM_E_EMBEDDED_COMMAND_UNSUPPORTED в качестве результата доверенного платформенного модуля.

Дескрипторы сеансов транспорта виртуализированы так же, как дескрипторы ключей и дескрипторы авторизации. В TPM доступно ограниченное количество сохраненных слотов контекста сеанса транспорта.

TBS делает сеанс виртуального транспорта недействительным в любом из следующих случаев:

  • Флаг continue-use, связанный с сеансом транспорта в потоке команд возврата из доверенного платформенного модуля, имеет значение FALSE.

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

    • TPM_ORD_Delegate_Manage
    • TPM_ORD_Delegate_CreateOwnerDelegation
    • TPM_ORD_Delegate_LoadOwnerDelegation

В каждом из этих случаев сеанс транспорта в TPM будет автоматически очищаться доверенным платформенный платформенный модуль:

  • Создание сеансов транспорта

    TBS создает виртуальный дескриптор для каждого сеанса транспорта, созданного клиентом. Дескрипторы виртуального транспорта действительны только в контексте, который их создал, а связанные ресурсы не сохраняются за пределами срока жизни связанного контекста.

  • Очистка сеансов транспорта

    TBS делает недействительным сеанс виртуального транспорта, если получает команду TPM_FlushSpecific для виртуального дескриптора из контекста клиента. Если сеанс транспорта физически присутствует в TPM при получении команды очистки, TBS немедленно очищает физический сеанс из доверенного платформенного модуля.

  • Временное удаление сеансов транспорта

    При удалении транспортного сеанса из доверенного платформенного модуля, чтобы освободить место для новой сущности, TBS выполняет TPM_SaveContext в этом транспортном сеансе.

  • Восстановление сеансов транспорта

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

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

Эксклюзивные сеансы транспорта

Монопольные сеансы транспорта в оболочке — это способ, с помощью которого программное обеспечение верхнего уровня определяет, обращается ли какое-либо другое программное обеспечение к доверенному платформенного модуля во время цепочки команд. Они не препятствуют доступу другого программного обеспечения к TPM, они просто предоставляют создателю транспортного сеанса средство определения наличия другого доступа. TBS не делает ничего конкретного, чтобы помешать эксклюзивным сеансам транспорта, но он несколько несовместим с ними. TBS пытается дублировать естественное поведение доверенного платформенного модуля, будучи прозрачным, поэтому он не использует команды из контекстов, которые устанавливают монопольный транспортный сеанс. Например, если клиент B отправляет команду, когда клиент A находится в монопольном транспортном сеансе, это сделает недействительным сеанс монопольного транспорта клиента A.

Команды, инициированные TBS, также могут завершить сеанс монопольного транспорта. Это происходит, когда клиент A находится в эксклюзивном транспортном сеансе, а команда, выполняемая клиентом A, вызывает ресурс, физически отсутствующего в TPM. В этой ситуации диспетчер виртуализации TBS выполняет команду TPM_LoadContext для предоставления этого ресурса, которая завершает сеанс монопольного транспорта клиента A.