Životní cyklus

Kryptografický klíč nevzniká jednou a potom už pouze „existuje“. Od okamžiku jeho vytvoření až po jeho zneplatnění nebo zničení prochází řadou stavů a operací. Každý z těchto kroků může ovlivnit bezpečnost celého systému.
Klíčový materiál přitom není určen pouze pro elektronický podpis. Může být používán pro šifrování, autentizaci, ochranu komunikačních kanálů, odvozování dalších klíčů nebo jiné kryptografické operace. Způsob řízení životního cyklu proto musí vycházet z konkrétního účelu klíče a z důsledků jeho kompromitace. V předchozích částech jsme se věnovali klasifikaci, účelu a oprávněním. Životní cyklus na tato témata přímo navazuje: určuje, co se s klíčem děje v čase, kdo jednotlivé změny smí provést a jak lze jejich provedení doložit.

Stavy a fáze životního cyklu

Životní cyklus je vhodné chápat jako řízenou posloupnost stavů. Konkrétní názvy se mohou mezi systémy lišit, ale typicky lze rozlišit například:

• plánování a registraci klíče,
• generování nebo import klíčového materiálu,
• aktivaci,
• používání,
• případné pozastavení,
• obnovu nebo rotaci,
• kompromitaci a zneplatnění,
• archivaci,
• bezpečné zničení.

Ne každý klíč musí projít všemi uvedenými stavy. Například veřejný klíč může být dlouhodobě používán k ověřování historických podpisů, zatímco soukromý podpisový klíč může být po ukončení používání zneplatněn a zničen. U šifrovacích klíčů může být naopak nutné zachovat možnost obnovy nebo dešifrování historických dat.
Podstatné proto není vytvořit univerzální seznam stavů, ale stanovit povolené přechody mezi stavy a pravidla pro jejich provedení. Změna stavu by měla být autorizovaná a auditovatelná.

Evidence životního cyklu

Součástí řízení životního cyklu musí být odpovídající evidence. Neznamená to, že organizace musí evidovat samotný obsah privátního klíče. U soukromého klíčového materiálu by jeho zpřístupnění běžnému evidenčnímu systému mohlo být naopak bezpečnostním problémem. Evidována by měla být především metadata, například:

• jednoznačný identifikátor klíče,
• účel a typ klíče,
• vlastník nebo odpovědný subjekt,
• systém nebo služba, ve které je klíč používán,
• stav klíče,
• datum vytvoření a případně aktivace,
• období plánovaného použití,
• vazba na certifikát nebo veřejný klíč,
• informace o rotaci, zneplatnění nebo archivaci,
• informace potřebné pro audit.

Taková evidence umožňuje zjistit, jaké klíče organizace má, k čemu slouží a v jakém jsou stavu, aniž by samotná evidence musela obsahovat jejich tajný materiál.

Generování klíčového materiálu

Generování patří mezi nejcitlivější fáze životního cyklu. Bezpečnost výsledného klíče nezávisí pouze na velikosti prostoru možných klíčů, ale také na kvalitě zdroje náhodnosti, správné inicializaci generátoru a správné implementaci kryptografických mechanismů.
Pokud je zdroj entropie předvídatelný nebo nedostatečný, může být výsledný klíč předvídatelný nebo může pocházet z výrazně menší množiny hodnot, než předpokládá použitý algoritmus. Problém tedy nemusí být v samotném kryptografickém algoritmu, ale v jeho implementaci nebo v prostředí, ve kterém je používán.
Je proto užitečné rozlišovat dvě tvrzení:

• pravděpodobnost náhodné kolize dvou kvalitně vygenerovaných klíčů je při správných parametrech prakticky zanedbatelná;
• proces generování klíčů je bezpečný pouze tehdy, pokud je bezpečný celý mechanismus získání entropie, inicializace a generování.

Praktickým problémem proto obvykle není samotný počet vytvořených klíčů. Podstatnější je, zda jsou klíče skutečně generovány kryptograficky bezpečným způsobem a zda nedochází k opakovanému nebo předvídatelnému generování.
U citlivých klíčů může být vhodné generovat klíč přímo v zabezpečeném prostředí, například v HSM, aby nebylo nutné soukromý klíč následně přenášet do běžného operačního systému.

Jedinečnost klíčů

Jedinečnost je důležitá zejména u klíčů, jejichž použití musí být jednoznačně spojeno s konkrétním subjektem nebo službou. U osobních podpisových klíčů je sdílení stejného soukromého klíče mezi více osobami zásadním problémem. Pokud více subjektů disponuje stejným klíčem, nelze pouze z kryptografického podpisu určit, který z nich operaci skutečně provedl. Tím se oslabuje možnost prokázat výhradní kontrolu konkrétního držitele nad klíčem.
U jiných typů klíčů může být situace odlišná. Například některé systémové nebo skupinové služby mohou záměrně používat jeden klíč v rámci přesně definovaného technického účelu. Ani zde však nejde pouze o otázku technické jedinečnosti. Je potřeba vědět, kdo může klíč použít a jaké následky by mělo jeho zneužití.
Jedinečnost klíče je tedy potřeba chápat v kontextu jeho identity, účelu a oprávnění, nikoli pouze jako požadavek, aby se dvě náhodně generované hodnoty matematicky neshodovaly.

Aktivace a používání

Po vytvoření nemusí být klíč automaticky připraven k použití. V některých systémech je mezi generováním a aktivací samostatný proces, při kterém se ověřuje účel klíče, jeho vazba na identitu nebo službu a oprávnění k jeho použití. Toto oddělení je užitečné zejména tam, kde je klíč vytvořen automatizovaně, ale jeho použití vyžaduje schválení nebo další kontrolu. Aktivace by proto měla být evidována stejně jako další významné změny stavu.
Během používání je potřeba sledovat nejen počet kryptografických operací, ale především kdo nebo co může použití klíče iniciovat a zda klíč opouští zabezpečené prostředí. Miliony operací provedených přímo v HSM nemusí znamenat stejný typ rizika jako jediný export soukromého klíče do nezabezpečeného prostředí.

Ochrana klíčového materiálu

Ochrana klíčového materiálu může mít několik úrovní. Jednoduchým příkladem je řízení přístupu prostřednictvím ACL (Access Control List), kdy je soubor s klíčem dostupný pouze určitému uživateli nebo procesu. To však chrání především na úrovni operačního systému. Pokud útočník získá dostatečná oprávnění k systému nebo kompromituje proces pracující s klíčem, samotné ACL nemusí stačit.
Další možností je uložení klíče v zašifrované podobě. Tím se omezuje riziko při kompromitaci samotného úložiště, ale vzniká další otázka: kde a jak je klíč dešifrován a jak dlouho je potom dostupný v paměti systému.
Vyšší úroveň ochrany mohou poskytovat specializované prostředky, například HSM nebo KMS. U HSM je podstatnou vlastností možnost provádět kryptografické operace přímo v zařízení bez nutnosti exportovat soukromý klíč do běžného operačního systému. KMS zase poskytuje centralizované řízení klíčů, jejich životního cyklu a přístupových pravidel.
HSM ani KMS však nejsou samostatným řešením správy klíčů. I zde je nutné řešit autentizaci a oprávnění administrátorů, audit, konfiguraci, zálohování a obnovu, dostupnost a ukončení životního cyklu.
U cloudového KMS nebo HSM je navíc potřeba posoudit rozdělení odpovědností mezi organizaci a poskytovatele. Technická ochrana klíče je pouze jednou částí rozhodnutí. Důležitá je také auditovatelnost, možnosti administrace, zálohování a obnova, dostupnost služby, závislost na poskytovateli a postup při ukončení služby.

Zálohování a obnova

Záloha klíčového materiálu není pouze otázkou dostupnosti. Vytváří další kopii tajemství, kterou je nutné chránit. U šifrovacích klíčů může být záloha nezbytná pro obnovu přístupu k historickým datům. Ztráta jediného klíče může v takovém případě znamenat ztrátu přístupu k velkému množství informací.
U osobních podpisových klíčů je situace odlišná. Kopie soukromého klíče může narušit požadavek na výhradní kontrolu držitele a její existence proto musí být posuzována podle účelu klíče a příslušných požadavků na daný typ podpisu. Důležitá proto není pouze otázka „zálohovat, nebo nezálohovat“, ale také:

• kdo smí zálohu vytvořit,
• kde je uložena,
• kdo ji může obnovit,
• za jakých podmínek lze obnovu schválit,
• jak je obnova auditována,
• a jak je chráněna samotná záloha.

Rotace a obnova klíče

Klíč nemusí být používán po celou dobu své existence. Organizace může stanovit maximální dobu jeho aktivního používání, případně jiná kritéria pro jeho nahrazení. Nový klíč pak převezme jeho úlohu a starý klíč přejde do jiného stavu.
Důvodem rotace může být například změna bezpečnostních požadavků, plánovaná obnova, změna systému nebo reakce na kompromitaci. U některých systémů lze rotaci provádět automatizovaně, jinde může být nutný řízený proces s explicitním schválením.
Je přitom důležité rozlišovat ukončení používání klíče a zničení klíče. Například podpisový klíč může přestat být používán pro nové podpisy, ale veřejný klíč, certifikát a další informace mohou být potřebné pro ověřování historických podpisů.
Stejně tak u šifrovacích klíčů může být nutné zachovat starý klíč pro dešifrování historických dat, i když už není povoleno jeho použití pro nové šifrovací operace.

Kompromitace a zneplatnění

Zvláštní stav představuje kompromitace nebo důvodné podezření na kompromitaci. Pokud existuje možnost, že se soukromý nebo tajný klíč dostal k neoprávněné osobě, musí být možné jeho použití rychle omezit nebo zastavit. Postup by měl zahrnovat alespoň:

1. identifikaci podezření na kompromitaci,
2. omezení nebo zastavení používání klíče,
3. posouzení rozsahu možného dopadu,
4. zneplatnění nebo jinou změnu stavu klíče,
5. případné vytvoření a aktivaci náhradního klíče,
6. uchování informací potřebných pro následný audit a vyhodnocení dopadu.

U podpisových klíčů je situace specifická tím, že kompromitace neznamená pouze problém pro budoucí operace. Je potřeba posoudit také podpisy vytvořené před zjištěním kompromitace a zachovat informace potřebné k jejich ověření a vyhodnocení.

Archivace a likvidace

Ukončení aktivního používání nemusí znamenat okamžité zničení veškerého materiálu souvisejícího s klíčem. Organizace může potřebovat zachovat veřejný klíč, certifikát, informace o jeho platnosti nebo další důkazní údaje. Naopak samotný soukromý nebo tajný klíč by měl být po skončení potřebné doby bezpečně zničen, pokud již není důvod jej uchovávat. Cílem je zabránit tomu, aby starý klíč zůstal skrytě použitelný v nějakém systému nebo záloze.
Likvidace proto musí zahrnovat nejen primární úložiště, ale podle architektury také záložní kopie, exporty a další místa, kde se mohl klíčový materiál objevit. U prostředků, které umožňují bezpečné zničení klíče přímo v zařízení, je vhodné využít jejich podporované mechanismy a výsledek operace evidovat.

Četnost použití a doba dostupnosti

Četnost použití klíče je relevantní parametr, ale nelze z ní samostatně odvodit jeho bezpečnostní úroveň. Klíč používaný tisíckrát denně může být bezpečně provozován v HSM, zatímco klíč použitý jednou ročně může být uložen v nevhodném prostředí. Je proto vhodnější sledovat zejména:

• jak často je klíč zpřístupněn mimo zabezpečené úložiště,
• jak dlouho zůstává v operační paměti,
• kdo nebo co může jeho použití iniciovat,
• zda je použití auditováno,
• jaké jsou důsledky kompromitace,
• a jak rychle lze klíč zneplatnit a nahradit.

Stejně tak je vhodné rozlišovat četnost kryptografických operací a četnost zpřístupnění klíčového materiálu. Služba může provádět velké množství podpisových nebo dešifrovacích operací, aniž by privátní klíč opustil HSM. Naopak jediný export klíče do nezabezpečeného prostředí může představovat zásadní bezpečnostní událost.

Závěr

Životní cyklus klíčového materiálu není pouze sled technických operací. Je to řízený proces, který propojuje generování, evidenci, aktivaci, používání, ochranu, případné zálohování a obnovu, rotaci, reakci na kompromitaci, archivaci a nakonec zneplatnění nebo zničení.
Pro každý typ klíče může mít jednotlivá fáze jiný význam. U podpisového klíče je zásadní ochrana výhradní kontroly a možnost zachovat důvěryhodnost historických podpisů. U šifrovacího klíče může být naopak klíčová dlouhodobá dostupnost pro obnovu dat. U autentizačních, pečetících nebo TSA klíčů se zase mění rozsah následků podle identity nebo služby, kterou klíč reprezentuje.
Bezpečnost proto nelze posuzovat jedním parametrem. Důležitá je kombinace účelu, oprávnění, způsobu ochrany, doby používání, dostupnosti, možnosti obnovy a pravidel pro ukončení životního cyklu. Jakmile je životní cyklus definován, přichází další praktická otázka: jaké vlastnosti musí mít systém, který klíče skutečně používá, aby jejich ochranu zvládl bez nepřiměřeného dopadu na provoz? Další část série se proto zaměří na latenci a propustnost kryptografických operací.

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.