A Validated Module Is Not a Protected Key

“Our keys live in a validated module and our TLS scores an A, so they are protected.”

Two true facts.

One false conclusion.

A validated module is not a protected key.

A validated module is a module whose design and algorithm implementations passed a defined test, at a defined time, in a laboratory.

An A is what a live server offered an outside probe on the day it was scanned.

Both are real evidence.

Neither is evidence about the key.

A key has a life.

It is generated.

It is used.

It is rotated, or it is supposed to be.

It is certified by somebody else, who may or may not tell you when they have been breached.

The key failures on record happened at those stages.

A key made from a guessable seed.

A certificate reissued over the same exposed key.

A certificate authority that knew it was breached and said nothing.

None of those stages is what a validation certificate or a scan grade observes.

You would not say “the safe passed its drill test, so the combination was never written on a sticky note.”

Say the same thing about an HSM and a TLS grade and it gets a slide in the architecture review.

1. “But the Module Is FIPS 140-3 Validated.”

Good.

That is a real check.

Under the Cryptographic Module Validation Program, accredited Cryptographic and Security Testing Laboratories, themselves accredited by NVLAP, evaluate the complete module.

Its interfaces.

Its role-based authentication.

Its physical security, where applicable.

Its self-tests.

The testable requirements are based on ISO/IEC 19790:2012 and ISO/IEC 24759:2017.

FIPS 140-3 defines four increasing security levels, so “validated” without a level tells your reader very little.

Ask which level, for which module, on which certificate.

Now look at when and what that check observed.

It happens before deployment.

It evaluates a module, not a key.

And it is dated: a validated module stays on the CMVP active list for up to five years, two on the interim-submission track, after which it is revalidated or it leaves the list.

So the validation says the box was built and tested to a bar.

It does not say which keys you put in the box.

Or where they were generated before they arrived.

Or whether the key in slot three is the one you think you rotated last spring.

The certificate describes the container. Your auditor is asking about the contents.

2. “But the Library Passed Its Algorithm Tests.”

Then you have evidence one layer below the module.

The Cryptographic Algorithm Validation Program tests individual algorithm implementations: AES, RSA, ECDSA, SHA-2/3, HMAC and so on.

Its Automated Cryptographic Validation Test System sends the implementation a battery of test vectors as a black box and checks the outputs.

The vendor never hands over source code.

Passing CAVP for every algorithm a module uses is a prerequisite for CMVP.

It is not a substitute for it.

Algorithm validation is not module validation, and that is exactly where vendor marketing likes to blur the sentence.

But notice what a test vector is.

A known input, an expected output.

It asks whether the implementation computes the algorithm correctly.

It does not ask where your key came from.

That question has a canonical answer, and it is not flattering.

CVE-2008-0166 was a Debian-specific patch to OpenSSL.

It was uploaded to the unstable distribution on 17 September 2006 and propagated into the stable release.

It broke the package’s random-number seeding and reduced the effective entropy of generated key material to a small, guessable range.

SSH host and user keys.

OpenVPN keys.

DNSSEC keys.

X.509 certificate keys.

Anything generated on an affected Debian or Ubuntu system in that window.

The advisory, DSA-1571-1, did not hedge: every DSA key ever used on an affected system for signing or authentication was to be considered compromised.

Not suspect.

Compromised.

This was not a weak-encryption story.

The algorithms were fine.

The entropy feeding key generation was not.

An attacker did not need to steal those keys.

They could recompute them from a small search space.

A key that was weak at birth inherits none of the protection that careful storage or rotation is supposed to add.

Put it in the best-validated module you can buy and it is still a guessable key in an expensive box.

Protocol behaviour is a third layer again.

Conformance suites such as BoringSSL’s test runner drive an implementation through a matrix of valid and malformed handshakes, with the protocol logic implemented twice so a shared misreading of the specification does not produce a false pass.

A library can pass algorithm vectors and fail that.

It can pass that and still have been fed a bad seed.

Three layers. Three pieces of evidence. None of them is the key.

3. “But We Score an A on SSL Labs.”

Excellent.

Now say what the A measured.

SSL Labs grades a live, internet-facing endpoint from outside, with no access to code or configuration files.

It sees what a client sees in a handshake.

Protocol support is weighted at 30%.

Key exchange at 30%.

Cipher strength at 40%.

A score of roughly 80 or above maps to an A.

Then come the override rules, which matter more than the weights.

A name mismatch, an expired or self-signed certificate, or a chain to an untrusted root forces a failing grade, however strong the ciphers.

Under the guide’s 2009r revision, a server without TLS 1.3 is capped at A-, even with every other category perfect.

That is useful evidence about negotiation and trust configuration on one endpoint on one day.

It cannot see server-side key storage.

It cannot see an internal-only misconfiguration that is invisible from outside the network.

It has no input at all for how the private key behind that certificate was generated, or whether it was ever exposed.

A key recomputed from a guessable seed negotiates a handshake exactly as well as a good one.

And the layers do not vouch for each other in either direction.

A FIPS-validated module deployed with a misconfigured certificate chain still fails the scan.

A perfectly configured server on a library with an unpatched conformance bug scores well until the bug is triggered.

The grade is a photograph of the front door. It is not a custody record.

4. “But the Vendor Is Certified.”

Certified to what, and what kind of document did that produce?

The four documents most often called security standards produce four different kinds of evidence: ISO 27001 an accredited certificate, NIST SP 800-53 an authorization, NIST CSF a self-assessment, and CIS Benchmarks a scan score.

They also sit at four different scopes.

A management system.

An organisation’s risk posture, expressed as outcomes.

A system with a defined boundary.

A single host or image, at one product version.

None of those four scopes is “this key”.

A certificate that the vendor runs an auditable management process is a genuine statement about the vendor.

An authorization for a system says a control baseline was assessed for that system.

A CIS-CAT Pro score says one host matched a Level 1 or Level 2 profile.

A CSF profile says what the vendor assessed about itself.

Not one of them says the signing key you depend on was generated with adequate entropy and replaced after its last exposure.

The editions are dated evidence too.

SP 800-53 Revision 5 received its 5.2.0 point release on 27 August 2025.

CSF 2.0 was published on 26 February 2024.

Record which document a vendor’s claim rests on, which kind of evidence it produced, and when.

Then stop asking the certificate a question it was never built to answer.

5. “But We Reissued Every Certificate After the Incident.”

Did you replace the keys, or did you replace the paperwork?

Heartbleed, disclosed in April 2014, let an attacker read up to 64 KiB of a server’s memory per request.

Private-key extraction was not theoretical.

Researchers recovered a private key from a server set up to test exactly that, within hours of disclosure.

At disclosure, an estimated 17% of the internet’s secure web servers, roughly half a million, were vulnerable.

Then the remediation numbers.

By 9 May 2014, only 43% of affected sites had reissued their certificates at all.

Of the sites that did reissue, 7% reused the same, potentially compromised key material.

Work it through per 100 affected sites: 43 reissued, and 7% of 43 is about 3.

So roughly 3 in every 100 affected sites had done the visible thing, a new certificate, over the key that may already have left the building.

Another 57 had not reissued at all.

By 21 June 2014, more than 309,000 public web servers were still vulnerable outright.

That 3-in-100 group is the one to worry about, because it looked finished.

A reissued certificate reads as “rotated” on a dashboard whether or not the key underneath changed.

The new certificate is valid.

The chain is correct.

The scan grade does not move.

The module holding the key is still validated.

Every check in this article passes.

The key is still the exposed one.

Rotation after exposure means new key material first, then a certificate for it.

Anything else is renewal with better intentions.

6. “But Our CA Would Tell Us If It Had Been Compromised.”

It might.

Eventually.

On its own schedule.

DigiNotar, a Dutch certificate authority, was breached in June 2011.

On 10 July 2011 the attacker used that access to issue a fraudulent wildcard certificate for Google.

It was used for man-in-the-middle interception against an estimated 300,000 Iranian Gmail users.

DigiNotar detected an intrusion internally by 19 July 2011, nine days after that certificate was issued.

It did not disclose.

The breach became public in late August, weeks later, after outside researchers identified the fraudulent Google certificate independently.

At least 531 fraudulent certificates were eventually traced to the compromise.

The company filed for bankruptcy by late September.

Detection and disclosure are two separate events.

The party that controls the first has no structural reason to hurry the second.

Your trust in an issuer is a lifecycle dependency of every key it certified for you, and nothing about your own module, your own algorithm tests or your own scan grade watches it.

Certificate Transparency exists to remove exactly that dependency.

Under RFC 6962, certificates go into public, append-only logs built on Merkle hash trees, where modifying a logged entry changes the root hash.

A log issues a Signed Certificate Timestamp promising to incorporate the certificate within a bounded delay, and browsers require that promise.

Google Chrome required CT for all publicly trusted certificates from April 2018.

The mechanism caught more than attackers: Symantec’s issuance of 187 certificates without the domain owners’ knowledge surfaced through monitoring.

But CT is an audit mechanism, not an alarm.

A domain owner can monitor the logs for any certificate issued for its domains, whichever CA issued it.

Somebody has to actually do that.

7. No, This Does Not Mean Validation Is Theatre.

It isn’t.

CAVP tells you the algorithms compute what they should.

CMVP tells you a specific module’s design and implementation met a fixed federal bar.

A conformance suite tells a library maintainer the handshake state machine survives malformed input.

A scan tells an operator what a real client is offered today.

A certificate, an authorization, a self-assessment and a scan score each tell a buyer something different and real about an organisation, a system or a host.

A validated module is a sound place to hold a key.

Use one.

Name its level.

What this article refuses is the last step of the sentence.

No single check certifies how a key was generated.

No single check certifies that it actually changed on rotation.

No single check certifies that its issuer disclosed a compromise.

Those are separate claims, and each needs its own evidence.

8. What You Should Actually Do.

Map evidence to stages, per key class. For each class of key, record which evidence covers which layer: the CMVP certificate and security level for the module, CAVP for the algorithms, conformance testing for the protocol library, an external scan for the live endpoint.

Write the dates next to them.

Five years on an active list is a long time to stop reading.

Treat generation as evidence, not an assumption. Record where each key was generated and on what system.

If a system is later found to have had an entropy flaw, treat every key generated on it as compromised, as DSA-1571-1 did.

Not “under review.”

Compromised.

Confirm new key material on every rotation. A new certificate is not proof of a new key.

Check that the key changed, not only that the expiry date moved.

Monitor Certificate Transparency logs for your domains. Do not wait for your issuer’s press release.

Classify every vendor claim. Is it a certificate, an authorization, a self-assessment or a scan score?

For which scope?

As of when?

Then ask the question none of them answers: for the keys you depend on, how were they generated, when did they last actually change, and who would know if the issuer had been compromised?

9. The Actual Model Is Not Complicated.

Every check observes one layer at one moment.

CAVP: the algorithm, before deployment.

CMVP: the module, before deployment, for up to five years.

Conformance testing: the protocol implementation, against a test matrix.

A scan: the live endpoint, today, from outside.

A standard: an organisation, a system, an outcome profile or a host.

A key’s protection is a lifecycle claim, and no single check makes it.

Generation, rotation and disclosure are where the recorded failures happened.

Evidence them stage by stage.

Otherwise you have a validated box, a good grade and a certificate on the wall.

And a key you cannot actually vouch for.