Cryptografisch wijzigingsbeheer en CBOM-bewijs

Quantsiv vindt de cryptografie die quantumcomputers zouden kunnen kraken

Het laat zien wat je eerst moet aanpakken, op basis van hoe lang je gegevens geheim moeten blijven, en markeert wijzigingen die er meer van toevoegen. Het scannen draait standaard in je eigen build-pipeline en levert een standaardoverzicht op van wat het vond: een Cryptographic Bill of Materials (CBOM).

Waarom het ertoe doet Bekijk de roadmap

Een toekomstige quantumcomputer zou de publieke-sleutelcryptografie kunnen kraken die vandaag breed wordt gebruikt, en de VS en de EU hebben datums gepubliceerd om die te vervangen. Vervangen begint met weten waar ze zit. Quantsiv scant je code bij elke build en laat zien wat blootligt, hoe lang het blootligt en waarnaar je moet overstappen.

Harvest Now, Decrypt Later

Aanvallers kunnen versleutelde gegevens vandaag kopiëren en bewaren tot een quantumcomputer ze kan ontsleutelen. Voor gegevens die jarenlang geheim moeten blijven, begint het risico nu.

Nu stelen, later lezen

Een aanvaller heeft vandaag geen quantumcomputer nodig. Het volstaat om je versleutelde verkeer en gestolen gegevens nu op te slaan en ze te ontsleutelen zodra er een quantumcomputer bestaat die groot genoeg is. RSA, ECDSA, Diffie-Hellman en DSA, de gangbare publieke-sleutelmethoden, vallen allemaal voor een bekende quantummethode, het algoritme van Shor. Bij wallets voor cryptoactiva is de blockchain zelf het archief: een publieke sleutel die al on-chain staat, is genoeg om later een overdracht te vervalsen.

De echte deadline is de levensduur van je gegevens

Het gaat er niet om wanneer de quantumcomputer komt, maar hoe lang je gegevens geheim moeten blijven. Moeten de gegevens van een systeem 25 jaar vertrouwelijk blijven, dan loopt verkeer dat gisteren is onderschept nu al risico. Medische dossiers, financiële gegevens, overheidscommunicatie en bedrijfsgeheimen moeten vaak jarenlang geheim blijven.

AI-codeassistenten kunnen kwetsbare standaardkeuzes herhalen

Codeassistenten kiezen cryptografie door bekende patronen aan te vullen, en kunnen zo oude standaardkeuzes herhalen die een quantumcomputer zou kunnen kraken. De code werkt en slaagt voor de tests, en is toch kwetsbaar.

Vandaag

Onderscheppen

Aanvallers leggen versleuteld verkeer vast, kopiëren versleutelde gegevens en bewaren die.

Later

Ontsleutelen

Een quantumcomputer die groot genoeg is, kraakt de publieke-sleutelcryptografie die de bewaarde kopieën beschermde.

Daarna

Blootleggen

Gegevens waarvan de versleuteling op RSA of ECC steunde, kunnen dan worden gelezen, ook gegevens die nog jaren vertrouwelijk moeten blijven. Bij handtekeningen is het risico anders: vervalsing in de toekomst, niet het lezen van oude gegevens.

De deadline staat al vast

Dit zijn gepubliceerde datums, geen voorspellingen. Normalisatie-instellingen en overheden in de VS en de EU hebben richtlijnen en eisen met datums uitgebracht om de kwetsbare cryptografie te vervangen.

13 aug 2024

NIST publiceert de vervangende standaarden

Het Amerikaanse standaardeninstituut publiceert drie nieuwe algoritmen: FIPS 203 (ML-KEM) om de sleutels af te spreken waarmee gegevens worden versleuteld, en FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) voor digitale handtekeningen. De vervangers bestaan nu.
nov 2024

NIST stelt voor wanneer de huidige algoritmen worden uitgefaseerd

In het eerste openbare concept van NIST IR 8547 worden RSA, ECC en DH met een sterkte van 112 bits, zoals RSA-2048, na 2030 afgeraden (deprecated). Alle quantumkwetsbare publieke-sleutelalgoritmen, ook P-256, zijn na 2035 niet meer toegestaan (disallowed).
22 jun 2026

Een Amerikaanse Executive Order stelt deadlines voor 2030 en 2031

Executive Order 14412 gaat in op de dreiging van harvest now, decrypt later. Het decreet stelt 31 dec 2030 als termijn voor post-quantum sleuteluitwisseling en 31 dec 2031 voor handtekeningen, op high-value assets en systemen met hoge impact.
24 jun 2026

OMB M-26-15 plant de federale migratie in fasen

Vijf fasen van 2026 tot 2035, van het Amerikaanse Office of Management and Budget. Federale instanties bouwen een geautomatiseerde inventaris waarvan de gegevens "should populate a central Cryptographic Bill of Materials" (een centrale CBOM zouden moeten vullen). De plannen van de instanties moeten uiterlijk 22 okt 2026 zijn ingediend.
~mrt 2027

Richtlijnen over wat een CBOM zou moeten bevatten

CISA, het Amerikaanse agentschap voor cyberveiligheid, publiceert in afstemming met NIST binnen 270 dagen na EO 14412 richtlijnen over de minimumelementen van een CBOM, rond maart 2027.
2030 – 2035

Migratiedeadlines lopen tot 2035

Onder EO 14412: sleuteluitwisseling uiterlijk 31 dec 2030 en handtekeningen uiterlijk 31 dec 2031 op high-value assets en systemen met hoge impact, met een voorgestelde FAR-regel (Federal Acquisition Regulation) voor betrokken opdrachtnemers. NSA CNSA 2.0 stelt datums voor exclusief gebruik tussen 2030 en 2033, afhankelijk van de categorie. In de EU vraagt de roadmap van de NIS-samenwerkingsgroep (23 jun 2025, een aanbeveling) om nationale strategieën tegen eind 2026, toepassingen met hoog risico tegen eind 2030 en zoveel systemen als haalbaar tegen 2035.

Bronnen: EO 14412, OMB M-26-15, NIST IR 8547, CISA Post-Quantum Cryptography Initiative, NSA CNSA 2.0, NIST FIPS 203, roadmap van de NIS-samenwerkingsgroep (EU).

Hoe Quantsiv werkt

Vier stappen, van het scannen van je code tot een standaardoverzicht van de cryptografie erin (een CycloneDX 1.6 CBOM).

1. Ontdekken

Quantsiv zoekt naar cryptografie in broncode, sleutel- en certificaatbestanden, buildscripts en de beveiligde verbindingen (TLS) van servers die je opgeeft of waarvan je aantoont dat ze van jou zijn. Standaard draait het in je CI, de geautomatiseerde build die draait telkens als je ontwikkelaars code wijzigen. Alleen de CBOM en de gegevens van elke bevinding bereiken Quantsiv, en alleen als je ze uploadt.

2. Analyseren

Elke bevinding wordt getoetst aan de algoritmen die een quantumcomputer zou kunnen kraken: RSA, ECDSA, Diffie-Hellman en DSA. Versleuteling en sleuteluitwisseling worden gerangschikt naar hoe lang de gegevens volgens jou geheim moeten blijven, het risico van harvest now, decrypt later. Handtekeningen worden op een apart spoor gerangschikt, afgezet tegen de deadline voor handtekeningen.

3. Prioriteren

De resultaten worden zo gerangschikt dat de belangrijkste oplossingen eerst komen, niet de langste lijst. Een medisch dossier dat jarenlang geheim moet blijven en een inlogtoken dat kort geldig is, zijn niet hetzelfde risico, ook als ze allebei RSA gebruiken. Elke bevinding zegt waarom ze op die plaats staat en, waar het gebruik duidelijk is, naar welke standaard je overstapt.

4. Aantonen

Quantsiv schrijft een CycloneDX 1.6 CBOM, een SARIF-bestand voor code-scantools en een gerangschikt rapport. Elke build wordt vergeleken met de laatste build van je hoofdbranch, en de wijzigingscontrole markeert cryptografie die een wijziging toevoegt, zodat de migratie niet terugglijdt.

Wat Quantsiv doet

Quantsiv vindt cryptografie door bekende patronen in code te herkennen. Het detecteert gangbare cryptografische API's in Python, JavaScript en TypeScript, Go, Java en Kotlin, C#, Rust, Ruby, PHP, C en C++, Objective-C, Swift en Dart, openssl-, ssh-keygen- en keytool-opdrachten in CI- en shellscripts, en sleutels en certificaten in PEM- en SSH-formaat. Omdat het patronen herkent, verschilt de diepgang per taal en worden sommige aanroepen gemist.

Cryptographic Bill of Materials

Een ingrediëntenlijst voor cryptografie: wat er is gevonden en waar. Quantsiv schrijft CycloneDX 1.6 die de strikte validatie van het schema doorstaat, importeert een CycloneDX 1.6 CBOM van elke andere tool en exporteert de laatste CBOM van elke repository als één document.

Gerangschikt naar hoe lang gegevens geheim blijven

Je geeft per soort gegevens op hoe lang ze vertrouwelijk moeten blijven, en versleuteling en sleuteluitwisseling worden naar die levensduur gerangschikt. Handtekeningen worden apart gevolgd tegen de deadline voor handtekeningen, omdat hun risico vervalsing is, niet dat iemand oude gegevens leest.

Markeert wijzigingen die er meer toevoegen

Elke build wordt vergeleken met de laatste build van je hoofdbranch, en cryptografie die een wijziging toevoegt, wordt gemarkeerd. Stel regels in per soort gegevens en leg uitzonderingen vast met een goedkeurder op naam en een vervaldatum. De resultaten gaan als SARIF naar GitHub Code Scanning en, met de template voor GitHub Actions, als commentaar naar de pull request.

Draait in je eigen build

Een container, een kant-en-klaar pakket, met templates voor GitHub Actions, GitLab, Jenkins en Azure DevOps. Het scannen werkt offline. Alleen de CBOM en de gegevens van elke bevinding bereiken Quantsiv, en alleen als je ze uploadt.

Sleutels, certificaten en beveiligde verbindingen

Leest sleutel- en certificaatbestanden op algoritme en grootte, en bewaart nooit de sleutel zelf. Peilt de beveiligde verbinding (TLS) van servers die je opgeeft; de gehoste dienst peilt alleen domeinen waarvan je met een DNS-record aantoont dat ze van jou zijn.

Code voor wallets en custody

Vindt de ondertekening en sleuteluitwisseling in gangbare walletbibliotheken: secp256k1- en Ed25519-sleutels voor ondertekening, Schnorr-handtekeningen en sleuteltransport met ECDH en ECIES. Zodra de publieke sleutel van een wallet op de blockchain staat, is het risico een vervalste overdracht, geen ontsleuteling, en de aanwijzing bij de bevinding zegt wat te doen tot de chain post-quantumhandtekeningen accepteert. Leest code, niet de blockchain.

Voor AI-codeassistenten

Met een alleen-lezen koppeling (een MCP-server) kan een AI-codeassistent je regels en opgegeven levensduren van gegevens opvragen voordat hij cryptografie schrijft. Dezelfde controle draait daarna in je build. De koppeling kan niets wijzigen en bevat geen AI-model van ons.

Waar je naar overstapt

Waar het gebruik duidelijk is, noemt elke bevinding de standaard om naar over te stappen: ML-KEM (FIPS 203), ML-DSA (FIPS 204) of SLH-DSA (FIPS 205), met hybride sleuteluitwisseling, oud en nieuw gecombineerd, tijdens de overgang.

Eerlijke beperkingen

Patroonherkenning mist aanroepen onder een andere naam of die pas tijdens het draaien ontstaan, code van buiten die in een project is gekopieerd (vendored code), en pakketten van derden (afhankelijkheden). We noemen de beperkingen vooraf.

Roadmap

Afgestemd op de Amerikaanse en Europese deadlines hierboven.

Fase 1 · Nu → 2027

Audit

Laten zien waar elke applicatie cryptografie gebruikt, vanuit haar eigen build. De functies hierboven zijn gebouwd; hierna in deze fase:

Post-quantum- en hybride cryptografie meegeteld als migratievoortgang, in code, sleutels, certificaten en configuratie
Een inventaris van pakketten van derden (afhankelijkheden): welke cryptografie meebrengen
Rapporten die hun dekking vermelden, zodat een gedeeltelijke scan niet wordt aangezien voor een schone
CBOM-uitvoer afgestemd op de minimumelementen van CISA zodra die verschijnen, rond maart 2027, en CycloneDX 1.7 geaccepteerd bij import
CBOM-bewijsrapporten voor auditors, met verwijzing naar de Amerikaanse en Europese richtlijnen

Fase 2 · 2027 → 2028

Migreren

De cirkel sluiten van bevinding tot oplossing, waarbij een mens elke wijziging goedkeurt.

Voorgestelde oplossingen als concept-pull requests met de codewijziging, de onderbouwing en de geciteerde richtlijn, ter beoordeling door een mens
Migratiedoelen die standaard hybride sleuteluitwisseling gebruiken, met de platformversies die elke wijziging nodig heeft
Tests die elke wijziging controleren voordat een mens die beoordeelt

Fase 3 · 2028 → 2030

Agentische crypto-agility

Agents doen voorstellen; deterministische controles verifiëren; een mens keurt goed. Niets wordt vanzelf gemerged of uitgerold.

Fase 4 · 2030 → 2035

Platformconsolidatie

Eén product om te installeren, voor audit, migratie en review.