데이터의 기밀성(암호화)과 무결성(인증)을 동시에 보장하는 인증 암호화(AEAD, Authenticated Encryption with Associated Data) 방식인 GCM(Galois/Counter Mode)은 블록암호(AES, ARIA 등) 운용 모드의 표준이다. NIST SP 800-38D를 통해 표준화되어 있으며 국내 암호모듈(KCMVP) 제도상에서도 검증대상 운영모드로 채택되어 있다. 이러한 GCM이 안전하게 동작하기 위해서는 nonce(IV)의 유일성과 같이 반드시 지켜져야 하는 운용 조건이 존재한다.

본 칼럼은 최근 발생한 wolfSSL 라이브러리의 CVE-2026-5446 취약점 사례를 통해 nonce 재사용이 실제 시스템에서 어떤 문제로 이어지는지를 살펴본다. 나아가 이를 예방하기 위한 KCMVP 제도와 KCMVP 암호모듈 인터페이스 개선 방향을 함께 제안한다.

1. 암호화와 무결성을 동시에: GCM 모드의 핵심 동작 원리 

GCM의 내부 구조는 크게 두 가지 연산으로 이루어진다.

(1)  CTR(Counter) 모드 기반의 평문 암호화 (기밀성 보장)

첫 번째는 CTR(Counter) 모드를 통한 암호화다. 내부적으로 카운터를 1씩 증가시키면서 블록암호 연산을 수행하고, 그 결과값(키스트림)을 평문과 XOR하여 암호문을 생성한다.

(2)  GHASH 함수 기반의 인증 태그 생성 (무결성 검증)

두 번째는 GHASH 함수를 이용한 인증 태그 생성이다. 암호문과 추가 인증 데이터(AAD)를 GHASH 함수로 처리하고, 여기에 블록 암호 연산 결과를 결합하여 최종 인증 태그를 만든다.

이처럼 암호화와 인증이 단일 패스로 동시에 이루어지는 이중 연산 구조 덕분에 GCM은 수신측이 암호문을 복호화하는 과정에서 데이터가 전송 과정에서 변조되지 않았음을 인증 태그를 통해 동시에 검증할 수 있다.

[그림 1] GCM 모드 동작 구조: CTR 암호화 + GHASH 인증 태그 생성

GCM 연산에서 nonce는 초기 카운터 블록인 J₀를 생성하는 데 사용된다. J₀는 이후 CTR 모드의 키스트림 생성과 인증 태그 계산 모두의 출발점이 되는 값이다.

J₀가 결정되면, 이후 각 암호화 블록은 J₀에서 카운터를 1씩 증가시킨 값으로 키스트림을 생성한다. 즉, 동일한 nonce를 사용하면 J₀가 동일해지고, 결과적으로 동일한 키스트림이 생성된다.

키스트림 KS = E(K, J₀)

동일한 키 K와 nonce로 두 평문 P₁, P₂를 각각 암호화하는 상황을 살펴보자. J₀가 동일하므로 두 암호화에서 생성되는 키스트림은 완전히 일치한다.

암호문 C₁ = P₁ ⊕ KS

암호문 C₂ = P₂ ⊕ KS

공격자가 두 암호문을 XOR하면 키스트림이 소거되어 평문의 XOR 값이 그대로 드러난다. 이를 'Two-Time Pad' 취약점이라고 한다. 공격자는 언어적 패턴, 통계적 분석 등을 활용하여 평문의 상당 부분을 추론할 수 있다.

C₁ ⊕ C₂ = (P₁ ⊕ KS) ⊕ (P₂ ⊕ KS) = P₁ ⊕ P₂

nonce 재사용의 다른 취약점은 무결성 파괴다. GHASH 서브키 H = E(K, 0¹²⁸)는 주어진 키에 대해 항상 고정된 값이다. nonce가 재사용되면 인증 태그 생성 수식을 연립방정식으로 세울 수 있고, 이를 통해 H를 복원하는 것이 가능해진다.

GHASH 키가 노출되면 공격자는 임의의 메시지에 대해 유효한 인증 태그를 계산할 수 있다. 이는 AEAD가 제공하는 무결성 및 인증 보장이 더 이상 성립하지 않음을 의미한다.

NIST SP 800-38D는 이 점을 다음과 같이 명확히 규정하고 있다.

NIST SP 800-38D, Section 8

"Across all instances of the authenticated encryption function with a given key, if even one IV is ever repeated, then the implementation may be vulnerable to the forgery attacks."

동일한 키로 수행되는 모든 암호화 인스턴스에서 IV가 단 한 번이라도 반복되면, 해당 구현은 위변조 공격에 취약해질 수 있다.

RFC 5116은 이 문제를 다음과 같이 명시하고 있다.

RFC 5116, Section 5.1.1

"The inadvertent reuse of the same nonce by two invocations of the GCM encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key."

동일한 키로 서로 다른 평문을 암호화할 때 nonce를 재사용하면, 해당 두 암호화의 기밀성이 훼손되고, 그 키가 제공하는 모든 인증 및 무결성 보호가 손상된다.

2. CVE-2026-5446 분석: wolfSSL 연동 시 발생한 Nonce 재사용의 맹점

wolfSSL은 임베디드 환경에 최적화된 경량 TLS 라이브러리로 외부 암호모듈이나 하드웨어 암호엔진을 연동할 수 있는 구조를 제공한다. wolfSSL은 KCMVP 인증 암호모듈을 연동하여 ARIA 알고리즘 기반 암호화 서비스를 지원하도록 구현하였다. 이는 국내 보안 인증 요건을 충족해야 하는 고객사 환경에서 wolfSSL을 활용하기 위한 구성이었다.

이 과정에서 wolfSSL은 ARIA-GCM 암호화 기능을 내부적으로 호출하는 래퍼(wrapper) 레이어를 구현하였다. 그런데 이 래퍼 구현에서 nonce 관리 원칙이 지켜지지 않았다. 구체적으로, 세션 초기화 시 설정된 IV(nonce)가 이후 갱신되지 않고 반복 사용되는 구조였다.

[그림 2] CVE-2026-5446 발생 경로: wolfSSL의 KCMVP 연동 구조와 nonce 재사용 취약 지점

CVE-2026-5446은 이 가이드를 따르지 않은 wolfSSL 측 구현에서 비롯된 취약점이다.

wolfSSL은 CVE-2026-5446에 대한 자체 분석을 통해 해당 취약점이 wolfSSL의 ARIA-GCM 연동 구현에서 비롯되었음을 확인하고 wolfSSL 코드만을 대상으로 수정 조치를 완료하였다.

✔ 조치 완료

wolfSSL은 CVE-2026-5446에 대한 수정을 자체적으로 완료하였다. (GitHub PR #10111: Fix ARIA build issue and FIPS guard)

해당 버전 이하의 wolfSSL 기반 제품을 운용 중인 경우 패치 적용이 권고된다.

CVE-2026-5446은 wolfSSL과 동일한 패턴의 오용은 다른 곳에서도 발생할 수 있다. KCMVP의 GCM 암호화를 사용하는 모든 제품과 솔루션에서 nonce가 올바르게 관리되고 있는지 점검이 필요하다.

3. CMVP vs KCMVP: Nonce 관리 정책의 차이

이번 취약점 사례는 단순히 구현 오류를 넘어 국내외 암호 모듈 검증 제도(CMVP 및 KCMVP) 수준에서 nonce 관리를 어떻게 규제하고 있는지에 대한 근본적인 질문을 제기한다.

CMVP: API 설계 수준의 차단

FIPS 140-3 기반의 CMVP(Cryptographic Module Validation Program)는 GCM 모드 사용 시 nonce를 암호모듈 내부에서 생성하도록 인터페이스를 구성하는 것을 원칙으로 한다.

NIST SP 800-38D와 FIPS 140-3 Implementation Guidance(IG)는 내부 DRBG를 통한 난수 생성, 또는 단조 증가 카운터(monotonic counter) 방식을 활용하여, 모듈이 nonce의 유일성을 스스로 보장하도록 요구한다. 즉, 구현자가 nonce를 잘못 다룰 여지를 인터페이스 수준에서 줄이는 방향이다.

KCMVP: 구현 유연성

반면 KCMVP에서는 현재 nonce를 외부에서 입력 받는 방식을 허용하고 있다. 이는 구현 유연성을 제공하는 측면이 있으나, 동시에 nonce 관리의 책임을 전적으로 구현자에게 위임하는 구조다. CVE-2026-5446과 같이 가이드를 따르지 않는 구현이 실제로 발생한다는 점에서 제도적 보완의 필요성이 제기된다.

📌 NIST SP 800-38D의 모듈 내부 생성 권고

"The IVs shall be generated by an approved method... In cases where the IV is generated externally, the generating entity shall ensure uniqueness." (NIST SP 800-38D, Section 8.2) — IV를 외부에서 생성하는 경우, 생성 주체가 유일성을 직접 보장해야 한다.

CVE-2026-5446 사례는 검증 제도의 관점에서도 시사점을 남긴다. 현행 KCMVP 체계는 KAT(Known Answer Test), MCT(Monte Carlo Test) 등을 통해 알고리즘 구현의 수학적 정확성을 검증한다. 그러나 취약점은 알고리즘 내부가 아니라 그것을 둘러싼 사용 방식에서 발생하는 경우가 적지 않다.

CMVP가 nonce를 모듈 내부에서 생성하도록 인터페이스 수준에서 구조화하고 있는 것처럼, KCMVP 제도에서도 운용상의 오용을 방지하기 위한 정책 확대가 필요하다.

• nonce 관리 정책 제출 의무화: nonce 생성 방식, 유일성 보장 메커니즘을 검증 서류 항목으로 지정
• 내부 생성 옵션 권고: DRBG 또는 단조 증가 카운터를 통한 모듈 내부 nonce 생성 인터페이스를 권고 기준으로 명시
• 오용 시나리오 검증 항목 신설: nonce 재사용, 컨텍스트 재초기화 누락 등 대표적 오용 패턴에 대한 실패 거동(fail-safe) 확인
• 외부 연동 구현 가이드라인 강화: wolfSSL 사례처럼 제3자가 KCMVP 모듈을 연동할 경우 적용해야 할 최소 보안 요건 명시

4. 오용의 차단: KCMVP 암호모듈 인터페이스 개선

DRBG 기반 nonce 자동 생성 옵션 도입

이번 사례를 계기로 nonce 오용을 구조적으로 방지하기 위한 KCMVP 암호모듈의 인터페이스 개선이 필요하다. 핵심 방향은 KCMVP 인증을 받은 DRBG를 활용하여 nonce를 모듈 내부에서 자동 생성하는 옵션을 추가하는 것이다.

옵션에 따라 외부 생성 nonce를 입력할 수 있고, nonce가 내부 DRBG를 통해 자동으로 생성되는 두가지 방식을 모두 지원한다. 내부에서 생성된 nonce는 출력 파라미터를 통해 반환된다. wolfSSL 사례처럼 외부 개발자가 이 인터페이스를 사용하면 가이드 숙지 여부와 무관하게 nonce 재사용 문제가 구조적으로 차단된다.

✔ KCMVP 인터페이스 개선 방향

1) DRBG 기반 nonce 자동 생성 옵션 추가 (내부 CSPRNG 활용)

2) 기존 외부 입력 인터페이스는 유지하되, 사용 가이드에 nonce 관리 정책 강화

GCM nonce 재사용 문제는 운용모드의 결함이 아닌 안전한 사용을 위한 운용 조건을 따르지 않은 구현 수준의 문제다. CVE-2026-5446은 이 사실을 실제 취약점으로 확인해 준 사례이며, wolfSSL의 자체 수정으로 해당 취약점은 조치되었다.

그러나 이번 사례가 남긴 질문은 계속된다. 제품과 솔루션에서는 동일한 패턴의 오용이 없는지 점검이 필요하다. 나아가 KCMVP 모듈은 nonce 자동 생성 인터페이스를 추가하여, 구현자가 가이드를 몰라도 올바른 방식으로 사용할 수 있는 구조를 만들어야 한다. 제도 측면에서도 CMVP가 이미 채택하고 있는 모듈 내부 nonce 생성 원칙을 KCMVP에도 적용하여 올바른 사용을 보장하는 것이 운용 보안성 측면에서 바람직한 방향이라 제언한다.