ECIES 라우터

Proposal 156
Closed
Author zzz, original
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의 제안은 목적지를 위해 ElGamal을 ECIES로 교체한다고 정의함 (현재 ECIES에 지정됨).

이 제안은 라우터에 대해 ElGamal을 ECIES-X25519로 교체하는 것을 정의함. 이 제안은 필요한 변경 사항에 대한 개요를 제공함. 대부분의 세부 사항은 다른 제안과 명세에 포함됨. 링크는 참조 섹션 참조.

목표

추가 목표는 Prop152 참조.

  • 라우터 아이덴티티의 ElGamal을 ECIES-X25519로 교체
  • 기존 암호화 기본 요소 재사용
  • 호환성을 유지하면서 가능한 경우 터널 빌드 메시지 보안 개선
  • 혼합된 ElGamal/ECIES 피어가 있는 터널 지원
  • 현재 네트워크와 최대한 호환
  • 전체 네트워크를 업그레이드하는 “플래그 데이"가 요구되지 않음
  • 위험을 최소화하기 위해 점진적인 배포
  • 새로운, 더 작은 터널 빌드 메시지

비목표

추가 비목표는 Prop152 참조.

  • 이중 키 라우터 요구 없음
  • 계층 암호화 변경 없음, 이에 대해서는 Prop153 참조

설계

키 위치와 암호화 유형

목적지의 경우, 키는 목적지에 있는 것이 아니라 리스셋에 있으며, 동일한 리스셋에서 여러 암호화 유형을 지원함.

라우터에는 이러한 것이 필요하지 않음. 라우터의 암호화 키는 라우터 아이덴티티에 있음. 공통 구조 명세 Common 참조.

라우터의 경우, 라우터 아이덴티티의 256바이트 ElGamal 키를 32바이트 X25519 키와 224바이트 패딩으로 교체할 예정임. 이는 키 인증서의 암호화 유형에 의해 나타남. 암호화 유형(LS2에서 사용된 것과 동일)은 4임. 이는 리틀엔디안 32바이트 X25519 공개 키를 나타냄. 이는 공통 구조 명세 Common에서 정의한 표준 구성임.

이는 암호화 유형 1-3에 대해 제안 145 Prop145에서 제안된 ECIES-P256에 대한 방법과 동일함. 이 제안은 채택되지 않았지만, Java 구현 개발자들은 코드 베이스의 여러 군데에 체크를 추가하여 라우터 아이덴티티 키 인증서에 암호화 유형을 대비했음. 이 작업의 대부분은 2019년 중반에 수행됨.

터널 빌드 메시지

[tunnel-creation] 명세를 사용하여 ElGamal 대신 ECIES를 사용하는 데 필요한 여러 변경 사항이 있음. 또한 터널 빌드 메시지의 보안을 강화하기 위한 개선 사항을 추가할 예정임.

1단계에서는 ECIES 홉을 위한 빌드 요청 레코드 및 빌드 응답 레코드의 형식과 암호화를 변경할 예정임. 이 변경 사항은 기존 ElGamal 라우터와 호환됨. 이 변경 사항은 제안 152 Prop152에 정의됨.

2단계에서는 새로운 버전의 빌드 요청 메시지, 빌드 응답 메시지, 빌드 요청 레코드 및 빌드 응답 레코드를 추가할 예정임. 크기를 줄여 효율성을 높일 예정임. 이 변경 사항은 터널의 모든 홉에서 지원해야 하며, 모든 홉은 ECIES여야 함. 이 변경 사항은 제안 157 Prop157에 정의됨.

종단간 암호화

기본 사항

Java I2P의 초기 설계에서는 라우터와 그 안의 모든 목적지가 공유하는 단일 ElGamal 세션 키 관리자가 있었음. 공유 SKM은 정보를 누출하고 공격자에 의해 상관될 수 있기 때문에 설계가 변경되어 각 목적지와 라우터 간에 개별 ElGamal SKM을 지원하게 됨. ElGamal 설계는 익명의 발신자만을 지원함; 발신자는 불변 키가 아닌 일시적인 키만 전송했음. 메시지는 발신자의 아이덴티티와 결합되지 않음.

그래서, 우리는 ECIES-X25519-AEAD-Ratchet Prop144, 지금은 ECIES에 지정되어 있는 ECIES Ratchet SKM을 설계함. 이 설계는 발신자의 고정 키를 첫 메시지에 포함시킨 노이즈 “IK” 패턴을 사용하여 지정되었음. 이 프로토콜은 ECIES(유형 4) 목적지에 사용됨. IK 패턴은 익명의 발신자를 허용하지 않음.

따라서, 제안에는 0으로 채워진 고정 키를 사용하여 Ratchet SKM에 익명 메시지를 보내는 방법도 포함했음. 이는 노이즈 “N” 패턴을 시뮬레이션하였으나 호환 가능한 방식으로, ECIES SKM이 익명 및 비익명 메시지를 모두 수신할 수 있었음. ECIES 라우터에 대해 제로 키를 사용하는 것이 목적이었음.

사용 사례 및 위협 모델

라우터로 전송된 메시지의 사용 사례와 위협 모델은 목적지 간의 종단간 메시지와 매우 다름.

목적지 사용 사례 및 위협 모델:

  • 목적지 간 비익명(발신자가 고정 키 포함)
  • 목적지 간 지속적인 트래픽을 효율적으로 지원(전체 핸드셰이크, 스트리밍 및 태그)
  • 항상 아웃바운드 및 인바운드 터널을 통해 전송됨
  • OBEP와 IBGW에서 모든 식별 가능한 특성을 숨기기 위해 일회용 키의 Elligator2 인코딩 요구
  • 두 참가자가 동일한 암호화 유형 사용해야 함

라우터 사용 사례 및 위협 모델:

  • 라우터 또는 목적지에서 익명 메시지(발신자가 고정 키 포함하지 않음)
  • 암호화된 데이터베이스 탐색 및 저장 전용, 일반적으로 floodfill에 전송됨
  • 드문 메시지
  • 다수의 메시지가 상관되지 않도록 함
  • 항상 아웃바운드 터널을 통해 직접 라우터로 전송됨. 인바운드 터널은 사용하지 않음
  • OBEP는 메시지를 라우터로 포워딩하고 있으며 암호화 유형을 알고 있음
  • 두 참가자가 다른 암호화 유형을 가질 수 있음
  • 데이터베이스 탐색 응답은 데이터베이스 탐색 메시지의 응답 키 및 태그를 사용하여 한 번만 메시지로 전송됨
  • 데이터베이스 저장 확인은 번들된 전송 상태 메시지를 사용하여 한 번만 메시지로 전송됨

라우터 사용 사례 비목표:

  • 비익명 메시지가 필요하지 않음
  • 탐색 리스셋을 게시하지 않으므로 인바운드 탐색 터널을 통해 메시지 전송할 필요 없음
  • 태그를 사용한 지속적인 메시지 트래픽이 필요 없음
  • 목적지를 위한 ECIES에 설명 된 “이중 키” 세션 키 관리자를 실행할 필요 없음. 라우터는 단일 공개 키만 가짐.

설계 결론

ECIES 라우터 SKM은 목적지에 대해 ECIES에 지정된 전체 Ratchet SKM을 필요로 하지 않음. IK 패턴을 사용하는 비익명 메시지에 대한 요구 사항이 없음. 위협 모델은 Elligator2로 인코딩된 일회용 키를 요구하지 않음.

따라서 라우터 SKM은 Prop152에 터널 빌딩을 위해 지정한 것과 동일한 노이즈 “N” 패턴을 사용할 것임. 목적지에 대해 ECIES에서 지정한 것과 동일한 페이로드 형식을 사용할 것임. IK에서 지정한 제로 고정 키(바인딩 또는 세션 없음) 모드는 사용하지 않을 것임.

탐색에 대한 응답은 탐색에서 요청한 경우 라쳇 태그로 암호화됨. 이는 Prop154에 문서화되어 있으며, 현재는 I2NP에 지정되어 있음.

이 설계에서는 라우터가 단일 ECIES 세션 키 관리자를 가지도록 함. 목적지를 위한 ECIES에 설명된 “이중 키” 세션 키 관리자를 실행할 필요가 없음. 라우터는 단일 공개 키만 가짐.

ECIES 라우터는 ElGamal 고정 키가 없음. 라우터는 여전히 ElGamal 라우터를 통해 터널을 빌드하고 ElGamal 라우터로 암호화된 메시지를 보내기 위해 ElGamal 구현이 필요함.

ECIES 라우터는 엘가말 태그가 있는 메시지를 받아들이기 위해 ElGamal 세션 키 관리자의 일부가 필요할 수 있음, 프로포절 152에서 명시한 것처럼 ECIES 태그가 있는 응답이 없는 0.9.46 이전의 floodfill 라우터 탐색으로부터 오는 응답으로. 그렇지 않으면, ECIES 라우터는 0.9.46 이전의 floodfill 라우터에 암호화된 응답을 요청할 수 없음.

이것은 선택 사항임. I2P 구현에 따라 결정이 달라질 수 있음 및 0.9.46 또는 그 이상으로 업그레이드 된 네트워크 양에 따라 달라질 수 있음. 현재 이 날짜 기준으로 약 85%의 네트워크가 0.9.46 이상임.

명세

X25519: ECIES 참조.

라우터 아이덴티티 및 키 인증서: Common 참조.

터널 빌딩: Prop152 참조.

새로운 터널 빌드 메시지: Prop157 참조.

요청 암호화

요청 암호화는 Tunnel-Creation-ECIES 및 Prop152에 지정된 것과 동일하며, 노이즈 “N” 패턴을 사용함.

탐색에 대한 응답은 탐색에서 요청한 경우 라쳇 태그로 암호화됨. 데이터베이스 탐색 요청 메시지는 I2NP 및 Prop154에 지정된 대로 32바이트 응답 키와 8바이트 응답 태그를 포함함. 응답을 암호화하는 데 키와 태그가 사용됨.

태그 세트는 생성되지 않음. ECIES-X25519-AEAD-Ratchet Prop144 및 ECIES에 지정된 제로 고정 키 기법은 사용되지 않음. 일회용 키는 Elligator2로 인코딩되지 않음.

일반적으로, 이는 새로운 세션 메시지가 될 것이며, 발신자가 익명이므로 제로 고정 키(바인딩 또는 세션 없음)와 함께 전송될 것임.

초기 ck 및 h를 위한 KDF

이것은 표준 패턴 “N"에 대한 표준 NOISE임. 이는 Tunnel-Creation-ECIES 및 Prop152에 터널 빌드 메시지에 지정된 것과 동일함.


이것은 "e" 메시지 패턴임:

// 프로토콜 이름 정의.
Set protocol_name = "Noise_N_25519_ChaChaPoly_SHA256"
(31 바이트, US-ASCII 인코딩, NULL 종료 없음).

// Hash h = 32 바이트 정의
// 32바이트로 패딩. 32바이트 이상이 아니므로 해싱하지 마세요.
h = protocol_name || 0

Define ck = 32 바이트 연결 체인 키. h 데이터를 ck에 복사.
체인 키를 h로 설정

// MixHash(null prologue)
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 블록을 포함해야 함.

응답 암호화

데이터베이스 탐색 메시지에 대한 응답은 데이터베이스 저장 또는 데이터베이스 검색 응답 메시지임. 이는 I2NP 및 Prop154에 지정된 대로 32바이트 응답 키 및 8바이트 응답 태그로 기존 세션 메시지로 암호화됨.

데이터베이스 저장 메시지에 대한 명시적인 응답은 없음. 발신자는 자신의 전송 상태 메시지를 포함하는 갈릭 메시지로 자신에게 응답을 번들로 보낼 수 있음.

정당화

이 설계는 기존 암호화 기본 요소, 프로토콜 및 코드를 최대한 재사용함.

이 설계는 위험을 최소화함.

구현 노트

이전의 라우터는 라우터의 암호화 유형을 확인하지 않으며, ElGamal로 암호화된 빌드 레코드 또는 netdb 메시지를 전송할 것임. 일부 최근 라우터는 잘못된 형식의 빌드 레코드를 보낼 수 있음. 일부 최근 라우터는 비익명(전체 래쳇) netdb 메시지를 보낼 수 있음. 구현자는 이러한 레코드와 메시지를 가능한 빨리 탐지하고 거부하여 CPU 사용량을 줄여야 함.

문제점

제안 145 Prop145는 제안 152 Prop152와 대부분 호환되게 다시 작성되거나 그렇지 않을 수 있음.

마이그레이션

구현, 테스트 및 배포는 몇 가지 릴리스를 통해 약 1년이 소요될 것임. 단계별 할당은 미정이며, 개발 속도에 따라 다름.

각 I2P 구현에 따라 구현 및 마이그레이션의 세부 사항이 다를 수 있음.

기본 포인트-투-포인트

ECIES 라우터는 ElGamal 라우터와 연결되고 연결을 받을 수 있음. 이것은 이미 가능해야 하며, 여러 검사가 Java 코드베이스에 2019년 중반까지 추가되었기 때문임, 이번에는 미완성 제안 145 Prop145로 인해. 코드 베이스에 ElGamal이 아닌 라우터와의 포인트-투-포인트 연결을 방해하는 것이 있는지 확인하세요.

코드 정확성 확인:

  • ElGamal 라우터가 DatabaseLookup 메시지의 AEAD 암호화된 응답을 요청하지 않도록 보장 (응답이 탐색 터널을 통해 라우터로 돌아올 때)
  • ECIES 라우터가 DatabaseLookup 메시지의 AES 암호화된 응답을 요청하지 않도록 보장 (응답은 탐색 터널을 통해서 라우터로 돌아감)

나중 단계까지, 명세 및 구현이 완료될 때까지:

  • ElGamal 라우터가 ECIES 라우터를 통해 터널 빌드를 시도하지 않도록 보장.
  • ElGamal 라우터가 ECIES floodfill 라우터로 암호화된 ElGamal 메시지를 보내지 않도록 보장. (DatabaseLookups 및 DatabaseStores)
  • ECIES 라우터가 ElGamal floodfill 라우터로 암호화된 ECIES 메시지를 보내지 않도록 보장. (데이터베이스 검색 및 데이터베이스 저장)
  • ECIES 라우터가 자동으로 floodfill이 되지 않도록 함.

변경이 필요하지 않음. 변경이 필요한 경우 타겟 릴리스: 0.9.48

NetDB 호환성

ElGamal floodfills에서 ECIES 라우터 정보를 저장하고 검색할 수 있는지 확인. 이것은 이미 가능해야 함, 여러 검사가 Java 코드베이스에 2019년 중반까지 추가되었기 때문임, 이번에는 미완성 제안 145 Prop145로 인해. 코드 베이스에 ElGamal이 아닌 RouterInfos를 네트워크 데이터베이스에 저장하지 못하도록 하는 것이 있는지 확인하세요.

변경이 필요하지 않음. 변경이 필요한 경우 타겟 릴리스: 0.9.48

터널 빌딩

제안 152 Prop152에 정의된 터널 빌딩을 구현함. ECIES 라우터가 모든 ElGamal 홉으로 터널을 빌드하고 이를 통해 자신의 빌드 요청을 테스트하고 디버그할 수 있도록 시작합니다.

그런 다음, ECIES 라우터가 ElGamal과 ECIES 홉을 혼합 사용하여 터널을 빌드하는 것을 테스트하고 지원합니다.

그런 다음 ECIES 라우터를 통해 터널 빌딩을 활성화합니다. 릴리스 후 제안 152에 대해 비호환적 변경 사항이 만들어지지 않는 한 최소한의 버전 체크가 필요하지 않을 것입니다.

기준 릴리스: 0.9.48, 2020년 말

ECIES floodfills에 Ratchet 메시지

비익명 메시지와 함께 ECIES floodfills에 의한 ECIES 메시지 수신을 구현하고 테스트합니다. 제안 144 Prop144에 정의된 대로 진행합니다. DatabaseLookup 메시지에 대한 AEAD 응답 수신을 구현하고 테스트합니다.

ECIES 라우터가 자동으로 floodfill이 가능합니다. 그런 다음 ECIES 라우터에 메시지 전송을 활성화합니다. 릴리스 후 제안 152에 대해 비호환적 변경 사항이 만들어지지 않는 한 최소한의 버전 체크가 필요하지 않을 것입니다.

기준 릴리스: 0.9.49, 2021년 초. ECIES 라우터가 자동으로 floodfill이 됩니다.

재키잉 및 새로운 설치

새로운 설치는 릴리스 0.9.49부터 ECIES를 기본값으로 합니다.

네트워크에 대한 위험과 혼란을 최소화하기 위해 모든 라우터를 점진적으로 재키잉하세요. 몇 년 전에 승인 유형 마이그레이션을 위해 재키잉을 수행한 기존 코드를 사용합니다. 이 코드는 각 라우터가 각 재시작 시 임의의 작은 확률로 재키잉하게 합니다. 여러 번 재시작 후, 라우터는 아마도 ECIES로 재키잉될 것입니다.

재키잉 시작의 기준은 네트워크의 충분한 부분, 아마도 50%가 ECIES 라우터를 통해 터널을 빌드할 수 있다는 것입니다 (0.9.48 또는 이상).

네트워크 전체의 재키잉을 적극적으로 시작하기 전에, 아마도 대부분 (90% 이상) 이 ECIES 라우터를 통해 터널을 빌드할 수 있어야 함 (0.9.48 이상) AND ECIES floodfills에 메시지를 보낼 수 있어야 함 (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년 말.

재키잉 완료

이 시점에서, 일정 버전 이상 이전의 라우터는 대부분의 피어를 통해 터널을 빌드할 수 없을 것입니다.

기준 릴리스: 0.9.53, 2022년 초.