Кратко

  • Индивидуальный проект от 27 октября требует, чтобы получатель BPSec заранее связывал каждую обязательную услугу защиты для каждого целевого блока с уполномоченным источником и его ключом. Действительная защита от другого законного узла не выполняет это требование.
  • Блок целостности полезной нагрузки должен охватывать первичный блок в рамках той же проверки. Два настоящих блока, проверенных по отдельности, могут происходить из разных Bundle.

Законный узел занял чужое место

В сети с задержками и разрывами связи пакет Bundle может пройти через несколько промежуточных узлов. У каждого бывают собственные ключи и разрешённые задачи. Один такой узел способен заменить защищённую исходным отправителем полезную нагрузку, создать новый Block Integrity Block, BIB, своим настоящим ключом и отправить результат дальше. Получатель проверит подпись и получит положительный ответ. Если его единственный критерий — «подписал законный участник», подмена останется за кадром.

RFC 9172, раздел 8.2.2, прямо разбирает эту возможность. Стандарт допускает несколько источников безопасности в одном Bundle и отдаёт выбор политики конкретной сети. Он описывает способ прикрыть исходный BIB блоком конфиденциальности, BCB. Но если получатель принимает BCB от любого разрешённого узла, посредник с настоящим ключом может заново защитить изменённое содержимое. Алгоритм подписи не ошибся; получатель присвоил результату слишком широкое значение.

Проект Н. Д. С. Гуптхаа переносит контроль на принимающую сторону. Для конкретной обязательной услуги на конкретном блоке локальная политика должна назвать ожидаемый Security Source и связанный с ним ключевой материал. Полученный BIB или BCB засчитывается только после проверки этим заранее указанным материалом. Иной узел может быть законным и полезным участником сети, но не исполнителем чужого требования целостности.

IETF Datatracker показывает редакцию 00 как индивидуальный Internet-Draft без статуса RFC и без одобрения IETF. Документ предлагает правила для получателя; в нём нет отчёта о применении в названной действующей сети.

Список доверенных ключей не заменяет распределение полномочий

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

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

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

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

Две подлинные страницы ещё не один документ

Правило R5 касается другой подмены. Один BIB может защищать полезную нагрузку, второй — отдельно первичный блок Bundle. Оба блока могут успешно пройти проверку и даже быть созданы одним отправителем. Если они взяты из двух разных Bundle, их соединение всё равно не удостоверено. Два подлинных листа не становятся единым подписанным договором от того, что их положили в одну папку.

Поэтому BIB самой полезной нагрузки должен включать первичный блок в собственную область целостности. RFC 9173, раздел 3.3.3, задаёт для этого бит 0; при отсутствии параметра действует значение 7, которое тоже включает первичный блок. Отдельный BIB над первичным блоком не заменяет общую защиту. RFC 9171 определяет структуру Bundle: первичный блок несёт сведения об идентичности и обработке, а блок полезной нагрузки — прикладные данные. Важен факт совместной защиты именно этих двух частей.

Проверка должна сохранять свой предмет

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

Уже сейчас оператору полезно отказаться от одной зелёной лампочки «подпись верна». Ему нужны источник, услуга, целевой блок, ожидаемый ключ и область, которую действительно защищал BIB. Иначе зелёная лампочка вежливо заверит чужую посылку.

Источники