Кратко

  • Base-режим RFC 9180 создаёт шифрование для владельца заданного закрытого KEM-ключа получателя. Успех Open() подтверждает принятие данных в конкретном контексте, а не личность или мандат удалённой стороны.
  • PSK, Auth и AuthPSK добавляют ограниченное доказательство владения настроенным секретом либо ключом. Они не создают сами по себе реестр идентичностей, формат сообщения, защиту от повторов, правило отзыва или бизнес-разрешение.
  • Надёжный журнал должен вести цепочку от выбора ключа через режим, suite, контекст и разбор сообщения к проверке свежести, политике и наблюдаемому результату. Нельзя выдавать середину цепочки за её конец.

Представим два события в журнале. Первое: служба получила enc и ciphertext. Второе: библиотека вернула plaintext. Между ними и последующим изменением реальной системы нередко исчезает целая последовательность решений. Кто выбрал открытый ключ получателя? Кто привязал ключ отправителя к организации? По какому формату прочитали поля? Почему старое сообщение не является повтором? Какая политика разрешила исполнение?

RFC 9180 не скрывает эти вопросы внутри криптографии. Он описывает Hybrid Public Key Encryption как композицию KEM, KDF и AEAD. KEM формирует и восстанавливает общий секрет; KDF выводит материал контекста; AEAD защищает plaintext вместе с выбранными ассоциированными данными. Это общий, проверяемый механизм. Это не система распределения ролей, не транспортный конверт и не журнал управленческого согласия.

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

Что знает получатель в режиме Base

HPKE ciphersuite — это тройка KEM, KDF и AEAD. В Base отправитель строит контекст из открытого ключа получателя pkR и переданного приложением info. Получатель обрабатывает пришедший enc своим соответствующим skR и тем же контекстом. При совместимых входах он получает контекст, в котором можно открыть содержимое.

Корректный вывод узок: эти байты были приняты при данной suite, данном контексте и данном ключе получателя. В этой формуле нет ключа отправителя и нет общего PSK. Любой, кому известен публичный ключ получателя, способен создать Base-шифротекст для него. Таблица свойств RFC 9180 не приписывает Base аутентификацию отправителя именно по этой причине.

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

AAD не меняет границу. Приложение может привязать к ciphertext идентификатор арендатора, версию или номер операции, и изменение байтов вызовет отказ. Но HPKE не определяет, верен ли идентификатор и имеет ли отправитель право его предъявлять. Целостность выбранного утверждения не равна праву делать это утверждение.

Режим Auth не превращает ключ в должность

PSK даёт получателю подтверждение владения заданным предварительно разделяемым секретом. Auth связывает гарантию с владением закрытым KEM-ключом отправителя. AuthPSK использует оба материала. В корректно спроектированной системе это полезные дополнительные свойства.

Однако протокол подтверждает владение материалом, а не автоматически юридическое или организационное имя. Один и тот же ключ может быть привязан к человеку, сервисной учётной записи, HSM, общей роли или подрядчику. Такая привязка живёт в процессах выпуска, хранения, смены, отзыва и определения области действия. Она не выходит из AuthDecap().

RFC 9180 прямо указывает, что Auth и AuthPSK аутентифицируют пару ключей отправителя, а не иной идентификатор. Если приложению нужно связать сообщение с доменом, адресом или именем организации, оно должно включить этот идентификатор в info. Значит, кто выбирает значение, кто проверяет его и когда связь прекращается, должны быть видимыми решениями приложения.

У гарантии есть и криптографическое условие: RFC описывает ограничение key-compromise impersonation для вариантов DHKEM Auth/AuthPSK при названных им условиях компрометации ключа получателя. Поэтому результат Auth нельзя превратить в бессрочное доказательство авторства или универсальную неотказуемость. Это ограниченная гарантия для конкретного состояния ключей и модели угроз.

Самая опасная подмена происходит в аудите. Поле auth_success может честно описывать пройденную проверку владения. Формулировка «партнёр одобрил запрос» требует ещё действующей привязки ключа к партнёру, полномочия на этот класс сообщений и решения политики по содержимому. Убрав эти ступени из журнала, команда убирает не риск, а его владельца.

Конверт, порядок и срок не поставляются вместе с шифрованием

info несёт аутентифицированную информацию при построении контекста, AAD — при отдельном Seal() или Open(). Это помогает привязать данные приложения к правильному масштабу. Но RFC 9180 не задаёт wire format сообщений HPKE. Приложение обязано недвусмысленно определить размещение enc, ciphertext, их порядка и неявных значений info; при нескольких ключах получателя может понадобиться и явный выбор ключа.

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

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

Особенно важна свежесть. В одном контексте RFC даёт ограниченную защиту от replay, требуя открывать сообщения в том порядке, в каком они были запечатаны. За пределами такого потока другой replay-защиты нет. Многосообщенческое приложение само вводит последовательность, неизменный идентификатор, окно времени или идемпотентность и связывает нужные данные с AAD.

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

Есть и ретроспективная граница: RFC 9180 не даёт forward secrecy при компрометации ключа получателя. Последующее получение долгоживущего секрета может позволить открыть старые сообщения, зашифрованные для него. Это не утверждение о чьём-либо компромиссе; это факт, который должны учитывать сроки хранения, ротация, классификация архивов и расследование.

Доказательная цепь до реального эффекта

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

При подготовке фиксируйте mode, suite, происхождение PSK либо ключа отправителя, info, AAD, конверт и выбор алгоритмов. При получении — безопасную ссылку на enc и ciphertext, выбранный ключ, результат построения контекста и Open(). Последний остаётся отдельным техническим фактом.

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