Rilevamento: RSA-OAEP encryption
critico
Harvest Now, Decrypt Later
src/billing_export.py:10
- Contesto aziendale
- I dati dei clienti devono restare segreti per 25 anni (dichiarato nel file
quantsiv.ymldel repository) - Perché questa priorità
- Protects data that must stay confidential for 25 years. (Protegge dati che devono restare riservati per 25 anni.)
- Il rischio
- La crittografia a chiave pubblica basata su RSA è vulnerabile a computer quantistici sufficientemente potenti. I dati intercettati oggi potrebbero diventare decifrabili in futuro, se i meccanismi di cifratura o di scambio di chiavi usati vengono compromessi.
- Verso cosa migrare
- Replace RSA encryption/key transport with ML-KEM (FIPS 203) plus an AEAD. (Sostituisci la cifratura e il trasporto di chiavi RSA con ML-KEM (FIPS 203) più un AEAD.)
- Riferimenti normativi
- 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 giu 2026): scambio di chiavi post-quantistico sugli high-value assets e sui sistemi ad alto impatto entro il 31 dic 2030. NIST IR 8547 (bozza pubblica iniziale): RSA, ECC e DH con sicurezza a 112 bit deprecati dopo il 2030, tutti gli algoritmi a chiave pubblica vulnerabili agli attacchi quantistici non consentiti dopo il 2035.)
Quantsiv AI: analisi di migrazione
Analisi completata Nella tua CI, con il modello che scegli Output simulato
L'implementazione attuale usa RSA-OAEP per proteggere i dati dei clienti esportati, che devono restare riservati per 25 anni.
Non è una sostituzione diretta. Qui RSA-OAEP cifra la chiave AES che protegge ogni esportazione. ML-KEM non cifra una chiave scelta: stabilisce un segreto condiviso, da cui si ricava la chiave dei dati. AES-256-GCM continua a cifrare i dati.
Migrazione consigliata
- Esamina l'attuale cifratura RSA-OAEP e il flusso di gestione delle chiavi.
- Valuta ML-KEM (FIPS 203) per lo scambio di chiavi post-quantistico, anche con approcci ibridi dove opportuno.
- Usa uno schema di cifratura simmetrica autenticata come AES-GCM per cifrare i dati.
- Individua le dipendenze, le integrazioni, i certificati e i requisiti di compatibilità coinvolti.
- Stabilisci la priorità della migrazione in base alla durata di riservatezza e all'esposizione crittografica.
- Convalida l'implementazione aggiornata ed esegui i controlli di regressione.
- Priorità
- Critica, riservatezza per 25 anni
- Coinvolti
src/billing_export.pye il codice di decifratura del partner, fuori da questo repository- Standard
- FIPS 203 (ML-KEM-768) per lo scambio di chiavi; AES-256-GCM per i dati
- Compatibilità
- Il formato di esportazione cambia, e il partner ha bisogno di una coppia di chiavi ML-KEM. Le esportazioni già inviate restano come erano.
Modifica proposta
@@ -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}Validazione
Controlli sulla modifica proposta
- target is a post-quantum alternative: ML-KEM-768
- rescanned: RSA is gone
- nothing quantum-vulnerable added
- policy passes
Output reale dei controlli di Quantsiv per la modifica qui sopra. Anche i tuoi test vengono eseguiti se imposti un comando di controllo; questo esempio non ne imposta. Una persona esamina la modifica, e non viene fatto alcun commit.
A ogni build successiva
Una pull request successiva aggiunge una chiave RSA. Il controllo delle modifiche la confronta con l'ultima build del branch principale:
- gate
- fail
- new asset
RSA-2048atsrc/partner_upload.py:6, high