Lab-06: PQC Code Signing
Lab-06: PQC Code Signing
Section titled “Lab-06: PQC Code Signing”Post-Quantum Code Signing with ML-DSA
Section titled “Post-Quantum Code Signing with ML-DSA”Key Message: Software signatures must remain valid for years. PQC ensures they can’t be forged by future quantum computers.
The Scenario
Section titled “The Scenario”“We sign our software releases. How long do those signatures need to be valid? And what happens when quantum computers can forge classical signatures?”
Code signatures are long-lived. A signed binary from 2024 might still be verified in 2034. If quantum computers can forge ECDSA signatures by then, attackers could create malicious software that appears legitimately signed.
TODAY FUTURE (5-15 years?)───── ────────────────────
You sign software Attacker with quantum computer │ │ │ ECDSA signature │ Breaks ECDSA │ │ ▼ ▼ Signed binary ────────────────► Forges valid signature (still in use) on malicious binary │ ▼ "Legitimate" malware passes verificationThe Problem
Section titled “The Problem”WITHOUT CODE SIGNING────────────────────
Developer Attacker Client │ │ │ │ firmware.bin │ │ │ ────────────────────────────┼──────────────────────────►│ │ │ │ │ │ firmware.bin (modified) │ │ │ ──────────────────────► │ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ Which one │ │ │ │ is real? │ │ │ └──────────────┘The Threat
Section titled “The Threat”┌──────────────────────────────────────────────────────────────────┐│ ││ SUPPLY CHAIN ATTACK: Modify code in transit ││ ││ ││ Developer ││ │ ││ │ firmware.bin (original) ││ ▼ ││ ┌──────────┐ ││ │ Mirror │ ◄──── Attacker injects malware ││ │ Server │ ││ └──────────┘ ││ │ ││ │ firmware.bin (compromised) ││ ▼ ││ ┌──────────┐ ││ │ Client │ Installs the firmware ││ │ │ without knowing it's ││ │ │ been modified ││ └──────────┘ ││ ││ Real-world examples: ││ - SolarWinds (2020): malware injected in an update ││ - CodeCov (2021): build script compromised ││ - 3CX (2023): supply chain of a supply chain ││ │└──────────────────────────────────────────────────────────────────┘The Solution: Code Signing
Section titled “The Solution: Code Signing”Sign the code BEFORE distributing it:
┌──────────────────────────────────────────────────────────────────┐│ ││ WITH CODE SIGNING ││ ││ Developer ││ │ ││ │ 1. Signs firmware.bin with ML-DSA ││ ▼ ││ ┌─────────────────────────────────┐ ││ │ firmware.bin │ ││ │ + firmware.bin.p7s (signature) │ ││ │ + signing.crt (certificate) │ ││ └─────────────────────────────────┘ ││ │ ││ ▼ ││ ┌──────────┐ ││ │ Client │ 2. Verifies the signature ││ │ │ ││ │ │ ✓ Hash matches ││ │ │ ✓ Signature valid ││ │ │ ✓ Certificate in the chain ││ │ │ ││ │ │ → Installation authorized ││ └──────────┘ ││ ││ If the firmware is modified: ││ ❌ Hash doesn't match → Signature invalid → REJECTED ││ │└──────────────────────────────────────────────────────────────────┘What a Signature Guarantees
Section titled “What a Signature Guarantees”| Property | Meaning |
|---|---|
| Integrity | The file hasn’t been modified |
| Authenticity | It really comes from the publisher |
| Non-repudiation | The publisher can’t deny signing it |
What We’ll Do
Section titled “What We’ll Do”- Create a Code Signing CA (ML-DSA-65) 1b. Issue a code signing certificate
- Sign a firmware binary (CMS/PKCS#7) 2b. Verify the signature (VALID)
- Tamper with the binary and verify again (INVALID)
Run the Demo
Section titled “Run the Demo”./journey/06-code-signing/demo.shThe Commands
Section titled “The Commands”Step 1: Create Code Signing CA
Section titled “Step 1: Create Code Signing CA”# Create a PQC CA for code signingqpki ca init --profile profiles/pqc-ca.yaml \ --var cn="Code Signing CA" \ --ca-dir output/code-ca
qpki ca export --ca-dir output/code-ca --out output/code-ca/ca.crtStep 1b: Issue Code Signing Certificate
Section titled “Step 1b: Issue Code Signing Certificate”# Generate key and CSRqpki csr gen --algorithm ml-dsa-65 \ --keyout output/code-signing.key \ --cn "ACME Software" \ --out output/code-signing.csr
qpki cert issue --ca-dir output/code-ca \ --profile profiles/pqc-code-signing.yaml \ --csr output/code-signing.csr \ --out output/code-signing.crtStep 2: Sign a Binary
Section titled “Step 2: Sign a Binary”# Create a test firmwaredd if=/dev/urandom of=output/firmware.bin bs=1024 count=100
qpki cms sign --data output/firmware.bin \ --cert output/code-signing.crt \ --key output/code-signing.key \ --out output/firmware.p7sStep 2b: Verify the Signature
Section titled “Step 2b: Verify the Signature”# Verify: 1) hash matches 2) signature valid 3) cert chain trustedqpki cms verify output/firmware.p7s \ --data output/firmware.bin \ --ca output/code-ca/ca.crt# Result: VALIDStep 3: Tamper and Verify Again
Section titled “Step 3: Tamper and Verify Again”# Any modification changes the hash → signature becomes invalidecho "MALWARE" >> output/firmware.bin
qpki cms verify output/firmware.p7s \ --data output/firmware.bin \ --ca output/code-ca/ca.crt# Result: INVALID - hash mismatchWhy Code Signing Needs PQC
Section titled “Why Code Signing Needs PQC”Long-Lived Signatures
Section titled “Long-Lived Signatures”| Software Type | Typical Lifespan | PQC Urgency |
|---|---|---|
| IoT firmware | 10-20 years | Critical |
| Industrial control | 15-30 years | Critical |
| Medical devices | 10-15 years | Critical |
| Desktop software | 5-10 years | High |
| Mobile apps | 2-5 years | Medium |
Attack Scenarios
Section titled “Attack Scenarios”- Firmware tampering: Attacker forges signature on malicious firmware update
- Supply chain attack: Malicious package appears legitimately signed
- Historical verification: Old signatures become untrustworthy
Size Comparison
Section titled “Size Comparison”| Component | Classical (ECDSA P-384) | Post-Quantum (ML-DSA-65) | Notes |
|---|---|---|---|
| Public key | ~97 bytes | ~1,952 bytes | In certificate |
| Signature | ~96 bytes | ~3,309 bytes | Per signed file |
| Certificate | ~1 KB | ~6 KB | One-time distribution |
For a 100 MB binary, the signature overhead is negligible.
Certificate Extensions
Section titled “Certificate Extensions”Code signing certificates have specific extensions:
| Extension | Value | Purpose |
|---|---|---|
| Extended Key Usage | codeSigning | Limits certificate use |
| Key Usage | digitalSignature | Signing operations only |
| Basic Constraints | CA: false | End-entity certificate |
When to Adopt PQC Code Signing
Section titled “When to Adopt PQC Code Signing”| Scenario | Recommendation |
|---|---|
| IoT/embedded firmware | Now - Long device lifespan |
| Critical infrastructure | Now - High-value targets |
| Enterprise software | Plan for 2025-2026 |
| Consumer apps | Can wait, but plan ahead |
What You Learned
Section titled “What You Learned”- Long-lived signatures: Code signatures may be verified for 10+ years
- Quantum threat: Future quantum computers could forge classical signatures
- PQC solution: ML-DSA signatures remain unforgeable
- Size trade-off: ~3 KB signature vs ~100 bytes (negligible for binaries)
- Drop-in replacement: Same workflow, different algorithm
References
Section titled “References”What’s Next?
Section titled “What’s Next?”You’ve proven WHO signed the code and that it hasn’t been tampered with.
But WHEN was it signed? If the certificate expires, how do you prove the signature existed before expiration?
← PQC OCSP | QLAB Home | Next: Timestamping → — Prove WHEN documents were signed.