03 Hoe het werkt

Hoe Quantsiv werkt

Vier stappen, van het scannen van je code tot een standaardregister (een CycloneDX 1.6 CBOM).

1. Ontdekken

Quantsiv zoekt cryptografie in je broncode. Scans draaien standaard in je CI, zodat je code in je eigen omgeving blijft en Quantsiv de CBOM en de details van de bevindingen alleen ontvangt als je ze uploadt. Je kunt Quantsiv ook een openbare repository op zijn eigen servers laten scannen; private repositories worden daar niet gescand.

2. Analyseren

Elke bevinding wordt getoetst aan quantumkwetsbare algoritmen en gerangschikt naar de bewaartermijn.

3. Prioriteren

Bij elke bevinding legt Quantsiv de prioriteit uit en noemt het de standaard om naar te migreren.

4. Documenteren

Quantsiv maakt een CycloneDX 1.6 CBOM, een SARIF-bestand dat werkt met code-analysetools, en een rapport met de bevindingen op prioriteit gerangschikt. Een AI-agent gebruikt deze informatie om quantumveilige alternatieven voor te stellen en de wijzigingen te helpen plannen. Quantsiv vergelijkt de resultaten van elke build met de laatste build van de hoofdbranch en markeert terugval.

Voorbeeld van een bevinding

Output*

example/billing-service branch main commit 1e94656 Scan voltooid Illustratief voorbeeld

Cryptografische inventaris

Gevonden assets
10
Quantumkwetsbaar
9
Quantumveilig
1
Gescande bestanden
8

Ernst

  • Kritiek 4
  • Hoog 5

Blootstelling

  • Harvest Now, Decrypt Later 4
  • Vervalsing van handtekeningen 4
  • Gebruik niet ingedeeld 1

Bevindingen

6 andere assets
  • kritiekECDH-256, sleuteluitwisseling web/src/card-vault.ts:3
  • hoogECDSA-256, certificaatsleutel certs/api.crt:1
  • hoogECDSA-256, sleutelgeneratie services/ledger/sign.go:12
  • hoogECDSA, handtekening services/ledger/sign.go:17
  • hoogRSA-3072, gebruik niet ingedeeld scripts/make-release-key.sh:3
  • veiligX25519MLKEM768, hybride sleuteluitwisseling deploy/nginx.conf:6

Bevinding: RSA-OAEP encryption

kritiek Harvest Now, Decrypt Later src/billing_export.py:10
Zakelijke context
Klantgegevens moeten 25 jaar geheim blijven (opgegeven in quantsiv.yml van de repository)
Waarom deze rang
Protects data that must stay confidential for 25 years. (Beschermt gegevens die 25 jaar vertrouwelijk moeten blijven.)
Het risico
Publieke-sleutelcryptografie op basis van RSA is kwetsbaar voor quantumcomputers die krachtig genoeg zijn. Gegevens die vandaag worden onderschept, kunnen in de toekomst ontsleuteld worden als de bijbehorende versleuteling of sleuteluitwisseling wordt gekraakt.
Overstappen naar
Replace RSA encryption/key transport with ML-KEM (FIPS 203) plus an AEAD. (Vervang RSA-versleuteling en -sleuteltransport door ML-KEM (FIPS 203) plus een AEAD.)
Regelgeving
EO 14412 (22 Jun 2026): post-quantum key establishment on high-value assets and high-impact systems by 31 Dec 2030. NIST IR 8547 (ipd): 112-bit RSA/ECC/DH deprecated after 2030, all quantum-vulnerable public-key algorithms disallowed after 2035. (EO 14412 (22 jun 2026): post-quantum sleuteluitwisseling op high-value assets en systemen met hoge impact uiterlijk 31 dec 2030. NIST IR 8547 (eerste openbare concept): RSA, ECC en DH met 112-bit-sterkte na 2030 afgeraden, alle quantumkwetsbare publieke-sleutelalgoritmen na 2035 niet meer toegestaan.)

Quantsiv AI: migratieanalyse

Analyse voltooid In je CI, met het model dat je kiest Gesimuleerde uitvoer

De huidige implementatie gebruikt RSA-OAEP om geëxporteerde klantgegevens te beschermen die 25 jaar vertrouwelijk moeten blijven.

Geen één-op-één-vervanging. Hier verpakt RSA-OAEP de AES-sleutel die elke export versleutelt. ML-KEM versleutelt geen gekozen sleutel: het spreekt een gedeeld geheim af, en daaruit wordt de gegevenssleutel afgeleid. AES-256-GCM blijft de gegevens versleutelen.

Aanbevolen migratie
  1. Beoordeel de huidige RSA-OAEP-versleuteling en het sleutelbeheer.
  2. Evalueer ML-KEM (FIPS 203) voor post-quantum sleuteluitwisseling, met hybride aanpakken waar dat past.
  3. Gebruik een geauthenticeerd symmetrisch versleutelingsschema zoals AES-GCM om de gegevens zelf te versleutelen.
  4. Breng de betrokken afhankelijkheden, integraties, certificaten en compatibiliteitseisen in kaart.
  5. Geef de migratie prioriteit op basis van de vertrouwelijkheidsduur en de cryptografische blootstelling.
  6. Valideer de bijgewerkte implementatie en voer regressiecontroles uit.
Prioriteit
Kritiek, 25 jaar vertrouwelijk
Betrokken
src/billing_export.py en de ontsleutelcode van de partner, buiten deze repository
Standaarden
FIPS 203 (ML-KEM-768) voor sleuteluitwisseling; AES-256-GCM voor de gegevens
Compatibiliteit
Het exportformaat verandert, en de partner heeft een ML-KEM-sleutelpaar nodig. Exports die al zijn verstuurd, blijven zoals ze waren.
Conceptwijziging
--- a/src/billing_export.py
+++ b/src/billing_export.py
@@ -4,10 +4,11 @@
 from cryptography.hazmat.primitives import hashes
 from cryptography.hazmat.primitives.ciphers.aead import AESGCM
-from cryptography.hazmat.primitives.asymmetric import padding
+from cryptography.hazmat.primitives.kdf.hkdf import HKDF
 
 def seal_export(records, partner_key, export_id):
-    data_key = AESGCM.generate_key(bit_length=256)
-    wrapped_key = partner_key.encrypt(data_key, padding.OAEP(mgf=padding.MGF1(hashes.SHA256()), algorithm=hashes.SHA256(), label=None))
+    # Key establishment: ML-KEM-768 (FIPS 203); the records stay encrypted with AES-256-GCM
+    kem_ciphertext, shared_secret = partner_key.encapsulate()
+    data_key = HKDF(algorithm=hashes.SHA256(), length=32, salt=None, info=b"billing-export v2").derive(shared_secret)
     nonce = os.urandom(12)
     body = AESGCM(data_key).encrypt(nonce, json.dumps(records).encode(), export_id.encode())
-    return {"wrapped_key": wrapped_key, "nonce": nonce, "body": body}
+    return {"kem_ciphertext": kem_ciphertext, "nonce": nonce, "body": body}

Validatie

Controles op de conceptwijziging
  • target is a post-quantum alternative: ML-KEM-768
  • rescanned: RSA is gone
  • nothing quantum-vulnerable added
  • policy passes

Echte uitvoer van de controles van Quantsiv voor het concept hierboven. Je eigen tests draaien ook als je een controleopdracht instelt; dit voorbeeld stelt er geen in. Een mens beoordeelt de wijziging, en er wordt niets gecommit.

Bij elke volgende build

Een latere pull request voegt een RSA-sleutel toe. De wijzigingscontrole vergelijkt die met de laatste build van de hoofdbranch:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

Bevinding: TLS-groepen voor sleuteluitwisseling

kritiek Harvest Now, Decrypt Later deploy/nginx.conf:6
Gevonden
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; X25519MLKEM768 wordt vastgelegd als quantumveilig; X25519 en ECDH-256 (P-256) niet.
Zakelijke context
Klantgegevens moeten 25 jaar geheim blijven (opgegeven in quantsiv.yml van de repository)
Waarom deze rang
Protects data that must stay confidential for 25 years. (Beschermt gegevens die 25 jaar vertrouwelijk moeten blijven.)
Het risico
Een client die de hybride groep niet kan gebruiken, valt terug op een klassieke groep. Verkeer over die verbindingen kan vandaag worden opgenomen en later worden ontsleuteld.
Overstappen naar
Migrate key establishment to ML-KEM (FIPS 203), deployed as a hybrid with X25519 (e.g. X25519MLKEM768 in TLS) during the transition. (Migreer de sleuteluitwisseling naar ML-KEM (FIPS 203), tijdens de overgang ingezet als hybride met X25519 (bijv. X25519MLKEM768 in TLS).)

Quantsiv AI: migratieanalyse

Analyse voltooid In je CI, met het model dat je kiest Gesimuleerde uitvoer

De server biedt de hybride groep al als eerste aan, dus het werk zit in de clients die die groep niet kunnen gebruiken. Een configuratiebestand krijgt aanwijzingen, geen codewijziging.

Aanbevolen migratie
  1. Zoek in de TLS-logs van de server welke clients nog X25519 of P-256 afspreken.
  2. Werk die clients bij of faseer ze uit, te beginnen met de clients die klantgegevens versturen.
  3. Verwijder de klassieke groepen uit ssl_ecdh_curve zodra het verkeer dat toelaat.
  4. Peil het endpoint opnieuw om te bevestigen dat de hybride groep wordt afgesproken.
Prioriteit
Kritiek, 25 jaar vertrouwelijk
Betrokken
deploy/nginx.conf en de clients van api.example.com
Standaarden
FIPS 203 (ML-KEM-768) in de hybride groep X25519MLKEM768
Compatibiliteit
Clients die geen van de overgebleven groepen ondersteunen, kunnen geen verbinding meer maken zodra de terugvalopties zijn verwijderd.

Validatie

Controles op de aanwijzingen
  • target is a post-quantum alternative: X25519MLKEM768
  • no other classical algorithm named

Echte uitvoer van de controles van Quantsiv voor de aanwijzingen hierboven. Wijzigingen aan configuratie, sleutels, certificaten en tokenformaten krijgen aanwijzingen, nooit een diff.

Bij elke volgende build

Een latere pull request voegt een RSA-sleutel toe. De wijzigingscontrole vergelijkt die met de laatste build van de hoofdbranch:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

Bevinding: JWT signing

hoog Vervalsing van handtekeningen src/auth/session_tokens.py:6
Zakelijke context
Handtekeningen moeten 10 jaar vertrouwd blijven (opgegeven in quantsiv.yml van de repository)
Waarom deze rang
Signatures must stay trusted for 10 years; deadline 31 Dec 2031. (Handtekeningen moeten 10 jaar vertrouwd blijven; deadline 31 dec 2031.)
Het risico
Een quantumcomputer zou de ondertekeningssleutel uit de publieke sleutel kunnen afleiden en tokens uitgeven die elke dienst accepteert. Er hoeft eerst niets te worden opgenomen: de publieke sleutel is per definitie openbaar.
Overstappen naar
Migrate to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). Prioritise long-lived signing keys: code/firmware signing, CA and token-issuer keys. (Stap over op ML-DSA (FIPS 204) of SLH-DSA (FIPS 205). Geef voorrang aan sleutels die lang meegaan: ondertekening van code en firmware, sleutels van CA's en tokenuitgevers.)
Regelgeving
EO 14412 (22 Jun 2026): post-quantum digital signatures on high-value assets and high-impact systems by 31 Dec 2031. NIST IR 8547 (ipd): disallowed after 2035. (EO 14412 (22 jun 2026): post-quantum digitale handtekeningen op high-value assets en systemen met hoge impact uiterlijk 31 dec 2031. NIST IR 8547 (eerste openbare concept): na 2035 niet meer toegestaan.)

Quantsiv AI: migratieanalyse

Analyse voltooid In je CI, met het model dat je kiest Gesimuleerde uitvoer

Deze sessietokens worden ondertekend met RS256, en andere diensten verifiëren ze. Een ander algoritme verandert het tokenformaat, dus de agent geeft aanwijzingen in plaats van een codewijziging.

Aanbevolen migratie
  1. Maak een lijst van elke dienst en bibliotheek die deze tokens verifieert.
  2. Controleer of elk daarvan ML-DSA-handtekeningen (FIPS 204) kan verifiëren voordat de uitgever overstapt.
  3. Geef tokens uit met een nieuwe ML-DSA-sleutel, en accepteer beide algoritmen tijdens de overstap.
  4. Faseer de RS256-sleutel uit zodra geen enkele verificateur er nog van afhangt.
Prioriteit
Hoog, deadline voor handtekeningen 31 dec 2031
Betrokken
src/auth/session_tokens.py en elke dienst die de tokens verifieert
Standaarden
FIPS 204 (ML-DSA)
Compatibiliteit
Tokens worden groter: een ML-DSA-65-handtekening is 3.309 bytes (FIPS 204), meer dan tien keer een RS256-handtekening met een 2048-bit-sleutel. Controleer de groottelimieten van cookies en headers.

Validatie

Controles op de aanwijzingen
  • target is a post-quantum alternative: ML-DSA-65
  • no other classical algorithm named

Echte uitvoer van de controles van Quantsiv voor de aanwijzingen hierboven. Wijzigingen aan configuratie, sleutels, certificaten en tokenformaten krijgen aanwijzingen, nooit een diff.

Bij elke volgende build

Een latere pull request voegt een RSA-sleutel toe. De wijzigingscontrole vergelijkt die met de laatste build van de hoofdbranch:

gate
fail
new asset
RSA-2048 at src/partner_upload.py:6, high

* Echte resultaten van Quantsiv op een demorepository

Neem contact op

Ontvang updates over deadlines voor de post-quantummigratie, standaarden en releases van Quantsiv.