Üha rohkem räägitakse ja muretsetakse selle pärast, mis juhtub siis, kui luuakse kvantarvuti, millel on võimekus murda levinud krüptoalgoritme, sest nendel põhineb suur osa digiturvalisusest.
Enimlevinud krüptoprotokoll on TLS, mille abil turvatakse suurt osa võrgusuhtlusest. Kui veebilehitseja aadressiribal on aadressi ees „https://“, siis kasutab ühendus TLSi. TLSi eesmärk on tagada andmevahetuse konfidentsiaalsus ja terviklus ning ühenduse ühe- või mõlemapoolne autentsus.
TLSi puhul on kõige pakilisem mure andmete konfidentsiaalsus, kuna see peab säilima ka pärast ühenduse lõppu. Üks oht on seega, et pahatahtlik osapool salvestab krüptitud liikluse, mida ta hetkel veel lahti murda ei saa, ja murrab selle hiljem, nt võimsa kvantarvuti soetamisel. Selle ohu maandamiseks on TLS 1.3 jaoks välja töötatud võtme hübriidkehtestus, mis sobitab kokku nii klassikalise kui ka kvantkindla algoritmi, et tagada tulevikusalastatus ka postkvant-ründaja vastu. See on vajalik, sest TLS 1.3 algne võtmekehtestus põhineb (EC)DHE meetodil, mis ei ole kvantkindel.
Üldisemalt tähendab võtme hübriidkehtestuse puhul sõna „hübriid“ mitme erineva algoritmi kombineerimist võtme kehtestamisel. Hübriidkehtestuse eesmärk on tagada võtmekehtestuse kindlus ka juhul, kui üks algoritmidest osutub kas praktikas või lausa teoorias ebaturvaliseks. Seega ei tähenda hübriidkehtestus seda, et kasutusel peab olema täpselt kaks algoritmi, millest üks on klassikaline ja teine kvantkindel, aga TLS 1.3 puhul see hetkel nii on.
Siinkohal võib tekkida ka terminoloogiline segadus. Nimelt räägitakse TLSi puhul tihti hübriidkrüptimisest, kus andmed krüptitakse salajase võtmega, aga salajane võti vahetatakse/luuakse osapoolte vahel mõne asümmeetrilise meetodiga. Siinkohal tähendab „hübriid“ sümmeetrilise ja asümmeetrilise lähenemise kombineerimist. See lähenemine TLS 1.3 puhul säilib, sest hinnanguliselt on TLS 1.3 kasutatavad sümmeetrilised krüptimisalgoritmid (AES, ChaCha20) 256-bitiste võtmete puhul kvantkindlad. Kokkuvõteks tähendab võtme hübriidkehtestuse kasutamine TLS 1.3 puhul seda, et salajane võti levitatakse võtmekehtestusskeemiga, mis kasutab mitut algoritmi.
Teiseks võib tekkida küsimus, miks kasutada hübriidkehtestusel nii klassikalist kui ka postkvant-algoritmi, selle asemel et (EC)DHE lihtsalt kvantkindla skeemiga asendada. Postkvant-skeemid peavad olema ründekindlad nii klassikaliste kui ka kvantarvutite vastu, aga olemasolevad postkvant-algoritmid on veel värsked, mistõttu pole neid nii põhjalikult uuritud kui klassikalisi skeeme. Seega on hetkel TLS 1.3 hübriidkehtestuse puhul kasutusel ka klassikaline algoritm, maandamaks riski, et kvantkindlas skeemis avastatakse viga enne võimsa kvantarvuti olemasolu, mis võimaldaks ka klassikalistel arvutitel skeemi murda.
Võtmekapselduse mehhanism (Key Encapsulation Mechanism, KEM) on krüptograafiline vahend, mis võimaldab avaliku võtme põhjal luua salajase väärtuse ja selle „krüptogrammi“, mille saab avada vaid vastava salajase võtme valdaja. Peamine erinevus võtme kapseldamisel ja harilikul avaliku võtmega krüptimisel on see, et kapseldatud salajane võti luuakse kapseldamise käigus: võtmekapselduse algoritm ei võta sisendiks eelgenereeritud salaväärtust/sõnumit, vaid ainult avaliku võtme. See võimaldab lihtsustada skeemi ennast ja selle turvaanalüüsi ning kohati ka selle tõhusust.
TLS 1.3 võtme hübriidkehtestuse mudel on kujutatud joonisel 1.
Kujundite ja lühendite seletus:
-
KeyGen() viitab võtmegenereerimise algoritmile. Täpne algoritm sõltub skeemist, aga käsitletud skeemide puhul on väljundiks alati salajane võti ja sellele vastav avalik võti pk. Joonisel kasutatud värvid võimaldavad järge pidada, millise algoritmi, vastavuse ja/või eesmärgiga on tegu.
-
Sümbol ilma sk või pk märketa viitab salajasele väärtusele, millel pole avalikku vastet. Teisisõnu viitab sümbol saladusele, mida osapooled omavahel turvaliselt jagama peavad. Sisuliselt on tegu jagatud salajase võtmega.
-
X25519 viitab TLS 1.3 Diffie-Hellmani (DH) võtmekehtestuse algoritmile Curve25519 elliptkõveral. Põhimõte jääb samaks ka muud elliptkõverat kasutades, nt SecP256r1 või SecP384r1.
-
X25519.Derive(sk, pk) viitab DH võtmekehtestuse kombineerimisfaasile, kus jagatud saladus saavutatakse kahe osapoole avaliku ja salajase võtme kombineerimisel. Algoritmi väljund on jagatud saladus.
-
-
KEM viitab postkvant-võtmekapselduse mehhanismile, mille täpne algoritm võib varieeruda, aga mis hetkel on ML-KEM.
-
KEM.Encaps(pk) viitab KEMi kapseldusalgoritmile, mis genereerib saladuse ja kapseldab selle sisendiks antud avaliku võtmega. Algoritmi väljund on nii jagatud saladus kui ka selle kapseldus. Lihtsuse mõttes kutsume kapseldust ennast edaspidi kapsliks.
Teisisõnu kujutab genereeritud saladust sisaldavat ümbrist, mille saab avada vaid osapool, kes teab avalikule võtmele pk vastavat salajast võtit.
-
KEM.Decaps(sk, ) viitab KEMi lahtikapselduse algoritmile, mis avab kapseldusfaasis loodud saladuse kapsli. Algoritmi väljund on jagatud saladus.
Sisendiks antud salajane võti sk peab olema vastavuses kapseldamiseks kasutatud avaliku võtmega.
-
-
Comb(·) viitab salajaste sisendväärtuste põhjal uue salaväärtuse tuletamiseks kasutatud algoritmile. Hetkel on selleks kasutusel HKDF-Extract.
Enne TLSi käepigistuse algatamist genereerib klient seansi jaoks kolm ühekordset võtmepaari. Ühekordsete võtmepaaride kasutamine on tulevikusalastatuse jaoks kriitiline, sest vastasel juhul saab võtme lekkimise/murdmise tagajärjel ka varasema talletatud suhtluse lahti krüptida.
Võtmepaarid (pk, sk) ja (pk, sk) on mõeldud hübriidkehtestuseks, aga klient genereerib ka tagavarapaari (pk, sk) juhuks, kui server hübriidkehtestust ei toeta. Kui server hübriidkehtestust ei toeta, siis toimub harilik võtmekehtestus võtmepaariga (pk, sk). Kui aga toetab, siis neid võtmeid rohkem ei kasutata ja seega pole ka joonisel ühtegi tehet nendega kujutatud.
Edaspidi oletame, et server toetab hübriidkehtestust.
Pärast võtmete genereerimist algatab klient TLS 1.3 käepigistuse, saates serverile ClientHello sõnumi, mis hõlmab supported_groups laiendis rühma „X25519MLKEM768“ ja key_share laiendis kahte võtmepaari:
- tavaline X25519 avalik osak pk, mida hübriidkehtestusel ei kasutata,
- „hübriidosak“, mis koosneb kokkuliidetud avalikest osakutest pk ja pk.
Kui server kliendi ClientHello sõnumi kätte saab, siis genereerib ta samuti ühe X25519 võtmepaari (pk, sk), mis on vajalik X25519 võtmekehtestuse jaoks. Järgmisena kasutab server oma salajast (sk) ja kliendi avalikku (pk) X25519 osakut, et tuletada klassikaliselt jagatud saladus . Osaku genereerib server, kasutades KEMi kapseldusalgoritmi kliendi avaliku postkvant-võtmega pk.
Kuna serveril on nüüd mõlemat viisi jagatud saladused olemas, kombineerib ta need salajaseks „hübriidvõtmeks“ , millega edaspidi sümmeetriliselt andmeid krüptida. Kuigi võtmel endal ei ole hübriidsusega mingit pistmist, kutsume seda hetkel nii, rõhutamaks, et võti jääb salajaseks ka siis, kui kas X25519 või ML-KEM peaks osutuma ebaturvaliseks.
Server vastab kliendile, saates tavapärase ServerHello sõnumi, kus key_share laiendis on hübriidosak, mis koosneb kokkuliidetud X25519 avalikust osakust pk ja kvantkindlalt kapseldatud saladusest .
Klient saab nüüd omakorda kasutada serveri avalikku (pk) ja oma enda salajast (sk) X25519 osakut, et tuletada klassikaliselt jagatud saladus , mis on sama kui serveril. Siis kasutab klient oma postkvant-salajast võtit sk, et avada kapsel ja saada kätte kvantkindlalt jagatud osak . Seejärel kombineerib klient mõlemad jagatud saladused hübriidvõtmeks , mida saavad nüüd nii klient kui ka server andmete krüptimiseks ja dekrüptimiseks kasutada.
Ülejäänud TLS 1.3 protokoll jätkub muutusteta.
Ülalkirjeldatud protokoll X25519MLKEM768 „hübriidrühmaga“ on üks kolmest, mis on RFC eelnõu draft-ietf-tls-ecdhe-mlkem poolt standardimisel.
Täpsemalt pakub eelnõu välja kolm hübriidrühma:
- SecP256r1MLKEM768 (4587, 0x11EB)
- X25519MLKEM768 (4588, 0x11EC)
- SecP384r1MLKEM1024 (4589, 0x11ED)
mis kombineerivad ECDH võtmekehtestuse standarditud rühmas ML-KEMiga. ML-KEM-768 saavutab 192-bitise turvataseme ja ML-KEM-1024 256-bitise turvataseme. Sulgudes olev arv viitab rühma identifikaatorile TLSi supported_groups laiendis. RFC eelnõu võtme hübriidkehtestuse kohta üldisemalt TLS 1.3-s on draft-ietf-tls-hybrid-design.
Joonistel 2 ja 3 on oluline võtmekehtestuse info Wiresharki kuvatõmmistel annoteeritud.
ML-KEM-768 avaliku võtme suurus on 1184 baiti ja kapsli suurus 1088 baiti. SecP256r1MLKEM768 ja SecP384r1MLKEM1024 rühmade puhul on ECDH ja MLKEM osakud vastupidises järjekorras key_share laiendis.
Täpsema info leiab RFC eelnõust.
Samal teemal:
- Kvantkindel krüptograafia, Zone'i blogi, 29. aprillil 2025
Loomise kuupäev: 29.04.2025
