SoC 암호 IP 검증의 황금률 — Golden Reference 완전 가이드
📅 2026-05-19 · 🔐 암호 알고리즘 · 🧪 RTL 검증 · 🏛️ NIST / XKCP / OpenSSL
AES, SHA-2/3, HMAC/KMAC, RSA 같은 암호 IP를 SoC에 내장할 때 가장 먼저 부딪히는 질문은 단순합니다. "이 RTL이 비트 단위로 옳다는 걸 어떻게 증명하지?" 정답은 검증 가능한 SW 기준 모델, 즉 Golden Reference와 표준 기관이 공인한 테스트 벡터의 조합입니다. 단, NIST CAVP 벡터를 통과하는 건 출발점일 뿐, 실제 디버깅에서 결정타를 날리는 건 중간값(Intermediate Values)이 노출되는 깨끗한 C 레퍼런스입니다. 본 가이드는 알고리즘별 표준, 레퍼런스 후보의 위상과 신뢰도, 확보 위치, 필수 테스트 벡터, 그리고 OpenSSL Wrapper의 결정적 함정까지 한 번에 정리합니다.
🧭 검증 워크플로우 — 한눈에 보는 전체 흐름
암호 RTL 검증은 결국 "표준 명세 → 골든 C 코드 → 테스트 벡터 → DPI-C 비교 → 회귀 자동화" 5단계의 사슬입니다. 어느 한 단계라도 추측에 의존하면 비트 단위 정합성은 무너집니다.
flowchart TD
A([FIPS 표준 명세]) --> B[Golden C 레퍼런스
NIST · XKCP · Fiat]
B --> C[테스트 벡터
KAT · MCT · ACVP JSON]
C --> D{DPI-C 라운드
중간값 일치?}
D -->|YES| E([RTL 검증 통과])
D -->|NO| F[버그 위치 추적
State 비교]
style A fill:#3498db,stroke:#2980b9,color:#ffffff
style B fill:#e8f8f5,stroke:#16a085
style C fill:#fef9e7,stroke:#f39c12
style D fill:#fef9e7,stroke:#f39c12
style E fill:#eafaf1,stroke:#27ae60,color:#1e8449
style F fill:#fdedec,stroke:#e74c3c,color:#c0392b
🔁 다이어그램 요약: FIPS 명세에서 출발한 Golden C 코드가 KAT·MCT·ACVP JSON 벡터를 통과하고, DPI-C로 RTL과 라운드별 중간값을 비교해 일치하면 검증 통과, 불일치 시 State 단위로 버그 위치를 역추적한다.
📚 1. 알고리즘별 표준과 Golden Reference 맵
알고리즘마다 "사실상 표준"으로 통하는 레퍼런스 후보가 다릅니다. SHA-3·KMAC은 Keccak 팀의 XKCP, AES·RSA는 산업 컴플라이언스 측면에서 OpenSSL이 기준이지만, RTL 비교용 골든으로 OpenSSL을 그대로 쓰면 위험합니다. 그 이유는 뒷부분에서 다룹니다.
| 알고리즘 |
표준 문서 |
1순위 Golden |
Oracle 후보 |
| AES |
FIPS 197 |
Rijndael C + NIST Intermediate Values |
OpenSSL (AES-NI 차단 빌드) |
| SHA-2 |
FIPS 180-4 |
NIST C Reference Code |
OpenSSL EVP_Digest* |
| SHA-3 / SHAKE |
FIPS 202 |
XKCP `ref` (Keccak 팀) |
OpenSSL 3.x |
| HMAC |
FIPS 198-1 |
NIST 예제 + OpenSSL HMAC() |
PyCryptodome (보조) |
| KMAC |
SP 800-185 |
XKCP (cSHAKE 포함) |
OpenSSL 3.0+ KMAC EVP |
| RSA |
FIPS 186-4 (→ 186-5) |
OpenSSL bignum + NIST 예제 |
Fiat-Crypto (수학적 증명) |
💡 핵심: SHA-3·KMAC은 XKCP가 곧 표준, AES·RSA는 OpenSSL이 산업 기준입니다. 하지만 RTL 비교용 골든 모델로는 OpenSSL이 부적합할 수 있다는 점이 본 가이드의 핵심 통찰입니다.
📥 2. 어디서 받을 수 있는가 — 확보 위치 카탈로그
🏛️ 2.1 NIST 공식 (1순위, 무조건 확보)
▶ CSRC 프로젝트 페이지의 알고리즘별 "Examples with Intermediate Values" PDF는 AES 각 라운드 후 16바이트 State, SHA-256 메시지 스케줄 W[t], Keccak θ/ρ/π/χ/ι 각 스텝 결과가 바이트 단위로 적혀 있어 RTL 파형과 1:1 비교가 가능합니다.
▶ CAVP 레거시 ZIP/RSP: AES(AESAVS), SHS(SHA-2), SHA-3, RSA(RSA2VS) — 알고리즘별로 KAT·MCT·MMT 벡터 수만 줄이 들어 있는 텍스트 묶음.
▶ ACVP (최신 JSON 표준): NIST가 RSP에서 JSON으로 전환 중. UVM/Python 테스트벤치 파싱이 훨씬 쉬워 신규 프로젝트는 ACVP JSON 우선이 권장됩니다.
🔑 2.2 XKCP — SHA-3 / KMAC 사실상 표준
저장소는 github.com/XKCP/XKCP. Keccak 설계자 Bertoni, Daemen, Peeters, Van Assche가 직접 유지보수하는 코드로, FIPS 202 및 SP 800-185 구현 중 최고 신뢰도입니다.
활용 원칙: `ref` 폴더만 골든 모델로 쓰고, AVX-512/ARMv8 최적화 폴더는 성능 비교용으로만. 어셈블리 최적화는 RTL과 구조가 달라 디버깅 가치가 떨어집니다.
⚠️ 2.3 OpenSSL — Oracle / Wrapper 용도 (Golden 부적합 주의)
FIPS 140-3 인증 현황: 모듈 #4985(2025-03-11, OpenSSL 3.1.2)가 현재 가장 권장. 모듈 #4811(2024-09-24)이 첫 FIPS 140-3, OpenSSL 3.5.4(2025-10-09 제출)는 PQC 포함 차세대 모듈로 인증 검토 중.
함정: EVP_EncryptInit 호출 시 런타임에 AES-NI/VAES/AVX-512 분기로 가버립니다. "내가 만든 RTL과 동일한 알고리즘 흐름을 따르는가"를 보장하지 않으므로, RTL 비교는 항상 FIPS 197 순수 명세 기반 C 레퍼런스로.
🛠️ 2.4 보조 도구 — Wycheproof · AWS-LC · Fiat-Crypto
▶ Wycheproof (Google → C2SP 이관): 실행 Harness 제거되어 JSON 벡터 직접 파싱하는 보조 도구로 위치 변경. 잘못된 패딩·약한 키·비정상 길이 등 에지 케이스 검증에 필수.
▶ AWS-LC: BoringSSL 포크 + FIPS 지원. 고성능·최신 PQC + 컴플라이언스를 동시에 원할 때.
▶ BoringSSL: Google 내부용. 외부 FIPS 지원 없음 — SoC 컴플라이언스 용도로 권장하지 않음.
▶ Fiat-Crypto: 수학적으로 정확함이 증명된 RSA/ECC bignum 코드 생성. RSA Golden Reference의 최고 신뢰 옵션.
📊 3. 골든 후보 신뢰도 비교
RTL 비교 적합성, 표준 권위, 디버깅 편의(중간값 노출), 자동화 친화(JSON·DPI-C) 4가지 축에서 후보들을 비교하면 다음과 같습니다.
※ 점수는 본 가이드의 정성적 평가 — RTL 비교 적합성 + 표준 권위 + 디버깅 편의 종합
🧪 4. 필수 테스트 벡터 분류
"검증되었다"고 말하려면 다음 7가지 카테고리를 모두 통과해야 합니다. 어느 한 단계라도 누락하면 사일런트 버그가 양산 칩에 박제됩니다.
| # |
카테고리 |
검증 대상 |
출처 |
| 1 |
KAT |
표준 입력 → 표준 출력 일치 (최소 요건) |
NIST CAVP |
| 2 |
MCT |
동일 연산 수천~수만 회 체이닝, 누적 오류 검출 |
CAVP / ACVP |
| 3 |
MMT |
여러 블록 경계에서 State 전파 정합성 |
CAVP |
| 4 |
Intermediate |
라운드별 State 비교 — SoC 디버깅의 본질 |
FIPS 부록 예제 |
| 5 |
Edge / Invalid |
최대·최소·0-길이, 약한 키, 잘못된 패딩 |
Wycheproof |
| 6 |
RSA 전용 |
KeyGen / SigGen·SigVer (PKCS#1, PSS) / OAEP / 타이밍 |
RSA2VS + Wycheproof |
| 7 |
HMAC/KMAC |
키 길이 < 블록, = 블록, > 블록 3분기 커버 |
CAVP HMAC |
⚙️ 5. Co-simulation 워크플로우 — DPI-C가 정답
RTL과 골든 모델을 연결할 때 Python ctypes보다 DPI-C가 cycle-accurate 비교에 우월합니다. 표준 흐름은 다음과 같습니다.
graph LR
A[Golden C
State 노출] --> B[DPI-C 바인딩
SystemVerilog]
B --> C[UVM Scoreboard
라운드별 비교]
C --> D[ACVP JSON
회귀 자동화]
style A fill:#e8f8f5,stroke:#16a085
style B fill:#eaf2f8,stroke:#2980b9
style C fill:#fef9e7,stroke:#f39c12
style D fill:#eafaf1,stroke:#27ae60
🔗 다이어그램 요약: NIST 예제·XKCP `ref` C 코드를 내부 State가 노출되도록 가공한 뒤 DPI-C로 SystemVerilog에 바인딩하고, UVM Scoreboard가 매 라운드마다 RTL 출력과 비교하며, ACVP JSON으로 회귀를 자동화하는 4단 파이프라인이 표준이다.
5.1 핵심 구현 패턴
▶ C 레퍼런스를 수정해 void aes_get_state(int round, uint8_t state[16]) 같은 inspection API를 추가.
▶ SystemVerilog에서 import "DPI-C" function void aes_get_state(...) 선언.
▶ UVM scoreboard에서 RTL 라운드 출력과 DPI 호출 결과를 매 라운드 비교 — 첫 불일치 발생 라운드가 바로 버그 지점.
▶ Python은 자극 생성·회귀 적재용으로만 한정. 검증 핵심 경로는 DPI-C에 두는 분리가 안전합니다.
5.2 라이브러리 함정 비교
| 라이브러리 |
중간값 추출 |
RTL 비교 적합성 |
| PyCryptodome |
❌ 블랙박스 |
부적합 |
| OpenSSL |
⚠️ 어셈 분기 |
Oracle 한정 |
| NIST 예제 C |
✅ 명시적 |
최적 |
| XKCP ref |
✅ State 노출 쉬움 |
최적 |
🚨 권고: 동일 벡터를 (a) 깨끗한 C 레퍼런스, (b) OpenSSL/AWS-LC, (c) XKCP `ref` 셋으로 삼중 검증하여 라이브러리 의존 오류를 차단하세요. 한 곳만 통과해도 안심하면 안 됩니다.
📖 6. 알고리즘 한눈에 — 핵심 구조 정리
🔐 AES (FIPS 197): 128-bit 블록, 128/192/256-bit 키. SubBytes(S-Box) → ShiftRows → MixColumns → AddRoundKey의 라운드 구조. 10/12/14 라운드. 검증 포인트: 각 라운드 후 16바이트 State.
#️⃣ SHA-2 (FIPS 180-4): SHA-224/256/384/512. Merkle-Damgård 구조 + Davies-Meyer 압축. 메시지 스케줄 W[t] 64/80개. 검증 포인트: 각 스텝의 a~h 워킹 변수.
🌀 SHA-3 (FIPS 202): Keccak-f[1600] 스펀지 구조. θ, ρ, π, χ, ι 5 스텝 × 24 라운드. SHAKE128/256은 가변 출력. 검증 포인트: 5×5×64 State Array의 라운드별 스냅샷.
🔏 HMAC (FIPS 198-1): H((K⊕opad) ∥ H((K⊕ipad) ∥ M)). 검증 포인트: 키 길이 3분기 처리.
🗝️ KMAC (SP 800-185): cSHAKE 기반 키드 해시. SHA-3보다 명시적 도메인 분리(Customization String) 제공. 검증 포인트: 도메인 분리 바이트 패딩.
🔑 RSA (FIPS 186-4 → 186-5): c = m^e mod n, 서명은 PKCS#1 v1.5 / PSS, 암호화는 OAEP. Bignum·Montgomery·CRT 최적화의 정확성 검증이 SoC 난이도 정점. 검증 포인트: 모듈러 지수 중간값.
🎯 7. 실전 권장 셋업 (최종 정리)
| 알고리즘 |
골든 (1순위) |
Oracle |
에지/회귀 |
| SHA-3 / KMAC |
XKCP `ref` |
OpenSSL 3.x |
Wycheproof JSON |
| AES |
FIPS 197 부록 기반 자작 C |
OpenSSL (AES-NI 차단) |
AESAVS + Wycheproof |
| SHA-2 / HMAC |
NIST C Reference |
OpenSSL |
CAVP RSP + ACVP JSON |
| RSA |
Fiat-Crypto 또는 자작 bignum |
OpenSSL |
RSA2VS + Wycheproof PSS |
🛡️ 물리 공격 대비 주의: SW Golden Reference만으로는 사이드채널·결함 주입 저항성을 증명할 수 없습니다. 전력·타이밍 누설은 TVLA(Test Vector Leakage Assessment)로 별도 평가해야 하며, 이는 게이트 레벨 시뮬레이션 파형 또는 실측 데이터에서 t-test 기반으로 수행합니다. 기능 검증과 보안 검증은 분리된 트랙입니다.
📅 8. 표준 이행 타임라인
2024-09
FIPS 140-3
#4811 첫 인증
2025-03
#4985
OpenSSL 3.1.2
2025-10
OpenSSL 3.5.4
PQC 제출
🏁 결론 — 4단 결합의 황금률
SoC 암호 IP 검증의 황금률은 "NIST 표준 + 깨끗한 C 레퍼런스 + DPI-C 중간값 비교 + Wycheproof 에지 케이스" 4단 결합입니다. OpenSSL은 Wrapper와 Oracle로 매우 유용하지만, 플랫폼별 어셈블리 분기 때문에 RTL 1:1 비교의 골든 모델로는 부적합합니다.
SHA-3·KMAC은 XKCP `ref`, RSA는 Fiat-Crypto 또는 NIST 예제 기반 자작 코드, AES·SHA-2는 FIPS 부록 Intermediate Values를 그대로 박제한 C 코드를 골든으로 두고, ACVP JSON으로 회귀 자동화하는 것이 2026년 현재 가장 견고한 셋업입니다. 그리고 잊지 말아야 할 한 가지 — 기능 검증과 사이드채널 검증은 완전히 다른 트랙입니다. TVLA는 별도 예산을 잡으세요.
🧠 한 줄 요약: 표준은 NIST, 골든은 XKCP·Fiat·NIST 예제, Oracle은 OpenSSL, 에지는 Wycheproof, 연결은 DPI-C, 회귀는 ACVP JSON — 이 6가지를 기억하면 됩니다.
📎 References
▶ NIST CSRC — Cryptographic Standards
▶ NIST ACVP-Server JSON Files
▶ XKCP — Keccak Code Package
▶ Keccak Team Official
▶ Wycheproof (C2SP)
▶ Fiat-Crypto
▶ NIST CAVP
본 문서는 일반 정보 제공을 목적으로 하며, 실제 IP 인증·컴플라이언스는 해당 인증 기관의 최신 가이드라인을 따라야 합니다. SoC 양산 적용 전에는 반드시 자격을 갖춘 보안 평가 기관의 검토를 거치시기 바랍니다.
📄 Raw Data
# 암호 알고리즘 SoC 설계를 위한 Golden Reference 완전 가이드
## 들어가며 — 왜 "Golden Reference"가 SoC 검증의 출발점인가
암호 IP(AES, SHA-2/3, HMAC/KMAC, RSA)를 SoC에 내장할 때, RTL이 비트 단위로 옳다는 것을 어떻게 증명할 수 있을까요? 정답은 **검증 가능한 SW 기준 모델(Golden Reference) + 표준 기관이 공인한 테스트 벡터**의 조합입니다. NIST CAVP/ACVP 벡터를 통과하는지 확인하는 것은 출발점일 뿐이고, 실제 RTL 디버깅에서는 **중간값(Intermediate Values)이 노출되는 깨끗한 C 레퍼런스**가 결정적 역할을 합니다([NIST CSRC](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines)). 본 보고서는 알고리즘별 표준, 레퍼런스 후보의 위상·신뢰도, 확보 위치, 필수 테스트 벡터, 그리고 OpenSSL Wrapper의 함정까지 한 번에 정리합니다.
---
## 1. 알고리즘별 표준과 Golden Reference 맵
| 알고리즘 | 표준 문서 | 1순위 Golden Reference | 2순위(Oracle용) | 위상 |
|---|---|---|---|---|
| **AES** | FIPS 197 | Rijndael C 레퍼런스 + NIST "Intermediate Values" | OpenSSL `libcrypto` (단, AES-NI 분기 주의) | 세계 표준 |
| **SHA-2** | FIPS 180-4 | NIST C Reference Code | OpenSSL `EVP_Digest*` | 세계 표준 |
| **SHA-3 / SHAKE** | FIPS 202 | **XKCP `ref` 폴더** (Keccak 팀 공식) | OpenSSL 3.x | Keccak 팀 = 사실상 표준 |
| **HMAC** | FIPS 198-1 | NIST 예제 + OpenSSL `HMAC()` | PyCryptodome (참고용) | 표준 |
| **KMAC** | NIST SP 800-185 | **XKCP** (KMAC128/256, cSHAKE 포함) | OpenSSL 3.0+ (KMAC EVP) | XKCP 사실상 독점 |
| **RSA** | FIPS 186-4 (현행 186-5로 이행 중) | OpenSSL bignum 계층 + NIST 예제 | Fiat-Crypto (수학적 증명 코드) | 산업 표준 |
> **핵심**: SHA-3·KMAC은 **XKCP가 곧 표준**, AES·RSA는 **OpenSSL이 산업 기준**이지만 RTL 비교용으로는 OpenSSL이 위험할 수 있다는 점을 뒤에서 다룹니다.
---
## 2. 확보 가능 위치 — 어디서 받을 수 있는가
### 2.1 NIST 공식 (1순위, 무조건 확보)
- **CSRC 프로젝트 페이지**: <https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines>
- 알고리즘별 **"Examples with Intermediate Values"** PDF — AES 각 라운드 후 16바이트 State, SHA-256 메시지 스케줄 W[t], Keccak θ/ρ/π/χ/ι 각 스텝 결과가 바이트 단위로 적혀 있어 RTL 파형과 1:1 비교 가능.
- **CAVP 레거시 ZIP/RSP**
- AES: <https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/aes/aesavs.zip>
- SHS(SHA-2): <https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/secure-hashing>
- SHA-3: <https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/sha-3>
- RSA: <https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/dss/rsa2vs.zip>
- **ACVP (최신 JSON 표준, 자동화 친화)**: <https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files> — UVM/Python 테스트벤치에서 파싱이 훨씬 쉬움. NIST가 현재 ACVP로 전환 중이므로 신규 프로젝트는 JSON 기반을 권장.
### 2.2 XKCP (SHA-3/KMAC 사실상 표준)
- 저장소: <https://github.com/XKCP/XKCP>, 팀 공식 페이지: <https://keccak.team/keccak.html>
- 위상: **Keccak 설계자(Bertoni, Daemen, Peeters, Van Assche)가 직접 유지보수**하는 코드. NIST FIPS 202 및 SP 800-185 구현 중 최고 신뢰도.
- 활용: **`ref` 폴더만 골든 모델로 사용**, AVX-512/ARMv8 최적화 폴더는 성능 비교용으로만 사용 (어셈블리 최적화는 RTL과 구조가 달라 디버깅 가치가 떨어짐).
### 2.3 OpenSSL (Oracle / Wrapper용)
- FIPS 140-3 인증 현황 (2024–2025):
- **#4985 (2025-03-11)**: OpenSSL 3.1.2 기반, 현재 가장 권장되는 기준
- **#4811 (2024-09-24)**: 첫 FIPS 140-3 모듈
- **OpenSSL 3.5.4 (2025-10-09 제출)**: PQC 포함 차세대 모듈, 인증 검토 중
- 위상: API 안정성 + FIPS 인증 = **산업 컴플라이언스의 사실상 표준**.
- **함정**: `EVP_EncryptInit` 호출 시 런타임에 AES-NI/VAES/AVX-512 분기로 가버리므로, "내가 만든 RTL과 동일한 알고리즘 흐름을 따르는가"를 보장하지 않음. **순수 수학적 명세(FIPS 197)와 비교**하는 것이 안전.
### 2.4 보조 도구 — Wycheproof, AWS-LC, BoringSSL, Fiat-Crypto
- **Wycheproof**: <https://github.com/C2SP/wycheproof> (Google → C2SP로 이관). 실행 Harness가 제거되어 JSON 벡터를 **직접 파싱하는 보조 도구**로 위치 변경. 에지 케이스(잘못된 패딩, 약한 키, 비정상 길이) 검증에 필수.
- **AWS-LC**: BoringSSL 포크 + FIPS 지원. 고성능/최신 PQC를 원하면서 컴플라이언스도 필요할 때.
- **BoringSSL**: Google 내부용. 외부 FIPS 지원 없음 — **SoC 컴플라이언스 용도로 권장하지 않음**.
- **Fiat-Crypto**: <https://github.com/mit-plv/fiat-crypto>. **수학적으로 정확함이 증명된** RSA/ECC bignum 코드 생성. RSA Golden Reference의 최고 신뢰 옵션.
---
## 3. 필수 테스트 벡터 분류 — 무엇을 통과해야 "검증되었다"고 말할 수 있는가
1. **KAT (Known Answer Test)** — NIST 제공 표준 입력 → 표준 출력 일치. 최소 요건.
2. **MCT (Monte Carlo Test)** — 동일 연산을 수천~수만 회 체이닝하여 누적 오류 검출. AES/SHA 모두 CAVP에 포함.
3. **MMT (Multi-block Message Test)** — 여러 블록 경계에서 State 전파가 옳은가.
4. **Intermediate Values Test** — FIPS 부록 예제로 **라운드별 State 비교**. SoC 디버깅의 본질.
5. **Edge / Invalid Inputs** — 최대/최소 길이, 0-길이 메시지, 약한 키, 잘못된 패딩(Wycheproof).
6. **RSA 전용**: KeyGen, SigGen/SigVer (PKCS#1 v1.5, PSS), Encrypt/Decrypt (OAEP), 그리고 **타이밍/사이드채널 저항성 벡터**.
7. **HMAC/KMAC 전용**: 키 길이 < 블록, = 블록, > 블록의 3가지 분기를 모두 커버.
---
## 4. Co-simulation 워크플로우 — RTL과 골든 모델을 연결하는 법
### 4.1 표준 접근: DPI-C (SystemVerilog/UVM)
Round 3 자료가 강조하듯, **Python ctypes보다 DPI-C가 cycle-accurate 비교에 우월**합니다. 다음 흐름이 표준입니다.
1. C 레퍼런스(NIST 예제 또는 XKCP `ref`)를 **내부 State를 노출하도록** 수정 — 예: `void aes_get_state(int round, uint8_t state[16])`.
2. SystemVerilog에서 `import "DPI-C" function void aes_get_state(...)` 선언.
3. UVM scoreboard에서 RTL의 라운드 출력과 DPI 호출 결과를 **매 라운드마다** 비교.
### 4.2 Python 보조: 자극 생성 / 회귀 자동화
- Python `ctypes`로 `golden_crypto.so` 로딩 → 대량 랜덤 벡터 생성/저장.
- ACVP JSON 파서 → 회귀 케이스 자동 적재.
- 단, **검증 핵심 경로는 DPI-C에 두고 Python은 케이스 생성에만** 두는 분리가 안전합니다.
### 4.3 PyCryptodome vs OpenSSL — 라이브러리의 한계
- **PyCryptodome**: 블랙박스. AES S-Box, RSA 모듈러 지수의 중간 상태를 꺼내기 어려워 **RTL 검증 부적합**. SW 통합 테스트 용도로만.
- **OpenSSL**: 고성능이지만 **플랫폼별 어셈블리 분기**가 잠재적 위험. Oracle용으로만 쓰고, 비교는 항상 FIPS 명세 기반 순수 C 레퍼런스로.
- **권고**: 동일 벡터를 (a) 깨끗한 C 레퍼런스, (b) OpenSSL/AWS-LC, (c) XKCP `ref`로 **삼중 검증**하여 라이브러리 의존 오류를 차단.
---
## 5. 알고리즘 한눈에 — 한 포스팅에 담는 개념 정리
- **AES (FIPS 197)**: 128-bit 블록, 128/192/256-bit 키. SubBytes(S-Box) → ShiftRows → MixColumns → AddRoundKey의 라운드 구조. 10/12/14 라운드.
- **SHA-2 (FIPS 180-4)**: SHA-224/256/384/512. Merkle-Damgård 구조 + Davies-Meyer 압축. 메시지 스케줄 W[t] 64/80개.
- **SHA-3 (FIPS 202)**: Keccak-f[1600] 스펀지 구조. θ, ρ, π, χ, ι 5 스텝 × 24 라운드. SHAKE128/256은 가변 출력.
- **HMAC (FIPS 198-1)**: `H((K⊕opad) ∥ H((K⊕ipad) ∥ M))`. 키 길이 3분기 처리가 핵심.
- **KMAC (SP 800-185)**: cSHAKE 기반 키드 해시. SHA-3보다 명시적 도메인 분리(Customization String) 제공.
- **RSA (FIPS 186-4)**: `c = m^e mod n`, 서명은 PKCS#1 v1.5 / PSS, 암호화는 OAEP. Bignum, Montgomery, CRT 최적화의 정확성 검증이 SoC의 난이도 정점.
---
## 6. 실전 권장 셋업 (요약)
1. **SHA-3/KMAC**: XKCP `ref` → 골든, OpenSSL 3.x → Oracle, Wycheproof JSON → 에지 케이스.
2. **AES**: FIPS 197 부록 Intermediate Values 기반 자작 C → 골든, OpenSSL(AES-NI 차단 빌드) → Oracle.
3. **SHA-2/HMAC**: NIST CAVP RSP + ACVP JSON → KAT/MCT, OpenSSL → Oracle.
4. **RSA**: Fiat-Crypto 생성 코드 또는 자작 bignum → 골든, OpenSSL → Oracle, NIST RSA2VS → KeyGen/SigGen/SigVer.
5. **공통**: ACVP JSON 우선, DPI-C 비교 필수, Wycheproof로 에지 보강.
> **물리 공격 대비**: Round 3 경고대로, **SW Golden Reference만으로는 사이드채널/결함 주입 저항성을 증명할 수 없습니다**. 전력/타이밍 누설은 **TVLA(Test Vector Leakage Assessment)**로 별도 평가해야 하며, 이는 게이트 레벨 시뮬레이션 파형 또는 실측 데이터에서 t-test 기반으로 수행합니다.
---
## 7. 라운드 간 모순 점검
본 조사 3라운드 사이에 **상호 모순되는 주장은 발견되지 않았습니다**. Round 1·2는 NIST/XKCP/OpenSSL의 위상을 일관되게 기술했고, Round 3는 OpenSSL을 골든이 아닌 Oracle로 한정하라는 정밀화된 권고를 추가했을 뿐, 앞 라운드와 충돌하지 않습니다.
---
## 결론
SoC 암호 IP 검증의 황금률은 **"NIST 표준 + 깨끗한 C 레퍼런스 + DPI-C 중간값 비교 + Wycheproof 에지 케이스"** 4단 결합입니다. OpenSSL은 Wrapper/Oracle로 유용하지만, 어셈블리 최적화 때문에 RTL 1:1 비교의 골든 모델로는 부적합합니다. SHA-3·KMAC은 XKCP `ref`, RSA는 Fiat-Crypto 또는 NIST 예제 기반 자작 코드, AES·SHA-2는 FIPS 부록 Intermediate Values를 그대로 박제한 C 코드를 골든으로 두고, ACVP JSON으로 회귀 자동화하는 것이 2026년 현재 가장 견고한 셋업입니다.
---
## References
- [NIST CSRC](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines)
- [NIST ACVP-Server](https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files)
- [XKCP (Keccak Code Package)](https://github.com/XKCP/XKCP)
- [Keccak Team](https://keccak.team/keccak.html)
- [Wycheproof (C2SP)](https://github.com/C2SP/wycheproof)
- [Fiat-Crypto](https://github.com/mit-plv/fiat-crypto)
- [NIST CAVP](https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program)
댓글
댓글 쓰기