ECIES роутеры

Proposal 156
Closed
Author zzz, orignal
Created 2020-09-01
Last Updated 2025-03-05
Target Version 0.9.51

Примечание

Развертывание и тестирование сети в процессе. Может быть изменено. Статус:

  • ECIES роутеры реализованы в 0.9.48, см. Common.
  • Создание туннелей реализовано в 0.9.48, см. Tunnel-Creation-ECIES.
  • Зашифрованные сообщения для ECIES роутеров реализованы в 0.9.49, см. ECIES-ROUTERS.
  • Сообщения о создании новых туннелей реализованы в 0.9.51.

Обзор

Резюме

Идентификаторы роутеров в настоящее время содержат ключ шифрования ElGamal. Это стандарт с начала I2P. ElGamal медленен и требует замены во всех местах использования.

Предложения для LS2 Prop123 и ECIES-X25519-AEAD-Ratchet Prop144 (теперь определены в ECIES) описали замену ElGamal на ECIES для Destinations.

Это предложение определяет замену ElGamal на ECIES-X25519 для роутеров. Предложение дает обзор необходимых изменений. Большинство деталей содержится в других предложениях и спецификациях. См. раздел ссылок для получения информации.

Цели

См. Prop152 для дополнительных целей.

  • Заменить ElGamal на ECIES-X25519 в Идентификаторах роутеров
  • Повторное использование существующих криптографических примитивов
  • Улучшить защищенность сообщений о создании туннелей, сохраняя совместимость
  • Поддержка туннелей с разными типами шифрования ElGamal/ECIES
  • Максимизация совместимости с текущей сетью
  • Не требуется одновременное обновление всей сети
  • Постепенное развертывание для минимизации риска
  • Новое, уменьшенное сообщение о создании туннелей

Не-цели

См. Prop152 для дополнительных не-целей.

  • Нет требований для роутеров с двойными ключами
  • Изменения в уровне шифрования, для этого см. Prop153

Дизайн

Местоположение ключа и тип криптографии

Для Destinations, ключ находится в наборе адресов, а не в Destination, и мы поддерживаем несколько типов шифрования в одном и том же наборе адресов.

Ничего из этого не требуется для роутеров. Ключ шифрования роутера находится в его Идентификаторе роутера. См. спецификацию общих структур Common.

Для роутеров мы заменим 256-байтный ключ ElGamal в Идентификаторе роутера на 32-байтный X25519 ключ и 224 байта заполнения. Это будет указано типом криптографии в сертификате ключа. Тип криптографии (такой же, как использованный в LS2) – 4. Это указывает на 32-байтный открытый ключ X25519 с порядком байтов “младший сначала”. Это стандартное построение, как определено в спецификации общих структур Common.

Это идентично методу, предложенному для ECIES-P256 для типов криптографии 1-3 в предложении 145 Prop145. Хотя это предложение никогда не было принято, разработчики Java-реализации подготовились к типам криптографии в сертификатах ключей Идентификаторов роутеров, добавив проверки во многих местах в кодовой базе. Большая часть этой работы была выполнена в середине 2019 года.

Сообщение о создании туннеля

Для использования ECIES вместо ElGamal требуется несколько изменений спецификации создания туннелей Tunnel-Creation. Кроме того, мы внесем улучшения в сообщения о создании туннелей для повышения безопасности.

На первом этапе мы изменим формат и шифрование записей о создании и ответах на создание для переходов ECIES. Эти изменения будут совместимы с существующими роутерами ElGamal. Эти изменения определены в предложении 152 Prop152.

На втором этапе мы добавим новую версию сообщений о запросе на создание, о создании ответа, записи о запросе на создание и записи об ответе на создание. Размер будет уменьшен для повышения эффективности. Эти изменения должны поддерживаться всеми узлами в туннеле, и все узлы должны быть ECIES. Эти изменения определены в предложении 157 Prop157.

Сквозное шифрование

История

В оригинальном дизайне Java I2P использовался единый Менеджер ключей сессий ElGamal (SKM), который использовался роутером и всеми его локальными Destination. Так как общий SKM мог раскрыть информацию и позволить корреляцию злоумышленниками, дизайн был изменен для поддержки отдельных SKM ElGamal для роутера и каждого Destination. Дизайн ElGamal поддерживал только анонимных отправителей; отправитель посылал только эфемерные ключи, а не статический ключ. Сообщение не было связано с идентичностью отправителя.

Затем мы разработали ECIES Ratchet SKM в ECIES-X25519-AEAD-Ratchet Prop144, теперь определено в ECIES. Этот дизайн был определен с использованием паттерна Noise “IK”, который включал статический ключ отправителя в первом сообщении. Этот протокол используется для ECIES (тип 4) Destinations. Паттерн IK не позволяет использовать анонимных отправителей.

Поэтому мы включили в предложение возможность отправки анонимных сообщений к Ratchet SKM, используя статический ключ, заполненный нулями. Это имитировало паттерн Noise “N”, но совместимо, поэтому ECIES SKM мог принимать и анонимные, и неанонимные сообщения. Предполагалось использовать нулевой ключ для ECIES роутеров.

Использование и модели угроз

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

Сценарий использования и модель угроз для Destination:

  • Неанонимный от/до Destinations (отправитель указывает статический ключ)
  • Эффективно поддерживает постоянный трафик между Destination (полное рукопожатие, потоковая передача и теги)
  • Всегда отправляется через исходящие и входящие туннели
  • Скрывает все идентифицирующие характеристики от OBEP и IBGW, требуя кодирования эфемерных ключей с помощью Elligator2.
  • Оба участника должны использовать один и тот же тип шифрования

Сценарий использования и модель угроз для Router:

  • Анонимные сообщения от роутеров или Destination (отправитель не включает статический ключ)
  • Для зашифрованных запросов и хранилищ базы данных, в основном для floodfill
  • Случайные сообщения
  • Несколько сообщений не должны быть коррелированы
  • Всегда отправляется через исходящий туннель напрямую к роутеру. Входящие туннели не используются
  • OBEP знает, что он перенаправляет сообщение роутеру и знает его тип шифрования
  • Два участника могут иметь разные типы шифрования
  • Ответы на запросы базы данных – это одноразовые сообщения, использующие ключ и тег запроса базы данных
  • Подтверждения о хранилище базы данных – одноразовые сообщения, использующие бесплатно включенное сообщение о доставке

Некоторые не-цели для роутеров:

  • Нет необходимости в неанонимных сообщениях
  • Нет необходимости отправлять сообщения через входящие исследовательские туннели (роутер не публикует исследовательские наборы адресов)
  • Нет необходимости в постоянном обмене сообщениями с использованием тегов
  • Нет необходимости в “двойных ключах” для Менеджеров ключей сессий, как описано в ECIES для Destinations. У роутеров только один открытый ключ.

Выводы дизайна

ECIES Router SKM не требует полного Ratchet SKM как указывается в ECIES для Destinations. Нет необходимости в неанонимных сообщениях, использующих паттерн IK. Модель угроз не требует закодированных эфемерных ключей Elligator2.

Таким образом, SKM роутера будет использовать паттерн Noise “N”, такой же, как указано в Prop152 для создания туннелей. Он будет использовать тот же формат нагрузки, как указано в ECIES для Destinations. Режим с нулевым статическим ключом (без связывания или сессии) IK, описанный в ECIES, не будет использоваться.

Ответы на запросы шифруются ратчетным тегом, если запрашивается в поисковом запросе. Это задокументировано в Prop154, теперь указано в I2NP.

Дизайн позволяет роутеру иметь один Менеджер ключей сессий ECIES. Нет необходимости иметь “двойные ключи” для Менеджеров ключей сессий, как описано в ECIES для Destinations. У роутеров только один открытый ключ.

Роутер ECIES не имеет статического ключа ElGamal. Роутеру всё ещё требуется реализация ElGamal для создания туннелей через роутеры ElGamal и отправки зашифрованных сообщений роутерам ElGamal.

Роутер ECIES МОЖЕТ потребовать частичного Менеджера ключей сессий ElGamal для приема сообщений с тегами ElGamal, полученных в ответ на запросы NetDB от floodfill роутеров до версии 0.9.46, так как эти роутеры не имеют реализации ответов с тегами ECIES, как указано в Prop152. Если это не так, роутер ECIES может не запрашивать зашифрованный ответ у floodfill роутера версии до 0.9.46.

Это опционально. Решение может варьироваться в различных реализациях I2P и может зависеть от доли сети, обновленной до версии 0.9.46 или выше. На данный момент приблизительно 85% сети работает на версии 0.9.46 или выше.

Спецификация

X25519: См. ECIES.

Идентификатор роутера и сертификат ключа: См. Common.

Создание туннелей: См. Prop152.

Новое сообщение о создании туннеля: См. Prop157.

Шифрование запросов

Шифрование запросов соответствует тому, что указано в Tunnel-Creation-ECIES и Prop152, с использованием паттерна Noise “N”.

Ответы на запросы шифруются ратчетным тегом, если это запрашивается в поисковом запросе. Сообщения запросов на поиск в базе данных содержат 32-байтный ключ для ответа и 8-байтный тег для ответа, как указано в I2NP и Prop154. Ключ и тег используются для шифрования ответа.

Наборы тегов не создаются. Схема с нулевым статическим ключом, указанная в ECIES-X25519-AEAD-Ratchet Prop144 и ECIES, не используется. Эфемерные ключи не будут закодированы с использованием Elligator2.

Как правило, это будут сообщения новой сессии, отправляемые с нулевым статическим ключом (без связывания или сессии), поскольку отправитель сообщения анонимен.

KDF для начальных ck и h

Это стандарт NOISE для паттерна “N” с стандартным именем протокола. Это соответствует тому, что указано в Tunnel-Creation-ECIES и Prop152 для сообщений о создании туннелей.


Это паттерн сообщения "e":

// Определите protocol_name.
Установите protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 байт, кодировка US-ASCII, без NULL-завершения).

// Определите хэш h = 32 байта
// Дополните до 32 байтов. НЕ хэшируйте, так как это не больше 32 байтов.
h = protocol_name || 0

Определите ck = 32-байтный цепной ключ. Скопируйте данные h в ck.
Установите chainKey = h

// MixHash(null пролог)
h = SHA256(h);

// до этого момента, все могут быть предварительно вычислены всеми роутерами.

KDF для сообщения

Создатели сообщений создают эфемерную ключевую пару X25519 для каждого сообщения. Эфемерные ключи должны быть уникальны для каждого сообщения. Это соответствует тому, что указано в Tunnel-Creation-ECIES и Prop152 для сообщений о создании туннелей.



// Статическая ключевая пара X25519 целевого роутера (hesk, hepk) из Идентификатора роутера
hesk = GENERATE_PRIVATE()
hepk = DERIVE_PUBLIC(hesk)

// MixHash(hepk)
// || ниже означает добавить
h = SHA256(h || hepk);

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

// Отправитель создает эфемерную ключевую пару X25519
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)
// Цепной ключ не используется
//chainKey = keydata[0:31]

// Параметры AEAD
k = keydata[32:63]
n = 0
plaintext = 464-байтная запись запроса на создание
ad = h
ciphertext = ENCRYPT(k, n, plaintext, ad)

Конец паттерна сообщения "es".

// MixHash(ciphertext) не требуется
//h = SHA256(h || ciphertext)

Полезная нагрузка

Полезная нагрузка имеет тот же формат блока, что и определяется в ECIES и Prop144. Все сообщения должны содержать блок DateTime для предотвращения повторов.

Шифрование ответов

Ответы на сообщения Database Lookup могут быть сообщениями Database Store или Database Search Reply. Они шифруются как сообщения существующей сессии с 32-байтным ключом ответа и 8-байтным тегом ответа, как указано в I2NP и Prop154.

Явных ответов на сообщения Database Store нет. Отправитель может включить собственный ответ как собственное Message Garlic, содержащее Delivery Status сообщение.

Обоснование

Этот дизайн максимизирует повторное использование существующих криптографических примитивов, протоколов и кода.

Этот дизайн минимизирует риск.

Заметки по внедрению

Старые роутеры не проверяют тип шифрования роутера и будут отправлять зашифрованные ElGamal записи о создании или netdb сообщения. Некоторые недавние роутеры имеют баги и будут отправлять различные типы неправильно сформированных записей о создании. Некоторые недавние роутеры могут отправлять неанонимные (полные сессии ratchet) netdb сообщения. Разработчики должны обнаруживать и отклонять эти записи и сообщения как можно раньше, чтобы уменьшить использование CPU.

Проблемы

Предложение 145 Prop145 может не быть переписано для полной совместимости с предложением 152 Prop152.

Миграция

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

Детали реализации и миграции могут варьироваться для каждой реализации I2P.

Базовая связь “точка-точка”

ECIES роутеры могут соединяться с и принимать подключения от ElGamal роутеров. Это должно быть возможно сейчас, так как несколько проверок было добавлено в кодовую базу Java к середине 2019 года в ответ на незавершенное предложение 145 Prop145. Убедитесь, что в кодовых базах ничего не препятствует соединениям точка-точка с не-ElGamal роутерами.

Проверки корректности кода:

  • Убедитесь, что ElGamal роутеры не запрашивают ответы зашифрованные AEAD для сообщений DatabaseLookup (когда ответ возвращается через исследовательский туннель роутеру)
  • Убедитесь, что ECIES роутеры не запрашивают ответы зашифрованные AES для сообщений DatabaseLookup (когда ответ возвращается через исследовательский туннель роутеру)

До поздних этапов, когда спецификации и реализации завершены:

  • Убедитесь, что создание туннелей не выполняется роутерами ElGamal через роутеры ECIES.
  • Убедитесь, что зашифрованные сообщения ElGamal не отправляются роутерами ElGamal к floodfill роутерам ECIES. (DatabaseLookups и DatabaseStores)
  • Убедитесь, что зашифрованные сообщения ECIES не отправляются роутерами ECIES к floodfill роутерам ElGamal. (DatabaseLookups и DatabaseStores)
  • Убедитесь, что ECIES роутеры не автоматически становятся floodfill.

Изменения не должны требоваться. Целевой выпуск, если изменения необходимы: 0.9.48

Совместимость NetDB

Убедитесь, что роутеры ECIES могут сохранять и извлекать информацию о роутерах (RouterInfos) из floodfill роутеров ElGamal. Это должно быть возможно сейчас, так как несколько проверок было добавлено в кодовую базу Java к середине 2019 года в ответ на незавершенное предложение 145 Prop145. Убедитесь, что в кодовых базах ничего не препятствует хранению не-ElGamal RouterInfos в базе данных сети.

Изменения не должны требоваться. Целевой выпуск, если изменения необходимы: 0.9.48

Создание туннелей

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

Затем протестируйте и поддержите роутеры ECIES, создающие туннели с использованием смешанных узлов ElGamal и ECIES.

Затем включите создание туннелей через роутеры ECIES. Проверка на минимальную версию не должна быть необходима, если после выпуска не будет сделано несовместимых изменений в предложении 152.

Целевой выпуск: 0.9.48, конец 2020

Ratchet сообщения к floodfill ECIES

Реализуйте и протестируйте прием сообщений ECIES (с нулевым статическим ключом) от floodfill ECIES, как определено в предложении 144 Prop144. Реализуйте и протестируйте прием AEAD ответов на сообщения DatabaseLookup роутера ECIES.

Включите автозадание floodfill для роутеров ECIES. Затем включите отправку сообщений ECIES к роутерам ECIES. Проверка на минимальную версию не должна быть необходима, если после выпуска не будет сделано несовместимых изменений в предложении 152.

Целевой выпуск: 0.9.49, начало 2021. Роутеры ECIES могут автоматически становиться floodfill.

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

Новые установки будут использовать ECIES по умолчанию, начиная с выпуска 0.9.49.

Постепенно переключайте ключи для всех роутеров, чтобы минимизировать риск и нарушение работы сети. Используйте существующий код, который выполнял переключение ключей для перехода на другой тип подписи несколько лет назад. Этот код дает каждому роутеру небольшой случайный шанс на переключение ключей при каждом перезапуске. После нескольких перезапусков роутер, вероятно, переключится на ECIES.

Критерием для начала переключения ключей является то, что достаточная часть сети, возможно, 50%, может строить туннели через роутеры ECIES (0.9.48 или выше).

Прежде чем агрессивно переключать ключи для всей сети, подавляющее большинство (возможно, 90% или более) должны иметь возможность построить туннели через роутеры ECIES (0.9.48 или выше) И отправлять сообщения к floodfill ECIES (0.9.49 или выше). Эта цель, возможно, будет достигнута к выпуску 0.9.52.

Переключение ключей займет несколько выпусков.

Целевой выпуск: 0.9.49 для новых роутеров по умолчанию на ECIES; 0.9.49 для медленного начала переключения ключей; 0.9.50 - 0.9.52 для постоянного увеличения скорости переключения ключей; конец 2021 для большинства сети быть переключенной.

Новое сообщение о создании туннеля (Этап 2)

Реализуйте и протестируйте новое сообщение о создании туннеля, как определено в предложении 157 Prop157. Резервируйте поддержку в выпуске 0.9.51. Проведите дополнительное тестирование, затем включите в выпуске 0.9.52.

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

Целевой выпуск: 0.9.52, конец 2021.

Завершение переключения ключей

В этот момент, роутеры старше определенной версии TBD не смогут построить туннели через большинство узлов.

Целевой выпуск: 0.9.53, начало 2022.