Latence a propustnost

Při návrhu kryptografického řešení se často objeví jednoduchá zkratka: hardware je rychlejší a bezpečnější než software. Takové tvrzení je ale příliš obecné. Hardware a software mají rozdílné vlastnosti, různé možnosti optimalizace a také jiné náklady na změnu, údržbu a ochranu. Pro rozhodnutí proto nestačí porovnat jednu hodnotu propustnosti. Je potřeba sledovat také latenci, determinismus, spotřebu zdrojů, možnost aktualizace, náklady, odolnost proti chybám a útokům, detekce chyb a útoků a především požadavky konkrétní aplikace.
Navíc se hranice mezi hardwarem a softwarem v praxi stírá. Software může využívat instrukce procesoru určené pro kryptografii, specializovaný akcelerátor nebo jiný hardwarový prostředek. Naopak programovatelný hardware může obsahovat poměrně obecnou logiku. Smysluplnější je proto porovnávat konkrétní architektury než abstraktní kategorie „hardware“ a „software“.

Hardware a software implementace

Mezi hardwarovou a softwarovou implementací kryptografických algoritmů existují rozdíly ve výkonu, latenci, ceně, možnosti aktualizace, způsobu detekce chyb i bezpečnostních vlastnostech. Bez konkrétního měření ale nelze spolehlivě určit, která varianta bude pro daný systém vhodnější.
Výrobci navíc nemusí uvádět všechny parametry potřebné pro skutečné posouzení. Nominální propustnost kryptografického akcelerátoru nemusí odpovídat propustnosti celého systému. Do výsledku mohou vstupovat přenosy mezi pamětí a akcelerátorem, fronty požadavků, synchronizace, síťové rozhraní, operační systém nebo sdílení prostředku více aplikacemi.

Z tabulky nevyplývá univerzální vítěz. Výběr architektury musí vycházet z požadované kombinace výkonu, latence, bezpečnosti, flexibility a životního cyklu.

Propustnost není latence

Propustnost udává množství dat, které je implementace schopna zpracovat za jednotku času. Latence naopak vyjadřuje čas od vzniku požadavku nebo datového bloku do okamžiku, kdy je k dispozici výsledek. Tyto veličiny nejsou zaměnitelné. Paralelizovaná implementace může mít velmi vysokou agregovanou propustnost, ale jednotlivý požadavek může stále vyžadovat relativně dlouhou dobu kvůli inicializaci výpočtu, synchronizaci, přístupu do paměti, čekání na akcelerátor nebo dokončení navazujících operací.
U symetrických algoritmů lze díky hardwarové akceleraci dosahovat vysoké propustnosti, zejména při zpracování velkých bloků nebo více paralelních toků. Operace založené na veřejném klíči, výměně klíčů, digitálním podpisu nebo ověřování podpisů mají jiný výpočetní charakter a jejich latence může být významnější. Při hodnocení proto nestačí sledovat taktovací frekvenci nebo nominální počet kryptografických operací. Výsledek ovlivňuje například:

• počet paralelních výpočetních jednotek,
• šířka datové cesty,
• velikost a hierarchie cache,
• propustnost paměťového subsystému,
• DMA přenosy,
• fronty požadavků,
• přerušení,
• sdílení akcelerátoru,
• synchronizace mezi CPU, akcelerátorem a síťovým rozhraním.

U softwaru se navíc uplatňuje operační systém, plánování vláken, přepínání kontextu, virtualizace nebo další mechanismy, které mohou do latence vnášet proměnlivou složku. Z bezpečnostního hlediska je proto vhodné sledovat nejen průměrnou dobu operace, ale také rozptyl a například horní kvantily latence. Systém s velmi krátkou průměrnou dobou operace může být pro časově kritické použití nevhodný, pokud za určitých okolností vykazuje výrazně delší odezvu.

Datapath a modelový příklad AES

Při návrhu specializovaného kryptografického datapathu lze výkon škálovat změnou šířky datové cesty. Následující hodnoty je ale nutné chápat jako modelový příklad, nikoli jako univerzální benchmark konkrétního ASIC.

Z tabulky je patrné, že širší datapath může snížit počet taktů potřebných pro zpracování bloku. Současně ale roste složitost implementace a není možné z toho přímo odvodit celkovou systémovou latenci. Pokud například uvažujeme modelový akcelerátor pracující na 1 GHz, vychází při uvedených počtech taktů přibližně následující hodnoty:

Tyto hodnoty popisují pouze samotnou kryptografickou operaci v daném modelu. Nezahrnují přenos dat, čekání ve frontě, přístup do paměti, synchronizaci ani ostatní části systému. Proto je nelze zaměňovat za end-to-end latenci.

End-to-end latence

Při vzdáleném řízení nebo zpracování dat je potřeba posuzovat celý řetězec. Pokud se data přenášejí mezi zařízeními, kryptografická ochrana může být provedena před přenosem i po přijetí dat. Při vzdáleném rozhodování se obdobný proces opakuje také v opačném směru. Modelový příklad může vypadat například takto:

1. sběr dat ze senzoru (1,0 µs) – digitalizace (1,0 µs),
2. zpracování (0,2 µs)  – přenos (2,7 µs) – zpracování (0,2 µs),
3. rozhodnutí (1,0 µs),
4. zpracování (0,2 µs)  – přenos (2,7 µs) – zpracování (0,2 µs),
5. akční člen (1,0 µs).

V uvedeném modelu vychází celkové zpoždění přibližně na 11 µs. Pokud příprava dat a kryptografické operace zaberou přibližně 1 µs, tvoří už významnou část časového rozpočtu. To může být důležité například u výkonové elektroniky a měničů, RF/DSP řízení, ultrazvukového snímání, ochranných a spínacích funkcí nebo některých optických a telekomunikačních systémů. Nejde ale pouze o tyto příklady. Stejný princip platí všude tam, kde existuje pevný časový rozpočet a kryptografická ochrana z něj spotřebovává významnou část.
Důležité je, že v takové situaci nemusí být hlavním problémem volba mezi hardwarem a softwarem. Pokud je celý systém příliš pomalý, pouhá optimalizace kryptografické operace nemusí problém vyřešit. Je potřeba posoudit celý časový řetězec.

Determinismus a časový rozpočet

U systémů pracujících s velmi rychlými nebo prudce se měnícími ději nabývá významu také determinismus. Nejde pouze o to, zda kryptografický mechanismus dokončí operaci dostatečně rychle v průměru, ale zda lze s dostatečnou jistotou předpokládat, že ji dokončí v požadovaném časovém intervalu. Každý další krok mezi získáním informace a reakcí systému vytváří vlastní latenci a případně také jitter, tedy časovou nejistotu. Celkovou odezvu lze zjednodušeně chápat jako součet latence snímání, předzpracování, kryptografických operací, komunikace, synchronizace, rozhodovací logiky a fyzické reakce.
U časově kritických systémů může být proto vhodnější mechanismus s předvídatelnou a omezenou latencí než řešení s vyšší průměrnou výkonností, ale výrazně proměnlivou odezvou. To je důležitý rozdíl mezi běžným informačním systémem a řídicím systémem. U běžného systému může být několik milisekund dodatečné latence zanedbatelných. U procesu s velmi krátkým časovým horizontem může stejná latence znamenat, že informace přestane být použitelná ještě před jejím ověřením.
Kryptografická ochrana tak může současně zvyšovat bezpečnost z hlediska důvěrnosti a integrity a vytvářet nárok na část časového rozpočtu systému. Nejde o argument proti kryptografii. Jde o důvod, proč ji posuzovat jako součást celého systému.

Časová hodnota informace

Tento problém souvisí také s klasifikací. Hodnota informace nemusí být konstantní v čase. Některé informace mají vysokou hodnotu pouze před nebo během určité události. Jiné mohou mít dlouhodobou hodnotu pro analýzu, plánování nebo zpětné odvození vlastností systému.
Samotný údaj může být po určité době prakticky bezvýznamný, ale větší množství podobných údajů může umožnit zpětně odvodit vlastnosti procesu, přesnost měření, reakční časy, konstrukční charakteristiky nebo jiné parametry systému. Časová degradace informační hodnoty proto nemusí být monotónní. Bezprostřední hodnota může prudce klesnout, zatímco analytická nebo důkazní hodnota může přetrvávat. Při posuzování ochrany je proto vhodné zohlednit:

• časové okno, ve kterém je informace citlivá,
• rychlost změny její hodnoty,
• možnost zpětné rekonstrukce,
• možnost kombinace s dalšími zdroji,
• požadavky na dlouhodobou důvěrnost nebo důkazní hodnotu.

Z toho vyplývá i pojem časový rozpočet informace. Označíme-li okamžik vzniku informace jako t₀ a nejzazší okamžik, kdy lze na jejím základě účinně jednat, jako tD, potom dostupný časový rozpočet lze přibližně vyjádřit jako:
T_D = t_D - t₀

Do tohoto intervalu se musí vejít nejen kryptografická operace, ale celý řetězec zpracování a reakce. Prakticky tedy nestačí podmínka:
T_(crypto) < T_D; důležitější je zajisti T_(end-to-end) < T_D,
zároveň je vhodné ponechat rezervu pro jitter, ztráty paketů, opakování komunikace, změnu zatížení a další nepředvídané stavy.
Pokud se tato podmínka nesplní, může být kryptografický mechanismus technicky správně implementovaný a přesto neposkytovat praktickou ochranu požadované operace, protože chráněná informace bude dostupná až po okamžiku, kdy ji již nelze účinně využít. V takovém případě je potřeba posuzovat architekturu celého systému: zda lze některé výpočty provést předem, zda lze operace paralelizovat, zda lze oddělit časově kritickou datovou cestu od méně kritického logování nebo zda je možné použít jiný kryptografický kontext s menší režií.

Závěr

Kryptografii proto není vhodné hodnotit pouze podle počtu zpracovaných bitů za sekundu. Pro návrh systému jsou stejně důležité latence, její rozptyl, determinismus a celková end-to-end odezva. Hardware může nabídnout vysokou a předvídatelnou propustnost, ale za cenu vyšší specializace nebo obtížnější aktualizace. Software přináší větší flexibilitu, ale jeho latenci mohou ovlivňovat další vrstvy systému. V praxi navíc často vzniká kombinované řešení, takže hranice mezi oběma přístupy není ostrá.
Rozhodující proto není otázka, zda je hardware nebo software obecně rychlejší. Rozhodující je, zda konkrétní architektura splňuje časový rozpočet dané aplikace při požadované úrovni bezpečnosti a současně poskytuje dostatečnou rezervu pro běžné i výjimečné provozní stavy. Stejně jako u klasifikace je přitom potřeba zohlednit časový rozměr informace. Informace může být kritická pouze po krátkou dobu, ale může mít také dlouhodobou analytickou nebo důkazní hodnotu. Požadavky na kryptografickou ochranu se proto nemají určovat pouze podle objemu dat nebo jejich okamžité citlivosti, ale také podle toho, kdy musí být informace chráněná, jak dlouho musí být chráněná a kdy ještě musí být použitelná.
Tím se dostáváme od samotného výkonu kryptografických operací k otázce, jaké role a prostředky mají v systému jednotlivé části kryptografické infrastruktury. Další část série se proto zaměří na používané role a jejich vztah ke správě klíčového materiálu.

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.