Blog

Témata:

25. 5. 2026

Bezpečnost Kryptografie

Životní cykly a kryptografie

Podvědomě tušíme souvislosti se stářím vybavení, jeho spolehlivostí a obecnou bezpečností. Na druhou stranu je obtížné si uvedený problém představit v oblasti kryptografie a tyto dopady vývoje přijmout. Zajímalo mne, jak vůbec je možné nad uvedenými životními cykly uvažovat, jaký mají vliv na bezpečnost, případně jaké vztahy jsou mezi životními cykly kryptografie a dalších aplikací nebo služeb. Cílem je jednak pochopení motivací udržet stávající řešení, dále dopady prodlužování na technologický dluh a nakolik může přístup za pomoci kryptoagility uvedené problémy řešit. Tato série článků se snaží sumarizovat přičiny, které překáží pravidelné a hlavně rychlé obměně kryptografie, stejně jako poskytnout přehled důvodů. Pokud důvody těchto problémů známe, jsme schopni je zvážit a odpovídajícím způsobem se rozhodnout.

Zombie apokalypsa

V současnosti se většina systémů podřizuje řízení na základě bezpečnosti. Důvodem je obrovcký nárůst rizik plynoucích z nacházených zranitelností nebo nesrovnalostí. S tím ale souvisí i část věnující se podpoře. V případě nedostupnosti záruční nebo pozáruční podpory se ze zařízení stávají zombie. Největším problémem z hlediska bezpečnosti (security) je zombie apokalypsa, kdy se z neservisovatelných ale funkčních zařízení, stávají „nemrtví“. Tedy zařízení, která nejsou ani zcela živá, ani mrtvá, pouze vytvářejí bezpečnostní riziko. Tyto zombie, tedy systémy bez jakékoliv podpory či servisu, mají v případě problému jedinou možnost řešení. A tím je výměna za jiné komponenty, tedy za zařízení s podporou. Typickým příkladem těchto zombie zařízení jsou staré routery, access pointy, tiskárny nebo další obdobná zařízení. Ale může se jednat i o zastaralé systémy, nepodporované aplikace, jejichž obhospodařování vytváří další vícenáklady. Tato zařízení či aplikace jsou sice stále funkční, ale obsahují velké množství bezpečnostních chyb. Pro případného útočníka jsou přímo darem z nebes, protože neřeší aktuální bezpečnostní hrozby nebo trendy.

Dopady životních cyklů

Proč jsou vlastně životní cykly důležité? Dovolují plánovat obměnu zařízení a do jisté míry mají schopnost popsat, o jaký typ zařízení se jedná. Zároveň přináší zajímavou otázku, zda je motivace k řízení těchto životních cyklů v současnosti odpovídající aktuální situaci. Prudký rozvoj kyberkriminality přináší hrozby, se kterými se při návrhu těchto systémů nepočítalo. Nevhodná motivace řízení životních cyklů tak přináší zvýšené náklady na architekturu systémů s cílem chránit systémy, které chránit ani není možné. Reaktivní přístup je vždy pozadu za snahami útočníků. Ale jak vlastně v jednotlivých oblastech uvedené cykly vypadají? Jak je možné je rozdělit?

Oblast	Technická životnost	Morální živostnost	Podpora	Motivace
IT: SMB, Enterprise, Datacentra	5-10 let	3-6 let	3-10 let	TCO - energie, licence, hustota výkonu
OT: Building, Industrial, Utility	15-40 let	10-25 let	5-20 let	Dostupnost a bezpečnost (safety)
IoT: Consumer, Industrial	5-15 let	3-7 let	2-5 let	Pořizovací náklad, jednoduchost, time-to-market
Automotive	15-25 let	8-15 let	8-15 let	Servisní náklady, regulace a bezpečnost (safety)
Consumer electronic	5-15 let	3-8 let	2-7 let	Pořizovací náklad, uživatelské rozhraní, morální životnost
Bankovní a platební systémy	10-20 let	8-15 let	10-20 let	Compliance, bezpečnost (security), dostupnost
Zdravotnictví a lékařské zařízení	10-25 let	8-15 let	10-25 let	Bezpečnost (safety), certifikace, validace
Embedded systémy	5-20 let	5-15 let	5-15 let	Stabilita, spotřeba, předvídatelné stavy
Nositelná elektronika	2-5 let	2-4 let	2-5 let	Velikost, kapacita baterie, uživatelské rozhraní
Cloud, SaaS infrastruktura	N/A	1-5 let	N/A	Škálovatelnost, OPEX, latence
Cybersecurity	3-10 let	2-5 let	3-10 let	Bezpečnost (security), reakční doba, náklady
Letectví a kosmonautika	10-30 let	10-30 let	N/A	Spolehlivost, radiační odolnost, dostupnost
Telekomunikace	10-25 let	5-10 let	10-20 let	Kapacita, latence, standardizace
Software
Operační systémy	2-5 let	2-3 let	2-10 let	Ekosystém, business model, uživatelské rozhraní
Mobilní aplikace	1-3 let	1-2 let	1-3 let	Ekosystém, API, business model
Enterprise aplikace	1-10 let	1-5 let	2-10 let	Ekosystém, API, business model
SaaS	N/A	N/A	N/A	Ekosystém, API, business model

I z takto hrubého přiblížení je vidět jednoduchý výstup. Každá oblast aplikací má odlišné modely životních cyklů řízené odlišnými požadavky na provoz, staví často na zcela odlišných filozofických principech. Proto je často přesně tento pohled na systémy v jádru problémů a nepochopení při implementaci, problémů s náklady, bezpečností (security) a ve výsledku může ohrožovat lidské zdraví a životy. Není možné očekávat požadavky odpovídající současným systémům od systémů starých jednu lidskou generaci (cca 30 let). Stejně tak není možné požadovat jako řešení problémů radikální výměnu systémů, kterých jsou nainstalované stovky tisíc až milióny a je na ně navázaný komplexní ekosystém. V některých případech je takový přístup ekvivalentem ekonomické sebevraždy, náklady na rychlou obměnu by zruinovaly rozpočet i silných ekonomik. Životní cykly se ale netýkají jenom hardware a software. Stejně tak existují životní cykly pro informace, uživatele, procesy. Nebo pro klíčový materiál a samozřejme i kryptografii. Výše uvedené vlastnosti a motivace ale není zcela snadné převést do uvedených oblastí.

Souboj pancíře a ráže

V případě soubor kryptologie a kryptoanalýzy rád připomínám podobný souboj v historii. Souboj pancíře a ráže. Evoluce postupovala i zde vcelku jednoduše. Čím silnější pancíř, tím těžší a rychlejší musel být náboj. Pokud nebyl rychlejší, musel být ještě těžší. V tomto souboji se objevily skoky. Ať to byly delší střely (penetrátory), podkaliberní projektily (penetrátor a sabot), kumulativní hlavice (urychlující v terminální fázi proud spalin o vysoké teplotě a rychlosti), explozí formované střely a v současnosti pak využití hlavic, útočících z jiného směru, kde není tak silný pancíř. Taková paralela je možná ještě přesnější než jiné, protože obsahuje skokové, lépe technologické změny vývoje.

Stejně tak existoval vývoj v kryptografii a kryptoanalýze. Postupná náhrada kódování za šifrování, použití hesel, použití matematických postupů až do současnosti. Tyto cykly se postupně zrychlují, jsou nacházeny slabiny starých algoritmů nebo protokolů a tyto komponenty zatížené chybou jsou následně nahrazovány za jiné, modernější. Kvantové počítače zde přinášejí hrozby, které do jisté míry už známe. Schopnost nalézt klíč a dešifrovat asymetrické (Shorův), případně symetrické (Groverův) algoritmy, nebo hledání kolizí ekvivalentních narozeninovému útoku (BHT algoritmus jako akronym pro Brassard-Høyer-Tapp). V současnosti tedy opět dochází ke skokové změně technologií. Naštěstí již máme technologie jiné, schopné výhodu kvantových počítačů na straně útočníka překonat. Ale taková situace vede k otázce, jaké jsou vlastně životní cykly kryptografie? Jak je možné popsat technickou a morální životnost, co je motivací vlastníka pro změnu?

Útoky na kryptografii

Kryptologové pracují s několika typy útoků. Ty je možné s odpovídajícími znalostmi využít jako signálizaci stavu životního cyklu. Bohužel, bez znalosti souvislostí tyto informace mohou být zavádějící.

Kryptografický útok je důkaz slabiny algoritmu, který upozorňuje na možné problémy. V tuto chvíli je algoritmus stále bezpečný. Tuto situaci je možné považovat za jeden ze signálů počátku konce morální životnosti. Bohužel se jedná o slabou indicii. Příkladem může být jemná změna bezpečnostního ekvivalentu algoritmu z hodnoty 256 bitů na 255,8 bitu. Státní aktér je v současnosti schopen s vypětím všech sil zaútočit na algoritmus s bezpečnostním ekvivalentem 80b. Ale patrně nikdo ještě není schopen zaútočit na algoritmus s bezpečnostním ekvivalentem 128b. Proto tento typ útoku nemá praktický dopad a na životnost nemá žádný vliv.
Teoretický útok popisuje situaci, kdy jsme teoreticky schopní (jednotlivec, organizace nebo stát) postavit systém, který by na takový algoritmus zaútočil. Tuto situaci lze považovat za varování a výrazně silnější signál blížícího se konce morální životnosti.
Praktický útok je konkrétní postup, který dokáže algoritmus zlomit. V tuto chvíli se nejedná o signál konce morální životnosti, ale konec technické živostnosti algoritmu. Je potřeba okamžitá náhrada.

Díky praktickému útoku s reálnými náklady je možné definovat konec technické životnosti. Algoritmus může sloužit do doby, než k takovému útoku dojde. Zde je nutné si dát pozor na ekonomickou stránku problému, přestože v některých případech jde ekonomika stranou. Daleko větší problém s definicí má ale morální životnost. Naštěstí i zde je možné zjednodušení, využívající standardizační instituce jako zprostředkovatele znalostí. Tyto instituce zaměstnávají personál, který má odborné a technické znalosti potřebné k posouzení vlastností algoritmu. Konec morální živostnosti tedy nastává, když algoritmus přestavá být doporučovaný, přestože není zlomený.

Největší problém je i v tomto případě podpora. Tu zajišťují jak standardizační instituce svými doporučeními, tak implementace v knihovnách zajišťujících výpočty potřebné pro kryptografické operace. Pokud je standardizační instituce považována za rozhodující pro ukončení morální živostnosti, je možné pro ukončení podpory uvažovat pouze software či hardware implementaci. V takovém případě je ukončení podpory v knihovnách ekvivalentní ukončení podpory algoritmů. Tento rozbor není zcela bez chyb, ale dovoluje základní orientaci. Jak ale pracovat s motivacemi, které řídí výměny v rámci životních cyklů? Co vede k těmto změnám?

Schopnosti jednotlivých aktérů útočit na kryptografii:

Počet operací	Kdo
<2³⁰	Běžní jednotlivci (potřebný bezpečnostní ekvivalent < 30b)
2³⁰-2⁵⁰	Dobře vybavení jednotlivci nebo malé až střední organizace (potřebný bezpečnostní ekvivalent 30b - 50b)
2^50-2⁷⁰	Velké organizace (potřebný bezpečnostní ekvivalent 50b - 70b)
2⁷⁰-2⁸⁰	Státní aktéři (potřebný bezpečnostní ekvivalent 70b - 80b)

Pokračování příště

Pokračování životních cyklů bude vysvětlovat motivací pro řízení kryptografie, životní cyklu kryptografie a kryptografickému dluhu. Poslední díl pak bude řešit měření kryptografického dluhu a důsledkům v řízení a obsluze tohoto dluhu. Součástí tohotu přehledu není životní cyklus kryptografického materiálu, ani otázka migrace na kryptografii odolnou kvantovým počítačům. Těmto tématům se věnují jiné články.

Reference:

Microsoft Product Lifecycle
Zdroj: https://www.microsoft.com/
Windows 10 Home and Pro Lifecycle
Zdroj: https://www.microsoft.com/
Red Hat Enterprise Linux Life Cycle
Zdroj: https://redhat.com/
Ubuntu Release Cycle
Zdroj: https://ubuntu.com/
International Energy Agency – Data Centres and Data Transmission Networks report
Zdroj: https://www.iea.org/
HP Enterprise Support Services
Zdroj: https://www.hp.com/
Dell End-of-Life Documents
Zdroj: https://www.dell.com/
Fujitsu Hardware Maintenance Services
Zdroj: https://www.fujitsu.com/
Fujitsu Maintenance Policy
Zdroj: https://global.fujitsu/
Lenovo Support Portal
Zdroj: https://support.lenovo.com/
ENISA – Good Practices for Security of IoT and Smart Infrastructures
Zdroj: https://www.enisa.europa.eu/
Consumer Reports – délka bezpečnostní podpory smart zařízení
Zdroj: https://www.consumerreports.org/
UNECE Vehicle Regulations – kyberbezpečnost a software update management vozidel
Zdroj: https://unece.org/
NASA – Thermal Design and Thermal Behaviour Reliability Principles
Zdroj: https://www.nasa.gov/
Our World in Data – Technological Progress and Computing Power Trends
Zdroj: https://ourworldindata.org/
NIST Cybersecurity Framework 2.0
Zdroj: https://www.nist.gov/
Key Management - NIST SP 800-57 a NIST SP 800-131
Zdroj: https://www.nist.gov/
NIST SP 800-61 Computer Security Incident Handling Guide
Zdroj: https://www.nist.gov/
NIST IR 8547 - Migration to Post-Quantum Cryptography
Zdroj: https://www.nist.gov/
Software-Defined Cryptography: A Design Feature of Cryptographic Agility
Zdroj: https://eprint.iacr.org/
RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Zdroj: https://www.rfc-editor.org/
CA Browser Forum - Baseline Requirements
Zdroj: https://cabforum.org/
OWASP SAMM stream B - Secret Management
Zdroj: https://owaspsamm.org/
NIST Post-Quantum Cryptography Project – standardizace postkvantové kryptografie
Zdroj: https://csrc.nist.gov/
AXELOS ITIL – framework pro IT service management a lifecycle služeb
Zdroj: https://www.axelos.com/
ISACA COBIT – governance framework pro enterprise IT
Zdroj: https://www.isaca.org/
ISO/IEC 27001 – standard systému řízení bezpečnosti informací (ISMS)
Zdroj: https://www.iso.org/
ISO 55001 – Asset Management Systems standard
Zdroj: https://www.iso.org/
ISO/IEC 15288 – Systems and Software Engineering Lifecycle Processes
Zdroj: https://www.iso.org/

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.

1. Úvodní ustanovení

1.1. Tyto všeobecné obchodní podmínky jsou, není-li ve smlouvě písemně dohodnuto jinak, nedílnou součástí všech smluv týkajících školení, pořádaných nebo poskytovaných školitelem, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, se sídlem Pod Harfou 938/58, Praha 9, zapsané u Úřadu městské části Praha 9 (dále jen „školitel“).
1.2. Smluvními stranami ve všeobecných obchodních podmínkách jsou míněni školitel a objednatel, kdy objednatel může být zároveň zprostředkovatelem smluvního vztahu.
1.3. Záležitosti, které nejsou upravené těmito obchodními podmínkami, se řeší podle Občanského zákoníků, tj. zákon č. 89/2012 Sb.

2. Vznik smlouvy přihlášením ke kurzu

2.1. Přihláškou se rozumí jednostranný úkon objednatele adresovaný školiteli prostřednictvím datové schránky s identifikací euxesuf, e-mailu na adresu register@cryptosession.cz nebo register@cryptosession.info, internetových stránek cryptosession.cz, cryptosession.info nebo kontaktním telefonem +420 602 427 840.
2.2. Odesláním přihlášky objednatel souhlasí s těmito všeobecnými podmínkami a prohlašuje, že se s nimi seznámil.
2.3. Přihláška se považuje za přijatou momentem potvrzení (stadnardně do 2 pracovních dní) školitelem nebo zprostředkovatelem. Toto potvrzení je zasláno do datové schránky nebo na kontaktní e-mail.
2.4. Standardní doba pro přihlášení je nejpozději 14 pracovních dní před konáním vzdělávací akce, pokud není uvedeno jinak. V případě fyzické nepodnikající osoby musí být objednávka alespoň 28 pracovních dní před konáním vzdělávací akce.
2.5. Na jednu přihláškou lze přihlásit i více než jednoho účastníka.
2.6. Pokud je více než 10 účastníků od jednoho objednatele, je možné se domluvit na školení v místě sídla zprostředkovatele nebo objednatele.
2.7. Přihlášky jsou přijímány a zpracovávány v pořadí, v jakém došly poskytovateli. Poskytovatel neprodleně informuje objednatele o všech skutečnostech. Těmi se míní naplnění kapacity, příliš nízký počet účastníků, nebo jiný závažný důvod, jako je nemoc lektora nebo zásah vyšší moci. Objednateli bude v tomto případě nabídnut nový termín, případně účast na jiné vzdělávací akci. V případě, že objednatel nebude s přesunutím či účastí na jiné nabídnuté vzdělávací akci souhlasit, poskytovatel mu vrátí účastnický poplatek. Nedostatečný účastníků je oznámen objednateli alespoň 14 dní před začátkem plánovaného termínu.
2.8. Smlouva mezi poskytovatelem a objednatelem vzniká odesláním potvrzení poskytovatelem objednateli.
2.9. Smlouvu lze změnit nebo zrušit pouze za splnění zákonných předpokladů a pouze písemně.

3. Zánik smlouvy zrušením přihlášky

3.1. Přihláška může být objednatelem zrušena pomocí e-mailu, nebo pomocí datové schránky.
3.2. Zákazník má právo stornovat svoji přihlášku na kurz 14 dní před konáním kurzu bez jakýchkoliv poplatků. Pokud se jedná o kratší dobu, dochází k následné změně. V intervalu 7-13 dní je účtován administrativní poplatek 10%, storno účasti v kratším intervalu než 7 dní pak poplatek 25%. V případě storna přihlášky nebo objednávky ze strany zákazníka je nabízena možnost účasti zákazníka v náhradním termínu bez dalšího poplatku. Právo na zrušení přihlášky zaniká realizací objednaného školení.
3.3. Při zrušení přihlášky školitelem náleží objednateli plná náhrada za neuskutečněnou akci.
3.4. Objednatel má právo žádat náhradní termín nebo náhradní školení. V takovém případě bude objednatel informován o všech otevřených kurzech. Náhradní termín si nelze vymáhat ani vynucovat, závisí na aktuální dostupnosti kurzu. Pokud má náhradní školení nižší cenu, objednatel doplatí rozdíl. Pokud má náhradní školení nižší cenu, školitel vrátí rozdíl cen školení objednateli.

4. Cena a platební podmínky

4.1. Odesláním přihlášky objednatel akceptuje smluvní cenu (dále jen účastnický poplatek) uvedenou u daného kurzu.
4.2. V případě více účastníků přihlášených jednou přihláškou je možná sleva.
4.3. Účastnický poplatek musí být uhrazen na bankovní účet společnosti vedený u Komerční banky č. 78-7768770207/0100. Při platbě je nutné uvést variabilní symbol, který je uveden na faktuře, odeslané objednateli školitelem.
4.4. Účastnický poplatek zahrnuje náklady poskytovatele včetně školicích materiálů. Poskytovatel je plátce DPH.
4.5. Účastnický poplatek je objednatel povinen uhradit do 14 pracovních dní od přijetí faktury, pokud nebylo samostatnou smlouvou uvedeno jinak.
4.6. Pokud se přihlášená osoba neúčastní školení a nedošlo k jiné domluvě, je její neúčast považována za storno příhlášku v intervalu kratším než 7 dní, tj. školiteli náleží odměna ve výši 25% z ceny kurzu. Přeplatek je vrácen do 14 dní na platební účet odesílatele, ze kterého byly prostředky odeslány. Platba na jiné číslo účtu není možná.
4.7. Nejdéle do 5 pracovních dní od začátku školení bude školitelem vystavena faktura, která bude dle dohody odeslána e-mailem nebo datovou schránkou.

5. Podmínky školení

5.1. Školitel je povinnen informovat objednatele 14 dní dopředu o místě a času školení, včetně termínu zahájení a ukončení denního programu.
5.2. Pokud objednatel není studentem kurzu, je povinnen zajistit distribuci těchto informací koncovým účastníkům. Za nesplnění těchto podmínek školitel nenese odpovědnost.
5.2. Standardně školení probíhá v čase od 9:00 do 17:00 na předem určeném místě.
5.3. Školitel může být dle aktuálních podmínek k dispozici od 8:00 do 9:00 a následně od 17:00 do 18:00 pro dotazy účastníků.
5.4. Na konci školení je koncovým uživatelům předán certifikát o absolovování.
5.5. Na konci školení koncoví uživatelé vyhodnocují přístup lektora a mají se vyjádřit k ohodnocení jeho prezentace, způsobu přednesení a ohodnotit významn poskytnutých informací.

6. Reklamace

6.1. Pokud je účastník hrubě nespokojen s průběhem kurzu, je školitel o této informaci vyrozuměn.
6.2. Důvody nespokojenosti jsou ten samý den zapsány do protokolu ve dvou kopiích. Jedna je předána objednateli a jednu má školitel.
6.3. Vyjádření k reklamaci bude podáno e-mailem do dvou týdnů. Následně do jednoho týdne bude domluven způsob řešení.
6.4. Nespokojenost zákazníka může být důvodem k rozvázání další spolupráce, nebo finanční kompenzaci až do výše ceny školení po odečtení nákladů.

7. Autorská práva k poskytnutým materiálům

7.1. Školicí materiály poskytnuté školitelem v rámci konání školení splňují znaky autorského díla dle zákona č. 121/2000 Sb.
7.2. Žádný ze školicích materiálů ani jeho část nesmí být bez předchozího písemného souhlasu školitele jakýmkoli způsobem dále zpracovávána, rozmnožována, rozšiřována nebo využívána k dalším prezentacím nebo školením.

8. Zodpovědnost

8.1. Školitel nepřebírá odpovědnost za nedostatky ve službách kterékoliv třetí strany, kterou využívá při školeních.
8.2. Školitel nepřebírá odpovědnost za zranění, škody a ztráty, vzniklé účastníkům vzdělávacích akcí, nebo které byly účastníky způsobeny. Takové náklady, způsobené uvedenými okolnostmi, ponese výhradně účastník vzdělávací akce.

9. Platnost podmínek

9.1 Tyto všeobecné obchodní podmínky jsou platné a účinné od 1. října 2024.