Če je vaš kriptografski algoritem del poslovne logike, imate problem.

Izdaja 13 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za razvojne arhitekte in izvajalce, ki gradijo ali vzdržujejo programsko opremo za nemške naročnike.

Poiščite v svoji kodi niz »RSA«, »SHA256withRSA« ali »ECDSA«. Če ga najdete v razredu, ki se imenuje InvoiceService, OrderExport ali DeliveryNoteSigner, imate odgovor na vprašanje, koliko bo stal prehod na nov postopek. Ne zato, ker bi bila koda slaba. Ampak zato, ker o kriptografiji odloča poslovna logika, in ta se spreminja počasi, previdno in drago.

V tem članku: Kako je videti problem · Pet lastnosti · Kaj prilagodljivost ni · Primer · Kako začeti v obstoječi kodi · Lastnik pravilnika · Kaj pokazati naročniku · Pasti · Vprašanje za naročnika · Priloga: referenčni vzorec

Koda, kakršno najdete v marsikateri produkcijski aplikaciji:

// poslovna logika ve, s katerim postopkom podpisuje
public byte[] signDeliveryNote(DeliveryNote note) {
    Signature s = Signature.getInstance("SHA256withRSA");
    s.initSign(loadKey("delivery-signing.pfx"));
    s.update(note.toBytes());
    return s.sign();
}

Koda deluje, je kratka in jasna. Marsikdo jo je kdaj napisal in bil nanjo celo ponosen. Težava je v tem, da je odločitev o postopku, ključu in obliki podpisa skrita v metodi, ki jo razvijalec dojema kot poslovno funkcijo. Ko boste postopek menjali, ne boste menjali ene nastavitve, ampak iskali vse takšne metode, jih spreminjali, ponovno preizkušali poslovne procese in usklajevali objavo z naročnikom.

Prilagodljiva različica iste funkcije:

// poslovna logika pove namen, ne postopka
public SignedDocument signDeliveryNote(DeliveryNote note) {
    return crypto.sign(Purpose.DELIVERY_NOTE, note.toBytes());
}

Kateri postopek, kateri ključ in v kateri obliki, odloči kriptografska storitev po pravilniku. Rezultat nosi oznako postopka, da ga bo mogoče pozneje pravilno preveriti.

1. Abstrakcija po namenu. Poslovna koda kliče »podpiši dobavnico« ali »zaščiti prilogo«, ne »RSA«. Namen je stabilen, postopek ne.
2. Ločitev odgovornosti. Ena komponenta izbira postopke in upravlja ključe. Razvijalec poslovne funkcije o tem ne odloča in ne more nehote izbrati napačnega.
3. Nastavitve s pravilnikom. Postopek je določen v nastavitvi, ki ima lastnika, različico in pregled sprememb. Ne v okoljski spremenljivki, ki jo kdo spremeni ob namestitvi.
4. Različice v podatkih. Vsak podpis, šifrirani zapis ali žeton nosi oznako postopka. Brez nje po zamenjavi ne veste, kako preveriti stare podatke. Ob tem predvidite prostor: postkvantni podpisi so večkrat večji od današnjih.
5. Preizkusljivost. Avtomatizirani preizkusi tečejo tudi z drugim postopkom. Zamenjava se prvič zgodi v testnem okolju, ne v produkciji.

Tri zamenjave pojmov so pogoste:

• Prilagodljivo ni kvantno varno. Prilagodljivost pove, kako lahko je zamenjati postopek, ne kateri postopek teče. Prilagodljiva aplikacija lahko danes uporablja samo RSA, le zamenja ga laže.
• Prilagodljivo ni »vse nastavljivo«. Spustni seznam s tremi postopki ne pomaga, če četrtega ni in pride šele z novo različico knjižnice.
• Prilagodljivo ni brezplačno. Zamenjava ostaja sprememba s preizkusi in usklajevanjem s protistranko. Prilagodljivost jo naredi obvladljivo, ne trivialno.

Evropski načrt za prehod na postkvantno kriptografijo iz junija 2025 prilagodljivost uvršča med naslednje korake in priporoča, da se upošteva pri javnih naročilih. Pričakujemo, da jo bodo nemški naročniki zato vse pogosteje navajali v zahtevah. Bolje je, da jo imate, preden jo zahtevajo.

Razvojna hiša v Mariboru, denimo, vzdržuje aplikacijo za upravljanje dobav za nemškega trgovca. Aplikacija podpisuje dobavnice, potrdila o prevzemu in izvoze za naročnikov ERP. Ko naročnik vpraša, koliko bi stala zamenjava podpisnega postopka, ekipa pregleda kodo in najde:

• 14 mest, kjer je postopek naveden neposredno v poslovnih razredih;
• dva različna ključa, ki se nalagata iz datotek na treh različnih mestih;
• podatkovno polje za podpis z omejitvijo 512 bajtov v bazi in v izvozni datoteki;
• nobenega preizkusa, ki bi tekel z drugim postopkom.

Ocena: tri mesece dela, od tega večina za preizkušanje poslovnih procesov, ne za kriptografijo. Ekipa predlaga drugačen pristop: najprej v enem sprintu uvede kriptografsko storitev po namenu in preusmeri vseh 14 mest nanjo, brez spremembe postopka. Nato razširi podatkovno polje in doda oznako postopka. Ko bo zamenjava postopka res potrebna, bo to sprememba pravilnika in preizkus, ne projekt.

Ni vam treba prepisati aplikacije. Postopek v štirih korakih:

1. Popišite mesta (izdaja 09): kje koda kliče kriptografske funkcije, s katerim postopkom in katerim ključem.
2. Uvedite storitev po namenu in nanjo preusmerite obstoječa mesta, brez spremembe postopka. Obnašanje ostane enako, preizkusi to potrdijo.
3. Dodajte oznako postopka v podatke in razširite polja, kjer je to potrebno. Stari podatki brez oznake veljajo kot »privzeti stari postopek«.
4. Dodajte preizkus z drugim postopkom. Lahko je tudi klasičen, na primer ECDSA namesto RSA. Dokazuje isto zmožnost.

Vsak korak je samostojno uporaben in ga je mogoče izvesti v rednem razvoju, ne kot ločen projekt.

Ko je postopek v pravilniku, se vprašanje premakne: kdo sme pravilnik spremeniti? V aplikaciji, ki jo razvijate in upravljate sami, je to vaša ekipa. V aplikaciji, ki jo namestite pri naročniku, je lahko to naročnikov skrbnik. Pri storitvi, ki teče pri vas in jo naročnik le uporablja, ste to vi, a naročnik mora vedeti, kdaj in kaj spremenite.

Zapišite to izrecno, v dokumentaciji in po potrebi v pogodbi: kdo pravilnik spremeni, kdo mora biti obveščen, kakšno je prehodno obdobje in kdo preizkusi povezave s protistrankami. Brez tega bo prva zamenjava postopka tudi prvi spor o odgovornosti (izdaja 07).

Nemški naročnik vas lahko vpraša, ali je vaša rešitev »kryptoagil«. Odgovor »da« ne pomeni ničesar. Pripravite raje dokaze:

• seznam mest, kjer koda uporablja kriptografijo, in na koliko mestih se določa postopek;
• opis kriptografske storitve in pravilnika: kdo ga upravlja, kje je shranjen, kako se spremeni;
• oznako postopka v podatkih in največjo velikost podpisa, ki jo oblike podpirajo;
• posnetek ali predstavitev zamenjave postopka v testnem okolju, tudi med dvema klasičnima postopkoma;
• seznam knjižnic z različicami in napovedano podporo postkvantnim postopkom.

Takšen odgovor je kratek, preverljiv in vas loči od ponudnikov, ki le odkljukajo okence.

• Lastni protokol za dogovor o postopku. Če se dve strani dogovarjata o postopku, mora biti dogovor zaščiten, sicer ju napadalec lahko prisili v najšibkejšega. Uveljavljeni protokoli, kot je TLS 1.3, to rešujejo; pri lastnih protokolih je to treba preveriti.
• Preveč možnosti. Vsak dodatno podprt postopek je treba vzdrževati in preizkušati. Prilagodljivost pomeni, da lahko zamenjate, ne da ponujate vse hkrati.
• Nastavitev brez lastnika. Postopek, ki ga lahko spremeni kdorkoli ob namestitvi, ni prilagodljivost, ampak tveganje.
• Lastna kriptografija. Abstrakcija naj kliče preverjene knjižnice. Lastnih izvedb postopkov ne pišite.

„Wir können das Signaturverfahren über eine zentrale Richtlinie wechseln und alte Signaturen weiter prüfen. Welches Verfahren und welche Übergangszeit erwarten Sie auf Ihrer Seite, und kann Ihr System Dokumente mit größeren Signaturen und einer Verfahrenskennung verarbeiten?“

Prevod: Podpisni postopek lahko zamenjamo prek osrednjega pravilnika in še naprej preverjamo stare podpise. Kateri postopek in kakšno prehodno obdobje pričakujete na svoji strani ter ali vaš sistem lahko obdela dokumente z večjimi podpisi in oznako postopka?

Zakaj tako? Ker vaša prilagodljivost nič ne pomaga, če naročnikov ERP ne sprejme večjega podpisa. Z vprašanjem pokažete, da ste svoj del uredili, in odprete pogovor o njegovem.

Nemška izdaja te teme se obrača na tehnično vodstvo in nabavo pri naročnikih: „Kryptoagilität: Können Ihre Dienstleister Algorithmen austauschen, ohne Geschäftsprozesse umzubauen?“ (v nemščini). Prejšnja izdaja: Postkvantna migracija bo stala. Nepripravljenost lahko stane več.

Referenčni vzorec (poenostavljen). Opisuje odgovornosti, ne določene tehnologije. V nemški izdaji je vsebinsko enak.

 +-----------------------------------------------------------+
 |  Poslovna logika     "podpiši dobavnico", "pošlji podatke" |
 |                      NE pozna postopka                     |
 +-----------------------------+-----------------------------+
                               | namen (podpis, zaščita)
 +-----------------------------v-----------------------------+
 |  Kriptografska       izbere postopek po pravilniku         |
 |  storitev            zapiše oznako postopka v podatke      |
 |  + pravilnik         preverja stare in nove postopke       |
 +-----------------------------+-----------------------------+
                               | postopek, sklic na ključ
 +-----------------------------v-----------------------------+
 |  Ponudnik            knjižnica, HSM, operacijski sistem    |
 +-----------------------------+-----------------------------+
                               |
 +-----------------------------v-----------------------------+
 |  Upravljanje ključev nastanek, hramba, menjava             |
 +-----------------------------------------------------------+

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

Naslednja izdaja (3. 8. 2026): »ML-KEM ni čarobna zamenjava za RSA.«

Viri (stanje 6. 7. 2026): NIS Cooperation Group, »A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography«, različica 1.1 (junij 2025), Next Steps »Cryptographic agility«; AIVD, CWI in TNO, »The PQC Migration Handbook«, 2. izdaja (december 2024); NIST FIPS 204 (avgust 2024).

Če želite ugotoviti, na koliko mestih vaša koda odloča o kriptografiji, nam pišite.