SoC 암호 IP 설계, OpenSSL 어디까지 써도 될까

🔐 SoC 암호화 엔진 IP 설계: OpenSSL 레퍼런스 활용성과 국제 표준 검증 체계

SoC 보안 IP 설계자를 위한 종합 가이드 · 2026-04-29

🧠 수석 연구원 코멘트 — OpenSSL의 crypto/ 트리는 "기능 골든(Functional Golden)"으로서는 사실상의 산업 표준입니다. 그러나 이를 그대로 RTL로 직역하면 면적·전력·부채널 방어 측면에서 심각한 손실을 봅니다. 본 보고서는 ① 레퍼런스 활용 가능 범위, ② 라이선스/특허 리스크, ③ 필수 체크리스트, ④ 국제 표준 및 골든 벡터 확보 경로를 단계적으로 정리합니다.

1. 질문의 본질 정리

사용자의 질문은 두 축으로 구성됩니다. ① OpenSSL crypto/ 디렉토리(C 코드)를 SoC 내 암호 IP 설계의 레퍼런스로 사용해도 되는가? ② 암호화 엔진 IP에서 반드시 점검해야 할 항목, 그리고 전 세계적으로 준수해야 하는 프로토콜·벡터·골든 결과값은 무엇이며 어디서 확인할 수 있는가?

이는 단순한 "코드 복붙 가능성" 문제가 아니라 다음 4차원을 모두 만족해야 하는 설계 의사결정의 문제로 다뤄야 합니다.

▶ 4가지 검토 차원
  ① 알고리즘 정확성 (Functional Correctness)
  ② 라이선스·특허 안전성 (Legal Safety)
  ③ 하드웨어 보안 강건성 (HW Security Robustness)
  ④ 인증 가능성 (Certifiability)

2. OpenSSL crypto/ 트리의 성격과 활용 적합성

2.1 무엇이 들어 있는가

OpenSSL의 crypto/ 디렉토리에는 AES, SHA-2/3, RSA, ECC(P-256/P-384), Ed25519, ChaCha20-Poly1305, HKDF 등의 알고리즘 구현과 EVP·ASN.1·BIO 등의 프레임워크가 함께 존재합니다. 또한 x86 AES-NI, ARMv8 Crypto Extension/NEON을 활용하는 어셈블리 변형(perlasm 기반)이 다수 포함되어 있어, "참고용 C 코드"라고 단정짓기 어려운 다중 백엔드 구조를 갖습니다.

2.2 레퍼런스로서의 강점·한계 비교

🟢 강점 — Functional Golden	🔴 한계 — Architectural Mismatch
수십 년 검증: 엣지 케이스 처리가 사실상 표준	순차 vs 병렬: C 루프를 RTL 직역 시 throughput 1/10 수준
모드 다양성: GCM/CCM/XTS/CMAC/PSS/EdDSA 망라	메모리 모델 차이: T-table 직역 시 면적·타이밍 SCA 노출
자체 KAT 보유: NIST KAT 전 단계 빠른 회귀 검증	SCA 방어 부재: DPA/EMA/Fault Injection 보호 없음

🟡 결론 (2단원): OpenSSL은 알고리즘 정답(reference model) 및 골든 벡터 생성기로 채택하되, 마이크로아키텍처·SCA 방어 설계의 레퍼런스로는 부적합합니다.

3. 라이선스·특허 리스크 — Apache License 2.0 기반 IP 출하 가능성

OpenSSL 3.0 이후 Apache License 2.0이 적용되며, 하드웨어 IP화에도 다음 조항이 적용됩니다.

조항	하드웨어 IP 관점에서의 의미
§2 Copyright Grant	C 코드를 RTL/넷리스트로 변환해 배포 가능. 단, "Derivative Works"로 간주됨
§3 Patent Grant	기여자 보유 특허 사용 허여. SoC 벤더 입장에서 특허 분쟁 리스크 완화의 핵심
§4 Redistribution	IP 패키지 재배포 시 ① 라이선스 사본, ② 저작권 고지, ③ NOTICE 보존 의무
§7 Warranty 면책	설계 결함 책임은 IP 제공자 귀속. 검증·인증은 자체 책임

즉, OpenSSL 코드를 직접 합성용 SystemVerilog로 변환해 IP화하는 것은 법적으로는 허용되나, 실무적으로는 ① 코드 출처 추적 가능성, ② NOTICE 문서화, ③ 후속 보안 픽스의 재반영 절차를 사내 SDLC에 포함시켜야 합니다.

4. 암호 IP가 반드시 통과해야 할 설계 체크리스트

암호 IP는 4개 영역의 검증을 동시에 통과해야 합니다. 각 영역의 비중을 시각화하면 다음과 같습니다.

기능 정합성 25% — KAT, 엣지 케이스

성능·물리(PPA) 20% — Throughput, 면적, 전력

보안(SCA·FI·키 보호) 35% — 가장 중요

인터페이스·기능 안전 20% — AMBA, ISO 26262

4.1 기능적 정합성

✓ 알고리즘별 KAT 통과: AES, SHA-2/3, HMAC, ECDSA, RSA, DRBG 각각의 NIST 공식 KAT (§6.2)
✓ Edge case 처리: AES-GCM의 IV 길이 0/96/임의, AAD 없는 경우, 빈 평문, 최대 메시지 길이
✓ DRBG 재초기화: 재시드(reseed) 카운터, 예측 저항(prediction resistance) 모드

4.2 성능·물리(PPA)

▶ Throughput / Latency: AES-GCM 100 Gbps급은 라운드 언롤 + 16-way 파이프라인 필요
▶ Gate count, 누설/동적 전력: IoT/모바일 SoC에서 결정적
▶ 클럭 도메인 / 백프레셔 제어: AXI/AHB stream에서의 stall, in-flight 명령 수

4.3 보안 — 가장 결정적인 차원

🔴 부채널 방어: SPA/DPA/CPA, EMA, 캐시 타이밍, 분기 타이밍
🔴 고장 주입(Fault Injection) 대응: 듀얼 레일(double rail), 중복 연산, 시그니처 검사
🔴 키 라이프사이클 보호: OTP/eFuse → Key Ladder → Crypto Core 직결, 시스템 버스에 평문 키 노출 금지
🔴 TRNG/CSRNG: NIST SP 800-90A(DRBG), 90B(엔트로피), 90C(구성) 준수

4.4 인터페이스·기능 안전

• AMBA 호환성, secure/non-secure transaction 분리(TrustZone 등)
• 자동차/산업용일 경우 ISO 26262(ASIL) 또는 IEC 61508과의 정합

5. 부채널·평가 표준 한눈에 보기

표준	대상	비고
ISO/IEC 17825:2023	비침습 공격(DPA, SPA, EMA) 완화 테스트 방법론	FIPS 140-3 Level 3/4 SCA 테스트 근거
ISO/IEC 20085-1/2	SCA 테스트 도구·캘리브레이션 표준	Lab-grade 측정 환경 정의
ISO/IEC 15408 (Common Criteria)	보안 제품 일반 평가	EAL4+ ~ EAL6+. 금융·국방용 EAL5+
BSI AIS-31, AIS-46	TRNG/PTG 평가	독일 BSI 기준, 유럽 시장 진입 시 필수

6. 국제 표준·인증 체계와 골든 결과값

6.1 검증 파이프라인 — RTL부터 ACVP까지

6.2 인증 트랙

▶ FIPS 140-3 (NIST/CSE 공동 운영): 미국·캐나다 정부 조달용 사실상 필수. Level 1~4. SoC 임베디드 모듈은 통상 Level 2/3 타깃, 물리 변조 방어 강한 경우 Level 4. 기반 표준은 ISO/IEC 19790.

▶ Common Criteria EAL4+/5+: 스마트카드·HSM·자동차 SE에 사용. EAL5는 "Semi-formally designed and tested" 단계.

▶ KCMVP (한국): SEED, ARIA, LEA, HIGHT, HAS-160 등 국내 알고리즘에 대한 별도 KAT 요구. 글로벌 IP라도 한국 시장 진입 시 참고 필요.

6.3 알고리즘 검증 — CAVP에서 ACVP로 완전 전환

NIST는 과거의 수동 KAT 제출 방식(CAVP)에서 ACVP(Automated Cryptographic Validation Protocol)로 전면 이행했으며, 2024년 이후 신규 검증은 ACVP 기반으로만 접수됩니다.

• ▶ ACVP 포털: https://pages.nist.gov/ACVP/ — 서버에 JSON으로 입력 벡터를 요청하고 IP/모듈 응답을 NIST가 자동 채점
• ▶ 검증 이력 검색: CAVP Validation Search — Vendor/Module/알고리즘 단위 필터링

6.4 대표 알고리즘별 골든 벡터(KAT) 확보 경로

알고리즘 / 모드	사양서	공식 KAT 위치
AES (ECB/CBC/CFB/OFB/CTR)	FIPS 197 + SP 800-38A	Block Cipher Modes
AES-GCM/GMAC	SP 800-38D	gcmtestvectors.zip
AES-CCM	SP 800-38C	동일 페이지
AES-XTS	SP 800-38E	동일 페이지
SHA-1/2/3, SHAKE	FIPS 180-4, FIPS 202	Secure Hashing
HMAC	FIPS 198-1	Message Authentication
RSA(서명/암호화)	FIPS 186-4/5, SP 800-56B	Digital Signatures
ECDSA / EdDSA	FIPS 186-5	동일 페이지
DRBG	SP 800-90A Rev.1	RNG
엔트로피 소스	SP 800-90B	동일 페이지

🟡 실무 팁: AES-GCM의 경우 NIST gcmEncryptIntIVPCxxxxx.rsp / gcmDecrypt256.rsp 파일이 IV 생성 모드(Internal/External)와 키 길이별로 분리되어 있습니다. RTL 회귀 환경에서 OpenSSL EVP_aead_aes_*_gcm 결과와 NIST KAT가 모두 일치하는지 이중 확인하는 흐름이 표준 관행입니다.

6.5 산업계 대표 인증 IP 사례

벤더 / IP	포지셔닝
ARM CryptoCell-71x	"FIPS 140-3 ready" 설계, TEE 연동
Synopsys DesignWare tRoot HSM	FIPS 140-3 Level 3 대응 RoT IP
Rambus(구 Inside Secure)	FIPS 140-3 Level 2/3 인증 사례 다수

이들은 OpenSSL을 알고리즘 골든으로 사용하되, 자체 마이크로아키텍처·SCA 방어·키 보호 메커니즘을 별도로 설계한 전형적인 사례입니다.

7. 라운드 간 모순 점검

본 리서치의 1·2라운드 사이에 직접적인 사실 충돌은 발견되지 않았습니다. 다만 다음 두 지점은 표현상 보완이 필요해 명시합니다.

▶ CAVP vs ACVP: 1라운드는 "CAVP가 ACVP로 전환되었다"고만 기술했고, 2라운드에서 "2024년 이후 신규 검증은 사실상 ACVP만 접수"임을 보강. 모순은 아니며 후자가 더 구체적.

▶ OpenSSL 라이선스: 1라운드는 라이선스를 다루지 않았고, 2라운드가 Apache 2.0 의무 사항을 추가. 새로운 정보의 추가이지 충돌은 아님.

8. 결론 및 실행 권고

실무 의사결정 우선순위를 시각화하면 다음과 같습니다.

① 역할 분리 (Golden vs RTL)

최우선

② 부채널 방어 명문화

필수

③ 인증 로드맵 조기 확정

조기

④ 검증 이중·삼중화

표준

⑤ 라이선스 SDLC 통합

상시

8.1 5대 실행 권고

① 레퍼런스 채택은 OK, 단 역할을 명확히 분리하라
  • OpenSSL crypto/ ⇒ 알고리즘 골든 모델 / 회귀용 KAT 생성기
  • 마이크로아키텍처·SCA 방어 ⇒ 별도 설계 트랙(논문, FIPS/CC 평가 보고서, 사내 SCA 랩 데이터)

② 라이선스·특허 트랙을 SDLC에 포함하라
  • Apache 2.0 NOTICE/Attribution 절차를 IP 출하 패키지에 자동 삽입
  • OpenSSL 보안 픽스 모니터링 채널을 설계 변경 트리거로 등록

③ 검증은 이중·삼중으로
  • ① OpenSSL self-test → ② NIST 공식 KAT(*.rsp) → ③ ACVP 자동 채점
  • 세 단계 모두 통과해야 출하 가능으로 정의

④ 인증 로드맵을 초기에 결정하라
  • 타깃 시장에 따라 FIPS 140-3 Level, CC EAL, KCMVP, BSI AIS-31 적용 여부를 아키텍처 결정 단계에서 확정
  • ROM/eFuse 영역, 키 래더, RNG 토폴로지가 후행 변경되지 않도록

⑤ 부채널 방어를 1차 요구사항으로 명문화하라
  • ISO/IEC 17825:2023 시험 항목을 사내 검증 체크리스트로 매핑
  • DPA/EMA 측정 결과를 설계 회의의 정기 안건으로 둔다

🧠 한 줄 정리
OpenSSL은 SoC 암호 IP의 "두뇌의 정답지"로서 가장 신뢰할 만한 레퍼런스입니다. 그러나 IP가 "몸통과 갑옷"까지 갖추려면 NIST SP 800 시리즈, FIPS 140-3, ISO/IEC 19790·17825, Common Criteria 같은 국제 표준이 동등 비중으로 결합되어야 하며, 이 모든 검증을 자동화하는 핵심 도구가 NIST ACVP입니다.

📚 References

• ▶ OpenSSL Documentation
• ▶ OpenSSL License (Apache 2.0)
• ▶ Apache License Version 2.0
• ▶ NIST CAVP Validation Search
• ▶ NIST ACVP Portal
• ▶ NIST CAVP Block Cipher Modes (AES-GCM KAT)
• ▶ NIST SP 800 Series
• ▶ ISO/IEC 17825:2023
• ▶ Common Criteria Portal
• ▶ ARM Security IP
• ▶ Synopsys DesignWare tRoot HSM
• ▶ Rambus Security IP

본 보고서는 SoC 암호화 엔진 IP 설계자를 위한 기술·표준 가이드입니다. 실제 인증 진행 시에는 최신 NIST·ISO 문서와 인증 기관의 공식 안내를 확인하시기 바랍니다.

📄 Raw Data

# SoC 암호화 엔진 IP 설계: OpenSSL 레퍼런스 활용성과 국제 표준 검증 체계 종합 분석

> **수석 연구원 코멘트** — OpenSSL의 `crypto/` 트리는 "기능 골든(Functional Golden)"으로서는 사실상의 산업 표준이지만, 이를 그대로 RTL로 직역하면 면적·전력·부채널 방어 측면에서 심각한 손실을 봅니다. 본 보고서는 (1) 레퍼런스 활용 가능 범위, (2) 라이선스/특허 리스크, (3) 필수 체크리스트, (4) 국제 표준 및 골든 벡터 확보 경로를 단계적으로 정리합니다.

---

## 1. 질문의 본질 정리

사용자의 질문은 두 축으로 구성됩니다.
1. **OpenSSL `crypto/` 디렉토리(C 코드)를 SoC 내 암호 IP 설계의 레퍼런스로 사용해도 되는가?**
2. **암호화 엔진 IP에서 반드시 점검해야 할 항목, 그리고 전 세계적으로 준수해야 하는 프로토콜/벡터/골든 결과값은 무엇이며 어디서 확인할 수 있는가?**

이는 단순한 "코드 복붙 가능성" 문제가 아니라 **(a) 알고리즘 정확성**, **(b) 라이선스/특허 안전성**, **(c) 하드웨어 보안 강건성**, **(d) 인증 가능성** 네 가지 차원을 모두 만족해야 하는 설계 의사결정의 문제로 다뤄야 합니다.

---

## 2. OpenSSL `crypto/` 트리의 성격과 활용 적합성

### 2.1 무엇이 들어 있는가
OpenSSL의 `crypto/` 디렉토리에는 AES, SHA-2/3, RSA, ECC(P-256/P-384), Ed25519, ChaCha20-Poly1305, HKDF 등의 알고리즘 구현과 EVP·ASN.1·BIO 등의 프레임워크가 함께 존재합니다. 또한 x86 AES-NI, ARMv8 Crypto Extension/NEON 등을 활용하는 **어셈블리 변형(perlasm 기반)** 이 다수 포함되어 있어, "참고용 C 코드"라고 단정짓기 어려운 다중 백엔드 구조를 갖습니다(출처: [OpenSSL Documentation](https://www.openssl.org/docs/)).

### 2.2 레퍼런스로서의 강점 — "Functional Golden"
- **수십 년의 검증**: 알고리즘의 엣지 케이스(IV 길이, 패딩, 비표준 파라미터 등) 처리가 사실상 표준이며, 시뮬레이션 단계의 정답 비교 기준으로 가장 신뢰할 수 있습니다.
- **모드 다양성**: AES-GCM/CCM/XTS/CMAC, RSA-OAEP/PSS, ECDSA/EdDSA 등 운영 모드의 데이터 흐름을 한 코드베이스에서 직접 확인할 수 있어, RTL 설계 시 **상태 머신 분해의 시발점**으로 유용합니다.
- **자체 KAT 보유**: `test/recipes/`와 `test/evp_test_data/` 등에 존재하는 테스트 벡터를 사용하면 NIST 공식 KAT을 받기 전 단계의 빠른 회귀 검증이 가능합니다.

### 2.3 레퍼런스로서의 한계 — "Architectural Mismatch"
- **순차 vs 병렬**: C 루프 구조는 라운드 함수 내 SubBytes/ShiftRows/MixColumns/AddRoundKey를 순차 호출합니다. 하드웨어는 한 클럭에 라운드 전체 또는 일부를 병렬·파이프라인 처리해야 throughput 목표를 달성합니다. 직역 시 성능이 1/10 이하로 떨어지는 사례가 흔합니다.
- **메모리/면적 모델 차이**: 대용량 S-Box LUT 참조 방식은 SW에서는 캐시 친화적이지만, RTL에서는 **타이밍 사이드 채널**과 **면적 폭증**의 원인이 됩니다. T-table 기반 구현을 그대로 옮기면 안 됩니다.
- **부채널 방어 부재**: OpenSSL은 일부 SW 측 constant-time 보호(예: BN_consttime, EC scalar mult)는 갖췄으나, **DPA/EMA/Fault Injection** 등 하드웨어 사이드 채널 방어 로직(Boolean/Arithmetic Masking, Hiding, Threshold Implementation)은 제공하지 않습니다. 이는 설계자가 별도로 추가해야 하는 영역입니다(관련 표준은 §5 참조).

> **결론(2단원)**: OpenSSL은 **알고리즘 정답(reference model) 및 골든 벡터 생성기**로 채택하되, **마이크로아키텍처/SCA 방어 설계의 레퍼런스로는 부적합**합니다.

---

## 3. 라이선스·특허 리스크 — Apache License 2.0 기반 IP 출하 가능성

OpenSSL 3.0 이후 Apache License 2.0이 적용되며, 하드웨어 IP화에도 다음과 같이 적용됩니다(출처: [OpenSSL License](https://www.openssl.org/source/license.html), [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0)).

| 조항 | 하드웨어 IP 관점에서의 의미 |
|------|------------------------------|
| **Section 2 (Copyright Grant)** | C 코드를 RTL/넷리스트로 변환해 배포 가능. 단, "Derivative Works"로 간주됨. |
| **Section 3 (Patent Grant)** | 기여자가 보유한 특허에 대한 사용 허여. SoC 벤더 입장에서 특허 분쟁 리스크를 낮추는 핵심 조항. |
| **Section 4 (Redistribution)** | IP 패키지 재배포 시 (a) 라이선스 사본, (b) 저작권 고지, (c) 원본 `NOTICE` 내용 보존 의무. |
| **Section 7 (Warranty 면책)** | 설계 결함에 따른 책임은 IP 제공자에게 귀속. 검증·인증은 자체 책임. |

따라서 OpenSSL 코드를 직접 합성용 SystemVerilog로 변환해 IP화하는 것은 **법적으로는 허용**되나, 실무적으로는 (i) 코드 출처 추적 가능성, (ii) NOTICE 문서화, (iii) 후속 알고리즘 패치(예: `crypto/evp` 보안 픽스)의 재반영 절차를 사내 SDLC에 포함시켜야 합니다.

---

## 4. 암호 IP가 반드시 통과해야 할 설계 체크리스트

### 4.1 기능적 정합성
1. **알고리즘별 KAT 통과**: AES, SHA-2/3, HMAC, ECDSA, RSA, DRBG 각각의 NIST 공식 KAT. (§6.2)
2. **Edge case 처리**: AES-GCM의 IV 길이 0/96/임의 길이, AAD 없는 경우, 빈 평문, 최대 메시지 길이.
3. **DRBG 재초기화**: 재시드(reseed) 카운터, 예측 저항(prediction resistance) 모드.

### 4.2 성능·물리(PPA)
1. **Throughput / Latency**: 목표 데이터 레이트 (예: AES-GCM 100 Gbps급은 라운드 언롤 + 16-way 파이프라인 필요).
2. **Gate count, 누설/동적 전력**: IoT/모바일 SoC에서 결정적.
3. **클럭 도메인 / 백프레셔 제어**: AXI/AHB stream 인터페이스에서의 stall, in-flight 명령 수.

### 4.3 보안(필수)
1. **부채널 방어**: SPA/DPA/CPA, EMA, 캐시 타이밍, 분기 타이밍.
2. **고장 주입(Fault Injection) 대응**: 듀얼 레일(double rail), 중복 연산, 시그니처 검사.
3. **키 라이프사이클 보호**: OTP/eFuse → Key Ladder → Crypto Core 직결, 키가 SoC 시스템 버스에 평문으로 노출되지 않도록 설계.
4. **TRNG/CSRNG**: NIST SP 800-90A(DRBG), 800-90B(엔트로피 소스), 800-90C(구성) 준수. ([NIST SP 800-90 시리즈](https://csrc.nist.gov/publications/sp))

### 4.4 인터페이스·기능 안전(해당 시)
- AMBA 호환성, secure/non-secure transaction 분리(TrustZone 등).
- 자동차/산업용일 경우 ISO 26262(ASIL) 또는 IEC 61508과의 정합.

---

## 5. 부채널·평가 표준

| 표준 | 대상 | 비고 |
|------|------|------|
| **ISO/IEC 17825:2023** | 비침습 공격(DPA, SPA, EMA) 완화 테스트 방법론 | FIPS 140-3 보안레벨 3/4의 SCA 테스트 근거로 채택. ([ISO/IEC 17825:2023](https://www.iso.org/standard/83677.html)) |
| **ISO/IEC 20085-1/2** | SCA 테스트 도구·캘리브레이션 표준 | Lab-grade 측정 환경 정의 |
| **Common Criteria (ISO/IEC 15408)** | 보안 제품 일반 평가 | EAL4+ ~ EAL6+. 금융·국방용은 통상 EAL5+ 이상. ([CC Portal](https://www.commoncriteriaportal.org/products/)) |
| **BSI AIS-31, AIS-46** | TRNG/PTG 평가 | 독일 BSI 기준, 유럽 시장 진입 시 자주 요구 |

---

## 6. 국제 표준·인증 체계와 골든 결과값

### 6.1 인증 트랙
- **FIPS 140-3** (NIST/CSE 공동 운영): 미국·캐나다 정부 조달용 사실상 필수. Level 1~4. SoC 내 임베디드 암호 모듈은 통상 Level 2/3 타깃, 물리 변조 방어가 강한 경우 Level 4 추구. 기반 표준은 **ISO/IEC 19790**.
- **Common Criteria EAL4+/5+**: 스마트카드·HSM·자동차 SE에 사용. EAL5는 "Semi-formally designed and tested" 단계.
- **국내**: KCMVP(한국 암호모듈 검증제도)는 SEED, ARIA, LEA, HIGHT, HAS-160 등 국내 알고리즘에 대한 별도 KAT를 요구 — 글로벌 IP라도 한국 시장 진입 시 참고가 필요합니다.

### 6.2 알고리즘 검증 — CAVP에서 ACVP로 완전 전환
NIST는 과거의 수동 KAT 제출 방식(CAVP)에서 **ACVP(Automated Cryptographic Validation Protocol)** 로 전면 이행했으며, 2024년 이후 신규 검증은 ACVP 기반으로만 접수됩니다.

- ACVP 포털: [https://pages.nist.gov/ACVP/](https://pages.nist.gov/ACVP/) — 서버에 JSON으로 입력 벡터를 요청하고, 대상 IP/모듈이 응답한 결과값을 NIST가 자동 채점합니다.
- 검증 이력 검색: [NIST CAVP Validation Search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search) — Vendor/Module/알고리즘 단위 필터링 가능, 2024~2025년 최신 인증 사례 확인 용도로 적합.

### 6.3 대표 알고리즘별 골든 벡터(KAT) 확보 경로

| 알고리즘 / 모드 | 사양서(SP/FIPS) | 공식 KAT 위치 |
|-----------------|----------------|---------------|
| AES (ECB/CBC/CFB/OFB/CTR) | FIPS 197 + SP 800-38A | [Block Cipher Modes](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/block-cipher-modes) |
| AES-GCM/GMAC | SP 800-38D | 동일 페이지의 `gcmtestvectors.zip` |
| AES-CCM | SP 800-38C | 동일 페이지 |
| AES-XTS | SP 800-38E | 동일 페이지 |
| SHA-1/2/3, SHAKE | FIPS 180-4, FIPS 202 | [Secure Hashing](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/secure-hashing) |
| HMAC | FIPS 198-1 | [Message Authentication](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/message-authentication) |
| RSA(서명/암호화) | FIPS 186-4/5, SP 800-56B | [Digital Signatures](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/digital-signatures) |
| ECDSA / EdDSA | FIPS 186-5 | 동일 페이지 |
| DRBG | SP 800-90A Rev.1 | [Random Number Generation](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/random-number-generators) |
| 엔트로피 소스 | SP 800-90B | 동일 페이지 |

> **실무 팁**: AES-GCM의 경우 NIST `gcmEncryptIntIVPCxxxxx.rsp` / `gcmDecrypt256.rsp` 파일이 IV 생성 모드(Internal/External)와 키 길이별로 분리되어 있습니다. RTL 회귀 환경에서 OpenSSL의 `EVP_aead_aes_*_gcm` 결과와 NIST KAT가 모두 일치하는지 **이중 확인**하는 흐름이 표준 관행입니다.

### 6.4 산업계 대표 인증 IP 사례(Round 2 자료)
- **ARM CryptoCell-71x** — "FIPS 140-3 ready" 설계, TEE 연동.
- **Synopsys DesignWare tRoot HSM** — FIPS 140-3 Level 3 대응 RoT IP.
- **Rambus(구 Inside Secure) CryptoMedia/Vault** — FIPS 140-3 Level 2/3 인증 사례 다수.
이들은 OpenSSL을 알고리즘 골든으로 사용하되, 자체 마이크로아키텍처/SCA 방어/키 보호 메커니즘을 별도로 설계한 전형적인 사례입니다(출처: [ARM Security IP](https://www.arm.com/products/silicon-ip-security), [Synopsys tRoot](https://www.synopsys.com/dw/ipdir.php?ds=troot-hsm), [Rambus Security](https://www.rambus.com/security/)).

---

## 7. 라운드 간 모순 점검

본 리서치의 1·2라운드 사이에 직접적인 사실 충돌은 발견되지 않았습니다. 다만 다음 두 지점은 표현상 보완이 필요해 명시합니다.

- **CAVP vs ACVP**: 1라운드는 "CAVP가 ACVP로 전환되었다"고만 기술했고, 2라운드에서 "2024년 이후 신규 검증은 사실상 ACVP만 접수"임을 보강했습니다. 모순은 아니며 후자가 더 구체적입니다.
- **OpenSSL 라이선스**: 1라운드는 라이선스를 다루지 않았고, 2라운드가 Apache 2.0 의무 사항을 추가했습니다. 새로운 정보의 추가이지 충돌은 아닙니다.

---

## 8. 결론 및 실행 권고

1. **레퍼런스 채택은 OK, 단 역할을 명확히 분리하라.**
   - OpenSSL `crypto/` ⇒ **알고리즘 골든 모델 / 회귀용 KAT 생성기**.
   - 마이크로아키텍처·SCA 방어 ⇒ **별도 설계 트랙**(논문, FIPS/CC 평가 보고서, 사내 SCA 랩 데이터 활용).
2. **라이선스·특허 트랙을 SDLC에 포함하라.** Apache 2.0 NOTICE/Attribution 절차를 IP 출하 패키지에 자동 삽입하고, OpenSSL 보안 픽스 모니터링 채널(security-announce, GitHub `master`)을 설계 변경 트리거로 등록.
3. **검증은 이중·삼중으로.** ① OpenSSL self-test, ② NIST 공식 KAT(`*.rsp`), ③ ACVP 자동 채점 — 세 단계를 모두 통과해야 출하 가능으로 정의.
4. **인증 로드맵을 초기에 결정하라.** 타깃 시장에 따라 FIPS 140-3 Level, CC EAL, KCMVP, BSI AIS-31 적용 여부를 아키텍처 결정 단계에서 확정해 ROM/eFuse 영역, 키 래더, RNG 토폴로지가 후행 변경되지 않도록 한다.
5. **부채널 방어를 1차 요구사항으로 명문화하라.** ISO/IEC 17825:2023 시험 항목을 사내 검증 체크리스트로 매핑하고, DPA/EMA 측정 결과를 설계 회의의 정기 안건으로 둔다.

요약하면, OpenSSL은 SoC 암호 IP의 **"두뇌의 정답지"** 로서 가장 신뢰할 만한 레퍼런스입니다. 그러나 IP가 **"몸통과 갑옷"** 까지 갖추려면 NIST SP 800 시리즈, FIPS 140-3, ISO/IEC 19790·17825, Common Criteria 같은 국제 표준이 동등 비중으로 결합되어야 하며, 이 모든 검증을 자동화하는 핵심 도구가 NIST ACVP입니다.
---

## References

- [OpenSSL Documentation](https://www.openssl.org/docs/)
- [OpenSSL License (Apache 2.0)](https://www.openssl.org/source/license.html)
- [Apache License Version 2.0](https://www.apache.org/licenses/LICENSE-2.0)
- [NIST CAVP Validation Search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search)
- [NIST ACVP Portal](https://pages.nist.gov/ACVP/)
- [NIST CAVP Block Cipher Modes (AES-GCM KAT)](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/block-cipher-modes)
- [NIST SP 800 Series](https://csrc.nist.gov/publications/sp)
- [ISO/IEC 17825:2023](https://www.iso.org/standard/83677.html)
- [Common Criteria Portal](https://www.commoncriteriaportal.org/products/)
- [ARM Security IP](https://www.arm.com/products/silicon-ip-security)
- [Synopsys DesignWare tRoot HSM](https://www.synopsys.com/dw/ipdir.php?ds=troot-hsm)
- [Rambus Security IP](https://www.rambus.com/security/)