Designing SoC Crypto IP with OpenSSL: Reference Scope, Licensing, and Validation Checklist
Using OpenSSL in SoC Crypto IP Design: Reference Scope, Licensing, and Validation
A comprehensive guide for SoC security IP designers · April 29, 2026
crypto/ tree is the de-facto industry standard for functional correctness. However, mapping it directly to RTL comes at a serious cost in area, power, and side-channel resilience. This guide covers: ① the appropriate scope for using OpenSSL as a reference, ② license and patent risks, ③ a mandatory design checklist, and ④ how to obtain international standard test vectors and golden results.
1. Framing the Problem
The core question has two parts: ① Can the OpenSSL crypto/ directory (C source) serve as a reference for crypto IP design inside an SoC? ② What exactly must a crypto engine IP verify, and where do you find globally accepted protocols, test vectors, and golden outputs?
This is not a simple "can I copy the code?" question. It is a design decision that must satisfy all four of the following dimensions simultaneously.
① Functional Correctness — algorithm-level accuracy
② Legal Safety — license and patent exposure
③ Hardware Security Robustness — resistance to physical attacks
④ Certifiability — ability to pass formal third-party evaluation
2. What the OpenSSL crypto/ Tree Actually Is
2.1 Contents
The crypto/ directory contains algorithm implementations for AES, SHA-2/3, RSA, ECC (P-256/P-384), Ed25519, ChaCha20-Poly1305, and HKDF, alongside framework layers for EVP, ASN.1, and BIO. It also includes multiple assembly backends — targeting x86 AES-NI and ARMv8 Crypto Extension/NEON via perlasm-generated variants. This multi-backend structure means it cannot simply be treated as "plain reference C code."
2.2 Strengths vs. Limitations as a Hardware Reference
| Strengths — Functional Golden | Limitations — Architectural Mismatch |
|---|---|
| Decades of validation: edge cases and corner conditions are handled to an industry standard level | Sequential vs. parallel: direct RTL translation of C loops yields roughly 1/10 the expected throughput |
| Mode coverage: GCM, CCM, XTS, CMAC, PSS, EdDSA all present | Memory model mismatch: a direct translation of the T-table AES lookup exposes significant area overhead and timing side-channel leakage |
| Built-in KAT suite: rapid regression against NIST known-answer tests before submitting to formal validation | No SCA countermeasures: DPA (differential power analysis), EMA (electromagnetic analysis), and fault-injection protections are absent |
3. License and Patent Risks — Shipping IP Under Apache License 2.0
OpenSSL 3.0 and later is distributed under Apache License 2.0 (AL2). When deriving a hardware IP from OpenSSL source, the following clauses apply.
| Clause | Meaning for Hardware IP |
|---|---|
| §2 Copyright Grant | Converting C source to RTL or a netlist and shipping it is permitted. The resulting IP is considered a "Derivative Work." |
| §3 Patent Grant | Contributors grant a royalty-free patent license for patents they hold that are necessarily infringed by the contribution. This is the key clause for reducing patent litigation risk from the SoC vendor's perspective. |
| §4 Redistribution | Any redistribution of the IP package must include: ① a copy of the license, ② the original copyright notice, and ③ the NOTICE file. |
| §7 Disclaimer of Warranty | Liability for design defects rests with the IP distributor, not the OpenSSL project. Verification and certification are entirely your responsibility. |
In short: converting OpenSSL source to synthesizable SystemVerilog and shipping it as a licensable IP block is legally permissible under AL2, but operationally it requires that your SDLC include ① source provenance tracking, ② NOTICE file automation in the IP delivery package, and ③ a process for back-porting OpenSSL security fixes into the RTL lineage.
4. Mandatory Design Checklist for Crypto IP
A production-ready crypto IP must pass validation across four domains simultaneously. The relative weight of each domain looks like this.
4.1 Functional Correctness
✓ Edge case coverage: AES-GCM with IV lengths of 0/96/arbitrary bytes; AAD-absent inputs; empty plaintexts; maximum message lengths
✓ DRBG reseeding: reseed counter behavior, prediction-resistance mode, and entropy-source conditioning
4.2 PPA (Power, Performance, Area)
Gate count, leakage, and dynamic power: determinative constraints for IoT and mobile SoC designs
Clock-domain crossing and backpressure: stall handling and in-flight command depth over AXI/AHB streaming interfaces
4.3 Security — The Non-Negotiable Dimension
Fault Injection (FI) resilience: dual-rail logic, redundant computation, and signature-based sanity checks on critical operations
Key lifecycle protection: OTP/eFuse → Key Ladder → Crypto Core direct path; plaintext key material must never appear on the system bus
TRNG / CSRNG: conformance to NIST SP 800-90A (DRBG), 90B (entropy source), and 90C (construction)
4.4 Interface and Functional Safety
• AMBA bus compliance; separation of secure and non-secure transactions (e.g., TrustZone-compatible transaction routing)
• For automotive or industrial SoCs: alignment with ISO 26262 (ASIL) or IEC 61508 requirements
5. Side-Channel and Evaluation Standards at a Glance
| Standard | Scope | Notes |
|---|---|---|
| ISO/IEC 17825:2023 | Test methodology for mitigation of non-invasive attacks (DPA, SPA, EMA) | Forms the SCA testing basis for FIPS 140-3 Level 3/4 |
| ISO/IEC 20085-1/2 | SCA test tool and calibration standards | Defines lab-grade measurement environment requirements |
| ISO/IEC 15408 (Common Criteria) | General security product evaluation framework | EAL4+ to EAL6+. Finance and defense targets typically require EAL5+ |
| BSI AIS-31, AIS-46 | TRNG / PTG evaluation | German BSI criteria; mandatory for European market entry |
6. International Certification Frameworks and Golden Test Vectors
6.1 Validation Pipeline — RTL Simulation to ACVP
6.2 Certification Tracks
Common Criteria EAL4+/5+: used in smart cards, HSMs, and automotive secure elements. EAL5 corresponds to the "Semi-formally designed and tested" assurance level.
KCMVP (Korea): Korea's national cryptographic module validation program, requiring separate KAT coverage for domestic algorithms such as SEED, ARIA, LEA, HIGHT, and HAS-160. Global IP entering the Korean market must account for these requirements.
6.3 Algorithm Validation — Full Transition from CAVP to ACVP
NIST has fully migrated from the legacy manual submission model (CAVP) to the ACVP (Automated Cryptographic Validation Protocol). As of 2024, new algorithm validations are accepted exclusively through ACVP. Under ACVP, the server delivers JSON-formatted input vectors to the module under test; the module returns responses, and NIST grades them automatically — eliminating the manual response-file submission workflow.
- ▶ ACVP Portal: https://pages.nist.gov/ACVP/
- ▶ Historical Validation Search: CAVP Validation Search — filter by vendor, module, or algorithm
6.4 Golden Test Vector (KAT) Sources by Algorithm
| Algorithm / Mode | Specification | Official KAT Location |
|---|---|---|
| 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 | Same page as above |
| AES-XTS | SP 800-38E | Same page as above |
| SHA-1/2/3, SHAKE | FIPS 180-4, FIPS 202 | Secure Hashing |
| HMAC | FIPS 198-1 | Message Authentication |
| RSA (signature / encryption) | FIPS 186-4/5, SP 800-56B | Digital Signatures |
| ECDSA / EdDSA | FIPS 186-5 | Same page as above |
| DRBG | SP 800-90A Rev.1 | RNG |
| Entropy Source | SP 800-90B | Same page as above |
gcmEncryptIntIVPCxxxxx.rsp / gcmDecrypt256.rsp) are split by IV generation mode (Internal/External) and key length. The standard practice in RTL regression environments is to cross-verify: run the same vectors through both EVP_aead_aes_*_gcm in OpenSSL and the NIST KAT files, and confirm both match your RTL output.
6.5 Representative Commercially Certified Crypto IP
| Vendor / IP | Positioning |
|---|---|
| Arm CryptoCell-71x | "FIPS 140-3 ready" design with TEE integration support |
| Synopsys DesignWare tRoot HSM | Root-of-Trust IP targeting FIPS 140-3 Level 3 compliance |
| Rambus (formerly Inside Secure) | Multiple production designs certified at FIPS 140-3 Level 2/3 |
All three vendors use OpenSSL as an algorithm golden — but they each design their own microarchitecture, SCA countermeasures, and key protection mechanisms independently. This is the canonical example of the separation-of-roles principle described in Section 2.
7. Consistency Check Across Research Rounds
No direct factual conflicts were found between research rounds 1 and 2. Two points are worth noting explicitly for clarity.
OpenSSL licensing: Round 1 omitted license details. Round 2 introduced the Apache 2.0 obligations. This is additive information, not a conflict.
8. Conclusions and Action Items
Prioritized implementation decisions, visualized by urgency.
8.1 Five Concrete Recommendations
• OpenSSL
crypto/ → algorithm golden model and KAT generator for regression• Microarchitecture and SCA countermeasures → separate design track driven by academic literature, FIPS/CC evaluation reports, and in-house SCA lab data
② Integrate license and patent compliance into your SDLC
• Automate Apache 2.0 NOTICE/Attribution insertion in every IP delivery package
• Subscribe to the OpenSSL security advisory feed and treat security fixes as design-change triggers
③ Verify at multiple layers
• ① OpenSSL self-test → ② NIST official KAT (
*.rsp) → ③ ACVP automated grading• Define "shippable" as passing all three stages — a failure at any stage is a blocker
④ Lock down the certification roadmap at the architecture phase
• Decide FIPS 140-3 level target, CC EAL, KCMVP applicability, and BSI AIS-31 scope before finalizing the architecture
• ROM/eFuse layout, Key Ladder topology, and RNG placement are very expensive to change later — fix them early
⑤ Elevate SCA defense to a first-class requirement
• Map ISO/IEC 17825:2023 test items to your internal verification checklist item by item
• Make DPA/EMA measurement results a standing agenda item in design reviews — not a late-stage audit
OpenSSL is the most trustworthy "answer key" for SoC crypto IP algorithm correctness. But for the IP to also have the right "body and armor," international standards — NIST SP 800 series, FIPS 140-3, ISO/IEC 19790 and 17825, and Common Criteria — must carry equal weight in the design process. The central tool for automating all of that validation is 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
We collect, organize, and verify materials from a semiconductor and SoC design perspective before publishing.
This post is based on publicly available data and cited sources. Last updated: June 8, 2026
댓글
댓글 쓰기