Code signing: proving who shipped a binary, and what it can't prove

A code signature answers two questions about a file: has a single bit changed since it was signed, and who signed it? The first comes from the hash; the second from the certificate chain that ties the signing public key to a named publisher. That is the whole promise. A signature says nothing about whether the code is safe, well written, or free of a backdoor: it only says that whoever held the publisher's private key approved these exact bytes.

That distinction is the lesson of most real code-signing incidents. Stuxnet (2010) carried drivers signed with private keys stolen from two Taiwanese hardware vendors, so Windows loaded them as legitimate. In the ASUS 'ShadowHammer' attack (disclosed 2019), attackers inside the vendor's update infrastructure pushed a trojanized updater signed with ASUS's own certificate. In SolarWinds (2020) the malicious code was injected during the build, so the normal pipeline signed it exactly as it signed every other release. In each case the cryptography worked perfectly; what failed was control over the key or over what reached it.

Signing a binary is the hash-then-sign pattern from the signatures module, applied to a file format. The signing tool hashes the file (skipping the bytes where the signature itself will go, so adding it doesn't change the hash), signs that digest with the publisher's private key, and embeds the result together with the certificate chain. Windows Authenticode wraps it all in a CMS SignedData structure (RFC 5652); Apple's codesign, Android's APK Signature Scheme, and Java JAR signing each use their own container, but the cryptographic core is the same.

The algorithms are the familiar ones: SHA-256 or SHA-384 for the digest, and RSA, ECDSA, or (in newer ecosystems such as package registries and Sigstore-style tooling) Ed25519 for the signature. Much of the deployed Windows ecosystem still uses RSA with PKCS#1 v1.5 padding for signatures, which remains acceptable for signing even though v1.5 encryption padding is broken; RSA-PSS is the more modern choice where verifiers support it. Signature size depends only on the key, not the file: a 2 GB installer and a 2 KB script signed with the same RSA-3072 key carry identical-size signatures.

Code-signing certificates expire, and since 1 March 2026 the CA/Browser Forum caps publicly trusted ones at 460 days (Ballot CSC-31, down from 39 months). Software, though, stays installed for a decade. Without help, every signature would stop verifying the day its certificate expired.

The fix is a trusted timestamp. Right after signing, the tool sends a hash of the signature to a Time-Stamping Authority, which returns its own signed token saying 'this signature existed at this time' (RFC 3161). A verifier then asks a different question: not 'is the certificate valid now?' but 'was it valid, and not revoked, at the timestamped moment?' A timestamped signature from 2019 still verifies in 2026; an untimestamped one generally does not once the certificate has expired.

When a signing key leaks, revoking its certificate the ordinary way would be a disaster: every legitimate binary ever signed with it would fail verification along with the attacker's. Code signing handles this with the timestamp. The revocation is recorded as taking effect from the estimated time of compromise, so signatures timestamped before that point keep verifying and anything timestamped after it is rejected.

That only works if the publisher can say when the compromise happened and the timestamps are trustworthy, which is one more reason the timestamp comes from an independent authority rather than the signer's own clock. It also explains why investigators care so much about establishing an incident timeline: the revocation date decides which shipped software customers keep trusting.

Because a stolen signing key turns malware into trusted software, the CA/Browser Forum's Code Signing Baseline Requirements have required since 1 June 2023 that the private key for any publicly trusted code-signing certificate, OV as well as EV, be generated and kept in a hardware module validated to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, or an equivalent. In practice that means a USB token, an on-premises HSM, or a cloud HSM-backed signing service; a .pfx file on a build server no longer qualifies.

Hardware stops the key from being copied, but not from being used. An attacker inside the build system can still submit malicious code to a perfectly protected HSM. So mature setups add controls around the key's use: signing as a separate service the build calls with a digest, per-release approvals or M-of-N authorization for production keys, separate keys for test and release, and logs of every signing operation that someone actually reviews. The key itself is usually created in a recorded key ceremony with dual control, the same discipline used for CA root keys.