Кратко

  • RFC 9684 определяет YANG RPC для TPM 1.2/2.0 Quotes со свежим nonce и получения BIOS-, IMA- и network-equipment boot logs.
  • Правильная подпись и совпавший replay подтверждают выбранную область измерений, а не полноту устройства и не корректность baseline.
  • Привязка AIK/AK, measurement policy, Reference Values, appraisal, Attestation Result, решение Relying Party, enforcement и результат сети остаются разными квитанциями.

TPM ответил на новый nonce, подпись сошлась, а PCR был воспроизведён из журнала. И всё же процесс, из-за которого началась проверка, отсутствовал: действующая IMA policy его не измеряла. Evidence была подлинной, но вопрос оказался уже реальности.

RFC 9684 стандартизирует важный участок. CHARRA позволяет YANG-клиенту выбирать PCR, запрашивать Quote и получать журналы. Он делает сбор Evidence совместимым между системами, но не превращает ответ RPC в окончательное суждение о доверии.

Nonce ограничивает replay, а не scope

Клиент обязан передать свежий nonce с достаточной энтропией. Attester связывает его с ответом, поэтому старую Quote нельзя незаметно выдать за ответ на текущий challenge.

Эта freshness относится к конкретной Evidence. Она не добавляет пропущенные PCR, не измеряет файлы вне политики и не запрещает устройству измениться после Quote. В composite device она не сообщает автоматически, какой TPM относится к какому компоненту.

RFC 9684 прямо оставляет вне scope способ передачи отношения между отдельным TPM и измеряемой частью. При mtpm отсутствие certificate-name может вызвать ответы всех совместимых TPM. Точный выбор сертификата полезен лишь при надёжной карте certificate–TPM–control/forwarding component.

Квитанция challenge должна сохранять устройство, RPC, nonce, версию TPM, сертификат, hash bank, индексы PCR, вид журнала и версию selection policy. Итоговый pass без этих данных не переживает замену платы, ротацию ключа или обновление image.

Валидная подпись не подтверждает собственные полномочия

Ответ TPM 2.0 может включать TPMS_QUOTE_INFO, подпись, имя сертификата, uptime и вспомогательные unsigned PCR values. Подпись защищает структуру, PCR помогают реконструкции, сертификат связывает ключ с ожидаемой ролью.

Получатель должен проверить, что сертификат TPM 1.2 относится к активной AIK, либо сертификат TPM 2.0 — к активной AK, а владение private key легитимно подтверждено для целевого TPM. Математически правильная подпись другого ключа не представляет нужный компонент.

Настраиваемые структуры могут указывать сертификат без связи с AK, неверный тип ключа, неподдерживаемый физическим TPM алгоритм или PCR, который системное ПО никогда не расширяет. RPC при этом способен завершиться успешно.

NETCONF и RESTCONF защищают management exchange. Они не определяют authority ключа, coverage компонента или правильный baseline. Защищённая доставка и appraisal — соседние, но разные результаты.

Согласованный log может быть неполным

PCR накапливает измерения как rolling hash. Event log предоставляет последовательность, которую Verifier воспроизводит, вычисляя ожидаемый PCR и сравнивая его с подписанной Evidence. Затем измерения сравниваются с Reference Values.

Механизм силён внутри выбранной поверхности. IMA templates задают поля записи, а IMA policy — измеряемые файлы. RFC 9684 отмечает: если policy отсутствует, измерения не выполняются и IMA фактически выключена. Пустой log может идеально совпадать с PCR.

BIOS/UEFI, IMA и network-equipment boot logs охватывают разные фазы. Компоненты могут запускаться параллельно. Легитимный patch меняет hashes и требует обновления Reference Integrity Manifest. Mismatch может означать вмешательство, разрешённый переход или устаревшую ссылку.

Проверяемая запись разделяет версию measurement policy, coverage, raw log, replay, происхождение и срок Reference Values, исключения и appraisal policy. Один vendor score не позволяет пересмотреть решение, если ошибочным оказался baseline.

Attestation Result ещё не является сетевым действием

RFC 9334 разделяет Attester, Verifier и Relying Party. Attester выдаёт Evidence, Verifier appraises её и формирует Attestation Result, а Relying Party применяет результат к конкретной транзакции. RFC 9683 задаёт контекст сетевого оборудования.

RFC 9684 главным образом улучшает получение Evidence. Результат, достаточный для инвентаризации, может не разрешать routing session. Негативный результат может открыть maintenance, ограничить функцию или потребовать человека, а не автоматически выключить весь узел.

После решения нужен receipt enforcement point: изолирован ли port, отозвана ли session, переместился ли traffic, сохранила ли redundancy сервис. TPM Quote этого не наблюдает. Sensor не должен подписывать символический результат за систему, которая действует.

Доступ к Evidence требует least privilege

Logs раскрывают digests и версии, полезные для поиска уязвимого ПО. Большие запросы потребляют ресурсы и создают denial-of-service pressure. Поэтому RFC 9684 требует защищать RPC через NACM, используя deny-all по умолчанию для неавторизованных Verifiers.

Локальная policy должна определять requester, компоненты, частоту, объём, хранение и доступ. Недостаточное измерение даёт ложную уверенность; чрезмерное извлечение увеличивает раскрытие и нагрузку. Общая YANG model не отменяет этот выбор.

Минимальная начальная спецификация сохраняет общий интерфейс узким. Слои реальности раскладывают слово «attested» на nonce, scope, key, baseline и decision. Приоритет работающего кода требует доказательства фактического enforcement.

CHARRA делает TPM response переносимым. Evidence становится вердиктом только после ответственного appraisal с правильными scope и baseline; operational fact появляется только после действия уполномоченной системы.

Источники