Принципы проектирования защищенных протоколов

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

Абади и Нидхем (1994 г.) сформулировали практические уроки проектирования протоколов в виде набора принципов. (1) Каждое сообщение должно объяснять своё значение: его интерпретация должна быть самодостаточной и не зависеть от контекста. (2) Условия, при которых участник должен выполнить действие, должны быть явно указаны в протоколе. (3) Если идентичность участника важна, она должна быть явно указана в сообщении. (4) Чётко определяйте цель шифрования: шифрование обеспечивает конфиденциальность, а подпись — аутентификацию; не используйте шифрование вместо подписи. (5) Сообщение следует шифровать на том уровне протокола, на котором требуется его секретность. Эти принципы предотвратили множество уязвимостей типа NS.

Атаки с повторным воспроизведением относятся к наиболее распространённым уязвимостям протоколов. Механизмы свежести гарантируют, что полученное сообщение было создано недавно, а не повторно воспроизведено из старого сеанса. Используются два подхода: (1) Одноразовые числа (числа, использованные ONCE) — схема «вызов — ответ», в которой получатель отправляет случайное значение и ожидает его возврата в ответе. Ответ должен содержать одноразовое число в зашифрованном или подписанном виде, чтобы старая запись обмена не могла пройти проверку. (2) Временные метки — обе стороны указывают текущее время; сообщение с устаревшей временной меткой отклоняется. Для временных меток требуются синхронизированные часы (Kerberos допускает расхождение в 5 минут). Одноразовые числа предпочтительнее, когда синхронизация часов недоступна; временные метки упрощают проверку без хранения состояния.

Использование одного криптографического ключа для нескольких целей создаёт опасные взаимосвязи. Если ключ K используется одновременно для шифрования и аутентификации, противник может подавать специально сформированные шифротексты механизму аутентификации, чтобы извлекать информацию. TLS 1.3 строго избегает этого с помощью HKDF-Expand-Label с отдельными метками для каждого производного ключа: «c hs traffic» (рукопожатие клиента), «s hs traffic» (рукопожатие сервера), «c ap traffic» (приложение клиента). Даже если ключ рукопожатия скомпрометирован, ключи приложения, полученные из другой ветви HKDF, остаются защищёнными. При проектировании протокола необходимо проверять каждый ключ на риски многократного использования и выводить отдельные ключи для отдельных целей.

Учетные данные аутентификации должны быть привязаны к конкретному сеансу, в котором они используются. Без такой привязки учетные данные, полученные в одном сеансе, можно воспроизвести в другом. Методы: (1) включать идентификаторы сеанса в данные, подписанные или аутентифицированные с помощью MAC. (2) включать транскрипт DH в подпись (подход STS). (3) использовать производный от HKDF ключ сеанса для вычисления MAC по идентификатору (подход SIGMA). Сообщение Finished в TLS 1.3: MAC(server_finished_key, transcript_hash) — MAC охватывает полный транскрипт, поэтому воспроизведение Finished из другого сеанса завершается неудачей. Именно эта привязка предотвращает межсеансовые атаки, обнаруженные в ранних вариантах Kerberos и NS.

Протоколы должны раскрывать только минимальный объем информации, необходимый для их работы. Раскрывайте идентичности только тем, кому они нужны. Не включайте серийные номера сертификатов или идентификаторы, позволяющие связать сеансы с идентичностями, если это не требуется. TLS 1.3 шифрует сертификат сервера (в отличие от TLS 1.2, где он передается в открытом виде), уменьшая объем сведений, доступных пассивному прослушивающему. ESNI (зашифрованный SNI, теперь ECH — зашифрованное приветствие клиента) шифрует указание имени сервера, чтобы скрыть, к какому серверу подключается клиент. Минимальное раскрытие информации — также принцип проектирования токенов: утверждения JWT должны содержать только необходимое для авторизации, а не полные записи об идентичности.

Согласование версии — распространенная поверхность атаки: злоумышленник удаляет или изменяет ClientHello, чтобы заставить обе стороны использовать более старую и слабую версию протокола. Защита включает: (1) аутентифицированное согласование версии — включать согласованную версию в подписанный транскрипт (сообщение Finished в TLS включает ClientHello, в том числе версию); (2) маркеры понижения — TLS 1.3 устанавливает специальные байты в ServerHello.Random при переходе на TLS 1.2, чтобы клиент мог обнаружить понижение; (3) предотвращение проблем с поддержкой версий — серверы должны отклонять некорректные ClientHellos, не выполняя молчаливый переход на запасной вариант; (4) SCSV — TLS_FALLBACK_SCSV сообщает серверу, что клиент повторяет попытку с более низкой версией, позволяя серверу отклонить неправомерный переход.

Сообщения протокола должны быть зафиксированы начиная с первого обмена. Немодифицируемость означает, что злоумышленник не может изменить шифротекст или подпись так, чтобы они прошли проверку в другом контексте. AEAD обеспечивает немодифицируемость шифротекста — любое изменение делает тег аутентификации недействительным. На уровне протокола хеширование транскрипта гарантирует, что обмен Finished в конце рукопожатия фиксирует каждое отправленное сообщение. Это предотвращает атаки «вырезать и вставить»: объединение сообщений из двух разных сеансов не может дать корректное значение Finished ни для одного из них. Схемы фиксации (криптографические фиксации на основе хеша) расширяют этот подход на потоки протокола, требующие предварительной фиксации до раскрытия.

Сложные протоколы часто дают сбои на границах состояний. Если переход между состояниями неоднозначен — что произойдет, если сообщение 3 поступит раньше сообщения 2? что если поступит неожиданный тип сообщения? — реализации могут разойтись, создавая несогласованности, которыми злоумышленник способен воспользоваться. Спецификации протоколов должны определять: полный автомат состояний (все состояния и допустимые переходы), поведение при неожиданных входных данных (отклонять их с конкретной ошибкой или молча игнорировать), тайм-ауты и ограничения на повторную передачу, а также очистку сеанса. SSL/TLS исторически страдал от расхождений реализаций автоматов состояний — CVE-2014-0160 (Heartbleed) был по сути сбоем автомата состояний: запрос heartbeat обрабатывался в состоянии, где объем памяти не был надлежащим образом ограничен.

Криптографические протоколы редко используются изолированно. Протокол AKE устанавливает ключ сеанса, который затем используется протоколом прикладного уровня. Если AKE и прикладной протокол спроектированы независимо, без учета компонуемости, их взаимодействие может нарушить безопасность. Среда универсальной компонуемости (UC) (Canetti, 2001) предоставляет строгую модель композиции протоколов: протокол является безопасным в модели UC, если он остается безопасным при произвольной композиции с другими протоколами, безопасными в модели UC. TLS 1.3, Signal и Noise ориентированы на композиционную безопасность. На практике используйте связывание канала (экспортируйте хеш транскрипта), чтобы связать сеанс AKE с последующей аутентификацией приложения и предотвратить передачу учетных данных между сеансами, установленными одним и тем же протоколом AKE.

Разработчики протоколов снова и снова допускают одни и те же типы ошибок. (1) Криптография собственного изготовления: реализация собственных блочных шифров, MAC или механизмов выработки ключей без экспертной проверки. (2) Неявное доверие: предположение об источнике сообщения на основании сетевого контекста, а не криптографического доказательства. (3) Необязательная безопасность: возможность настраивать шифрование или аутентификацию, что неизбежно ведет к понижению уровня безопасности. (4) Токены с длительным сроком действия без отзыва: выдача JWT или ключей сеанса с большим сроком действия и без механизма отзыва. (5) Игнорирование канала ошибок: отсутствие аутентификации сообщений об ошибках позволяет злоумышленнику внедрять ошибки и влиять на поведение протокола. (6) Использование шифрования для аутентификации: шифрование данных не подтверждает источник без MAC или подписи.

Согласно принципам Абади—Needham, почему сообщение должно явно содержать идентичность отправителя, если идентичность имеет значение?

Безопасное проектирование протоколов опирается на установленные принципы: модель противника Dolev—Yao (противник, контролирующий сеть), принципы Абади—Needham (явная идентичность, самодостаточные сообщения), обеспечение свежести с помощью одноразовых значений или временных меток, разделение ключей посредством HKDF с различными метками, привязка учетных данных аутентификации к сеансу, минимальное раскрытие информации, предотвращение понижения версии с помощью аутентификации транскрипта, немодифицируемость благодаря AEAD и хешированию транскрипта, четкие автоматы состояний с определенной обработкой ошибок и компонуемость, подтверждаемая доказательствами безопасности в модели UC. Нарушения этих принципов являются источником почти всех известных криптографических уязвимостей на уровне протокола.