TPM: что именно заслуживает доверия

Четыре разных обещания

TPM — компонент для защищённой работы с ключами, состоянием и криптографическими операциями, а не сканер вредоносного кода. В TPM 2.0 механизм авторизации может связывать использование объекта с политикой. PCR аккумулируют измерения; quote подписывает связанные с ними сведения. Эти функции полезны именно потому, что их назначение ограничено и формализовано. S01

Но безопасная система должна различать четыре утверждения: ключ защищён внутри компонента; измерения отражают нужную последовательность; проверяющая сторона правильно оценила сведения; допущенная операция соответствует намерению владельца. Даже корректность первых двух не даёт автоматически последние два. Это рабочая модель анализа, которую удобно применять к загрузке, выдаче секретов и удалённому доступу.

PCR — накопление, а не антивирусная оценка

Операция extend связывает прежнее значение PCR с новым digest через хеширование. Поэтому порядок измерений имеет значение. Само значение не содержит человекочитаемую историю и не говорит «хорошо» или «плохо». Для интерпретации нужен журнал событий и ожидаемая политика измерений. Quote и проверка выбранных PCR — часть доказательства, но не семантический анализ всего исполняемого кода. S02

Практический вопрос Blue звучит так: какой компонент измерил какие байты и до какого события? Если был измерен файл до загрузки, последующее изменение его копии в памяти может находиться вне этого свидетельства. Antarctic и Abyss показывают, почему в модели необходимо отдельно обозначить время измерения и время использования. E45 E06

При этом изменившийся PCR не обязательно означает атаку. Причиной может быть обновление прошивки, загрузчика или политики. Система допуска должна уметь отличать ожидаемую смену версии от неразрешённого состояния. Слепое добавление любого нового значения в baseline уничтожает смысл проверки; запрет любой смены делает обновления практически невозможными.

Attestation — протокол решения

RATS разделяет Attester, Verifier и Relying Party. Первая сторона предъявляет Evidence, вторая оценивает его по политике, третья принимает решение о доступе. Freshness рассматривается отдельно: корректная подпись старого свидетельства не делает его актуальным. Это архитектура обмена и оценки, а не обещание абсолютной чистоты устройства. S03

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

Red: проверяйте гипотезу о разрыве между предъявленным свидетельством и разрешённой операцией. Вопрос не только в подделке подписи, но и в том, может ли корректное свидетельство быть использовано вне предполагаемого контекста.

Blue: храните версию политики вместе с результатом оценки. Иначе через месяц невозможно объяснить, почему конкретное устройство было допущено, особенно после обновления эталонных значений.

Три поверхности TPM

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

TPM-FAIL: криптография может утечь через время

Работа TPM-FAIL исследовала временные утечки в реализациях операций подписи, в том числе Intel fTPM и дискретном TPM STMicroelectronics. Авторы показали, что математически корректная схема подписи не исключает извлечение информации из её реализации. Результаты относятся к изученным продуктам и условиям, а не к каждой реализации TPM 2.0. S04

Защитный урок — учитывать способ вычисления, а не только выбранный алгоритм и сертификат соответствия. Для инвентаризации нужны производитель, версия firmware и применённые исправления. Название «TPM 2.0» слишком грубо для оценки конкретной уязвимости.

С исследовательской стороны полезно разделять три уровня доказательства: наличие зависимого от секрета времени, статистически различимый сигнал и восстановление полезной информации в заявленной модели доступа. Эти уровни не следует сворачивать в одно слово «сломано». У каждого свои условия, шум и стоимость повторения.

faulTPM: скрытая шина не устраняет весь класс риска

faulTPM исследует компрометацию среды исполнения AMD fTPM через AMD Secure Processor. Авторы демонстрируют, что отсутствие внешней шины discrete TPM не исключает атаки на внутреннее состояние fTPM. В изученной физической модели полученный доступ затрагивает криптографический материал и состояние TPM. Работа отдельно обсуждает различия защиты диска с TPM-only и TPM+PIN. S05

Из этого нельзя делать вывод «PIN всегда бесполезен» или «любой AMD-компьютер сейчас уязвим». Нужны конкретные поколения оборудования, версии и условия исследования. Корректный вывод уже: перенос TPM в firmware меняет поверхность атаки, а безопасность fTPM зависит от среды, в которой он исполняется.

Для Blue это аргумент в пользу документированной модели физического доступа и политики восстановления. Но пароль, recovery key и аппаратный компонент не стоит считать взаимозаменяемыми резервами. Каждый защищает и раскрывает разные активы в разные моменты жизненного цикла устройства.

Sealing и момент раскрытия секрета

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

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

Программа проверки Red / Blue

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

Критерий зрелости

Зрелая архитектура с TPM умеет ответить не «есть ли чип», а «какое решение было принято на основании какого свежего свидетельства и что именно оно разрешило». Для bootkit-угроз к этому добавляется временная ось: что произошло между измерением загрузчика и использованием ядра. Только такая постановка связывает аппаратную функцию с реальной защитой.