Luna HSMs ensure the highest quality of protection of your cryptographic material with the following security measures:
Layered Encryption
Luna HSMs do not keep any objects unencrypted. All objects are encrypted by multiple layers, and are fully decrypted in temporary (volatile) memory only when needed.
Hierarchy of Protection
One general storage key (GSK), for the HSM, protects general storage objects that might be needed by various roles. A separate user storage key (USK) for each role protects the contents of the partition accessed by that role. The hierarchy of protection applies to each individual role. The USK for each role on the HSM encrypts objects that are owned by that role, ensuring that each person sees and touches only what belongs to them. Every Luna HSM has a master tamper key (MTK) that strongly encrypts each object generated and stored within the HSM.
The key encryption key (KEK) further encrypts every key being used to ensure that your keys are never shown in plaintext.
Cloning Domain or Security Domain
Every HSM or partition is part of a security domain, set at initialization time. This is also called a cloning domain, because objects under such a domain can be securely copied (cloned) only to other HSMs or partitions that share that exact domain.
Multiple HSMs or partitions can be set to be part of the same cloning domain or different ones. Key material cannot leave its cloning domain, so if an attacker were to try to copy your cryptographic material to a device that does not share a cloning domain with your HSM or partition, they would be unsuccessful. Using cloning domains ensures that key material can travel only between trusted and authorized devices. This adds a strong layer of defense against attackers.
NOTE The security or cloning domain is not the lowest encryption level, so a cloning operation does not provide access to Crypto material.
Other than direct use of the partition clone command, operations that use cloning are limited to backup, restore and synchronizing the HSMs in HA groups ( among HSMs that share the same domain). Only the backup operation imposes a source-partition domain on the target partition within the Backup HSM; the restore operation and the HA synchronization both require that the source and target HSMs or partitions must already have matching domains.
Scalable Key Storage
Luna HSM Firmware 7.7.0 and newer supports Scalable Key Storage (SKS), the ability to securely store off-board many more keys than can fit within the bounds of the HSM card hardware. Partitions at Luna HSM Firmware 7.7.0 and newer can be configured in one of the following ways by the HSM SO:
>version zero (V0) partitions, the default, continue to use the cloning model described above (also referred to as "Keys in Hardware")
>version one (V1) partitions use cloning only for the SKS Master Key (SMK), while all other backup/restore and HA operations involve keys and objects being exported and imported as encrypted binary large objects (blobs), while otherwise remaining securely encrypted in external storage (either in Luna Network HSM 7 appliance storage or on a host computer for a Luna PCIe HSM 7 or Luna USB HSM 7)
The SMK secures all stored keys and objects within the security perimeter of the HSM, even when they reside in offboard storage because:
>the keys and objects are securely encrypted with the SMK when not in use inside the cryptographic module.
>the SMK is secured by the traditional "keys in hardware" cloning/security domain, and can be copied only to another HSM or partition that shares the specific cloning/security domain. The cloning (or security) domain is set by the Partition SO and changes only through intentional action of the Partition SO, for the life of the partition.
On V1 partitions, HA replication and synchronization that traditionally used cloning transparently use a combination of SMK cloning and SKS extract/insert operations. An operation like a cloning command or backup/restore command invokes cloning of all indicated objects when used against a V0 partition or a pre-firmware-7.7.0 partition.
The same command, when used against a V1 partition, invokes cloning for the SMK, and then silently invokes SKS to complete the copying of indicated keys and objects, once the SMK is in place on the destination partition.
Either way, your keys and objects remain protected by the HSM's security perimeter. Externally stored keys (in the form of encrypted blobs) cannot be decrypted or used until they are brought back inside the cryptographic module.
Tamper Protection
Physical Security
Luna HSMs are equipped with intrusion-resistant, tamper-evident hardware, and use the strongest cryptographic algorithms to ensure that your data is secure. If a security breach is detected, a tamper event occurs and the HSM becomes locked until the tamper is cleared by the appropriate authority or the HSM is reset.
Luna Network HSM 7
The Luna Network HSM 7 appliance is a commercial-grade secure appliance. This means that:
>It is provided with anti-tamper external features that make physical intrusion into the unit difficult. These measures deter casual intrusion and leave visible evidence of attempts (successful or otherwise) to open the unit.
>Vents and other paths into the unit are baffled to prevent probing from the outside.
>It includes a hardened OS that constantly monitors for security vulnerabilities.
>The HSM card inside the appliance houses the actual HSM components. It is encased in an aluminum shell, filled with hardened epoxy. Attempts to gain access to the circuit board itself would result in physical evidence of the attempted access and likely physical destruction of the circuitry and components, thus ensuring that your keys and sensitive objects are safe from an attacker.
Luna PCIe HSM 7
The Luna PCIe HSM 7, or cryptographic module, is a multi-chip standalone module as defined by FIPS PUB 140–2 section 4.5. This means that:
>The module is enclosed in a strong enclosure that provides tamper-evidence. Any tampering that might compromise the module’s security is detectable by visual inspection of the physical integrity of the module. In addition, any attempts to physically tamper with the token would likely result in the destruction of its circuitry and components, thus ensuring that your keys and sensitive objects are safe from an attacker.
>The module’s physical design also resists visual inspection of the device design, physical probing of the device and attempts to access sensitive data on individual components of the device.
If an attacker with unlimited resources were to simply steal the module, and apply the resources of a well-equipped engineering lab, it might be possible to breach the physical security. However, without the password (password-authenticated HSMs) or the iKeys (multifactor quorum-authenticated HSMs), such an attacker would be unable to decipher any signal or data that they manage to extract.
With that said, it is your responsibility to ensure the physical security of the unit to prevent such theft, and it is your responsibility to enforce procedural security to prevent an attacker ever having possession of (or unsupervised access to) both the HSM and its authentication secrets.
Luna USB HSM 7
The Luna USB HSM 7 is a multi-chip standalone module as defined by FIPS PUB 140-2 section 4.5, like the Luna PCIe HSM 7 described above, and provides the same physical tamper resistance measures. The Luna USB HSM 7 contains HSM hardware in a sealed, tamper-resistant enclosure, and all keys are stored encrypted within the hardware, inaccessible without the proper credentials (password or iKey).
Surrounding Environment
The data sheets provided for individual products show the environmental limits that the device is designed to withstand. It is your responsibility to ensure that the unit is protected throughout its working lifetime from extremes of temperature, humidity, dust, vibration/shock that exceed the stated limits.
We do not normally specify operational tolerances for vibration and shock, as the Luna HSM is intended for installation and use in an office or data center environment. We perform qualification testing on all our products to ensure that they will survive extremes encountered in shipping, which we assume to be more demanding than the intended operational environment.
It is also your responsibility to ensure that the HSM is installed in a secure location, safe from vandalism, theft, and other attacks. In summary, this usually means a clean, temperature-, humidity-, and access-controlled facility. We also strongly recommend power conditioning and surge suppression to prevent electrical damage, much as you would do for any important electronic equipment.
Authentication Data Security
All of the above security features are built into the HSM product, and they do present strong barriers to attackers. It is important that your own organization's security mandates, processes, and procedures avoid compromising that protection. It is all very well to have protection against external and opportunist attackers. But it is also necessary to ensure consistent proper handling by your own staff, over the long term.
Procedural checks and balances, with oversight, are important.
It is your responsibility to protect passwords and/or iKeys from disclosure or theft and to ensure that personnel who might need to input passwords do not allow themselves to be watched while doing so, and that they do not use a computer or terminal with keystroke logging software installed.
As a best practice, engage in role/responsibility separation as much as possible (the HSM interfaces encourage this), but if your model puts all administrative functions in the hands of one person, at least be aware of how much power that gives them over the content and the use and the availability of your important keys and objects, and have contingencies in place to address the possibility of that person ever becoming compromised in any way.
For example, when the HSM SO creates an application partition, the eventual owner of that partition should change passwords (including hardware authentication tokens, like iKeys for multifactor quorum) for themselves [partition SO] and others [User or Crypto Officer, Limited Crypto officer, Crypto User] as applicable. The HSM SO can still delete the partition, but has no visibility or entry into it.
Password authentication for roles and cloning/security domains are only as secure as any text string can be made secure.
Multifactor Quorum authentication for roles and cloning/security domains are generally much more secure (and used to protect the highest value keys and objects), because you can exert procedural control over the physical portion of the authentication secrets, such as lockups, sign-outs/sign-ins, audits, etc.
Certification
The Thales website provides more information about the certifications, compliance, and validation progress for each of the Luna HSM variants:
https://cpl.thalesgroup.com/encryption/hardware-security-modules/general-purpose-hsms
FIPS
At any given time, a FIPS-validated version of the HSM firmware is available, and a newer, not-yet-validated version might also be available for newly introduced products that have not had time to go through the long evaluation and validation process. The usual practice is to ship units pre-loaded with the firmware and software at the FIPS-validated level by default, while providing the option to update the Client software, Appliance software, and HSM firmware to the newer version. This allows customers who need FIPS validation to have that configuration from the factory, and customers who need newer features (and do not need FIPS validation) to upgrade by simply installing the newer software and following the upgrade procedure.
Common Criteria
Some versions of the product are submitted for Common Criteria EAL evaluation.
You can check with Thales Customer Support to inquire about the certification status of Luna HSM products. If FIPS validation or CC EAL certification are not requirements for you, then the newest version is normally the preferred option.
Handling and best practices
All of the above security features are built into the HSM product, and they do present strong barriers to attackers.
It is up to you to avoid practices that devalue or circumvent the security features.
