포스트 양자 보안 전환 (Post-Quantum Security Transition)

양자 컴퓨터 시대를 대비해 리눅스 커널 개발자가 실제로 점검해야 할 TLS, VPN, Secure Boot, 모듈 서명, TPM, 공급망, 저장 데이터 전환 포인트를 실무 중심으로 정리합니다.

개요

양자 컴퓨터(Quantum Computer) 시대의 위협을 논할 때 가장 흔한 오해는 "모든 암호가 한 번에 무너진다"는 식의 단순화입니다. 실제로는 공개키(Public-Key) 계열과 대칭키(Symmetric-Key) 계열의 영향이 크게 다르며, 리눅스 커널 개발자 관점에서는 프로토콜 핸드셰이크, 서명 검증기, 부팅 체인, 공급망 검증기가 먼저 문제를 드러냅니다.

이 문서는 "양자 컴퓨터가 무섭다"는 수준의 일반론이 아니라, 지금 어떤 자산을 찾아야 하고, 어디는 하이브리드가 가능하며, 어디는 검증기 전체를 같이 바꿔야 하는지를 실무 중심으로 정리합니다. 이론 설명은 필요한 만큼만 담고, 깊은 수학 배경은 암호화 알고리즘 내부 구조로 넘깁니다.

NIST는 2024년 8월 13일에 FIPS 203(ML-KEM), FIPS 204(ML-DSA), FIPS 205(SLH-DSA)를 최종 발표했으며, 미국 NSA는 2025년 3월 CNSS Policy 15(CNSSP-15) 개정판을 통해 CNSA 1.0 폐지와 CNSA 2.0 전환 타임라인을 국가 안보 시스템(NSS)에 제시했습니다.

왜 이 문제가 생기는가

기초 개념만 놓고 보면 문제는 단순합니다. 지금의 공개키 암호는 "역연산이 매우 어렵다"는 가정 위에 서 있는데, 양자 알고리즘은 그 역연산 일부를 고전 컴퓨터보다 훨씬 효율적으로 처리할 수 있습니다. 반면 대칭 암호는 "모든 키를 다 해보는 데 시간이 너무 오래 걸린다"는 쪽에 더 가깝기 때문에, 같은 양자 위협이라도 영향이 다르게 나타납니다.

위협 모델

양자 시대 위협은 단순히 "언젠가 RSA가 깨진다"는 문장으로 끝나지 않습니다. 커널과 운영 환경에서는 적어도 세 가지 축을 나눠서 봐야 합니다.

위협을 머릿속에서 그리는 방법

양자 위협을 판단할 때는 "암호 알고리즘"보다 먼저 어떤 자산이 얼마나 오래 살아남아야 하는가를 생각하는 편이 좋습니다. 예를 들어 오늘의 HTTPS 세션 쿠키는 하루 뒤면 가치가 사라질 수 있지만, 오늘 전송한 소스 코드 서명 키 백업이나 장기 계약 문서는 10년 뒤에도 가치가 남을 수 있습니다.

실제 운영 시나리오 세 가지

1. HTTPS 서비스:
   지금 방문자의 세션은 오늘 끝날 수 있지만, 기업 고객의 계약 문서와 API 토큰은 장기 가치가 남을 수 있습니다. 그래서 공용 웹사이트와 내부 관리망의 우선순위는 같지 않습니다.
2. 커널 모듈(Kernel Module) 배포:
   오늘 서명한 모듈이 내일만 검증되면 끝나는 것이 아니라, 나중에 장애 복구나 포렌식 때도 "그때 이 바이너리가 진짜였는가"를 입증해야 할 수 있습니다.
3. 원격 증명 인프라:
   TPM Quote 자체보다 중요한 것은 검증 서버가 그 증명을 어떤 인증서 체인(Chain of Trust)으로 신뢰하느냐입니다. 양자 전환은 여기서 자주 지연됩니다.

무엇이 실제로 위협받는가

양자 위협은 암호 primitive마다 다르게 작용합니다. 아래 표는 리눅스 커널 문서에서 자주 다루는 기술을 세 갈래로 나눈 것입니다.

왜 대칭 암호는 상대적으로 덜 급한가

실무자가 가장 많이 헷갈리는 지점이 바로 여기입니다. 네트워크 패킷을 실제로 암호화하는 것은 보통 AES-GCM이나 ChaCha20-Poly1305 같은 대칭 암호입니다. 그런데 이 세션 키를 처음 안전하게 합의하는 과정은 대개 ECDH나 DH 같은 공개키 기반 절차입니다. 양자 위협은 이 "문을 여는 열쇠 교환"에 먼저 큰 충격을 줍니다.

네트워크 프로토콜과 커널 경계

실무적으로 가장 먼저 부딪히는 영역은 TLS, VPN, QUIC 같은 네트워크 프로토콜입니다. 여기서 중요한 것은 데이터 평면(Data Plane)과 제어 평면(Control Plane)을 분리해서 보는 것입니다.

기초 예시로 이해하는 세 가지 상황

하이브리드 설계와 알고리즘 선택

TLS 1.3 하이브리드 키 교환은 기존 타원 곡선(Elliptic Curve) 기반 키 교환과 ML-KEM을 병렬로 수행하고, 두 공유 비밀을 하나의 결합 함수로 묶어 세션 키를 만듭니다(IETF draft-ietf-tls-hybrid-design의 concat 방식). 어느 한쪽 알고리즘이 나중에 깨져도 나머지 하나가 세션을 보호하므로, 전환기에는 두 경로를 모두 강제하는 정책이 중요합니다. 결합 단계에서 도메인 분리(Domain Separation) 라벨을 쓰지 않으면 두 프로토콜의 공유 비밀이 충돌할 수 있으므로 표준 구현의 키 스케줄을 그대로 따라야 합니다.

알고리즘별 키·서명 크기 비교

FIPS 203/204/205에 정의된 고정 크기입니다. 커널 7.0의 include/crypto/mldsa.h 상수와 일치합니다. 크기 증가는 핸드셰이크 메시지, 인증서 체인, 패킷 MTU 계획에 그대로 나타나므로 용량 계획의 입력값으로 사용합니다.

부팅 체인과 공급망

양자 전환에서 가장 까다로운 부분은 검증기 전체가 함께 움직여야 하는 영역입니다. 네트워크 핸드셰이크는 비교적 하이브리드가 쉽지만, 부팅 체인과 공급망은 펌웨어, 부트로더, 운영체제 도구, CI, HSM, 감사 로그까지 연결됩니다.

업데이트 신뢰 체인(Chain of Trust)은 어떻게 보아야 하는가

부팅 체인과 공급망은 네트워크와 달리 "한 번의 핸드셰이크"로 끝나지 않습니다. 개발자가 서명한 아티팩트가 빌드 시스템(Build System), 저장소, 배포판, 부트로더, 커널, 모듈 로더를 거치며 여러 번 검증됩니다. 따라서 중간 어느 검증기 하나라도 PQ 전환을 이해하지 못하면 전체 체인이 고전 알고리즘에 계속 묶일 수 있습니다.

저장 데이터와 장기 기밀성

dm-crypt나 파일시스템(Filesystem) 암호화는 대칭 암호가 중심이므로, 네트워크 핸드셰이크처럼 즉시 붕괴하는 영역은 아닙니다. 그래서 "디스크 암호화는 당장 안 바꿔도 된다"는 말이 어느 정도는 맞습니다. 다만 이것이 아무 것도 안 해도 된다는 뜻은 아닙니다.

• 장기 기밀 데이터: 10년 이상 숨겨야 하는 백업, 아카이브, 의료 정보, 국가 기반 자료는 AES-256 중심으로 보안 마진을 재점검하는 편이 안전합니다.
• 키 래핑 경로: 실제 위험은 종종 데이터 평문이 아니라, 그 데이터를 보호하는 키를 RSA나 ECC로 감싼 백업 포맷과 키 배포 경로에서 발생합니다.
• 패스프레이즈 기반 키 유도: LUKS2의 Argon2 같은 강한 KDF는 계속 중요하지만, 이것만으로 공개키 전환 문제가 해결되지는 않습니다.
• 원격 접근형 스토리지: Ceph, NFS-over-TLS, 원격 관리 채널처럼 네트워크 핸드셰이크를 동반하는 저장 경로는 수확 후 복호화 위협을 따로 봐야 합니다.

기초 예시: 무엇은 급하고 무엇은 덜 급한가

하드웨어, TPM, 난수, 성능

양자 전환은 알고리즘 이름만 바꾸는 작업이 아닙니다. 하드웨어 가속, TPM 증명, NIC 오프로드, 패킷 크기, CPU 용량 계획이 함께 바뀝니다.

특히 네트워크 장비와 방화벽(Firewall)은 "데이터 평면은 오프로드되는데 제어 평면만 CPU에 남는" 비대칭 병목이 자주 생깁니다. PQC 전환기에는 이 차이가 더 커질 수 있으므로, 단순한 Gbps 수치만 보지 말고 핸드셰이크 처리량(Throughput), 인증서 체인 크기, 초기 연결 지연을 같이 측정해야 합니다.

왜 성능 수치가 달라지는가

대략적으로 보면 PQ 전환은 세 군데에서 비용을 늘립니다. 첫째, 핸드셰이크 메시지 안에 들어가는 공개키와 보조 데이터가 커집니다. 둘째, 서명과 검증에 쓰는 CPU 시간이 늘어날 수 있습니다. 셋째, 기존 하드웨어 가속기는 AES나 SHA는 잘 가속해도 새 KEM과 서명 알고리즘은 곧바로 가속하지 못할 수 있습니다.

난수(Randomness)와 포스트 양자 보안

PQC 전환에서 가장 과소평가되는 전제 조건이 난수입니다. RSA·ECC는 주로 키 생성에만 난수를 쓰지만, PQC는 매 세션·매 서명마다 난수를 소비합니다. ML-KEM 캡슐화는 32바이트의 신선한(fresh) 난수 메시지 m을 요구하며(FIPS 203), ML-DSA 서명은 기본적으로 신선한 난수와 사전 생성 시드를 함께 쓰는 hedged 변형을 사용합니다(FIPS 204). 난수 생성기가 취약하면 알고리즘 자체가 표준을 정확히 따라도 보안이 무너집니다.

알고리즘별 난수 의존 지점

난수 실패가 실제 공격으로 이어지는 경로

리눅스 커널 난수 경로 실무

• CRNG(ChaCha20): 커널 getrandom()은 ChaCha20 기반 CRNG(Cryptographically Secure RNG)의 fast-key-erasure 출력입니다. 부팅 초기 CRNG 준비 전에는 블로킹되며, CONFIG_RANDOM_TRUST_CPU/CONFIG_RANDOM_TRUST_BOOTLOADER로 준비 시간을 단축할 수 있습니다.
• getrandom() vDSO(6.11+): 같은 ChaCha20 스트림을 사용자 공간에서 직접 소비하며, 커널 재시드(Reseed) 시 generation 카운터로 재키잉합니다. opaque_state는 스레드(Thread)당 하나씩 할당해야 하며, fork() 후 자식이 부모 상태를 그대로 이어 쓰면 같은 스트림이 이어질 수 있으므로 새 상태를 할당해야 합니다.
• VM 스냅샷·복제: 스냅샷 복원으로 RNG 상태가 중복되면 동일한 난수 스트림이 재생될 수 있습니다. 커널은 add_vmfork_randomness()로 하이퍼바이저(Hypervisor)가 고유 VM ID를 넣고 CRNG를 강제 재시드하는 경로를 제공하므로, 가상화(Virtualization) 관리 계층에서 복원 직후 호출해야 합니다.
• 사용자 공간 DRBG: OpenSSL 3.x는 기본적으로 AES-256-CTR DRBG를 쓰고 getrandom()에서 시드합니다. FIPS 140-3 검증 모듈은 SP 800-90A DRBG와 SP 800-90B 엔트로피 소스 검증을 요구하므로, 난수를 직접 구현하기보다 검증된 라이브러리를 사용합니다.

# 1. 커널 난수 소스 신뢰 설정 확인 (CONFIG_RANDOM_TRUST_CPU / BOOTLOADER)
zcat /proc/config.gz 2>/dev/null | grep RANDOM_TRUST || \
    grep -E "CONFIG_RANDOM_TRUST" /boot/config-$(uname -r)

# 2. CRNG 준비 상태 (준비되면 256 — 이후에는 항상 256)
cat /proc/sys/kernel/random/entropy_avail

# 3. OpenSSL DRBG가 OS 난수(getrandom)에서 시드되는지 추적
strace -e trace=getrandom openssl rand -hex 16 2>&1 | head

# 4. 하이브리드 TLS 연결마다 key_share가 새로 만들어지는지 확인
openssl s_client -connect 127.0.0.1:4433 -tls1_3 -groups X25519MLKEM768 \
    -brief 2>&1 | grep -i negotiated

전환 체크리스트

실무에서는 한 번에 전체를 바꾸기보다, 영향이 큰 경로부터 순차적으로 정리하는 편이 안전합니다.

1. 암호 자산 목록을 만듭니다. TLS 종료점, WireGuard 피어, IKE 게이트웨이, Secure Boot 키, 모듈 서명 키, Git 태그 서명 키, TPM 증명 체계를 모두 나열합니다.
2. 장기 기밀 자산을 분리합니다. 수확 후 복호화 위협이 큰 서비스부터 우선순위를 매깁니다.
3. 하이브리드 가능한 구간을 먼저 엽니다. TLS와 릴리스 서명처럼 병행 운용이 가능한 영역부터 시험합니다.
4. 검증기 호환성을 따로 추적합니다. 펌웨어, 부트로더, 배포판 툴, HSM, CI, 원격 검증기가 어떤 알고리즘을 실제로 받는지 확인합니다.
5. 성능 한계를 다시 측정합니다. 핸드셰이크 지연, CPU 사용량, 패킷 크기, 인증서 체인 크기, 서명 검증 시간을 재측정합니다.
6. 로그와 감사 기준을 바꿉니다. 어떤 경로가 고전 전용인지, 어떤 경로가 하이브리드인지, 어떤 경로가 PQ 우선인지 운영자가 구분할 수 있어야 합니다.

# 1. 커널과 사용자 공간의 암호 자산을 훑는 기본 점검
grep -E "CONFIG_MODULE_SIG|CONFIG_SYSTEM_TRUSTED|CONFIG_IMA|CONFIG_INTEGRITY" .config
mokutil --sb-state
keyctl list %:.platform

# 2. TLS / OpenSSL / PQC 관련 지원 확인
openssl version
openssl list -public-key-algorithms 2>/dev/null | grep -E "ML-|SLH"
openssl list -kem-algorithms 2>/dev/null

# 3. VPN과 키 교환 경계 확인
wg show
ip xfrm state
ip xfrm policy

# 4. TPM과 측정 부팅 경계 확인
tpm2_pcrread sha256:7,11 2>/dev/null
journalctl -b | grep -i "secure boot\\|ima\\|tpm"

작게 시작하는 30일 예시

1. 1주차:
   TLS 종료점, VPN, Secure Boot, 모듈 서명, 릴리스 서명 위치를 표로 정리합니다.
2. 2주차:
   각 경로가 어떤 공개키 알고리즘과 어떤 검증기를 쓰는지 기록합니다.
3. 3주차:
   하이브리드 전환이 가능한 서비스 한 곳을 고르고 시험 환경에서 연결 지연과 CPU 비용을 측정합니다.
4. 4주차:
   운영 문서에 "고전 전용", "하이브리드 시험 중", "장기 전환 필요" 상태를 표시하고 다음 분기 계획을 세웁니다.

커널·배포판 PQC 동향 (2024-2026)

2024년 8월 NIST가 FIPS 203/204/205 최종본을 공개한 뒤 2년 동안 리눅스 생태계는 사용자 공간(User Space)부터 빠르게 포스트 양자(Post-Quantum) 알고리즘을 받아들이기 시작했습니다. 커널 본체도 7.0(2026-04-12) 개발 주기에서 ML-DSA(Dilithium) 검증 라이브러리와 X.509 인증서 처리를 처음으로 병합했습니다. ML-KEM과 SLH-DSA는 아직 커널 업스트림에 없으므로, 2026년 현재는 "상층부는 이미 움직이고, 커널은 검증기 쪽부터 따라가는" 전환기로 볼 수 있습니다.

CNSA 2.0 규제 달력

미국 NSA의 CNSA 2.0과 NIST SP 800-131A Rev.3는 리눅스 운영자가 실제로 의식해야 하는 외부 압력의 중심입니다. 배포판 정책과 커널 기본값이 이 달력을 따라 조금씩 움직입니다.

커널 내부 PQC 현황 점검

2026년 8월 현재 커널 업스트림에는 ML-DSA가 7.0(2026-04-12)에서 처음 병합되었으며, 나머지 ML-KEM·SLH-DSA는 아직 없습니다. 대부분의 실제 PQC 경로는 여전히 사용자 공간 라이브러리(OpenSSL 3.5, liboqs, SymCrypt-OpenSSL, NSS 3.118)를 거칩니다. 커널이 관여하는 지점은 다음과 같은 경계에 집중됩니다.

• kTLS 오프로드 — TLS 1.3 핸드셰이크는 사용자 공간에서 끝나고 레코드 계층만 커널로 내려오므로, 하이브리드 KEM 전환의 영향은 kTLS가 아닌 handshake upcall에 나타납니다.
• 모듈 서명 — 7.0에서 asymmetric_keys가 mldsa44/65/87 X.509 공개키를 받아들이게 되어 ML-DSA로 서명한 모듈의 검증이 가능해졌습니다. 다만 커널의 ML-DSA는 검증 전용이며 서명 생성은 OpenSSL 3.5 등 외부 툴에서 수행합니다.
• IMA/EVM — 해시 알고리즘 자체보다는 서명 체계(X.509 기반)가 문제이며, 7.0에서 asymmetric-key 계열에 ML-DSA가 올라온 만큼 같은 체인으로 확장될 여지가 있습니다.
• fscrypt, dm-crypt — 대칭 경로라 PQC 직접 영향은 작지만, DebConf25는 장기 아카이브 시 KEM으로 감싼 파일 키 래핑(Key Wrapping)을 재설계해야 한다는 제안을 공개했습니다.
• TPM 2.0 — TCG의 PQC 확장(LDAA 등)은 2026년 기준 아직 주요 벤더 펌웨어에 내려오지 않았으며, 커널 drivers/char/tpm/ 쪽도 전통적인 RSA/ECDSA 경로가 유지됩니다.

# 커널 업스트림에서 PQC 관련 심볼 빠른 확인 (7.0+ 기준: ML-DSA는 존재, ML-KEM/SLH-DSA는 미정의)
grep -RE "ML_DSA|ML_KEM|SLH_DSA" include/ crypto/ lib/crypto/ 2>/dev/null | head
ls lib/crypto/mldsa.c crypto/mldsa.c 2>/dev/null && echo "ML-DSA 병합됨 (7.0+)"

# 모듈 서명 키 알고리즘 현재 설정 확인
scripts/config --state MODULE_SIG_KEY
scripts/config --state MODULE_SIG_HASH
scripts/config --state MODULE_SIG_FORMAT

# asymmetric-key 서브시스템의 지원 알고리즘 목록
cat /proc/crypto | awk '/^name/ {name=$3} /^type.*akcipher/ {print name}'

OpenSSL 3.5·OpenSSH 실습

실무자에게 가장 빠른 학습 방법은 OpenSSL 3.5를 설치한 환경에서 직접 하이브리드 TLS 연결과 PQC 서명을 생성해 보는 것입니다. 아래 예시는 OpenSSL 3.5가 기본으로 깔리는 RHEL 10 또는 Fedora 42 이상에서 바로 실행됩니다.

ML-KEM-768 하이브리드 키 교환 확인

# 현재 OpenSSL이 지원하는 KEM과 서명 목록
openssl list -kem-algorithms | grep -E "ML-KEM|X25519MLKEM"
openssl list -signature-algorithms | grep -E "ML-DSA|SLH-DSA"

# 서버 측: TLS 1.3 + 하이브리드 key_share로만 응답하도록 강제
openssl s_server -accept 4433 \
    -cert server.crt -key server.key \
    -tls1_3 -groups X25519MLKEM768 \
    -www

# 클라이언트 측: 같은 그룹으로 접속하고 실제 선택된 KEM 확인
openssl s_client -connect 127.0.0.1:4433 \
    -tls1_3 -groups X25519MLKEM768 \
    -brief 2>&1 | grep -E "Negotiated|Peer signature"

TLS 1.3 핸드셰이크에서 ClientHello에 두 개의 key_share(X25519와 X25519MLKEM768) 항목이 들어가는지는 tshark로 확인합니다. PQC 키 교환은 ClientHello 크기가 1KB를 훌쩍 넘기게 만들며, 일부 구형 미들박스는 이 크기에서 단절을 일으키는 것이 2025년의 대표적 운영 이슈입니다.

# 하이브리드 key_share가 실제 전송되는지 패킷 레벨에서 확인
tshark -i lo -f "tcp port 4433" \
    -Y "tls.handshake.type == 1" \
    -Tfields -e tls.handshake.extensions_key_share.group \
    -e tls.handshake.extensions_key_share.key_exchange_length

ML-DSA-65 서명 생성과 검증

# 1. ML-DSA-65 개인키 생성 (FIPS 204의 권장 중급 파라미터)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# 2. 공개키 추출과 키 속성 확인
openssl pkey -in mldsa65.key -pubout -out mldsa65.pub
openssl pkey -in mldsa65.key -text -noout | head -5

# 3. 문서 서명과 검증
echo "package release 2026.04" > manifest.txt
openssl pkeyutl -sign -inkey mldsa65.key \
    -rawin -in manifest.txt -out manifest.sig
openssl pkeyutl -verify -pubin -inkey mldsa65.pub \
    -rawin -in manifest.txt -sigfile manifest.sig

# 4. 서명 크기 실측 — ML-DSA-65 서명은 3,309바이트(FIPS 204 고정값)로 ECDSA-P256(~70바이트)보다 크게 뛰어오릅니다.
wc -c manifest.sig

OpenSSH ML-KEM 키 교환

OpenSSH 9.9(2024-09)가 mlkem768x25519-sha256를 실험적으로 도입했고, 10.0(2025-04)부터 기본 제안 알고리즘 1순위로 승격했습니다(9.9까지는 sntrup761x25519-sha512가 기본이었습니다). Ubuntu 26.04는 OpenSSH 10.2p1을 탑재하므로 별도 설정 없이 기본 제안에 포함됩니다. 서버와 클라이언트가 같은 KEM을 선호하도록 맞춰야 협상이 성공합니다.

# 서버가 실제로 제안하는 KEX 알고리즘
ssh -Q kex | grep -E "mlkem|sntrup"

# 클라이언트에서 명시적으로 ML-KEM 하이브리드 키 교환 강제
ssh -o KexAlgorithms=mlkem768x25519-sha256 \
    -o HostKeyAlgorithms=ssh-ed25519 \
    -vv user@host 2>&1 | grep "kex:"

# /etc/ssh/sshd_config에 시스템 전역 정책 고정
printf "KexAlgorithms mlkem768x25519-sha256,curve25519-sha256\n" \
    | sudo tee /etc/ssh/sshd_config.d/50-pqc.conf

배포판 crypto-policies 관점

# RHEL 10 / Fedora: 시스템 전역 암호 정책 상태
update-crypto-policies --show
update-crypto-policies --is-applied

# 기본에서 SHA-1과 레거시 알고리즘을 제외하고 PQC 선호로 고정하는 예
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# 정책이 다루는 구성 요소 목록 (OpenSSL, GnuTLS, NSS, OpenSSH, Libreswan 등)
ls /etc/crypto-policies/back-ends/

자주 나오는 오해

• "AES도 곧바로 깨집니다." 공개키 계열과 대칭키 계열의 영향이 다릅니다. 우선순위를 섞으면 전환 계획이 무너집니다.
• "QRNG가 있으면 끝입니다." 좋은 난수는 필요하지만, 공개키 교환과 서명 체계 전환을 대신하지는 못합니다.
• "rand()만으로 충분합니다." PQC의 KEM 캡슐화 난수와 서명 논스(Nonce)는 예측 불가능한 암호학적 RBG가 필수입니다. 시드만 알면 재생되는 비암호학적 생성기는 즉시 공격 대상이 됩니다.
• "TPM이 있으니 이미 안전합니다." TPM은 측정과 봉인에는 계속 유용하지만, 증명 인증서와 검증기 체인은 별도 전환이 필요합니다.
• "WireGuard PSK를 켰으니 모두 해결됐습니다." PSK는 헤지 수단일 뿐이며, 조직 전체의 공개키 신뢰 체계를 포스트 양자 상태로 바꾸는 작업은 별개입니다.
• "이중 서명에서 하나만 통과해도 충분합니다." 호환성 확보에는 도움이 되지만, 그 정책만으로는 포스트 양자 보증이 생기지 않습니다.
• "kTLS를 PQC로 다시 써야 합니다." 실제 전환 지점은 주로 TLS 핸드셰이크와 인증서 정책입니다. 레코드 계층의 대칭 처리 자체가 문제의 핵심은 아닙니다.
• "커널이 PQC를 지원하지 않으니 기다려도 됩니다." 7.0부터 ML-DSA X.509 검증이 병합되어 모듈 서명 검증 경로가 열렸습니다. 다만 커널은 검증 전용이라 서명 생성 툴체인과 배포 정책은 사용자 공간에서 별도로 준비해야 합니다.

관련 문서

• 암호화 알고리즘 내부 구조 — Shor 알고리즘, Grover 알고리즘, ML-KEM, ML-DSA의 배경을 정리합니다.
• OpenSSL — 하이브리드 TLS 키 교환과 EVP KEM API를 실습 중심으로 봅니다.
• WireGuard — Curve25519 기반 VPN 설계와 PSK 헤지의 한계를 봅니다.
• IPSec & xfrm — ESP 데이터 평면과 IKE 제어 평면의 경계를 봅니다.
• Secure Boot — 부팅 체인 검증과 모듈 서명 정책을 함께 점검합니다.
• TPM 2.0 — 측정 부팅, 봉인, 원격 증명과 포스트 양자 전환 경계를 봅니다.
• 공급망 보안(Supply Chain Security) — 커밋, 태그, 릴리스, 모듈 서명 파이프라인을 운영 관점에서 확장합니다.
• 하드웨어 난수 생성기 — QRNG와 hwrng를 과대평가하지 않으면서 정확한 역할을 정리합니다.

참고자료

• FIPS 203 — ML-KEM — 2024년 8월 13일 공개된 NIST 포스트 양자 키 캡슐화(Encapsulation) 표준입니다.
• FIPS 204 — ML-DSA — 2024년 8월 13일 공개된 NIST 포스트 양자 서명 표준입니다.
• FIPS 205 — SLH-DSA — 해시 기반 서명 표준입니다.
• NIST Post-Quantum Cryptography Project — 표준화 현황과 보조 자료를 제공합니다.
• NSA CSI: Quantum-Readiness — 조직 전환 우선순위와 운영 관점을 설명합니다.
• NSA Post-Quantum Cybersecurity Resources — CNSS Policy 15를 포함한 관련 자료 모음입니다.
• IETF TLS ECDHE-MLKEM — TLS 1.3 하이브리드 키 교환 표준화 문서입니다.
• OpenSSL 3.5 Documentation — ML-KEM, ML-DSA 관련 API와 TLS 설정 문서를 확인할 수 있습니다.
• OpenSSL 3.5.0 Final Release Announcement — 2025년 4월 8일 공개된 LTS 릴리스 공지로, 지원 기간과 PQC 기본값을 명시합니다.
• Linux To Gain ML-DSA/Dilithium Post-Quantum Cryptography For Module Signing — Phoronix — 커널 모듈 서명 PQC 전환 논의의 요약입니다.
• DebConf25: Rethinking Cryptography in the Linux Kernel — 장기 아카이브와 dm-crypt, fscrypt의 PQC 재설계 관점을 다룹니다.
• Post-quantum cryptography in Red Hat Enterprise Linux 10 — crypto-policies 통합과 PKCS#12 FIPS 기본 전환의 운영 관점을 정리합니다.
• Ubuntu 26.04 Post-Quantum SSH Hardening — OpenSSH ML-KEM 기반 키 교환의 적용 방법을 설명합니다.
• IETF TLS Hybrid Design — 하이브리드 키 교환의 결합 방식(concat)과 도메인 분리, 다운그레이드 방지 원리를 설명합니다.
• OpenSSH Release Notes — 9.9의 mlkem768x25519-sha256 실험 도입과 10.0의 기본 승격 이력을 확인할 수 있습니다.
• CNSA 2.0 and New Security Requirements (NSA, 2026-03) — CNSSP-15 갱신 이력(2016 CNSA 1.0, 2025 CNSA 2.0)과 2027/2030/2031/2035 공식 타임라인을 제시합니다.
• getrandom(2) man page — 커널 CRNG, vDSO getrandom, 엔트로피 동작을 설명합니다.
• KyberSlash — 2024년 공개된 ML-KEM 계열 구현의 타이밍 부채널(Side Channel) 사례로, 구현 난수 처리 실수가 보안을 무너뜨리는 실제 예입니다.