· Michal Pietrus · 4 min read
QKD vs. PQC | dwa paradygmaty, dwa modele zagrożeń, jeden problem
Zabezpieczenia hardware (QKD), zabezpieczenia software (PQC), a może jak zwykle, to zależy?
Dwa odrębne paradygmaty zabezpieczeń w komunikacji cyfrowej, ale powstałe w kontekście jednego zagrożenia, wprost związanego z kryptograficznie efektywnym komputerem kwantowym (CRQC).
QKD i PQC to dwa różne techniczne podejścia do zabezpieczenia komunikacji (a zatem i Twoich danych) w sytuacji, kiedy obecne zabezpieczenia kryptograficzne przestają działać w erze komputerów kwantowych. Jedno opiera się na połączeniu kryptografii i dedykowanej infrastruktury sprzętowej, a drugie wyłącznie na nowych algorytmach kryptograficznych.
QKD vs. PQC to już etap implementacji, ale zanim to nastąpi, jest kilka innych problemów do rozwiązania.
Ostatecznie to Ty decydujesz, czy (albo kiedy) podjąć ten temat i choć nie sposób ocenić, kiedy odpowiedni komputer kwantowy zostanie zbudowany, z pewnością również świat nie stoi w miejscu [1][2]. Nie sposób również pominąć w tej dyskusji znaczenia komputera kwantowego w kontekście geoekonomicznym.
Choć większe agencje rządowe, jak BSI, ANSSI czy NSA (nie wchodzę w teorie spiskowe), już jakiś czas temu wyraziły swoją opinię na ten temat[1][2][3], tematu tego jeszcze nie poruszałem, zatem dziś wchodzi na stół. Opinia powyższych jest jednoznaczna, tj. traktuje o praktycznej (pragmatycznej w znakomitej większości przypadków) przewadze PQC nad QKD.
Z każdej z w/w opinii wyłowisz pewien kontekst “dlaczego nie idź tą drogą”, natomiast, jak to zwykle bywa, odpowiedzi jest kilka.
QKD, czyli Quantum Key Distribution, to koncept oparty o istnienie bramek (nadawca->odbiorca, p2p), gdzie nadawca, Grażyna, korzystając z własności mechaniki kwantowej, jest dostawcą entropii, a odbiorca, Janusz, jej biorcą (tutaj poprzez np. protokół [BB84], lub wystandaryzowany w ETSI Quantum Key Distribution (QKD); Common Criteria Protection Profile - Pair of Prepare and Measure Quantum Key Distribution Modules). Idąc dalej, warto by wejść w mechanikę kwantową celem zrozumienia na jakich zasadach funkcjonują QKD, albo co jest tym źródłem entropii, ale celowo to pomijam.
No dobra, ale po co ta entropia?
Zwróc uwagę czym jest wsad do algorytmów symetrycznych jak AES czy ChaCha20. W szczególności, że w tych algorytmach poza szyfrowaną wiadomością, do szyfrowania potrzebujesz klucza szyfrującego i dokładnie taką rolę pełni infrastruktura QKD, tj. dostawcy losowego klucza, wynikającego wprost z własności mechaniki kwantowej. Zatem jeśli Grażyna i Janusz posiadają bramki QKD, wykorzystują je do przesyłania tego klucza. Jeśli natomiast pojawia Andrzej i próbuje podsłuchać komunikację, Grażyna i Janusz, są w stanie wykryć że są podsłuchiwani, co znowu wynika z własności mechaniki kwantowej.
W praktyce w infrastrukturze QKD masz dwa kanały komunikacji: kwantowy (niezaufany) i klasyczny (uwierzytelniony). Ten pierwszy jest w pewnym sensie kanałem przesyłania entropii, natomiast żeby zweryfikować poprawność odczytu, strony komunikują się dodatkowo kanałem klasycznym.
W QKD potrzebujesz zatem dodatkową infrastrukturę (hardware + software), masz większy narzut komunikacyjny (synchronizacja stanu), potrzebujesz kanał klasyczny zabezpieczony (uwierzytelniony) klasyczną kryptografią, a bramki są de facto SPOF (single point of failure).
W zamian otrzymujesz protokół kwantowej dystrybucji klucza. Tylko tyle. Zatem szyfrowanie (i deszyfrowanie) danych, bo na nich Ci przecież zależy, zostaje po staremu. Nic się nie zmienia.
QKD vs. PQC
Nasuwa mi się skojarzenie perimeter model (castle-and-moat network model) (tu jako QKD) vs. paradygmat Zero Trust Architecture (ZTA) [NIST SP 800-207] (jako PQC). Przejmujesz kontrolę nad bramką (trust anchor) dostępową QKD i dostajesz pełną kontrolę. Z kolei w przypadku PQC (i analogią ZTA) masz zupełnie inną granularność. Zupełnie inny model zagrożeń.. W PQC nie ma ani punktów pośrednich, ani żadnej dodatkowej infrastruktury. Jest tylko nadawca i odbiorca.
Ale… jeśli przyjmiesz, że dzisiejsze routery z IPsec wzbogacasz jakimś wariantem wyposażonym w komponent QKD, otrzymujesz na poziomie szkieletowym możliwość transmisji informacji, które wrzucasz tam jako plaintext, a przesyłasz jaki ciphertext, bo za szyfrowanie odpowiada infrastruktura i sprzęt. Dostawcy sprzętu oczywiście idą w tą stronę, a ich całkiem niezły przegląd znajdziesz tutaj. Nie sposób również nie wspomnieć o wielkości potencjalnego rynku. McKinsey & Company w świeżo upieczonej analizie wskazuje, że rozwiązania oparte o QKD do 2035 roku mogą tworzyć rynek o wartości nawet 7 mld USD.
Wkładając dane w “szyfrującą rurę”, ogólnie rzecz biorąc, w pewnych sytuacjach jest prościej, np. wiele źródeł danych, z których każde z osobna trzeba by wyposażyć w bezpieczny kanał komunikacyjny (np. TLS). Co możesz zrobić zamiast tego to puścić wszystko via IPsec+QKD.
Praktyczne zastosowanie takiego podejścia to wewnątrz korporacyjna komunikacja, gdzie przesyłasz dane z A do B i gdzie bezpieczny kanał komunikacji wynika z QKD. Jeden z banków, konkretnie H**C dokładnie dlatego wszedł w QKD. Zatem delegując szyfrowanie (oraz uwierzytelnianie) do zupełnie innej warstwy w modelu OSI, zakładając QKD, dostajesz pewne benefity, ale jak to zwykle bywa, nie za darmo.
Inny przykład: wiele źródeł danych, ale geograficznie rozproszonych, zatem trudno je spiąć fizycznie w jeden (albo nawet trzy) kanał(y) komunikacyjny(e). Taniej pójść w PQC.
Jeszcze inny przykład: Ty i Twoja cyfrowa komunikacja z Twoim bankiem. QKD czy PQC?
Zupełnie osobną kwestią jest też dojrzałość dzisiejszych systemów opartych na QKD, ale z czasem i to się zmieni.
Oceń sam praktyczną aplikowalność QKD w Twoim ekosystemie.
Na koniec warto wspomnieć, że w Polsce WOC, czy Creotech Quantum działają w tym temacie. Niezależnie po której stronie stoisz w kontekście QKD, zbieranie doświadczenia w technologiach potencjalnie istotnych możliwe jest tylko wówczas, gdy rzeczywiście robisz to sam.
