BSI TR-02102 in postkvantna kriptografija: kaj zahteva nemški naročnik in kaj lahko dokažete

Stanje: 3. novembra 2026. Preverjeno ob BSI TR-02102-1, različica 2026-01, in nemški nacionalni smernici z dne 12. oktobra 2026. Spremembe so navedene na koncu strani.

• TR-02102-1 nemškega urada BSI je tehnična smernica, ne zakon. Namenjena je predvsem razvijalcem, ki od leta 2026 načrtujejo nove kriptografske sisteme. V Nemčiji velja za merilo stanja tehnike, zato jo nemški naročniki vse pogosteje pišejo v pogodbe.
• Izmenjava ključev: RSA, Diffie-Hellman in ECDH sami priporoča le še do konca leta 2031, pri zelo visoki stopnji zaščite do konca leta 2030. Pozneje samo hibridno, skupaj s kvantno odpornim algoritmom, kot je ML-KEM.
• Podpisi: klasične algoritme za podpis same predvidoma priporoča do konca leta 2035.
• Roka 2030 in 2035 za primere uporabe z visokim in srednjim tveganjem sta iz Načrta EU za postkvantno kriptografijo, ki je namenjen tudi Sloveniji. Nemčija ga je 12. oktobra 2026 prevzela kot nujno priporočilo, s prvim kriptografskim inventarjem do konca leta 2026.
• Za dobavitelja postane vse to obveznost šele s pogodbo. Nemški ali evropski zakon, ki bi določal postkvantni rok za vaše podjetje, ne obstaja.

Nemški naročnik pošlje aneks k pogodbi. V njem je nov člen: »Der Auftragnehmer gewährleistet die Konformität der gelieferten Software mit BSI TR-02102-1 in der jeweils gültigen Fassung.« Odgovor je treba poslati v dveh tednih. Prodaja vpraša razvoj, ali smo »skladni«. V razvoju vedo, da aplikacija uporablja TLS, ki ga zagotavlja Windows, in RSA-certifikat, ki so ga pred leti dobili od naročnika. Kaj od tega je »skladno«, nihče ne zna povedati.

Tak člen ni samovolja. Nemški naročnik ima svoje razloge:

• Če spada med pomembne ali posebej pomembne subjekte po nemškem zakonu o BSI, morajo njegovi ukrepi »upoštevati stanje tehnike«, tudi pri uporabi kriptografije (§ 30 BSIG).
• Nacionalna smernica BMDS, BMI in BSI z dne 12. oktobra 2026 mu priporoča, naj zahteve glede postkvantne kriptografije in kriptografske prilagodljivosti po TR-02102 privzeto upošteva pri nabavi. Od dobaviteljev naj zahteva tudi CBOM (smernica, razdelek 4.6).
• Do konca leta 2030 mora sam preklopiti primere uporabe z visokim tveganjem. Brez vas tega ne more.

Naročnik torej ne sprašuje zaradi birokracije. Tveganje prenaša tja, kjer je tehnična odločitev. Problem nastane, ko ga prenese z besedo, ki ničesar ne določa. »Skladnost s TR-02102« se ne da preveriti, dokler ni jasno, za katere povezave, podatke in podpise gre.

Smernica ima štiri dele, trenutno vse v različici 2026-01:

BSI priporočila pregleda vsako leto. V prvem delu jih izrecno omeji na obdobje do konca leta 2032, ker so daljše napovedi negotove (razdelek 1.2).

Skladnosti ne dosežete z izbiro algoritmov. Smernica sama opozarja, da sistem ni samodejno varen samo zato, ker uporablja le priporočene algoritme (razdelek 1). Če je treba skladnost izdelka s smernico dokazati, zahteva certifikate Common Criteria ali primerljive postopke BSI, na primer odobritev (razdelek 1.2). Majhno razvojno podjetje tega dokazila praviloma nima. Zato ne more podpisati, da ga ima.

Kako postane zavezujoča. Ravni je dobro ločiti:

V Sloveniji Urad Vlade RS za informacijsko varnost (URSIV) priporoča, da zavezanci po Zakonu o informacijski varnosti (ZInfV-1) in druge organizacije začnejo prehod na postkvantno kriptografijo. Tudi to je priporočilo, ne rok.

Kaj je »visoko tveganje«. Po Načrtu EU je primer uporabe visoko tvegan, če bi razkritje podatkov tudi po desetih ali več letih še povzročilo resno škodo. Nemška smernica doda dva dejavnika: kako ranljivi so uporabljeni algoritmi in koliko časa traja prehod (razdelek 4.5). Razvrstitev je naročnikova. Vi mu lahko poveste, katere vaše povezave in podatki sodijo v njegov primer uporabe, in koliko časa potrebujete za spremembo.

Od kod 2031. Rok 2031 je samo v smernici BSI, ki ga utemeljuje s skupnim priporočilom BSI in evropskih partnerskih organov iz leta 2024. Načrt EU ga ne pozna; uporablja stopnje tveganja ter leti 2030 in 2035.

2032 in 2036. Nekateri pregledi navajajo leto 2032. To je ista meja kot 2031, šteta od prvega leta, ko je klasični dogovor o ključu priporočen le še hibridno: smernica ga po letu 2031 priporoča samo še v kombinaciji s kvantno odpornim postopkom (razdelek 2.3). Enako je 2036 prvo leto po roku za podpise ob koncu leta 2035; tam gre za napoved, ne še za pravilo.

Slovenija. Načrt EU od držav članic pričakuje začetne nacionalne načrte do konca leta 2026. Javno objavljenega slovenskega časovnega načrta do 3. novembra 2026 nismo našli. URSIV je objavil gradivo o prehodu (april 2026) in slovenski prevod pogostih vprašanj o Načrtu EU (maj 2026).

Kaj nemški načrt pomeni za slovenskega dobavitelja, podrobneje opisuje »Nemčija konkretizira svoj postkvantni načrt«.

Načelo. Vzporedno tečeta dve izmenjavi ključev, klasična in kvantno odporna. Iz obeh se izpelje en skupni ključ, ki ostane varen, dokler je varen vsaj eden od algoritmov (TR-02102-1, razdelek 2.2).

Zakaj ne samo novi algoritem. Kvantno odpornim algoritmom še ne zaupamo enako kot preizkušenim, ker so manj raziskani, na primer glede stranskih kanalov in varnosti implementacije (razdelek 2.2). Smernica jih zato zaenkrat priporoča izključno hibridno.

Kateri algoritmi. Za kvantno odporni del TR-02102-1 navaja (razdelek 2.4):

• ML-KEM-768 in ML-KEM-1024 po FIPS 203, ki ju uporablja večina knjižnic in protokolov;
• FrodoKEM-976 in FrodoKEM-1344, bolj konzervativno izbiro, ki je pri ISO v standardizaciji;
• Classic McEliece z navedenimi nabori parametrov. Po napredku kriptoanalize leta 2026 BSI odsvetuje njegovo uporabo v novem razvoju;
• HQC namerava BSI dodati po objavi standarda.

Kako se skrivnosti združijo. Za lastne protokole in formate datotek smernica priporoča dva kombinatorja (razdelek 2.2, tabela 2.1):

• CatKDF po ETSI TS 103 744, s KMAC ali HKDF;
• KeyCombine po NIST SP 800-227, pri katerem funkcijo H izvede priporočena KDF ali KMAC.

Protokoli, kot je TLS 1.3, kombinacijo urejajo sami (opomba 2.5).

Kje že deluje.

• TLS 1.3: RFC 10024 je od avgusta 2026 predlagani standard. Skupini SecP256r1MLKEM768 in SecP384r1MLKEM1024 bo BSI priporočil v naslednji različici TR-02102-2. Po navedbi BSI ju je skladno s smernico mogoče uporabljati že zdaj, poleg njiju pa tudi X25519MLKEM768.
• SSH: RFC 10042 (informativni, avgust 2026) opisuje mlkem768x25519-sha256 in dve različici s krivuljami NIST.
• IPsec: RFC 9370 omogoča več izmenjav ključev v IKEv2. ML-KEM za IKEv2 je oktobra 2026 še osnutek IETF.

Cena. Ključ ML-KEM-768 je dolg 1184 bajtov, šifropis 1088 bajtov (FIPS 203). Vzpostavitev povezave se poveča za dobra dva kilobajta. Prvo sporočilo odjemalca ne gre več v en sam paket. Starejši požarni zidovi in naprave, ki pregledujejo promet, se lahko pri tem zataknejo. To preverite v testnem okolju, ne pri naročniku.

Zakaj ML-KEM ni preprosta zamenjava za RSA, je opisano v »ML-KEM ni čarobna zamenjava za RSA.«

Pri podpisih napad »shrani zdaj, dešifriraj pozneje« ne deluje. Klasični podpis ostane zaupanja vreden, dokler ne obstaja kriptografsko relevanten kvantni računalnik (TR-02102-1, razdelek 2.1). Zato je rok poznejši. Za dobavitelja pa sta pomembni dve stvari:

• Posodobitve. Izdelki, ki bodo v uporabi po letu 2030, naj bodo nadgradljivi na kvantno odporne algoritme. Tudi sam mehanizem posodobitev naj uporablja postkvantne podpise. Smernica to »nujno priporoča« (razdelek 5.3), podobno tudi Načrt EU. Če vaša programska oprema posodobitve podpisuje z RSA in podpisa ni mogoče zamenjati, bo naročnik to vprašal prej kot leta 2035.
• Certifikati. Infrastruktura javnih ključev potrebuje leta, preden vsi preverjevalci razumejo nove formate (razdelek 5.3).

Kaj smernica priporoča za podpise (razdelek 5.3.4):

• Kvantno odporen podpis praviloma le skupaj s klasičnim: oba podpisa sta zapisana zaporedno in veljata samo skupaj.
• ML-DSA-65 in ML-DSA-87 po FIPS 204, v različici »hedged«.
• Podpisi na osnovi zgoščevalnih funkcij se smejo uporabljati tudi sami: SLH-DSA po FIPS 205 ter XMSS in LMS. Zadnja dva imata stanje, zato sta priporočena le tam, kjer je števec zanesljivo voden, na primer pri podpisovanju posodobitev programske in strojne opreme.

Kombinirani formati certifikatov (Composite ML-DSA, Composite ML-KEM) so oktobra 2026 še osnutki IETF. Zakaj zamenjava certifikata ne zadostuje, pojasnjuje »Postkvantna PKI«.

Smernica je napisana za nove sisteme. Vaša aplikacija je verjetno stara deset let in teče pri naročniku, ki je ne sme ustaviti. Kje se kriptografija dejansko zgodi, je zato prvo vprašanje:

• Povezave (TLS, VPN, SSH). Pogosto jih ne vzpostavi vaša koda, ampak platforma: Windows, spletni strežnik, obratni posredniški strežnik, gonilnik ODBC. Naročniku povejte, katera komponenta to je in katera različica. Ali zna hibridno izmenjavo ključev, je odvisno od nje in od nasprotne strani, ne od vas.
• Aplikacije .NET. Težave so trdo kodirani algoritmi in dolžine ključev: RSA z 2048 biti v kodi, lastni formati podpisov, identifikatorji algoritmov v bazi. Kjer aplikacija sama izdaja certifikate, podpisuje sporočila CMS ali dokumente XML ali šifrira datoteke, je treba spremeniti klic. Cele aplikacije ni treba pisati na novo.
• Access in VBA. Aplikacija Access običajno ne šifrira sama. Povezavo s SQL Serverjem vzpostavi gonilnik ODBC, spletne klice komponente sistema Windows. V popis spadajo gonilnik in njegova različica, nastavitve šifriranja v povezovalnih nizih in podpisani projekti VBA. Gesla, shranjena v povezanih tabelah, niso kvantni problem, a jih boste ob tem gotovo našli.
• Shranjeni podatki. AES-256 ostane. Pozornost potrebujejo arhivi in varnostne kopije, katerih ključ je bil nekoč prenesen z RSA ali ECDH. Če je bil ta prenos prestrežen in shranjen, so tako varni kot ta prenos.
• Naprave z dolgo življenjsko dobo. Če podpisa strojne programske opreme ni mogoče zamenjati, ostane le zamenjava naprave. Nemška smernica omenja obe poti: počakati na naslednika, ki podpira PQC, ali napravo zamenjati prej (razdelek 4.6).

Kaj je v deset let stari aplikaciji sploh mogoče spremeniti, obravnava »Deset let stara aplikacija in postkvantna prihodnost«.

Dvanajst točk za dobavitelja, ki mora naročniku odgovoriti z dejstvi. Pri vsaki točki je navedeno, kaj preverite, kje, kdo je odgovoren, kateri dokaz šteje in kaj ostane odprto. Pri odgovornosti ločujemo vas (dobavitelja) in naročnika, ker se pri tej temi najpogosteje zamešata. Za stanje vsake točke zadoščajo štiri vrednosti:

• preverjeno: pogoj pod »Preverjeno, ko« je izpolnjen in dokaz obstaja;
• delno: izpolnjeno za del izdelka ali strank, preostanek je imenovan;
• ni preverjeno: še odprto;
• ni relevantno: s pisno utemeljitvijo, na primer »izdelek ne uporablja algoritmov z javnim ključem«.

• Preverite: Kdo pri vas odgovarja na vprašanja naročnikov o kriptografiji in kdo odloča o spremembah?
• Kje: organigram, sklep vodstva.
• Odgovoren: vodstvo.
• Dokaz: imenovana oseba z nadomestnikom; naročnik ve, na koga se obrne.
• Preverjeno, ko: prodaja na vprašanje »quantensicher?« ne odgovori brez te osebe.

• Preverite: Kje vaš izdelek uporablja kriptografijo? Protokoli, certifikati, podpisi, šifrirani podatki, shrambe ključev, knjižnice in njihove različice.
• Kje: izvorna koda, konfiguracija, seznam odvisnosti, namestitvena navodila.
• Odgovoren: vi.
• Dokaz: seznam z algoritmom, dolžino ključa, različico protokola, knjižnico z različico in mestom v izdelku. Strojno berljivo kot CBOM, na primer v formatu CycloneDX.
• Odprto: kriptografija v komponentah tretjih oseb, ki je ne vidite.
• Preverjeno, ko: isti seznam lahko pošljete vsakemu naročniku brez prilagajanja.

Več o tem: »Kriptografijo uporabljate vsak dan. Ali veste, kje vse?« in »Imate SBOM? Še vedno morda ne veste, katero kriptografijo uporabljate.«

• Preverite: Katero kriptografijo izvaja vaša koda, katero operacijski sistem, gonilnik ali strežnik pri naročniku?
• Kje: opis arhitekture izdelka, namestitvena navodila.
• Odgovoren: vi; za platformo naročnik.
• Dokaz: pri vsaki postavki iz točke 2 oznaka »izdelek« ali »platforma« z imenom komponente.
• Preverjeno, ko: naročnik iz odgovora razbere, kaj mora posodobiti sam.

• Preverite: Koliko časa morajo ostati zaupni podatki, ki jih vaš izdelek prenaša ali hrani?
• Kje: pogodba ali aneks, naročnikova varnostna dokumentacija.
• Odgovoren: naročnik; vi poveste, kateri podatki gredo skozi kateri kanal.
• Dokaz: naročnikova razvrstitev ali vaše vprašanje zanjo.
• Preverjeno, ko: veste, ali ste del primera uporabe z visokim tveganjem (deset let in več).

• Preverite: Ali povezave vašega izdelka podpirajo TLS 1.3 s hibridno skupino iz RFC 10024? Velja enako za SSH in VPN?
• Kje: konfiguracija, testni zajem vzpostavitve povezave.
• Odgovoren: vi za lastno kodo; naročnik za strežnike in posredniške strežnike.
• Dokaz: testni zapis z dejansko dogovorjeno skupino.
• Odprto: če nasprotna stran ne zna hibridno, povezava pade nazaj na klasični algoritem. To mora biti vidno.
• Preverjeno, ko: dogovorjena skupina je izmerjena, ne le nastavljena.

• Preverite: Ali izdelek šifrira tudi mimo TLS, na primer datoteke, sporočila ali licenčne ključe? S čim združuje skrivnosti?
• Kje: izvorna koda, opis zasnove.
• Odgovoren: vi.
• Dokaz: opis zasnove s kombinatorjem (CatKDF ali KeyCombine) in testni vektorji.
• Preverjeno, ko: noben lasten format ne združuje skrivnosti drugače kot po tabeli 2.1 smernice, ali pa je odstopanje utemeljeno in časovno omejeno.

• Preverite: Ali lahko zamenjate algoritem, s katerim podpisujete posodobitve?
• Kje: postopek izdaje, zagonski nalagalnik, hramba podpisnih ključev.
• Odgovoren: vi.
• Dokaz: opis postopka posodobitve; preizkus z drugim algoritmom.
• Preverjeno, ko: za vsak izdelek, ki bo v uporabi po letu 2030, je kvantno varna pot posodobitev opisana.

• Preverite: Katere certifikate uporablja izdelek, kdo jih izda, kako dolgo veljajo in ali jih je mogoče zamenjati brez nove različice izdelka?
• Kje: shramba certifikatov, konfiguracija in namestitveni paketi izdelka.
• Odgovoren: vi za izdelek; naročnik za svojo PKI.
• Dokaz: seznam certifikatov z izdajateljem in veljavnostjo.
• Odprto: kombinirani formati certifikatov še niso RFC.
• Preverjeno, ko: zamenjava certifikata je konfiguracija, ne nova izdaja.

• Preverite: Kje so algoritmi, dolžine ključev ali identifikatorji trdo zapisani?
• Kje: iskanje po kodi za imena algoritmov, dolžine ključev in OID.
• Odgovoren: vi.
• Dokaz: seznam mest; test, ki algoritem zamenja z nastavitvijo namesto s spremembo kode.
• Preverjeno, ko: vsako mesto je nastavljivo ali načrtovano za spremembo z rokom.

Več o tem: »Če je vaš kriptografski algoritem del poslovne logike, imate problem.«

• Preverite: Katere knjižnice in komponente tretjih oseb prinašajo kriptografijo in kaj načrtujejo njihovi avtorji?
• Kje: seznam odvisnosti, opombe ob izdajah, strani projektov.
• Odgovoren: vi.
• Dokaz: različice in objavljeni načrti; pri odprtokodnih knjižnicah opombe ob izdajah.
• Preverjeno, ko: za vsako komponento iz točke 2 veste, ali in od katere različice podpira ML-KEM ali ML-DSA.

• Preverite: Ali imate testni načrt za vzpostavitev povezave, velikost paketov, zmogljivost in nasprotne strani, ter pot nazaj?
• Kje: testno okolje, postopek uvajanja sprememb.
• Odgovoren: vi; testno okolje pogosto naročnik.
• Dokaz: testno poročilo; opisana pot nazaj s sprožilcem.
• Preverjeno, ko: nobena sprememba ne gre k naročniku brez testa in poti nazaj.

• Preverite: Ali so odgovori iz točk 1 do 11 zbrani na enem mestu, z datumom in različico izdelka?
• Kje: skupni repozitorij ali dokumentni sistem.
• Odgovoren: vi.
• Dokaz: mapa, ki jo lahko pošljete vsakemu naročniku: popis, načrt z roki, meje in odstopanja.
• Preverjeno, ko: na nov vprašalnik odgovorite iz mape, ne iz spomina.

Kako iz mape dokazil odgovoriti na vprašalnik, opisuje »Nemški vprašalnik o postkvantni varnosti: kaj lahko dokažete?«, z dvojezičnim vprašalnikom v prilogi.

TR-02102-1 izide vsako leto znova, običajno januarja. Kaj obljubite s pogodbo, ki se sklicuje nanjo, je zato odvisno od tega, kako jo navaja:

Nove izdaje niso le kozmetične. Leta 2020 so v smernico prišli prvi postkvantni algoritmi, a le za hibridno uporabo, leta 2023 je varnostna raven zrasla na 120 bitov, od leta 2024 RSA z 2048 biti ni več skladen, leta 2026 pa so prišli roki za prehod. Kako smo stran sproti dopolnjevali, je navedeno na koncu.

Primer Classic McEliece. Algoritem je v smernici od leta 2020, danes le za hibridno uporabo. V obvestilu s stanjem 29. septembra 2026 BSI po novih kriptoanalitičnih rezultatih, h katerim je prispeval tudi sam, odsvetuje njegovo uporabo v novem razvoju in napotuje na FrodoKEM, ML-KEM in pozneje HQC. Za tistega, ki ga danes uporablja hibridno, to ni izredna situacija: kombinacija po oceni BSI še vedno zagotavlja vsaj varnost klasičnega algoritma. Za pogodbo pa je to dober preizkus. Če obljublja »vsakokratno veljavno različico«, se bo vaša obveznost spremenila z naslednjo izdajo smernice. Če obljublja različico 2026-01, se ne bo, naročnik pa bo vseeno vprašal, kaj nameravate.

Kaj predlagati. Izhodišče je različica, ki velja ob podpisu. Poznejše različice veljajo s prehodnim rokom, ki ga dogovorite vnaprej, odstopanja pa razkrijete z utemeljitvijo in rokom. Tako obljubo lahko izpolnite in dokažete, naročnik pa z njo dokaže svoje stanje tehnike.

Člen o »skladnosti s TR-02102« ni nujno slab. Slab je, če ne pove, kaj točno obljubljate. Pred podpisom ga je smiselno preoblikovati:

To ni pravni nasvet. Pogodbo preverite s svojim pravnikom. Tehnično pa je naročniku v korist, da prejme natančno obljubo: z njo lahko dokaže svoje stanje tehnike, s »smo skladni« ne.

Razvijamo dva izdelka za postkvantne algoritme v obstoječi programski opremi. Oba sta objavljena kot predogled.

Kriptografska knjižnica za .NET obstoječi kodi na posameznem mestu klica doda ML-KEM in ML-DSA: za certifikate, sporočila CMS, podpise XML in hibridni dogovor o ključu. Privzete nastavitve sledijo TR-02102-1, različici 2026-01. To je javno dokumentirano (smernica za postkvantne algoritme):

• ML-KEM-768 in -1024 ter ML-DSA-65 in -87 delujejo samo skupaj s klasičnim algoritmom.
• Hibridne ključe združuje s KeyCombine po NIST SP 800-227, s HKDF-SHA256 kot funkcijo H.
• Nepriporočeni nabori parametrov in čisti postkvantni algoritmi ustvarijo nove podatke samo z izrecno odobritvijo ob zagonu. Vsako odstopanje sproži dogodek.
• Klic, ki zahteva postkvantni del in ga ne more ustvariti, se konča z napako. Tiho ne nadaljuje klasično.

Česa ne zna:

• CatKDF, SLH-DSA, XMSS, LMS, FrodoKEM in Classic McEliece niso izvedeni.
• Ne vsebuje vzpostavitve povezave TLS.
• OpenSSL od različice 3.5 naprej namestite in posodabljate sami.
• Ni certificirana ne po FIPS 140-3 ne po drugi shemi. To, da privzete nastavitve sledijo smernici, ni odobritev.

Kriptografska storitev ponuja ML-KEM in ML-DSA kot ločen proces za L4Re in Windows. Hibridno združevanje tam izvede klicatelj.

Database Gateway in gonilnik OData-ODBC komunicirata prek HTTPS. Izmenjava ključev je stvar platforme, na kateri tečeta. Za te povezave ne trdimo ničesar o postkvantni varnosti; v kontrolnem seznamu spadajo pod točko 5 kot vsaka druga povezava. Na čem delamo, da se to spremeni, opisuje naslednji razdelek.

Do te teme nismo prišli prek učbenika, temveč prek podatkovne poti. Marca 2020, ko so čez noč vsi delali od doma, smo v nekaj dneh postavili zasilni dostop: poslovne aplikacije so podatke dobivale prek HTTP namesto neposredno iz baze. Obratovanje je teklo naprej. Dostop pa je preverjal le, kdo sprašuje, ne pa, kaj ta oseba sme. Iz te vrzeli je nastal Database Gateway s prijavo ob vsaki zahtevi, pravili za posamezen objekt in metodo ter dnevnikom tudi zavrnjenih zahtev. Celotno zgodbo opisuje prispevek »Delo od doma 2020: aplikacija je delovala. Je bila arhitektura pripravljena?«.

Ena meja je ostala, tista iz prejšnjega razdelka: pravice ureja Gateway, prenos pa ščiti platforma, s klasično izmenjavo ključev. Na tem delamo v dveh smereh.

Dodaten postkvantni ključ za HTTPS. Zgled prihaja iz sveta VPN. Rosenpass teče ob WireGuardu, s postkvantnimi algoritmi izmenja lasten ključ in ga WireGuardu preda kot vnaprej deljeni ključ za rokovanje; ključ zamenja vsaki dve minuti. WireGuard šifrira kot doslej, zato povezava ni šibkejša kot s samim WireGuardom. Raziskujemo, kako ta vzorec prenesti na TLS 1.3 med Gatewayem in gonilnikom, saj zna TLS 1.3 zunanje dogovorjeni ključ uporabiti skupaj z običajno izmenjavo Diffie-Hellman. Prevzeti želimo vzorec, ne izbire algoritmov: Rosenpass poleg Kyberja uporablja tudi Classic McEliece, ki ga BSI zdaj odsvetuje. Za postkvantni del načrtujemo ML-KEM in kombinator po razdelku 2.2 smernice.

Robni prehod za naprave na terenu. V konzorcijskem projektu »Postquantensichere Verschlüsselung in automatisierten Systemen«, ki ga sofinancirata Evropska unija in dežela Severno Porenje-Vestfalija, s Tehnično univerzo v Dresdnu (jedro operacijskega sistema L4Re), podjetjem ISS (strojna oprema) in drugimi partnerji razvijamo prehod (edge gateway), ki stoji pred napravo, na primer pred vetrno elektrarno. Cilj: ukaz doseže napravo le, če se pošiljatelj lahko izkaže in je za to pooblaščen, tako da nihče ne more prevzeti naprave prek njenih oddaljenih dostopov. Naš del v konzorciju sta algoritem in PKI kot storitev, torej certifikati, po katerih se udeleženci med seboj prepoznajo.

Kam to vodi. Obe poti se končata pri vprašanju, ki je bilo odločilno že leta 2020: kdo sme kaj in kdo lahko to dokaže? Zato Database Gateway razširjamo v infrastrukturo za dobavno verigo. Vsaka namestitev postane lasten prostor zaupanja za podjetja, ki sodelujejo pri njej, na primer za upravljavca, proizvajalca in serviserja. V njem se preveri vsaka zahteva, ne glede na omrežje, iz katerega pride (zero trust), udeleženci pa se med seboj izkažejo s certifikati iz PKI te namestitve, namesto da bi si vnaprej zaupali (mutual trust). Za dobavitelja v taki verigi bi to pomenilo, da svojo vlogo dokaže s certifikatom, ne s tem, da je v pravem omrežju.

To je naša smer, ne današnji obseg izdelka. Roki in obseg funkcij še niso določeni, v raziskovalnem projektu pa se lahko spremeni tudi pot. Do takrat za povezave Database Gatewaya velja, kar piše zgoraj. Če sodelujete v taki dobavni verigi in bi radi zgodaj soodločali, nam pišite prek strani za stik.

• Še ne veste, kje v izdelku je kriptografija: začnite s točkami 1 do 3 kontrolnega seznama. Za to ne potrebujete nikogar od zunaj, rezultat pa lahko uporabite za vse naročnike.
• Vaša aplikacija .NET sama podpisuje ali šifrira: dokumentacija knjižnice korak za korakom pokaže prvo hibridno verigo certifikatov. Funkcije, zahteve in omejitve so na strani izdelka.
• Popisa ne želite delati sami: na strani Kriptografija lahko naročite popis kriptografije. V prvem pogovoru se dogovorimo, kateri sistemi spadajo zraven.

Ali TR-02102 velja v Sloveniji?
Kot predpis ne. Do vas pride prek pogodb z nemškimi naročniki. Načrt EU, iz katerega sta roka 2030 in 2035, pa je namenjen vsem državam članicam, tudi Sloveniji.

Ali moramo biti certificirani?
Samo če to zahteva pogodba ali izdelek potrebuje odobritev, na primer za tajne podatke v Nemčiji. Dokaz skladnosti s smernico po njenih lastnih besedah zahteva certifikate Common Criteria ali primerljiv postopek BSI.

Ali ZInfV-1 zahteva postkvantno kriptografijo?
Roka zanjo ne določa. URSIV zavezancem in drugim organizacijam priporoča, da začnejo s prehodom: pregledajo uporabo kriptografije, pripravijo načrte in postopoma uvajajo kvantno odporne rešitve.

Kaj odgovoriti na »Ist Ihre Lösung quantensicher? Ja/Nein«?
Z »Ja« prevzamete obveznost, ki je ne morete dokazati. Z »Nein« izgubite priložnost pojasniti, kaj že deluje. Priložite kratek opis: katere povezave in podatki, katera algoritma, od katere različice, kaj je odvisno od naročnika.

Ali smemo X25519MLKEM768 uporabljati v TLS 1.3?
Da. Po navedbi BSI ga je mogoče uporabljati poleg skupin, ki jih namerava priporočiti: SecP256r1MLKEM768 in SecP384r1MLKEM1024 iz RFC 10024, predvidenih za naslednjo različico TR-02102-2. Če v pogodbi obljubite »priporočeno po TR-02102«, ponudite eno od teh dveh skupin.

Kaj se je v TR-02102-1 spremenilo leta 2026?
Različica 2026-01 prvič določa roke za prehod, prenavlja izpeljavo ključev in hibridizacijo ter napoveduje opustitev samostojne uporabe klasičnih asimetričnih algoritmov. Kaj so spremenile prejšnje različice in kaj to pomeni za pogodbo, pojasnjuje razdelek Katera različica smernice velja v pogodbi.

Ali zadošča, da RSA zamenjamo z ML-KEM?
Ne. Smernica ML-KEM priporoča samo skupaj s klasičnim algoritmom. Prehod zajema tudi podpise, certifikate, protokole in shranjene podatke.

Kaj je CBOM?
Cryptographic Bill of Materials, na primer po CycloneDX: strojno berljiv seznam kriptografskih sestavin izdelka. Nemška smernica jo priporoča za primerjavo v dobavni verigi in navaja, da se njena dostava lahko zapiše v pogodbo.

Viri (preverjeno 3. novembra 2026):

• BSI: TR-02102-1 »Kryptographische Verfahren: Empfehlungen und Schlüssellängen«, različica 2026-01 z dne 23. 1. 2026, razdelki 1, 1.2, 2.1 do 2.4, 5.3, 5.3.4; deli 2 do 4 v različici 2026-01; na isti strani opombi o RFC 10024 in Classic McEliece
• BSI: sporočilo za javnost z dne 11. 2. 2026 (v nemščini)
• BMDS, BMI, BSI: »Nationale Umsetzung der EU-Roadmap zur Umstellung auf Post-Quanten-Kryptografie«, 11. 9. 2026, objavljeno 12. 10. 2026 (v nemščini)
• Skupina za sodelovanje NIS: »A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography«, 1. del, različica 1.1 z dne 11. 6. 2025; pogosta vprašanja z dne 15. 4. 2026 v slovenskem prevodu URSIV
• URSIV: »Varna digitalna prihodnost v dobi kvantnih računalnikov«, april 2026
• Evropska komisija: Priporočilo (EU) 2024/1101 z dne 11. 4. 2024
• § 30 BSIG (v nemščini)
• NIST: FIPS 203, FIPS 204, FIPS 205 (avgust 2024); SP 800-227 (september 2025)
• IETF: RFC 10024, RFC 10042, RFC 9370
• ETSI TS 103 744 V1.2.2 (2026-02)

Kaj spremljamo: naslednjo različico TR-02102-1 (običajno januarja), napovedano priporočilo skupin iz RFC 10024 v TR-02102-2, dodajanje HQC, sprejem kombiniranih formatov certifikatov in slovenski nacionalni načrt.

Regulativne trditve se starajo. Če stran berete po zgoraj navedenem datumu, preverite roke v izvirnem viru.