skip to content

An issuing authority's signing key is held in a hardware module and cannot be exported - what does that stop, and what does it not?

level: seniorimportance: should knowfreq 46%

answer

  1. custody and use are different things
  2. no file to steal
  3. the module answers, it does not judge
  4. compromise bounded by access, not forever
  5. backup is decided at generation only

basics

~20 s

It stops the key being copied out, so no attacker can run a duplicate authority you cannot see. It does not stop the key being used: whoever controls the signing service in front of the module obtains genuine certificates for as long as that access lasts.

solid answer

~50 s

Non-exportable storage separates **custody** from **use**. The key material is generated inside a hardware security module and never leaves it in any form, so there is no file to steal, no backup to find, and no silent copy running somewhere else. What the module offers instead is an operation: authenticate to it, hand it bytes, get a signature back. It enforces its own access control, but it has no view of your issuance policy - it cannot know whether the requester was entitled to a certificate for that name. So an attacker who compromises the signing service does not need the key; they ask the service, which asks the module, and the certificates that come out are genuinely signed and keep validating long after the intrusion ends. Non-exportability bounds the compromise to the window of access, which is exactly its value.

code

pseudocode · 10 lines
pseudocode
function issue_certificate(request, caller):
    if not authenticated(caller):
        reject "unknown caller"
    if not permitted_names(caller, request.names):
        reject "name outside this caller's scope"    // policy lives HERE

    tbs = build_TBSCertificate(request)
    signature = module.sign(tbs)                     // module checks only its own access
    record(caller, request.names, tbs.serialNumber)  // the reconciliation trail
    return certificate(tbs, signature)

go deeper

for a junior

Recall that the key is generated inside the device and never comes out, so there is no key file anywhere to protect.

for a middle

Explain the split between custody and use, and why an attacker with access to the calling service does not need the key itself.

for a senior

Show where the controls actually go - requester authorisation, name constraints, quorum, rate limits and a reconcilable issuance record - and how you would bound the damage of a one-hour intrusion.

for a principal

Weigh the symmetry: the same refusal that stops exfiltration stops your own recovery, so the cloning or split-custody decision has to be made and rehearsed at generation time.

## What non-exportable actually means A hardware security module generates a key pair internally and exposes the private half only as a capability: callers that authenticate to it may ask for a signature over bytes they supply. There is no interface that returns the private key, encrypted or otherwise. That single property changes the shape of the whole risk model, because it splits two things that a key in a file combines - **having the key** and **being able to use it**. ## What it stops - **Exfiltration.** There is no file to copy, no export container to intercept, no backup tape carrying it. - **A parallel authority.** Nobody can stand up a second issuer with the same key elsewhere and keep issuing after you have cleaned up your own systems. - **Unbounded damage.** Because use requires access to the service in front of the module, the compromise is bounded by the period of that access rather than continuing indefinitely. - **Accidental spread.** Keys in files end up in images, snapshots and developer laptops without anybody deciding that they should. A key that cannot leave cannot drift. ## What it does not stop - **Use by whoever controls the caller.** The module authenticates its callers; it does not evaluate whether this particular certificate should be issued for this particular name. - **Mis-issuance.** Certificates produced during an intrusion are genuinely signed. They validate exactly like legitimate ones, before, during and after the intrusion, and there is no property of the module that marks them retrospectively. - **Coercion or insider action.** An operator with legitimate access can obtain a signature legitimately, which is not a defect of the module but a reason the controls have to sit elsewhere. - **Availability loss.** A module that fails, is decommissioned, or cannot be reached stops all issuance. | threat | does non-exportable hardware storage help? | |---|---| | stolen backup containing the key | yes - there is no such backup | | compromised signing service | no - the attacker uses the key rather than taking it | | a rogue operator with legitimate access | no - their access is the point of entry | | key lingering in a machine image | yes - it never became bytes | | destruction of the module | no - this is the cost side, not the benefit | ## Where the real controls sit Because the module cannot make policy decisions, every meaningful control lives in the layer that calls it: 1. **Authorisation of the requester** - who may ask for a signature at all. 2. **Constraint on what may be asked** - which names, which profile, which lifetime; these are checks the calling service performs before it ever builds the `TBSCertificate`. 3. **Quorum on the dangerous operations** - anything that certifies another issuer, or changes what the service will sign, requiring more than one person. 4. **Rate and anomaly limits** - a burst of issuance is one of the few live signals you get that something is wrong. 5. **A reconcilable record** - a log of everything signed that can be compared against what should have been signed. Without that comparison you cannot answer the only question that matters after an intrusion: what came out during the window? The hardware protects the secret. The service protects the decision. Conflating the two is the classic error, and it shows up as a design where the module is treated as the security control and the calling service is treated as ordinary infrastructure. ## The problem you must solve at generation time A key that can never leave also cannot be backed up as a file, and that is a genuine operational hazard: if the module dies and the key was the anchor for everything below it, the loss may be as expensive as a compromise. There are two ways out and both are decisions taken **when the key is generated**, not later: - **Clone into a second module** during the generation event, so a standby holds the same key under the same protections. - **Split the key's recovery material among several custodians** at generation, so no one person can reconstitute it and a quorum can. Afterwards neither option is available, because the key cannot be extracted to make them. This is the most common way teams discover that the property they bought is symmetric: the same refusal that keeps an attacker from copying the key keeps you from copying it too. ## How to answer this in an interview Name the split explicitly - custody versus use - then give one consequence on each side: no silent duplicate authority, and no protection against an attacker who simply asks. Finish on where the controls therefore live, and on the backup decision that can only be made once.

  • An intruder held access to the signing service for one hour. What is your recovery plan?
    Reconcile every signature produced in that window against what should have been issued, then withdraw everything unaccounted for. The key itself need not be replaced, because it never left - which is the return on the hardware. If the record is not reconcilable, you cannot bound the damage and the honest answer becomes replacing the issuing key entirely.
  • Why does moving an existing key into a hardware module not give you the same property?
    Because the key existed as bytes before it was imported, so every copy made along the way still exists and the module cannot retract them. Non-exportability is only meaningful for a key that was generated inside and never had another form; an imported key inherits the exposure of its whole prior life.
  • Does the module's own log answer the question of what was mis-issued?
    Only partially. A module records the operations it performed, not whether they were authorised by your issuance policy, which it cannot see. You need the calling service's record of requester, names and serial numbers, reconciled against an independent expectation of what should have been issued.

saying these in an interview costs you the question

  • Says a hardware-held key cannot be misused.
  • Believes certificates signed during an intrusion stop validating afterwards.
  • Thinks the module enforces which names may be certified.
  • Assumes an imported key gains non-exportability retroactively.
  • Plans to back the key up to a file after generation.
  • Treats the module as the control and the calling service as plumbing.