Примечание
Сетевое развертывание и тестирование в процессе. Возможны незначительные правки. См. SPEC для официальной спецификации.
Обзор
В этом документе предлагаются изменения шифрования сообщений создания туннеля с использованием криптографических примитивов, введенных ECIES-X25519 . Это часть общего предложения Предложение 156 по переходу маршрутизаторов с ElGamal на ключи ECIES-X25519.
Для целей перехода сети с ElGamal + AES256 на ECIES + ChaCha20 необходимы туннели со смешанными узлами ElGamal и ECIES. Предоставлены спецификации обработки прыжков в смешанных туннелях. Никаких изменений в формат, обработку или шифрование прыжков ElGamal вноситься не будет.
Создателям туннелей ElGamal потребуется создавать временные ключевые пары X25519 на каждый прыжок и следовать данной спецификации при создании туннелей, содержащих прыжки ECIES.
В этом предложении описываются изменения, необходимые для создания туннелей ECIES-X25519. Для общего обзора всех изменений, необходимых для маршрутизаторов ECIES, см. предложение 156 Предложение 156 .
В этом предложении сохраняется тот же размер записей создания туннеля, что требуется для совместимости. Более мелкие записи и сообщения будут реализованы позже — см. Предложение 157 .
Криптографические примитивы
Новые криптографические примитивы не вводятся. Примитивы, необходимые для реализации этого предложения:
- AES-256-CBC как в Cryptography
- STREAM ChaCha20/Poly1305 функции: ENCRYPT(k, n, plaintext, ad) и DECRYPT(k, n, ciphertext, ad) — как в NTCP2 ECIES-X25519 и RFC-7539
- X25519 DH функции — как в NTCP2 и ECIES-X25519
- HKDF(salt, ikm, info, n) — как в NTCP2 и ECIES-X25519
Другие функции Noise, определённые в других местах:
- MixHash(d) — как в NTCP2 и ECIES-X25519
- MixKey(d) — как в NTCP2 и ECIES-X25519
Цели
- Увеличение скорости криптографических операций
- Замена ElGamal + AES256/CBC на примитивы ECIES для BuildRequestRecords и BuildReplyRecords туннеля.
- Без изменений размера зашифрованных BuildRequestRecords и BuildReplyRecords (528 байт) для совместимости
- Без новых сообщений I2NP
- Сохранение размера зашифрованной записи создания туннеля для совместимости
- Добавление сквозной секретности для сообщений создания туннеля.
- Добавление аутентифицированного шифрования
- Обнаружение переупорядочивания BuildRequestRecords узлами
- Повышение разрешения временной метки, чтобы можно было уменьшить размер фильтра Блума
- Добавление поля истечения срока действия туннеля, чтобы стали возможны разные сроки жизни туннелей (только для полностью ECIES-туннелей)
- Добавление расширяемого поля опций для будущих функций
- Повторное использование существующих криптографических примитивов
- Улучшение безопасности сообщений создания туннеля, где это возможно, при сохранении совместимости
- Поддержка туннелей со смешанными узлами ElGamal/ECIES
- Улучшение защиты от атак «маркировки» (tagging) на сообщениях создания туннеля
- Узлам не нужно знать тип шифрования следующего прыжка до обработки сообщения создания туннеля, так как у них может не быть RI следующего узла в этот момент
- Максимальная совместимость с текущей сетью
- Без изменений в шифровании AES запросов/ответов для создания туннеля на маршрутизаторах ElGamal
- Без изменений в «слоевом» шифровании AES туннеля, для этого см. Предложение 153
- Продолжение поддержки как 8-записных TBM/TBRM, так и переменных VTBM/VTBRM
- Не требует одновременного обновления всей сети («flag day»)
Нецели
- Полная переработка сообщений создания туннеля, требующая «flag day».
- Уменьшение сообщений создания туннеля (требует всех прыжков ECIES и нового предложения)
- Использование опций создания туннеля, как определено в Предложение 143 , требуется только для малых сообщений
- Двунаправленные туннели — для этого см. Предложение 119
- Уменьшение сообщений создания туннеля — для этого см. Предложение 157
Модель угроз
Цели проектирования
Ни один из узлов не может определить инициатора туннеля.
Промежуточные узлы не должны определять направление туннеля или свою позицию в туннеле.
Ни один узел не может читать содержимое других запросов или ответов, кроме усечённого хэша маршрутизатора и временного ключа для следующего узла
Ни один участник обратного туннеля для исходящего создания не может читать записи ответов.
Ни один участник исходящего туннеля для входящего создания не может читать записи запросов, за исключением того, что OBEP может видеть усечённый хэш маршрутизатора и временный ключ для IBGW
Атаки маркировки (tagging)
Основная цель проектирования создания туннеля — затруднить маршрутизаторам X и Y, действующим сообща, определить, что они находятся в одном туннеле. Если маршрутизатор X находится на прыжке m, а маршрутизатор Y — на прыжке m+1, они, очевидно, узнают это. Но если маршрутизатор X на прыжке m, а маршрутизатор Y на прыжке m+n при n>1, это должно быть намного сложнее.
Атаки маркировки — это когда промежуточный узел X изменяет сообщение создания туннеля таким образом, что маршрутизатор Y может обнаружить изменение, когда сообщение дойдёт до него. Цель — чтобы любое изменённое сообщение было отброшено маршрутизатором между X и Y до того, как достигнет Y. Для изменений, которые не были отброшены до маршрутизатора Y, создатель туннеля должен обнаружить повреждение в ответе и отбросить туннель.
Возможные атаки:
- Изменение записи создания
- Замена записи создания
- Добавление или удаление записи создания
- Переупорядочивание записей создания
TODO: Предотвращает ли текущая схема все эти атаки?
Проектирование
Фреймворк протокола Noise
Это предложение определяет требования на основе фреймворка протокола Noise NOISE (Revision 34, 2018-07-11). В терминологии Noise, Алиса — инициатор, а Боб — ответчик.
Это предложение основано на протоколе Noise Noise_N_25519_ChaChaPoly_SHA256. Этот протокол Noise использует следующие примитивы:
Односторонний шаблон рукопожатия: N Алиса не передаёт свой статический ключ Бобу (N)
Функция DH: X25519 X25519 DH с длиной ключа 32 байта, как указано в RFC-7748 .
Функция шифрования: ChaChaPoly AEAD_CHACHA20_POLY1305 как указано в RFC-7539 раздел 2.8. 12-байтовый nonce, первые 4 байта установлены в ноль. Идентично тому, что в NTCP2 .
Хэш-функция: SHA256 Стандартный 32-байтовый хэш, уже широко используется в I2P.
Дополнения к фреймворку
Отсутствуют.
Шаблоны рукопожатия
Рукопожатия используют шаблоны Noise .
Используется следующее буквенно-символьное соответствие:
- e = одноразовый временный ключ
- s = статический ключ
- p = полезная нагрузка
Запрос создания идентичен шаблону Noise N. Это также идентично первому сообщению (Session Request) в шаблоне XK, используемом в NTCP2 .
<- s
...
e es p ->
Шифрование запроса
Записи запроса создания туннеля создаются создателем туннеля и асимметрично шифруются для отдельного прыжка. Это асимметричное шифрование записей запроса в настоящее время — ElGamal, как определено в Cryptography и содержит контрольную сумму SHA-256. Эта схема не является сквозной по секретности.
Новая схема будет использовать односторонний шаблон Noise “N” с ECIES-X25519 (временный-статический DH), с HKDF и AEAD ChaCha20/Poly1305 для сквозной секретности, целостности и аутентификации. Алиса — это инициатор создания туннеля. Каждый прыжок в туннеле — это Боб.
(Свойства безопасности полезной нагрузки)
N: Аутентификация Конфиденциальность
-> e, es 0 2
Аутентификация: Нет (0).
Эту полезную нагрузку мог отправить любой участник, включая активного атакующего.
Конфиденциальность: 2.
Шифрование для известного получателя, сквозная секретность только при компрометации отправителя,
уязвимо к повторной передаче. Эта полезная нагрузка шифруется только на основе DH,
включающих статическую пару ключей получателя. Если статический закрытый ключ получателя скомпрометирован,
даже в будущем, эта полезная нагрузка может быть расшифрована. Это сообщение также может быть повторно передано,
так как нет вклада временного ключа от получателя.
"e": Алиса генерирует новую временную пару ключей и сохраняет её в переменной e,
записывает временный открытый ключ в виде открытого текста в буфер сообщения
и хэширует открытый ключ вместе со старым h, чтобы вычислить новый h.
"es": Выполняется DH между временной парой ключей Алисы и статической парой ключей Боба.
Результат хэшируется вместе со старым ck, чтобы вычислить новый ck и k, и n устанавливается в ноль.
Шифрование ответа
Записи ответа создания туннеля создаются создателем прыжков и симметрично шифруются для создателя. Это симметричное шифрование записей ответа в настоящее время — AES с предваряющей контрольной суммой SHA-256. и содержит контрольную сумму SHA-256. Эта схема не является сквозной по секретности.
Новая схема будет использовать AEAD ChaCha20/Poly1305 для целостности и аутентификации.
Обоснование
Временный открытый ключ в запросе не нуждается в маскировке с помощью AES или Elligator2. Только предыдущий прыжок может его видеть, и он знает, что следующий прыжок использует ECIES.
Записям ответа не требуется полное асимметричное шифрование с другим DH.
Спецификация
Записи запроса создания
Зашифрованные BuildRequestRecords имеют размер 528 байт как для ElGamal, так и для ECIES, для совместимости.
Запись запроса, незашифрованная (ElGamal)
Для справки, это текущая спецификация записи BuildRequestRecord для маршрутизаторов ElGamal, взятая из I2NP . Незашифрованные данные дополняются ненулевым байтом и хэшем SHA-256 данных перед шифрованием, как определено в Cryptography .
Все поля big-endian.
Незашифрованный размер: 222 байта
байты 0-3: ID туннеля, для получения сообщений, ненулевой
байты 4-35: хэш идентификатора локального маршрутизатора
байты 36-39: следующий ID туннеля, ненулевой
байты 40-71: хэш идентификатора следующего маршрутизатора
байты 72-103: ключ слоя туннеля AES-256
байты 104-135: ключ IV туннеля AES-256
байты 136-167: ключ ответа AES-256
байты 168-183: IV ответа AES-256
байт 184: флаги
байты 185-188: время запроса (в часах с эпохи, округлённое вниз)
байты 189-192: следующий ID сообщения
байты 193-221: неинтерпретируемые / случайные заполнители
Запись запроса, зашифрованная (ElGamal)
Для справки, это текущая спецификация записи BuildRequestRecord для маршрутизаторов ElGamal, взятая из I2NP .
Зашифрованный размер: 528 байт
байты 0-15: Усечённый хэш идентификатора прыжка
байты 16-528: ElGamal-зашифрованная BuildRequestRecord
Запись запроса, незашифрованная (ECIES)
Это предлагаемая спецификация записи BuildRequestRecord для маршрутизаторов ECIES-X25519. Краткое описание изменений:
- Удалён неиспользуемый 32-байтовый хэш маршрутизатора
- Изменение времени запроса с часов на минуты
- Добавление поля истечения срока для будущих переменных сроков жизни туннеля
- Добавление дополнительного места для флагов
- Добавление сопоставления (Mapping) для дополнительных опций создания
- Ключи ответа AES-256 не используются для собственной записи ответа прыжка
- Незашифрованная запись длиннее, так как накладные расходы на шифрование меньше
Запись запроса не содержит ключей ответа ChaCha. Эти ключи выводятся из KDF. См. ниже.
Все поля big-endian.
Незашифрованный размер: 464 байта
байты 0-3: ID туннеля, для получения сообщений, ненулевой
байты 4-7: следующий ID туннеля, ненулевой
байты 8-39: хэш идентификатора следующего маршрутизатора
байты 40-71: ключ слоя туннеля AES-256
байты 72-103: ключ IV туннеля AES-256
байты 104-135: ключ ответа AES-256
байты 136-151: IV ответа AES-256
байт 152: флаги
байты 153-155: дополнительные флаги, не используются, установлены в 0 для совместимости
байты 156-159: время запроса (в минутах с эпохи, округлённое вниз)
байты 160-163: истечение срока запроса (в секундах с момента создания)
байты 164-167: следующий ID сообщения
байты 168-x: опции создания туннеля (Mapping)
байты x-x: другие данные, подразумеваемые флагами или опциями
байты x-463: случайные заполнители
Поле флагов такое же, как определено в Tunnel Creation и содержит следующее::
Порядок битов: 76543210 (бит 7 — старший) бит 7: если установлен, разрешает сообщения от любого бит 6: если установлен, разрешает сообщения любому и отправляет ответ указанному следующему прыжку в сообщении ответа создания туннеля биты 5-0: Не определены, должны быть установлены в 0 для совместимости с будущими опциями
Бит 7 указывает, что прыжок будет входным шлюзом (IBGW). Бит 6 указывает, что прыжок будет исходной точкой (OBEP). Если ни один бит не установлен, прыжок будет промежуточным участником. Оба не могут быть установлены одновременно.
Истечение срока запроса предназначено для будущих переменных сроков жизни туннеля. Сейчас единственное поддерживаемое значение — 600 (10 минут).
Опции создания туннеля — это структура Mapping, как определено в Common Structures . Это для будущего использования. Опции в настоящее время не определены. Если структура Mapping пуста, это два байта 0x00 0x00. Максимальный размер Mapping (включая поле длины) — 296 байт, а максимальное значение поля длины Mapping — 294.
Запись запроса, зашифрованная (ECIES)
Все поля big-endian, кроме временного открытого ключа, который little-endian.
Зашифрованный размер: 528 байт
байты 0-15: Усечённый хэш идентификатора прыжка
байты 16-47: Временный открытый ключ X25519 отправителя
байты 48-511: BuildRequestRecord, зашифрованная ChaCha20
байты 512-527: MAC Poly1305
Записи ответа создания
Зашифрованные BuildReplyRecords имеют размер 528 байт как для ElGamal, так и для ECIES, для совместимости.
Запись ответа, незашифрованная (ElGamal)
Ответы ElGamal шифруются с помощью AES.
Все поля big-endian.
Незашифрованный размер: 528 байт
байты 0-31: Хэш SHA-256 байтов 32-527
байты 32-526: случайные данные
байт 527: ответ
общая длина: 528
Запись ответа, незашифрованная (ECIES)
Это предлагаемая спецификация записи BuildReplyRecord для маршрутизаторов ECIES-X25519. Краткое описание изменений:
- Добавление Mapping для опций ответа создания туннеля
- Незашифрованная запись длиннее, так как накладные расходы на шифрование меньше
Ответы ECIES шифруются с помощью ChaCha20/Poly1305.
Все поля big-endian.
Незашифрованный размер: 512 байт
байты 0-x: Опции ответа создания туннеля (Mapping)
байты x-x: другие данные, подразумеваемые опциями
байты x-510: Случайные заполнители
байт 511: Байт ответа
Опции ответа создания туннеля — это структура Mapping, как определено в Common Structures . Это для будущего использования. Опции в настоящее время не определены. Если структура Mapping пуста, это два байта 0x00 0x00. Максимальный размер Mapping (включая поле длины) — 511 байт, а максимальное значение поля длины Mapping — 509.
Байт ответа — один из следующих значений, как определено в Tunnel Creation , чтобы избежать фингерпринтинга:
- 0x00 (принять)
- 30 (TUNNEL_REJECT_BANDWIDTH)
Запись ответа, зашифрованная (ECIES)
Зашифрованный размер: 528 байт
байты 0-511: BuildReplyRecord, зашифрованная ChaCha20
байты 512-527: MAC Poly1305
После полного перехода на записи ECIES, правила заполнения остаются такими же, как и для записей запроса.
Симметричное шифрование записей
Смешанные туннели разрешены и необходимы для перехода с ElGamal на ECIES. Во время переходного периода всё больше маршрутизаторов будет использовать ключи ECIES.
Предварительная обработка симметричной криптографии будет работать одинаково:
«шифрование»:
- шифр работает в режиме расшифровки
- записи запроса предварительно расшифровываются на этапе предварительной обработки (скрывая зашифрованные записи запроса)
«расшифровка»:
- шифр работает в режиме шифрования
- записи запроса шифруются (раскрывая следующую запись запроса в открытом виде) узлами-участниками
ChaCha20 не имеет «режимов», поэтому он просто запускается три раза:
- один раз на предварительной обработке
- один раз узлом
- один раз при окончательной обработке ответа
При использовании смешанных туннелей создатели туннелей должны основывать симметричное шифрование BuildRequestRecord на типе шифрования текущего и предыдущего прыжка.
Каждый прыжок будет использовать свой собственный тип шифрования для шифрования BuildReplyRecords и других записей в VariableTunnelBuildMessage (VTBM).
На обратном пути конечная точка (отправитель) должна будет отменить Multiple Encryption , используя ключ ответа каждого прыжка.
В качестве поясняющего примера рассмотрим исходящий туннель с ECIES, окружённый ElGamal:
- Отправитель (OBGW) -> ElGamal (H1) -> ECIES (H2) -> ElGamal (H3)
Все BuildRequestRecords находятся в зашифрованном состоянии (с использованием ElGamal или ECIES).
AES256/CBC, при использовании, по-прежнему применяется к каждой записи отдельно, без объединения нескольких записей.
Аналогично, ChaCha20 будет использоваться для шифрования каждой записи, а не потокового шифрования всего VTBM.
Записи запроса предварительно обрабатываются отправителем (OBGW):
Запись H3 «шифруется» с использованием:
- ключа ответа H2 (ChaCha20)
- ключа ответа H1 (AES256/CBC)
Запись H2 «шифруется» с использованием:
- ключа ответа H1 (AES256/CBC)
Запись H1 отправляется без симметричного шифрования
Только H2 проверяет флаг шифрования ответа и видит, что за ним следует AES256/CBC.
После обработки каждым прыжком записи находятся в «расшифрованном» состоянии:
Запись H3 «расшифровывается» с использованием:
- ключа ответа H3 (AES256/CBC)
Запись H2 «расшифровывается» с использованием:
- ключа ответа H3 (AES256/CBC)
- ключа ответа H2 (ChaCha20-Poly1305)
Запись H1 «расшифровывается» с использованием:
- ключа ответа H3 (AES256/CBC)
- ключа ответа H2 (ChaCha20)
- ключа ответа H1 (AES256/CBC)
Создатель туннеля, т.е. конечная точка входа (IBEP), постобрабатывает ответ:
Запись H3 «шифруется» с использованием:
- ключа ответа H3 (AES256/CBC)
Запись H2 «шифруется» с использованием:
- ключа ответа H3 (AES256/CBC)
- ключа ответа H2 (ChaCha20-Poly1305)
Запись H1 «шифруется» с использованием:
- ключа ответа H3 (AES256/CBC)
- ключа ответа H2 (ChaCha20)
- ключа ответа H1 (AES256/CBC)
Ключи записи запроса (ECIES)
Эти ключи явно включены в записи BuildRequestRecords ElGamal. Для записей BuildRequestRecords ECIES включены ключи туннеля и ключи ответа AES, но ключи ответа ChaCha выводятся из обмена DH. См. Предложение 156 для деталей статических ключей ECIES маршрутизатора.
Ниже приведено описание способа вывода ключей, ранее передаваемых в записях запроса.
KDF для начальных ck и h
Это стандартный NOISE для шаблона “N” со стандартным именем протокола.
Это шаблон сообщения "e":
// Определить protocol_name.
Set protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 байт, кодировка US-ASCII, без NULL-терминатора).
// Определить Hash h = 32 байта
// Дополнить до 32 байт. НЕ хэшировать, так как длина не более 32 байт.
h = protocol_name || 0
Определить ck = 32-байтовый цепной ключ. Скопировать данные h в ck.
Set chainKey = h
// MixHash(null prologue)
h = SHA256(h);
// до этого момента всё может быть предварительно вычислено всеми маршрутизаторами.
KDF для записи запроса
Создатели туннелей ElGamal генерируют временную пару ключей X25519 для каждого прыжка ECIES в туннеле и используют указанную выше схему для шифрования своей записи BuildRequestRecord. Создатели туннелей ElGamal будут использовать схему, описанную до этой спецификации, для шифрования прыжков ElGamal.
Создателям туннелей ECIES нужно будет шифровать каждый из открытых ключей прыжков ElGamal по схеме, определённой в Tunnel Creation . Создатели туннелей ECIES будут использовать указанную выше схему для шифрования прыжков ECIES.
Это означает, что прыжки будут видеть зашифрованные записи только от прыжков с тем же типом шифрования.
Для создателей туннелей ElGamal и ECIES они будут генерировать уникальные временные пары ключей X25519 на прыжок для шифрования прыжков ECIES.
ВАЖНО: Временные ключи должны быть уникальны для каждого прыжка ECIES и для каждой записи создания. Несоблюдение этого правила открывает вектор атаки для сообщающихся прыжков подтвердить, что они находятся в одном туннеле.
// Статическая пара ключей X25519 каждого прыжка (hesk, hepk) из Идентификатора Маршрутизатора
hesk = GENERATE_PRIVATE()
hepk = DERIVE_PUBLIC(hesk)
// MixHash(hepk)
// || ниже означает добавление
h = SHA256(h || hepk);
// до этого момента всё может быть предварительно вычислено каждым маршрутизатором
// для всех входящих запросов создания
// Отправитель генерирует временную пару ключей X25519 на каждый прыжок ECIES в VTBM (sesk, sepk)
sesk = GENERATE_PRIVATE()
sepk = DERIVE_PUBLIC(sesk)
// MixHash(sepk)
h = SHA256(h || sepk);
Конец шаблона сообщения "e".
Это шаблон сообщения "es":
// Noise es
// Отправитель выполняет X25519 DH с открытым статическим ключом прыжка.
// Каждый прыжок находит запись с усечённым хэшем своего идентификатора,
// и извлекает временный ключ отправителя перед зашифрованной записью.
sharedSecret = DH(sesk, hepk) = DH(hesk, sepk)
// MixKey(DH())
//[chainKey, k] = MixKey(sharedSecret)
// Параметры ChaChaPoly для шифрования/расшифровки
keydata = HKDF(chainKey, sharedSecret, "", 64)
// Сохранить для KDF записи ответа
chainKey = keydata[0:31]
// Параметры AEAD
k = keydata[32:63]
n = 0
plaintext = 464-байтовая запись запроса создания
ad = h
ciphertext = ENCRYPT(k, n, plaintext, ad)
Конец шаблона сообщения "es".
// MixHash(ciphertext)
// Сохранить для KDF записи ответа
h = SHA256(h || ciphertext)
replyKey, layerKey и layerIV по-прежнему должны быть включены внутрь записей ElGamal
и могут генерироваться случайным образом.
Шифрование записи запроса (ElGamal)
Как определено в Tunnel Creation . Никаких изменений в шифровании для прыжков ElGamal не вносится.
Шифрование записи ответа (ECIES)
Запись ответа шифруется с помощью ChaCha20/Poly1305.
// Параметры AEAD
k = chainkey из запроса создания
n = 0
plaintext = 512-байтовая запись ответа создания
ad = h из запроса создания
ciphertext = ENCRYPT(k, n, plaintext, ad)
Шифрование записи ответа (ElGamal)
Как определено в Tunnel Creation . Никаких изменений в шифровании для прыжков ElGamal не вносится.
Анализ безопасности
ElGamal не обеспечивает сквозную секретность для сообщений создания туннеля.
AES256/CBC находится в немного лучшем положении, будучи уязвимым только к теоретическому ослаблению из-за
атаки с известным открытым текстом biclique.
Единственная известная практическая атака против AES256/CBC — это атака с оракулом заполнения, когда IV известен атакующему.
Атакующему нужно будет взломать шифрование ElGamal следующего прыжка, чтобы получить информацию о ключе AES256/CBC (ключ ответа и IV).
ElGamal значительно более ресурсоёмок по CPU, чем ECIES, что ведёт к возможному истощению ресурсов.
ECIES, используемый с новыми временными ключами на каждую BuildRequestRecord или VariableTunnelBuildMessage, обеспечивает сквозную секретность.
ChaCha20Poly1305 обеспечивает AEAD-шифрование, позволяя получателю проверить целостность сообщения до попытки расшифровки.
Обоснование
Этот дизайн максимизирует повторное использование существующих криптографических примитивов, протоколов и кода. Этот дизайн минимизирует риски.
Примечания по реализации
- Старые маршрутизаторы не проверяют тип шифрования прыжка и будут отправлять зашифрованные ElGamal записи. Некоторые недавние маршрутизаторы имеют ошибки и будут отправлять различные типы повреждённых записей. Реализаторам следует обнаруживать и отклонять такие записи до операции DH, если возможно, чтобы снизить нагрузку на CPU.
Проблемы
Миграция
См. Предложение 156 .