Security Engineering →mediumMultiple Choice

CAS-004 Security Engineering Practice Question

A security engineer is designing the key-management lifecycle for a hardware security module (HSM) that will hold a root certificate authority signing key. The requirement is that the private key must never exist in plaintext outside the HSM, even during backup, and that restoration must be possible after a total device failure. Which approach BEST satisfies these requirements?

⚠ Common exam trap

The trap here is assuming that wrapping a key under a key-encryption key keeps it 'inside the HSM,' when in fact the wrapped blob is exportable and recoverable.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure the HSM to back up the key material using its secure backup mechanism to at least two geographically separate HSMs.

The only approach that keeps the private key inside a hardware-protected boundary while still allowing recovery is a vendor-supported secure backup or cloning mechanism between HSMs. Wrapping, plaintext export, and software encryption all allow the key to exist in a form that can be recovered outside certified hardware, which the scenario explicitly forbids.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Configure the HSM to back up the key material using its secure backup mechanism to at least two geographically separate HSMs.
Why this is correct
Many HSMs support cloning or secure backup where the key is transferred between devices in a wrapped, hardware-protected form and never exists as a recoverable plaintext blob. Storing the backup on a second, geographically separate HSM preserves availability after device failure while keeping the private key inside certified hardware boundaries, satisfying both the no-plaintext and restoration requirements.
✗
Store the key on the HSM and replicate it to a spare HSM using the vendor's plaintext export option, then destroy the source.
Why it's wrong here
A plaintext export option, even if used only once, violates the explicit requirement that the private key never exist in plaintext outside the HSM. During the export window the key is exposed in host memory and on any intermediate medium, and destroying the source afterward does not undo that exposure. This is exactly the practice the scenario prohibits.
✗
Encrypt the private key with AES-256 in software and store the ciphertext on a hardened file server accessible only to administrators.
Why it's wrong here
Software-based encryption moves the key outside hardware protection; once the ciphertext and passphrase are both available to administrators, the private key is recoverable and can be copied. This defeats the HSM's tamper-resistant boundary and makes the root CA key subject to host compromise, so it fails the scenario's core constraint.
✗
Export the private key wrapped under a key-encryption key, store the wrapped blob on encrypted network storage, and re-import it after failure.
Why it's wrong here
Wrapping the key under a key-encryption key still produces an exportable private key blob that leaves the HSM boundary; anyone who later obtains the key-encryption key can unwrap it. This breaks the requirement that the private key never exist in plaintext (or recoverable form) outside the device, and it also weakens the non-repudiation guarantee for the root CA.

Go deeper

CAS-004 Security Engineering Practice Question

Why each option matters

Option-by-option breakdown

Related to this question