V oblasti bezpečnosti je nutné mít přehled o spravovaných komponentách. Ale pro kryptografii dlouho nebyl k dispozici žádný ucelený postup. Výsledkem je nepříjemná situace, která ohrožuje bezpečnost a zvyšuje náklady na změnové řízení.
Crypto agility je termín, který se v poslední době často objevuje v oblasti IT bezpečnosti, zejména v oblasti kryptografie. Jeho cílem je hlavně zjednodušení a samozřejmě také zrychlení změn kryptografických mechanismů, tedy zvýšení flexibility řízení. Důvodem je existence bezpečnostních hrozeb (chyb protokolů, algoritmů nebo technik), změn v regulacích, přechody na jiné technologie.
Kryptografie nám má zajišťovat klíčové bezpečnostní vlastnosti: důvěrnost (confidentiality), celistvost (integrity), autenticitu (authenticity) a neodmítnutelnost (non-repudiation). Bez odpovídající správy však není možné těchto vlastností efektivně dosáhnout. Správa kryptografických protokolů a algoritmů je dnes velmi náročná, a pokud spolupracuje více aplikací od různých výrobců, může změna trvat i týdny až měsíce. Pokud se v takovém případě objeví například výše uvedená bezpečnostní hrozba, dochází k ohrožení jak celé organizace, tak často i navázaného dodavatelského řetězce. Proto je odpovědnost za kryptoagilitu úlohou nejenom pro product design, ale je součástí implementace, operátory IT, IT a bezpečnostní architekty, vývojáře software, hardware ale i vývojáře standardů, a v neposlední řadě i pro management.
V této oblasti je několik příkladů problémů s vyřazením staré a přechodem na novou kryptografii. Níže uvedené body jsou tak mementem situace, která v oblasti IT panuje, ale příkladů z reality by bylo podstatně více:
1) Migrace z algoritmu DES na jeho nástupce, algoritmus AES. Algoritmus DES byl standardizován v roce 1977, ale už okolo roku 1990 se objevila první praktická demonstrace útoku. V roce 1999 jako dočasná náhrada vznikl standard 3DES. Přestože byl AES standardizován již v roce 2001, v roce 2005 byl DES ze standardu vyřazen. Algoritmus 3DES byl označen v roce 2015 jako nevyhovující a od roku 2023 je zakázán pro použití, migrace na tento standard ale nebyla dodnes úspěšně dokončena.
2) Migrace z algoritmu RC4 na jiné proudové nebo blokové algoritmy. Tento algoritmus byl komerčně dostupný od roku 1987. V roce 2005 se objevila práce, upozorňující na statisticky významné závislosti, přesto byl algoritmus prakticky zlomen až v roce 2015. Dodnes je možné se s ním potkat v Kerberos/Active Directory, starších verzích TLS, případně dalších místech. Jeho alternativní název je ARCFOUR, ale jedná se o identický algoritmus.
3) Zlomení hashovacího algoritmu MD5. Algoritmus MD5 byl publikován v roce 1991 a zlomen již v roce 2005. Přesto je dodnes součástí některých verzí protokolů NTP, SMB, autentizačních mechanismů, digitálních podpisů, kontrol celistvosti a dalších komponent, vše velice snadno zranitelné.
Kryptoagilita je aktuálně zdůrazňována kvůli přechodu na kryptografii odolnou kvantovým počítačům (PQC – Post-Quantum Cryptography). Přesto vztah mezi kryptoagilitou a PQC není jednoznačný: kryptoagilita je přístup k řízení kryptografie zaměřený na rychlou změnu, zatímco přechod na PQC je jen jeden z případů, kdy je řízená změna vyžadována. Rozlišujeme tak důvod změny a způsob jejího řízení. Z dlouhodobého hlediska jednotlivé kryptografické algoritmy postupně zastarávají, proto je nutné zajistit pravidelnou obměnu. Navíc dochází k občasným průlomům, umožňujícím náhlou změnu bezpečnosti. V takovém případě je extrémně důležíté být připraven rychle reagovat. Příklady z minulosti jsou v tomto ohledu extrémně užitečné. Ať se jedná o zlomení algoritmu RC4, přechod z algoritmu DES potažmo 3DES na algoritmus AES, zlomení hash funkcí MD5 nebo SHA1, používání defaultních nonce u symetrického algoritmu AES-GCM, stejně jako příchod kvantových počítačů. Všechny uvedené změny se vyznačovaly náhlou změnou vnímání bezpečnosti. Tyto změny vyžadují zvláště v současném prostředí rychlou reakci organizace, a proto je kryptoagilita tak důležitá. Tento prvek souvisí i vývojem v oblasti PQC. Čistě hypoteticky, co když některý z navrhovaných algoritmů bude prolomen? Co když vývoj v této oblasti dovolí vyřešit některý z matematických problémů? V tuto chvíli potřebujeme kryptoagilitu a schopnost rychle reagovat.
Uvedený způsob řízení má kromě rychlosti změn (flexibility) zajistit i snížení nároků na personál. Na druhou stranu vyžaduje splnění určitých podmínek. Jednou z nejdůležitějších je efektivní správa zdrojů, tedy fungující asset management. Tento proces vyžaduje kompletní přehled o jednotlivých zařízeních a jejich konfiguracích. Použití standardních popisů umožňuje automaticky identifikovat možné změny a vylepšení. Pokud v takovém případě dojde k bezpečnostnímu incidentu v oblasti kryptografie, lze velmi rychle najít přijatelné řešení. Standardní sady mají obsahovat různé seznamy (BOM – Bill of Materials). Pro kryptoagilitu je nejdůležitější pouze jeden z nich, takzvaný CBOM. Jedná se o akronym pro Cryptography Bill of Materials. Asset management samozřejmě využívá i další sady, zde je přehled základních z nich:
Tento přehled jednotlivých BOM sad má sice význam pro asset management, ale daleko důležitější je pro vlastníka. Umožňuje mu totiž efektivnější řízení s nižšími náklady. Ale efektivně řídit změny kryptografie lze pouze s kompletními informacemi o zdrojích. Tedy musí být k dispozici asset management, správa zdrojů. Co to přesně znamená?
Asset management je proces, který určuje, co a kde mám a kdo to spravuje. Záznamy o položkách jsou takzvané CI. Jednotlivé CI (Configuration Items) jsou uloženy v CMDB (Configuration Management Database) spolu s jejich konfiguracemi a vazbami. Pokud se pro konfiguraci používají standardizované seznamy, je změna otázkou porovnání seznamů a případného generování nové konfigurace. Je možné jít dále a definovat kryptopolitiku pro celou organizaci, což výrazně zjednodušuje konfiguraci a snižuje náklady na změny. Veškeré změny lze automatizovat a sjednotit, což snižuje množství potřebného úsilí.
Důležitost asset managementu a vztah k BIA/BC: Funkční asset management je nezbytný nejen pro rychlou reakci na bezpečnostní incidenty, ale i pro provázání s Business Impact Analysis (BIA) a Business Continuity (BC). Správně vedený CBOM umožňuje rychle vyhodnotit dopad změn či incidentů na kritické procesy organizace a zajišťuje kontinuitu provozu. V současnosti by měly být BOM moduly, včetně CBOM, součástí dodávky od renomovaných výrobců. Popis musí zahrnovat možnosti nastavení a ideálně i výchozí konfigurace. Změna konfigurace závisí na správě konkrétního systému; nastavení z výroby nemusí být vždy aplikováno. Možnosti nastavení jsou kritickým faktorem – jejich absence znamená, že organizace musí vytvářet vlastní CBOM seznamy, což zvyšuje nároky na práci.
Dalším krokem je podpora řízení kryptografie podle definované politiky. Centrálně distribuovaná nastavení umožňují jednotnou správu napříč organizací a spolupracujícím vybavením. Snižuje se tím riziko výpadků a komplexnost systému, zároveň se zvyšuje rychlost řízení změn. CBOM je zásadní i při spolupráci více organizací, kde je hledání společných řešení náročné jak znalostně, tak systémově. Moderní prostředí obsahuje desítky až stovky aplikací a tisíce mikroservisů, takže rekonfigurace je technologická i projektová výzva. Bez centralizovaného repozitáře politik by organizace čelily buď vysokým nákladům, nebo neplánovaným výpadkům.
CBOM jako definice vlastností implementace kryptografie obsahuje spoustu, možná i na první pohled nedůležitých vlastností. Je tu seznam vlastností systému, tedy jaké algoritmy a protokoly jsou podporovány. Je tu popis systému, což mohou být definice hardware a firmware, nebo definice použitých knihoven a jejich verzí. Je tu seznam podporovaných generátorů náhodnosti, knihoven pro odvozování tajemství (KDF – Key Derivation Function) a spousta dalších funkcionalit. Zároveň tu je také popis aktuálního stavu. Co je povoleno, jaké algoritmy a délky klíčů jsou k dispozici. Tedy mimo možností systému tu i popis jeho současného nastavení.
Problémem u CBOM je v současnosti hlavně nutnost popisu schopností systému. Získat tyto informace je extrémně náročné a dostupné informace nejsou zcela přesné. Příčinou je nedostatečná spolupráce s dodavateli nebo partnery, nízká úroveň poskytování informací o schopnostech kryptoknihoven a další podobné nešvary. V současnosti zcela minimální počet výrobců nabízí zákazníkům popis vlastností systému ve standardizovaném formátu, což znesnadňuje standardizaci a následnou automatizaci. Někteří dodavatelé nejenom že neposkytují data o podporovaných algoritmech, což činí standardizované řízení kryptoagility obtížným. Často neposkytují ani důkazy správnosti implementace nebo audit kódu, nebo jako alternativu soulad se standardy nebo certifikaci. Přitom důvěra ve správnost a znalost schopností kryptosystému je pro řízení důležité. Co s tím lze provést?
Dle mého názoru je klíčové definovat kritéria pro výběr řešení. Bezpečnost informačních systémů a jeho komponent by měla zahrnovat standardizované přehledy a možnost automatizace změn. Pokud je vyžadována bezpečnost informačních systémů a jeho komponent, kritéria by měla zahrnovat zároveň i odpovídající přehledy a soulady. Stejně tak by mělo být možné zajistit automatizaci uvedených změn dle požadavků ve formě politik. V jiném případě se zákazník vystavuje nebezpečí opakovaných implementací, které dle složitosti znamenají výrazné ekonomické a provozní dopady. Proto mi připadá jako vhodná zpětná vazba odmítnutím produktu, který takové podmínky nesplňuje. To snad dokáže uvedené výrobce odpovídajícím způsobem motivovat. Tento způsob je známý také jako "hlasování nohama".
Přehled problémů v nedávné minulosti:
| Incident | Rok | Kategorie problému | Škála mitigace | Odhad škod (€) |
| Debian RNG | 2006–2008 | slabý RNG | měsíce | 50 000 – 500 000 (náklady na výměnu klíčů a obnovu systémů) |
| Dual_EC_DRBG | 2007–2013 | kompromitovaný RNG | roky | 1–10 mil. € (teoreticky ohroženo miliony systémů) |
| DigiNotar | 2011 | kompromitovaná CA | měsíce | 8–12 mil. € (ztráta důvěry, likvidace CA) |
| Heartbleed | 2014 | implementační bug | měsíce | 1–2 mld. € (patch, obnova TLS klíčů, reputace) |
| SHA-1 migration | 2014–2017 | zastaralý algoritmus | roky | 5–20 mil. € (masivní migrace certifikátů, provozní výpadky) |
| Logjam | 2015 | slabé DH parametry | měsíce | 500 000 – 5 mil. € (teoretické ohrožení 8 % HTTPS serverů) |
| DROWN | 2016 | starý protokol | měsíce | 1–10 mil. € (teoretické ohrožení 33 % serverů) |
| ROCA | 2017 | slabý RSA generátor | měsíce až roky | 100–500 mil. € (smartcards, TPM, kompromitace identit) |
| Marriott Breach | 2018 | řízení certifikátů / dlouhodobá kompromitace | roky | 100–120 mil. € (500 mil. zákazníků, uniklá citlivá data) |
| SolarWinds | 2020 | řízení certifikátů / supply chain | měsíce | 200–500 mil. € (federální agentury, velké firmy) |
| Twitter/X (TLS certifikát) | 2020 | řízení certifikátů / expirace certifikátu | hodiny | 50–200 tis. € (API výpadek) |
| Let’s Encrypt root expiration | 2021 | expirace trust chain | roky | 1–5 mil. € (problémy starších zařízení a IoT) |
| Twitter/X (TLS certifikát) | 2022 | řízení certifikátů / chyba ověřování | hodiny | 50–200 tis. € (provozní výpadky) |
V současnosti by tak podobné chyby dosáhly na přímé náklad zpravidla o řád vyšší. Extrémní příklad by byla chyba podobná HeartBleed. Přímé náklady by byly okolo 10 miliard Eur. Ale nepřímé, způsobené problémy se ztrátou důvěry, dopady na ekonomiku ale i pokutami z hlediska GDPR si ani netroufám odhadovat.
Daleko náročnější pro přijetí je výsledek následujícího přehledu doby migrací technologií. U většiny algoritmů je doba pro odstranění nikoliv v řádu dnů až týdnů, ale překvapivě 10–15 let. Pokud vezmu v úvahu možné dopady, jedná se o silný argument pro crypto-agility architekturu.
| Název | Rok (oznámení – dokončení) | Kategorie problému | Škála mitigace | Odhad dopadů (€) |
| Ukončení podpory SSL 2.0 | 1996–2011 | zastaralý protokol | roky | ~200–500 mil. € |
| Ukončení podpory SSL 3.0 | 2014–2015 | zranitelný protokol (POODLE) | měsíce až roky | ~500 mil. – 1 mld. € |
| Ukončení podpory TLS 1.0 | 2016–2021 | zastaralý protokol | roky | ~1–2 mld. € |
| Ukončení podpory TLS 1.1 | 2016–2021 | zastaralý protokol | roky | ~500 mil. – 1 mld. € |
| Ukončení podpory DTLS 1.0 | 2015–2022 | zastaralý protokol | roky | ~100–300 mil. € |
| Zranitelnost RC4 | 2001–2016* | slabý kryptografický algoritmus | roky | ~1–3 mld. € |
| Zranitelnost DualEC DRBG | 2007–2014 | kompromitovaný RNG | roky | ~100–500 mil. € |
| Zranitelnost MD5 | 2004–2012 | kolizní hash funkce | roky | ~500 mil. – 1 mld. € |
| Ukončení podpory DES | 1998–2005** | slabý symetrický algoritmus | roky | ~200–500 mil. € |
| Ukončení podpory 3DES | 2016–2023** | zastaralý symetrický algoritmus | roky | ~500 mil. – 1.5 mld. € |
| SHA-2-224 (omezené použití) | 2001–současnost | hash funkce s omezeným použitím | roky | ~50–100 mil. € |
| Ostatní blokové šifry s 64bit blokem (CAST5/CAST128, Blowfish, IDEA aj.) | 2016–2023 | zastaralé blokové šifry (64bit block, Sweet32) | roky | ~200–600 mil. € |
* je v roce 2026 stále ještě podporovanou součástí Microsoft Active Directory
** migrace ještě stále není dokončena (TLS ciphersuite, SSH, IPSec ...)
Závěrem lze říci následující a není to moc potěšující zpráva:
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“).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.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.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.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.6. Reklamace
6.1. Pokud je účastník hrubě nespokojen s průběhem kurzu, je školitel o této informaci vyrozuměn.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.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.9. Platnost podmínek
9.1 Tyto všeobecné obchodní podmínky jsou platné a účinné od 1. října 2024.Informace o sběru a zpravování osobních údajů
Zpracovatel Jan Dušátko (dále jen „Správce“), dle nařízení Evropského parlamentu a Rady (EU) č. 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů, dále jen „Nařízení“) zpracovává osobní údaje. Dále jsou rozepsané jednotlivé osobní údaje, které jsou součástí zpracování při konkrétních aktivitách u této webové prezentace a v rámci obchodního styku.Informace o záznamech přístupu na webovou prezentaci
Tento web nesbírá žádné cookies. Stránka nepoužívá ani žádné analytické scripty třetích stran (sociální sítě, cloud provideři). Z těchto důvodů je také nabízena volba pro zobrazení mapy formou odkazu, kde primárním zdrojem je OpenStreet a alternativy pak často používané Mapy společnosti Seznam, a.s., případně Google Maps společnosti Google LLC Inc. Využití jakéhokoliv z těchto zdrojů je zcela na libovůli uživatelů těchto stránek. Správce nenese odpovědnost za sběr dat realizovaný těmito společnostmi, neposkytuje jim data o uživatelích a na sběru dat nespolupracuje.Informace o kontaktování provozovatele stránek
Formulář pro kontaktování provozovatele stránek (správce) obsahuje následující osobní údaje: jméno, příjmení, e-mail. Tyto údaje jsou určeny jen a pouze pro tuto komunikaci, odpovídající oslovení uživatele a jsou udržovány po dobu nezbytnou k naplnění účelu, maximálně pak po dobu jednoho roku, pokud si uživatel neurčí jinak.Informace o objednávkovém formuláři
Pro případ zájmu o objednávku formulář obsahuje více údajů, tj. jméno, příjmení, e-mail a kontaktní údaje na organizaci. Tyto údaje jsou určeny jen a pouze pro tuto komunikaci, odpovídající oslovení uživatele a jsou udržovány po dobu jednoho roku, pokud si uživatel neurčí jinak. V případě, kdy na základě této objednávky dojde k uzavření obchodního vztahu, budou nadále správcem udržovány pouze informace vyžadované českými zákony na základě obchodních vztahů (název a adresa společnosti, číslo bankovního účtu, typ kurzu a jeho cena).Informace o dokumentu o absolovování kurzu
V rámci kurzu je vydán zpracovatelem dokument o absolovování kurzu. Tento dokument obsahuje následující údaje: jméno a příjmení studenta, název a datum absolovování kurzu a jméno zaměstnavatele. Uvedené informace se následně používají pro tvorbu lineárního stromu hashí (nemodifikovatelný záznam). Tato databáze obsahuje pouze informace o poskytnutých jménech a názvech společností, které mohou a a nemusí odpovídat realitě a je udržován zpracovatelem pro případné opětovné vystavení nebo ověření vydání dokumentu.Práva subjektu osobních údajů
Zákazník nebo návštěvník tohoto webu má možnost požádat o informace o zpracování osobních údajů, právo požadovat přístup k osobním údajům, případně právo požádat o opravu nebo výmaz veškerých dat, které by o něm byly vedeny. V případě výmazu tento požadavek není možné splnit pouze pokud se nejedná o data nezbytně nutná v rámci obchodního styku. Zákazník nebo návštěvník webu má dále právo na vysvětlení týkající se zpracování jeho osobních údajů, pokud tento zjistí nebo se domnívá, že zpracování je prováděno v rozporu s ochranou jeho soukromého a osobního života nebo v rozporu s platnými právními předpisy a právo požadovat odstranění takto vzniklého stavu a zajištění nápravy.