Factory Test Keys in Release Firmware: Build a Gate That Detects Accidental Trust
Gate release on the public identities accepted by the shipping verifier, then prove that an otherwise valid development-signed image is rejected. A production signing job can use the intended key while an independently built bootloader still contains development trust.
This guide pins MCUboot v2.2.0’s Zephyr compiled-public-key integration. Hardware-key and built-in-key interfaces require their own trust-source evidence. It provides a review and qualification method, not instructions to replace keys, change fuses or reconfigure deployed devices. No key operations or target tests were performed.
1. Separate producer identity from verifier trust
Create two inventory rows. The producer row identifies the public identity corresponding to the approved signing service. The consumer row identifies the public identities the final bootloader can accept. A match is necessary for the intended release, but the consumer must also exclude every unintended identity.
The pinned image-tool guide explicitly warns against production use of the distributed development key because its private material is widely available. The review needs only public identities; do not copy private keys into a release archive or this worksheet.
Define a canonical public-key representation and fingerprint method for comparison. Record the encoding and algorithm context so a PEM-file digest is not accidentally compared with a digest of a different public-key serialization.
2. Resolve the exact build input
The Zephyr key-file setting supplies algorithm-dependent default filenames. Review the resolved bootloader configuration rather than assuming an application build’s signing choice also changed the bootloader.
The tagged build logic resolves absolute paths directly, otherwise checks the detected configuration directory and then the MCUboot repository. It generates public-key source and includes it in the bootloader build.
Retain the resolved path as build evidence, while keeping private filesystem details out of public deliverables. More importantly, retain the public identity derived from that input and its relation to the linked verifier material. A filename containing “production” establishes neither identity nor authorization.
| Evidence layer | Question | Insufficient substitute |
|---|---|---|
| Approved trust policy | Which public identities may authorize this product? | A human-friendly key filename |
| Resolved configuration | What input did this bootloader build select? | An application signing setting |
| Generated public-key source | Which identity was emitted for verification? | An intended input in an old build log |
| Linked binary | Was that material actually included without unintended alternatives? | A generated file left outside the link |
| Acceptance behavior | Does the final verifier enforce the approved set? | Successful signing or one successful boot |
3. Treat the default-key warning as a lead
The scoped CMake logic emits a warning when the resolved key path is in its known default-file list. That check is path-based, and the warning is not itself a fatal release gate.
A copied development key under another filename can therefore escape this particular warning. Conversely, a familiar path name does not replace a content-identity review. Make the release decision from the derived public identity and approved policy, not only from the presence or absence of a warning string.
Require the release system to fail when identity evidence is missing, unintended or inconsistent. This is a proposed release policy; the article does not claim the upstream build implements that broader gate automatically.
4. Check the final consumer, including separate paths
Use the build manifest, generated source, link map and appropriate binary inspection to connect the public identity to the shipped artifact. A raw text search alone is unreliable evidence: key encodings and optimized structures may differ from the source representation.
The validation source contains different trusted-key lookup branches. If the build uses platform-supplied hashes or a built-in-key provider, inspect that actual provider rather than declaring the absence of a generated key file safe.
Inventory independently shipped recovery verifiers and manufacturing-service images. Give each one a binary identity and acceptance-policy result. Do not assume that a current normal bootloader proves an older recovery image has the same trust set.
5. Qualify residual-trust rejection
| Proposed fixture | Required result | Interpretation |
|---|---|---|
| Approved production identity, supported format | Passes required verification | Positive control establishes the intended route |
| Development identity, otherwise compatible artifact | Rejected by signer authorization | Residual development trust is excluded on this path |
| Unrelated test identity, otherwise compatible artifact | Rejected by signer authorization | No unintended generic acceptance |
| Unsigned artifact with valid structure | Rejected under the required signing policy | No integrity-only fallback |
| Same cases through each independent recovery verifier | Matches its approved trust contract | Path-specific coverage |
Use approved synthetic artifacts prepared through the organization’s test process. Keep version, format and applicability valid enough to reach the signature decision. Rejection by a size check or rollback gate does not demonstrate exclusion of the development signer.
Retain the first failing stage and a passing control from the same binary. Do not weaken the verifier or alter production security settings to make a test easier. These are proposed tests, not reported execution results.
Hypothetical renamed default input
A fictional build switches its input filename to a release-oriented name, and the known-path warning disappears. The public-identity gate still matches an unapproved development identity. Meanwhile, the separate signing service already uses the intended production identity.
The release remains blocked because producer intent did not change the consumer’s trust. Repair the build input through the authorized release process, rebuild, and repeat artifact-specific evidence collection. Do not infer that already deployed devices are affected without their actual binary and policy evidence.
6. Close with a verifiable trust inventory
Deliver public fingerprints, approved purposes, final verifier hashes and path-specific test results. Keep private keys and provisioning credentials outside ordinary evidence packages.
Recheck after bootloader rebuilds, board changes, recovery-image refreshes or signing-infrastructure changes. This gate detects unintended release trust; it does not perform planned key rotation or establish complete product security.
