JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Аннотация

Повысить безопасность Java-приложений, которым нужна защищённая сетевая связь, за счёт реализации алгоритмов гибридного обмена ключами для TLS 1.3. Такие алгоритмы защищают от будущих атак с использованием квантовых вычислений: они сочетают алгоритм, устойчивый к квантовым атакам, с традиционным алгоритмом. Приложения, использующие API javax.net.ssl, по умолчанию получат преимущества этих улучшенных алгоритмов без изменения существующего кода.

Что не является целью

• Целью не является реализация гибридного обмена ключами ни для какого API, кроме javax.net.ssl, ни для какой версии TLS, кроме 1.3.

• Целью не является реализация негибридных схем обмена ключами для TLS на основе ML-KEM, которые тоже защищали бы от будущих атак с использованием квантовых вычислений. Однако мы можем сделать это в будущем.

Мотивация

Квантовые вычисления представляют растущую угрозу для широко распространённых алгоритмов шифрования с открытым ключом, таких как Rivest-Shamir-Adelman (RSA) и Elliptic-Curve Diffie-Hellman (ECDH). Переходить на алгоритмы, устойчивые к квантовым атакам, нужно срочно, хотя крупномасштабных квантовых компьютеров, способных взломать эти алгоритмы, пока не существует: злоумышленник может собрать зашифрованные данные уже сегодня, сохранить их и расшифровать, когда такие компьютеры станут доступны.

Чтобы защитить TLS от этой угрозы «собери сейчас, расшифруй потом», рабочая группа TLS в Internet Engineering Task Force (IETF) разработала основу для схем гибридного обмена ключами для TLS 1.3. Схема гибридного обмена ключами сочетает алгоритм, устойчивый к квантовым атакам, с традиционным алгоритмом и остаётся безопасной, пока хотя бы один из алгоритмов не взломан. Такой подход защищает от квантовых атак и при этом учитывает, что новые алгоритмы ещё не прошли тех многолетних испытаний и анализа, которые уже проведены для традиционных алгоритмов.

В платформе Java уже есть строительные блоки для реализации схем гибридного обмена ключами: KEM API, добавленный в Java 21 (JEP 452), и алгоритм ML-KEM, добавленный в Java 24 (JEP 496). Реализация этих схем гибридного обмена ключами для TLS — следующий шаг в поддержке постквантовой криптографии в платформе.

Описание

Мы доработаем реализацию TLS 1.3 в JDK, чтобы она поддерживала три новые схемы Post-Quantum Hybrid Key Exchange, которые сочетают ML-KEM с традиционными алгоритмами Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE):

• X25519MLKEM768: гибридная схема, сочетающая ECDHE с X25519 и ML-KEM-768,
• SecP256r1MLKEM768: гибридная схема, сочетающая ECDHE на кривой secp256r1 с ML-KEM-768, и
• SecP384r1MLKEM1024: гибридная схема, сочетающая ECDHE на кривой secp384r1 с ML-KEM-1024.

В спецификации TLS схемы обмена ключами называются «именованными группами» (named groups). Поэтому мы добавим названия этих схем в раздел Named Groups спецификации Java Security Standard Algorithm Names. Названия совпадают с указанными IANA.

Использование схем гибридного обмена ключами

TLS-клиенты перечисляют поддерживаемые схемы обмена ключами в порядке предпочтения в первом сообщении TLS handshake. По умолчанию реализация TLS 1.3 в JDK будет ставить гибридную схему X25519MLKEM768 в начало этого списка, делая её наиболее предпочтительной. Таким образом, чтобы воспользоваться устойчивым к квантовым атакам TLS, когда он доступен, не потребуется менять существующий код, если только этот код ещё не выбирает конкретные схемы обмена ключами.

Полный список схем по умолчанию будет таким: X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072 и ffdhe4096. Исходя из этого порядка схем по умолчанию, клиенты TLS 1.3 будут предлагать общие ключи (key shares) X25519MLKEM768 и x25519.

Гибридная группа X25519MLKEM768 — самая быстрая из гибридных групп, и именно её сейчас по умолчанию включает большинство TLS-клиентов. Гибридные группы SecP256r1MLKEM768 и SecP384r1MLKEM1024 по умолчанию не включены. Список схем по умолчанию можно изменить с помощью системного свойства jdk.tls.namedGroups. Также можно выбрать конкретные схемы, вызвав метод SSLParameters::setNamedGroups при настройке соединения через TLS-сокет, например:

SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
                                getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();

// Configure the socket to use two hybrid KEM schemes and
// two traditional schemes
params.setNamedGroups(new String[] {
    "SecP256r1MLKEM768", "X25519MLKEM768", "secp256r1", "x25519"
});
tlsSock.setSSLParameters(params);

Альтернативы

Как сказано выше, мы не предлагаем реализовывать негибридные схемы обмена ключами для TLS на основе ML-KEM. Такие чистые схемы — ещё один способ защититься от будущих атак с использованием квантовых вычислений. Однако гибридные схемы сейчас более востребованы и дают минимальную гарантию безопасности как от квантовых, так и от традиционных атак, которую ни один из классов алгоритмов не обеспечивает сам по себе. Чистые схемы ML-KEM мы можем реализовать в дальнейшей работе.

Тестирование

• Модульные тесты подтвердят корректное взаимодействие клиента и сервера с новыми схемами гибридного обмена ключами, а также корректную работу, когда эти новые именованные группы задаются через системное свойство jdk.tls.namedGroups или через SSLParameters::setNamedGroups.

• Тестирование с другими реализациями TLS, поддерживающими гибридные схемы, подтвердит совместимость.