Criptografie post-quantum pentru IT manageri: ce faci anul acesta

Nimeni nu știe cu certitudine când va exista un calculator cuantic capabil să spargă RSA sau criptografia pe curbe eliptice (ECC). Pentru un IT manager, însă, data exactă contează mai puțin decât pare. Algoritmii folosiți azi pentru schimbul de chei — în TLS, VPN, SSH — sunt vulnerabili în principiu la un astfel de calculator, iar migrarea unei organizații întregi durează ani.

Riscul concret de azi are un nume: „harvest now, decrypt later”. Un adversar poate intercepta și stoca acum trafic criptat, urmând să-l decripteze când tehnologia o va permite. Pentru o comandă online, irelevant. Pentru dosare medicale, contracte pe 20 de ani, proprietate intelectuală sau date de stat, foarte relevant. Întrebarea corectă nu este „când vin calculatoarele cuantice”, ci „cât timp trebuie să rămână secrete datele pe care le transmit azi”.

În august 2024, NIST a publicat primele trei standarde finale de criptografie post-quantum (PQC). Nu trebuie să înțelegi matematica din spate, dar merită să recunoști numele, pentru că le vei vedea în fișele tehnice ale furnizorilor:

În martie 2025, NIST a selectat și HQC ca mecanism de rezervă pentru stabilirea cheilor, bazat pe o matematică diferită de ML-KEM — o plasă de siguranță în cazul în care ar apărea o slăbiciune neașteptată.

Două documente dau ritmul. NIST IR 8547, publicat ca draft în noiembrie 2024, propune ca algoritmii vulnerabili cuantic bazați pe RSA și ECC să fie depreciați până în 2030 și interziși după 2035 pentru sistemele federale americane. Fiind draft, termenele pot încă suferi modificări, dar direcția e clară, iar furnizorii globali se aliniază.

În Europa, foaia de parcurs coordonată publicată în iunie 2025 de Grupul de cooperare NIS stabilește trei repere pentru statele membre:

• Până la finalul lui 2026: începerea tranziției — inventar, planuri naționale, comunicare cu industria.
• Până la finalul lui 2030: migrarea cazurilor de utilizare cu risc ridicat și a infrastructurii critice.
• Până în 2035: migrarea a cât mai mult posibil din restul sistemelor.

Pentru o organizație din sfera NIS2, criptografia face parte explicit din măsurile tehnice de gestionare a riscului — vezi Art. 21 NIS2: controalele tehnice. Un plan PQC documentat, chiar și la început, arată că riscul a fost identificat și gestionat.

Nu poți migra ce nu știi că folosești. Un inventar criptografic — numit uneori CBOM (Cryptography Bill of Materials), prin analogie cu SBOM — răspunde la întrebarea: unde, în ce sistem și cu ce algoritm protejăm date sau identități? Surse de pornire:

• Certificatele TLS interne și externe: algoritm de cheie, lungime, emitent, dată de expirare.
• Configurațiile TLS și SSH de pe servere, load balancere, reverse proxy-uri și VPN-uri.
• Bibliotecile criptografice și versiunile lor (OpenSSL, BoringSSL, Java, .NET) din inventarul de software.
• Infrastructura de chei publice (PKI), HSM-urile și semnarea de cod.
• Aplicațiile proprii care apelează direct funcții criptografice sau stochează date criptate pe termen lung.
• Serviciile furnizorilor (SaaS, cloud, dispozitive de rețea) unde criptografia nu e sub controlul tău.

Un criteriu simplu, folosit frecvent în discuțiile despre PQC: dacă timpul cât datele trebuie să rămână confidențiale plus timpul necesar migrării depășește momentul în care un calculator cuantic relevant ar putea exista, ai deja o problemă. Practic, ordinea devine:

1. Confidențialitate pe termen lung în tranzit: legături între sedii, VPN-uri, backup-uri trimise în afara organizației, arhive medicale sau juridice.
2. Rădăcini de încredere cu viață lungă: CA-uri interne, firmware și semnarea de cod pentru dispozitive care stau în teren 10–15 ani.
3. Trafic web obișnuit: TLS către utilizatori, unde migrarea vine în mare parte prin actualizări de software.
4. Date cu valoare scurtă: sesiuni, tokenuri temporare — ultimele pe listă.

Pune rezultatul într-un registru simplu, cu un responsabil pentru fiecare sistem și o dată țintă, și tratează-l ca pe orice alt risc din registrul de riscuri: revizuit periodic, raportat conducerii, legat de bugetul anual. Multe migrări vor coincide cu înlocuiri de echipamente sau reînnoiri de licențe deja planificate — avantajul unei liste făcute din timp este că nu cumperi azi un dispozitiv care nu va putea fi actualizat mâine.

Vestea bună: prima migrare e deja în curs, fără efortul tău. Browserele majore folosesc un schimb de chei hibrid care combină X25519 (clasic) cu ML-KEM, sub numele de grup X25519MLKEM768. „Hibrid” înseamnă că atacatorul trebuie să spargă ambii algoritmi — dacă ML-KEM s-ar dovedi slab, rămâi cel puțin la nivelul de securitate de azi.

Pe partea de server, OpenSSL 3.5 (aprilie 2025) include ML-KEM, ML-DSA și SLH-DSA și suportă acest grup hibrid. Pași practici pentru anul acesta:

• Identifică serverele, reverse proxy-urile și load balancerele care rulează versiuni vechi de biblioteci criptografice și planifică actualizarea lor.
• Activează grupul hibrid acolo unde software-ul îl suportă, după test cu clienții tăi reali (unele dispozitive intermediare vechi pot avea probleme cu mesajele de handshake mai mari).
• Elimină versiunile vechi de protocol (TLS 1.0/1.1) și suitele slabe — PQC nu salvează o configurație deja depășită.

Cea mai mare parte a criptografiei tale vine de la furnizori. Include în achizițiile și reînnoirile de contract întrebări precum:

1. Aveți o foaie de parcurs PQC publicată, cu termene?
2. Ce algoritmi standardizați de NIST (ML-KEM, ML-DSA, SLH-DSA) suportați azi și din ce versiune?
3. Suportați schimbul de chei hibrid în TLS și VPN?
4. Algoritmii se pot schimba prin configurare sau necesită hardware nou?
5. Cum vor fi actualizate certificatele și cheile de semnare ale produsului?

Ultimele două întrebări țin de crypto-agility: capacitatea de a schimba algoritmii fără a reconstrui sistemul. Este lecția cea mai durabilă a tranziției PQC — și pentru aplicațiile proprii: algoritmii nu se scriu fix în cod, ci se citesc din configurare.