Кратко

  • RFC 9019 называет обновление прошивки авторизованным удалённым выполнением кода. Подпись подтверждает автора и защищает манифест, но устройство отдельно проверяет, разрешено ли этому автору запрошенное действие.
  • Автор, оператор устройства, оператор сети, пользователь и центр настройки доверия могут иметь разные права. RFC 9124 поддерживает несколько подписей, чтобы совместить разрешения разных ролей.
  • Локальная квитанция авторизации изменения может связать манифест, политику, окно, запуск и наблюдаемый результат. Это редакционное предложение Daniel Kade, а не новое поле SUIT.

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

Однако происхождение и целостность уже, чем право запустить код. RFC 9019 была опубликована в апреле 2021 года как информационная RFC IETF. Она описывает обновление как авторизованное удалённое выполнение кода, считает аутентифицированную личность автора входом в процесс авторизации и требует проверить, входит ли действие в полномочия подписанта.

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

Завершение передачи не завершает переход состояния

RFC 9019 разделяет потребителя прошивки и верификатор. Потребитель разбирает манифест, проверяет его и сохраняет образ. Верификатор, часто загрузчик, снова проверяет образ перед выполнением. Если образ непригоден, устройство должно выбрать другой действительный или получить новый.

В примерной последовательности сообщение «Firmware Update Completed» отправляется до перезагрузки, проверки secure boot и активации. Оно корректно сообщает о завершении представленной стадии. Оно не может доказать будущий результат.

Загрузчик может отклонить образ. Устройство может запуститься, но не восстановить сервис. В многоконтроллерном продукте может активироваться только часть компонентов. Механизм восстановления может выбрать старый образ. Сеть может исчезнуть до отчёта. Сервер, видевший раннее завершение, ещё не знает устойчивое состояние.

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

Архитектура различает носителей власти

RFC 9019 выделяет автора, оператора устройства, сетевого оператора, пользователя и Trust Provisioning Authority, TPA. TPA распределяет якоря и политики и может делегировать права. Автор создаёт образ; оператор ведёт парк; сетевой оператор управляет другой поверхностью.

В простом продукте роли может совмещать одна организация. Одной подписи достаточно, если политика действительно наделила её всеми нужными правами. Стандарт не требует обязательного человеческого клика или двух подписей для каждого случая.

В сложной цепочке права расходятся. Поставщик радиомодуля подписывает свой компонент, но не выбирает время остановки завода. Сервис доставки хранит и передаёт файл, но не получает права менять его. Команда безопасности оценивает срочность, а оператор отвечает за безопасное состояние оборудования.

Политика TPA становится картой полномочий: ключи связываются с ролями, роли — с компонентами, классами, действиями, сроками и делегированием. Устаревшая или чрезмерно широкая карта допускает институционально неверное изменение при совершенно исправной криптографии.

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

Несколько подписей — не голосование

В примере критической инфраструктуры RFC 9019 аутентичный автор может не обладать единоличным правом установки. Устройство можно настроить на подпись автора и оператора. Вторая подпись не усиливает происхождение; она добавляет решение ответственного за среду.

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

Число не заменяет роли. Два ключа в роли автора не выполняют правило «автор плюс оператор». Три общих подписанта не заменят отсутствующего владельца безопасности. Нужно оценить роль ключа, версию политики, область и покрытое действие.

То же относится к делегированию. Важно не только то, что новый ключ подписан, но кто имел право его назначить, на какие компоненты, до какого срока и с возможностью ли дальнейшей передачи. Цепочка ключей становится цепочкой полномочий только при сохранении границ.

Предварительная авторизация предшествует загрузке

Потребитель манифеста решает, стоит ли получать образ. RFC 9019 описывает предварительную авторизацию: сначала определяется, может ли подписант выполнить обновление. Ранний отказ экономит канал, энергию и ресурс памяти ограниченного устройства.

Запрашиваемое действие имеет структуру. Разрешение на приложение не покрывает загрузчик. Временный аварийный мандат не вечен. Право на датчики не распространяется на промышленный контроллер. Дайджест защищает байты, но не создаёт эти компетенции.

Status Tracker может объявить версию, получить сведения об устройстве и инициировать процесс. Его могут эксплуатировать разные стороны. Владение триггером не передаёт право авторства или одобрения. Хранение, транспорт, запуск процесса и разрешение остаются разными функциями.

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

Последовательность манифеста не равна версии прошивки

RFC 9124 требует растущей последовательности, чтобы не принять старый действительный манифест. Но это не поле версии прошивки. Более новый манифест может сознательно разрешить образ с более низкой версией.

Так выполняется контролируемое восстановление. Если свежий выпуск неудачен, ответственная сторона выпускает новое решение о возврате к известному образу. Последовательность авторизации растёт, версия кода снижается.

Автоматическая метка «атака» для любого снижения помешает восстановлению. Следует проверить последовательность, право отката, исходное состояние, группу и причину. И наоборот, более высокий номер версии не доказывает полномочия. «Новее» — не роль доступа.

История манифестов хранит решения; история прошивок — исполняемые состояния. Иногда они движутся в разные стороны. Это различие должно сохраняться для расследования.

Подлинный образ может быть неприменим

Устройство может содержать несколько микроконтроллеров. Изменение требует нескольких образов, зависимостей, точного предшественника, места хранения и согласованной активации. RFC 9124 предусматривает идентификаторы производителя, класса, устройства, компонента, дайджесты предшественника и шаги обработки именно потому, что подлинность не равна применимости.

Дифференциальная нагрузка ломается на неправильном предшественнике. Два действительных компонента могут быть несовместимы вместе. Образ соседней аппаратной модели способен пройти проверку подписи и правильно быть отклонённым по классу.

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

Автоматическое обновление возможно и нужно. Отсутствие человека в момент исполнения означает заранее выраженную политику, а не отсутствие ответственного решения.

Квитанция авторизации изменения

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

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

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

Это редакционное предложение Daniel Kade, а не элемент SUIT, требование IETF, удалённая команда или продукт TPA. Оно не позволяет точной криптографической улике отвечать на вопросы вне её области.

Отчёт семинара IoTSU, RFC 8240, сохраняет вопросы собственности, согласия, восстановления, окончания поддержки и определения успеха. Это не стандарт, но он показывает, почему жизненный цикл шире подписи.

Подход Heng Lu разделяет минимальную спецификацию, локальное решение, добровольное принятие, исполнение и наблюдаемый итог. RFC дают общий язык. Политика распределяет власть; код исполняет; наблюдение подтверждает или заново открывает решение.

Сообщение о завершении должно остаться истинным в своей фазе. Право установки и успешный запуск требуют собственных доказательств.

Источники