Виртуализация ресурсов
Основной функцией ТБS является эффективное совместное использование определенных ограниченных ресурсов доверенного платформенного модуля: ключей, авторизации и транспортных сеансов.
При создании экземпляра одного из этих ресурсов ТБS создает виртуальный экземпляр ресурса и возвращает дескриптор этому виртуальному экземпляру в результирующем потоке команд (а не фактическому экземпляру дескриптора, возвращаемого TPM). ТБS поддерживает сопоставление между виртуальным дескриптором и фактическим дескриптором внутри. Если доверенному платформенного модуля не требуется места для хранения дополнительных ресурсов заданного типа, существующие экземпляры ресурса выборочно сохраняются и вытеснены до тех пор, пока TPM не сможет сохранить новый ресурс. Когда старые ресурсы требуются снова, ТБS загружает сохраненные контексты (сохранение и вытеснение других ресурсов при необходимости) перед отправкой команды.
Все виртуализации в ТБS выполняются от имени определенного контекста. Каждый контекст разрешен только для доступа к виртуальным ресурсам, созданным специально от его имени, а также физическим ресурсам доверенного платформенного модуля, соответствующим этим виртуальным ресурсам. По умолчанию общее количество всех виртуализированных ресурсов ограничено 500. Это число можно изменить, создав или изменив значение реестра DWORD с именем MaxResources в разделе HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm. Использование ресурсов ТБS в режиме реального времени можно наблюдать с помощью средства монитора производительности для отслеживания количества ресурсов ТБS. Это ограничение стало устаревшим с Windows 8 и Windows Server 2012.
Ограниченные ресурсы доверенного платформенного модуля, которые не виртуализированы ТБS (например, счетчики и хранилище NV), должны совместно использоваться между стеками программного обеспечения.
Заметка
Эта обработка виртуализации приводит к сбою команд, включающих ключи в вычисление параметров авторизации HMAC. В результате многие команды, устаревшие в TPM версии 1.2, не могут использоваться программным обеспечением приложения в среде TBS.
Ограничения ресурсов
TPM позволяет вызывающим пользователям запрашивать свои возможности, чтобы определить, сколько места доступно для определенных типов ресурсов. Некоторые из этих ограничений ресурсов, такие как объем свободного места для ключей, сеансов авторизации и транспортных сеансов, эффективно расширяются с помощью ТБS с помощью виртуализации. Ограничения ТБS, контролируемые параметром реестра MaxResources реестра, обычно гораздо больше, чем фактические ограничения базового оборудования доверенного платформенного модуля. Механизм не предоставляется для запроса ограничений ТБS отдельно от ограничений оборудования доверенного платформенного модуля. Это ограничение ТБS стало устаревшим с Windows 8 и Windows Server 2012.
Ключи
ТбS виртуализирует маркеры ключей, чтобы ключи можно было прозрачно выгрузить из доверенного платформенного модуля, если они не используются и загружаются обратно в TPM при необходимости. При создании ключа ТБS связывает виртуальный дескриптор с загруженным ключом. Тот же виртуальный дескриптор используется для времени существования ресурса. Дескриптора виртуальных ключей допустимы только в контексте, созданном им, и связанные ресурсы не сохраняются за пределами жизни контекста.
Создание ключей с помощью TPM_LoadKey2
Если ключ создается с помощью команды TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load или TPM2_LoadExternal, тбS заменяет дескриптор в возвращаемом потоке байтов дескриптором его выбора виртуальным ключом. В результате ТБS гарантирует, что каждый виртуальный дескриптор является уникальным. Если ТБS обнаруживает столкновение (крайне маловероятное событие), ТБS выгрузит ключ из доверенного платформенного модуля и сообщает вызывающему программному обеспечению. Затем программное обеспечение может повторно отправить операцию. Этот процесс можно повторять, пока ТБS не получит уникальный дескриптор ключа.
Очистка ключей
ТБS запрещает дескриптор виртуального ключа при получении сообщения TPM_FlushSpecific или TPM2_FlushContext для этого виртуального дескриптора из контекста клиента. Если ключ физически присутствует в TPM при получении сообщения об очистке, тбS сбрасывает ключ из доверенного платформенного модуля в то время.
Временное удаление ключей
При вытеснению ключа из доверенного платформенного модуля, чтобы освободить место для нового элемента, ТБS выполняет команду TPM_SaveContext или TPM2_ContextSave на ключе перед вытеснением.
Восстановление ключей
Когда команда, ссылающаяся на загруженный ключ, отправляется в ТБS, она гарантирует, что ключ физически присутствует в доверенном платформенный модуль. Если ключ отсутствует, тбS восстанавливает его с помощью вызова TPM_LoadContext или TPM2_ContextLoad. Если ключ не может быть восстановлен в доверенном платформенный модуль, тбS возвращает TPM_E_INVALID_KEYHANDLE в качестве результата доверенного платформенного модуля.
ТБS заменяет каждый виртуальный дескриптор, связанный с ключом в потоке команд, физическим дескриптором ключа, загруженного в TPM. Если команда отправляется с виртуальным дескриптором, который не распознается ТБS в контексте вызывающего объекта, тбS форматирует поток ошибок для вызывающего объекта с TPM_E_INVALID_KEYHANDLE.
Сеансы авторизации
Сеансы авторизации создаются путем вызова TPM_OIAP, TPM_OSAP или TPM_DSAP. В каждом случае возвращаемый поток байтов содержит физический дескриптор доверенного платформенного модуля только что созданного сеанса авторизации. ТбS заменяет это виртуальным дескриптором. При последующей ссылке на сеанс авторизации ТБS заменяет виртуальный дескриптор в потоке команд физическим дескриптором сеанса авторизации. ТБS гарантирует, что время существования сеанса виртуальной авторизации соответствует времени существования сеанса физической авторизации. Если клиент пытается использовать истекший срок действия виртуального дескриптора, ТБS форматирует поток ошибок с TPM_INVALIDAUTHHANDLE ошибки.
Слоты сеансов ограничены, и ТБS может выйти из внешних слотов, в которых можно сохранить контексты сеанса авторизации. В этом случае ТБS выбирает сеанс авторизации, чтобы сделать его недействительным, чтобы новый контекст можно было успешно сохранить. Приложению, которое пытается использовать старый контекст, потребуется повторно создать сеанс авторизации.
ТБS делает сеанс виртуальной авторизации недействительным при возникновении любого из следующих случаев:
Флаг продолжения использования, связанный с сеансом авторизации в возвращенном потоке команд из доверенного платформенного модуля, FALSE.
Команда, использующая сеанс авторизации, завершается сбоем.
Выполняется команда, которая отменяет сеанс авторизации, связанный с командой (например, TPM_CreateWrapKey).
Ключ, связанный с сеансом OSAP или DSAP, удаляется из доверенного платформенного модуля с вызовом TPM_FlushSpecific или TPM2_FlushContext (независимо от того, возникла ли эта команда с помощью ТБS или с более высоким уровнем программного обеспечения).
ТБS автоматически изменит размер сеансов авторизации после успешного выполнения некоторых недетерминированных команд, чтобы убедиться, что состояние ТБS остается согласованным с состоянием доверенного платформенного модуля. Затронутые команды:
- TPM_ORD_Delegate_Manage
- TPM_ORD_Delegate_CreateOwnerDelegation
- TPM_ORD_Delegate_LoadOwnerDelegation
В каждом из следующих случаев сеанс авторизации доверенного платформенного модуля автоматически очищается TPM:
Создание сеансов авторизации
Дескриптор сеанса виртуальной авторизации действителен только в контексте, созданном им, и связанные ресурсы не сохраняются за пределами жизни связанного контекста.
Очистка сеансов авторизации
ТБS запрещает сеанс виртуальной авторизации, если он получает команду TPM_FlushSpecific или TPM2_FlushContext для виртуального дескриптора из контекста клиента. Если сеанс авторизации физически присутствует в доверенном платформенный платформенный модуль при получении команды очистки, тбS немедленно очищает физический сеанс от доверенного платформенного модуля.
Временное удаление сеансов авторизации
При вытеснению сеанса авторизации из доверенного платформенного модуля для создания места для новой сущности тбS выполняется TPM_SaveContext или TPM2_ContextSave на этом сеансе авторизации.
Восстановление сеансов авторизации
Когда авторизованная команда доверенного платформенного модуля отправляется в ТБS, служба ТБS гарантирует, что все сеансы виртуальной авторизации, указанные в команде, физически присутствуют в доверенном платформенный модуль. Если какие-либо сеансы авторизации отсутствуют, ТБS восстанавливает их с помощью вызова TPM_LoadContext или TPM2_ContextLoad. Если сеанс авторизации не может быть восстановлен в доверенном платформенный модуль, тбS возвращает TPM_E_INVALID_HANDLE в качестве результата доверенного платформенного модуля.
ТБS заменяет каждый виртуальный дескриптор, связанный с сеансом авторизации в потоке команд, физическим дескриптором сеанса авторизации, загруженного на TPM.
Если команда отправляется с виртуальным дескриптором, который не распознается ТБS в контексте вызывающего объекта, тбS форматирует поток ошибок для вызывающего объекта с TPM_E_INVALID_HANDLE ошибки.
Сеансы транспорта
Заметка
Обработка сеансов транспорта, как описано здесь, относится к Windows Vista и Windows Server 2008.
Сеансы транспорта — это механизм, предоставляемый TPM, который позволяет стеку программного обеспечения шифровать данные в команде по мере передачи между программным обеспечением и TPM. Это предотвращает перехват данных злоумышленником по мере прохождения аппаратной шины.
Важный
Шифруются только полезные данные. Выполняемые команды по-прежнему можно определить.
К сожалению, этот механизм также запрещает ТБS изучать полезные данные. В большинстве случаев это не проблема, так как ТБS изменяет только дескрипторы, а не полезные данные. Однако в случае TPM_LoadContext, например, возвращенный дескриптор ресурсов охватывается шифрованием. Поэтому ТБS предотвращает попытки выполнения TPM_LoadContext операции, охваченной сеансом транспорта.
ТБS блокирует следующие команды в сеансе транспорта:
- 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
Если любая из этих команд охватывается сеансом транспорта, ТБS возвращает TPM_E_EMBEDDED_COMMAND_UNSUPPORTED в качестве результата доверенного платформенного модуля.
Дескриптора сеансов транспорта виртуализированы таким образом, как дескрипторы ключей и дескриптор авторизации. В TPM доступно ограниченное количество сохраненных слотов контекста сеанса транспорта.
ТБS недействителен сеанс виртуального транспорта, если происходит любое из следующих случаев:
Флаг продолжения использования, связанный с сеансом транспорта в возвращаемом потоке команд из доверенного платформенного модуля, FALSE.
Как и в случае с сеансами авторизации выше, ТБS автоматически изменит размер сеансов транспорта после успешного выполнения некоторых недетерминированных команд, чтобы убедиться, что состояние ТБS остается согласованным с состоянием доверенного платформенного модуля. Затронутые команды:
- TPM_ORD_Delegate_Manage
- TPM_ORD_Delegate_CreateOwnerDelegation
- TPM_ORD_Delegate_LoadOwnerDelegation
В каждом из этих случаев сеанс транспорта в доверенном платформенного платформенного модуля будет автоматически очищаться TPM:
Создание сеансов транспорта
ТБS создает виртуальный дескриптор для каждого сеанса транспорта, созданного клиентом. Виртуальные дескрипторы транспорта допустимы только в контексте, созданном им, и связанные ресурсы не сохраняются за пределами жизни связанного контекста.
Очистка сеансов транспорта
ТБS запрещает сеанс виртуального транспорта, если он получает команду TPM_FlushSpecific для виртуального дескриптора из контекста клиента. Если сеанс транспорта физически присутствует в доверенном платформенный модуль при получении команды очистки, тбS немедленно сбрасывает физический сеанс из доверенного платформенного модуля.
Временное удаление сеансов транспорта
При вытеснению сеанса транспорта из доверенного платформенного модуля для создания места для новой сущности ТБS выполняется TPM_SaveContext в этом сеансе транспорта.
Восстановление сеансов транспорта
Когда команда TPM_ExecuteTransport отправляется в ТБS, служба ТБS гарантирует, что сеанс транспорта, указанный в команде, физически присутствует в доверенном платформенный модуль. Если сеанс транспорта отсутствует, тбS восстанавливает его с помощью вызова TPM_LoadContext.
ТБS заменяет виртуальный дескриптор, связанный с сеансом транспорта в потоке команд, физическим дескриптором сеанса транспорта, загруженного в TPM. Если команда отправляется с виртуальным дескриптором, который не распознается ТБS в контексте вызывающего объекта, тбS форматирует поток ошибок для вызывающего объекта с помощью TPM_E_INVALID_HANDLE.
Эксклюзивные сеансы транспорта
Монопольные сеансы транспорта являются способом для программного обеспечения верхнего уровня, чтобы определить, обращается ли любое другое программное обеспечение к доверенному платформенного платформенного модуля во время цепочки команд. Они не препятствуют доступу к доверенному платформенного модуля другому программному обеспечению, они просто дают создателю сеанса транспорта средства определения того, что произошел другой доступ. ТБS не делает ничего конкретного, чтобы препятствовать эксклюзивным транспортным сеансам, но это несколько несовместимо с ними. ТБS пытается дублировать естественное поведение доверенного платформенного модуля, будучи прозрачным, поэтому он не предпочитает команды из контекстов, которые устанавливают монопольный сеанс транспорта. Например, если клиент B отправляет команду, когда клиент A находится в эксклюзивном сеансе транспорта, он будет недействительным монопольный сеанс транспорта клиента A.
Команды, инициированные ТБS, также могут завершить эксклюзивный сеанс транспорта. Это происходит, когда клиент A находится в эксклюзивном сеансе транспорта, и команда, выполняемая клиентом A, вызывает ресурс, который физически не присутствует в доверенном платформенный модуль. В этой ситуации диспетчер виртуализации TBS запускает команду TPM_LoadContext для предоставления этого ресурса, которая завершает монопольный сеанс транспорта клиента A.