Proven by Intelligence
Proving Invisible Safety Through Intelligence.
Organizations typically protect sensitive data such as personal information, trade secrets, and financial records by employing encryption to prevent tampering and external leakage. Various encryption systems are deployed to protect different forms of data, and the concept of Root of Trust (RoT) is always invoked when considering these systems.
Root of Trust (RoT) refers to the set of computing functions within a computer operating system (OS) that are inherently trusted. In security architectures, it acts as a separate computing engine that controls critical cryptographic processes on a trusted computing platform. In other words, RoT denotes a trustworthy device or component that cannot be altered and upon which all security operations of the computing system depend.
What underpins trust in encryption-based security?
Cryptographic security necessarily relies on cryptographic keys to perform functions such as data encryption, digital signature generation, and signature verification. Encryption algorithms required for these operations, including AES, ARIA, RSA, and ECDSA, are standardized and publicly available, and numerous commercial and open-source cryptographic APIs are readily accessible.
Ultimately, the trustworthiness of encryption-based security depends on how securely cryptographic keys are concealed and protected.
Among available approaches, hardware-based protection currently offers the most reliable method for ensuring design-level safety and resistance to malware attacks. The rationale is illustrated below.
The following diagram shows a typical key hierarchy for Transparent Data Encryption (TDE), a database-provided data encryption feature.
At the lowest level, data is encrypted to protect it, but this alone does not guarantee complete security.
Consequently, the data encryption key (DEK) used to encrypt the data must itself be protected. Typically, the DEK is encrypted and protected by a TDE master key (a key encryption key, or KEK).
Finally, the ultimate master key should be protected by hardware. In this hierarchical model, the RoT of the cryptographic system is hardware-based, and it is considered to provide security equivalent to that hardware.
RoT is a particularly critical component in public key infrastructure (PKI) environments that generate and protect root and certification authority keys.
A prototypical example of a hardware RoT is the Hardware Security Module (HSM). The following sections describe HSMs in detail.
HSM: Definition
A Hardware Security Module (HSM) is a hardened, tamper-resistant hardware device designed to securely store cryptographic keys and protect them both physically and logically.
HSMs securely store managed cryptographic keys within the device and perform cryptographic operations while ensuring keys never leave the secure boundary.
Unlike approaches that load cryptographic keys into application memory or software modules, HSMs perform encryption and decryption by sending the data to the HSM and receiving the result. The cryptographic keys are kept and managed internally, and all cryptographic computations occur inside the HSM. This strong security model prevents key leakage at the source.
FIPS 140-2 Certification Levels — Summary
.
FIPS (Federal Information Processing Standards) defines cryptographic and related security requirements for IT products used in sensitive applications. Among various FIPS standards, FIPS 140-2 specifies security requirements for cryptographic modules.
The FIPS 140-2 certification levels indicate that products must implement countermeasures ranging from basic software module compliance to advanced physical tamper protection that zeroizes keys upon attempted physical compromise. Products that achieve FIPS 140-2 certification are considered to provide high levels of security, and this certification is widely recognized in the industry as a key security benchmark—often regarded as more critical than Common Criteria (CC) for cryptographic modules.
Types of HSMs
- PCIe (Embedded) HSM

- Description: The embedded PCIe HSM is the most common form and can be installed inside individual security system servers.
- Interface: Typically used via standard cryptographic interfaces such as PKCS#11.
- Use Cases: Low-latency, high-throughput transaction processing, TDE key protection for databases, and certificate signing tasks.
- Network-Attached HSM (Appliance)

- Description: A dedicated HSM appliance that connects over the network. It often runs a hardened OS and specialized software to resist hacking and to provide high performance.
- Interface: Uses standard interfaces like PKCS#11, but communication between the PKCS#11 library and the appliance typically occurs over dedicated TCP/IP channels.
- Advantages: Centralized key management, scalability, and support for high-availability (HA) configurations.
- Use Cases: Large-scale PKI, financial transaction processing, bulk signing and encryption services.
- USB Token HSM

- Description: Portable USB-based HSMs, commonly referred to as security tokens.
- Characteristics: Intended for personal use, to securely store private keys and perform user-level cryptographic operations.
- Use Cases: Personal digital signatures, certificate storage, multi-factor authentication tokens, and electronic wallets.
- Cloud HSM Service

- Description: Managed HSM services provided by cloud providers, such as AWS CloudHSM, offer HSM functionality within the cloud environment via standard interfaces like PKCS#11.
- Advantages: Ease of provisioning and scaling, integration with cloud-native services, and elimination of physical hardware procurement.
- Considerations: Review cloud provider trust, data residency, and regulatory compliance when deploying cloud HSMs.
- Use Cases: Key protection for cloud-hosted databases and applications, centralized key management for SaaS offerings.
- Semiconductor (Chip) Type HSM

- Description: Security chips (secure elements) and HSM chips perform cryptographic operations internally and provide strong protection, but they may not expose standard HSM interfaces such as PKCS#11.
- Characteristics: Suitable for embedding into SoCs and constrained devices, offering compact form factors with low power consumption.
- Use Cases: Key storage and device authentication for IoT/edge devices, embedded security in consumer electronics.
Conclusion
We have reviewed the definition and various types of HSMs that provide robust protection for cryptographic keys.
Efficient key management requires a Key Management System (KMS) to complement HSMs. A comprehensive solution that centralizes and automates key lifecycle operations—such as NeoKeyManager—facilitates secure key generation, distribution, rotation, and auditability while integrating with HSM backends.
Inquiry │ 📧nkm_biz@mdsit.co.kr 📞+82-31-601-4311
