제 6 장: FIPS 140-3 검증 경로

6.1 FIPS 140-3 표준 체계의 개요

NIST FIPS 140-3은 2019년 3월 22일 미국 상무부에서 공식 승인된 암호 모듈 보안 요건 표준으로, 이전 FIPS 140-2 (2001년 5월 25일 승인) 의 후속이다. FIPS 140-3은 새 요구사항을 처음부터 다시 정의하는 대신 국제 표준 ISO/IEC 19790:2025 (Information technology — Security techniques — Security requirements for cryptographic modules) 를 본문으로 채택하고, 시험 요건은 ISO/IEC 24759:2025 (Test requirements for cryptographic modules) 를 채택한다. 이로써 미국과 국제 사회가 처음으로 단일 표준 본문 위에서 암호 모듈 검증을 운영하게 되었으며, 캐나다 CCCS (Canadian Centre for Cyber Security) 와의 공동 운영이 자연스럽게 이어진다.

TLS Lite는 자원 제약 호스트(IoT 게이트웨이·산업 PLC·의료기기)를 표적으로 하므로, 그 안에 박힌 암호 모듈 자체가 검증 대상이 된다. TLS Lite 봉투에 박힌 X25519 키 교환, ed25519 서명, HKDF-Expand, AES-GCM 인증암호는 모두 FIPS 140-3 시험 카탈로그에 등재된 알고리즘들이다. 본 장은 표준 본문을 단순히 인용하는 데 그치지 않고, TLS Lite 구현자가 FIPS 140-3 인증서 (Validation Certificate) 를 보유한 모듈을 호스트 안에 넣는 실무 경로를 단계별로 설명한다.

FIPS 140-3 검증은 두 축으로 운영된다. 첫째, CAVP (Cryptographic Algorithm Validation Program) 는 알고리즘 단위 인증을 발행한다. 즉 "이 모듈의 AES-GCM 구현이 NIST SP 800-38D 시험 벡터를 모두 통과했다"를 증명한다. 둘째, CMVP (Cryptographic Module Validation Program) 는 모듈 전체 인증을 발행한다. 즉 알고리즘 통과에 더해, 물리적 경계·자체 시험·키 관리·운영 환경·역할 기반 인증 등 11개 영역 전체를 시험 실험실 (NVLAP 인증) 이 검증한 결과에 NIST와 CCCS가 인증서 번호를 부여한다.

운영자가 자주 혼동하는 지점은 "벤더 확인 (Vendor Affirmation)" 과 "CMVP 인증서" 의 구분이다. 벤더 확인은 제조사가 자체적으로 "FIPS 140-3 호환" 이라고 선언하는 것으로, 법적 효력이 없다. 미 연방 정부 조달 (Federal Information Security Modernization Act, FISMA) 과 한국 공공 정보보호제품 평가·검증 (CC EAL / KCMVP) 에서는 반드시 인증서 번호를 가진 모듈만 인정한다. 본 장은 인증서를 발행 받는 정식 경로를 다룬다.

6.2 FIPS 140-2 → 140-3 주요 변경점

FIPS 140-3은 FIPS 140-2 대비 12개 영역에서 핵심 변경을 도입했다. 가장 큰 변경은 본문 자체가 NIST가 단독 저술한 표준에서 ISO/IEC 19790:2025 채택으로 전환된 점이며, 그 결과 비미국 (한국·일본·EU) 검증 기관과의 상호 인정이 구조적으로 가능해졌다. 표 6-1은 12개 영역 변경 요약이다.

가장 실무적인 충격은 비결정적 난수 생성 (Deterministic Random Bit Generator, DRBG) 요구의 강화이다. FIPS 140-3은 SP 800-90A (DRBG 메커니즘) 뿐 아니라 SP 800-90B (엔트로피 소스 평가) 와 SP 800-90C (RBG 구성) 를 모두 요구한다. TLS Lite 봉투의 nonce 생성과 X25519 사설키 생성이 이 RBG에 의존하므로, 호스트 보드에 박힌 하드웨어 엔트로피 소스 (HEALTH TESTS 통과 필수) 의 적합성 증거가 검증 패키지에 포함되어야 한다.

6.3 보안 등급 Level 1~4

FIPS 140-3은 단일 등급이 아니라 4단계 보안 등급을 정의한다. 모듈은 11개 영역 각각에 등급을 받고, 전체 모듈 등급은 가장 낮은 영역 등급으로 결정된다 (최단 사슬 법칙). 표 6-2는 영역별 등급 요건 요약이다.

TLS Lite의 표적 시장 (IoT·산업)에서는 Level 2 또는 Level 3이 가장 흔하다. 일반 게이트웨이·소비자 IoT는 Level 1으로 충분한 반면, 산업 PLC·의료기기·금융 결제 단말은 Level 2~3을 요구한다. Level 4는 핵 시설·국가 비밀 통신처럼 극단적 위협 환경에서만 요구되며, 시장에 인증된 Level 4 모듈은 손에 꼽힌다 (2026년 5월 기준 CMVP 등재 약 12종).

한 모듈 제조사 검증 책임자의 회고에 따르면, Level 2에서 Level 3으로의 도약은 "탬퍼 증거"에서 "탬퍼 응답"으로의 전환이 핵심이며, 이는 단순히 봉인 스티커를 더 두껍게 붙이는 차원이 아니라 칩 내부에 탬퍼 감지 회로와 그 즉시 동작하는 키 영점화 (zeroization) 회로를 박는 하드웨어 재설계를 요구한다. 그 결과 NRE 비용이 보통 8~15배 증가하며, 일정도 6개월 이상 추가된다.

6.4 CMVP 검증 절차와 평균 소요

CMVP는 NIST와 CCCS가 공동 운영하는 모듈 검증 프로그램이다. 운영 대기열 (Modules in Process List) 은 NIST CSRC 사이트에 매주 갱신되어 공개된다. 평균 소요는 2026년 5월 기준 표 6-3과 같다.

2026년 5월 기준 NIST CSRC 의 Modules in Process 페이지에는 약 380개 모듈이 대기열에 있으며, 이 중 약 75%가 "Review Pending" (NIST·CCCS 심사 대기) 상태이다. 대기열 평균 체류 기간이 늘어난 배경에는 FIPS 140-3 전이가 2026년 9월 22일에 완전 종료되어 (Sunset Date), FIPS 140-2 인증서가 모두 폐기된 영향이 있다. 그 결과 2024년 하반기부터 모든 신규·갱신 모듈이 140-3 경로로 쏠려, NIST 인력 대비 처리량이 1.6배 초과되었다.

실무 운영자에게 의미 있는 함의는 두 가지이다. 첫째, 신규 모듈을 시장에 출시하려면 최소 18개월의 검증 일정을 전체 제품 로드맵에 반영해야 한다. 둘째, 이미 인증서를 가진 모듈을 OEM (Original Equipment Manufacturer) 으로 호스트에 박는 경로 (Re-branding) 가 자체 검증보다 훨씬 빠르다. TLS Lite 구현자에게는 후자가 보통 합리적이다.

6.5 Approved vs Allowed 알고리즘

FIPS 140-3은 알고리즘을 세 등급으로 분류한다. Approved (NIST가 승인한 알고리즘), Allowed (Approved 안에서 보조 기능으로 사용 가능한 알고리즘), Non-Approved (FIPS 모드에서 사용 금지) 이다. 표 6-4는 TLS Lite 관련 알고리즘 분류이다.

TLS Lite 봉투가 채택한 cipher suite 풀은 의도적으로 FIPS Approved 알고리즘만 사용하도록 설계되었다. 구체적으로 TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, 키 교환은 X25519 (또는 P-256 ECDHE), 서명은 ed25519 (또는 ECDSA-P-256) 이다. 단, TLS_CHACHA20_POLY1305_SHA256 는 RFC 8446에서 권장되지만 FIPS 140-3 Approved 목록에 없으므로, FIPS 모드 호스트에서는 협상되지 않아야 한다 (해당 TLS extension 자체를 막거나, 클라이언트가 제시해도 서버가 거절). 이 분기 처리는 TLS Lite Phase 2 §B.3 cipher 협상 로직에서 명시된다.

6.6 모듈 경계와 자체 시험

FIPS 140-3 검증의 출발점은 모듈 경계 (Cryptographic Module Boundary) 정의이다. 경계는 물리적 (칩·보드·박스), 논리적 (DLL·SO·라이브러리), 하이브리드 셋 중 하나로 명시되어야 한다. TLS Lite 참조 구현 wia/tls-lite-host:1.0.0은 OpenSSL 3.x FIPS provider를 채택했을 때 논리적 경계로 정의되며, 모듈 경계 안에는 cryptographic primitive (AES·SHA·HMAC·X25519·ed25519), DRBG, 자체 시험 코드, 키 저장 인터페이스가 포함된다. 봉투 직렬화·로깅·API 핸들러는 경계 외부이다.

표 6-6은 FIPS 140-3이 요구하는 자체 시험 종류와 트리거 조건이다.

POST의 핵심은 Known-Answer Test (KAT) 이다. 모듈 안에 미리 박힌 시험 벡터에 대해 알고리즘이 정확한 출력을 산출하는지를 부팅 시마다 검증한다. 아래는 TLS Lite 참조 구현이 부팅 시 수행하는 POST의 의사 코드이다.

// FIPS 140-3 Power-on Self-test (POST) 의사 코드
// TLS Lite 참조 구현 — wia/tls-lite-host:1.0.0

module_state = INITIALIZING

function fips_post():
    // 1. Pre-operational: 모듈 바이너리 무결성
    expected_hmac = "0x3F8A...C217"   // 빌드 시 박힌 값
    actual_hmac   = HMAC_SHA256(module_binary, integrity_key)
    if (actual_hmac != expected_hmac):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "integrity")
        return REFUSE_TO_START

    // 2. KAT: AES-128-GCM
    pt  = "0x00112233...EEFF"
    key = "0x00010203...0F"
    iv  = "0xCAFEBABE...01"
    ct_expected = "0xA1B2C3...D4E5"
    ct_actual   = AES_128_GCM_Encrypt(pt, key, iv)
    if (ct_actual != ct_expected):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "AES-128-GCM")
        return REFUSE_TO_START

    // 3. KAT: SHA-256
    msg = "abc"
    h_expected = "0xBA7816BF...AD15"
    h_actual   = SHA256(msg)
    if (h_actual != h_expected):
        module_state = ERROR
        emit_audit("FIPS_POST_FAIL", "SHA-256")
        return REFUSE_TO_START

    // 4. KAT: HMAC-SHA-256
    // 5. KAT: ECDSA-P-256 sign/verify
    // 6. KAT: X25519 (ECDH)
    // 7. KAT: ed25519 sign/verify
    // 8. KAT: HKDF-SHA-256
    // 9. DRBG instantiate + generate (SP 800-90A)
    // 10. Continuous DRBG 비교 시드

    module_state = OPERATIONAL
    emit_audit("FIPS_POST_OK", "all-algorithms")
    return READY

// 정상 동작 중에는 CRT가 매 키 생성마다 동작
function on_key_generation(alg):
    keypair = alg.generate()
    test_sig = alg.sign(keypair.priv, "test-vector")
    ok = alg.verify(keypair.pub, "test-vector", test_sig)
    if (!ok):
        emit_audit("FIPS_CRT_FAIL", alg)
        zeroize(keypair)
        return REFUSE_KEY
    return keypair

실패 처리의 핵심은 "Error State 진입 시 어떤 cryptographic 서비스도 응답하지 않는다"이다. 자체 시험 실패는 모듈 손상의 신호이며, 그 모듈이 계속 응답하도록 두는 것은 침해된 통신을 정상인 양 받아들이는 것과 같다. TLS Lite 봉투 클래스는 모듈 Error State 진입 시 호스트가 반환해야 할 에러 코드 (WIA-TLS-LITE-MODULE-ERROR) 를 정의하여, 운영자가 즉시 인지·차단할 수 있게 한다.

6.7 Approved 알고리즘 인벤토리 선언

FIPS 140-3 검증 패키지의 핵심 산출물 중 하나가 Security Policy 문서이다. 그 문서 안에는 모듈이 Approved 모드에서 제공하는 모든 알고리즘과 그 매개변수가 빠짐없이 열거된다. 아래는 TLS Lite 참조 구현이 Security Policy에 선언하는 인벤토리의 JSON 표현 예이다 (실제 Security Policy는 PDF 형식).

{
  "module": "WIA TLS Lite Cryptographic Module",
  "version": "1.0.0",
  "fips_140_3_level": 2,
  "validation_certificate": "PENDING-CMVP-2026Q4",
  "approved_algorithms": [
    {
      "name": "AES",
      "modes": ["GCM-128", "GCM-256"],
      "ref": "FIPS 197 + SP 800-38D",
      "cavp_cert": "A-4521"
    },
    {
      "name": "SHA-2",
      "modes": ["SHA-256", "SHA-384"],
      "ref": "FIPS 180-4",
      "cavp_cert": "A-4522"
    },
    {
      "name": "SHA-3",
      "modes": ["SHA3-256"],
      "ref": "FIPS 202",
      "cavp_cert": "A-4523"
    },
    {
      "name": "HMAC",
      "modes": ["HMAC-SHA-256"],
      "ref": "FIPS 198-1",
      "cavp_cert": "A-4524"
    },
    {
      "name": "HKDF",
      "modes": ["HKDF-SHA-256"],
      "ref": "SP 800-56C Rev. 2",
      "cavp_cert": "A-4525"
    },
    {
      "name": "ECDSA",
      "modes": ["P-256", "P-384"],
      "ref": "FIPS 186-5",
      "cavp_cert": "A-4526"
    },
    {
      "name": "X25519",
      "modes": ["ECDH-Curve25519"],
      "ref": "SP 800-186 + RFC 7748",
      "cavp_cert": "A-4527"
    },
    {
      "name": "Ed25519",
      "modes": ["sign-verify"],
      "ref": "FIPS 186-5 + RFC 8032",
      "cavp_cert": "A-4528"
    },
    {
      "name": "DRBG",
      "modes": ["HMAC-DRBG-SHA-256"],
      "ref": "SP 800-90A Rev. 1",
      "cavp_cert": "A-4529"
    }
  ],
  "non_approved_algorithms_disabled_in_fips_mode": [
    "ChaCha20-Poly1305",
    "MD5",
    "SHA-1 (signature only)",
    "3DES",
    "RC4"
  ],
  "tls_lite_cipher_suites_approved": [
    "TLS_AES_128_GCM_SHA256",
    "TLS_AES_256_GCM_SHA384"
  ],
  "tls_lite_cipher_suites_disabled_fips": [
    "TLS_CHACHA20_POLY1305_SHA256"
  ]
}

이 인벤토리는 실 모듈에 박힌 코드 경로와 1:1 정합이 입증되어야 한다. CMVP 심사자는 Security Policy에 적힌 모든 항목이 모듈 안에 실제로 존재함을, 그리고 인벤토리에 없는 알고리즘은 FIPS 모드에서 도달 불가함을 시험 보고서로 확인한다. 따라서 인벤토리의 한 줄 추가는 시험 일정의 한 달 추가로 환산되는 것이 흔하다. TLS Lite 봉투의 cipher suite 풀이 의도적으로 좁게 설계된 이유도 이 비용 구조 때문이다.

6.8 키 관리 수명주기

FIPS 140-3 § 7.9 (Sensitive Security Parameter Management) 는 키의 전체 수명주기 — 생성·합치·저장·사용·내보내기·파기 — 를 각 단계마다 명시된 통제로 보호하도록 요구한다. TLS Lite는 봉투 안에서 사용되는 세션 키 (AES-128-GCM 키), 키 교환 사설키 (X25519 priv), 서명 사설키 (ed25519 priv) 세 종류의 키를 다루며, 각각의 수명주기는 표 6-2의 Level 2 요건을 만족하도록 설계되었다.

세션 키는 매 TLS Lite 핸드셰이크마다 HKDF-Expand-Label로 새로 도출되며, 세션 종료 시 즉시 영점화된다. 영점화는 단순한 free()가 아니라 메모리에 0을 직접 기록하는 명시적 호출 (예: OpenSSL의 OPENSSL_cleanse) 로 이루어져야 하며, 컴파일러 최적화로 인해 영점화 코드가 사라지지 않도록 volatile 한정자나 memory barrier가 필요하다.

키 교환 사설키 (X25519 priv) 는 봉투 단위 ephemeral 키로 사용되어 매 봉투마다 새로 생성·파기된다 (Forward Secrecy 보장). 서명 사설키 (ed25519 priv) 는 호스트 식별자에 결합된 장기 키로, OS 키스토어 또는 HSM (Hardware Security Module) 안에 저장되며 모듈 경계를 절대 평문으로 떠나지 않는다. 모듈 경계 밖으로 내보내려면 SP 800-38F의 키 래핑 (AES Key Wrap) 으로 봉인되어야 한다.

6.9 운영 환경과 Operational Modes

FIPS 140-3은 모듈이 두 운영 모드 — Approved Mode 와 Non-Approved Mode — 를 가질 수 있도록 허용한다. 단, 두 모드의 분리가 코드로 강제되어야 하며, 운영자가 모드 전환 사실을 명시적으로 인지하고 (예: 부팅 시 로그·관리자 콘솔 표시) 모드 사이의 키·CSP가 교차 사용되지 않아야 한다. TLS Lite 참조 구현은 환경변수 WIA_TLS_LITE_FIPS_MODE=1 로 Approved Mode를 강제하며, 이 모드에서는 ChaCha20-Poly1305 cipher suite가 협상 단계에서 자동으로 제외된다.

운영 환경 자체 (Operational Environment) 도 등급별로 요건이 다르다. Level 1은 일반 OS 위에서도 허용되지만, Level 2 이상은 Common Criteria (ISO/IEC 15408) EAL2 이상으로 평가된 OS 위에서 실행되어야 한다. 한국에서는 KCC (한국공통기준) 인증을 받은 RHEL·SUSE·Tmax OS·인박스OS 등이 후보이며, KCC 인증과 미국 NIAP (National Information Assurance Partnership) 인증이 상호 인정 관계에 있는지는 사례별로 확인이 필요하다.

한국 KCMVP·암호모듈 검증 정합

한국은 국가정보원 (NIS, National Intelligence Service) 산하 IT보안인증사무국이 운영하는 KCMVP (Korea Cryptographic Module Validation Program) 를 통해 자체 암호 모듈 검증 체계를 운영한다. KCMVP는 2005년 시작되었으며, 본문 기반은 KS X ISO/IEC 19790 (정보보호기술 — 보안기법 — 암호 모듈 보안 요구사항) 이다. 운영 절차는 한국정보통신기술협회 (TTA, Telecommunications Technology Association) 와 한국인터넷진흥원 (KISA, Korea Internet & Security Agency) 시험 실험실이 분담한다.

KCMVP가 CMVP와 결정적으로 다른 점은 국내 표준 암호 알고리즘 — SEED·HIGHT·LEA·ARIA·KCDSA·EC-KCDSA·LSH·HAS-160 — 을 Approved 알고리즘으로 등재한다는 점이다. CMVP는 이 알고리즘들을 인정하지 않으므로, 미국 연방 조달과 한국 공공 조달 양쪽 시장을 동시에 노리는 벤더는 두 검증을 각각 받아야 한다. TLS Lite는 cipher suite 풀에서 AES와 SEED·ARIA를 양립시키도록 cipher 협상 로직을 분기 설계했으며, 한국 공공 시장 호스트에서는 TLS_ARIA_128_GCM_SHA256 · TLS_SEED_128_GCM_SHA256 변형이 협상 가능하다.

한국 산업계의 KCMVP 적용 사례는 다양하다. 삼성전자 Knox 보안 플랫폼은 KCMVP 인증을 받은 자체 암호 모듈을 모바일 기기에 박아 공공 시장 (국방·경찰·소방) 에 공급한다. SK텔레콤과 KT는 5G 코어망의 보안 게이트웨이 (Security Gateway, SecGW) 안에 KCMVP 모듈을 채택해, 단말 인증·세션 키 보호·로깅 무결성을 처리한다. ETRI (한국전자통신연구원) 는 양자내성 (PQC) 알고리즘의 KCMVP 등재를 위한 시험 벡터를 한국정보보호학회 (KIISC, Korea Institute of Information Security and Cryptology) 의 암호기술협의회와 공동 작성 중이다.

TLS Lite 한국 호스트 배치에서는 다음 정합 매트릭스를 권고한다. (1) 호스트 OS는 KCC 인증 OS 또는 NIAP-KCC 상호인정 OS, (2) 암호 모듈은 KCMVP L2 또는 KCMVP L3 인증 모듈, (3) cipher suite 풀은 AES + ARIA를 양립, (4) 서명 알고리즘은 ECDSA-P-256 + EC-KCDSA 양립, (5) 호스트 식별자는 한국 공인전자서명 인증서 (NPKI/GPKI) 와 결합 가능한 X.509 표면, (6) 감사 전송은 국가정보원 보안적합성 검증 (CC EAL) 요건과 정합되는 무결성 보호 로그.

6.10 검증 패키지 결선

TLS Lite Phase 4 §C.6은 운영자가 자기 호스트에 박힌 모듈의 FIPS 인증서를 봉투의 메타데이터에 첨부하는 방식을 정의한다. 봉투 안의 module_validation 객체는 인증 프로그램 식별자 (CMVP·KCMVP), 인증서 번호, 보안 등급, 인증 만료일을 담는다. 연합되는 다른 호스트가 이 메타데이터를 검사하여, 자신의 정책 (예: "Level 2 이상만 수용") 과 일치하지 않으면 봉투를 거부할 수 있다.

구현자가 본 장의 결선을 검증하는 체크리스트는 다음과 같다. (a) simulator/index.html의 cipher 패널 (#cipher) 에서 TLS_AES_128_GCM_SHA256·TLS_AES_256_GCM_SHA384·X25519·ed25519 가 Approved로 표시되는지, (b) TLS_CHACHA20_POLY1305_SHA256 가 FIPS 모드에서 Disabled로 표시되는지, (c) 모듈 부팅 시 POST 결과가 감사 로그 한 줄로 발신되는지, (d) Security Policy의 알고리즘 인벤토리가 실 코드 경로와 정합하는지, (e) KCMVP 정합이 필요한 호스트에서는 ARIA·SEED cipher suite가 추가 협상 가능한지.

본 장에서 다루는 정상 참조

• NIST FIPS 140-3 (Security Requirements for Cryptographic Modules, 2019)
• ISO/IEC 19790:2025 (Security requirements for cryptographic modules)
• ISO/IEC 24759:2025 (Test requirements for cryptographic modules)
• NIST SP 800-140A~F (CMVP Documentation Requirements)
• NIST SP 800-131A Rev. 2 (Transitioning the Use of Cryptographic Algorithms and Key Lengths)
• NIST SP 800-56A Rev. 3 / 56B Rev. 2 / 56C Rev. 2 (Key Establishment)
• NIST SP 800-90A Rev. 1 / 90B / 90C (RBG·Entropy·Construction)
• NIST SP 800-38D (GCM)
• FIPS 180-4 (Secure Hash Standard)
• FIPS 197 (AES)
• FIPS 202 (SHA-3)
• FIPS 186-5 (Digital Signature Standard)
• FIPS 198-1 (HMAC)
• CMVP Implementation Guidance (IG) for FIPS 140-3
• NIST CSRC CMVP Modules in Process List (csrc.nist.gov)
• KS X ISO/IEC 19790 (한국 정보보호기술 표준)
• IETF RFC 8446 (TLS 1.3) · RFC 9147 (DTLS 1.3) · RFC 7748 (Curve25519) · RFC 8032 (Ed25519)

구현 워크시트

1. spec/의 Phase 1 봉투 정의에서 module_validation 객체 스키마를 확인한다.
2. 호스트가 채택한 암호 모듈의 CMVP 또는 KCMVP 인증서 번호와 등급을 수집한다.
3. ./cli/tls-lite.sh envelope --fips 로 FIPS Approved Mode 봉투를 산출한다.
4. simulator/index.html#cipher 패널에서 cipher suite 풀이 FIPS 모드 정합인지 확인한다.
5. 한국 시장 호스트라면 KCMVP 인증서를 추가하고 ARIA cipher suite 협상을 활성화한다.
6. https://github.com/WIA-Official/wia-tls-lite-conformance의 §C.6 FIPS 정합 슈트를 실행한다.

표준 간 합성 요약

본 장은 TLS Lite eBook의 다른 Phase 1~4 장과 마찬가지로 WIA 표준 패밀리와 합성된다. FIPS 140-3 검증 메타데이터를 봉투에 담는 설계는 WIA-AIR-SHIELD의 신뢰 목록과 직접 합성되어, 신뢰 목록 항목이 "Level 2 이상 CMVP·KCMVP 인증 모듈" 로 자동 필터링될 수 있다. 또한 WIA-OMNI-API의 자격증명 저장이 FIPS Level 2 HSM 안에 박히도록 정합하면, 한 호스트가 한 키 체인으로 여러 WIA 표준을 동시에 운영하면서도 검증 등급을 일관되게 유지한다.

제 6 장 미주

1. NIST, FIPS 140-3: Security Requirements for Cryptographic Modules, March 22, 2019. csrc.nist.gov/publications/detail/fips/140/3/final
2. ISO/IEC 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for cryptographic modules. iso.org/standard/85940.html
3. ISO/IEC 24759:2025, Test requirements for cryptographic modules. iso.org/standard/85941.html
4. NIST CSRC, CMVP Modules In Process List. csrc.nist.gov/projects/cmvp/modules-in-process
5. NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019.
6. NIST SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, April 2018.
7. NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, August 2020.
8. NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015.
9. NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018.
10. FIPS 180-4, Secure Hash Standard (SHS), August 2015.
11. FIPS 197, Advanced Encryption Standard (AES), November 2001 (Updated May 2023).
12. FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015.
13. FIPS 186-5, Digital Signature Standard (DSS), February 2023.
14. CMVP, Implementation Guidance for FIPS 140-3. csrc.nist.gov/projects/cmvp/fips-140-3-ig-announcements
15. 국가정보원, 암호모듈 시험·검증 (KCMVP) 안내. nis.go.kr
16. GitHub: WIA-Official/wia-standards-public/tls-lite — 본 챕터 원본·정정 이력·재현 자산.