Когда доверенный платформенный модуль блокирует сам себя, чтобы предотвратить мошенничество или атаку, это называется блокировкой. Блокировка доверенного платформенного модуля часто продолжается в течение того или иного времени или до выключения компьютера. Доверенный платформенный модуль, находящийся в режиме блокировки, обычно возвращает ошибку, получив команды, которым требуется значение авторизации. Единственное исключение состоит в том, что находящийся в режиме блокировки доверенный платформенный модуль всегда позволяет владельцу выполнить хотя бы одну попытку сброса блокировки доверенного платформенного модуля. Если доверенный платформенный модуль вошел в режим блокировки или медленно реагирует на команды, рекомендуется сбросить значение блокировки. Для сброса блокировки доверенного платформенного модуля требуется авторизация владельца модуля. Авторизация владельца доверенного платформенного модуля определяется, когда администратор впервые становится владельцем доверенного платформенного модуля. Пароль авторизации владельца хэшируется для создания значения авторизации, сохраняемого в доверенном платформенном модуле. Администраторам рекомендуется сохранять хэш-значения авторизации владельца в файл с расширением TPM, содержащий хэш-значение авторизации в XML-структуре. По соображениям безопасности файл пароля владельца доверенного платформенного модуля не содержит оригинал пароля владельца. Владелец доверенного платформенного модуля часто настраивается при первом включении на компьютере шифрования диска BitLocker. В этом сценарии пароль авторизации владельца доверенного платформенного модуля сохраняется вместе с ключом восстановления BitLocker. При сохранении ключа восстановления BitLocker в файл BitLocker также сохраняет файл владельца доверенного платформенного модуля (TPM), содержащий хэш-значение пароля владельца модуля. При печати ключа восстановления BitLocker одновременно печатается пароль владельца доверенного платформенного модуля. Хэш-значение пароля владельца доверенного платформенного модуля также можно сохранить в доменных службах Active Directory (AD DS), если соответствующим образом настроены параметры групповой политики организации.

Общие сведения о механизмах защиты доверенного платформенного модуля

В некоторых сценариях доверенный платформенный модуль защищает ключи шифрования, требуя соответствующее значение авторизации для доступа к ключу (типичным примером является шифрование диска BitLocker, настроенное для использования доверенного платформенного модуля и средства защиты ключа с помощью ПИН-кода, при котором пользователь, чтобы получить доступ к ключу шифрования тома, защищенному доверенным платформенным модулем, должен ввести правильный ПИН-код в процессе загрузки). Чтобы помешать вредоносным объектам раскрыть значения авторизации, в доверенных платформенных модулях реализована логика защиты. Эта логика защиты предназначена для замедления или остановки ответов доверенного платформенного модуля, если он обнаруживает, что объект, возможно, пытается угадать значения авторизации.

Отраслевые стандарты группы Trusted Computing Group (TCG) определяют, что производители доверенного платформенного модуля должны реализовать определенную форму логики защиты в микросхемах TPM 1.2. Различные производители доверенных платформенных модулей реализуют различные механизмы и поведение защиты. Общей рекомендацией для микросхем доверенных платформенных модулей является экспоненциальное увеличение времени реакции модуля при получении модулем неправильных значений авторизации. В некоторых микросхемах доверенных платформенных модулей неудачные попытки могут стираться со временем. Другие микросхемы доверенных платформенных модулей могут хранить каждую из неудачных попыток неопределенно долго. Следовательно, некоторые пользователи могут сталкиваться с все увеличивающимися задержками при неправильном вводе значения авторизации, отправляемого в доверенный платформенный модуль, что помешает им использовать модуль в течение определенного времени. Пользователи могут сбросить механизмы защиты в доверенном платформенном модуле, выполнив следующую процедуру.

Примечание

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

Сброс блокировки доверенного платформенного модуля

Откройте оснастку консоли управления TPM (tpm.msc).
В области Действие щелкните Сброс блокировки доверенного платформенного модуля для запуска мастера сброса блокировки доверенного платформенного модуля.
Выберите способ ввода пароля владельца доверенного платформенного модуля.
- Если пароль владельца доверенного платформенного модуля сохранен в TPM-файле, выберите Имеется файл с паролем владельца, а затем либо введите путь к файлу, либо нажмите кнопку Обзор, чтобы перейти к папке файла.
- Если нужно вручную ввести пароль владельца доверенного платформенного модуля, выберите Ввести пароль владельца вручную, а затем введите пароль в предоставленном поле. Если одновременно включены шифрование диска BitLocker и доверенный платформенный модуль и при включении BitLocker выбрана печать пароля восстановления BitLocker, на том же листе бумаги печатается пароль владельца доверенного платформенного модуля.

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

Вопросы и ответы

Когда следует выполнять сброс блокировки доверенного платформенного модуля?

Самый вероятный сценарий - при использовании средства защиты ключа, состоящего из доверенного платформенного модуля и ПИН-кода, в процессе загрузки пользователи заметят замедление времени реакции, если введен неправильный ПИН-код. Может показаться, что система на какое-то время «зависнет», прежде чем пользователю будет сообщено о том, что введен неправильный ПИН-код и что доверенный платформенный модуль блокирован. При блокировке доверенного платформенного модуля в течение определенного времени также возможно, что, хотя пользователь вводит правильный ПИН-код, доверенный платформенный модуль реагирует так, как если бы ПИН-код был введен неправильно. Аналогичное поведение может возникать для других приложений, использующих доверенный платформенный модуль со значениями авторизации, но если операционная система уже запущена, скорее всего, перестанет отвечать только одно приложение, взаимодействующее с доверенным платформенным модулем. Так как доверенный платформенный модуль может неопределенно долго хранить все неправильные попытки авторизации, пользователям, если они часто ошибаются при вводе значений авторизации, таких как ПИН-код BitLocker, может понадобиться проактивное сбрасывание блокировки доверенного платформенного модуля.

Каково ожидаемое поведение при активированной логике защиты доверенного платформенного модуля для защиты значений авторизации?

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

Если доверенный платформенный модуль блокирован во время использования BitLocker, в процессе загрузки существует возможность либо открыть консоль восстановления BitLocker, либо подождать для повторного ввода ПИН-кода.

После запуска Windows в консоли управления TPM состояние доверенного платформенного модуля будет показано как блокированное.

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

Что делать, если не удается вспомнить пароль владельца доверенного платформенного модуля?

Возможно, что хэш-значение авторизации владельца доверенного платформенного модуля было сохранено в файле с расширением TPM, когда администратор первоначально становился владельцем доверенного платформенного модуля на компьютере. Выполните в своей файловой системе поиск файла с расширением TPM. Пароль владельца доверенного платформенного модуля может быть напечатан при печати пароля восстановления BitLocker. Если найти пароль владельца доверенного платформенного модуля не удается, можно очистить доверенный платформенный модуль и снова стать его владельцем. При этом следует соблюдать осторожность, так как данные, зашифрованные с помощью доверенного платформенного модуля, будут потеряны. При использовании BitLocker перед очисткой доверенного платформенного модуля не забудьте приостановить или выключить работу BitLocker. Дополнительные сведения об очистке доверенного платформенного модуля см. в разделе Очистка TPM.

Важно ли хранить в секрете хэш-значение авторизации владельца доверенного платформенного модуля?

Да. Если вредоносный объект получит хэш-значение авторизации владельца доверенного платформенного модуля, он сможет выполнить несколько попыток угадать значение авторизации ключа шифрования (например, ПИН-код BitLocker), использовать хэш-значение авторизации владельца доверенного платформенного модуля для сброса блокировки модуля и повторить эти действия любое количество раз. В результате значение авторизации может быть раскрыто, если его размер относительно невелик.

Как пароль владельца доверенного платформенного модуля связан с хэш-значением авторизации владельца доверенного платформенного модуля?

Для создания хэш-значения авторизации владельца доверенного платформенного модуля пароль владельца доверенного платформенного модуля хэшируется с помощью SHA-1 и шифруется с помощью Base-64.