GMAC은 Galois Message Authentication Code의 약자로 주로 GCM(Galois/Counter Mode)이라는 블록암호 운영모드에서 사용하는 인증 코드 생성 방식입니다.

GMAC는 데이터의 무결성과 진위확인을 위해 사용됩니다.

GCM에서 암호화는 하지 않고 인증만 수행하는 경우를 GMAC이라고 부릅니다.

GMAC 동작과정

GMAC은 기본적으로 블록암호 알고리즘과 Galois 필드(GF(2^128))에서의 수학 연산을 기반으로 합니다. 아래는 GMAC 동작과정을 간단하게 설명한 것입니다.

입력값

1. 비밀키(K) : 블록암호 알고리즘에 사용하는 키
2. 초기화 벡터(IV) : Nonce, 길이는 일반적으로 96비트
3. 인증할 메시지(A) : 암호화하지 않고 인증만 수행할 데이터

동작절차

• 해시 서브키(H) 생성
  • 블록암호 알고리즘으로 128비트의 0 블록을 암호화하여 해시키 H = K(0128)를 생성
  • 이 키는Galois 필드 연산에 사용됩니다.
• GHASH 함수 준비
  • GMAC의 핵심은 GHASH라는 함수이니다.
  • GHASH는 해시 키 H와 입력 메시지 A를 Galois 필드에서 곱셈 및 덧셈하여 해시값을 만듭니다.
  • 메시지 A는 128bit 블록으로 패딩되어 처리됩니다.
• Y0 생성(IV 처리)
  • 96bit IV의 경우 Y_0 = IV || 0x00000001
  • 그 외의 경우 GHASH를 사용하여  Y_0 계산
• 태그 생성
  • GHASH 결과 S를 얻은 후 Tag = K(Y_0) ⊕ S 계산
  • 이 최종 결과가 GMAC 태그입니다. 이 값은 메시지의 무결성을 보장합니다.

function GMAC(Key, IV, AAD):
    # 1. 해시 서브키 H 계산
    H := AES_Encrypt(Key, 0^128)

    # 2. IV 처리 → 초기 counter 블록 Y₀ 계산
    if length(IV) == 96 bits:
        Y0 := IV || 0x00000001
    else:
        Y0 := GHASH(H, [], IV)  # IV를 GHASH로 처리하여 Y0 생성

    # 3. AAD에 대한 해시 계산
    S := GHASH(H, AAD)

    # 4. 최종 태그 계산
    Tag := AES_Encrypt(Key, Y0) ⊕ S

    return Tag

보조함수 GHASH

function GHASH(H, AAD):
    X := 0^128  # 초기값

    # AAD를 128비트 블록으로 나눔 (패딩 포함)
    AAD_blocks := split_and_pad(AAD, 128)

    for block in AAD_blocks:
        X := (X ⊕ block) × H  # 곱셈은 GF(2^128) 상에서 수행

    return X

GCM과 GMAC의 입력 구성

1. 해시함수란?

해시함수는 임의의 길이를 가진 입력 데이터를 고저오딘 길이의 해시값으로 변환하는 함수입니다.

입력: "Hello World"
해시 값: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

출력 크기는 해시함수 알고리즘에 따라 설정됨

2. 해시함수의 특징

• 일방향성(One Way Function)
  • 입력 -> 해시값은 쉽게 계산 가능
  • 해시값 -> 입력으로 되돌리는 것은 어려움
• 충돌저항성(Collision Resistance)
  • 서로 다른 입력이 동일한 해시값을 가질 확률이 극도로 낮음
  • 하지만 이론적으로 가능
• 변경 민감성(Avalanche Effect)
  • 입력데이터가 1bit만 변경되어도 출력 해시값은 완전히 달라짐
• 빠른 연산 속도
  • 해시 계산은 매우 빠르게 이루어짐
• 2차 선이미지 회피성
  • 주어진 입력  M1에 대해 같은 해시값을 가지는 다은 입력 M2를 찾는 것은 매우 어려움

3. 해시함수의 주요 용도

• 비밀번호 저장
  • 비밀번호를 해시해서 저장 -> 원래 비밀번호는 서버에 없음
  • 해시값만 저장 -> 탈취되어도 원래 비밀번호는 알수 없음
• 데이터 무결성 검증
  • 파일이나 메시지가 변경되었는지 확인
  • 해시값으로 비교 -> 다르면 변조된 것
• 디지털 서명
  • 메시지의 해시값을 서명하여 인증
  • 전체 메시지를 서명하는 것보다 빠르고 효율적
• 블록체인
  • 블록의 연결, 작업 증명(Proof of Work)에 해시 사용

4. 주요 해시함수 종류

5. 해시 함수 관련 주의사항

• 절대로 비밀번호를 해시없이 저장하지 말것
• Salt를 추가하여 Rainbow Table Attack을 방어해야 함
• 해시는 암호화가 아니라 지문 생성이라고 생각해야 함. 복호화가 불가능

* Rainbow Table Attack이란?

미리 계산된 해시값 목록을 활용하여 빠르게 원래 입력을 찾아내는 공격 방법 입니다.

해시함수 자체를 깨는 것이 아니라 해시값 -> 원래 입력을 빠르게 찾으려고 하는 사전 공격의 일종입니다.

레이보우 테이블 공격의 원리

1. 공격자는 비밀번호 후보 리스트를 준비
   (ex. 123456, password, qerty, abc123..)
2. 각 후보를 해시함수에 넣어 해시값을 미리 계산
3. 해시값을 테이블에 저장. 이것을 레인보우 테이블이라고 함
4. 추후 유출된 해시값이 있을 때 레인보우 테이블에 해당 해시값이 저장되어 있는지 검색하고, 해시값이 존재할 경우 입력 메시지를 알아낼 수 있음

레인보우 테이블의 장점

• 한번 만들어놓으면 여러 공격에 재사용이 가능함
• 계산을 미리 해놨으므로 매우 빠르게 공격이 가능함

레인보우 테이블 공격의 방어 방법

• Salt를 사용
  • 비밀번호에 고유의 Salt(랜덤 데이터)를 추가하여 해시를 수행
  • 같은 비밀번호라도 다른 해시값이 생성되므로 레인보우테이블 공격을 무력화할 수 있음

비밀번호: 'password'
Salt: 'X8t!2'
해시값: H('passwordX8t!2')

• 비밀번호 복잡도 강화
  
  • 복잡하고 긴 비밀번호를 사용하여 레인보우 테이블을 만들기 어렵도록 함

1. ECB (Electronic Codebook) 모드

• 방식: 각 블록을 독립적으로 암호화.
• 특징:
  • 동일한 평문 블록 → 동일한 암호문 블록.
  • 병렬 처리 가능.
• 단점: 패턴이 반복되면 암호문에도 반복 패턴이 생겨 보안상 위험.
• 용도: 거의 사용하지 않음 (보안 취약).

도식:

C_i = E(K, P_i)

 2. CBC (Cipher Block Chaining) 모드

• 방식: 이전 암호문 블록과 현재 평문 블록을 XOR 후 암호화.
• 특징:
  • 초기화 벡터(IV)가 필요.
  • 동일한 평문 블록이라도 암호문은 달라짐.
  • 병렬 복호화 가능, 암호화는 직렬 처리.
• 단점:
  • 하나의 블록 오류 → 현재 블록과 다음 블록 오류 전파.

도식:

C_i = E(K, P_i ⊕ C_{i-1}),  C_0 = IV

3. CFB (Cipher Feedback) 모드

• 방식: 이전 암호문 블록을 암호화한 후, 평문과 XOR.
• 특징:
  • 스트림 암호처럼 동작 가능.
  • 부분 블록 처리 가능.
  • 복호화 시 병렬 처리 어려움.
• 단점:
  • CBC처럼 오류 전파 발생.

도식:

C_i = P_i ⊕ E(K, C_{i-1}),  C_0 = IV

🔑 4. OFB (Output Feedback) 모드

• 방식: 암호화기 출력만을 피드백하여 XOR.
• 특징:
  • 오류 전파 없음 (한 비트 오류 → 해당 비트만 손상).
  • 미리 키 스트림 생성 가능.
  • IV 필수.
• 단점:
  • IV 재사용 시 보안 치명적.

도식:

O_i = E(K, O_{i-1}),  C_i = P_i ⊕ O_i,  O_0 = IV

5. CTR (Counter) 모드

• 방식: 증가하는 카운터 값을 암호화 후, 평문과 XOR.
• 특징:
  • 완전 병렬 처리 가능 (암호화/복호화 모두).
  • 미리 키 스트림 생성 가능.
  • IV 또는 nonce 필요.
• 단점:
  • 카운터 값 충돌 → 보안 붕괴.

도식:

C_i = P_i ⊕ E(K, Nonce || Counter_i)

비교 요약

모드병렬 암호화병렬 복호화오류 전파패턴 감춤

오류전파 : 암호문에서 한비트가 손상되었을 대 복호화된 평문에서 얼마나 많은 부분이 잘못되느냐를 의미
패턴감춤 : 평문에 반복되는 패턴(ex. 'AAAA', 'BBBB')이 암호문에서 그대로 드러나는지를 의미

선택 포인트

• 안전성 중요 → ECB는 피하기.
• 병렬 성능 필요 → CTR 모드.
• 스트림 암호화 필요 → OFB, CFB.
• 파일 암호화 → CBC, CTR.

KCMVP의 목적 및 개요

KCMVP(Korea Cryptographic Module Validation Program, 한국형 암호모듈 검증 프로그램)는 국가 정보통신망에서 사용되는 암호모듈의 안전성과 구현 적합성을 검증하는 제도입니다 ([KISA 암호이용활성화

• 암호모듈검증 - 개요

KCMVP(Korea Cryptographic Module Validation Program, 한국형 암호모듈 검증 프로그램)는 국가 정보통신망에서 사용되는 암호모듈의 안전성과 구현 적합성을 검증하는 제도입니다​. 행정기관 등 국가·공공기관에서 소통되거나 저장되는 중요 정보를 보호하기 위해, 해당 정보의 암호화에 사용되는 소프트웨어/하드웨어 암호모듈의 보안성을 국가가 인증해주는 것입니다​. 2009년 제도가 시행된 이후 정부·공공 부문의 각종 보안 제품에 활용될 암호모듈들을 검증해왔으며, 미국의 CMVP(FIPS 140 표준) 제도를 참고하여 구축되었습니다​. 이를 통해 국가적으로 신뢰할 수 있는 암호 기반환경을 조성하고 보안성을 확보하는 것이 KCMVP의 주요 목적입니다.

기술적 요구사항 (암호모듈 구성요소 및 알고리즘 요건)

암호모듈이란 정보 보호를 위해 암호연산을 수행하는 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로 이루어진 구성요소를 말합니다. KCMVP에서는 이러한 다양한 형태의 암호모듈을 검증 대상으로 삼으며, 모듈의 형태에 관계없이 공통된 보안 요구사항을 적용합니다. 암호모듈은 보안성에 따라 1부터 4까지의 보안수준을 부여받는데, 1등급이 가장 기본적인 보안 요구사항을 충족하는 수준이고 4등급이 가장 높은 단계입니다. 등급이 높아질수록 키 관리, 자기 진단(Self-tests), 물리적 변조 방지 등의 요구사항이 강화되며, 예를 들어 4등급은 엄격한 물리적 보안과 변조 시 즉각적인 키 소멸 등의 최고 수준 보안기능을 요구합니다.

암호모듈이 충족해야 할 기술적 요건은 국제 표준에 부합되도록 정의되어 있습니다. 국가표준 KS X ISO/IEC 19790:2015 (암호모듈 보안 요구사항) 및 KS X ISO/IEC 24759:2015 (암호모듈 시험 요구사항)을 KCMVP의 평가 기준으로 채택하여, 모듈의 설계부터 운영까지 다양한 보안 요구사항을 검사합니다. 또한 암호모듈에 구현된 암호 알고리즘의 적합성 검증도 중요한 기술 요건입니다. KCMVP에서는 모듈이 국가가 승인한 안전한 암호 알고리즘을 사용하고 있는지, 그리고 해당 알고리즘을 정확히 구현했는지를 검증합니다. 검증 대상이 되는 알고리즘 유형은 블록암호 및 운영모드, 해시 함수, 메시지 인증코드(MAC), 의사난수/난수 발생기, 공개키 암호, 전자서명, 키 합의/분배, 키 유도 등으로 광범위합니다. 예를 들어 국내 표준 알고리즘인 ARIA, SEED, LEA, HIGHT 블록암호, SHA-2/LSH 해시함수, HMAC/CMAC 메시지인증, RSA/ECC 기반 전자서명 및 키교환, 난수발생기(DRBG) 등이 이에 포함됩니다. 알고리즘 구현의 정확성은 KCAVS(Korea Cryptographic Algorithm Validation Suite)라는 테스트 도구를 통해 확인하는데, 입력값과 예상 출력값을 비교하는 KAVP(CAVP) 테스트 절차를 거쳐 알고리즘이 표준에 맞게 동작하는지 검증합니다. 이러한 기술적 요구사항을 모두 만족해야 KCMVP 인증을 통과할 수 있으며, 결과적으로 해당 암호모듈은 지정된 보안수준(1~4)으로 검증필(Validated) 인증을 받게 됩니다.

인증 대상과 적용 범위 (인증 대상 제품 및 활용)

KCMVP 인증은 국가 및 공공 분야에서 사용되는 IT제품의 암호모듈에 대해 사실상 의무적으로 요구되고 있습니다. 국가정보원은 일정한 유형의 보안제품을 정부·공공기관에 도입할 때 반드시 KCMVP 검증필 암호모듈을 사용할 것을 규정하고 있습니다.

예를 들면 다음과 같은 제품 분야에서는 KCMVP 인증을 받은 암호모듈의 탑재가 필수적입니다 

• DB(데이터베이스) 암호화 시스템 – 데이터베이스에 저장된 정보를 암호화/복호화하는 솔루션
• 통합인증 시스템 (SSO 등) – Single Sign-On 등 사용자 인증을 처리하는 솔루션
• 문서 암호화 제품 (DRM 등) – 디지털저작권관리(DRM) 등 문서/파일 암호화 솔루션
• 가상사설망 (VPN) – 네트워크 구간 암호화를 통한 VPN 장비 및 소프트웨어
• 소프트웨어 기반 보안 USB – USB 저장매체에 대한 암호화 보안 기능이 있는 제품
• 내부정보 유출방지(DLP) 시스템 – PC/서버 등의 중요 정보 유출을 차단하는 보안 제품
• 양자암호통신 장비 – 양자키분배(QKD) 장비, 양자키관리, 양자암호화 통신장비 등 차세대 암호기술 제품
• 기타 암호기능이 주요한 제품 – 이메일 암호화, 구간(링크) 암호화 장비, 디스크/파일 암호화 솔루션, 하드웨어 보안토큰 등

상기의 제품들은 모두 암호기능이 핵심이므로, 그 내부에 탑재된 암호모듈이 KCMVP 인증을 받아야 안전한 제품으로 간주됩니다. 만약 검증되지 않은 모듈을 사용한 제품은 국가·공공기관에 납품할 수 없거나, 기관 자체 지침에 따라 배제가 될 수 있습니다. 따라서 관련 업계에서는 정부용 제품을 개발할 때 반드시 먼저 암호모듈에 대한 KCMVP 인증을 획득하는 것이 필수적인 절차로 자리잡고 있습니다. 인증 받은 암호모듈은 국가정보원에서 "검증필 암호모듈 목록”으로 공개 관리되며, 각 기관은 도입 시 해당 목록을 참조해 인증의 유효성(만료 여부), 모듈의 해시값 무결성, 보안정책 문서 등을 확인하도록 권고됩니다.

관련 기관 및 역할

KCMVP 제도는 국가정보원(NIS)이 총괄하며, 여러 시험 기관들이 협력하는 구조로 운영됩니다. 여기서 국가정보원은 검증기관의 역할을 수행하는데, 암호모듈 보안기준의 제정과 인증 정책 수립, 최종 인증서 발급을 관장합니다. 국가정보원 산하에 암호모듈검증위원회를 두어 암호 전문가들이 모듈의 보안성을 심의·의결하고, 인증 여부를 최종 결정합니다. 한편 실제로 암호모듈의 시험 및 평가 업무를 담당하는 곳은 공인 시험기관들입니다. 주요 시험기관으로는 국가보안기술연구소(NSR)와 한국인터넷진흥원(KISA)이 있으며, 이외에도 일정 자격을 갖춘 민간 시험기관이 지정될 수 있습니다. 현재 KCMVP 시험기관으로는 국가보안기술연구소, KISA 외에 민간 기업인 KOSYAS 등이 지정되어 있습니다. 이들 시험기관(Testing Laboratory)은 암호모듈 개발업체로부터 시험 의뢰를 받아 모듈에 대한 평가를 수행하고, 그 결과를 국가정보원에 보고하는 역할을 맡습니다. 민간 기관이 시험기관으로 지정되려면 국내에 위치하고 일정 수 이상의 암호전문가를 보유하는 등 엄격한 요건을 충족해야 하며, 지정 후에도 정기적인 재인증 심사를 통해 자격을 유지합니다. 이처럼 국가정보원(검증기관)과 시험기관(전문 평가기관)이 협력하여 운영됨으로써, 평가의 공정성과 기술 전문성이 확보되고 있습니다.

인증 절차 (신청부터 인증서 발급까지)

KCMVP 인증 절차는 공식적으로 7단계로 설명되지만, 크게 요약하면 암호모듈 개발업체→시험기관 평가→국정원 검증의 순서로 진행됩니다. 아래에 단계별로 절차를 설명합니다:

1. 인증 신청: 암호모듈을 개발한 업체(신청기관)는 준비된 모듈과 관련 문서를 갖추어 국정원이 지정한 시험기관에 검증 신청을 합니다. 이 단계에서 모듈의 기능, 사용된 알고리즘, 보안설계에 대한 설명이 담긴 보안정책서, 설계명세 등 제출자료를 준비하여 시험기관에 제출합니다.
2. 시험 계약 및 평가 수행: 시험기관은 신청을 접수하면 업체와 시험평가 계약을 체결하고 본격적인 평가 업무를 수행합니다. 평가 과정에서는 우선 암호 알고리즘 구현 적합성 검증(KAVP 테스트)을 실시하여 모듈에 구현된 알고리즘들이 표준에 맞게 동작하는지 확인합니다. 또한 제출된 설계 문서와 모듈을 분석하여, 암호모듈 보안 요구사항(KS X ISO/IEC 19790 기준)에 따른 구현 여부를 점검합니다. 예를 들어, 초기 자기진단 기능, 키 관리 방식, 권한 분리가 적절히 구현되었는지, 물리적 장치의 경우 감응 탐지 장치나 봉인(seal) 같은 변조 방지 기구가 등급 요구에 부합하는지 등을 평가합니다. 이 모든 시험 과정은 국제 표준에 따라 정형화된 절차로 진행되며, 필요 시 개발사에 질의하거나 수정 기회를 제공하면서 보완 테스트가 수행되기도 합니다.

1. 시험 결과 보고: 시험기관의 평가가 완료되면, 그 시험 결과와 평가보고서가 국가정보원(검증기관)에 제출됩니다. 보고서에는 모듈의 보안설계 적합성 평가, 알고리즘 테스트 결과, 발견된 문제 및 조치 내역, 권고 등급 등이 포함됩니다. 시험기관은 이러한 상세한 결과를 정리하여 검증기관에 공식 보고함으로써, 최종 인증을 위한 심의를 요청하게 됩니다.
2. 검증 심의 및 결정: 국가정보원은 접수된 평가 결과를 가지고 암호모듈검증위원회 회의를 개최합니다. 위원회는 제출된 자료를 심의하여 암호모듈이 요구되는 보안 기준을 만족하는지, 적정한 보안등급을 부여할 수 있는지 등을 검토합니다. 필요하면 시험기관이나 개발업체에 추가 자료나 설명을 요구할 수도 있습니다. 심의 결과 인증 요건을 모두 충족했다고 의결되면 인증 승인으로 결정되며, 만약 기준을 충족하지 못한 부분이 발견되면 보완 또는 인증불가 결정이 내려집니다. 이 단계까지가 검증기관의 최종 판단 과정이며, 실질적인 인증 여부 및 등급이 확정됩니다.
3. 인증서 발급 및 목록 등재: 국가정보원은 위원회의 심의 결과에 따라 해당 암호모듈의 인증서(검증서)를 발급하고, 공식 검증필 암호모듈 목록에 등재합니다. 인증결과는 시험기관을 통해 신청업체에 통보되며, 인증된 모듈에는 고유한 검증번호와 인증서가 부여됩니다. 이후 누구나 열람할 수 있는 국가정보원 공개 목록에 모듈 명칭, 버전, 개발사, 부여등급, 유효기간 등의 정보가 등록되어 공개 검증 상태가 됩니다. 인증서에는 모듈이 준수한 보안등급과 알고리즘 목록, 적용 범위 등이 명시되며, 개발업체는 해당 모듈을 “KCMVP 검증필”이라고 홍보할 수 있게 됩니다. (※ 인증 후에도 모듈에 중대한 변경이 발생하면 재평가를 받아야 하며, 5년 주기로 인증효력 연장 여부를 검토합니다.)

以上의 절차를 거쳐 KCMVP 인증을 획득하게 되며, 전체 과정에는 통상 수개월에서 1년가량의 시간이 소요됩니다. 예비검토(사전컨설팅), 보완조치 시간 등을 포함하면 기간은 달라질 수 있고, 2023년부터는 신청 절차의 투명성과 신속성을 높이기 위해 온라인 신청 시스템 도입이 추진되고 있습니다.

국제 기준(FIPS 140-3 등)과의 연계성 및 차이점

KCMVP는 국제 암호모듈 보안 기준과 밀접하게 연계되어 있습니다. 앞서 언급한 KS X ISO/IEC 19790 표준은 미국 연방표준 FIPS 140-2/3에 대응하는 국제 표준으로, 미국, 캐나다, 일본 등도 이 표준을 자국 인증에 적용하고 있습니다. 실제로 KCMVP 제도는 미국 NIST의 CMVP(Cryptographic Module Validation Program)를 본떠 만들어졌으며, FIPS 140-2의 기준을 초창기부터 수용하여 운영되다가 현재는 FIPS 140-3(ISO 19790 2판) 기준까지 반영하고 있습니다. 따라서 평가 항목이나 보안등급 체계 면에서 KCMVP와 FIPS 140-3는 큰 틀에서 상호 대응됩니다. 예를 들어 FIPS 140-3의 Security Level 1~4 요구사항이 KCMVP에도 유사하게 적용되며, 자기진단, 키관리, 물리적 보안 등의 개념도 동일한 국제 기준에 근거합니다.

그럼에도 불구하고 KCMVP와 국제 인증 간에는 몇 가지 차이점이 존재합니다. 우선, 암호 알고리즘의 정책적 차이가 두드러집니다. KCMVP에서는 국산 알고리즘 중심의 암호체계를 채택하여 국가가 인정한 알고리즘을 위주로 인증을 실시해왔는데, 이러한 체계는 미국의 FIPS 140 인증이나 유럽의 CC(Common Criteria) 인증과 상호 호환되지 않는 측면이 있습니다. 예를 들어 한국의 KCMVP 모듈들은 ARIA, SEED, LSH 등의 국내 표준 알고리즘을 포함하는 경우가 많지만, 미국 FIPS 인증에서는 AES, SHA-2 등 NIST 표준 알고리즘 위주로 평가됩니다. 따라서 한쪽에서 인증받은 모듈이라도 다른 쪽 표준에 맞지 않는 알고리즘을 썼다면 그대로 상호인정되지 않으며 별도 인증을 받아야 합니다. 실제로 KCMVP 인증서는 국내 용도로만 효력을 가지며, 미국 정부 조달을 위해서는 별도로 FIPS 140 인증을 취득해야 하는 등 국제 상호인증 체계는 구축되어 있지 않습니다. 이와 관련해 “국내 KCMVP와 국산 알고리즘 중심 체계는 미국 FIPS-140이나 유럽 CC와 호환되지 않는다”는 업계 지적도 있어, 향후 국내 알고리즘의 국제 표준화 추진과 상호인정 논의가 과제로 남아 있습니다.

또 다른 차이로는 인증 활용과 현황의 차이가 있습니다. 미국의 CMVP는 1990년대 중반부터 시행되어 수천 건 이상의 모듈이 인증되었고, Level 3~4의 고등급 HSM(Device) 인증 사례도 다수인 반면, 국내 KCMVP는 2009년 이후 2023년까지 누적 250여 건의 인증에 그쳐 규모가 작으며 대부분 소프트웨어 모듈 위주의 1~2등급 인증이었습니다. 이는 국내에서 고가의 하드웨어 보안모듈(HSM)보다 소프트웨어 구현 위주로 인증을 받아왔음을 보여주며, 아직까지 최고 등급인 4등급 인증을 받은 사례는 없습니다. 다만 일본(JCMVP) 등 다른 국가 사례와 비교하면 한국의 인증 건수는 많은 편이고, 향후 양자내성암호 등의 등장으로 인증 수요와 국제 협력이 늘어날 것으로 전망됩니다.

요약하면 KCMVP는 국제표준 기반으로 운영되면서도 국내 환경에 특화된 암호모듈 인증제도라고 할 수 있습니다. 국제 기준과 동등한 기술 신뢰성을 확보함과 동시에, 국내에서 필요한 알고리즘과 정책을 반영하여 자국 보안주권을 유지하는 균형을 추구하고 있습니다. 향후에는 FIPS 140-3를 비롯한 국제동향에 발맞추어 기준을 계속 개정하되, 글로벌 상호인정이나 국산 알고리즘의 국제적 승인 등을 통해 KCMVP의 국제 호환성을 높이는 노력도 병행될 것으로 기대됩니다.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)은 NIST에서 2024년 8월 13일에 발표한 FIPS 203 표준입니다. 이는 양자 컴퓨터 시대에 대비한 포스트 양자 암호(PQC) 중 하나로, 안전한 공개키 기반 공유 비밀키 생성을 위한 암호 알고리즘입니다

ML-KEM 개요

• 목적: 두 사용자가 공개 채널을 통해 안전하게 공유 비밀키(shared secret key) 를 설정할 수 있게 해주는 암호 기술입니다.
• 방식: “KEM (Key-Encapsulation Mechanism, 키 캡슐화 메커니즘)” 구조를 따릅니다.
• 기반 수학: Module Learning With Errors (MLWE) 문제의 어려움에 기반함. 이는 lattice-based 문제로, 양자 컴퓨터에도 안전한 것으로 간주됨.

1. Alice: KeyGen() → (pk, sk)
2. Bob: Encaps(pk) → (c, K)
3. Bob → Alice에게 c 전송
4. Alice: Decaps(sk, c) → K'
5. 이제 Alice와 Bob은 공유키 K = K'

      Alice                                 Bob
     (수신자)                             (송신자)
   ------------                         ------------
   KeyGen()                             ← ek (공개키)
   ↓                                          |
   ek, dk                                     |
                                             Encaps(ek)
                                              ↓
                                    생성: (c, K), send c →
   Decaps(dk, c)                          ← c
   ↓
   생성: K′ (≈ K)

파라미터 세트

파라미터 세트

복호화 실패율

파라미터실패 확률

ML-KEM 작동 방식

1. KeyGen:

• Alice가 키 페어 (Encapsulation Key, Decapsulation Key)를 생성
• Encapsulation Key는 공개, Decapsulation Key는 비밀

입력 :

내부적으로 사용되는 랜덤 바이트 d, z (암호모듈이 생성함)

출력:

ek: Encapsulation Key (공개키)

dk: Decapsulation Key (비밀키)

1. 랜덤 시드 d → NTT를 위한 행렬 A를 생성
2. 노이즈 다항식 샘플링 → 비밀 벡터 s, 오류 벡터 e를 생성
3. t = A ∘ s + e (모듈 기반 다항식 연산)
4. 공개키 ek = 압축된 A, t 값
5. 비밀키 dk = s, e, t, z, 그리고 H(ek) 해시값

Algorithm 19 ML-KEM.KeyGen()
Input: None
Output: (ek, dk) — encapsulation key, decapsulation key

1: d ←$ B32                   // 32바이트 랜덤값
2: z ←$ B32                   // 또 다른 32바이트 랜덤값
3: (ek, dk) ← ML-KEM.KeyGen_internal(d, z)
4: return (ek, dk)

2. Encaps (Bob이 실행):

• Alice의 Encapsulation Key를 이용해 공유 비밀키 K 생성 + 캡슐화된 메시지 ciphertext 생성
• 이 ciphertext를 Alice에게 전송

입력:

ek (Alice의 공개키)

출력: 

c: ciphertext (암호문)

K: 공유 비밀키 (256비트)

1. 랜덤 메시지 m 생성 (32바이트)
2. m과 H(ek)를 해시하여 암호화용 시드 r 및 해시값 d 생성
3. m, r를 사용하여 Kyber 기반 PKE 암호화를 수행:
   • (u, v) 형태의 암호문 생성 (NTT 기반 다항식 연산)
4. c = (u, v, d)
5. 공유 비밀키 K는 H(m, c)를 통해 유도

Algorithm 20 ML-KEM.Encaps(ek)
Input: ek — encapsulation key
Output: (c, K) — ciphertext, shared secret key

1: m ←$ B32                         // 무작위 메시지 생성
2: d ← H(m || H(ek))               // 해시 통해 바인딩
3: (cPKE, m') ← K-PKE.Encrypt(ek, m, d)
4: K ← H(m || cPKE)                // 공유키 생성
5: c ← cPKE || d                   // 암호문 구성
6: return (c, K)

3. Decaps (Alice가 실행):

• 받은 ciphertext와 자신의 비밀키(Decapsulation Key)를 사용해 공유 비밀키 K′를 복원

입력:

dk: 비밀키

c: 암호문

출력:

K′: 공유 비밀키 (256비트)

1. 암호문 c를 디코딩 → (u, v, d)
2. dk의 비밀값을 사용해 (u, v)를 복호화 → 메시지 m′ 복원
3. ek 해시와 m′을 사용해 새로운 암호문 c′ 재생성
4. c′ == c이면:
   • K′ = H(m′, c) 사용
5. 그렇지 않으면:
   • K′ = H(z, c) (z는 비밀키 생성시 포함된 랜덤 값)
   • 마지막 단계는 IND-CCA2 보안을 보장하기 위한 방어 기법입니다. 암호문이 조작되었을 경우에도 K′를 추정할 수 없게 만듭니다.

Algorithm 21 ML-KEM.Decaps(dk, c)
Input: dk — decapsulation key, c — ciphertext
Output: K′ — shared secret key

1: Parse c as (cPKE, d)
2: m′ ← K-PKE.Decrypt(dk, cPKE)
3: (cPKE′, m″) ← K-PKE.Encrypt(ek, m′, d)
4: if cPKE′ == cPKE then
5:     K′ ← H(m′ || c)
6: else
7:     K′ ← H(z || c)              // CCA 방어
8: return K′

기술적 특성

• CRYSTALS-KYBER에서 파생된 알고리즘
• NTT (Number-Theoretic Transform) 활용해 다항식 곱셈 최적화
• IND-CCA2 보안 보장 (적응적 선택 암호문 공격에 안전)
• 키 및 캡슐 크기:
  • 예: ML-KEM-512는 공개키 800바이트, 비밀키 1632바이트, 캡슐화 메시지 768바이트, 공유 비밀키 32바이트

Open Quantum Safe 프로젝트 개요

배경 및 프로젝트 목적

Open Quantum Safe(OQS) 프로젝트는 양자 내성 암호(quantum-resistant cryptography)로의 전환을 지원하기 위해 시작된 오픈 소스 프로젝트입니다. 양자 컴퓨팅 기술의 발전으로 기존의 RSA, ECC 등 공개키 암호가 슈어(Shor)의 알고리즘 등에 의해 손쉽게 깨질 수 있는 위험성이 대두되었고, “Y2Q”(또는 Q-Day)라 불리는 시점에 대비해야 한다는 필요성이 제기되었습니다. 특히 “오늘 저장해서 훗날 풀기(harvest now, decrypt later)”와 같은 공격 시나리오가 우려되는데, 이는 현재 안전하다고 여겨지는 암호 통신을 도감청·저장해 두었다가 미래의 양자 컴퓨터로 복호화하는 방식입니다. 이러한 배경에서 OQS 프로젝트는 학계 및 업계와 협력하여 양자 내성 암호 알고리즘의 개발과 프로토타이핑을 촉진함으로써, 향후 양자 컴퓨팅 시대에도 안전한 보안 통신을 구현하는 것을 목표로 하고 있습니다.

추진 기관과 출범 배경

OQS 프로젝트는 2014년 미셸 모스카(Michele Mosca)와 더글라스 스티빌라(Douglas Stebila)에 의해 연구 프로젝트로 설립되었으며, 이후 다수의 기여자와 후원자의 도움을 받아 성장해 왔습니다. 2024년에는 OQS 프로젝트가 리눅스 재단(Linux Foundation)에 합류하여, 해당 재단의 Post-Quantum Cryptography Alliance 출범 프로젝트 중 하나가 되었습니다. 이로써 OQS는 보다 광범위한 산업계·학계의 지원을 받으며 발전하고 있으며, 현재 기술 지침은 OQS 기술 운영 위원회(Technical Steering Committee)에 의해 관리되고 있습니다. 초기 단계부터 OQS는 아마존 웹 서비스(AWS), 캐나다 사이버 보안 센터, 시스코(Cisco), VeriSign 등 여러 기관의 후원을 받아왔고, 캐나다 및 호주 등지의 연구지원 기금을 통해 일부 구성 요소 개발을 진행하기도 했습니다.

주요 활동 및 구성 요소

OQS 프로젝트는 크게 두 가지 축으로 활동합니다:

• liboqs 라이브러리 개발: liboqs는 양자 내성 암호 알고리즘들을 모아 제공하는 오픈 소스 C 라이브러리로, 키 캡슐화 메커니즘(KEM)과 디지털 서명 알고리즘 구현체들을 다수 포함하고 있습니다. 이 라이브러리는 다양한 최신 포스트 양자 알고리즘들을 한데 통합하여 일관된 API로 제공하며, 알고리즘 간 성능 비교를 위한 테스트 하네스와 벤치마크 도구도 포함하고 있습니다. liboqs에 구현된 알고리즘들은 주로 미국 NIST의 포스트 양자 암호 표준화 프로젝트에 제출된 공개 구현 코드를 기반으로 하고 있으며, NIST 표준화 결과에 따라 격자 기반, 코드 기반, 해시 기반 등 다양한 수학적 난제에 근거한 스킴들을 지원합니다. 예를 들어, 2022~2024년 NIST 최종 라운드에서 선정된 CRYSTALS-Kyber (격자 기반 KEM), CRYSTALS-Dilithium (격자 기반 서명), Falcon (격자 기반 서명), SPHINCS+ (해시 기반 서명) 등이 포함되었으며, 그 외에도 Classic McEliece(코드 기반 KEM), BIKE(코드 기반 KEM), HQC(코드 기반 KEM), FrodoKEM(격자 기반 KEM), NTRU 계열(격자 기반) 등 다양한 알고리즘을 실험적으로 지원합니다. 이러한 알고리즘 모음과 공용 API를 통해 개발자와 연구자들은 하나의 인터페이스로 여러 후보 암호들을 교체해가며 테스트할 수 있습니다.
• 암호 프로토콜 통합 및 실험: OQS는 liboqs에서 제공하는 알고리즘을 실제 애플리케이션과 통신 프로토콜에 접목하는 프로토타입 통합 작업을 수행합니다. 대표적으로 TLS/SSL 구현체인 OpenSSL과 BoringSSL의 포크(fork)를 만들어, 여기에 후보 PQC 알고리즘을 적용한 키 교환 및 인증서 검증 절차를 통합했습니다. OQS-OpenSSL (1.1.1 기반) 및 OpenSSL 3에 대한 OQS 제공자(provider), 그리고 BoringSSL 포크 등이 개발되어 TLS 1.3 핸드셰이크에 양자 내성 하이브리드 키 교환이나 PQ 서명 알고리즘을 적용한 실험이 가능해졌습니다. 마찬가지로 SSH 프로토콜에서도 OpenSSH를 포크한 OQS-OpenSSH를 통해 PQ 및 하이브리드 키 교환을 구현하여 시범 운영하고 있습니다. 이외에도 X.509 인증서, VPN, MQTT 등 다양한 보안 프로토콜에 양자 내성 알고리즘을 접목한 예제들과 데모를 제공함으로써, 실제 환경에서의 호환성과 성능을 시험하고 개발자들이 쉽게 실험해볼 수 있도록 지원합니다. 다만 이러한 통합 버전들은 어디까지나 프로토타이핑 및 연구 목적의 레퍼런스 구현으로 제공되는 것이며, 상용 환경에서 바로 사용하기에는 성숙도가 부족하다는 점을 명시하고 있습니다 . 실제 배포시에는 전통 암호와 PQC의 혼합(hybrid)사용 등을 통해 점진적으로 전환하는 것이 권장되며, OQS 측도 보안 한계와 위험성을 프로젝트 FAQ와 문서를 통해 투명하게 공유하고 있습니다.

사용하는 주요 기술 (liboqs 등)

liboqs는 OQS 프로젝트의 핵심 기술 산출물로서, 다음과 같은 특징을 지닙니다:

• 오픈 소스 및 다중 플랫폼: MIT 라이선스로 공개된 liboqs는 리눅스, macOS, Windows 등 여러 운영체제와 x86_64, ARM 등의 아키텍처에서 동작하도록 설계되었습니다. 크로스 컴파일 도구체인을 통해 임베디드 등 기타 플랫폼용 빌드도 지원하며, C99 준수 API로 구현됩니다.
• 공용 API 제공: KEM 알고리즘들과 전자서명 알고리즘에 대한 통일된 함수 호출 인터페이스를 제공하여, 응용 프로그램이 특정 알고리즘에 종속되지 않고도 쉽게 교체 실험을 할 수 있습니다. 이 API 설계는 NIST 및 SUPERCOP의 표준 인터페이스를 참고하여 만들어졌으며, 추가적인 래퍼와 데이터 구조를 통해 사용성을 높였습니다.
• 다언어 래퍼: C 라이브러리인 liboqs의 기능을 C++(oqs-cpp), Python(oqs-python), Go(oqs-go), Rust(oqs-sys) 등 다양한 언어 환경에서 사용할 수 있도록 래퍼(wrapper) 프로젝트도 제공됩니다. 이를 통해 폭넓은 개발자 커뮤니티가 자신이 선호하는 언어로 양자 내성 암호 기술을 시험해볼 수 있습니다.
• 알고리즘 구현 및 관리: liboqs에 포함된 알고리즘 구현체들은 NIST PQC 경연에 참가한 팀들이 공개한 레퍼런스 구현 또는 최적화 구현을 그대로 가져오거나, PQClean 등의 프로젝트를 통해 표준화된 형태로 통합된 것입니다. 따라서 학계 최신 구현을 폭넓게 아우르며, 알고리즘별로 성능 벤치마크와 테스트를 수행해 신뢰성을 확인합니다. OQS는 특정 알고리즘의 “승자”를 미리 결정하지 않으며, NIST 표준화 결과와 연구 동향에 따라 지원 알고리즘 목록을 조정합니다. 예컨대, 4라운드 표준화에서 탈락하거나 보안 약점이 발견된 알고리즘(예: SIKE의 기반인 SIDH의 공격 사례)은 목록에서 제거하고, 새로운 후보나 표준 채택 알고리즘은 추가하는 식입니다. 이러한 유연성과 개방성은 향후 더 강력한 양자 공격이나 추가 알고리즘 발전이 있을 경우에도 지속적으로 대응할 수 있게 해줍니다.

양자 컴퓨팅 시대를 대비한 보안적 의미

OQS 프로젝트의 등장은 양자 컴퓨팅 시대에 대비한 선제적 보안 강화 노력이라는 점에서 중요한 의미를 가집니다. 오늘날 양자 컴퓨터의 성능은 아직 제한적이어서 실제로 현행 암호를 깨지는 못하지만, 암호 표준 교체에는 오랜 시간이 소요되기 때문에 미리 대비책을 마련해야 합니다. 모스카의 정리(Mosca’s theorem)에서도 언급되듯이, 데이터의 보유 기간과 알고리즘 전환 기간, 양자 컴퓨터 개발 속도를 고려하면 지금 이 순간부터 준비를 시작해야 안전하다고 합니다. OQS는 이러한 대비를 위해 오픈 소스 커뮤니티 주도로 누구나 PQC 알고리즘을 시험하고 기존 시스템에 통합해볼 수 있는 공개된 장터(테스트베드) 역할을 합니다.

또한 OQS 프로젝트는 표준화 기관(NIST 등)의 노력과 보조를 맞춰 움직이므로, 산업계가 혼란을 최소화하면서 양자 내성 암호로 이행하도록 돕고 있습니다. 예를 들어 NIST가 2022~2024년에 걸쳐 선정한 초기 PQC 표준 알고리즘들을 OQS의 도구체인에 신속히 반영함으로써, 웹 브라우저, TLS 라이브러리, VPN 소프트웨어 등에서 일찍이 양자 안전 기능을 시험 구축해볼 수 있었습니다. 일부 기술 선도 기업들은 이미 iMessage나 Signal과 같은 메시징 시스템, Cloudflare의 TLS 트래픽 등에 PQC를 도입하거나 시범운용하고 있는데, 이러한 실험들이 가능하도록 OQS가 공통 플랫폼을 제공한 셈입니다. 요약하면, Open Quantum Safe 프로젝트는 향후 도래할 양자 컴퓨팅 위협에 대응하여 암호 인프라의 안전한 업그레이드 경로를 마련해주는 핵심적인 오픈 소스 이니셔티브이며, 정부·기업·학계에 정보 공유와 협력의 장을 제공함으로써 모두의 보안 수준을 높이는 데 기여하고 있습니다.

블록 암호의 주요 패딩 알고리즘

패딩 알고리즘 개요

블록 암호는 정해진 크기(예: 64비트=8바이트, 128비트=16바이트 등)의 블록 단위로 데이터를 암호화합니다. 따라서 메시지 길이가 블록 크기의 배수가 아닌 경우 패딩(padding)을 추가하여 마지막 블록을 채워야 합니다. 패딩은 평문에 일정한 규칙으로 의미 없는 바이트들을 추가하는 작업으로, 복호화 시에도 동일한 규칙으로 이를 제거하여 원래의 평문을 복원할 수 있게 해줍니다. 패딩 방식에 따라 암호화된 결과의 길이가 블록 크기까지 늘어나며, 복호화 프로그램이 패딩된 바이트들을 정확히 인식하고 제거할 수 있도록 특정 패턴을 따릅니다.

패딩을 적용하지 않으면 마지막 블록이 부족한 상태로 암호화를 수행할 수 없을 뿐 아니라, 복호화 시에도 어디까지가 실제 평문이고 어디부터가 쓰레기 데이터인지 구분할 수 없습니다. 예를 들어 평문의 길이가 블록 크기의 정확한 배수인 경우, 별도의 조치 없이 암호화하면 복호화 시 마지막 바이트가 평문의 일부인지 패딩인지 구분할 수 없습니다. 이를 해결하기 위해 패딩 규격들은 항상 최소 1바이트 이상의 패딩을 추가하도록 정의되어 있으며, 평문 길이가 딱 맞아 떨어지는 경우에도 하나의 전체 블록을 패딩으로 채워 구분이 가능하게 합니다.

대표적인 패딩 알고리즘 목록

블록 암호에서 널리 사용되거나 표준으로 정의된 대표적인 패딩 방식은 다음과 같습니다:

• PKCS#7 패딩 – 패딩으로 추가되는 모든 바이트의 값이 추가된 전체 패딩 바이트의 개수를 나타내는 방식 (PKCS#5는 8바이트 블록 암호에 국한된 동일 방식)
  예를 들어 4바이트를 패딩으로 추가해야 하면 각 바이트에 값 0x04를 넣습니다.
• ANSI X.923 패딩 – 마지막 바이트를 추가된 패딩 바이트의 개수로 설정하고, 그 밖의 패딩 바이트들은 모두 0x00 (또는 구현에 따라 임의의 값)으로 채우는 방식
  예를 들어 4바이트 패딩 시 마지막 바이트는 0x04, 이전의 3바이트는 0x00으로 채웁니다.
• ISO/IEC 7816-4 패딩 – 패딩의 첫 바이트로 0x80 하나를 추가하고, 남는 패딩 바이트는 모두 0x00으로 채우는 방식
  만약 패딩이 한 바이트만 필요하면 0x80 한 바이트만 추가합니다.
• 제로 패딩(Zero Padding) – 필요한 패딩 바이트를 전부 0x00 값으로 채우는 방식
  다른 메커니즘과 달리 패딩 자체에 대한 별도 표준이 아니지만, 실행 환경에서 평문 길이를 별도로 알고 있거나 평문의 마지막에 널(byte 0x00)이 올 수 없는 경우에 종종 사용됩니다
• ISO 10126 패딩 – 현재는 폐지된 이전 표준으로, 패딩 길이 이외의 패딩 바이트들을 임의의 랜덤 값들로 채우고 마지막 바이트에 패딩 개수를 기록하는 방식입니다

이외에도 특수한 상황에서는 비트 패딩(bit padding)이 사용되기도 하는데, ISO/IEC 7816-4 방식이 이에 해당하며 비트 단위 프로토콜에서도 적용할 수 있는 패딩 방식입니다.

패딩 알고리즘 동작 원리와 예시

PKCS#7 패딩 (PKCS#5 포함)

PKCS#7은 현재 가장 널리 쓰이는 패딩 규격으로, 추가되는 각 바이트의 값으로 추가된 패딩 바이트의 개수를 기록합니다. 즉, N바이트를 패딩해야 한다면 패딩 공간을 N으로 채운 값 N을 가진 바이트들로 모두 채우는 방식입니다. 예를 들어 블록 크기가 8바이트이고 마지막 블록에 5바이트의 패딩이 필요하다면, 0x05 값을 가진 바이트 5개를 추가합니다. 만약 평문 길이가 블록의 배수라 하더라도 규격상 항상 8바이트 패딩 블록을 추가해야 하므로, 이 경우에는 8바이트 모두를 값 0x08로 채운 하나의 패딩 블록이 추가됩니다 

PKCS#5 패딩은 PKCS#7의 특별한 경우로, 64비트(8바이트) 블록 암호(예: DES)에 대해서만 정의된 것입니다. 내용적으로 PKCS#7과 동일하며, 단지 블록 크기가 8바이트인 경우에 한해 쓰인 명칭일 뿐이므로 실제 구현이나 사용에서는 PKCS#7과 interchangeably 사용됩니다 

• 예시: 평문이 "HELLO" (5바이트)이고 블록 크기가 8바이트라고 가정하면, PKCS#7 패딩을 적용하여 3바이트를 추가해야 합니다. 추가되는 바이트들은 모두 패딩 전체 크기인 0x03으로 채워지므로, 실제 암호화되는 최종 바이트열은 "HELLO\x03\x03\x03"이 됩니다. 복호화 측에서는 암호문을 복호화한 결과의 마지막 바이트를 확인하여 0x03이므로 마지막 3바이트를 제거함으로써 원래 평문을 복원합니다.

ANSI X.923 패딩

ANSI X.923 패딩은 미국 ANSI에서 정의한 데이터 패딩 방식으로, 패딩의 마지막 바이트에만 패딩 바이트의 개수를 기록하고 그 이전의 모든 패딩 바이트들은 0값으로 채우는 것이 특징입니다 패딩으로 최소 1바이트에서 최대 블록 크기 바이트까지 추가되며(블록 크기가 8일 경우 1~8바이트), 마지막에 추가된 패딩 바이트의 값은 추가된 패딩 바이트의 수 N을 의미하는 0xN입니다. 표준상 마지막 바이트 이외의 패딩 바이트 값은 무작위 값으로 채울 수 있으나, 일반 구현에서는 편의상 모두 0x00으로 채우는 경우가 많습니다

• 예시: 블록 크기가 8바이트인데 마지막 블록에 4바이트의 패딩이 필요하다고 가정하면, ANSI X.923 방식에서는 추가되는 4바이트 중 마지막 바이트를 0x04로 설정하고 앞선 3바이트는 0x00으로 채웁니다 따라서 패딩된 최종 블록은 ... | DD DD DD DD 00 00 00 04 |의 형태를 갖습니다. 복호화 시 마지막 바이트의 값 0x04를 읽어 4바이트의 패딩이 추가되었음을 알고, ciphertext 끝의 4바이트를 제거하여 원문을 얻습니다.

PKCS#7 패딩과 ANSI X.923 패딩은 동일한 정보를 약속된 다른 형태로 기록할 뿐 기능적으로 등가(equivalent)합니다 두 방식 모두 마지막 바이트에 패딩 길이를 담고 있으며 최대 255 바이트까지 패딩을 표현할 수 있습니다. 차이는 PKCS#7은 패딩 바이트들을 모두 동일한 값으로 채우는 반면 ANSI X.923은 마지막 바이트를 제외한 패딩 영역을 0 또는 임의의 값들로 채운다는 점뿐입니다. 이 미묘한 차이로 인한 유의미한 이점은 거의 없으며, 실제 보안성이나 성능 면에서 두 방식은 대등합니다 

ISO/IEC 7816-4 패딩

ISO/IEC 7816-4 패딩은 국제 표준으로, 스마트카드 등의 파일 시스템 규격에서 유래한 패딩 방식입니다 패딩의 첫 번째 바이트를 0x80 값으로 설정하고 나머지 필요한 패딩 바이트들은 모두 0x00으로 채워 블록을 마무리하는 것이 특징입니다 이 방식은 종종 “80h 패딩”, “1-그리고-0 패딩(one-and-zero padding)” 또는 비트 패딩(bit padding)이라고도 불리는데, 이는 이 규격이 실제로 평문 데이터의 끝에 1 비트(1000 0000의 0x80)만 세우고 나머지 패딩 구간은 0으로 채우는 개념이기 때문입니다. 이러한 정의 덕분에 바이트 단위뿐 아니라 비트 단위로도 응용할 수 있어, 메시지 길이가 바이트 경계가 아닐 때도 동일 원리로 패딩을 적용할 수 있습니다.

• 예시: 블록 크기가 8바이트이고 4바이트의 패딩이 필요한 경우, ISO 7816-4 방식으로 패딩하면 첫 패딩 바이트는 0x80, 나머지 3바이트는 0x00으로 채워집니다. 예를 들면 최종 블록이 ... | DD DD DD DD 80 00 00 00 | 형태가 됩니다. 만약 1바이트의 패딩만 필요했다면 0x80 한 바이트만 추가되어 마지막 블록은 ... | ... DD 80 |와 같이 0x80으로 끝나게 됩니다. 복호화 시에는 복호화된 데이터의 끝부분부터 역방향으로 스캔하며 최초로 나타나는 0x80 바이트를 찾고, 그 바이트부터 끝까지를 패딩으로 간주하여 제거합니다. 만약 역으로 탐색했을 때 0x80이 나타나지 않거나 규칙에 맞지 않는 값이 나오면 패딩 오류로 간주합니다.

ISO 7816-4 패딩은 명시적인 패딩 길이 숫자가 없기 때문에 이론적으로는 무제한 길이의 패딩도 지원할 수 있습니다 다만 일반적으로는 필요한 최소한의 바이트만 패딩으로 추가하며, 다른 패딩들과 마찬가지로 평문 길이가 블록 경계에 정확히 맞아떨어지더라도 0x80과 0으로 이루어진 한 블록의 패딩을 추가하도록 정의합니다 (그렇지 않으면 평문의 마지막 바이트가 우연히 0x80일 때 혼동이 발생할 수 있기 때문입니다).

제로 패딩 (Zero Padding)

제로 패딩은 말 그대로 모든 패딩 바이트를 0x00 값으로 채우는 방식입니다. 예를 들어 4바이트의 패딩이 필요하면 00 00 00 00을 추가하는 식입니다. 이 방식은 엄밀히 말해 암호화 표준으로 공식화된 적은 없지만, 구현이 단순하여 일부 상황에서 관습적으로 사용됩니다. 특히 암호화하는 데이터의 실제 길이를 별도의 메타데이터로 알고 있는 경우나, 평문 데이터가 문자열이고 문자열의 끝에는 0x00 (널 문자) 등이 올 수 없는 환경에서 활용됩니다. 이러한 경우에는 복호화 후 미리 알고 있던 길이만큼만 취하거나, 또는 문자열의 경우 '\0' 이후를 무시하는 방식으로 패딩을 제거하여 원문을 복원할 수 있습니다.

• 예시: 평문 "ABC" (3바이트)를 8바이트 블록 암호로 암호화한다고 가정하면, 남는 5바이트를 모두 0x00으로 패딩할 수 있습니다. 암호화되는 최종 바이트열은 "ABC\x00\x00\x00\x00\x00"가 되며, 복호화한 쪽에서 원본 데이터의 길이(3바이트)를 알고 있다면 앞의 3바이트 "ABC"만을 취하고 이후의 0x00 바이트들은 버립니다.

제로 패딩은 구현이 가장 간단하지만 패딩을 식별할 수 있는 정보가 존재하지 않으므로 안전한 복원에는 별도의 전제 조건이 필요합니다. 예를 들어 평문 데이터가 임의의 바이너리 데이터일 경우 마지막에 0x00 바이트가 포함되어도 전혀 이상하지 않으므로, 패딩으로 추가된 0x00들과 평문의 실제 0x00 데이터를 구분할 방법이 없습니다. 따라서 평문 길이를 별도로 전달하거나, 혹은 평문이 특정 문자 인코딩 문자열이라서 0x00은 종단 문자로서만 등장한다는 보장이 있을 때에만 사용이 권장됩니다. 만약 이러한 조건 없이 제로 패딩을 사용할 경우 복호화 결과에서 패딩과 실제 데이터를 혼동하여 데이터 무결성이 깨질 위험이 있습니다.

패딩 알고리즘 비교 및 활용

대표적인 패딩 방식들의 원리를 살펴보았으므로, 이제 각 방식별로 어떤 상황에 적합하고 어떤 장단점이 있는지 비교해보겠습니다. 아래는 각 패딩 방식의 권장 활용 분야와 장단점을 정리한 내용입니다:

• PKCS#7 패딩
  • 적합한 상황: 범용적으로 가장 많이 사용되는 패딩으로, 특별한 요구 사항이 없다면 기본 선택지로 적합합니다. 다양한 프로그래밍 언어나 암호화 라이브러리에서 기본 제공되며, 과거 TLS 등 여러 프로토콜에서도 채택되었을 만큼 폭넓게 활용됩니다
  • 장점: 표준으로 명확히 정의되어 있어 상호운용성이 높고 구현이 쉬우며, 패딩 길이 정보가 명시적으로 포함되어 있어 복호화 시 처리도 간단합니다. 또한 모든 패딩 바이트가 동일한 값이므로, 패딩 무결성 검증시 한 번에 검사가 가능하여 오류를 쉽게 잡아낼 수 있습니다.
  • 단점: 평문이 블록 경계에 딱 맞을 경우에도 전체 블록을 추가로 패딩해야 하므로 데이터 길이가 늘어나는 오버헤드가 있습니다. 예컨대 16바이트 단위 AES에서 16바이트짜리 평문 하나를 암호화하면 16바이트를 더 패딩으로 붙여 총 32바이트 암호문이 됩니다. 하지만 이러한 단점은 ANSI X.923 등의 다른 표준 패딩도 동일하며, 패딩 자체로 인한 성능 부담은 일반적으로 미미한 편입니다.
• ANSI X.923 패딩
  • 적합한 상황: 과거 금융권 등 특정 표준을 준수해야 하는 시스템에서 주로 사용되었습니다. 현재는 PKCS#7로 대체되는 추세지만, 기존 VB6/ASP.NET 등 일부 구현이 ANSI X.923을 기본 사용하는 경우가 있어 이들과의 호환이 필요할 때 선택합니다.
  • 장점: PKCS#7과 마찬가지로 명시적인 패딩 길이 정보를 포함하여 확실한 패딩 제거가 가능합니다. 모든 패딩 바이트를 0으로 채우므로 필요시 평문을 패딩 전후로 시각적으로 구분하기가 다소 수월할 수 있으며 (패딩 영역이 모두 00으로 보임), 임의의 값으로 패딩을 채울 유연성도 있습니다. 또한 PKCS#7로 패딩된 암호문을 X.923 패딩으로 간주하고 해제하거나 그 반대의 처리도 이론적으로는 가능할 정도로 유사합니다.
  • 단점: PKCS#7 대비 특별한 우위점이 거의 없어 현대의 암호 표준에서 잘 쓰이지 않는 방식입니다. 패딩 바이트 중 마지막 한 바이트만 유의미하고 나머지는 모두 0이어서, 만약 패딩 영역에서 단일 바이트 오류가 발생해도 (예: 0이 아닌 값으로 변조돼도) 패딩 길이만 맞으면 검출이 어려울 수 있다는 지적이 있습니다. 실제 구현에서는 패딩 바이트 전체에 대한 무결성 검사를 수행하므로 이러한 차이는 크지 않지만, 패딩 오라클 공격 등 취약성 관점에서 PKCS#7에 비해 더 안전하다고 볼 근거는 없습니다.
• ISO/IEC 7816-4 패딩
  • 적합한 상황: 스마트카드 응용이나 특정 임베디드 시스템에서 주로 사용됩니다. 또한 비트 단위의 메시지 길이를 처리해야 할 때 (예를 들어, 마지막에 1 비트만 세우고 남은 비트를 패딩하는 경우) 이 방식을 일반화하여 쓸 수 있습니다. 일반 소프트웨어 환경에서는 드물지만, 암호 라이브러리에서 옵션으로 제공되는 경우가 있어 특수한 프로토콜 구현에 사용되기도 합니다.
  • 장점: 패딩에 고정된 구분 마커(0x80)를 사용하므로 패딩의 시작 지점을 뚜렷이 표시할 수 있으며, 패딩 길이와 무관하게 일정한 패턴을 가집니다. 0x80 한 바이트만 찾으면 패딩 전체를 식별할 수 있기 때문에, 블록 경계가 아닌 임의의 길이(비트 단위)에도 확장할 수 있는 융통성이 있습니다 . 또한 패딩 영역이 모두 0x80 또는 0으로 구성되어 있어, 패딩 데이터가 암호문에 미치는 영향이 상대적으로 단순합니다.
  • 단점: 패딩을 제거하려면 역순으로 바이트를 검사해야 하며 (특히 여러 블록에 걸쳐 패딩이 존재할 경우 조금 더 복잡해짐) 최악의 경우 평문의 처음까지 확인해야 하는 오버헤드가 있습니다. 하지만 블록 크기가 크지 않으므로 이 성능 영향은 미소합니다. 또한 다른 표준에 비해 대중적인 구현체가 적어 호환성 측면에서 덜 보편적입니다. 패딩의 특정 바이트 값(0x80) 의존 특성상, 평문에 0x80이 많이 등장하는 경우 패딩 부분과 혼동될 여지가 있지 않냐는 의문이 있을 수 있으나, 규칙상 평문 끝에 바로 패딩 마커를 붙이도록 정의되어 있어 실제 혼동이 발생하지는 않습니다.
• 제로 패딩
  • 적합한 상황: 평문의 실제 길이를 별도로 관리하는 프로토콜이나, 평문이 문자열 데이터로 마지막에 0x00 문자가 올 수 없다고 보장되는 경우에 한해 사용이 권장됩니다. 예를 들어 네트워크 프로토콜에서 암호화 전에 평문의 길이를 따로 전송하거나, 암호화 파일 포맷에서 원본 데이터 크기를 별도 메타데이터로 저장하는 경우 등이 이에 해당합니다. 이 밖에 C언어 스타일의 널 종단 문자열(null-terminated string)을 암호화할 때 문자열 끝의 '\0'들을 패딩으로 활용하는 용도로 쓰이기도 합니다 
  • 장점: 가장 구현이 단순하며, 추가적인 정보 없이도 직관적으로 패딩을 채울 수 있기 때문에 오류 가능성이 적은 편입니다. 또한 패딩 바이트가 모두 0x00이므로 사람이 확인하기에도 분명하고, 특정 상황에서는 패딩 제거 연산을 생략하고도 자연스럽게 평문을 얻을 수 있습니다 (예: null-terminated 문자열을 복호화한 경우, 문자열 연산에서 '\0' 이후를 읽지 않으므로 패딩을 자동 무시하게 됨).
  • 단점: 패딩과 평문을 구분할 명확한 방법이 없기 때문에 위험합니다. 별도의 평문 길이 정보가 없으면, 복호화 결과의 뒤쪽에 있는 0x00들이 원래 평문에 포함된 값인지 패딩인지 판단할 수 없습니다. 이러한 모호성 때문에 일반 암호 프로토콜에는 잘 사용되지 않으며, 표준화된 규격도 존재하지 않습니다. 잘못 사용할 경우 데이터 일부가 손실되거나 불필요한 바이트가 덧붙는 부작용이 발생할 수 있습니다.
• ISO 10126 패딩 (참고)
  • 적합한 상황: 현재는 권고되지 않는 구식 방식으로, 특별한 이유가 없다면 사용되지 않습니다. 과거에 임의 바이트로 채워서 분석을 어렵게 하려는 의도로 고안되었으나, 현대에는 임의의 IV나 AEAD 알고리즘으로 동일한 효과를 얻기 때문에 의미가 줄어들었습니다.
  • 장점: 패딩 바이트들을 랜덤한 값들로 채우므로 암호문만 보았을 때 패딩 부분에 규칙성이 거의 없습니다. 이론적으로 동일한 평문이라도 암호화를 할 때마다 패딩이 달라질 수 있어, 마지막 블록의 암호문이 매번 바뀌는 효과를 냅니다.
  • 단점: ANSI X.923과 마찬가지로 마지막 한 바이트 외에는 패딩 데이터로서 별 의미가 없고, 그 값들이 랜덤이므로 복호화 시 검증이 사실상 불가능합니다. 즉 패딩 길이만 맞으면 어떤 값이든 받아들이게 되므로, 오류 탐지가 어렵고 보안적으로 이점이 없습니다. ISO 10126 표준 자체도 2007년에 폐지되었으며 , 현재 주요 라이브러리에서는 지원하지 않는 경우가 많습니다.

보안적 고려사항 (패딩 오라클 공격)

패딩 적용 시에는 **패딩 오라클 공격(padding oracle attack)**에 대한 대비가 필요합니다. 패딩 오라클 공격이란, 암호화된 데이터의 패딩 유효성 여부가 외부에 누설되는 취약점을 이용하여 공격자가 암호문의 일부를 평문으로 해독하거나 임의의 평문을 암호화해내는 기법입니다. 예를 들어 서버 측에서 암호문을 복호화한 뒤 패딩이 올바르지 않으면 에러 메시지를 보내주거나 다른 응답을 보인다면, 공격자는 이를 이용해 평문의 바이트를 하나씩 역추론하거나 잘못된 패딩을 이용해 암호문을 조작할 수 있습니다. 2002년 Serge Vaudenay의 논문으로 CBC 모드에서의 패딩 오라클 공격이 처음 널리 알려졌으며, 이후 웹 애플리케이션 등 다양한 환경에서 실습적으로 이러한 공격이 구현되었습니다.

패딩 오라클 공격은 패딩 방식 자체의 문제라기보다는 구현상의 정보 노출 문제입니다. PKCS#7, ANSI X.923, ISO 7816-4 등 어떤 패딩을 쓰든지, 복호화 과정에서 “패딩이 유효한지” 여부를 공격자가 알아챌 수 있다면 모두 공격에 노출될 수 있습니다. 패딩의 구조적인 차이가 공격 난이도에 약간 영향을 줄 수는 있지만 근본적인 해결책이 되지는 않습니다. 따라서 다음과 같은 대응책을 적용하는 것이 중요합니다:

• 패딩 오류 정보를 숨기기: 복호화 후 패딩 오류가 발생하더라도 공격자에게 동일한 형태의 응답을 돌려주고, 패딩 오류와 다른 오류를 구별할 수 없게 만듭니다. 예를 들어 패딩이 잘못되어도 그냥 일반적인 “해독 실패” 오류를 내고 추가 정보를 주지 않거나, 오류가 발생한 경우 시간을 일부러 지연시키는 등의 방법으로 공격자가 판단하기 어렵게 합니다.
• 무결성 검증 (MAC 또는 인증): **메시지 인증 코드(MAC)**나 전자서명 등을 활용하여 평문 패딩까지 포함한 무결성을 검증한 후에만 평문을 처리합니다. 일반적으로는 암호문에 대한 HMAC을 함께 전송하여 복호화 전에 검증하거나, 최신 프로토콜에서는 인증된 암호화(AEAD) 모드를 사용하여 암복호화 시 자동으로 무결성을 확인합니다. 이를 통해 패딩이 잘못된 경우에도 애초에 MAC 검증에서 걸러지므로 패딩 오류 여부가 외부에 드러나지 않게 됩니다.
• 패딩 대신 스트림 모드 사용 고려: 기술적으로는 패딩을 사용하지 않도록 암호 운용 방식을 선택하는 것도 방법입니다. 예를 들어 CTR이나 CFB와 같은 스트림 모드로 블록 암호를 운영하면 별도의 패딩 없이도 임의 길이의 데이터를 처리할 수 있습니다. 다만 이러한 변경은 시스템 전반의 구조를 바꾸는 것이므로 기존 프로토콜을 유지하면서는 어렵고, 가능하다면 GCM과 같은 AEAD 모드로 교체하는 것이 근본적인 해결책이 될 수 있습니다.

요약하면, 패딩 알고리즘을 선택할 때에는 용도와 환경에 따라 적절한 방식을 고르고, 구현 시에는 패딩으로 인한 보안 취약점이 발생하지 않도록 주의해야 합니다. 대부분의 현대적인 시스템에서는 PKCS#7 패딩을 기본으로 사용하며, 동시에 패딩 오라클 공격을 막기 위한 무결성 체크나 인증된 암호화를 적용하는 것이 일반적입니다. 패딩 자체는 블록 암호를 유연하게 사용하기 위한 필수 요소이므로, 그 원리와 각 방식의 특성을 이해하고 안전하게 활용하는 것이 중요합니다.