포스트 양자 보안 전환 (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월 4일 CNSS Policy 15를 통해 국가 안보 시스템의 포스트 양자 전환 방향을 명확히 제시했습니다.

왜 이 문제가 생기는가

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

위협 모델

양자 시대 위협은 단순히 "언젠가 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)을 분리해서 보는 것입니다.

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

부팅 체인과 공급망

양자 전환에서 가장 까다로운 부분은 검증기 전체가 함께 움직여야 하는 영역입니다. 네트워크 핸드셰이크는 비교적 하이브리드가 쉽지만, 부팅 체인과 공급망은 펌웨어, 부트로더, 운영체제 도구, 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과 서명 알고리즘은 곧바로 가속하지 못할 수 있습니다.

전환 체크리스트

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

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주차:
   운영 문서에 "고전 전용", "하이브리드 시험 중", "장기 전환 필요" 상태를 표시하고 다음 분기 계획을 세웁니다.

2025-2026 커널·배포판 동향

2024년 8월 NIST가 FIPS 203/204/205 최종본을 공개한 뒤 1년 반 동안 리눅스 생태계는 사용자 공간(User Space)부터 빠르게 포스트 양자(Post-Quantum) 알고리즘을 받아들이기 시작했습니다. 반면 커널 본체의 crypto/와 lib/crypto/ 경로에는 아직 ML-KEM, ML-DSA 구현이 업스트림되지 않았으며, 2025-2026년은 "상층부는 이미 움직이고, 커널은 이어서 따라가는" 전환기로 볼 수 있습니다.

CNSA 2.0 규제 달력

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

커널 내부 PQC 현황 점검

2026-04 현재 커널 업스트림에 병합된 PQC 구현은 없으며, 대부분의 실제 PQC 경로는 사용자 공간 라이브러리(OpenSSL 3.5, liboqs, SymCrypt, NSS 3.112)를 거칩니다. 커널이 관여하는 지점은 다음과 같은 경계에 집중됩니다.

• kTLS 오프로드 — TLS 1.3 핸드셰이크는 사용자 공간에서 끝나고 레코드 계층만 커널로 내려오므로, 하이브리드 KEM 전환의 영향은 kTLS가 아닌 handshake upcall에 나타납니다.
• 모듈 서명 — CONFIG_MODULE_SIG_KEY와 CONFIG_MODULE_SIG_FORMAT에 ML-DSA 체계를 추가하려는 패치 시리즈가 LKML에서 논의 중이며, 6.19 전후로 첫 병합이 예상됩니다.
• IMA/EVM — 해시 알고리즘 자체보다는 서명 체계(X.509 기반)가 문제이며, 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 관련 심볼 빠른 확인 (6.15 기준에서는 대부분 미정의)
grep -RE "ML_KEM|ML_DSA|SLH_DSA|CRYPTO_PQC" include/ crypto/ lib/crypto/ 2>/dev/null || \
    echo "업스트림 커널(6.15)에는 아직 PQC 심볼이 없습니다."

# 모듈 서명 키 알고리즘 현재 설정 확인
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,293바이트로 ECDSA-P256(~70바이트)보다 크게 뛰어오릅니다.
wc -c manifest.sig

OpenSSH ML-KEM 키 교환

OpenSSH 9.9 이후로 mlkem768x25519-sha256가 실험 플래그로 들어갔고, Ubuntu 26.04와 일부 배포판 패치에서는 기본 제안으로 승격됩니다. 서버와 클라이언트가 같은 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가 있으면 끝입니다." 좋은 난수는 필요하지만, 공개키 교환과 서명 체계 전환을 대신하지는 못합니다.
• "TPM이 있으니 이미 안전합니다." TPM은 측정과 봉인에는 계속 유용하지만, 증명 인증서와 검증기 체인은 별도 전환이 필요합니다.
• "WireGuard PSK를 켰으니 모두 해결됐습니다." PSK는 헤지 수단일 뿐이며, 조직 전체의 공개키 신뢰 체계를 포스트 양자 상태로 바꾸는 작업은 별개입니다.
• "이중 서명에서 하나만 통과해도 충분합니다." 호환성 확보에는 도움이 되지만, 그 정책만으로는 포스트 양자 보증이 생기지 않습니다.
• "kTLS를 PQC로 다시 써야 합니다." 실제 전환 지점은 주로 TLS 핸드셰이크와 인증서 정책입니다. 레코드 계층의 대칭 처리 자체가 문제의 핵심은 아닙니다.

관련 문서

• 암호화 알고리즘 내부 구조 — 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 기반 키 교환의 적용 방법을 설명합니다.
• CNSA 2.0 Compliance Requirements — 알고리즘 목록, 파라미터 강도, 시점별 전환 요구 사항을 정리합니다.