Skip to content

Artifact Signature Verification

Verification protocol — instantiates Transitive Trust Boundary Hardening

Checks a cryptographic signature over an artifact's exact bytes against a pre-decided trust anchor at the point of use, so it is accepted because it verifies — not because of the channel it arrived through.

A perimeter admits a payload because of where it came from; this mechanism replaces that with what it can prove. Artifact Signature Verification checks a cryptographic signature over an artifact's exact bytes against a public key the consumer decided in advance to trust — the trust anchor — and does the check at the point of use, independent of whatever mirror, CDN, broker, or repository actually delivered the bytes. Its defining move is to make the delivery path irrelevant: a fast but untrusted mirror is fine, because a signature cannot be forged over altered bytes without the private key. This is what makes it this mechanism and not a build-lineage check or a cross-source vote — it verifies a single cryptographic binding, these bytes were signed by that key, and nothing more.

Example

A Linux server installs packages from a public mirror. The mirror is convenient and completely untrusted — anyone can run one. Each package, though, is signed by the distribution's release key, and that key shipped with the OS as a trust anchor. When apt pulls a package, it verifies the signature against the distribution key, not against the mirror. A mirror that serves a tampered package cannot produce a valid signature over the altered bytes, so the install fails at the consumer regardless of how "trusted" the mirror looked. The consumer accepts the package because the signature verifies against a key it chose to trust — the transitive trust in the mirror is cut out of the decision entirely.

How it works

The check binds bytes to a key at the consumer, before use: hash the exact artifact, verify the signature against the pre-decided trust anchor, and reject on any mismatch, expiry, or unknown signer. A valid result asserts precisely one thing — the holder of this key signed these exact bytes — and deliberately asserts nothing about the signer's intent or the artifact's safety. Everything else the archetype needs (which keys are legitimate, whether one was revoked, how it was built) lives in other mechanisms; this one is the narrow, cryptographic gate.

Tuning parameters

  • Trust-anchor set — which keys count as authoritative. A narrow, pinned set of exact signer keys is strong; a broad bundle "trust any key in here" quietly defeats the check.
  • Enforcement mode — warn versus hard-fail. Blocking on failure is the point; a warning that ships anyway is theater.
  • Key-to-artifact binding — whether any trusted key may sign anything, or specific keys are authorized for specific artifacts. Tighter binding limits what a single compromised key can pass.
  • Freshness / expiry — whether signatures must be timestamped and unexpired, closing replay of old validly-signed (but since-withdrawn) artifacts.
  • Unknown-key handling — fail-closed on an unrecognized signer versus prompting; fail-closed is the safe default.

When it helps, and when it misleads

Its strength is decisive: tampering in transit and untrusted delivery paths are caught cold, and the consumer's acceptance no longer rides on trusting a mirror, broker, or channel. It is the cheapest, hardest evidence that an artifact is the one a specific key signed.

Its central failure mode is a category error: a valid signature proves the key signed the bytes, not that the artifact is benign. If the signing key or the signer is compromised, a perfectly valid signature ships a hostile payload — the classic supply-chain move, where defenses work exactly as configured yet admit the attack because it wears trusted credentials.[1] Verifying against the wrong anchor, or accepting any key in a bundle, hollows it out the same way. The discipline that guards it: pin the exact authorized signers, treat trust-anchor custody as the real security boundary, and pair signature checks with build-lineage and cross-source evidence rather than reading "signature valid" as "safe."

How it implements the components

  • origin_and_integrity_evidence — the verified signature is the origin-and-integrity evidence: cryptographic proof that these exact, untampered bytes came from the holder of a trusted key.
  • consumer_side_verification_gate — the check runs at the consumer's point of use as a gate that blocks any artifact it cannot verify, before the artifact is trusted or installed.

It does not maintain or rotate the set of trusted signing keys — it consumes that from Key Rotation and Revocation Drill (signer_key_custody_map, revocation_and_rotation_path); it does not check how the artifact was built (transformation_and_custody_record, Provenance Attestation Check); and it does not corroborate across independent channels (independent_channel_cross_check, Multi-Source Release Corroboration).

Notes

The mechanism answers who signed it, never should I trust the signer. That upstream decision — which keys become trust anchors and how their private halves are guarded — is where most real failures live, and it belongs to key custody, not to the verification step. Keeping the two separate is what lets a compromised signer be replaced without redesigning verification.

References

[1] A single signing key is a single point of failure precisely because a valid signature authenticates the signer, not the payload — the design premise behind The Update Framework (TUF), which layers signing roles and thresholds so that no one compromised key can unilaterally get an artifact accepted. ↩