Bevinding: RSA-OAEP encryption
src/billing_export.py:10
- Zakelijke context
- Klantgegevens moeten 25 jaar geheim blijven (opgegeven in
quantsiv.ymlvan 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
- Beoordeel de huidige RSA-OAEP-versleuteling en het sleutelbeheer.
- Evalueer ML-KEM (FIPS 203) voor post-quantum sleuteluitwisseling, met hybride aanpakken waar dat past.
- Gebruik een geauthenticeerd symmetrisch versleutelingsschema zoals AES-GCM om de gegevens zelf te versleutelen.
- Breng de betrokken afhankelijkheden, integraties, certificaten en compatibiliteitseisen in kaart.
- Geef de migratie prioriteit op basis van de vertrouwelijkheidsduur en de cryptografische blootstelling.
- Valideer de bijgewerkte implementatie en voer regressiecontroles uit.
- Prioriteit
- Kritiek, 25 jaar vertrouwelijk
- Betrokken
src/billing_export.pyen 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
@@ -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-2048atsrc/partner_upload.py:6, high
