Code Signing

Code signing cryptographically binds the identity of the publisher to the software artifact. A digital certificate issued by a trusted Certificate Authority (CA) validates the author's organizational identity.

• Uses X.509 certificates to link a public key to a verified entity
• Extended Validation (EV) certificates require rigorous vetting and enable SmartScreen reputation acceleration
• Prevents attackers from distributing malware under the guise of a trusted software vendor

A cryptographic hash digest of the code is generated and encrypted with the publisher's private key. Any modification to the executable—even a single bit—invalidates the signature.

• Common algorithms: SHA-256, SHA-384, SHA-512
• The operating system recalculates the hash at runtime and compares it against the decrypted signature value
• Detects tampering, corruption, or man-in-the-middle alterations during distribution

Once a software artifact is signed with a private key, the publisher cannot plausibly deny having produced that artifact. The signature serves as a legally admissible forensic artifact.

• Private keys must remain under exclusive control of the signing entity
• Hardware Security Modules (HSMs) enforce single-use access policies
• Provides an auditable trail for compliance frameworks like FedRAMP and SOC 2

A trusted timestamp authority (TSA) countersigns the signature with a verifiable time token. This proves the code was signed while the certificate was still valid.

• Enables long-term validation even after the original certificate expires
• Compliant with RFC 3161 standards for cryptographic timestamps
• Critical for archival software and regulated industries requiring multi-year signature verifiability

The operating system validates the signature by traversing a hierarchical chain of trust from the signing certificate up to a trusted root CA embedded in the system's trust store.

• Intermediate CAs bridge the end-entity certificate to the root
• Revocation checks via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol)
• A broken chain—expired, revoked, or untrusted—triggers security warnings like Windows SmartScreen or macOS Gatekeeper

Modern signing tools support embedding multiple signatures in a single artifact, enabling backward compatibility with legacy systems while maintaining modern cryptographic strength.

• Example: Signing with both SHA-1 (for Windows 7) and SHA-256 (for Windows 10+)
• Facilitates gradual deprecation of weaker algorithms without breaking older clients
• Tools like SignTool and osslsigncode natively support dual-signing workflows

Code signing relies on asymmetric public-key cryptography. A developer generates a private key (kept secret) and a public key (widely distributed). The signing tool creates a unique cryptographic hash of the code, which is then encrypted with the private key to form the digital signature. The end-user's system decrypts this signature using the public key and compares the resulting hash against a freshly computed hash of the downloaded code.

• Hash Function: Typically SHA-256 or SHA-384, producing a fixed-size digest of the executable.
• Signature Creation: The hash is encrypted with the signer's private key.
• Verification: The client decrypts with the public key and validates the hash match.
• Result: A mismatch indicates even a single-bit alteration or corruption since signing.

A raw public key is meaningless without a mechanism to bind it to a verified identity. Code signing uses a hierarchical Public Key Infrastructure (PKI). A Certificate Authority (CA) vouches for the developer's identity by issuing an X.509 code signing certificate. This certificate chains up to a trusted root CA certificate pre-installed in operating systems and browsers.

• Root CA: The ultimate trust anchor (e.g., DigiCert, Sectigo).
• Intermediate CA: Issues end-entity certificates, insulating the root.
• Code Signing Certificate: Binds the developer's verified identity to their public key.
• Extended Validation (EV): Requires rigorous identity vetting and stores keys on a physical hardware token (FIPS 140-2 Level 2).

Digital certificates have a finite validity period. To prevent signatures from becoming invalid when a certificate expires, code signing incorporates trusted timestamping. At the moment of signing, a hash of the code is sent to a Time Stamping Authority (TSA) , which countersigns it with a trusted timestamp token.

• Purpose: Proves the code was signed while the certificate was valid.
• Mechanism: The TSA's signature freezes the state of the signature at a specific point in time.
• Longevity: Allows the signature to be verified years later, even after the original certificate has expired or been revoked.
• RFC 3161: The standard protocol governing trusted timestamping.

The private key is the crown jewel of the code signing process. Its compromise allows an attacker to sign malware as if they were the legitimate publisher. Hardware Security Modules (HSMs) provide a tamper-resistant environment for key generation and storage, ensuring the private key can never be exported in plaintext.

• FIPS 140-2 Level 3: The standard for physical and logical key protection.
• Key Ceremony: A multi-person, audited process for initializing and backing up HSM keys.
• Signing as a Service: Cloud HSMs (e.g., AWS CloudHSM, Azure Dedicated HSM) allow CI/CD pipelines to request signatures without direct key access.
• Result: Even if a build server is breached, the attacker cannot extract the signing key.

Operating systems enforce code signing policies at runtime. Apple Gatekeeper on macOS blocks unsigned applications by default, requiring notarization for software distributed outside the App Store. Microsoft Authenticode on Windows validates signatures against the WinTrust API, displaying publisher information in User Account Control (UAC) prompts.

• Apple Notarization: An automated service that scans signed software for malicious content and issues a ticket stapled to the app.
• Microsoft SmartScreen: Builds reputation for signed binaries; EV-signed code gains reputation faster.
• Linux Integrity Measurement Architecture (IMA): Extends the verified boot concept to userspace, appraising file signatures against a custom policy.
• Android APK Signature Scheme v4: Enables streaming-aware, fs-verity compatible integrity protection.

Modern DevSecOps pipelines automate code signing as a critical stage. The Sigstore project introduces keyless signing using OpenID Connect (OIDC). Instead of managing long-lived private keys, a short-lived ephemeral key pair is generated, the public key is bound to an OIDC identity (e.g., a GitHub Actions workflow), and the event is recorded in a public transparency log (Rekor).

• Cosign: The CLI tool for signing containers and blobs with Sigstore.
• Fulcio: The root CA issuing short-lived certificates based on verified OIDC tokens.
• Rekor: An immutable, append-only transparency log that makes signing events auditable.
• Benefit: Eliminates the key management burden while providing a verifiable chain of custody.