Inhaltsverzeichnis
2.3 Strategia & Tecnologia
Pianificazione strategica e decisioni tecnologiche per la crittografia post-quantum.
Fasi di migrazione
Fase 1 Fase 2 Fase 3 Fase 4
------ ------ ------ ------
Preparazione Hybrid Validazione Solo PQ
Oggi --------------------------------------------------------> Futuro
Installare Nuovi cert Validare Solo PQ
libreria ibridi entrambe (opzionale)
Fase 1: Preparazione
Attivita:
- Valutare pacchetto NuGet
- Distribuire OpenSSL 3.6 in ambiente test
- Inventario: Quali sistemi usano crittografia?
- Valutazione rischio: Quali dati hanno esigenze di protezione a lungo termine?
Risultato: Libreria installata, in modalita Classic (nessun cambiamento di comportamento)
Fase 2: Attivare Hybrid
Attivita:
- Attivare CryptoMode.Hybrid in progetto pilota
- Creare nuovi certificati (automaticamente ibridi)
- Test di compatibilita con client legacy
- Rollout graduale su altri sistemi
Risultato: I nuovi certificati sono protetti PQ, quelli vecchi continuano a funzionare
Fase 3: Validazione
Attivita:
- Attivare validazione firma PQ
- Impostare monitoring per errori di validazione
- Sostituire gradualmente certificati legacy
- Documentazione e formazione
Risultato: Validazione ibrida completa attiva
Fase 4: Solo PQ (opzionale)
Prerequisito: Tutti i sistemi PQ-ready
Attivita:
- Attivare CryptoMode.PostQuantum
- Rimuovere supporto legacy
- Piena sicurezza PQ
Nota: Per la maggior parte delle organizzazioni, la Fase 3 e sufficiente.
Priorita
| Priorita | Sistemi | Motivazione |
|---|---|---|
| 1 (immediata) | Archivi a lungo termine, contratti | Massima esigenza di protezione |
| 2 (breve termine) | PKI, infrastruttura certificati | Base per altri sistemi |
| 3 (medio termine) | API, servizi web | Comunicazione in corso |
| 4 (successiva) | Sistemi interni | Minor rischio di intercettazione |
Decisioni tecnologiche
Perche OpenSSL 3.6?
| Criterio | OpenSSL 3.6 | Alternative |
|---|---|---|
| Validazione FIPS | Validabile FIPS 140-3 | Bouncy Castle: Nessun FIPS |
| Algoritmi PQ | ML-DSA, ML-KEM nativi | liboqs: Sperimentale |
| Manutenzione | OpenSSL Foundation, a lungo termine | Team piccoli, incerto |
| Performance | Ottimizzato hardware (AES-NI, AVX) | Spesso solo software |
Perche AES-256-GCM?
| Criterio | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| Certificazione FIPS | FIPS 197 (standard) | Non certificato FIPS |
| Supporto hardware | AES-NI su tutte le CPU | Nessuna accelerazione hardware |
| Sicurezza PQ | 128-bit post-quantum | 128-bit post-quantum |
Perche Hybrid invece di Solo PQ?
| Aspetto | Hybrid (raccomandato) | Solo PQ |
|---|---|---|
| Rischio | Minimo - due livelli di sicurezza | Maggiore - solo algoritmi PQ |
| Compatibilita | Sistemi legacy funzionano | Rompe con legacy |
| Raccomandazione NIST | Raccomandato per transizione | Solo dopo migrazione |
Riepilogo per audit
| Decisione | Motivazione | Riferimento |
|---|---|---|
| OpenSSL 3.6 | Validabile FIPS, standard industriale | OpenSSL Foundation |
| AES-256-GCM | Certificato FIPS 197, accelerato hardware | NIST FIPS 197 |
| ML-DSA/ML-KEM | Standardizzato NIST (FIPS 203/204) | NIST PQC Project |
| Modalita Hybrid | Raccomandato NIST/BSI, difensivo | NIST SP 800-227 |
Fattori di successo
- Sponsorship esecutiva: Supporto della direzione
- Avvio anticipato: Non aspettare i computer quantistici
- Rollout graduale: Minimizzazione rischio attraverso fasi
- Monitoring: Rilevare e correggere errori di validazione
- Documentazione: Per audit e trasferimento conoscenze
Approfondimenti
- Migrazione (tecnica) - Passi dettagliati
- Compliance - Requisiti normativi
- Amministratore - Implementazione operativa
Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional
Zuletzt geändert: il 30/01/2026 alle 09:03
