Структура протокола шума

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Вводный раздел этой статьи может быть слишком длинным .Пожалуйста, ознакомьтесь с правилами по объему и помогите перенести детали в текст статьи. ( Декабрь 2024 ) Эта статья может потребовать редактирования с точки зрения грамматики, стиля, связности, тона или орфографии .Вы можете помочь, отредактировав его . ( Декабрь 2024 )( Узнайте, как и когда удалить это сообщение ) Тон или стиль этой статьи может не отражать энциклопедический тон , используемый в Википедии .Рекомендации см. в руководстве Википедии по написанию лучших статей . ( Декабрь 2024 )( Узнайте, как и когда удалить это сообщение ) В этой статье содержатся инструкции, советы или практические советы .Пожалуйста, помогите переписать контент, сделав его более энциклопедическим, или перенесите его в Викиверситет, Викиучебники или Викигид. ( Декабрь 2024 ) ( Узнайте, как и когда удалить это сообщение )

Noise Protocol Framework , иногда называемый Noise или Noise Framework , позволяет проектировать протоколы защищенных каналов между двумя сторонами. По сравнению с TLS 1.3 , Noise Framework (описанный в общедоступной спецификации ^[1] ) позволяет выбирать шаблон рукопожатия и криптографические алгоритмы для создания конкретного протокола, имеющего наиболее подходящие криптографические свойства и компромиссы для поставленной задачи, например, поведение RTT. Noise является основой некоторых протоколов со значительным развертыванием, таких как Nebula Slack, ^[2] WhatsApp и WireGuard .

Протокол безопасного канала состоит из двух фаз:

• фаза рукопожатия: аутентифицирует и устанавливает общие секретные ключи с использованием обмена ключами Диффи-Хеллмана (DH) для аутентифицированного обмена ключами (AKE)
• фаза транспортировки: использует общие секретные ключи для шифрования данных

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

В спецификации перечислены три шаблона одностороннего рукопожатия и 12 основных интерактивных шаблонов рукопожатия. Существуют вариации некоторых из них:

• отложенные шаблоны, где аутентификация DHs откладывается до следующего сообщения. Цифра 1используется после первого и/или второго символа, например NK1илиX1X1
• предварительно общий симметричный ключ для поддержки протоколов, где обе стороны имеют 32-байтовый общий секретный ключ, например Npsk0илиXpsk1
• составные протоколы, в которых роли инициатора и ответчика меняются местами в качестве механизма переговоров через fallbackмодификатор. Шумовая труба — пример, найденный в §10.4 ^[3]

Реальный пример — WireGuard, конструкция которого описана на странице 10 Белой книги Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s.

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

Спецификация описывает API в §5 ^[4] с использованием следующих объектов, каждый из которых имеет небольшой набор методов :

• Объект CipherStateсодержит k и n переменных, которые он использует для шифрования и дешифрования шифротекстов. Во время фазы рукопожатия каждая сторона имеет один CipherState, но во время фазы транспортировки каждая сторона имеет два CipherStateобъекта: один для отправки и один для получения.
• Объект SymmetricStateсодержит переменные CipherStateck и h . Он так назван, потому что инкапсулирует все «симметричное крипто», используемое Noise. Во время фазы рукопожатия у каждой стороны есть один , который может быть удален после завершения рукопожатия.SymmetricState
• Объект HandshakeStateсодержит SymmetricStateплюс переменные DH ( s , e , rs , re ) и переменную, представляющую шаблон рукопожатия. Во время фазы рукопожатия каждая сторона имеет один HandshakeState, который может быть удален после завершения рукопожатия.

Реализация конкретного протокола включает в себя проектирование представления сообщений, а также аспекты за пределами Noise Framework. Пример последнего происходит с протоколами, использующими транспорты UDP , такими как WireGuard , который использует скользящее окно для обработки прибытия вне очереди.

Свойства безопасности нескольких шаблонов рукопожатия описаны в Спецификации и могут поддерживать взаимную аутентификацию, прямую секретность, нулевое круговое шифрование, сокрытие личности и другие расширенные функции. Формальный криптографический анализ общих шаблонов рукопожатия появился в академической литературе. ^{[5] [6]} Вторая попытка привела к созданию онлайн-инструмента Noise Explorer. ^[7]

Большая часть нижеследующего текста представляет собой выдержки из Спецификации с форматированием:

• IKдля имен протоколов, состоящих из шаблонов рукопожатия, криптографии и модификаторов
• ck для переменных в машине состояний рукопожатия
• e для токенов в шаблоне сообщения
• § префиксы ссылок на разделы в Спецификации

с акцентом на:

• образцы рукопожатия
• свойства безопасности и компромиссы
• обязанности по применению и соображения безопасности

Фреймворк был разработан Тревором Перрином при поддержке Мокси Марлинспайка на основе работы, проделанной в Open Whisper Systems .

« Шум » относится к одному из обоснований дизайна: ^[8]

Шифрованные тексты должны быть неотличимы от случайных, потому что:

Это упрощает использование протоколов Noise со случайным заполнением (для сокрытия длины) или для устойчивых к цензуре "неотпечатываемых" протоколов или со стеганографией . Однако следует отметить, что эфемерные ключи, скорее всего, будут отличимы от случайных, если не используется такая техника, как Elligator. ^[9]

Возможно, это также игра слов на слово Signal (программное обеспечение) .

Большинство протоколов защищенных каналов используют AKE на основе подписей (для аутентификации) и Diffie-Hellman (для обмена ключами). В последние 10–15 лет растет интерес к AKE на основе DH (без подписей).

• Теория: Кудла-Патерсон, ^[10] НАКСОС, ^[11] Нтор ^[12]
• Практика: Ntor; ^[12] NaCl , CurveCP , DNSCurve , OPTLS ^[13]

Элегантный, но каждый протокол начинается с нуля

• Идея №1: Объединить простые элементы для создания разных протоколов
• ^{Идея №2: Использовать симметричную криптографию типа «губка» (идея из [14]} Strobe ^[15] Майка Гамбурга )

Первоначальный коммит для спецификации был сделан 4 августа 2014 года ^[16] и претерпел множество изменений после обсуждения в списке рассылки до rev34 11 июля 2018 года. ^[17] Примечание: первоначально поддерживался в Wiki, начиная с 10 февраля 2013 года. ^[18]

Чтобы создать имя Noise Protocol, Initialize()вам нужно объединить строку ASCII Noise_с четырьмя секциями имен, разделенными подчеркиванием, которые последовательно называют шаблон рукопожатия, функции DH, функции шифрования и затем хэш-функции. Результирующее имя должно быть 255 байт или меньше. ^[19] Примеры:

• Noise_XX_25519_AESGCM_SHA256
• Noise_N_25519_ChaChaPoly_BLAKE2s
• Noise_IK_448_ChaChaPoly_BLAKE2b

Каждый раздел имени должен состоять только из буквенно-цифровых символов (т. е. символов из одного из диапазонов «A»...«Z», «a»...«z» и «0»...«9»), а также двух специальных символов «+» и «/».

К каждому разделу имени применяются дополнительные правила, как указано ниже.

Раздел имени шаблона рукопожатия содержит имя шаблона рукопожатия и последовательность из нуля или более модификаторов шаблона. ^[20]

Имя шаблона рукопожатия должно быть заглавной строкой ASCII, содержащей только буквенные символы или цифры (например, XX1или IK).

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

Модификатор шаблона именуется строчной буквенно-цифровой строкой ASCII, которая должна начинаться с буквенного символа (не цифры). Модификатор шаблона добавляется к базовому шаблону, как описано ниже:

Первый модификатор, добавленный к базовому шаблону, просто добавляется. Таким образом, fallbackмодификатор, добавленный к XXшаблону, производит XXfallback. Дополнительные модификаторы разделяются знаком плюс. Таким образом, добавление psk0модификатора приведет к разделу имени XXfallback+psk0или полному имени протокола, например Noise_XXfallback+psk0_25519_AESGCM_SHA256.

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

Правила для разделов DH, шифра и имени хеша идентичны. Каждый раздел имени должен содержать одно или несколько имен алгоритмов, разделенных знаками плюс. ^[21]

Каждое имя алгоритма должно состоять исключительно из буквенно-цифровых символов и символа косой черты ("/"). Рекомендуется, чтобы имена алгоритмов были короткими, а символ "/" использовать только при необходимости, чтобы избежать двусмысленности (например, SHA3/256предпочтительнее, чем SHA3256).

В большинстве случаев в каждом разделе имени будет одно имя алгоритма (т.е. без знаков плюс). Несколько имен алгоритмов используются только тогда, когда это требуется шаблоном или модификатором.

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

В Спецификации перечислены 8 современных алгоритмов со следующими названиями. ^{[22] [23]}

В Wiki есть этот список неофициальных алгоритмов; ^[24] Я опустил постквантовые алгоритмы, поскольку записи появились до начала работы NIST по стандартизации постквантовой криптографии, начатой ​​в 2016 году с первыми тремя постквантовыми криптостандартами: FIPS 203, FIP 204 и FIP 205 в 2024 году.

Здесь мы ^{[ кто? ]} документируем некоторые названия, которые могут быть использованы для нестандартных алгоритмов, чтобы экспериментальное использование этих алгоритмов могло использовать согласованные названия (ПРИМЕЧАНИЕ: ни один из этих алгоритмов не одобрен для использования с Noise, используйте на свой страх и риск).

Noise Protocols имеют входной пролог, который позволяет хешировать произвольные данные в переменную h. Если обе стороны не предоставят идентичные данные пролога, рукопожатие не будет выполнено из-за ошибки расшифровки. Это полезно, когда стороны участвуют в переговорах до рукопожатия и хотят убедиться, что они разделяют идентичные взгляды на эти переговоры. ^[34]

Например, предположим, что Боб сообщает Алисе список протоколов шума, которые он готов поддерживать. Затем Алиса выберет и выполнит один протокол. Чтобы гарантировать, что «человек посередине» не отредактирует список Боба, удалив опции, Алиса и Боб могут включить этот список в качестве данных пролога.

Обратите внимание, что хотя стороны подтверждают идентичность своих прологов, они не смешивают данные пролога с ключами шифрования. Если вход содержит секретные данные, предназначенные для усиления шифрования, вместо этого следует использовать рукопожатие PSK (см. §9).

Следующие шаблоны рукопожатий представляют собой «односторонние» рукопожатия, поддерживающие односторонний поток данных от отправителя к получателю. Эти шаблоны могут использоваться для шифрования файлов, записей базы данных или других неинтерактивных потоков данных. ^[35]

После одностороннего рукопожатия отправитель может отправить поток транспортных сообщений, зашифровав их с помощью первого CipherState, возвращаемого из . Split()Второй CipherState из Split()отбрасывается — получатель не должен отправлять никаких сообщений с его помощью (так как это нарушит правила в §7.3).

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

• N= Нет статического ключа для отправителя
• K= Статический ключ для инициатора K , известный ответчику
• X= Статический ключ отправителя X передан получателю

N:

<- с ... -> е , ес

K:

-> с <- с ... -> е , ес , сс

X:

<- с ... -> е , ес , с , сс

Nявляется обычным шифрованием с открытым ключом на основе DH. Другие шаблоны добавляют аутентификацию отправителя, где открытый ключ отправителя либо известен получателю заранее ( K), либо передается в зашифрованном виде ( X).

Следующие шаблоны рукопожатия представляют интерактивные протоколы. Эти 12 шаблонов называются «фундаментальными» интерактивными шаблонами рукопожатия. ^[36]

Основные интерактивные шаблоны именуются двумя символами, которые указывают на статус статических ключей инициатора и ответчика:

Первый символ относится к статическому ключу инициатора:

• N= No статический ключ для инициатора
• K= Статический ключ для инициатора, Kизвестный ответчику
• X= Статический ключ для инициатора Xпередан («передан») ответчику
• I= Статический ключ для инициатора Iнемедленно передается ответчику, несмотря на сниженное или отсутствующее сокрытие личности

Второй символ относится к статическому ключу ответчика:

• N= No статический ключ для ответчика
• K= Статический ключ для ответчика, Kизвестный инициатору
• X= Статический ключ для ответчика Xпередан («передан») инициатору

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

Для отправителя:

• 0. Нет аутентификации . Эта полезная нагрузка могла быть отправлена ​​любой стороной, включая активного злоумышленника.

Используется: IN#1, IN#2, IN#4, # IX1, #2, #3, #5, #2, #2, #4, #1, #2, #3, #1 , #3 , #2, #1, #2, #4, #1KNKNKNKXNKNKNNNNNNNXNXXKXNXNXNXX

• 1. Аутентификация отправителя уязвима для подмены ключа (KCI) . Аутентификация отправителя основана на статическом-статическом DH ( ss ), включающем статические пары ключей обеих сторон. Если долгосрочный закрытый ключ получателя был скомпрометирован, эта аутентификация может быть подделана. Обратите внимание, что будущая версия Noise может включать подписи, которые могут улучшить это свойство безопасности, но приносят другие компромиссы.

Используется: IK#2, IN#3, KK#3, KN#4, NK#3 NN, NN# NX2, XK#3, XN#2, #3, #2, XN#3, XX#2

• 2. Аутентификация отправителя , устойчивая к подмене ключей (KCI) . Аутентификация отправителя основана на эфемерно-статическом DH ( es или se ) между статической парой ключей отправителя и эфемерной парой ключей получателя. Если предположить, что соответствующие закрытые ключи защищены, эта аутентификация не может быть подделана.

Используется: IK#2, IK#3, IK#4, IK#5, IN#3 IX, # IX2 IX, KK#3, # 4 KK, #3, #4 KK, #5, KK#6, KN#4, #3 KX, # 4 KX, #5, #2, #3, #2, #3, #4, #5, # 3, #2 , #3, #4KXNKNKNXXKXKXKXKXNXXXXXX

Для получателя:

• 0. Никакой конфиденциальности . Эта полезная нагрузка отправляется в открытом виде.

Используется: IN#1, IN#2, IN#4, # IX1, #2, #3, #5, #2, #2, #4, #1, #2, #3, #1 , #3 , #2, #1, #2, #4, #1KNKNKNKXNKNKNNNNNNNXNXXKXNXNXNXX

• 1. Шифрование для эфемерного получателя . Эта полезная нагрузка имеет прямую секретность, поскольку шифрование включает эфемерно-эфемерный DH ( ee ). Однако отправитель не аутентифицировал получателя, поэтому эта полезная нагрузка может быть отправлена ​​любой стороне, включая активного злоумышленника.

Используется: IK#2, IN#3, KK#3, KN#4, NK#3 NN, NN# NX2, XK#3, XN#2, #3, #2, XN#3, XX#2

• 2. Шифрование для известного получателя, прямая секретность только для компрометации отправителя, уязвимость к повторному воспроизведению . Эта полезная нагрузка шифруется только на основе DH, включающих статическую пару ключей получателя. Если статический закрытый ключ получателя будет скомпрометирован, даже позднее, эта полезная нагрузка может быть расшифрована. Это сообщение также может быть воспроизведено, поскольку нет эфемерного вклада от получателя.

Используется: IK#2, IK#3, IK#4, IK#5, IN#3 IX, # IX2 IX, KK#3, # 4 KK, #3, #4 KK, #5, KK#6, KN#4, #3 KX, # 4 KX, #5, #2, #3, #2, #3, #4, #5, # 3, #2 , #3, #4KXNKNKNXXKXKXKXKXNXXXXXX

• 3. Шифрование для известного получателя, слабая прямая секретность . Эта полезная нагрузка зашифрована на основе эфемерно-эфемерного DH, а также эфемерно-статического DH с участием статической пары ключей получателя. Однако привязка между предполагаемым эфемерным открытым ключом получателя и статическим открытым ключом получателя не была проверена отправителем, поэтому предполагаемый эфемерный открытый ключ получателя мог быть подделан активным злоумышленником. В этом случае злоумышленник мог позже скомпрометировать статический закрытый ключ получателя, чтобы расшифровать полезную нагрузку. Обратите внимание, что будущая версия Noise может включать подписи, которые могли бы улучшить это свойство безопасности, но приносят другие компромиссы.

Используется: IN#2, IX#2, KN#3, KX#3

• 4. Шифрование для известного получателя, слабая прямая секретность, если закрытый ключ отправителя был скомпрометирован . Эта полезная нагрузка шифруется на основе эфемерно-эфемерного DH, а также на основе эфемерно-статического DH с участием статической пары ключей получателя. Однако привязка между предполагаемым эфемерным открытым ключом получателя и статическим открытым ключом получателя была проверена только на основе DH с участием как этих открытых ключей, так и статического закрытого ключа отправителя. Таким образом, если статический закрытый ключ отправителя был ранее скомпрометирован, предполагаемый эфемерный открытый ключ получателя мог быть подделан активным злоумышленником. В этом случае злоумышленник может позже скомпрометировать статический закрытый ключ предполагаемого получателя, чтобы расшифровать полезную нагрузку (это вариант атаки «KCI», позволяющий провести атаку «слабой прямой секретности»). Обратите внимание, что будущая версия Noise может включать подписи, которые могут улучшить это свойство безопасности, но приносят другие компромиссы.

Используется: IK#3, KK#4

• 5. Шифрование для известного получателя, сильная прямая секретность . Эта полезная нагрузка зашифрована на основе эфемерного-эфемерного DH, а также эфемерного-статичного DH с парой статических ключей получателя. Предполагая, что эфемерные закрытые ключи защищены, и получатель не выдает себя за другого злоумышленника, который украл его статический закрытый ключ, эта полезная нагрузка не может быть расшифрована.

Используется: IK#4, IK#5, IN#4 , # IX3, # 4 , # 5, #6 , # 5, #4 , #5 , #4, #3 , #4, #5, #4, #3, #4IXKKKKKNKXKXNKNXXKXKXNXXXX

В следующей таблице перечислены свойства сокрытия личности для всех шаблонов одностороннего рукопожатия в §7.4 и фундаментальных шаблонов рукопожатия в §7.5. Кроме того, мы перечислим несколько шаблонов отложенного рукопожатия, которые имеют другие свойства сокрытия личности, чем соответствующий фундаментальный шаблон. ^[37]

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

В этом разделе рассматривается только утечка личности через статические поля открытого ключа в рукопожатиях. Конечно, личности участников Noise могут быть раскрыты другими способами, включая поля полезной нагрузки, анализ трафика или метаданные, такие как IP-адреса.

Свойства соответствующего открытого ключа:

• 0. Передано открытым текстом.
• 1. Зашифровано с прямой секретностью, но может быть проверено анонимным инициатором.
• 2. Зашифровано с прямой секретностью, но отправлено анонимному ответчику.
• 3. Не передается, но пассивный злоумышленник может проверить кандидатов на закрытый ключ респондента и определить, является ли кандидат правильным. Злоумышленник также может воспроизвести ранее записанное сообщение новому респонденту и определить, являются ли два респондента «одними и теми же» (т. е. используют ли они одну и ту же статическую пару ключей) по тому, принимает ли получатель сообщение.
• 4. Зашифровано статическим открытым ключом ответчика, без прямой секретности. Если злоумышленник узнает закрытый ключ ответчика, он может расшифровать открытый ключ инициатора.
• 5. Не передается, но пассивный злоумышленник может проверить кандидатов на пару (закрытый ключ ответчика, открытый ключ инициатора) и узнать, является ли пара кандидатов правильной.
• 6. Зашифровано, но со слабой прямой секретностью. Активный злоумышленник, который выдает себя за инициатора без статического закрытого ключа инициатора, а затем позже узнает закрытый ключ инициатора, может расшифровать открытый ключ ответчика.
• 7. Не передается, но активный злоумышленник, который выдает себя за инициатора, не имея статического закрытого ключа инициатора, а затем узнает кандидата на закрытый ключ инициатора, может проверить, является ли кандидат правильным.
• 8. Зашифровано с прямой секретностью для аутентифицированной стороны.
• 9. Активный злоумышленник, который выдает себя за инициатора и записывает один запуск протокола, может затем проверить кандидатов на открытый ключ ответчика.

Основные шаблоны рукопожатия, описанные в предыдущем разделе, выполняют операции DH для аутентификации ( es и se ) как можно раньше. ^[38]

Можно описать дополнительный набор шаблонов рукопожатия, которые откладывают эти DH аутентификации до следующего сообщения. Чтобы назвать эти шаблоны отложенного рукопожатия, цифра 1используется после первого и/или второго символа в имени фундаментального шаблона, чтобы указать, что DH аутентификации инициатора и/или ответчика откладывается до следующего сообщения.

Отложенные шаблоны могут быть полезны по нескольким причинам:

• Инициатор может заранее знать статический открытый ключ ответчика, но не желать отправлять какие-либо зашифрованные данные 0-RTT.
• В некоторых случаях отсрочка аутентификации может улучшить свойства сокрытия личности при рукопожатии (см. §7.8).
• Будущие расширения Noise могут быть способны заменять операции DH подписями или шифротекстами KEM, но смогут сделать это только в том случае, если отправитель аутентифицирует себя (подписи) или отправитель аутентифицирует получателя (шифротексты KEM). Таким образом, каждый фундаментальный шаблон рукопожатия способен только заменить каждый аутентификационный DH подписью или шифротекстом KEM, но отложенные варианты делают обе замены возможными.

Ниже приведены два примера, показывающие фундаментальный шаблон рукопожатия слева и отложенный вариант(ы) справа. Полный набор из 23 отложенных шаблонов рукопожатия находится в Приложении §18. ^[39]

^[40]

До сих пор мы предполагали, что Алиса и Боб хотят выполнить один Noise Protocol, выбранный инициатором (Алисой). Однако есть ряд причин, по которым Боб может захотеть переключиться на другой Noise Protocol после получения первого сообщения Алисы. Например: ^[41]

Алиса могла выбрать протокол Noise, основанный на шифре, функции DH или шаблоне рукопожатия, которые Боб не поддерживает.

Алиса могла отправить зашифрованное начальное сообщение с «нулевым RTT» на основе устаревшей версии статического открытого ключа Боба или PSK.

Обработка этих сценариев требует составного протокола, в котором Боб переключается с исходного протокола Noise, выбранного Алисой, на новый протокол Noise. В таком составном протоколе роли инициатора и ответчика поменялись бы местами — Боб стал бы инициатором нового протокола Noise, а Алиса — ответчиком.

Составные протоколы значительно усложняют работу, поскольку Алисе необходимо объявить протокол Noise, с которого она начинает, и протокол(ы) Noise, на которые она может переключиться, и обеим сторонам необходимо договориться о безопасном переходе.

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

Noise Pipes поддерживают XXшаблон, но также позволяют Алисе кэшировать статический открытый ключ Боба и попытаться выполнить IKрукопожатие с шифрованием 0-RTT.

В случае, если Боб не сможет расшифровать первоначальное сообщение Алисы IK, он переключится на XXfallbackшаблон, который по сути позволяет сторонам завершить XXрукопожатие, как если бы Алиса отправила XXпервоначальное сообщение вместо IKисходного сообщения.

Модификатор fallbackпреобразует шаблон, инициированный Алисой, в шаблон, инициированный Бобом, преобразуя начальное сообщение Алисы в предварительное сообщение, которое Боб должен получить каким-то другим способом (например, через начальное IKсообщение от Алисы). После этого преобразования остальная часть шаблона рукопожатия интерпретируется как шаблон рукопожатия, инициированный Бобом. ^[42]

Например, вот fallbackмодификатор, применяемый для XXсоздания XXfallback:

XX:

-> е <- е , ee , s , es -> s , se

XXfallback:

-> е ... <- е , ее , с , ес -> с , се

Обратите внимание, что откат может быть применен только к шаблонам рукопожатия в форме, инициированной Алисой, где первое сообщение Алисы может быть интерпретировано как предварительное сообщение (т. е. оно должно быть либо e , s , либо « e , s »).

Типичный составной протокол для шифрования с нулевым RTT включает три различных протокола шума: ^[43]

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

Должен быть какой-то способ для Боба различать случаи полного и нулевого RTT при получении первого сообщения. Если Алиса делает попытку нулевого RTT, должен быть какой-то способ для нее различать случаи нулевого RTT и переключения при получении ответа.

Например, каждое сообщение о рукопожатии может предшествовать некоторым данным переговоров, таким как байт типа (см. §13). Эти данные не являются частью сообщения Noise, но сигнализируют, какой протокол Noise используется.

В этом разделе определяется протокол Noise Pipe. Следующие шаблоны рукопожатия удовлетворяют полным, нулевым RTT и ролям коммутатора, обсуждавшимся в предыдущем разделе, поэтому могут использоваться для предоставления полного рукопожатия с простой опцией нулевого RTT: ^[3]

XX:

-> е <- е , ee , s , es -> s , se

IK:

<- с  ... -> е , эс , s , ss <- е , ee , se

XXfallback:

-> е ... <- е , ее , с , ес -> с , се

Шаблон XXиспользуется для полного рукопожатия, если стороны ранее не общались, после чего Алиса может кэшировать статический открытый ключ Боба.

Шаблон IKиспользуется для установления связи с нулевым RTT.

Шаблон XXfallbackиспользуется для установления связи, если Бобу не удается расшифровать исходное IKсообщение (возможно, из-за смены статического ключа).

Электронное письмо от Тревора Перрина от 4 марта 2018 г. ^[44]

Я создал проект спецификации для фреймворка "NLS", который добавляет язык переговоров ("NoiseLingo") поверх NoiseSocket (отсюда "NoiseLingoSocket"). Он основан на идеях из 1. ^[45]

Для этого нужен измененный проект NoiseSocket с изменениями из 2 ^[46] (переименование нескольких вещей и изменение расчета пролога для дифференциации случая «повторной попытки» и добавления пролога приложения):

• Структура NLS ^[47]
• Протокол NoiseSocket ^[48]

В проекте NLS также определены некоторые «базовые профили», которые представляют собой высокоуровневые протоколы, используемые разработчиками приложений:

• NoiseLink (рукопожатие 1-RTT)
• NoiseZeroLink (рукопожатие 0-RTT)
• NoiseShortLink (для встроенных систем низкого уровня)
• NoiseAnonBox (шифрование с открытым ключом)
• NoseAuthBox (шифрование с открытым ключом + аутентификация отправителя)

Идея заключается в том, что NoiseLingo и NLS предоставляют вам меню полей согласования, из которых легко выбирать для создания профилей. Кроме того, эти профили будут иметь много общего и, таким образом, потенциал для взаимодействия (например, клиент NoiseZeroLink может общаться с сервером NoiseLink, откатываясь к 1-RTT). И если вы начнете с чего-то простого, например, NoiseLink, будет легко добавлять новые поля NLS и параметры согласования по мере обнаружения новых потребностей.

Приложение, построенное на Noise, должно учитывать несколько вопросов: ^[49]

• Выбор криптофункций : 25519Функции DH рекомендуются для типичного использования, хотя 448функции DH могут обеспечить дополнительную безопасность в случае разработки криптоаналитической атаки против эллиптической кривой криптографии. 448Функции DH следует использовать с 512-битным хешем, например SHA512, или BLAKE2b. 25519Функции DH можно использовать с 256-битным хешем, например SHA256, или BLAKE2s, хотя 512-битный хеш может обеспечить дополнительную безопасность в случае разработки криптоаналитической атаки против меньших хеш-функций. AESGCMтрудно реализовать с высокой скоростью и постоянным временем в программном обеспечении.
• Расширяемость : приложениям рекомендуется использовать расширяемый формат данных для полезных нагрузок всех сообщений (например, JSON, Protocol Buffers). Это гарантирует возможность добавления полей в будущем, которые игнорируются старыми реализациями.
• Padding Приложениям рекомендуется использовать формат данных для полезных нагрузок всех зашифрованных сообщений, который допускает padding. Это позволяет реализациям избегать утечки информации о размерах сообщений. Использование расширяемого формата данных, согласно предыдущему пункту, может быть достаточным.
• Завершение сеанса : приложения должны учитывать, что последовательность транспортных сообщений Noise может быть усечена злоумышленником. Приложения должны включать явные поля длины или сигналы завершения внутри транспортных полезных нагрузок, чтобы сигнализировать об окончании интерактивного сеанса или об окончании одностороннего потока транспортных сообщений.
• Поля длины : приложения должны обрабатывать любые поля кадрирования или дополнительные поля длины для сообщений Noise, учитывая, что сообщение Noise может быть длиной до 65535 байт. Если требуется явное поле длины, приложениям рекомендуется добавлять 16-битное поле длины big-endian перед каждым сообщением.
• Данные согласования : приложения могут захотеть поддержать передачу некоторых данных согласования до рукопожатия и/или до каждого сообщения рукопожатия. Данные согласования могут содержать такие вещи, как информация о версии и идентификаторы для протоколов Noise. Например, простой подход будет заключаться в отправке однобайтового поля типа перед каждым сообщением рукопожатия Noise. Более гибкие подходы могут отправлять расширяемые структуры, такие как protobufs. Данные согласования вносят значительную сложность и риски безопасности, такие как атаки отката (см. следующий раздел).

В этом разделе собраны различные соображения по безопасности: ^[50]

• Аутентификация : Протокол Noise со статическими открытыми ключами проверяет, что соответствующие закрытые ключи принадлежат участникам, но приложение должно определить, является ли статический открытый ключ удаленной стороны приемлемым. Методы для этого включают сертификаты, которые подписывают открытый ключ (и которые могут передаваться в полезных нагрузках рукопожатия), предварительно настроенные списки открытых ключей или подходы «закрепления» / «непрерывности ключей», когда стороны запоминают открытые ключи, с которыми они сталкиваются, и проверяют, представляет ли та же сторона тот же открытый ключ в будущем.
• Завершение сеанса : предотвращение прерывания потока передачи данных злоумышленниками
• Откат : Если стороны принимают решение о протоколе Noise на основе некоторых предыдущих переговоров, которые не включены в качестве пролога, то атака отката может быть возможна. Это особый риск для составных протоколов, и требует особого внимания, если рукопожатию Noise предшествует общение между сторонами.
• Повторное использование статического ключа : пара статических ключей, используемая с Noise, должна использоваться с одним алгоритмом хеширования. Пара ключей не должна использоваться вне Noise или с несколькими алгоритмами хеширования. Допустимо использовать пару статических ключей с различными протоколами Noise, при условии, что во всех них используется один и тот же алгоритм хеширования. (Повторное использование пары статических ключей Noise вне Noise потребует крайне тщательного анализа, чтобы гарантировать, что использование не ставит под угрозу друг друга, а доказательства безопасности сохраняются).
• Повторное использование PSK : PSK, используемый с Noise, должен использоваться с одним алгоритмом хэширования. PSK не должен использоваться вне Noise, а также с несколькими алгоритмами хэширования.
• Повторное использование эфемерного ключа : каждая сторона в протоколе Noise должна отправить новый эфемерный открытый ключ перед отправкой любых зашифрованных данных. Эфемерные ключи никогда не должны использоваться повторно. Нарушение этих правил, скорее всего, приведет к катастрофическому повторному использованию ключа. Это одно из обоснований шаблонов в §7 и правил действительности в §7.3. Это также причина, по которой односторонние рукопожатия допускают передачу сообщений только от отправителя, а не от получателя.
• Неправильное использование открытых ключей в качестве секретов : может возникнуть соблазн использовать шаблон с открытым ключом предварительного сообщения и предположить, что успешное рукопожатие подразумевает знание открытого ключа другой стороной. К сожалению, это не так, поскольку установка открытых ключей на недействительные значения может привести к предсказуемому выводу DH. Например, Noise_NK_25519инициатор может отправить недействительный эфемерный открытый ключ, чтобы вызвать известный вывод DH из всех нулей, несмотря на то, что он не знает статический открытый ключ ответчика. Если стороны хотят аутентифицироваться с помощью общего секрета, его следует использовать как PSK.
• Привязка канала : в зависимости от функций DH злоумышленник может участвовать в нескольких сеансах, которые выводят один и тот же общий секретный ключ, устанавливая открытые ключи на недопустимые значения, которые вызывают предсказуемый вывод DH (как в предыдущем пункте). Также может быть возможно установить открытые ключи на эквивалентные значения, которые вызывают одинаковый вывод DH для разных входов. Вот почему протокол более высокого уровня должен использовать хэш рукопожатия ( h ) для уникальной привязки канала вместо ck , как объяснено в §11.2.
• Увеличение одноразовых значений : повторное использование одноразового значения для n с тем же ключом k для шифрования было бы катастрофическим. Реализации должны тщательно следовать правилам для одноразовых значений. Одноразовые значения не могут возвращаться к нулю из-за целочисленного переполнения, а максимальное одноразовое значение зарезервировано. Это означает, что сторонам не разрешено отправлять более 2 ⁶⁴ -1 транспортных сообщений.
• Имена протоколов : используемое имя протокола Initialize()должно однозначно идентифицировать комбинацию шаблона рукопожатия и криптографических функций для каждого ключа, с которым оно используется (будь то пара эфемерных ключей, пара статических ключей или PSK). Если тот же секретный ключ был повторно использован с тем же именем протокола, но другим набором криптографических операций, то могут возникнуть плохие взаимодействия.
• Предварительно общие симметричные ключи : Предварительно общие симметричные ключи должны быть секретными значениями с 256 битами энтропии.
• Объемы данных : AESGCMфункции шифрования постепенно снижают безопасность по мере увеличения объема данных, зашифрованных одним ключом. В связи с этим стороны не должны отправлять более 2 ⁵⁶ байт (примерно 72 петабайта), зашифрованных одним ключом. Если возможна отправка таких больших объемов данных, следует выбирать другие функции шифрования.
• Коллизии хэшей : если злоумышленник может найти коллизии хэшей в данных пролога или хэше рукопожатия, он может выполнить атаки «коллизии транскриптов», которые обманывают стороны, заставляя их иметь разные представления о данных рукопожатия. Важно использовать Noise с хэш-функциями, устойчивыми к коллизиям, и заменять хэш-функцию при любом признаке слабости.
• Реализация отпечатков пальцев : если этот протокол используется в настройках с анонимными сторонами, следует позаботиться о том, чтобы реализации вели себя одинаково во всех случаях. Это может потребовать обязательного точного поведения для обработки недействительных открытых ключей DH.

• I2P (маршрутизатор ntcp2)
• Молния
• libp2p
• Libra / Diem от Facebook (цифровая валюта) (закрытие в 2022 году ^[67] )
• nQUIC ^[68]
• Slack's Nebula, ^[2] «Масштабируемый сетевой инструмент наложения»
• WhatsApp
• WireGuard

Разработка фреймворка Noise и TLS 1.3 охватывала период с 2014 по 2018 год. Первый черновик RFC 8446 ^[69] был в августе 2014 года, что привело к выпуску предлагаемого стандарта в августе 2018 года после 28 черновиков. В списке рассылки была короткая ветка ^[70] со сравнением с OPTLSпредложением. ^[71]

Некоторые другие применения шума в общем криптографическом смысле:

• Механизмы дифференциальной защиты от аддитивного шума

• Официальный сайт со спецификацией и Wiki
• Репозитории Github
• слайды из доклада 2017 года «Структура протокола шума»
• Введение в структуру протокола шума
• Использование Noise Protocol Framework для проектирования распределенной системы возможностей
• noisecat: шумовой швейцарский армейский нож

Презентации:

• 20-минутный доклад на Real World Crypto 2018 Тревора Перрина
• 25-минутное выступление Дэвида Вонга