What is code signing?

Code signing is the practice of attaching a cryptographic digital signature to software so that anyone receiving it can verify who published it and confirm it has not been altered since. It provides two guarantees at once: authenticity, meaning the code comes from a known publisher, and integrity, meaning the code has not been tampered with in transit. It is the invisible mechanism that lets an operating system, app store, or package manager accept trusted software and warn about the rest.

How does code signing work?

Code signing relies on asymmetric cryptography, where the signer holds a private key kept secret and a public key distributed freely, combined with a hash function. The publisher computes a fixed-size digest of the software and encrypts that digest with their private key to produce the signature; the recipient recomputes the hash, uses the publisher's public key to recover the original digest, and confirms the two match. If even one byte was altered, the recomputed hash will not match and verification fails.

What is a chain of trust in code signing?

A public key alone does not prove identity, since anyone can generate a key pair, so Public Key Infrastructure closes the gap. A Certificate Authority verifies a publisher's identity and issues a code signing certificate that binds the publisher's name to its public key. Verification then follows a chain: the signature validates against the publisher's certificate, that certificate validates against the issuing Certificate Authority, and the chain terminates at a root certificate that the operating system already trusts.

Why does code signing use timestamping?

Signing certificates expire, and without help every signature would become invalid the moment its certificate expired, breaking old but legitimate software. Trusted timestamping solves this by having a timestamp authority countersign at signing time to attest that the signature existed at a specific moment. Verifiers then check that the certificate was valid when the software was signed, so correctly timestamped software keeps verifying long after the certificate expires.

How should developers protect code signing keys?

Store private keys in a hardware security module or a dedicated key-management service, never in a source repository or on a developer laptop. Sign in an isolated, hardened build pipeline rather than manually on an individual's machine, and always timestamp signatures so releases remain verifiable after certificate rotation. Automate verification so that package managers, deployment systems, and update clients reject unsigned or invalid artifacts by default.

⚙ Application Security

Code Signing Explained

Q: What happens if a code signing private key is compromised?

A stolen private key lets an attacker sign malware that appears to come from you, so the certificate must be invalidated before its natural expiry. Certificate Authorities publish revocation information through certificate revocation lists or online status protocols, which verifiers consult to reject signatures made with a compromised key. Because the whole system depends on key secrecy, protecting the private key is the entire ballgame.

Code signing is the practice of attaching a cryptographic digital signature to software so that anyone receiving it can verify who published it and confirm it has not been altered since. When you install an operating-system update or run a downloaded application without a scary warning, code signing is usually the invisible mechanism vouching for that software. It provides two guarantees at once — authenticity (the code comes from a known publisher) and integrity (the code has not been tampered with in transit).

Why Code Signing Matters

Software travels through many hands between the developer and the user — mirrors, content-delivery networks, package registries, and update servers. Any of these could serve a modified binary containing malware. Without a way to verify origin and integrity, users must simply trust that nothing went wrong along the way.

Code signing removes that blind trust. It lets a runtime, package manager, or operating system make an automated decision: accept software from a recognized publisher whose signature checks out, and reject or warn about everything else. This underpins app stores, driver installation, automatic updates, and secure boot, and it is a foundational control for software supply chain security.

How Code Signing Works

Code signing relies on asymmetric cryptography, where a signer holds a mathematically linked pair of keys: a private key kept secret and a public key distributed freely. Signing uses the private key; verification uses the public key. The process combines this with a cryptographic hash function.

Signing

A hash function computes a fixed-size digest of the software. Any change to the file, even a single bit, produces a completely different digest.
The publisher encrypts that digest with their private key, producing the digital signature.
The signature, along with the publisher's certificate, is bundled with the software.

Hashing first makes signing efficient: the expensive asymmetric operation runs on a small digest rather than the entire, possibly large, file.

Verifying

The recipient recomputes the hash of the received software.
Using the publisher's public key, they decrypt the signature to recover the original digest.
If the two digests match, the software is intact and genuinely came from the holder of the private key.

If even one byte was altered, the recomputed hash will not match, and verification fails.

Certificates and the Chain of Trust

A public key alone does not prove identity — anyone can generate a key pair. This gap is closed by Public Key Infrastructure (PKI). A Certificate Authority (CA) verifies a publisher's identity and issues a code signing certificate that binds the publisher's name to its public key, signed by the CA.

Verification therefore follows a chain of trust: the software's signature is validated against the publisher's certificate, that certificate is validated against the CA that issued it, and the chain terminates at a root certificate that the operating system already trusts. If any link fails to validate, the whole chain is rejected. Some ecosystems raise assurance further by requiring keys to be stored on tamper-resistant hardware before a certificate is issued.

Timestamping and Revocation

Two problems complicate code signing over time, and both have standard solutions.

Certificate expiry. Signing certificates expire. Without help, every signature would become invalid the moment its certificate expired, breaking old but legitimate software. Trusted timestamping solves this: at signing time, a trusted timestamp authority countersigns to attest that the signature existed at a specific moment. Verifiers then check that the certificate was valid *when the software was signed*, so correctly timestamped software keeps verifying long after the certificate expires.

Key compromise. If a private key is stolen, its certificate must be invalidated before its natural expiry. CAs publish revocation information — through certificate revocation lists or online status protocols — that verifiers consult to reject signatures made with a compromised key.

Practical Guidance for Developers

Code signing only delivers its guarantees when the signing key is protected as rigorously as the guarantees imply. A stolen key lets an attacker sign malware that appears to come from you, so key protection is the entire ballgame.

Protect private keys in a hardware security module or a dedicated key-management service, never in a source repository or on a developer laptop.
Sign in an isolated environment, ideally as a controlled step in a hardened build pipeline rather than manually on an individual's machine.
Always timestamp signatures so releases remain verifiable after certificate rotation.
Automate verification so that consumers — package managers, deployment systems, and update clients — reject unsigned or invalid artifacts by default.

A minimal verification policy in a deployment pipeline might read:

1. Fetch artifact and its signature.
2. Verify signature against the publisher's public key.
3. Verify the certificate chains to a trusted root and was valid at signing time.
4. Check revocation status.
5. Proceed only if every step succeeds; otherwise fail closed.

Code signing pairs naturally with reproducible builds: reproducibility lets independent parties confirm a binary matches its source, and signing then binds that verified binary to an accountable identity. Together they let users trust both *what* the software is and *who* produced it.

Key Takeaways

Code signing attaches a digital signature that proves software authenticity (who published it) and integrity (that it is unaltered).
It works by hashing the software and encrypting the digest with a private key, which anyone can verify using the corresponding public key.
Certificates and PKI bind a public key to a real identity through a chain of trust ending at a trusted root.
Timestamping keeps signatures valid after certificates expire, and revocation invalidates compromised keys early.
The security of the whole system depends on protecting the private key, ideally in hardware, and verifying signatures automatically before running or deploying code.

code-signingdigital-signaturespkisoftware-integrityappsec