Deset let stara aplikacija in postkvantna prihodnost: kaj sploh lahko spremenimo?

Izdaja 15 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za interne IT-oddelke in vzdrževalce starejših aplikacij, ki podatke izmenjujejo z nemškimi naročniki.

Aplikacija za izvoz dobavnic je bila napisana leta 2016. Teče brez težav, uporabniki jo poznajo, sodelavec, ki jo je napisal, je še vedno v podjetju. Nemški naročnik vpraša, kdaj bo podpirala postkvantne postopke. Sodelavec odpre projekt in ugotovi, da knjižnica za povezave uporablja različico OpenSSL, ki je ni več mogoče prenesti z uradne strani, in da prevajalnik, s katerim je bila aplikacija zgrajena, na novem računalniku ne teče več.

V tem članku: Šest omejitev · Kaj lahko spremenite sami · Najprej obnovite gradnjo · Naprave v proizvodnji · Kaj ni v vaših rokah · Primer · Štiri poti · Kako govoriti z naročnikom · Vprašanje za naročnika · Priloga: odločitveno drevo

Starejša aplikacija je lahko poslovno brezhibna in kriptografsko v slepi ulici. Redko zaradi same kode, skoraj vedno zaradi tistega, na čemer stoji:

Konkretno: Java je vmesnike za ML-KEM in ML-DSA dobila z različico 24 (marec 2025). OpenSSL podpira postkvantne postopke od različice 3.5 (april 2025); serija 1.1.1 se od septembra 2023 javno ne vzdržuje več. Aplikacija, ki teče na starejših različicah, novih postopkov ne bo dobila z nastavitvijo.

Pri lastni aplikaciji, ki jo lahko znova zgradite, je več možnega, kot se zdi:

• Posodobitev knjižnice, če aplikacija knjižnico prinaša s seboj. Pogosto zahteva prilagoditve kode, a ne nove aplikacije.
• Prehod na novejše izvajalno okolje, z vmesnim korakom, če je skok prevelik.
• Ločitev kriptografije od poslovne logike (izdaja 13), postopno, ob rednem delu.
• Razširitev podatkovnih oblik, kjer jih določate sami: daljša polja, oznaka postopka.

Pogoj za vse to je, da aplikacijo sploh lahko zgradite. Če izvorna koda, prevajalnik ali odvisnosti niso več dosegljivi, je prvi korak obnova gradnje, ne kriptografija.

Pri aplikacijah, starejših od deset let, je prva ovira lahko presenetljivo prozaična: aplikacije ni več mogoče zgraditi. Izvorna koda obstaja, a manjka licenca za prevajalnik, komponenta tretjega proizvajalca ali skripta, ki jo je nekdo pred leti pognal ročno in je od takrat njegova mala skrivnost.

Preden se lotite kriptografije, preverite tri stvari:

• Ali lahko aplikacijo zgradite na čistem računalniku samo iz repozitorija in zapisanih navodil?
• Ali poznate vse odvisnosti z različicami, vključno s knjižnicami v mapi aplikacije?
• Ali lahko novo različico preizkusite brez tveganja za produkcijo?

Če je odgovor na katero od vprašanj »ne«, je to prvi projekt. Ni drag, a brez njega je vsaka poznejša sprememba, kriptografska ali poslovna, tvegana. Ta korak se splača tudi brez kvantnih računalnikov.

Posebna skupina so naprave: krmilniki, merilniki, čitalniki, terminali. Pogosto komunicirajo z naročnikom posredno, prek strežnika, ki zbira njihove podatke. Njihova kriptografija je v strojni programski opremi in se spremeni samo s posodobitvijo proizvajalca.

Za vsako takšno napravo zapišite, ali proizvajalec še izdaja posodobitve, ali naprava podatke podpisuje ali šifrira in ali ti podatki zapustijo vaše omrežje. Naprava, ki podatke pošilja samo na lokalni strežnik, ta pa jih naprej posreduje po sodobni povezavi, je manjše tveganje kot naprava, ki se neposredno povezuje navzven.

• Naprave s fiksno strojno programsko opremo. Če proizvajalec posodobitve ne izda, je ne bo.
• Platforme brez podpore. Operacijski sistem brez varnostnih posodobitev novih postopkov ne bo dobil.
• Druga stran. Če naročnikov strežnik podpira samo klasične postopke, vaša posodobitev ne spremeni dogovora (izdaja 14).
• Pogodbeni okvir. Če vzdržujete aplikacijo za naročnika in pogodba pokriva le odpravo napak, je posodobitev platforme dodatno naročilo, ne vzdrževanje (izdaja 12).

Pri teh točkah je vaša naloga, da omejitev jasno zapišete in sporočite, ne da jo prikrijete.

Vzemimo proizvajalca embalaže z Dolenjske. Kot v marsikaterem slovenskem podjetju tudi pri njem teče namizna aplikacija, napisana v Delphiju leta 2016, ki iz baze podatkov pripravi dobavnice in jih po SFTP pošlje nemškemu naročniku. Za povezavo uporablja komponento, ki kliče knjižnici OpenSSL 1.0.2, priloženi v mapi aplikacije.

Pregled pokaže:

• Izvorna koda je v repozitoriju, prevajalnik pa je različica, za katero podjetje nima več licence. Gradnja na novem računalniku ne uspe.
• Komponenta za povezavo ima novejšo različico, ki podpira OpenSSL 3, a zahteva spremembe na nekaj mestih v kodi.
• Dobavnice niso podpisane; zaupnost zagotavlja samo SFTP.
• Naročnik je za drugo leto napovedal nov portal s spletnim vmesnikom.

Odločitev: aplikacije ne prenavljajo celovito. Najprej obnovijo gradnjo z aktualnim prevajalnikom in posodobijo komponento za povezavo na različico z OpenSSL 3.5. To odpravi zastarelo knjižnico in odpre pot hibridnemu dogovoru o ključu, ko ga bo podpiral naročnikov strežnik. Celoten izvoz bodo prenovili ob prehodu na naročnikov portal.

Najpomembnejši izsledek ni bil kvanten: aplikacija je leta tekla na knjižnici brez varnostnih popravkov, ne da bi kdo to opazil.

Kadar neposreden prehod ni mogoč, ostanejo štiri poti:

• Prenesti: posodobiti platformo, okolje ali knjižnico in prilagoditi aplikacijo.
• Izolirati: sistem ostane, kot je, a povezave navzven prevzame vmesni sistem s sodobnimi postopki. Starejši sistem govori klasično le po kratkem, nadzorovanem odseku. Zaščita podatkov v samem sistemu se s tem ne spremeni.
• Zamenjati: sistem nadomestiti z novim in postkvantno zmožnost zapisati v zahteve.
• Začasno odstopati: tveganje zavestno sprejeti, ga dokumentirati, z odgovorno osebo in rokom.

Izolacija in začasno odstopanje sta nadomestna ukrepa. Sprejemljiva sta, če zmanjšata konkretno tveganje na konkretnem mestu, imata lastnika, imata rok in je njuna učinkovitost preverjena, na primer z meritvijo dogovorjenega postopka na vmesnem sistemu (izdaja 11). Ali je aplikacijo treba poslovno nadomestiti, je posebna odločitev; kriptografija je pri njej le eden od dejavnikov.

Pri starejših sistemih je skušnjava velika, da na vprašanje naročnika odgovorite neodločno: »Preverjamo.« »V načrtu.« Takšen odgovor kupi nekaj tednov in izgubi zaupanje.

Boljši je odgovor v treh delih: kaj velja danes (platforma, postopki, omejitve), kaj boste spremenili sami in do kdaj, kaj ni v vaših rokah in od koga je odvisno. Nemški naročnik, ki mora tveganja v dobavni verigi obvladovati, potrebuje predvsem predvidljivost. Starejši sistem z jasnim načrtom je zanj manjše tveganje kot sodoben sistem brez odgovora.

„Für unser Altsystem können wir die Bibliothek bis Ende des Jahres aktualisieren; die Plattform erneuern wir mit dem Wechsel auf Ihr neues Portal. Wann ist dieser Wechsel geplant, und welche Verfahren wird das Portal unterstützen?“

Prevod: Pri našem starejšem sistemu lahko knjižnico posodobimo do konca leta; platformo bomo prenovili ob prehodu na vaš novi portal. Kdaj je ta prehod načrtovan in katere postopke bo portal podpiral?

Zakaj tako? Ker pokažete, kaj lahko naredite sami in kdaj, in svojo večjo naložbo povežete z naročnikovim načrtom. Tako ne prenavljate dvakrat.

Nemška izdaja te teme se obrača na upravljavce starejših in industrijskih sistemov pri naročnikih: „Ihr Altsystem funktioniert. Aber ist es bis 2030 noch migrationsfähig?“ (v nemščini). Prejšnja izdaja: ML-KEM ni čarobna zamenjava za RSA.

Odločitveno drevo za starejši sistem (za vsak sistem enkrat). V nemški izdaji je vsebinsko enako.

 Ali sistem varuje podatke ali podpise z dolgo življenjsko dobo
 zaščite ali veliko škodo (izdaji 02, 12)?
 ├─ ne ───> začasno odstopati; upoštevati ob naslednji prenovi
 └─ da
     Ali je konec življenjske dobe sistema načrtovan pred koncem 2030?
     ├─ da ───> naslednik z zahtevo PQC (zamenjati);
     │          do takrat izolirati, če je mogoče
     └─ ne
         Ali je mogoče posodobiti platformo in zamenjati postopek
         z razumnim naporom?
         ├─ da ───> prenesti
         └─ ne
             Ali je mogoče povezavo navzven speljati prek
             sodobnega vmesnega sistema?
             ├─ da ───> izolirati (začasno, z dokazom)
             │          in načrtovati zamenjavo
             └─ ne ───> zamenjati; do takrat začasno odstopati
                        z odgovorno osebo in rokom

Zapis vsake odločitve:

Vse objavljene izdaje serije: pregled »Postkvantna varnost v dobavni verigi«

Naslednja izdaja (5. 10. 2026): »Nemčija konkretizira svoj postkvantni načrt. Kaj mora storiti slovenski dobavitelj?«

Viri (stanje 7. 9. 2026): NIS Cooperation Group, »A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography«, različica 1.1 (junij 2025); JEP 496 in 497 (JDK 24, marec 2025); OpenSSL 3.5 Release Notes (april 2025); OpenSSL, konec javnega vzdrževanja serije 1.1.1 (11. 9. 2023).

Če vaše najpomembnejše aplikacije ni več mogoče zgraditi, nam pišite.