| | | | | Mottó:
A kyber crystal [...] was found on scattered planets
across the galaxy. They were used by the
Jedi and the Sith in the construction of their lightsabers.
/starwars.fandom.com/ | | 2022. július 5. | | | | | Post-Quantum Cryptography: új Ibtv. (2013. évi L. törvény) és NIST PQC | | | | | | 2022. júliusának első hetén két fontos esemény is történt a "quantum-safe" kriptográfia témakörében.
Az Ibtv. (2013. évi L. törvény) 2022. július 1-én hatályosodott változatában megjelent egy új fogalom, a "poszt-kvantumtitkosítás", amelyet a "két végpont közötti kommunikáció" során kell majd - a végrehajtási rendeletek, műszaki specifikációk megszületése után - alkalmaznia mindenkinek, aki "kormányzati célú" vagy "közszolgáltatást nyújtó" szervezet vagy "hitelintézetekről és a pénzügyi vállalkozásokról szóló törvény szerinti bank". Bár, a jogszabály jelen változata csak a kommunikációs csatornák bizalmasságát emeli ki, az ehhez hasonló szabályozások ennél jóval szélesebb kört szoktak együtt emlegetni: elég, ha csak a GDPR-ra gondolunk, ahol a továbbítás mellett a tárolt személyes adatok titkosítását és integritását is védeni kell. Vélhetőleg a jelen Ibtv. is pontosításra fog még kerülni, hogy összhangban legyen más jogszabályokkal.
A NIST PQC az elmúlt 6 év matematikai vizsgálatai alapján 2022. július 5-én bejelentette a kvantumszámítógépeknek is ellenálló algoritmusok versenyének győzteseit, amik "quantum-safe" módon tudnak adatokat pl. rejtjelezni, azaz jók lesznek a "poszt-kvantumtitkosítás" biztosítására.
Mit is jelent ez?
Úgy tűnik, hogy most már minden feltétel adott ahhoz, hogy az új algoritmusok be tudjanak kerülni a fejlesztőkörnyezetekbe (.NET, Java stb.), standalone crypto library-kbe (OpenSSL, BouncyCastle stb.), Apache web server config-okba, hogy aztán a rájuk épülő alkalmazások kódjai is hozzáigazításra kerülhessenek. Bizonyos funkcióknál (pl. HTTPS kommunikációnál, SSL/TLS handshake lefutásánál) elegendő lehet a web server-t konfigurálni, más funkcióknál viszont – üzenetszintű műveleteknél (pl. rejtjelezett SAML vagy OpenID Connect JWT-nél) – jobban bele kell nyúlni a kódokba, sőt, akár adatbázisok szintjén is igényelhet módosítást a technológiaváltás (pl. rejtjelezett módon tárolt adatok esetében). Éppen ezért fontos, hogy az üzemeltetők, fejlesztők a matematikai háttérből fakadó szempontokat is figyelembe vegyék konfigurálás, kódolás során és ne történjen meg ismét a 2010-es, és azóta tanpéldává vált Sony PlayStation 3 esethez hasonló hiba: akkor, a matematikai háttértudás hiánya miatt egy "integer" beégetésre került az elliptikus görbés (ECDSA) digitális aláírás kódjában, pedig valójában ott egy véletlenszámnak kellett volna szerepelnie. És így törték fel konzolgép teljes védelmi rendszerét...
A kvantumszámítógép kapcsán, ha felmerül a kriptográfia, akkor általában két fogalmat szoktak emlegetni: "quantum cryptography" és "post-quantum cryptography". A "quantum cryptography" esetében a hálózaton átküldött jelnél a védelmet az jelenti, hogy a kvantumfizikai törvények miatt a cut-and-paste jellegű megfigyelés érzékelhető a túloldalon, vagyis a vevő észreveszi, ha az átküldött adathoz (pl. AES kulcs) más is hozzáférhetett. (A hagyományos kommunikációs csatornáknál, ha valaki megfigyeli a hálózati kommunikációt, akkor copy-and-paste jelleggel, azaz másolással tudja kimenteni a fontos információkat, nem pedig kivágással, mint a cut-and-paste esetében.) A "post-quantum cryptography" esetében a hálózaton átküldött jelnél a védelmet az jelenti, hogy valamilyen matematikai értelemben vett nehéz problémán alapuló algoritmus révén van védve az átküldött adat (pl. AES kulcs). Mindkét megoldás révén végre lehet hajtani a kulcsegyeztetést "quantum-safe" módon, de nem mindegy, hogy a hálózati infrastruktúrát kell-e fejleszteni vagy csak a szoftvereket. És az sem mindegy, hogy mindez mikorra valósulhat meg...
Egyelőre azt még nem tudjuk, hogy 5 vagy 50 év múlva lesz kvantumszámítógép és hogy az milyen működési elvű lesz (pl. 3 Kelvin fokon fog-e üzemelni vagy szobahőmérsékleten), a lényeg, hogy akkor lesz veszélyes a jelenleg használt kriptográfiára, ha a Shor algoritmust és Grover algoritmust futtatni tudja.
A hitelesség és bizalmasság kapcsán eltérnek a teendők a kvantumszámítógépre való felkészülés során. A hitelesség folytonosságának biztosításához bőven elegendő, ha a kvantumszámítógép megjelenése előtti pillanatban bevédjük az adatainkat egy újabb (archív) időbélyeggel, digitális aláírással. A bizalmasság folytonosságának biztosítása viszont nem megoldott: ha valaki már a mai napon lementette az RSA révén kódolt AES kulcsos SSL/TLS handshake kommunikációt és az utána átküldött adatokat, akkor azt be tudja majd küldeni egy kvantumszámítógépnek, hogy fejtse meg. Szóval, ha van valaki, aki lementegeti jelenleg is a hálózati kommunikációkat, akkor az később létrehozhat akár egy "quantum-based" WikiLeaks portált is...
Annak érdekében, hogy legalább a mai naptól kezdve biztosított legyen a hálózati kommunikációnk bizalmassága, a "quantum-safe" rejtjelezés, vagy - ahogy a 2022-07-01-én hatályosodott Ibtv. (2013. évi L. törvény) fogalmaz - a "poszt-kvantumtitkosítás" támogatott kell, hogy legyen a kormányzati, közműves és banki megoldásoknál. Természetesen, itt még létrejönnek majd végrehajtási rendeletek, műszaki specifikációk, illetve várhatóan a jogszabályi szöveg, és esetleg a kötelezettek köre is módosulni fog, de az mindenképpen fontos fejlemény, hogy a "quantum-safe" kriptográfia megjelent egy ország jogrendjében.
De melyek számítanak "quantum-safe" algoritmusnak? És ezek közül melyek azok, amelyek a hitelesség vagy a bizalmasság biztosítására megfelelőek? Nos, pontosan ezt vizsgálta a NIST PQC, azaz egy algoritmus-kiválasztási verseny, amelyre 6 évvel ezelőtt 69 pályázó nevezett, de a győzteseket csak most, 2022-07-05-én hirdették ki.
A NIST PQC eredményhirdetése egy fontos mérföldkő, de még van teendő bőven, mielőtt megjelenhetne pl. egy Apache web server config-jában valamelyik algoritmus. A versenyre beküldött PoC (Proof-of-Concept) kódok alapján kőbe vésik, szabványba foglalják a biztonságosnak vélt paramétereket, majd ezek bekerülnek a nagy fejlesztőkörnyezetekbe (.NET, Java stb.) és standalone crypto library-kbe (OpenSSL, BouncyCastle stb.). Ha ez megvan, akkor lehet a ráépülő rendszereket is "utánhúzni". Ezek lehetnek netbanki megoldások, authentikációs szerverek vagy más rendszerek, de ahhoz, hogy egy új algoritmus teljes életciklusa támogatott lehessen a CA (hitelesítés szolgáltató) szoftvereket is be kell frissíteni, hogy a létrehozott kulcspár nyilvános felére tanúsítványt lehessen kibocsátani. És ez még csak a SW modulok köre, de a HW moduloknál ugyanígy el kell végezni a befrissítéseket! Márpedig egy HSM vagy chipkártya esetében általában 8-10 éves életciklussal számolnak, de ezt a technológiaváltást most valószínűleg mégis hamar meglépik a gyártók. Azt viszont tudni kell, hogy még ha az alaposan kitesztelt firmware SW el is készül, az ilyen terméktípusokra meg kell kérni az auditokat is, hogy meglegyen a CC, FIPS terméktanúsítvány (ez pedig jellemzően nem csak 1-2 hónapos folyamat), azaz a teljes átállás előkészületeihez szükség lehet akár 2 évre is.
Térjünk vissza egy pillanatra a 2022-07-01-én hatályosodott Ibtv. (2013. évi L. törvény) "poszt-kvantumtitkosítás" fogalmához, aminél az az elvárás, hogy a "két végpont közötti kommunikáció" védendő "quantum-safe" algoritmusokkal! Ezen megfogalmazás alapján az egyik legjelentősebb ilyen protokoll az SSL/TLS, amelynek v1.3 változata óta az RSA-alapú kulcsrejtjelezés (keyEncipherment) helyett már csak a DH-alapú (Diffie-Hellman) kulcsegyeztetés (keyAgreement) támogatott a "Perfect Forward Secrecy" jegyében. A NIST PQC versenyen azonban kulcsrejtjelező (Key-Encapsulation Mechanism) algoritmusokat választottak ki, ezért kérdéses volt, hogy ez miképp tud összhangba kerülni a SSL/TLS v1.3 követelményeivel. Szerencsére a kutatók már találtak erre is megoldást: az egyik ilyen a KEMTLS névre hallgat.
A KEMTLS tud mindent, amit az elődei is: SSL/TLS server és mutual/client authentication módban is tud működni. A leegyszerűsített folyamatábrán jól látszik, hogy igazából kétszer hajtja végre a kulcsrejtjelezést, oda-vissza irányban elküldésre kerül egy-egy "shared secret" darabka a másik fél számára rejtjelezve, majd ezek "összefűzésével" előáll mindkét oldalon a közös, egyeztetett szimmetrikus (pl. AES) kulcs. Bár, az SSL/TLS handshake lépések száma így ismét megnő (pedig a v1.3 verziónál az egyszerűsödés is egy előny volt), de legalább a "quantum-safe" DH-szerű (Diffie-Hellman) kulcsegyeztetés (keyAgreement) mégis támogatható lesz.
A hagyományos kriptográfiai algoritmusoknál is bizonyos területeken, mint a beágyazott rendszereknél, az IoT világában fontos szempont volt az átküldendő adatmennyiség, azaz pl. a digitálisan aláírt üzenetek mérete. Az órajelciklusok korlátozott száma, a relatíve kis buszsebesség és a rövid reakcióidős követelmények együtt azt igényelték, hogy az RSA helyett inkább az elliptikus görbés ECDSA algoritmust használják. Bár, a NIST PQC gondolt a méretproblémákra, ezért került be a Falcon nevű "quantum-safe" algoritmus a győztesek közé ("Falcon will also be standardized by NIST since there may be use cases for which CRYSTALS-Dilithium signatures are too large."), de azért azt lehet látni, hogy ez még így is nagyobb méretű digitális aláírást használ, mint az RSA, ami helyett már régebben is az ECDSA-ra váltottak. Szóval, itt még az IoT világ szakértőitől szükséges lesz majd egy visszajelzés, hogy jó lehet-e ez?! "Örülünk, Vincent?"
A (kulcs)rejtjelezés és digitális aláírás általában egyszerű módon kerül alkalmazásra a legtöbb esetben - még egy SSL/TLS handshake során is -, de vannak olyan területek, ahol összetettebb módon kell őket használni, és ezek a módok algoritmus-specifikusak. Ha tehát valahol vak aláírás vagy homomorf rejtjelezés alkalmazása is szükséges, ott külön feladatot jelent annak megvizsgálása, hogy a győztes "quantum-safe" algoritmusok közül melyik lehet jó.
A vak aláírásról ritkábban lehet hallani, mostanában talán a jegybanki kriptovaluták kapcsán merül fel a fogalom, mint pl. a David Chaum-féle, a Swiss National Bank számára készített modelljénél, ahol privacy szempontok miatt használják. A jó hír az, hogy a "lattice-based" algoritmusokkal a vak aláírás "quantum-safe" módon is támogatható lehet (a "hash-based" algoritmusokról viszont nincs ilyen információ).
A homomorf rejtjelezésről gyakrabban lehet hallani, hiszen jelenleg is alkalmazzák olyan rendszereknél, ahol érzékeny adatokon kell végezni műveleteket, vagyis ahol csak a végeredmény lehet nyilvános: ilyen pl. az egészségügyi adatokkal végzett statisztikai számítások, vagy elektronikusan lebonyolított választásoknál a titkos szavazatok összeszámlálása, illetve mostanában a Mesterséges Intelligencia témakörében az algoritmus-tanítás is ilyen, ahol nem csak az adatok lehetnek érzékenyek és védendők, hanem maga a már betanított algoritmus is. A jó hír az, hogy a "lattice-based" algoritmusokkal a homomorf rejtjelezés "quantum-safe" módon is támogatható lehet (a "code-based" algoritmusokról viszont nincs ilyen információ).
Ha minden szempontot meg is vizsgáltunk már, hogy a technológiaváltást meglépjük a saját rendszereinknél, azért érdemes egy pillanatra megállnunk: vajon kellően biztonságosak-e az alapok, amelyekre építkezünk? Jók-e a kódok a crypto library-kben? A hagyományos kriptográfiai algoritmusoknál az RSA-ra elégséges volt az idő, a fontos ökölszabályok mind bekerültek a crypto library-kbe. Az új, "quantum-safe" algoritmusok kódjainál viszont vajon mennyi időre lesz szükség a kiforrottsághoz? Bizakodó lennék, ha azt láttam volna az elmúlt pár évben, hogy az RSA-ról ECDSA-ra váltást probléma nélkül meg tudják lépni a "nagyok", ehhez képest viszont olyan szintű hibák jöttek elő, amelyek már a 20 évvel ezelőtti, hazai auditok során lefuttatott negatív teszt eseteknél is kibuktak volna. A Microsoft .NET fejlesztőkörnyezetben az elliptikus görbék paraméterei nem kerültek ellenőrzésre még 2 évvel ezelőtt (így bárki tudott az éles Microsoft CA alá tartozó pl. code signer tanúsítványt és kulcspárt létrehozni), az Oracle Java fejlesztőkörnyezet pedig a NULL értékű elliptikus görbés digitális aláírásokat fogadta el automatikusan jónak még 2 hónappal ezelőtt! Joggal merül fel tehát a kérdés: ha az RSA-ról ECDSA-ra váltás ennyire nem ment még a nagyoknak sem, akkor a hagyományosról "quantum-safe" algoritmusokra való váltás mikor lesz valóban bevállalható a .NET és Java fejlesztőkörnyezeteket használva? Valószínűleg sokkal fontosabbá válik a tesztelés (akár nemzeti szinten is), ahol lehet - pl. OpenSSL - ott a lényeges részeket forráskód szintjén is elemezgetni kell, ahol nem lehet ott "black/grey box" teszteket kell kidolgozni, hogy legalább a triviális, NULL értékű digitális aláírás hiba ne jöjjön elő ismét!
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
