Кратко

  • RFC 5402 добавляет CMS-компрессию в многослойные EDIINT-сообщения; её положение определяет, какие байты подписываются и входят в MIC.
  • RFC 3274 предупреждает, что совместное сжатие секретных и недоверенных данных до шифрования может раскрывать информацию по коэффициенту сжатия.
  • Успешные расшифрование, подпись и MIC подтверждают свои границы, но не доказывают отсутствие утечки длины, корректную обработку документов или коммерческое принятие.

Зелёная криптография и незамеченный боковой канал

Контрольные проверки сработали именно так, как были настроены. Сертификат считался доверенным, подпись сошлась, зашифрованная оболочка раскрылась, MIC совпал. Ни один из этих результатов не был ложным.

Ложным оказался итоговый вывод «конфиденциальность доказана полностью». Компрессор уже превратил сходство между секретом и управляемой частью входа в изменение длины. Шифрование скрыло значения байтов, но сохранило общую длину результата. При повторяемых наблюдениях это может стать источником информации.

RFC 5402 опубликован в феврале 2010 года как Informational в Independent Stream. Его IESG Note подчёркивает, что документ не относится к Standards Track и требует осторожности при оценке применения. Он описывает использование RFC 3274 CMS CompressedData внутри AS1, AS2 и AS3, а не утверждает безопасность любой конкретной композиции.

Компрессия — это преобразование до проверки

EDIINT-сообщение может включать полезное содержимое, подпись и шифрование. RFC 5402 добавляет ещё один слой. Для подписанного документа отправитель может сжать внутренний MIME и затем подписать compressed-data. Либо он может сначала создать multipart/signed, а затем сжать весь подписанный блок.

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

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

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

Предупреждение RFC 3274 не является доказательством атаки

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

Из этого нельзя заключить, что каждое EDIINT-сообщение уязвимо или что атака произошла. Источники не содержат данных о конкретном продукте, трафике или инциденте. Но предупреждение достаточно, чтобы не принимать encrypted=true за закрытие анализа.

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

Сигнал длины также должен храниться осторожно. Телеметрия, которая регистрирует точные размеры и коррелирует их с бизнес-событиями, сама может расширить круг наблюдателей.

ZLIB-совместимость не описывает контекст

RFC 5402 требует поддержки ZLIB, использующего DEFLATE. RFC 3274 задаёт CMS content type и идентификатор алгоритма. Уровень компрессии не передаётся как параметр, поскольку разные уровни совместимы с одной декомпрессией.

При этом исторически AlgorithmIdentifier встречается с отсутствующим параметром или с ASN.1 NULL. Получатели могут увидеть обе формы. Этот небольшой пример показывает предел слова «поддерживается»: оно не раскрывает строгость декодера, лимит размера, порядок MIME, canonicalization или политику ошибок.

RFC 5402 требует значение версии AS2 или AS3 не ниже 1.1 при использовании профиля. Версия и capability указывают на доступную функцию. Разрешение по договору, включённая настройка и успешный результат конкретного сообщения остаются отдельными событиями.

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

Транспортная форма создаёт несколько размеров

Если бинарный compressed-data находится во внешнем слое семибитного транспорта вроде SMTP, ему нужен base64 Content-Transfer-Encoding. Если он заключён внутрь зашифрованного MIME, base64 применяется к внешней шифрованной части.

Следовательно, существуют размер исходного MIME, размер сжатого CMS, размер шифрованной оболочки и размер base64-представления. Для анализа утечки важно не смешивать их. Наблюдатель на разных участках видит разные метрики.

Для целостности тоже важна стадия. В неподписанных сжатых случаях RFC 5402 задаёт MIC по распакованному содержимому с MIME-заголовками и применённым Content-Transfer-Encoding. RFC 4130 добавляет canonicalization. Хеш финального XML не заменяет этот расчёт.

Хранилище должно связывать стадию, размер, хеш и преобразование. Иначе изменение base64-переноса может выглядеть как изменение коэффициента компрессии, а изменение данных — как обычная смена транспорта.

Отрицательный MDN не становится бизнес-решением

Если декомпрессия не удалась и был запрошен receipt, RFC 5402 использует в подписанном MDN Error: decompression-failed. Проверенная подпись делает этот отчёт атрибутируемым: партнёр утверждает, что не смог пройти слой компрессии.

Это не означает, что он прочитал и отверг заказ. Возможно, бизнес-документ не был получен. Ошибка также не указывает единственную причину: повреждение, ограничение ресурсов, несовместимая форма или неверная настройка остаются возможными.

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

Технический сбой должен сохранить входные байты и запустить воспроизведение. Универсальный статус «отклонено» создаёт риск повторной отправки и дублирования, одновременно скрывая точный диагноз.

Общий MIC и отдельные документы

RFC 6362 позволяет multipart/related с несколькими вложениями. Для сжатого неподписанного сообщения MIC рассчитывается по всему распакованному multipart после транспортной canonicalization. При несовпадении все вложения считаются недействительными и требуют повторной передачи.

После успешной проверки каждое вложение проходит собственный путь. XML проверяется по схеме, PDF архивируется, изображение может быть запрещено политикой. Хранение и транзакционная обработка оставлены реализации.

Нужен родительский receipt для общей оболочки и дочерние receipts для Content-ID, извлечённого хеша, parser, проверки и решения. Групповая целостность не превращает каждый файл в допустимый, а ошибка приложения не переписывает криптографическую историю оболочки.

Полная граница безопасности длиннее флага encryption

Цепочка начинается с соглашения партнёров и разрешённого профиля. Затем сохраняются исходный MIME, canonicalization, идентификатор компрессии, расположение слоя, подписанные и зашифрованные байты. На приёме фиксируются transfer decoding, расшифрование, декомпрессия, подпись и MIC.

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

Стандарты не доказывают атаку или поведение текущего вендора. Они показывают, почему успешно пройденные криптографические проверки не дают права удалить из отчёта риск, возникший на предыдущем преобразовании.