Blog članak

Migracija na postkvantnu kriptografiju: praktični vodič

Praktični vodič za migraciju s klasične na postkvantnu kriptografiju: NIST-ovi standardizirani algoritmi, hibridna TLS izmjena ključeva u produkciji, konfiguracija OpenSSL-a s oqs-providerom, rok Bijele kuće do 2030. i fazna strategija migracije utemeljena na kripto-agilnosti.

Vrijeme ističe. Bijela kuća u lipnju je 2026. objavila memorandum M-26-15 kojim nalaže svim američkim saveznim agencijama migraciju uspostave ključeva za sustave visokog utjecaja na postkvantnu kriptografiju (PQC) do 31. prosinca 2030., a digitalnih potpisa do 2031. Sličan pritisak osjeća i privatni sektor — zbog NSA-inih rokova CNSA 2.0, NIST-ova cilja povlačenja kvantno ranjivih algoritama do 2035. te sasvim stvarne prijetnje napada tipa »prikupi sada, dešifriraj kasnije«.

Ovaj vodič obuhvaća što PQC znači u praksi, koji su ključni standardi, kako već danas omogućiti hibridni TLS i kako izgraditi strategiju migracije koja vas neće ostaviti u panici 2030. godine.

Tri NIST-ova standarda koje morate poznavati

NIST je 13. kolovoza 2024. objavio prva tri finalizirana PQC standarda nakon osmogodišnjeg međunarodnog natječaja u kojem je sudjelovalo 82 kandidatska algoritma iz 25 zemalja. Evo što je objavljeno:

StandardAlgoritamNamjenaPreimenovano iz
FIPS 203ML-KEMMehanizam kapsulacije ključeva (šifriranje)CRYSTALS-Kyber
FIPS 204ML-DSAPrimarni digitalni potpisCRYSTALS-Dilithium
FIPS 205SLH-DSARezervni digitalni potpisSphincs+

ML-KEM je najhitniji standard za većinu organizacija zbog prijetnje »prikupi sada, dešifriraj kasnije« — šifrirani podaci snimljeni danas mogu se pohraniti i dešifrirati godinama kasnije kad se pojavi kriptografski relevantno kvantno računalo (CRQC). Uspostavu ključeva treba nadograditi prije potpisa.

ML-DSA je primarni algoritam potpisa za certifikate, potpisivanje koda i potpisivanje dokumenata. Temelji se na rešetkastoj kriptografiji i učinkovit je, ali proizvodi znatno veće potpise od ECDSA-e.

SLH-DSA je konzervativna rezerva. Oslanja se na hash-based kriptografiju (drugu matematičku osnovu od ML-DSA-inih rešetki), stoga ako jedan pukne, drugi ostaje siguran. Cijena su ogromne veličine potpisa — i do 50 KB na najvišoj razini sigurnosti.

Stvarnost veličina ključeva

Današnji TLS handshake s ECDSA + X25519 iznosi otprilike 4–6 KB na žici. Isti handshake s ML-KEM-768 + ML-DSA-65 može doseći 20–50 KB. To ima stvarne posljedice:

  • MTU fragmentacija — veće poruke handshakea mogu se fragmentirati preko više TCP segmenata, što uzrokuje probleme s jumbo okvirima na VPN-ovima i međuspremicima
  • Ograničenja CDN-a i balansera opterećenja — neki hardverski akceleratori imaju fiksne veličine međuspremnika za TLS izmjenu ključeva
  • Nabreklost lanca certifikata — lanac certifikata s ML-DSA potpisima i među-CA certifikatima može premašiti 20 KB, za razliku od današnjih ~4 KB

Odabir prave razine sigurnosti važan je. ML-KEM-768 (ekvivalent AES-192) dovoljan je za većinu slučajeva upotrebe; ML-KEM-1024 postoji, ali dolazi s razmjerno većim ključevima i sporijim performansama.

Hibridni TLS: uvođenje PQC-a bez rušenja interneta

Najpragmatičniji pristup migraciji na PQC danas je hibridna izmjena ključeva — kombinacija klasičnog algoritma (X25519 ECDH) s postkvantnim algoritmom (ML-KEM) u jednom TLS handshakeu. Veza je sigurna sve dok barem jedan od ta dva algoritma ostane neprobojan.

To nije teorija. Cloudflare je omogućio hibridnu X25519 + Kyber izmjenu ključeva za sva web-mjesta i API-je na svojoj mreži u listopadu 2022. Google Chrome uključuje X25519Kyber768 kao zadanu postavku od Chromea 124 (travanj 2024.).

Omogućavanje hibridne izmjene ključeva s OpenSSL 3.x i oqs-providerom

Ako kontrolirate svoju TLS-terminacijsku infrastrukturu, PQC možete omogućiti već danas putem OpenSSL 3.x arhitekture provajdera i oqs-providera projekta Open Quantum Safe (OQS).

# Instalacija liboqs i oqs-providera
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/oqs ..
make -j$(nproc) && make install

# Izgradnja oqs-providera
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -DCMAKE_PREFIX_PATH=/opt/oqs ..
make -j$(nproc) && make install

Kad je provajder izgrađen, konfigurirajte OpenSSL da ga učita:

# /etc/ssl/openssl.cnf — dodajte ili izmijenite odjeljak providers
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqs_sect

[default_sect]
activate = 1

[oqs_sect]
activate = 1
module = /opt/oqs/lib/ossl-modules/oqsprovider.so

Sada možete testirati hibridni TLS navođenjem nazivne grupe X25519MLKEM768 (standardizirane u nacrtima IETF TLS WG). Pokrenite OpenSSL s_server s hibridnom izmjenom ključeva:

# Poslužitelj
openssl s_server -cert server.crt -key server.key \
  -groups X25519MLKEM768 -www -port 4433

# Klijent (provjera dogovorene grupe)
openssl s_client -connect localhost:4433 -groups X25519MLKEM768

Ako veza uspije i dogovorena grupa je X25519MLKEM768, imate funkcionalan hibridni TLS handshake. Klijent i poslužitelj sada su otporni na napade tipa prikupi-sada-dešifriraj-kasnije.

Preglednici i CDN-ovi

Ako koristite CDN ili obrnuti proxy, provjerite podržava li već hibridni TLS. Cloudflare ga podržava od 2022. Za prilagođene izvore konfigurirajte svoj upstream TLS stog (Nginx, HAProxy ili Go/Rust servis) da pregovara X25519MLKEM768 kao podržanu grupu.

Nginx s OpenSSL 3.x + oqs-providerom:

# /etc/nginx/nginx.conf — http blok
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
ssl_protocols TLSv1.3;

Ovo govori Nginxu da preferira hibridnu PQ grupu, s povratkom na klasične grupe ako je klijent ne podržava.

Fazna strategija migracije

Nadograđujući se na četverofazni model memoranduma M-26-15 Bijele kuće i smjernice NIST-ova NCCoE-a o kripto-agilnosti, donosimo praktičan plan za svaku organizaciju.

Faza 1: Otkrivanje i popis kriptografije (sada — prvi kvartal 2027.)

Ne možete migrirati ono što ne možete pronaći. Izradite popis svakog sustava, biblioteke i protokola koji obavlja kriptografske operacije:

  • TLS certifikati i konfiguracije izmjene ključeva na svakom poslužitelju, balanseru opterećenja i API-ju proxy
  • Certifikati za potpisivanje koda i CI/CD tijekovi potpisivanja
  • Kriptografski profili VPN-a i IPsec-a
  • Konfiguracije šifriranja baza podataka u mirovanju (TDE, EFS, LUKS)
  • Kriptografske mogućnosti hardverskih sigurnosnih modula (HSM)
  • Lanac internih CA certifikata i potpisivanje CRL-ova

Nekoliko komercijalnih alata i alata otvorenog koda može automatizirati ovaj posao, no čak i ručni popis na temelju mrežnog skeniranja odlična je polazna točka. Ključno pitanje za svaki sustav: Može li ova komponenta podržati hibridnu ili isključivo PQC kriptografiju ili je mora zamijeniti?

Faza 2: Prioritet uspostave ključeva (2027.–2028.)

Krenite od sustava najizloženijih napadima »prikupi sada, dešifriraj kasnije«:

  1. Javna TLS terminacija — web-poslužitelji, CDN izvori, API-ji proxy. Omogućite X25519MLKEM768 kao preferiranu grupu za izmjenu ključeva.
  2. Interni TLS — service mesh, međuservisna komunikacija, replikacija baza podataka. Hibridnu izmjenu ključeva prvo testirajte u neprodukcijskom okruženju — stariji hardverski akceleratori i međuspremnici mogu odbaciti nepoznate nazivne grupe.
  3. VPN koncentratori — provjerite rukovanje MTU-om može li podnijeti veći hibridni handshake. PQC izmjena ključeva dodaje ~2 KB korisnom teretu IKE ili TLS handshakea.

Za svaki sustav testiranje treba potvrditi da hibridne veze uspijevaju, da je latencija prihvatljiva (obično 5–15 % povećanja vremena handshakea) i da nema zatajenja pregovaranja sesije s postojećim klijentima.

Faza 3: Migracija potpisa (2028.–2031.)

Potpisi su manje hitni od izmjene ključeva (za potpisane podatke ne postoji ekvivalent »prikupi sada«), ali zamjena traje duže jer se lanci certifikata moraju ponovno izdati:

  1. Interni CA — generirajte nove ML-DSA ili hibridne (ML-DSA + ECDSA) unakrsno potpisane ključeve certifikacijskog tijela
  2. Potpisivanje koda — ažurirajte CI/CD tijekove za upotrebu PQC ključeva za potpisivanje. ML-DSA potpisi na binarnim datotekama znatno povećavaju veličinu potpisane isporuke — za većinu internog potpisivanja koristite ML-DSA-44 ili ML-DSA-65
  3. TLS certifikati — uvodite hibridne certifikate (dvolančani certifikati s klasičnim i PQ potpisima) tijekom obnove. Time se izbjegava lomljenje naslijeđenih klijenata, a nove se veze osposobljavaju za budućnost
  4. Potpisivanje dokumenata i e-pošte — S/MIME i OpenPGP podržavaju PQC algoritme u nedavnim ažuriranjima (OpenPGP v6 uključuje ML-KEM i ML-DSA)

Faza 4: Kripto-agilnost kao trajna praksa

Posljednja i najvažnija faza jest izgradnja kripto-agilnosti — mogućnosti zamjene kriptografskih primitiva bez većih arhitektonskih promjena.

NIST-ov NCCoE definira kripto-agilnost kroz:

  • Apstrahirana kriptografska sučelja — nikad ne ugrađujte identifikatore algoritama u kod. Koristite uzorke provajdera (poput OpenSSL 3.x provajdera) koji omogućuju zamjenu algoritama bez dodirivanja aplikacije
  • Automatizirani popis — kontinuirano otkrivanje kriptografske upotrebe, a ne jednokratna revizija
  • Postupna degradacija — preferirajte hibridne implementacije koje rade i s klasičnim i s PQC klijentima tijekom prijelaznih razdoblja
  • Testna infrastruktura — redovito provjeravajte interoperabilnost s najnovijim standardiziranim algoritmima i nazivnim grupama

Organizacije koje će uspjeti s PQC migracijom nisu one koje izvedu jednu veliku eksplozivnu nadogradnju 2030. godine. One su koje kripto-agilnost učine normalnim inženjerskim postupkom već danas.

Uobičajene zamke kojih treba izbjegavati

Čekanje na »konačne« standarde. NIST je već objavio konačne standarde. ML-KEM i ML-DSA neće se mijenjati. Uvodite hibridno rješenje već sada.

Zanemarivanje utjecaja na performanse u većem mjerilu. TLS handshake od 20–50 KB u redu je za nekoliko veza. Za CDN rub koji obrađuje 100 000 handshakeova u sekundi, trošak propusnosti i procesora znatan je. Profilirajte prije uvođenja u produkciju.

Pretpostavka da svi klijenti podržavaju hibridne grupe. Stariji IoT uređaji, ugrađeni sustavi i starije OS kriptografske biblioteke možda neće pregovarati nepoznate TLS nazivne grupe. Održavajte povratni put.

Previda hardvera. HSM-ovi, mrežni akceleratori i pametne kartice možda ne podržavaju PQC. Provjerite planove svojih dobavljača — CISA u siječnju 2026. navodi HSM-ove s PQC podrškom kao »široko dostupne«, no nisu svi dobavljači isporučili ažuriranja firmvera.

Zaključak

Migracija na postkvantnu kriptografiju nije problem budućnosti. NIST je objavio standarde 2024. Chrome i Cloudflare već imaju hibridni TLS u produkciji. Bijela kuća postavila je rok za uspostavu ključeva do 2030. Glavna teškoća nisu algoritmi — već popis, testiranje i organizacijsko planiranje potrebni da se dotakne svaki sustav koji obavlja kriptografiju.

Krenite s hibridnom izmjenom ključeva na svojim javnim TLS krajnjim točkama. Izradite kriptografski popis. Postavite oqs-provider u testnim okruženjima. Cilj nije savršenstvo — već uklanjanje jedinstvene točke zatajenja na kojoj bi kvantni protivnik mogao retroaktivno dešifrirati vaš šifrirani promet. Svaki sustav koji migrirate prije 2030. jedan je hitan slučaj manje u 2029.

Povezana područja

Ova su područja rada usklađena s temom članka i daju čišći prijelaz od edukativnog sadržaja do konkretne implementacije.

Nastavite čitati

Prvo po zajedničkim kategorijama, a zatim po najjačem preklapanju u tagovima.