ml-dsa

오리진에 대한 양자 이후 인증이 이제 지원됩니다 (새 탭에서 열림)

Cloudflare는 Cloudflare와 고객의 원본 서버 사이 연결에 ML-DSA 기반의 포스트퀀텀(PQ) 인증을 지원하기 시작했다. 이제 Custom Origin Trust Store와 Authenticated Origin Pulls를 조합하면 원본 서버 연결을 암호화할 뿐 아니라 양쪽을 포스트퀀텀 방식으로 인증하는 mTLS 구성이 가능하다. 이는 Cloudflare가 2029년까지 완전한 포스트퀀텀 보안을 달성하기 위해 세운 로드맵의 첫 번째 주요 milestone이다. ## 포스트퀀텀 인증이 필요한 이유 - 기존에는 양자컴퓨터가 현재의 암호화를 미래에 해독하는 ‘수집 후 해독(harvest-now/decrypt-later)’ 공격에 대비해 포스트퀀텀 암호화를 우선 배포했다. - 최근 양자컴퓨팅과 암호해석 기술의 발전으로, 공격자가 고전적 인증서를 위조해 서버나 클라이언트를 사칭하는 위험에도 대비해야 하게 됐다. - Cloudflare는 다음 연결에 대해 이미 포스트퀀텀 암호화를 지원하고 있다. - 방문자와 Cloudflare 간 연결: 2022년 지원 - Cloudflare와 원본 서버 간 연결: 2023년 지원 - 이번 변경은 여기에 포스트퀀텀 인증을 추가한 것이다. ## Cloudflare-원본 서버 연결의 특성 - 웹사이트 요청에는 일반적으로 두 개의 TLS 연결이 사용된다. - 방문자 → Cloudflare - Cloudflare → 고객 원본 서버 - Cloudflare-원본 서버 연결에서는 Cloudflare가 TLS 클라이언트 역할을 하므로 인증 방식을 직접 통제할 수 있다. - Cloudflare는 여러 요청을 적은 수의 연결로 묶는 connection pooling을 사용해 PQ 서명에 따른 연결 설정 비용을 분산할 수 있다. - 고객과 이미 Cloudflare 계정 기반의 신뢰 관계가 있으므로, 공개 웹 PKI의 제약 없이 용도에 맞는 사설 PKI를 사용할 수 있다. - 중간 인증서 체인과 Certificate Transparency가 필요하지 않을 수 있다. - 공개 웹의 인증서 생태계보다 빠르게 ML-DSA 인증을 배포할 수 있다. - 방문자-Cloudflare 연결에서는 향후 Merkle Tree Certificates(MTC)를 활용할 계획이며, 초기 배포 목표는 2027년이다. ## 지원되는 ML-DSA 구성 - Cloudflare는 FIPS 204의 세 가지 ML-DSA 파라미터 세트를 지원한다. - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - 대부분의 애플리케이션에는 성능이 가장 우수하고 NIST 보안 강도 카테고리 2를 제공하는 ML-DSA-44가 권장된다. ## Custom Origin Trust Store를 이용한 원본 인증 - Full (strict) SSL 모드에서 Cloudflare는 원본 서버의 인증서를 신뢰 저장소와 대조한다. - 기본적으로 일반적으로 신뢰되는 CA와 Cloudflare Origin CA가 사용된다. - Custom Origin Trust Store(COTS)를 사용하면 고객이 관리하는 CA 목록으로 기본 신뢰 저장소를 대체할 수 있다. - 이제 ML-DSA CA를 업로드할 수 있으며, Cloudflare는 해당 CA로부터 발급된 원본 서버 인증서만 신뢰하도록 구성할 수 있다. - COTS 사용에는 Advanced Certificate Manager가 필요하다. ## Authenticated Origin Pulls를 이용한 상호 인증 - Authenticated Origin Pulls(AOP)는 원본 서버가 Cloudflare에서 온 요청만 처리하도록 제한하는 기능이다. - Cloudflare가 클라이언트 인증서를 제시하므로 원본 서버는 요청 주체가 Cloudflare인지 검증할 수 있다. - 이를 통해 Cloudflare와 원본 서버 간 상호 TLS(mTLS)를 구성할 수 있다. - AOP는 모든 Cloudflare 요금제에서 무료로 제공된다. - 영역(zone)별 및 호스트명별 설정에서 다음을 업로드할 수 있다. - ML-DSA 인증서 - ML-DSA 개인 키 - 개인 키는 현재 FIPS 204 seed 형식으로만 업로드할 수 있다. - 전역(global) 설정의 ML-DSA 지원은 아직 제공되지 않으며 추후 작업으로 예정되어 있다. ## 다운그레이드 공격 방지 - 양쪽이 PQ 인증을 지원하는 것만으로는 완전한 포스트퀀텀 보안이 보장되지 않는다. - 원본 서버가 기존의 양자 취약 인증 방식도 계속 신뢰하면, 공격자가 고전적 인증서를 위조해 연결을 다운그레이드할 수 있다. - 따라서 인증서를 검증하는 원본 서버는 양자 취약한 인증 메커니즘에 대한 신뢰를 제거해야 한다. - 복잡한 PKI에서는 인증 체계 전환 단계와 신뢰 설정을 별도로 설계해야 한다. ## 구성에 필요한 도구와 절차 - 인증서 생성에는 OpenSSL 3.5.0 이상이 필요하다. - Cloudflare가 현재 허용하는 개인 키 형식은 FIPS 204의 seed-only 인코딩이다. - 일반적인 구성 절차는 다음과 같다. - ML-DSA-44 등의 알고리즘으로 원본 서버용 CA와 인증서 체인을 생성한다. - 생성한 CA를 COTS에 업로드한다. - ML-DSA 클라이언트 인증서와 개인 키를 AOP의 영역별 또는 호스트명별 설정에 업로드한다. - Cloudflare API 또는 대시보드를 통해 원본 서버의 mTLS 및 인증서 검증을 활성화한다. - 원본 서버에서 양자 취약 인증서와 인증 기관을 신뢰하지 않도록 설정한다. ## 실용적인 권장 사항 대부분의 사용자는 ML-DSA-44를 사용해 COTS와 AOP를 함께 구성하는 것이 적절하다. 단순히 ML-DSA 인증서를 추가하는 데 그치지 말고, 원본 서버의 신뢰 저장소에서 기존 양자 취약 인증 방식을 제거해야 다운그레이드 공격까지 방어할 수 있다.

왜 우리는 더 나은 양자내성 서명 알고리즘을 기다릴 수 없는가 (새 탭에서 열림)

RSA와 ECC는 충분히 강력한 양자컴퓨터가 등장하면 깨질 수 있으므로, 양자내성을 갖춘 암호 알고리즘으로의 전환이 필요하다. ML-KEM은 이미 널리 사용되기 시작했지만, 인증을 보호하는 양자내성 서명은 아직 선택지가 제한적이며 당장은 ML-DSA를 사용해야 한다. 더 나은 알고리즘이 개발 중이지만 전환 시점에 맞춰 준비되기 어렵기 때문에, “원하는 알고리즘이 아니라 현재 가진 알고리즘으로 대응해야 한다”는 것이 글의 결론이다. ## 양자내성 암호 전환이 시급한 이유 - RSA와 ECC는 현재 인터넷 보안의 핵심이지만, 충분히 발전한 양자컴퓨터에서는 취약해진다. - 공격자가 지금 암호화된 데이터를 수집해 두었다가 미래에 복호화하는 **harvest-now-decrypt-later** 공격이 가능하다. - NIST는 8년에 걸친 국제 경쟁 끝에 2024년 다음 알고리즘을 표준화했다. - **ML-KEM**: 양자내성 키 캡슐화·암호화 알고리즘 - **ML-DSA**: 양자내성 디지털 서명 알고리즘 - Cloudflare는 이미 대부분의 트래픽에 ML-KEM을 적용하고 있으며, 2029년까지 전체 시스템을 양자내성 상태로 전환하는 것을 목표로 한다. - 암호화만으로는 충분하지 않다. 인증서와 인증 시스템의 서명까지 양자내성으로 바꿔야 무단 접근을 막을 수 있다. ## 당장은 ML-DSA를 사용해야 하는 이유 - ML-DSA는 현재 표준화된 양자내성 서명 중 가장 범용적인 선택지다. - 다만 기존 RSA·ECC에 비해 다음과 같은 단점이 있다. - 공개키와 서명 크기가 훨씬 크다. - 네트워크 전송량이 증가한다. - RSA와 ECC에서 활용하던 일부 최적화 기법을 적용하기 어렵다. - 더 나은 후보가 개발되고 있지만, 표준화와 구현·배포까지는 오랜 시간이 걸린다. - NIST는 새로운 서명 알고리즘 9개를 “signatures on-ramp” 3라운드로 진출시켰다. - 기존 경쟁에서 선정된 Falcon의 후속 표준인 **FN-DSA**도 표준 초안이 곧 나올 예정이다. - 그러나 이 알고리즘들은 현재 진행 중인 양자내성 전환에 맞춰 준비되기 어렵다. - 따라서 완벽한 알고리즘을 기다리기보다, 현재 사용 가능한 ML-DSA로 우선 전환해야 한다. ## 양자내성 서명 알고리즘의 평가 기준 - 글에서는 TLS에 적합한 128비트 보안 수준의 변형을 중심으로 후보들을 비교한다. - 주요 평가 지표는 다음과 같다. - 공개키 크기 - 서명 크기 - 서명 생성 시간 - 서명 검증 시간 - 후보 알고리즘은 보안 수준별로 여러 변형을 제공하며, 3라운드 과정에서 성능과 크기가 바뀔 수 있다. - 일부 알고리즘은 구현상의 위험도 존재한다. - **FN-DSA·SQIsign**: 빠르고 타이밍 부채널 공격에 안전한 구현이 어렵다. - **LMS**: 서명마다 상태를 보존해야 하며, 안전한 서명을 위해 상당한 캐시가 필요하다. - **SLH-DSA의 특정 변형**: 생성 가능한 서명 수가 제한적이다. ## ‘만능 알고리즘’이 없는 상황 - 양자 공격에 취약하다는 점을 제외하면 Ed25519는 여전히 거의 모든 지표에서 가장 뛰어난 서명 알고리즘이다. - 공개키와 서명이 작다. - 서명 생성이 빠르다. - 검증 속도도 대부분의 애플리케이션에 충분하다. - 반면 양자내성 알고리즘에는 Ed25519와 같은 만능 선택지가 없다. - 크게 두 종류로 나뉜다. - **전문가형(specialist)**: 특정 지표에서는 ECC에 근접하지만 다른 부분에 큰 단점이 있다. - **범용형(generalist)**: 모든 지표에서 균형 잡힌 대신, ECC만큼 뛰어난 항목은 적다. - ML-DSA는 대표적인 범용형 알고리즘으로, 크기·성능·구현 난이도에서 극단적인 약점은 없지만 전반적으로 부담이 크다. ## SQIsign: 작은 서명과 느린 서명 생성 - SQIsign은 전송 크기만 보면 ECC의 대체재에 가까운 특성을 보인다. - 서명 크기: 148바이트 - 공개키 크기: 65바이트 - RSA-2048보다도 작다. - 그러나 다음과 같은 약점이 있다. - 후보 중 가장 복잡한 알고리즘이다. - 서명 생성과 검증이 느리다. - 타이밍 부채널 공격에 안전한 서명 생성 구현이 어렵다. - 부채널 방어를 적용하면 성능 저하가 더 커진다. - 2024년과 비교하면 구현이 크게 개선되었다. - 당시에는 타이밍 부채널 안전 구현이 없었다. - 검증 속도도 현재보다 약 20배 느렸다. - 최근에는 알고리즘 단순화와 성능 개선이 진행됐다. - 그래도 안전한 서명 생성은 가까운 미래에 TLS 핸드셰이크처럼 온라인으로 반복되는 작업에 쓰기 어려울 가능성이 높다. - 대신 서명 생성보다 검증이 중요한 오프라인 용도에는 적합할 수 있다. - 인증기관(CA)의 서명 - DNSSEC - SQIsign은 아이소제니(isogeny) 수학에 기반한다. - 같은 계열의 SIKE는 NIST 경쟁 후반에 치명적으로 공격받았다. - 다만 SIKE는 이미 보안 우려가 있었고, 그 때문에 표준화에서 제외된 뒤 추가 검토 대상으로 남아 있었다. - SQIsign은 SIKE의 취약점과 관련된 torsion point를 사용하지 않으므로 동일한 문제가 직접 적용되지는 않는다. - 현재 SQIsign에 대해 알려진 최선의 공격은 잘 선택된 타원곡선처럼 일반적인 전수공격에 가깝다. - 그러나 아이소제니 수학은 매우 풍부하고 공격 표면도 넓어, 충분한 검토 없이 서둘러 표준화해서는 안 된다. ## 실용적인 결론 현재 시스템은 더 나은 서명 알고리즘이 나올 때까지 기다리기보다 ML-DSA를 중심으로 양자내성 전환을 시작해야 한다. 이후 FN-DSA, SQIsign 등 후속 알고리즘이 표준화되고 구현 안정성이 검증되면, TLS·CA·DNSSEC처럼 용도별 특성에 맞춰 ML-DSA와 함께 선택적으로 도입하는 전략이 현실적이다.