A valid signature on a firmware image proves that someone with access to the signing key used it. It does not prove that anyone approved that image for release. A TPM-based remote attestation verifier should check two things separately. First, the device’s signed measurements must verify and be fresh. Second, we would require the measured image hash to appear on a backend-held signed allow-list approved by a second, independent release manager. When policy checks signatures alone, whoever holds the build key can push updates as if they were the legitimate owner.

TechnoLynx designs this separation for device fleets. That means an allow-list schema and a release-manager approval workflow kept apart from build signing, attestation checks that validate both the signature and allow-list membership, backend verification keys protected by TPM 2.0 or another hardware root of trust, and a fleet-wide revocation path that is built and tested before anyone needs it. We would start with the allow-list schema and the approval workflow, because every other check is made against them.

Why a validly signed firmware image is not an image authorised for release

Signing an image manifest guarantees that only holders of the signing key can produce valid signatures, and it lets anyone verify integrity later. A valid signature does not show whether the signer still had authority or whether the key had been compromised. The nhimg.org FAQ on compromised signing keys calls this the difference between cryptographic validity and trust validity: a signature can verify perfectly and still be unsafe to rely on if the key has been compromised, the certificate revoked or the signing role changed.

The IETF manifest model for IoT firmware updates states the consequence plainly. A third party that obtains a key trusted for firmware updates, or even indirect access to one through an HSM, can perform firmware updates as though it were the legitimate owner. The HSM detail matters. If manifest signing runs on an internet-connected server, an attacker who compromises that server can sign manifests even though the keys never leave the HSM.

Two public incidents show what a compromised signature or a leaked signing key means in practice.

• Operation ShadowHammer. Kaspersky found trojanised ASUS software whose digital signature was intact, valid and verifiable, and concluded it was looking at a compromised signature rather than a broken one. The software was signed with legitimate “ASUSTeK Computer Inc.” certificates, which is partly why it went undetected for so long. The same two certificates had signed at least 3000 legitimate ASUS files, so revoking them was very hard.
• The MSI key leak. In May 2023, Help Net Security reported Binarly’s analysis of leaked MSI data. It contained private firmware signing keys for 57 MSI products and private Intel Boot Guard keys for 116. Leaked Key Manifest and Boot Policy Manifest keys could be used to sign malicious firmware that passes Boot Guard, the check that refuses firmware not signed with the OEM key fused into the chipset.

In both cases the cryptography worked exactly as designed. The policy was the gap: it treated “signed by the expected key” as the whole definition of trusted.

What a passing TPM attestation proves about the image a device booted

Remote attestation is a challenge-response protocol. A verifier uses it to establish that a prover is in an acceptable state at the time attestation was requested. With a TPM, the verifier asks for a quote, a signed report of the Platform Configuration Registers that hold a rolling hash of the boot measurements. The verifier checks the attestation key’s certificate to confirm the device’s identity. It then replays the event log against the signed digests and compares the logged digests with reference values.

RFC 9683 (Remote Integrity Verification, IETF) sets out when a device should not be trusted:

• the signature over the TPM evidence is wrong;
• the nonce does not match;
• the PCR values do not match the log;
• the important log entries do not match known-good values.

It adds a freshness rule. Evidence older than the appraisal policy’s threshold is stale. A passing attestation therefore tells you three things: which measurements this specific TPM reported, that the report is recent and not a replay, and that the measurements match whatever the verifier treats as known good.

Identity carries a lot of that weight. Signed evidence that a particular software version was loaded is of little value without cryptographic proof of which attester produced it. This is why RFC 9683 requires the attestation key (AK) to differ from the device identity key (DevID), so an identity key cannot sign a spoofed quote. The AK certificate must also carry the same device identity as the DevID, binding the AK to the device against a person-in-the-middle attack. The same identity point has a physical edge. A TPM that already holds an authentic DevID, stolen and fitted to a counterfeit board, can make that board indistinguishable from a genuine one.

What attestation does not prove is that the image is the right one. RFC 9683 says RIV can reliably show that a known, untampered package is running. Deciding whether it is the correct package for the application is the device owner’s job. RFC 9334, the IETF RATS architecture, makes a similar point from the authorisation side. A policy that treats every compliant device from a manufacturer the same is inappropriate as the only basis for authorisation where the owner wants to restrict which devices are allowed. Measurement shows which known package is running. Release authorisation is the owner’s separate statement that this hash should run.

How to keep the release allow-list separate from the signature check

The RATS architecture’s appraisal policies already have a place for an allow-list. The verifier appraises evidence against reference values and endorsements using an Appraisal Policy for Evidence. A relying party then applies its own policy to the attestation results to make authorisation decisions. One of the constraint types RFC 9334 lists is membership in a set of reference values. A release allow-list is exactly that: the set of image hashes the owner has approved. In RFC 9683’s terms, appraisal matches evidence against reference values, the golden measurements that represent the intended configured state.

Keylime is a concrete example. Its runtime policy is a set of golden hashes loaded into the verifier. The verifier polls TPM quotes and puts the agent into a failed state if any measured file does not match. For boot, the Keylime verifier replays the measured boot log against the quoted PCRs and then evaluates the attested log against the operator’s measured boot policy, failing attestation if the log does not conform. Keylime’s documentation also notes a limit of signature checks compared with the hash list. IMA signature verification establishes provenance, but unlike hashes it does not protect against files being swapped for other signed versions, which is a downgrade. A compromised key and a build with newly found vulnerabilities are both reasons to revoke valid signatures.

Microsoft’s Azure Host Attestation Service validates each host’s evidence against an attestation policy that defines the secure state. In Azure’s fleet, a host that fails is not trusted, has its communications blocked and is investigated before it can rejoin.

Appraisal order for a release-gated attestation

In our design, the verifier runs these checks in order. Each one has to pass before the next one counts:

1. Attester identity. The AK certificate matches the DevID subject and the same manufacturer authority.
2. Quote signature. The signature over the TPM evidence verifies.
3. Freshness. The quote’s nonce equals the verifier’s nonce, and the evidence is within the policy’s freshness threshold.
4. Log integrity. The event log replays to the quoted PCR values.
5. Release authorisation. The measured image hash is a member of the current allow-list.
6. Allow-list authenticity. We would require the allow-list to verify, carry the release approvals and be the latest accepted version.
7. Relying-party decision. The service that grants access or workloads applies its own policy to the result.

Steps 5 and 6 are where release authorisation lives, and we would make them fail closed, treating a signed hash not on the list as unknown. RFC 9683 says the supplier should deliver reference values as signed RIMs, classifying configurations as known good, known bad or unknown. It also leaves the trust procedure for those RIMs to the owner. We would put the owner’s own allow-list in that leeway. A supplier’s RIM can feed the list, but it should not be the list.

We would have an allow-list entry record at least the image hash, the product line and version, a monotonic release counter, and the approvers’ identities. The verifier can then reject rollbacks and cross-line reuse without consulting anything else. We would model that verification on Uptane’s checks of version numbers, expiration timestamps, delegations, signatures and hashes.

Should a second, separate release-manager approval be required before an image is allow-listed?

Yes. Without one, the allow-list is just a second signature from the same pipeline, and the build key still decides alone. NIST SP 800-53 control CM-5(4), dual authorisation, requires two individuals who can each judge whether a change correctly implements an approved change and who are each accountable for it. Organisations also consider rotating those duties to reduce the risk of collusion. The IETF manifest model gives the same idea a device-side form. A device can require firmware to carry both an Authorship right and a Qualification right held by different parties, and then it cannot install the firmware without proof from both.

Some container supply chains work this way. AWS describes re-signing an image with another key after review or scanning, and having the pipeline block any image without that signature from moving to higher environments. The Update Framework (TUF) makes the same idea structural: new root metadata must be signed by a threshold of keys, and each key counts only once.

Where the keys live matters too. Uptane separates an Image repository run by human administrators with offline keys from a Director repository that uses online keys and automated processes. It also says supplier signing keys should not be reachable from the Image repository and should be well secured, so a compromise affects some ECUs and not all. For an attestation backend, we would hold the release-manager approval key offline or in a separate HSM with its own access path, never on the build server. RFC 9124’s warning about an online signing server applies to the approval key just as much as to the build key.

The cost is real. A second approval adds a step before release. It also needs organisational discipline, because a gate that gets bypassed under deadline pressure, or rubber-stamped by the same person who triggered the build, gives no independence.

What an attacker holding a stolen signing key can still do

When the build key is the only key that matters, an attacker holding it can sign malicious images that pass signature verification. That image then installs as though the attacker were the legitimate owner. In our design, the attacker’s image still verifies cryptographically, but its hash is not on the allow-list, so an attesting device that boots it fails step 5 and loses fleet trust.

That leaves three residual risks, and it helps to name them honestly:

• Devices that never check revocation. Devices in the field that never phone home keep trusting the old key.
• Previously approved but vulnerable builds. Signatures alone do not protect against a downgrade to older signed versions.
• The approval path itself. If the allow-list signing path is compromised too, the separation collapses back into one point of trust.

Uptane notes that an OEM can use its inventory of installed versions to spot abnormal installation patterns that suggest a key compromise. Attestation records give an operator the same kind of signal.

How to revoke trust across the fleet in images signed with a compromised key

Revoking the certificate is not enough. Revocation stops new signatures validating only on systems that check revocation status. It does not make deployed devices distrust the key, and many of those devices never check. A leaked firmware signing key is a full recovery event: you identify every model and firmware version signed with it, rotate to a new key held in an HSM, and push an update signed with the new key. Devices with no connectivity or no update mechanism may stay exposed permanently. Revocation data also helps only when validation logic actually consults it. Cached responses, offline verification and skipped status checks are named failure points.

In our design, the allow-list gives the backend a revocation lever that does not depend on every device fetching a revocation list. Removing an entry is a whitelist-style revocation: a credential is revoked by taking it off the permitted list and, if needed, adding its replacement. In our design, removing every hash signed by the compromised key makes the next attestation fail for devices running those images. Those devices then drop out of fleet trust, as in Azure’s model, until they are investigated and remediated.

For a compromised key, we would treat new signatures as untrusted immediately and review older ones before accepting them again. In practice, that means taking every allow-list entry signed by the compromised key off the list, re-adding only those you can re-verify from an out-of-band record of the original build, and re-signing those with the new key. Uptane’s recovery sequence covers the rest. Use the root role to revoke and replace the affected keys, restore the repository from an offline backup to a known good state, and update the fleet to replace metadata and images.

The limits matter. In our design, allow-list revocation takes effect when a device next attests, so offline devices stay exposed until they make contact. A malicious device may also ignore an instruction to drop revoked credentials and try to keep using them. One paper on TEE credential management therefore proposes reporting such misuse to an authority that can decommission the device.

The attestation service becomes the system you have to keep running

Moving release authority onto the backend makes the allow-list and verifier a critical dependency. If that service is unavailable or compromised, the fleet either cannot attest or attests against the wrong policy. That calls for the same hardening as any trust root: verification keys anchored in hardware, high availability, a decision on whether devices fail closed or open when they cannot reach the service, and an audited change process for the allow-list itself. For the key-protection side, see our guide to anchoring OTA signing and attestation to a hardware root of trust.

A release gate that is never exercised can fail silently. We would run allow-list rejections, approval-bypass attempts and a revocation drill as scheduled tests. A first live run during an incident is too late. Our production AI reliability work applies the same idea to AI systems, with release gates that catch failures before customers do.