Code signing and cryptographic erase

Why this matters

This lesson closes domain 3 — the largest domain on the exam — with two applied uses of the primitives from the previous lesson, and it is the domain's capstone for a reason: both are places where the cryptography is straightforward and everything that matters is in the surrounding process.

Code signing is only as strong as the protection of the signing key and the integrity of what gets signed. A signature over a compromised build is a signature that certifies the compromise, and supply chain incidents have worked exactly that way — the attacker did not break the cryptography, they used it.

Cryptographic erase is only as strong as its preconditions. Destroying a key renders data unreadable if and only if every copy was encrypted with that key and no plaintext copy exists anywhere — which returns to lesson sixteen's leakage paths, and is where the technique usually fails.

The lesson

Signing build artefacts, and protecting the signing key that makes it meaningful

Code signing applies a digital signature to software so that a consumer can verify its origin and that it has not been altered since. It is the mechanism behind trusted application installation, driver loading, package management, container image verification and firmware updates.

What it provides is exactly the signature properties of the previous lesson — integrity, authenticity, and non-repudiation of the build — and nothing more. In particular, it says nothing about whether the code is safe. A signature certifies who produced the artefact, not that what they produced is benign. That distinction is examinable and it is the reason signing is a supply chain control rather than a malware control.

The signing key is the whole of the assurance, and it must be protected accordingly:

• Hardware-held and non-exportable, in an HSM or equivalent, so a compromise of a build host does not yield the key.
• Not usable by the pipeline directly. A key that any build can invoke means any compromise of the build system produces validly signed malware. A separate signing service, which accepts a request, applies policy, and returns a signature, is the pattern — and it is where approval and logging live.
• Policy at the point of signing: only artefacts from an approved pipeline, from an approved branch, that passed required checks, with an authorised requester.
• Every signing operation logged, immutably, because the log is how you answer "what did we sign" after a compromise, and that is the first question asked.
• Separate keys per purpose and environment, so revocation is proportionate — one key for everything means revoking it invalidates everything.

The failure mode that carries the most weight: a stolen signing key is worse than a stolen credential, because artefacts signed with it are trusted by every consumer, potentially for years, and revocation means invalidating everything that key signed — including legitimate software in production. The response to a suspected signing key compromise is therefore an organisational event, not a rotation, and a scenario describing one is usually asking whether you understand that.

Verification at install and at run time, and the gap between the two

A signature that is never verified provides nothing, and when it is verified determines what it protects against.

Verification at install or deployment checks the artefact before it is placed. It catches tampering in distribution — a compromised mirror, a modified download, an artefact substituted in a registry.

Verification at load or run time checks the artefact each time it executes. It additionally catches modification after installation, which is what an attacker with local access does.

The gap between them is where a real attack class lives. If an artefact is verified at install and then executed many times without re-verification, anything that can modify it on disk afterwards executes unverified. Mechanisms that address it — signed and enforced application control, verification at load, immutable or read-only filesystems — are the compensations, and read-only runtime filesystems are the cheapest of them, which is why lesson fifteen recommended them for containers.

Three further gaps that scenarios use:

• Verification that fails open. If the verifier cannot reach a revocation service or a trust store and proceeds anyway, an attacker who blocks that check defeats the control. This is the same fail-open problem as lesson thirty-seven's revocation checking.
• Trusting too many signers. A trust store containing many authorities means any of them can authorise code. Pinning to your own signer for your own software is far stronger than trusting a general store.
• Signed installers that fetch unsigned payloads. The installer verifies and then downloads content that does not, which moves the entire trust boundary to the download.

The principle: verification must cover the whole path from build to execution, and the control is only as strong as its weakest unverified step.

Supply-chain provenance: attestations, SBOMs and reproducible builds

Signing proves who produced an artefact. Provenance goes further and describes how it was produced, which is what a consumer needs in order to decide whether to trust it.

Build attestations are signed statements about the build: which source commit, which builder, which parameters, which dependencies, and which checks passed. They are generated by the build system and signed, so a consumer can verify not only that an artefact came from you but that it came from your pipeline, from your main branch, with your tests passing. This is what lesson nineteen meant by pipeline evidence consumed as an assurance signal.

A software bill of materials lists the components in an artefact. Its operational value is the one lesson thirty named: when a vulnerability is disclosed in a library, the question "which of our systems contain it" becomes a query rather than a rebuild-and-rescan exercise across the estate. Its limits are worth knowing — it is only as accurate as its generation, it frequently misses components not installed through package management, and a bill of materials nobody queries is a file.

Reproducible builds are builds that produce a bit-identical artefact from the same source and environment. Where achievable, they allow independent verification that a published artefact corresponds to the published source, which closes the gap where a signed artefact was built from something other than what the source repository shows. They are difficult to achieve, which is why they are aspirational for most and standard in high-assurance contexts.

Together these answer three different questions and it is worth keeping them apart: signing answers who, attestation answers how, and a bill of materials answers what is inside. A supply chain programme needs all three, and most organisations have the first.

Cryptographic erase: destroying the key instead of the media, and its preconditions

Cryptographic erase renders data unrecoverable by destroying the key that encrypts it, leaving the ciphertext in place.

Its advantages are substantial: it is fast — destroying a key takes moments regardless of data volume — it works on storage you cannot physically access, which is the cloud case from lesson sixteen, and it is the only erasure primitive a cloud customer can actually exercise. It also works for shared media, where physical destruction is not an option.

Its preconditions are where it fails, and every one of them must hold:

• The data was encrypted from the start, with that key. Data written before encryption was enabled is not covered.
• Every copy is covered. Backups, snapshots, replicas, exports, caches, analytics extracts and lower-environment copies — lesson sixteen's list. A single plaintext copy defeats it entirely.
• The key is genuinely destroyed, in every location including key backups, escrow and HSM backups. A key that survives in a backup is a key.
• No earlier version of the key remains. Where rotation retained previous versions to read historical data — the requirement lesson seventeen named — those versions must also be destroyed.
• The encryption is sound. A future break of the algorithm recovers ciphertext that was never deleted, which is the post-quantum consideration from lesson thirty-three applied to erasure: cryptographic erase of data with a long confidentiality requirement, using a scheme that may be broken within that period, is not erasure.

The practical implication is that cryptographic erase must be designed in. Deciding to use it after data exists usually means discovering that half the copies are outside the key boundary. The design consists of encrypting everything from the outset, with keys scoped to the erasure unit you will later want — per tenant, per customer, per classification — because a key shared across everything can only erase everything.

That scoping decision is the same blast-radius decision lesson seventeen described for key revocation, arriving from the other end: the scope of a key is the scope of both your emergency response and your erasure capability.

When crypto-erase is not acceptable and physical destruction is required

The closing distinction of domain 3, and it is decided by obligation as often as by risk.

Cryptographic erase is generally acceptable where the organisation controls the key lifecycle, the encryption meets a recognised standard, and the destruction is evidenced. Many data protection regimes accept it as rendering data inaccessible.

Physical destruction is required in identifiable circumstances, and a scenario will signal one of them:

• A mandate names it. Some classification regimes and sector rules require physical destruction or degaussing for media that held data above a level, regardless of encryption. This is a compliance constraint, not a risk judgement, and arguing with it is the wrong answer.
• The preconditions cannot be established. If you cannot demonstrate that all copies were encrypted with the destroyed key, cryptographic erase is a claim rather than a fact.
• The data was not encrypted from the start, which is the commonest case for older estates.
• The confidentiality requirement outlives the cryptography, per the post-quantum point above.
• The media is failing, so the controller cannot be relied upon to perform the erase correctly — a drive that cannot be written cannot be sanitised by any software method.

Methods and their evidence differ: overwriting is appropriate for functioning media where the data is not classified beyond it; degaussing applies to magnetic media and destroys the device; and physical destruction to a specified particle size is the highest assurance. In every case what an assessor needs is the certificate of destruction identifying the media, the method, the date and the operator — because, as with every control in this course, an action that cannot be evidenced cannot be relied on, and domain 3 closes on the same note domain 1 opened with.