From 8dd4ec1647ca76f317453d65390283e5875c3ab2 Mon Sep 17 00:00:00 2001 From: John Sotiropoulos Date: Mon, 13 Jul 2026 16:30:28 +0100 Subject: [PATCH 1/2] Add Quantum Top 10 entries from template (QS01-QS10) --- ...QS01_Harvest-Now-Decrypt-Later-Exposure.md | 40 +++++++++++++++++ .../QS02_Long-Lived-Sensitive-Data.md | 41 +++++++++++++++++ ..._Vulnerable-Signatures-and-Code-Signing.md | 42 ++++++++++++++++++ ...Absent-Cryptographic-Inventory-and-CBOM.md | 43 ++++++++++++++++++ .../QS05_Crypto-Agility-Failures.md | 44 +++++++++++++++++++ ...06_Insecure-Migration-and-Hybrid-Misuse.md | 44 +++++++++++++++++++ .../QS07_Hardware-Roots-of-Trust.md | 42 ++++++++++++++++++ .../QS08_QPU-Tenant-Isolation-Failures.md | 41 +++++++++++++++++ .../QS09_Toolchain-and-Compiler-Compromise.md | 43 ++++++++++++++++++ ...Side-Channel-and-Control-Plane-Exposure.md | 43 ++++++++++++++++++ quantum-top-10/_template.md | 28 ++++++++++++ 11 files changed, 451 insertions(+) create mode 100644 quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md create mode 100644 quantum-top-10/QS02_Long-Lived-Sensitive-Data.md create mode 100644 quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md create mode 100644 quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md create mode 100644 quantum-top-10/QS05_Crypto-Agility-Failures.md create mode 100644 quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md create mode 100644 quantum-top-10/QS07_Hardware-Roots-of-Trust.md create mode 100644 quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md create mode 100644 quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md create mode 100644 quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md create mode 100644 quantum-top-10/_template.md diff --git a/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md new file mode 100644 index 0000000..a4e737b --- /dev/null +++ b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md @@ -0,0 +1,40 @@ +## QS01:2026 - Harvest-Now-Decrypt-Later Exposure + +**Description:** + +Adversaries are already capturing encrypted traffic and stored ciphertext today, retaining it for future decryption once a cryptographically relevant quantum computer (CRQC) exists. The relevant operation is typically a key-establishment step protected by RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman - all broken in polynomial time by Shor's algorithm. Once the session key is recovered, the symmetric ciphertext follows. Any organisation whose data has meaningful confidentiality lifetime - financial records, health data, source code, intelligence material, contractual or commercial secrets - must treat current TLS, VPN, and at-rest encryption based on these primitives as future-readable. The risk is concrete now, not contingent on quantum hardware availability. + +**Common Examples of Vulnerability:** + +1. Data sets whose confidentiality requirement extends beyond 2030 - health records, intellectual property, regulated personal data with long retention, government and defence data - protected only by classical public-key cryptography. +2. Transport and channel protection using vulnerable key establishment: TLS endpoints, VPN tunnels, encrypted backup channels, archival storage encryption, and satellite or microwave links relying on RSA, ECDH, or finite-field DH. +3. Encrypted traffic transiting an untrusted boundary where it can be passively recorded and retained for later decryption. +4. Session encryption migrated to PQC while long-validity certificates and key-wrapping keys are left on classical algorithms. + +**How to Prevent:** + +1. Migrate vulnerable channels to hybrid post-quantum TLS using ML-KEM (FIPS 203) where the platform supports it. +2. For data at rest, layer a PQC-protected encryption envelope over existing classical encryption for the highest-sensitivity datasets. +3. Rotate symmetric data keys protected by quantum-vulnerable wrapping more frequently to reduce the volume exposed by any single recovered key. +4. Reduce data retention where the business case allows - data not retained cannot be decrypted later. + +**Example Attack Scenarios:** + +Scenario #1: An adversary passively records TLS-protected traffic as it crosses an untrusted network boundary today. The handshake used RSA or ECDH key establishment. The captured ciphertext is archived. Once a CRQC becomes available, the adversary recovers the session key via Shor's algorithm and decrypts years of previously confidential traffic retroactively. + +Scenario #2: An organisation encrypts long-retention backups at rest with AES-256, but the AES data key is wrapped with RSA. An attacker exfiltrates the encrypted backups and the wrapped keys. Because the quantum-vulnerable layer is the RSA key-wrapping - not the symmetric cipher - the attacker recovers the wrapping key with a future CRQC and unwraps the AES keys, exposing the entire archive. + +**Reference Links:** + + + +1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final): Key-establishment standard for post-quantum migration. +2. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/): Migration timelines calling out long-lived sensitive data as a priority class. +3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases. +4. [White House National Security Memorandum 10 (NSM-10) / OMB M-23-02](https://www.whitehouse.gov/): Cite HNDL as the primary driver of US migration urgency. + + + diff --git a/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md b/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md new file mode 100644 index 0000000..bb9467b --- /dev/null +++ b/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md @@ -0,0 +1,41 @@ +## QS02:2026 - Long-Lived Sensitive Data + +**Description:** + +Data with a confidentiality requirement that extends past the projected arrival of a CRQC cannot be protected by today's public-key primitives alone. Mosca's inequality is the operative planning frame: if the time to migrate to quantum-safe cryptography (X) plus the required confidentiality lifetime of the data (Y) exceeds the time until a CRQC exists (Z), the organisation is already exposed. For data with multi-decade confidentiality requirements - archives, backups, regulated personal data, identity records, intellectual property, signed material whose integrity must hold for years - current public-key protection is insufficient regardless of exactly when a CRQC arrives. This is distinct from QS01: it focuses on stored data and signed artefacts whose protection requirements outlast any reasonable migration window, rather than in-flight traffic. + +**Common Examples of Vulnerability:** + +1. Major data categories where confidentiality lifetime plus migration lead time exceeds published government CRQC planning horizons (2030-2035 for most regulators). +2. Archives and backups that pre-date current crypto policy and may contain quantum-vulnerable encryption under long retention requirements. +3. Signed artefacts whose validity must persist for years: contracts, regulatory filings, evidentiary records, signed software releases, blockchain transactions. +4. Identity and credential records with multi-year lifetimes: government identity issuance, professional credentials, root certificates. +5. Data-at-rest encrypted with AES-256 but wrapped with an RSA or ECC key - the quantum-vulnerable layer sits above the symmetric key. + +**How to Prevent:** + +1. Establish data classification by confidentiality lifetime, not just sensitivity - a medium-sensitivity record with a 30-year retention requirement may outrank a high-sensitivity record retained for two years. +2. Plan re-encryption programmes for high-priority archives, sequenced against migration capacity. +3. For long-lived signed artefacts, plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before classical signature schemes are deprecated. +4. Where re-encryption is not feasible, reduce retention to the minimum legally and operationally required. + +**Example Attack Scenarios:** + +Scenario #1: A regulated entity retains personal records for a statutory 30-year period, encrypted with an RSA-wrapped AES key. An adversary harvests the encrypted store today. Applying Mosca's inequality, the confidentiality lifetime far exceeds the CRQC horizon, so the records are effectively already compromised: the attacker recovers the wrapping key once a CRQC exists and decrypts the full archive, well within its required protection window. + +Scenario #2: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. An attacker records the signed artefacts and, after a CRQC becomes available, forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor. + +**Reference Links:** + + + +1. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality. +2. [UK NCSC migration guidance](https://www.ncsc.gov.uk/): Long-lived data prioritisation for PQC migration. +3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/): End-2030 high-risk deadline and standalone-PKC prohibition. +4. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art protection required through the product support period. + + + diff --git a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md new file mode 100644 index 0000000..614e549 --- /dev/null +++ b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md @@ -0,0 +1,42 @@ +## QS03:2026 - Vulnerable Signatures and Code-Signing + +**Description:** + +Public-key signatures underpin code signing, supply-chain integrity, document validity, identity certificates, transactions, and long-term non-repudiation. RSA, DSA, ECDSA, and EdDSA are all broken by Shor's algorithm, so any system that verifies these signatures to establish trust - software updates, container images, firmware, package managers, TLS certificate hierarchies, SBOM attestations, signed documents, blockchain transactions - is at risk once a CRQC exists. Unlike confidentiality breaches, signature forgery enables active attacks: malicious updates, fake identities, fraudulent transactions, supply-chain compromise. The post-quantum signature standards (ML-DSA / FIPS 204 and SLH-DSA / FIPS 205) have larger keys and signatures and different operational profiles, with non-trivial impact on hardware roots of trust, constrained devices, and certificate ecosystems. + +**Common Examples of Vulnerability:** + +1. Certification authority hierarchies (root, intermediate, issuing CA) signing with RSA-2048 or ECDSA P-256 over multi-year validity periods. +2. Code-signing keys: OS update signing, firmware signing, container image signing (Sigstore, cosign, Notary), package signing, mobile app signing, CI/CD signing. +3. Other long-lived signature trust anchors: UEFI Secure Boot keys, TPM endorsement keys, JWT/SAML issuer keys, document-signing certificates, blockchain wallet keys. +4. Large verifier populations - devices, services, or artefacts - that trust a classical key and cannot easily be upgraded. + +**How to Prevent:** + +1. Migrate code-signing and CA hierarchies before broader estate migration - they have the longest blast radius and lead time. +2. Adopt hybrid signing during transition: produce both a classical and a PQC signature on the same artefact so non-PQC verifiers keep working while PQC-aware verifiers gain forward security. +3. Use ML-DSA (FIPS 204) for general digital signatures; use SLH-DSA (FIPS 205) for very long-lived, high-assurance signatures where stateless hash-based security is preferred. +4. Plan for shorter certificate lifetimes during transition (e.g. the CA/Browser Forum 47-day TLS maximum effective 2029) to reduce the exposure window. +5. Engage PKI, code-signing, and certificate-authority vendors on PQC roadmaps - failure here is a supply-chain blocker. + +**Example Attack Scenarios:** + +Scenario #1: An attacker with a future CRQC recovers the private key of a code-signing certificate still on ECDSA P-256. They sign malware that passes verification on every device trusting that anchor, distributing a malicious "update" through the legitimate update channel. + +Scenario #2: An organisation migrates its leaf TLS certificates to PQC but leaves the root and intermediate CAs on RSA. An attacker forges an intermediate CA signature with a CRQC and issues trusted certificates for arbitrary domains - the chain is only as strong as its weakest classical link. + +**Reference Links:** + + + +1. [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Module-lattice digital signature standard. +2. [NIST FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final): Stateless hash-based signature standard for high-assurance, long-lived use. +3. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/): Software and firmware signing exclusively CNSA 2.0 by 2030. +4. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 and CMS extensions. +5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art integrity and authenticity requirements. + + + diff --git a/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md b/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md new file mode 100644 index 0000000..8aadbd6 --- /dev/null +++ b/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md @@ -0,0 +1,43 @@ +## QS04:2026 - Absent Cryptographic Inventory and CBOM + +**Description:** + +Organisations cannot migrate cryptography they have not catalogued. Cryptographic inventory means a documented record of every place cryptography is used - applications, services, certificates, signing keys, protocols, libraries, hardware roots of trust, third-party components, and embedded keys in firmware or silicon - with algorithm, key length, key custody, lifecycle, and system owner recorded for each. Without it, scope is unknowable, prioritisation is impossible, and a controlled migration cannot be executed. Long-lived signing keys, embedded device keys, root and intermediate CA keys, code-signing keys, hardware-bound keys in HSMs and TPMs, and keys baked into firmware or silicon are all on the critical path and are most often where inventories fail. The absence of a structured cryptographic bill of materials (CBOM) is the single most common blocker to PQC migration in 2026. + +**Common Examples of Vulnerability:** + +1. No structured, current record of cryptographic usage across the estate - or one that exists only as unstructured prose rather than a CBOM-compatible format. +2. Inventories that omit whole classes: HSM and TPM contents, embedded devices, third-party components, and SaaS dependencies. +3. One-off inventories with no automated or scheduled process to keep them current, so they age out within months. +4. Records that capture algorithm and key length but not key custody, generation, or rotation procedures. +5. Keys baked into firmware, silicon, or sealed devices that cannot be enumerated through software discovery. + +**How to Prevent:** + +1. Adopt CBOM (Cryptography Bill of Materials) as the inventory format, aligning with CycloneDX or SPDX cryptographic extensions. +2. Use cryptographic discovery tooling to bootstrap the inventory: TLS scanners, certificate transparency logs, code-scanning for crypto-library usage, dependency scanners for SBOMs. +3. Assign named owners for each asset class: applications, certificates, signing infrastructure, embedded systems, third-party. +4. Make the inventory a living document - integrate updates into change management, procurement, and CI/CD pipelines. +5. Extend inventory to cover key generation, custody, rotation, and revocation, not just static algorithm and key-length data. + +**Example Attack Scenarios:** + +Scenario #1: An organisation begins PQC migration but has no CBOM. A forgotten intermediate CA and a set of firmware-embedded signing keys are never catalogued, so they are never migrated. After a CRQC exists, an attacker targets exactly these un-inventoried classical anchors, which remain trusted across the estate. + +Scenario #2: A SaaS dependency terminates TLS with a quantum-vulnerable configuration the organisation never recorded because inventory covered only owned-and-operated systems. The unmanaged dependency becomes the harvest point for an HNDL adversary, invisible to the migration programme. + +**Reference Links:** + + + +1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/): 2028 discovery-and-assessment milestone. +2. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): End-2026 inventory and dependency-map requirement. +3. [CISA, NSA, NIST - Quantum-Readiness: Migration to PQC fact sheet (August 2023)](https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography): Cryptographic inventory recommendation. +4. [CycloneDX CBOM specification](https://cyclonedx.org/capabilities/cbom/): Cryptography Bill of Materials schema. +5. [NIST IR 8547 (Draft)](https://csrc.nist.gov/pubs/ir/8547/ipd): Lifecycle management for transition planning. + + + diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md new file mode 100644 index 0000000..3280f91 --- /dev/null +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -0,0 +1,44 @@ +## QS05:2026 - Crypto-Agility Failures + +**Description:** + +Cryptographic agility is the engineering property that allows an algorithm, key size, or parameter set to be replaced without rebuilding the system around it. Most production systems hard-code cryptographic algorithms, key sizes, parameter sets, and key formats deep in code, configuration, hardware, and protocols. Systems that lack agility - algorithms baked into source, protocol logic, custom data formats, or non-updatable firmware - require replacement, not migration. As ML-KEM, ML-DSA, and SLH-DSA move into production and parameter sets continue to evolve through subsequent NIST rounds (Falcon, HQC, others), organisations without negotiable algorithms, abstracted crypto APIs, version-aware protocols, and dynamic policy will be unable to respond to standards updates, broken parameter sets, or future migrations. Crypto-agility is itself a security control. Symmetric primitives are more quantum-resilient, but "quantum is only a public-key problem" must not be read as "symmetric needs no work": AES key sizes, hash strengths, MAC lengths, and KDFs all need review end-to-end. + +**Common Examples of Vulnerability:** + +1. Hard-coded algorithm identifiers in source: `RSA`, `sha256WithRSAEncryption`, explicit OIDs embedded in protocol logic. +2. Proprietary protocols that fix algorithms rather than negotiate them (unlike TLS 1.3). +3. Embedded devices with no tested path to receive firmware updates that change cryptographic primitives. +4. Systems that cannot select among ML-KEM-512/768/1024 parameter sets without code changes. +5. Symmetric weaknesses left unaddressed: AES-128 on long-lived links, truncated MACs, weak KDFs, unsafe key derivation in hybrid KEMs. + +**How to Prevent:** + +1. Refactor algorithm selection out of business logic into a cryptographic abstraction layer. +2. Standardise on libraries that ship PQC: OpenSSL 3.x with PQC providers, BoringSSL, SymCrypt, JDK 24+, .NET 10+. +3. Avoid custom protocol implementations where standard alternatives exist - prefer TLS 1.3 with hybrid PQC cipher suites over a bespoke handshake. +4. Test the rotation path end-to-end in non-production, including embedded and mobile clients, to surface agility blockers before migration. +5. Include agility requirements in procurement: new contracts should require PQC support and demonstrable algorithm replacement on a defined timescale. +6. Track IETF PQUIP and TLS working-group output for documented migration patterns and failure modes. + +**Example Attack Scenarios:** + +Scenario #1: A NIST parameter set for a deployed PQC algorithm is later found weak. An organisation that hard-coded the algorithm cannot swap it without a full rebuild-and-reship cycle across firmware it cannot update in the field, leaving vulnerable systems exposed for the length of a replacement project. + +Scenario #2: A team adds a crypto abstraction layer but never tests rotation. When migration day arrives, an embedded client that pins a classical algorithm identifier silently fails PQC negotiation and continues on classical crypto, and the untested "agility" turns out to be theoretical - the attacker targets the client that never actually migrated. + +**Reference Links:** + + + +1. [CISA, NSA, NIST - Quantum-Readiness fact sheet](https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography): Cryptographic agility recommendation. +2. [UK NCSC guidance on crypto-agility](https://www.ncsc.gov.uk/): Agility expectations for migration. +3. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): Explicit agility expectation. +4. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Agility documents and migration patterns. +5. [IETF TLS Working Group](https://datatracker.ietf.org/wg/tls/about/): Hybrid KEM and signature negotiation. + + + diff --git a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md new file mode 100644 index 0000000..b267b44 --- /dev/null +++ b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md @@ -0,0 +1,44 @@ +## QS06:2026 - Insecure Migration and Hybrid Misuse + +**Description:** + +Hybrid cryptography is the practical migration pattern, but it is widely misimplemented. A hybrid construction combines a classical algorithm and a PQC algorithm so that breaking the combination requires breaking both - for key encapsulation, deriving the session key from both an ECDH share and an ML-KEM share; for signatures, producing two signatures over the same artefact. Done correctly, hybrid provides defence in depth during transition. Done incorrectly, it weakens security, hides algorithm failures, becomes an attractive permanent state that delays full migration, or introduces new attack surface: silent fallback to classical when PQC negotiation fails, broken hybrid KEM constructions where key derivation does not require both inputs, weak parameter selection, non-constant-time PQ implementations vulnerable to timing side channels, and downgrade attacks during the transition window. + +**Common Examples of Vulnerability:** + +1. Drop-in replacement that silently falls back to classical when PQC negotiation fails. +2. Broken hybrid KEM constructions where the key derivation does not require both the classical and PQC inputs (selection or XOR rather than a KDF over both). +3. Weak parameter selection - ML-KEM-512 where ML-KEM-768 is required. +4. Non-constant-time PQ implementations vulnerable to timing side channels. +5. Downgrade attacks where an attacker strips PQC options during transition to force classical-only negotiation. +6. Pre-2024 hybrid Kyber/Dilithium implementations still in use after ML-KEM and ML-DSA superseded them. + +**How to Prevent:** + +1. Use standard hybrid constructions from IETF drafts and vendor implementations rather than custom combinations. +2. Combine hybrid outputs through a KDF over both inputs, not by selection or XOR. +3. Test for downgrade resistance - ensure PQC failure does not silently fall back to classical-only, and monitor for handshakes that revert. +4. Track hybrid deployments as transitional and plan their replacement with pure PQC ahead of regulatory deadlines for high-risk use cases. +5. Verify hybrid implementations use ML-KEM and ML-DSA, not predecessor draft algorithms, and rely on validated constant-time libraries (SymCrypt, BoringSSL, AWS-LC) rather than reference code. +6. Pilot hybrid PQC TLS in non-production for each architecture pattern, measuring handshake size, latency, throughput, and middlebox behaviour - larger PQC handshakes may be dropped or fragmented by firewalls and load balancers. + +**Example Attack Scenarios:** + +Scenario #1: A deployment negotiates hybrid PQC TLS but falls back to classical-only if the PQC option is absent. An active attacker strips the PQC key-share from the handshake, forcing a downgrade to ECDH, then records the session for later CRQC decryption - the hybrid protection is nullified by the fallback. + +Scenario #2: A team builds a custom hybrid KEM that derives the session key from the ML-KEM share alone and merely attaches the ECDH share for "compatibility." Because breaking the combination requires breaking only the PQC part, an implementation flaw in the PQC library compromises the whole session, defeating the point of hybrid. + +**Reference Links:** + + + +1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. +2. [IETF - Hybrid PQ Key Exchange in TLS 1.3 (draft)](https://datatracker.ietf.org/wg/tls/about/): Standard hybrid KEM construction. +3. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. +4. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): End-2030 standalone-classical prohibition for high-risk cases (hybrid as interim). + + + diff --git a/quantum-top-10/QS07_Hardware-Roots-of-Trust.md b/quantum-top-10/QS07_Hardware-Roots-of-Trust.md new file mode 100644 index 0000000..00bdd30 --- /dev/null +++ b/quantum-top-10/QS07_Hardware-Roots-of-Trust.md @@ -0,0 +1,42 @@ +## QS07:2026 - Hardware Roots of Trust + +**Description:** + +Hardware roots of trust are cryptographic anchors burned into silicon, firmware, or sealed devices: TPM endorsement keys, UEFI Secure Boot platform keys, smart-card root certificates, HSM device identities, embedded SSL certificates in IoT devices, signed firmware in vehicles and industrial controllers. They are designed to be tamper-resistant and difficult to update - the opposite of what PQC migration requires - and they have the longest replacement cycle of any cryptographic asset class. The ML-DSA and SLH-DSA schemes have substantially larger keys and signatures than RSA or ECDSA, with material implications for HSMs, smart cards, and constrained devices that may lack capacity for the new primitives. Devices in service today will likely outlive any practical PQC deadline: operational technology and industrial control systems often run for 15-20 years, so hardware shipped in 2026 will still be in service in 2041. + +**Common Examples of Vulnerability:** + +1. Hardware roots of trust with no in-place upgrade path: TPMs, UEFI keys, smart cards, HSMs, embedded device certificates, signed firmware, automotive and industrial control system certificates. +2. Devices whose expected replacement cycle crosses the 2030 or 2035 PQC deadline applicable to their sector but which cannot be re-anchored. +3. HSMs and smart cards without capacity to hold ML-DSA keys (typically 2-4 KB) or produce ML-DSA signatures (2.4-4.5 KB). +4. IoT and OT devices - industrial controllers, smart meters, connected vehicles - treated as out of scope despite hardware-anchored cryptography. + +**How to Prevent:** + +1. Begin procurement transition now: new hardware should support PQC algorithms or be crypto-agile by design. +2. For existing devices with upgrade paths, plan and test firmware updates that introduce PQC trust anchors before existing trust is compromised. +3. For devices without upgrade paths, plan retirement or compensating-control wraps (network segmentation, restricted-lifetime certificates above the hardware anchor, additional cryptographic layers). +4. Engage TPM, HSM, smart-card, and embedded-device suppliers on PQC roadmaps during procurement. +5. Track Trusted Computing Group, UEFI Forum, and 3GPP work on PQC adaptations of hardware-anchored standards. + +**Example Attack Scenarios:** + +Scenario #1: A fleet of industrial controllers with a 20-year service life ships in 2026 with ECDSA-based signed-firmware verification and no field-update path for the trust anchor. After a CRQC exists, an attacker forges firmware signatures that the controllers accept, and there is no mechanism to rotate the anchor short of physical replacement. + +Scenario #2: An organisation attempts to migrate smart cards to ML-DSA but discovers the deployed cards lack the memory and compute to hold the larger keys and produce the larger signatures. The cards cannot be upgraded in place, so the classical root remains trusted until the entire card base is physically reissued. + +**Reference Links:** + + + +1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/): Identifies TPM, X.509 PKI, UEFI Secure Boot, and 6G as needing new PQC standards by 2028. +2. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/): Niche equipment and constrained devices CNSA 2.0 by 2033. +3. [Trusted Computing Group](https://trustedcomputinggroup.org/): Work on PQC TPM specifications. +4. [EU Cyber Resilience Act, Annex IV](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): Critical product categories including smart-card and smart-meter gateways. +5. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 profiles. + + + diff --git a/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md b/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md new file mode 100644 index 0000000..a7d05cc --- /dev/null +++ b/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md @@ -0,0 +1,41 @@ +## QS08:2026 - QPU Tenant Isolation Failures + +**Description:** + +Cloud-based quantum platforms increasingly host workloads from multiple tenants on shared QPUs, allocating qubits from a shared processor to different tenants concurrently or in rapid succession, and claiming isolation between them. Recent peer-reviewed research shows that isolation is weaker than it appears. Two classes of attack are documented: crosstalk attacks, where quantum crosstalk lets a malicious circuit on one tenant's allocation degrade the fidelity of a victim's computation on the same processor (even mere QPU-topology adjacency suffices); and state-leakage attacks, where standard reset gates fail to fully clear qubit state between consecutively executed circuits, leaking information across the boundary the platform claims to enforce. Organisations running sensitive computations - proprietary algorithms, trade-secret optimisation problems, classified workloads - must treat shared-QPU isolation as a security claim requiring evidence, not a default property. + +**Common Examples of Vulnerability:** + +1. Sensitive workloads run on shared (multi-tenant) QPUs rather than dedicated allocations. +2. Platforms whose documented isolation guarantees are unsupported by evidence such as post-execution qubit-reset verification or neighbour-isolation policies. +3. Circuits whose inputs (problem instance, parameters, hardcoded constants) or outputs constitute confidential or proprietary information, executed adjacent to untrusted tenants. +4. Reliance on standard reset gates that leave residual state observable by the next tenant on the same physical qubits. + +**How to Prevent:** + +1. For sensitive workloads, use dedicated QPU allocations or reservation modes where available, even at higher cost. +2. Where shared QPUs are unavoidable, design circuits to minimise the information value of crosstalk or state-leakage observation: split sensitive computations across runs, randomise parameter mappings, avoid embedding hardcoded sensitive constants directly in circuits. +3. Require documented isolation evidence from providers: post-execution qubit reset verification, neighbour-isolation policies, scheduling constraints. +4. Treat shared-QPU output as observable by other tenants until proven otherwise; do not pass it through trust boundaries that depend on confidentiality. +5. Track ongoing QPU-isolation research (NDSS, CCS, Usenix Security, ISLPED). + +**Example Attack Scenarios:** + +Scenario #1: A financial firm runs a proprietary optimisation circuit on a shared QPU. A malicious co-tenant schedules a circuit adjacent on the QPU topology and uses quantum crosstalk to degrade the victim's fidelity (Choudhury et al., NDSS 2025; Ash-Saki et al., ISLPED 2020), corrupting results the firm relies on - without ever needing co-execution. + +Scenario #2: A tenant's circuit is scheduled on physical qubits immediately after a competitor's workload. Because standard reset gates do not fully clear state (Xu et al., CCS 2023), the tenant observes residual state leaking information about the previous, confidential computation. + +**Reference Links:** + + + +1. [Choudhury et al. - Quantum crosstalk attacks on multi-tenant quantum systems (NDSS 2025)](https://www.ndss-symposium.org/): Demonstrated crosstalk fidelity-degradation attack. +2. [Ash-Saki et al. - Crosstalk-based fault injection in NISQ-era quantum systems (ISLPED 2020)](https://dl.acm.org/): Crosstalk fault injection. +3. [Xu et al. - Reset-gate state leakage and power side-channel attacks on quantum controllers (CCS 2023)](https://dl.acm.org/doi/proceedings/10.1145/3576915): Reset-gate state leakage across tenant boundary. +4. [EU DORA - Regulation (EU) 2022/2554, Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj): Third-party ICT risk expectation that platform claims are evidenced. + + + diff --git a/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md b/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md new file mode 100644 index 0000000..c083efb --- /dev/null +++ b/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md @@ -0,0 +1,43 @@ +## QS09:2026 - Toolchain and Compiler Compromise + +**Description:** + +A submitted quantum job is not just a circuit - it is hardcoded constants and computational data embedded in a program that flows through a compiler, transpiler, and pulse-level scheduler before reaching hardware, and each layer is a potential point of compromise. Quantum software stacks compose high-level frameworks (Qiskit, Cirq, PennyLane), transpilers, optimising compilers, pulse-level schedulers, and hardware configuration files. Two classes of attack are documented: circuit theft via compromised compilers (Suresh et al., HASP 2021), where - because circuits encode their data hardcoded as parameters - theft of the circuit is theft of both the algorithm and its inputs; and QTrojan (Chu et al., 2023), where adversaries stealthily disable data encoding inside a circuit by manipulating hardware configuration files disguised as routine pulse calibrations, so the circuit appears to execute normally but produces incorrect results invisibly. This is a supply-chain risk specific to quantum software stacks: circuit integrity, IP confidentiality, and pipeline trustworthiness must be evaluated, not assumed. + +**Common Examples of Vulnerability:** + +1. Quantum toolchains composed of multiple open-source and vendor components with limited integrity verification between stages. +2. Circuits that encode sensitive data as hardcoded parameters (most, given current platform constraints), exposed to theft anywhere along the pipeline. +3. Calibration and pulse-configuration update pipelines with weak authentication or no change auditing. +4. Production toolchains that auto-update compilers and transpilers without integrity verification. +5. Pulse and hardware configuration files treated as routine rather than a sensitive operations surface. + +**How to Prevent:** + +1. Apply software supply-chain hygiene to quantum toolchains: signed releases, verified dependencies, reproducible builds where possible. +2. Where IP is embedded in circuits, evaluate whether the provider's audit and integrity controls suffice for the threat model. +3. Pin specific versions of compilers and transpilers; do not auto-update production toolchains without integrity verification. +4. Treat hardware configuration and pulse calibration as a sensitive surface: restrict modification access and audit changes. +5. Engage platform providers on transparency around toolchain integrity controls. + +**Example Attack Scenarios:** + +Scenario #1: A compromised transpiler in the pipeline exfiltrates submitted circuits (Suresh et al., HASP 2021). Because the circuit carries its proprietary optimisation problem hardcoded as parameters, the attacker steals both the algorithm and its confidential inputs in a single theft. + +Scenario #2: An adversary alters a hardware configuration file to disable a circuit's data encoding, disguising the change as a routine pulse calibration (QTrojan, Chu et al., 2023). The victim's circuit appears to run normally but silently returns incorrect results, and the manipulation is invisible to the submitting user. + +**Reference Links:** + + + +1. [Suresh et al. - Circuit theft via compromised quantum compilers (HASP 2021)](https://dl.acm.org/): Compiler-based circuit-theft attack. +2. [Chu et al. - QTrojan: stealthy data-encoding disablement via hardware configuration manipulation (2023)](https://arxiv.org/): QTrojan attack. +3. [SLSA - Supply-chain Levels for Software Artifacts](https://slsa.dev/): Supply-chain integrity framework applicable in spirit. +4. [EU DORA - Regulation (EU) 2022/2554, Articles 28-44](https://eur-lex.europa.eu/eli/reg/2022/2554/oj): Third-party ICT risk obligations extending to provider toolchain integrity. +5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art integrity and authenticity for quantum software products. + + + diff --git a/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md b/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md new file mode 100644 index 0000000..6faf89d --- /dev/null +++ b/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md @@ -0,0 +1,43 @@ +## QS10:2026 - Side-Channel and Control-Plane Exposure + +**Description:** + +Unlike classical processors, quantum computers depend on extensive classical control infrastructure to execute any quantum operation - signal generators, mixers, FPGAs, room-scale racks of conventional electronics, and classical control software. This control plane mediates everything that reaches the QPU and everything observed from it, has not been studied comprehensively from a security perspective, and is more physically accessible than the microchip-scale architecture of classical CPUs. Side-channel attacks against this layer are demonstrated: timing analysis of reset operations reveals program execution patterns (Mi et al., CCS 2022), and power-consumption traces from quantum controllers enable reverse-engineering of gate-level circuits (Xu et al., CCS 2023). Combined with the fact that current platforms have no quantum memory or quantum networking - so every job carries its data hardcoded into the program itself - interception or side-channel observation of the control plane is a direct path to leaking the workload it runs. + +**Common Examples of Vulnerability:** + +1. Classical control infrastructure (signal generators, mixers, FPGAs, control software) accessible to other tenants or the platform operator. +2. Timing observability of a tenant's circuit execution, leaking program structure via reset-operation timing. +3. Power-trace observability where control electronics are co-located with other workloads in a shared physical environment. +4. Platforms that do not document side-channel resistance properties. +5. Sensitive data hardcoded into circuits (no quantum memory), so any control-plane compromise is data compromise. + +**How to Prevent:** + +1. For sensitive workloads, prefer providers that document side-channel resistance and physical isolation properties. +2. For on-premises quantum hardware, apply physical security controls comparable to cryptographic key infrastructure: restricted access, monitoring, tamper-evidence. +3. Where workloads can be split, randomise execution timing and parameter ordering to reduce information leak. +4. Engage providers on disclosure of side-channel research and applied mitigations. +5. Treat control-plane compromise as equivalent to workload compromise - the data is hardcoded in the circuit. +6. Track ongoing research; new results appear at major security venues each year. + +**Example Attack Scenarios:** + +Scenario #1: An attacker with access to the classical control plane performs timing analysis of reset operations (Mi et al., CCS 2022), recovering the structure of a victim tenant's quantum program from the timing of classical reset commands - without touching the qubits themselves. + +Scenario #2: Power-consumption traces are captured from the controllers driving the QPU (Xu et al., CCS 2023). Power analysis of the classical electronics recovers the gate sequence of a confidential circuit; because the circuit's data is hardcoded, reconstructing the gates reconstructs the workload and its inputs. + +**Reference Links:** + + + +1. [Mi et al. - Timing side channels in quantum reset operations (CCS 2022)](https://dl.acm.org/doi/proceedings/10.1145/3548606): Timing side channel revealing program execution patterns. +2. [Xu et al. - Power side-channel attacks on quantum controllers (CCS 2023)](https://dl.acm.org/doi/proceedings/10.1145/3576915): Gate-level circuit reverse-engineering via power traces. +3. [NIST FIPS 140-3 - Security Requirements for Cryptographic Modules](https://csrc.nist.gov/pubs/fips/140-3/final): Classical physical-security framework offering partial conceptual coverage. +4. [Common Criteria (ISO/IEC 15408)](https://www.commoncriteriaportal.org/): Side-channel evaluation concepts not yet adapted to quantum control infrastructure. + + + diff --git a/quantum-top-10/_template.md b/quantum-top-10/_template.md new file mode 100644 index 0000000..e6ce012 --- /dev/null +++ b/quantum-top-10/_template.md @@ -0,0 +1,28 @@ +## Vulnerability Name + +**Description:** + +A brief description of the vulnerability that includes its potential effects such as system compromises, data breaches, or other security concerns. + +**Common Examples of Vulnerability:** + +1. Example 1: Specific instance or type of this vulnerability. +2. Example 2: Another instance or type of this vulnerability. +3. Example 3: Yet another instance or type of this vulnerability. + +**How to Prevent:** + +1. Prevention Step 1: A step or strategy that can be used to prevent the vulnerability or mitigate its effects. +2. Prevention Step 2: Another prevention step or strategy. +3. Prevention Step 3: Yet another prevention step or strategy. + +**Example Attack Scenarios:** + +Scenario #1: A detailed scenario illustrating how an attacker could potentially exploit this vulnerability, including the attacker's actions and the potential outcomes. + +Scenario #2: Another example of an attack scenario showing a different way the vulnerability could be exploited. + +**Reference Links:** + +1. [Link Title](URL): Brief description of the reference link. +2. [Link Title](URL): Brief description of the reference link. From 1ede68c06ef038814613c266d17932c5bb5eec01 Mon Sep 17 00:00:00 2001 From: John Sotiropoulos Date: Mon, 13 Jul 2026 18:33:28 +0100 Subject: [PATCH 2/2] Verify reference URLs and add Standards & Regulatory Mapping sections - Replace best-effort URLs with verified canonical sources (NIST, NCSC, EU roadmap/EUR-Lex, NSA, CISA, IETF, academic DOIs) - Correct QS08 mis-citation: 'Choudhury et al.' -> Li et al., NDSS 2025 - Split the two distinct Xu et al. CCS 2023 papers (QS08 reset, QS10 power) - Correct academic titles; note Suresh/Mi are countermeasure papers - Promote Standards & Regulatory Mapping to a visible TODO-flagged section --- ...QS01_Harvest-Now-Decrypt-Later-Exposure.md | 15 ++++++++------- .../QS02_Long-Lived-Sensitive-Data.md | 15 ++++++++------- ..._Vulnerable-Signatures-and-Code-Signing.md | 13 +++++++------ ...Absent-Cryptographic-Inventory-and-CBOM.md | 13 +++++++------ .../QS05_Crypto-Agility-Failures.md | 15 ++++++++------- ...06_Insecure-Migration-and-Hybrid-Misuse.md | 13 +++++++------ .../QS07_Hardware-Roots-of-Trust.md | 15 ++++++++------- .../QS08_QPU-Tenant-Isolation-Failures.md | 19 ++++++++++--------- .../QS09_Toolchain-and-Compiler-Compromise.md | 17 +++++++++-------- ...Side-Channel-and-Control-Plane-Exposure.md | 13 +++++++------ 10 files changed, 79 insertions(+), 69 deletions(-) diff --git a/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md index a4e737b..d8e1194 100644 --- a/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md +++ b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md @@ -26,15 +26,16 @@ Scenario #2: An organisation encrypts long-retention backups at rest with AES-25 **Reference Links:** - + 1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final): Key-establishment standard for post-quantum migration. -2. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/): Migration timelines calling out long-lived sensitive data as a priority class. -3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases. -4. [White House National Security Memorandum 10 (NSM-10) / OMB M-23-02](https://www.whitehouse.gov/): Cite HNDL as the primary driver of US migration urgency. +2. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Migration timelines calling out long-lived sensitive data as a priority class. +3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases. +4. [White House National Security Memorandum 10 (NSM-10)](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/) and [OMB M-23-02](https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf): Cite HNDL as the primary driver of US migration urgency. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NIST FIPS 203 (ML-KEM) for key establishment. NCSC Timelines for migration to post-quantum cryptography (March 2025). EU Coordinated Implementation Roadmap (June 2025), end-2030 high-risk deadline. NSA CNSA 2.0 prioritises network encryption and long-lived secrets. NIS2 Article 21(2)(h) cryptographic policy obligation; DORA Article 9 confidentiality and integrity at rest, in use and in transit. NSM-10 and OMB M-23-02 cite HNDL as the migration driver. diff --git a/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md b/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md index bb9467b..3022fd6 100644 --- a/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md +++ b/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md @@ -27,15 +27,16 @@ Scenario #2: A vendor issues software releases signed with ECDSA, with signature **Reference Links:** - + 1. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality. -2. [UK NCSC migration guidance](https://www.ncsc.gov.uk/): Long-lived data prioritisation for PQC migration. -3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/): End-2030 high-risk deadline and standalone-PKC prohibition. -4. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art protection required through the product support period. +2. [UK NCSC - Next steps in preparing for post-quantum cryptography](https://www.ncsc.gov.uk/paper/next-steps-in-preparing-for-post-quantum-cryptography): Long-lived data prioritisation for PQC migration. +3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 high-risk deadline and standalone-PKC prohibition. +4. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art protection required through the product support period. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NIST IR 8547 (Draft) on transition planning. NCSC migration guidance on long-lived data prioritisation. EU Coordinated Implementation Roadmap end-2030 high-risk deadline; explicit prohibition on standalone quantum-vulnerable PKC for high-risk cases after 2030. CRA Annex I requires state-of-the-art protection through the support period, which for many products extends past 2030. diff --git a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md index 614e549..016fa0d 100644 --- a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md +++ b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md @@ -27,16 +27,17 @@ Scenario #2: An organisation migrates its leaf TLS certificates to PQC but leave **Reference Links:** - + 1. [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Module-lattice digital signature standard. 2. [NIST FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final): Stateless hash-based signature standard for high-assurance, long-lived use. -3. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/): Software and firmware signing exclusively CNSA 2.0 by 2030. +3. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/): Software and firmware signing exclusively CNSA 2.0 by 2030. 4. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 and CMS extensions. -5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art integrity and authenticity requirements. +5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art integrity and authenticity requirements. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NIST FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). NSA CNSA 2.0: software and firmware signing exclusively CNSA 2.0 by 2030. NCSC recommends ML-DSA-65 for most use cases. EU CRA Annex I requires state-of-the-art mechanisms for integrity and authenticity. IETF LAMPS working group on PQC X.509 and CMS extensions. DORA Articles 28-44 on third-party risk management apply to PKI and signing service vendors. diff --git a/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md b/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md index 8aadbd6..49d9c6e 100644 --- a/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md +++ b/quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md @@ -28,16 +28,17 @@ Scenario #2: A SaaS dependency terminates TLS with a quantum-vulnerable configur **Reference Links:** - + -1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/): 2028 discovery-and-assessment milestone. -2. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): End-2026 inventory and dependency-map requirement. +1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): 2028 discovery-and-assessment milestone. +2. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2026 inventory and dependency-map requirement. 3. [CISA, NSA, NIST - Quantum-Readiness: Migration to PQC fact sheet (August 2023)](https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography): Cryptographic inventory recommendation. 4. [CycloneDX CBOM specification](https://cyclonedx.org/capabilities/cbom/): Cryptography Bill of Materials schema. 5. [NIST IR 8547 (Draft)](https://csrc.nist.gov/pubs/ir/8547/ipd): Lifecycle management for transition planning. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NCSC Timelines for migration to post-quantum cryptography (2028 discovery milestone). EU Coordinated Implementation Roadmap end-2026 inventory and dependency-map requirement. CISA, NSA, NIST Quantum-Readiness fact sheet (August 2023) cryptographic inventory recommendation. NIST IR 8547 on lifecycle management. NIS2 Article 21(2)(h). DORA Article 9 ICT risk management obligation. CycloneDX and SPDX CBOM specifications. diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index 3280f91..5e94827 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -29,16 +29,17 @@ Scenario #2: A team adds a crypto abstraction layer but never tests rotation. Wh **Reference Links:** - + 1. [CISA, NSA, NIST - Quantum-Readiness fact sheet](https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography): Cryptographic agility recommendation. -2. [UK NCSC guidance on crypto-agility](https://www.ncsc.gov.uk/): Agility expectations for migration. -3. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): Explicit agility expectation. +2. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Agility expectations within PQC migration guidance. +3. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): Explicit agility expectation. 4. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Agility documents and migration patterns. -5. [IETF TLS Working Group](https://datatracker.ietf.org/wg/tls/about/): Hybrid KEM and signature negotiation. +5. [IETF - Hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/): Hybrid KEM negotiation. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +CISA, NSA, NIST Quantum-Readiness fact sheet (cryptographic agility recommendation). NCSC guidance on crypto-agility. EU Coordinated Implementation Roadmap explicit agility expectation. NIS2 Article 21(2)(h) implies agility through state-of-the-art and risk-based requirements. IETF PQUIP working group agility documents; IETF TLS working group on hybrid KEM and signature negotiation. diff --git a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md index b267b44..bee7a08 100644 --- a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md +++ b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md @@ -30,15 +30,16 @@ Scenario #2: A team builds a custom hybrid KEM that derives the session key from **Reference Links:** - + 1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. -2. [IETF - Hybrid PQ Key Exchange in TLS 1.3 (draft)](https://datatracker.ietf.org/wg/tls/about/): Standard hybrid KEM construction. +2. [IETF - Hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/): Standard hybrid KEM construction. 3. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. -4. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/): End-2030 standalone-classical prohibition for high-risk cases (hybrid as interim). +4. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 standalone-classical prohibition for high-risk cases (hybrid as interim). - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NIST FIPS 203, FIPS 204. NCSC guidance treats hybrid as interim. EU Coordinated Implementation Roadmap end-2030 standalone-classical prohibition for high-risk cases. NIS2 Article 21(2)(h) state-of-the-art cryptography obligation, which supervisors increasingly read as requiring correctly-constructed hybrid during transition. DORA Article 9 confidentiality and integrity obligations apply to financial entities deploying hybrid TLS in production. IETF drafts on Hybrid PQ Key Exchange in TLS 1.3 and on Composite ML-DSA. IETF PQUIP working group migration documents. diff --git a/quantum-top-10/QS07_Hardware-Roots-of-Trust.md b/quantum-top-10/QS07_Hardware-Roots-of-Trust.md index 00bdd30..3969dd2 100644 --- a/quantum-top-10/QS07_Hardware-Roots-of-Trust.md +++ b/quantum-top-10/QS07_Hardware-Roots-of-Trust.md @@ -27,16 +27,17 @@ Scenario #2: An organisation attempts to migrate smart cards to ML-DSA but disco **Reference Links:** - + -1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/): Identifies TPM, X.509 PKI, UEFI Secure Boot, and 6G as needing new PQC standards by 2028. -2. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/): Niche equipment and constrained devices CNSA 2.0 by 2033. +1. [UK NCSC - Timelines for migration to post-quantum cryptography](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Identifies TPM, X.509 PKI, UEFI Secure Boot, and 6G as needing new PQC standards by 2028. +2. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/): Niche equipment and constrained devices CNSA 2.0 by 2033. 3. [Trusted Computing Group](https://trustedcomputinggroup.org/): Work on PQC TPM specifications. -4. [EU Cyber Resilience Act, Annex IV](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): Critical product categories including smart-card and smart-meter gateways. +4. [EU Cyber Resilience Act, Annex IV](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): Critical product categories including smart-card and smart-meter gateways. 5. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 profiles. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +NCSC Timelines for migration explicitly identifies hardware roots of trust. NSA CNSA 2.0: niche equipment and constrained devices CNSA 2.0 by 2033. IETF LAMPS for X.509 PQC. Trusted Computing Group work on PQC TPM specifications. UEFI Forum Secure Boot evolution. EU CRA Annex IV critical product categories (smart meter gateways, smart cards). 3GPP work on PQC for 6G and post-5G cellular. diff --git a/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md b/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md index a7d05cc..f93a76b 100644 --- a/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md +++ b/quantum-top-10/QS08_QPU-Tenant-Isolation-Failures.md @@ -21,21 +21,22 @@ Cloud-based quantum platforms increasingly host workloads from multiple tenants **Example Attack Scenarios:** -Scenario #1: A financial firm runs a proprietary optimisation circuit on a shared QPU. A malicious co-tenant schedules a circuit adjacent on the QPU topology and uses quantum crosstalk to degrade the victim's fidelity (Choudhury et al., NDSS 2025; Ash-Saki et al., ISLPED 2020), corrupting results the firm relies on - without ever needing co-execution. +Scenario #1: A financial firm runs a proprietary optimisation circuit on a shared QPU. A malicious co-tenant schedules a circuit adjacent on the QPU topology and uses quantum crosstalk to degrade the victim's fidelity (Li et al., NDSS 2025; Ash-Saki et al., ISLPED 2020), corrupting results the firm relies on - without ever needing co-execution. Scenario #2: A tenant's circuit is scheduled on physical qubits immediately after a competitor's workload. Because standard reset gates do not fully clear state (Xu et al., CCS 2023), the tenant observes residual state leaking information about the previous, confidential computation. **Reference Links:** - + -1. [Choudhury et al. - Quantum crosstalk attacks on multi-tenant quantum systems (NDSS 2025)](https://www.ndss-symposium.org/): Demonstrated crosstalk fidelity-degradation attack. -2. [Ash-Saki et al. - Crosstalk-based fault injection in NISQ-era quantum systems (ISLPED 2020)](https://dl.acm.org/): Crosstalk fault injection. -3. [Xu et al. - Reset-gate state leakage and power side-channel attacks on quantum controllers (CCS 2023)](https://dl.acm.org/doi/proceedings/10.1145/3576915): Reset-gate state leakage across tenant boundary. -4. [EU DORA - Regulation (EU) 2022/2554, Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj): Third-party ICT risk expectation that platform claims are evidenced. +1. [Li et al. - Crosstalk-induced Side Channel Threats in Multi-Tenant NISQ Computers (NDSS 2025)](https://www.ndss-symposium.org/ndss-paper/crosstalk-induced-side-channel-threats-in-multi-tenant-nisq-computers/): Demonstrated crosstalk-based side-channel/fidelity attack on shared QPUs. (Corrects the earlier "Choudhury et al." mis-citation; arXiv:2412.10507.) +2. [Ash-Saki et al. - Analysis of Crosstalk in NISQ Devices and Security Implications in Multi-Programming Regime (ISLPED 2020)](https://doi.org/10.1145/3370748.3406570): Crosstalk-based fault injection. +3. [Xu et al. - Securing NISQ Quantum Computer Reset Operations Against Higher Energy State Attacks (CCS 2023)](https://doi.org/10.1145/3576915.3623104): Documents reset-operation state leakage across the tenant boundary. +4. [EU DORA - Regulation (EU) 2022/2554, Article 28](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng): Third-party ICT risk expectation that platform claims are evidenced. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +No formal standard yet covers QPU tenant isolation. NIST and NCSC have not published guidance on quantum platform security. The relevant published research includes Li et al. on crosstalk-induced side-channel threats (NDSS 2025), Ash-Saki et al. on crosstalk-based fault injection (ISLPED 2020), and Xu et al. on reset-operation state leakage (CCS 2023). Where DORA Article 28 third-party risk applies to financial entities using quantum platform services, the supervisory expectation is that platform security claims are evidenced rather than assumed. diff --git a/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md b/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md index c083efb..48a79bb 100644 --- a/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md +++ b/quantum-top-10/QS09_Toolchain-and-Compiler-Compromise.md @@ -28,16 +28,17 @@ Scenario #2: An adversary alters a hardware configuration file to disable a circ **Reference Links:** - + -1. [Suresh et al. - Circuit theft via compromised quantum compilers (HASP 2021)](https://dl.acm.org/): Compiler-based circuit-theft attack. -2. [Chu et al. - QTrojan: stealthy data-encoding disablement via hardware configuration manipulation (2023)](https://arxiv.org/): QTrojan attack. +1. [Suresh et al. - Short Paper: A Quantum Circuit Obfuscation Methodology for Security and Privacy (HASP 2021)](https://doi.org/10.1145/3505253.3505260): Establishes the untrusted-compiler circuit-IP-theft threat and proposes an obfuscation countermeasure. +2. [Chu et al. - QTrojan: A Circuit Backdoor Against Quantum Neural Networks (IEEE ICASSP 2023)](https://doi.org/10.1109/ICASSP49357.2023.10096293): Backdoor triggered via quantum-compiler configuration files ([arXiv:2302.08090](https://arxiv.org/abs/2302.08090)). 3. [SLSA - Supply-chain Levels for Software Artifacts](https://slsa.dev/): Supply-chain integrity framework applicable in spirit. -4. [EU DORA - Regulation (EU) 2022/2554, Articles 28-44](https://eur-lex.europa.eu/eli/reg/2022/2554/oj): Third-party ICT risk obligations extending to provider toolchain integrity. -5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj): State-of-the-art integrity and authenticity for quantum software products. +4. [EU DORA - Regulation (EU) 2022/2554, Articles 28-44](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng): Third-party ICT risk obligations extending to provider toolchain integrity. +5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art integrity and authenticity for quantum software products. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +No formal standard yet covers quantum toolchain integrity directly. The relevant published research includes Suresh et al. on circuit-theft attacks (HASP 2021) and Chu et al. on QTrojan (2023). General software supply chain frameworks - SLSA, Sigstore, CISA Secure Software Development Framework - apply in spirit but have not been adapted to quantum stacks. Where regulated entities consume quantum platform services, DORA Articles 28-44 third-party ICT risk obligations extend to the toolchain integrity of those providers. EU CRA Annex I state-of-the-art integrity and authenticity requirements apply to quantum software products placed on the EU market. diff --git a/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md b/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md index 6faf89d..b2d703a 100644 --- a/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md +++ b/quantum-top-10/QS10_Side-Channel-and-Control-Plane-Exposure.md @@ -29,15 +29,16 @@ Scenario #2: Power-consumption traces are captured from the controllers driving **Reference Links:** - + -1. [Mi et al. - Timing side channels in quantum reset operations (CCS 2022)](https://dl.acm.org/doi/proceedings/10.1145/3548606): Timing side channel revealing program execution patterns. -2. [Xu et al. - Power side-channel attacks on quantum controllers (CCS 2023)](https://dl.acm.org/doi/proceedings/10.1145/3576915): Gate-level circuit reverse-engineering via power traces. +1. [Mi et al. - Securing Reset Operations in NISQ Quantum Computers (CCS 2022)](https://doi.org/10.1145/3548606.3559380): Documents reset-operation state leakage / timing exposure across tenants. +2. [Xu et al. - Exploration of Power Side-Channel Vulnerabilities in Quantum Computer Controllers (CCS 2023)](https://doi.org/10.1145/3576915.3623118): Gate-level circuit reverse-engineering via power traces. 3. [NIST FIPS 140-3 - Security Requirements for Cryptographic Modules](https://csrc.nist.gov/pubs/fips/140-3/final): Classical physical-security framework offering partial conceptual coverage. 4. [Common Criteria (ISO/IEC 15408)](https://www.commoncriteriaportal.org/): Side-channel evaluation concepts not yet adapted to quantum control infrastructure. - +> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. + +No formal standard yet covers quantum platform side channels. The relevant published research includes Mi et al. on timing side channels (CCS 2022) and Xu et al. on power side-channel attacks (CCS 2023). General classical side-channel frameworks (FIPS 140-3 physical security requirements, Common Criteria) provide partial conceptual coverage but have not been adapted to quantum control infrastructure.