A Certified Chip Is Not a Genuine Chip

“Our devices use certified TPMs with Secure Boot on, so the platform is trustworthy from the silicon up.”

Hold that sentence still for a moment. It is carrying more than it can lift.

A certified chip is not a genuine chip.

A certificate says a design was evaluated.

A signature says an identity signed something.

Neither says that the chip on this board, the firmware in this flash, or the package in this lockfile is the genuine, unmodified instance of what was evaluated or signed.

That third question has a name.

Provenance.

It is not a sub-clause of certification.

It is not a property of a signature.

It is a separate claim about a specific unit or a specific build, and it needs its own evidence.

Every guarantee a hardware root of trust offers assumes the chip doing the measuring is the chip the manufacturer built and shipped.

If it isn’t, the thing you rely on to detect tampering is the tampered component.

It will boot, measure and attest normally.

It will also be wrong, with excellent posture.

1. “But the TPM Is Common Criteria Certified.”

Good. That is a meaningful thing to have.

It answers a design question.

A Common Criteria or FIPS 140 certificate attests to the security properties of a design as evaluated, in a specific tested configuration: a hardware revision paired with a firmware version.

It says nothing about whether the unit in your shipment is a genuine instance of that design.

Made on the certified fabrication line.

Rather than a counterfeit, a remarked part or a substitute.

“Common Criteria EAL5+ certified” is an answer to “how rigorously was this design evaluated?”

It is not an answer to “how do I know this chip is one of those?”

A buyer who treats the first as the second has answered half the sourcing question and filed the whole of it.

The certificate also has an edge in time.

It attaches to the tested configuration, so a firmware update that changes security-relevant behaviour can, depending on the scheme and the jurisdiction’s acceptance rules, invalidate it rather than roll it forward.

Vendors often pre-certify a defined set of firmware versions where the update mechanism itself was part of the evaluation.

That is a vendor arrangement.

It is not something to assume on a payment terminal because the update was signed.

A certificate is a statement about a design at a configuration.

Your device is a physical object with a history.

2. “But We Buy From a Major OEM.”

So does almost everyone.

That narrows the list of names on the silicon.

It does not verify the silicon.

TPM and secure-element manufacturing is concentrated.

Infineon, STMicroelectronics, Nuvoton and Microchip, which absorbed Atmel, are the names most consistently seen in TCG certified-product listings.

Intel, AMD and Qualcomm ship firmware TPMs built into their own processors.

Concentration has a practical consequence you should notice before an incident notices it for you.

Standardizing on one vendor’s TPM standardizes on that vendor’s implementation quirks, update cadence and vulnerability history.

TPM-Fail affected Intel’s firmware TPM and one STMicroelectronics chip.

Not TPM 2.0 as a specification.

A buyer sourcing from Infineon or Nuvoton at the time was not exposed to that particular flaw.

The brand on the box is a vendor decision.

The part in the box is a provenance question.

And the counterfeit problem is larger by volume than the implant problem.

The US Department of Commerce recorded counterfeit electronic-component incidents rising from 3,868 in 2005 to 9,356 in 2008.

That is 5,488 more incidents in 2008 than in 2005, or about 2.4 times the 2005 figure (9,356 ÷ 3,868 ≈ 2.42), against a global semiconductor market above $200 billion.

A 2012 US Senate Armed Services Committee investigation found roughly 1,800 cases of suspected counterfeit parts entering the US defense supply chain across 2009 and 2010.

Be precise about what those numbers are.

They are semiconductor-wide figures. They are not a count of counterfeit TPMs.

They establish that counterfeits move through the ordinary component supply chain at scale.

The methods are unglamorous.

Die salvaging: used silicon recovered and sold as new.

Remarking: a different or lower-grade part relabelled with a better part number.

Blacktopping: a package resurfaced to hide prior use or its original markings.

Each is harder to catch on a security chip than on a resistor.

A counterfeit or substituted TPM can pass basic functional testing while lacking the tamper-response circuitry or the certified process the genuine part was rated for.

It works.

It just isn’t the thing that was evaluated.

The industry response went into standards rather than a single fix: SAE AS5553 in April 2009 for avoidance, detection and disposition, and AS6081 in November 2012 adding inspection requirements adopted into US DoD procurement.

3. “But the Supermicro Story Was Debunked.”

It wasn’t debunked.

It wasn’t confirmed either.

That is the precise and slightly uncomfortable position.

Bloomberg Businessweek’s October 2018 “The Big Hack” alleged covert hardware implants on Supermicro server motherboards, reaching roughly 30 US companies and government agencies.

Apple, Amazon and Supermicro issued specific, detailed denials.

Supermicro told the SEC it found no evidence of malicious implants after review.

No government agency or independent researcher has publicly corroborated the central claim since.

Reported, denied, uncorroborated.

Not “debunked”, which claims a refutation nobody has published.

Not “true”, which claims a corroboration nobody has published.

And here is why the objection misses anyway.

Your argument for provenance does not rest on Supermicro.

It rests on a documented programme.

NSA Tailored Access Operations ANT catalog documents, published by Der Spiegel in December 2013 and dated to 2008-2009, describe GODSURGE.

A JTAG-based implant added to Dell PowerEdge servers “during interdiction”.

While the hardware was in transit, before the customer took delivery.

The same catalog describes firmware-level tooling aimed at hard-disk controllers.

That is the attack class, operationalized, on paper.

It is also a state programme.

It does not mean every buyer is an interdiction target.

It means that “the hardware arrived sealed from a reputable vendor” is not, by itself, evidence about what is on the board.

Hold both cases in the same hand.

One proves the threat is real.

The other shows how easily the same fear produces a claim that should not be repeated as settled.

4. “But Secure Boot Is Enabled Across the Fleet.”

Enabled is one clock.

Current is another.

Your dashboard is probably showing you the first.

Secure Boot verifies each stage against a trusted-signer list before running it.

A signature stays trusted until it is revoked in dbx, whether or not the underlying bug has been patched somewhere else.

BlackLotus is the dated evidence.

A UEFI bootkit first observed in the wild in 2022 and detailed publicly in 2023.

It did not forge a signature.

It did not break the cryptography.

It used CVE-2022-21894, “Baton Drop”, in an older, legitimately Microsoft-signed Windows bootloader that had been patched but never added to dbx.

Secure Boot kept trusting that binary exactly as designed.

BlackLotus used it to load unsigned code before the Windows kernel started, and persisted in the EFI System Partition, where most antivirus tooling does not look.

The signature check worked. The revocation list was stale.

That is an operational gap, not a mathematical one.

So your fleet has two separate questions.

Are the latest signed components installed?

Has dbx been updated for every revocation since the platform was provisioned?

A report saying “Secure Boot: enabled” answers neither of them completely.

It reports a necessary condition and lets you read it as a sufficient one.

Even “enabled” is not one guarantee across operating systems.

Most Linux distributions boot through shim, a small Microsoft-signed bootloader that trusts a distribution key.

Ubuntu’s shim trusts a signed bootloader but permits an unsigned kernel by default.

Fedora extends signature verification through the kernel and loadable modules.

Same toggle, same certified hardware, different chain.

5. “But Every Firmware Update Is Signed by the Vendor.”

Signed by whom is a good question.

Verified by what, and refusing what, are better ones.

A boot chain is only as strong as the mechanism that replaces firmware in the field.

If an image is accepted without verification, or checked by something an early compromise can bypass, the device will boot, measure and attest normally.

Because the compromised firmware is now the thing doing the measuring.

Verification has to happen at the earliest stage. The update package should be signed by a key the boot ROM or earliest firmware checks before flashing.

Not a key checked only by an operating-system updater.

Then there is the downgrade.

A signature check accepts any image signed by the right key.

Including last year’s image.

Including the one with the published vulnerability.

A validly signed, outdated firmware image passes plain signature verification completely.

Anti-rollback counters exist for exactly that case.

One-way non-volatile counters inside the root of trust enforce a minimum version, so “install the old, signed, vulnerable build” fails even when the attacker holds a legitimate copy of it.

Signed is an identity property. Current is a version property.

They need different mechanisms, and a vendor signature supplies only the first.

6. “But the Package Came From the Official Registry.”

The registry checked who published it.

That is what registries check.

npm requires two-factor authentication, or a scoped access token, before an account can publish a package or change its settings.

PyPI required 2FA for every account maintaining a project or organization by the end of 2023.

Both are account controls.

Neither inspects what the code does.

npm relies on user reports to take down packages that are malicious, insecure or low quality.

Detection is reactive.

crates.io sits on a different model again: its most visible security layer is RustSec, a community advisory database consumed through cargo-audit and fed into OSV and GitHub’s Advisory Database.

That tells you about vulnerabilities already found.

It does not vouch for a publish.

npm provenance and PyPI Trusted Publishing are real improvements.

A CI platform acts as an OpenID Connect identity provider and issues a short-lived token scoped to one repository and workflow run, instead of a long-lived password pasted into a config file.

Notice where the trust went.

To the CI provider: in npm’s case GitHub Actions or GitLab, its two supported provenance providers.

That is a better identity.

It is still an identity.

Every party in the chain does the same thing.

The maintainer is trusted by the registry.

The registry is trusted by the vendor.

The vendor’s build is trusted by the customer through a signature.

The SolarWinds Orion update, covered in the SBOM review, was signed by its genuine pipeline and still carried a backdoor. The customer had no independent way to tell.

What would let an outsider check the artifact rather than the identity?

A reproducible build.

Building the same source always produces bit-for-bit identical output, so any third party can rebuild from published source and compare, instead of trusting the original builder’s attestation.

Ordinary CI makes no such promise.

Timestamps, filesystem ordering, environment variables and non-deterministic tools make two honest builds differ.

Reproducibility is most mature in a handful of security-conscious open-source projects and Linux distributions.

It is rare in commercial vendor pipelines.

7. No, This Does Not Mean Certification Is Worthless.

It isn’t.

A certified design is a better starting point than an unevaluated one.

A signed update is better than an unsigned one.

A registry that enforces 2FA is better than one that doesn’t.

Each control answers its question honestly.

The failure is asking it a different question.

Nor does this mean every buyer should X-ray every TPM, or treat a shipment from a distributor as a state operation in progress.

The documented interdiction case is a state programme.

The Supermicro allegation is uncorroborated.

Physical exposure differs too: a chip in a locked, access-logged data centre faces a different attacker from a payment terminal in a public kiosk, and tamper-evident, tamper-resistant and tamper-responsive packaging are separate choices sized to that exposure.

The point is narrower.

Certification and signatures answer design and identity questions.

Provenance is a separate question.

High-assurance deployments have to answer it on purpose, because nothing else answers it for them.

8. What You Should Actually Do

Buy security-critical components through authorized distributors. Check package markings against the vendor’s published references.

For the highest-assurance deployments, budget for physical inspection of samples: X-ray, decapsulation, scanning acoustic microscopy, the same toolkit built for counterfeit detection elsewhere.

Report Secure Boot state and dbx currency as separate fleet metrics. An enabled toggle with a stale revocation list is a partially configured control with a green light.

Require firmware updates verified by the earliest boot stage, with anti-rollback counters enforced so an old signed image cannot come back.

Confirm which firmware versions a certificate covers before updating a regulated device, rather than assuming the vendor’s signature carries the certification forward.

Prefer dependencies built reproducibly or published with CI-issued provenance. Where neither exists, record that you are trusting an identity, and whose.

Then write down, per component, which of the three questions you have evidence for.

Design.

Identity.

Provenance.

9. The Actual Model Is Not Complicated.

A certificate answers: was this design evaluated, and in which configuration?

A signature answers: did this identity sign this artifact?

A registry answers: is this the account that publishes this name?

Provenance answers: is this unit, this image, this build, the genuine and unmodified instance of the thing those answers describe?

The first three are necessary.

None of them is the fourth.

Counterfeit counts, registry policies and certification scopes are dated evidence and will move.

The gap between a design and the object in your hand will not.

A certified chip is not a genuine chip.

It is a genuine design, and a question about the chip.