Implementace kryptografického protokolu s využitím mobilní kryptografie

Implementace kryptografického protokolu s využitím mobilní kryptografie Petr Švenda <[email protected]> Fakulta Informatiky Masarykova universita, Brno

Abstrakt Příspěvek se zabývá implementací autentizačního protokolu a protokolu pro výměnu důvěrných dat mezi stranami A a B v situaci s upravenými předpoklady útočníkových možností. Strana A může být v souladu se standardním modelem útočníka ovlivňována pouze prostřednitvím manipulace příchozích a odchozích zpráv protokolu. Předpoklady strany B jsou oslabeny. Předpokládáme, že kroky protokolu strany B jsou prováděny softwarovou aplikací, která je vykonávána ve výpočetním prostředí pod kontrolou útočníka. Dále předpokládáme, že útočník může sledovat vykonávané instrukce procesoru a číst paměť používanou aplikací. Bezpečnost probíhajícího protokolu tak může být narušena nejen analýzou a manipulací vyměňovaných zpráv, ale i manipulací samotného procesu zpracování a vyhodnocení zpráv protokolu stranou vykonávanou v prostředí pod kontrolou útočníka. Cílem příspěvku je využít konceptu mobilní kryptografie [1] pro ochranu kódu aplikace, která provádí vyhodnocení protokolu. Implementace vychází z protokolu ISO9798-2 pro vzájemnou autentizaci sdíleným klíčem symetrické kryptografie a využivá alternativní implementaci šifrovacího algoritmu AES (White-Box Attack Resistant AES, navržená v [2], dále WBACRAES), která umožňuje ukrýt hodnotu používaného klíče a zpracovávaných dat i v případě, že má útočník přístup k průběhu šifrování. Vlastní přínos je v návrhu mechanismů, které umožňují využít možnosti WBACR AES pro implementaci protokolu zajišťujícího autentizaci, důvěrnost a čerstvost dat tak, aby napadení aplikace s touto implementací bylo obtížnější. Jedná se o odstranění nutnosti provádět v průběhu protokolu porovnávací rozhodnutí, které jsou útočníkem snadno modifikovatelná. Je zavedena kontrola čerstvosti přijatých zpráv, která je obtížněji odstranitelná než použití testu na očekávanou hodnotu keksíku. Je navržen postup generování vstupního a výstupního kódování pro WBACRAES použitelný pro CBC režim, který umožňuje hlubší integraci s okolním aplikačním kódem. Kombinací WBACR AES a metody pro tvorbu hashovací funkce z blokového šifrovače je navržena implementace klíčovaného hashovacího algoritmu umožňující utajení hodnoty použitého klíče. Výsledkem je popis protokolu SEAUT (SEcure AUthenticated Transport protokol) včetně jeho doporučené implementace na straně umístěné v potencionálně nebezpečném prostředí.

Klíčová slova:

autentizační protokol, mobilní kryptografie, obfuscation, softwarový agent, WhiteBox Attack Resistant AES.

1

Úvod

Mnoho reálných situací vyžaduje autentizaci a výměnu důvěrných dat mezi stranami, z nichž jedna je vykonávána v prostředí, které je pod kontrolou možného útočníka. Příkladem je využití autonomní softwarové aplikace pro rozhodování a správu přístupu k digitálním objektům v rámci Digital Rights Management [3] ve výpočetním prostředí koncového uživatele. Během rozhodování dochází ke komunikaci mezi aplikací vykonávané na zabezpečeném serveru poskytovatele digitálního objektu a autonomní softwarovou aplikací (dále softwarový agent) na počítači, jehož uživatel disponuje plnými právy pro přístup ke všem jeho výpočetním prostředkům a lze předpokládat, že má zájem na narušení korektnosti běhu softwarového agenta. Pro ochranu vyměňovaných dat má pak význam nejen odolnost protokolu proti útočníkovi s přístupem k vyměňovaným zprávám, ale i způsob implementace zpracování protokolu v kódu softwarového agenta. Dalším příkladem je spolupráce aplikace vykonávané na kryptografické čipové kartě (bezpečné prostředí) komunikující se softwarovým agentem na počítači pod možnou kontrolou útočníka. Provedení funkčnosti (použití podpisového klíče apod.) je vázáno nejen na zadaní správného PINu uživatelem, ale i na autentizaci sofwarového agenta, který data k podpisu zasílá.

Mikulášská kryptobesídka 2004

1

Bezpečnost výpočetního prostředí je ve většině případů relativní vzhledem k prostředkům, které musí útočník vynaložit na její prolomení. Přesto však má toto dělení smysl v případě, že komunikující strany se nacházejí v prostředích s různou úrovní zabezpečení, z nichž jednu pokládáme za dostačující vzhledem k hodnotě zpracovávaných informací (strana A), zatímco druhou nikoli (strana B). Zavádíme následující model útočníkových možností: V souladu s běžnými předpoklady kladenými na kryptografický protokol má útočník přístup ke všem vyměňovaným zprávám mezi stranou A a B. Strana A se vůči útočníkovi jeví jako „černá skříňkaÿ, kterou může ovlivňovat pouze manipulací příchozích a odchozích zpráv. Předpoklady kladené na stranu B jsou však oproti straně A oslabené. Předpokládáme, že útočník může provádět statickou a dynamickou inspekci programového kódu reprezentující stranu B s využitím ladících nástrojů (dissasembler, debugger), čtení a modifikaci kódu nebo dat a podvržení systémových funkcí a další. Pro prostředí tohoto typu přípěvek identifikuje místa snadno napadnutelná útočníkem a s využitím mobilní kryptografie navrhuje modifikace, které by prakticky znemožnily nebo alespoň ztížily napadnutelnost. V následujícím textu bude presentován protokol i jeho doporučená implementace na straně B s ohledem na specifické prostředí, ve kterém se nachází. Na implementaci zpracování protokolu na straně A nejsou kladeny žádné dodatečné požadavky, neboť se nepředpokládá, že útočník bude mít k průběžným hodnotám přístup. Například použité šifrovací klíče mohou být representovány polem s otevřenou hodnotou a podobně. Důležitím prvkem je nezávislost softwarového agenta na jeho uživateli. Softwarový agent si sám nese svoje autentizační informace a v průběhu protokolu nekomunikuje s uživatelem, v jehož prostředí je spuštěn. Cílem je naopak autentizační informace softwarového agenta před uživatelem utajit resp. zajistit jejich integritu tak, aby je uživatel nebo zlovolný software na uživatelově počítači nemohl využít ve vlastní režii. Vycházíme z předpokladu, že WBACR AES (viz 3 umístěný v kódu softwarového agenta poskytuje dostatatečnou ochranu používané hodnotě klíče, nechrání však další hodnoty používané v průběhu protokolu. Mezi tyto hodnoty patří příznak o výsledku proběhlé autentizace, hodnoty keksíku pro zajištění čerstvosti a měnící se hodnota klíče relace, který nemůže být implementován formou WBACR AES. Navržená implementace protokolu nezajišťuje absolutní odolnost proti útočníkovi, měla by však zvýšit množství nutných změn v kódu pro úspěšný útok. Více změn vyžaduje více útočníkova času a zvyšuje pravděpodobnost, že dojde k detekci změny doplňkovými integritním mechanismy (například [5, 6]) pokud jsou použity. Dělení textu je následující: Kapitola 2 uvádí funkční požadavky kladené na hledaný protokol a stanovuje vlastnosti, které by měla mít jeho vhodná implementace straně B. V kapitole 3 jsou shrnuty základní vlastnosti implementace šifrovacího algoritmu AES navržené v [2]. Kapitola 4 popisuje autentizační a transportní protokol navržený pro bezpečnou komunikaci mezi stranou umístěnou v bezpečném prostředí (chráněný server, kryptografická čipová karta) a stranou umístěnou ve výpočetním prostředí pod potenciální kontrolou útočníka (softwarový agent). V kapitole 5 jsou podrobněji rozebrány stavební prvky použité pro implementaci tohoto protokolu na straně B.

2

Požadované vlastnosti protokolu

Pro potřeby komunikace mezi stranami A a B byly stanoveny požadavky na vhodný protokol tak, aby zajišťoval vzájemnou autentizaci komunikujících stran i autentizaci, utajení a čerstvost vyměňovaných dat. Tyto požadavky odpovídají potřebám pro komunikaci typu klient/server. Nejprve je provedena (vzájemná) autentizace, na základě které se server rozhoduje, zda umožní klientovi přístup ke svým zdrojům. Klient se ujistí, že komunukuje s požadovaným serverem. Následně klient zasílá požadavky serveru, který po zpracování zasílá zpět odpověď. Pokud bychom předpokládali, že útočník má možnost ovlivňovat komunikující strany A a B pouze manipulací vyměňovaných zpráv, pak existuje široké spektrum kryptografických protokolů, které výše uvedené požadavky splňují. Pro autentizaci lze využít protokolů typu výzva-odpověď založených na symetrické nebo asymetrické kryptografii. Autentizaci dat lze zajistit digitálním podepisováním nebo přidáním autentizačního kódu zprávy (MAC). Utajení dat lze dosáhnout šifrováním, čerstvosti použitím „keksíkůÿ na bázi čítače, náhodného čísla nebo časového razítka. Oslabení předpokladů kladených na stranu B tak, že útočník může navíc pozorovat/modifikovat prováděné operace na úrovni instrukcí procesoru a kontrolovat využívanou paměť ukazuje, že implementace zvoleného protokolu běžným způsobem nepostačuje, pokud nejsou explicitně nechráněné hodnoty používaných klíčů a integrit procesu zpracování vstupních a výstupních zpráv protokolu. Útočník může provést tyto základní kategorie útoků: 2


• Odhalení citlivých dat – Pomocí disassembleru je lokalizováno přibližné místo použití, pomocí debuggeru během dynamické inspekce je z oprační paměti přečtena otevřená hodnota. Typicky jde o autentizační informace a hodnoty šifrovacích klíčů. Obranou je práce s citlivými daty D tak, aby nebyla nikdy přístupná v paměti v otevřené podobě, ale pouze v tvaru GIOC (D) transformovaném pomocí funkce GIOC , kde GIOC není známa útočníkovi. Je nutné příslušně upravit operace, které s takto transformovanými daty manipulují. Lze použít technik mobilní kryptografie známých jako počítání se šifrovanými daty a počítání se šifrovanou funkcí[1]. Implementace navrženého protokolu takto pracuje s hodnotami autentizačních klíčů (viz 3), hodnotou klíče relace (viz 5.3) a daty určenými k zašifrování (viz 5.1). • Modifikace vyhodnocení průběhu protokolu - Cílem útočníka je úprava kódu vyhodnocující vyměňované zprávy tak, aby byl porušen některý z výše uvedených cílů protokolu, například autentizace strany, která ve skutečnosti nezná autentizační informace nebo zpracování příchozí zprávy jako čerstvé, přestože jde o opakovaně zaslanou zprávu. Modifikována mohou být dlouhodobě nesená data softwarového agenta, například veřejný klíč PA je nahrazen klíčem PA0 , ke kterému útočník vlastní privátní klíč SA0 . Modifikována mohou být průběžná data jako pořadový čítač zpráv nebo příznak udávající stav autentizace. Modifikovány mohou být instrukce kódu, typicky instrukce porovnání (vůči očekávané hodnotě) a přiřazení (výsledku autentizace). Navržená implementace protokolu nevyžaduje porovnávací operace v autentizační části (viz 4.1). Nahrazení hodnot klíčů je ztíženo použitím vstupního a výstupního kódování WBACR AES tabulek (viz 3). • Využití části kódu ve vlastní režii - Útočník lokalizuje v kódu softwarového agenta strany B úsek, ve kterém dochází k aplikaci funkce f na data D, například aplikace autentizačních informací na autentizační výzvu. Úsek vyjme a nahrazením vstupních dat D se autentizuje vůči straně A ve vlastní režii. Útočník je tak schopen vytvářet korektní odpovědi i bez znalosti obsažené funkce f . Typickým cílem v tomto kontextu jsou autentizační funkce a funkce pro šifrování/dešifrování vyměňovaných dat. Navržená implementace ztěžuje extrakci kódu zavedením vstupního a výstupního kódování pro WBACR AES tabulku použitelné v CBC režimu (viz 5.1) a zavedením „směrovýchÿ klíčů (viz 4.1). Vhodná implementace (zvoleného protokolu) by proto měla splňovat následující podmínky: • Strana B neprovádí žádné porovnávací operace vzhledem k očekávaným hodnotám. • Autentizační informace strany B a informace sloužící k utajení vyměňovaných dat nejsou čitelné při použití statické (disassembler) a dynamické (debugger) inspekce. • Strana B explicitně zajišťuje integritu keksíku používaného pro kontrolu čerstvosti. • Strana B neobsahuje funkci generující zprávy zaměnitelné za zprávy pocházející od strany A, a to ani v případě, že útočník manipuluje se vstupními daty této funkce.

3

White-Box Attack Resistant AES

Pro ochranu kódu a dat vykonávaných ve výpočetním prostředí pod kontrolou útočníka lze využít konceptu mobilní kryptografie [1], který umožňuje provést implementaci některých tříd funkcí1 tak, že je výpočetně obtížné získat hodnotu použitých dat i v případě, že má útočník možnost monitorovat vykonávané instrukce procesoru. Tato myšlenka je využita pro implementaci šifrovacího algoritmu AES [7] navržené v [2] (dále WBACR AES). Umožňuje šifrovat v prostředí pod kontrolou útočníka tak, aby zisk používané hodnoty klíče byl výpočetně obtížný. Konkrétní implementace WBACR AES může šifrovat pouze jednou, předem danou hodnotou klíče K. Na základě hodnoty K jsou vygenerovány tabulky o celkové velikosti 600KB (šifrovací i dešifrovací směr) s předpočtenými hodnotami odpovídajícími použití klíče K. Tabulky jsou dvojího typu. První typ provádí operace AddRoundKey(), SubByte() a část MixColumn() v rámci jedné rundy. Druhý typ dokončuje operaci MixColumn(). Hodnota expadovaného klíče K se v průběhu rund liší. Proto jsou pro každou z 10-ti rund přítomny odlišné tabulky. Vstupní data jsou transformována pouze prostřednictvím série operací „náhleduÿ do těchto tabulek na základě aktuální hodnoty x části vstupu. Operace „náhleduÿ do předpočtené tabulky pro operaci f se rozumí nahrazeni hodnoty x 1V

současné době polynomiální a racionální funkce.


3

hodnotou x0 = f (x), která se nachází na x-tém řádku tabulky. Po posledním náhledu je vstupní blok zašifrován klíčem, který byl použit pro generování tabulek. Průběžné hodnoty x a x0 mezi jednotlivými náhledy jsou přístupné útočníkovi. Ze znalosti hodnot x a x0 lze dedukovat informace o funkci f . Pro ztížení dedukce je využito vstupního a výstupního kódování (dále IOC). Během generování tabulky pro funkci f je zvolena náhodná bijekce GIOC a spočtena její inverze G−1 IOC . Na x-tý řádek předpočtené tabulky pro f je namísto hodnoty f (x) umístěna hodnota GIOC (f (x)). Výsledkem náhledu tak není přímo f (x), ale GIOC (f (x)). Mějme nyní funkci g, která je aplikována na výsledek funkce f a kterou chceme realizovat taktéž předpočtenou tabulkou. Na řádek y-tý řádek tabulky pro funkci g umístíme hodnotu g(G−1 IOC (y)). Složením získáme platnost následující rovnice: g(f (x)) = g(G−1 (G (f (x))). V tomto příkladě je bijekce G výstupním kódováním tabulky IOC IOC pro funkci f a inverze G−1 vstupním kódováním tabulky pro funkci g. Tabulka pro f nemá vstupní IOC kódování2 a tabulka pro g nemá výstupní kódování. Je zřejmé, že IOC lze snadno rozšířit na libovolné množství po sobě jdoucích funkcí.

3.1

Výhody a nevýhody

Šifrování využívající WBACR AES má oproti standardní implementaci několik předností: 1. Utajení hodnoty použitého klíče – zpětný zisk hodnoty klíče je výpočetně obtížný i při znalosti vygenerovaných tabulek. Otevřená hodnota průběžných výsledků během série náhledů je přítomna pouze v transformovaném tvaru pomocí IOC. 2. Oddělitelná šifrovací a dešifrovací funkčnost – vygenerované tabulky pro šifrování a dešifrování jsou navzájem nezávislé. Lze zavést analogii asymetrické kryptografie. Šifrovací část tabulek pro klíč K je použita jako „privátní klíčÿ, dešifrovací část slouží jako „veřejnýÿ klíč distribuovaný ostatním aplikacím. Proces vytváření digitálního podpisu zprávy je nahrazen časově méně náročnou tvorbou autentizačního kódu (MAC). Podrobnější srovnání s asymetrickou kryptografií a výhod tohoto řešení je uvedeno v 6.2. 3. Vstupní a výstupní kódování – vstupním kódováním je myšlena bijektivní transformace GIOC vstupního bloku dat, která je v rámci náhledů do předpočtených tabulek pro první rundu pomocí inverzní transformace G−1 IOC (zahrnuté v tabulkách) odstraněna. Transformace GIOC je volena náhodně během generování tabulek. Před začátkem šifrování musí být data přítomna v transformovaném tvaru pomocí GIOC , jinak je výsledek šifrování chybný. Analogicky pro výstupní kódování aplikované v rámci náhledů poslední rundy, které je nutno před použitím výstupních dat inverzní transformací G−1 IOC odstranit. Použití vstupního anebo výstupního kódování ztěžuje možnost samostatného použití tabulek extrahovaných z kódu softwarového agenta. Útočník musí získat i předpis použité bijektivní transformace F , což zvyšuje celkovou provázanost kódu. Zároveň je poskytnut základ pro „napojeníÿ dalších operací ve stylu mobilní kryptografie. Nevýhodou použití může být naopak větší velikost implementace (cca 600kB předpočtených tabulek pro šifrování i dešifrování daným klíčem) a nemožnost dynamické změny hodnoty klíče po vygenerování tabulek. Je vhodné poznamenat, že předpočtené tabulky mohou být používaný jako „šifrovací strojÿ i bez znalosti obsaženého klíče, proto je vhodné doplňkovými nástroji typu obfuscation 3 [10] zvýšit obtížnost jejich extrakce.

3.2

Bezpečnost

Bezpečnost šifrování pomocí WBACR AES je vhodné zvážit ve třech základních kategoriích a dále dle konkrétního způsobu použití. První kategorií je bezpečnost zašifrovaných dat pomocí WBACR AES proti útočníkovi, který nevlastní WBACR AES tabulky ani klíč použitý k jejich generování. V tomto případě je bezpečnost ekvivalentní standardní implementaci algoritmu AES se 128bitovým klíčem a 128bitovým blokem. WBACR AES je pouze variantou implementace algoritmu AES, nikoli novým algoritmem. Druhou kategorií je situace, kdy jsou WBACR AES tabulky umístěné v kódu softwarového agenta a útočník se je snaží extrahovat. Zde bude bezpečnost závislá na použitém typu obfuscation transformací, 2 Resp.

identitní: ∀x : GIOC (x) = x invariantní transformace kódu a dat, která ztěžuje zpětnou rekonstrukci funkčnosti kódu a zisk hodnoty

3 Sémanticky

dat.

4


obecně však lze říci, že vzhledem k velikosti tabulek a omezení operací pouze na náhledy do tabulek, bude obfuscation poměrně dobře proveditelná. Extrahované tabulky může útočník použít jako šifrovací stroj bez znalosti šifrovacího klíče. Toto použití lze ztížit zavedením vstupního a výstupního kódování. Třetí kategorií je případ, kdy se již útočníkovi podařilo tabulky extrahovat a jeho cílem je zisk hodnoty klíče, který byl použit pro jejich generování. V současné době není znám žádný výpočetně proveditelný útok, který by umožnil odstranit interní kódování a vedl tak ke kompromitaci hodnoty uchovávaného klíče. Bližší rozbor bezpečnosti WBACR AES lze nalézt v [2]. Možným ohrožením by mohlo být využití varianty diferenciální chybové analýzy presentované v [13] v případě, že není použito vstupního ani výstupního kódování. Konkrétní aplikace tohoto typu útoku je předmětem dalšího studia.

4

SEcure AUthenticated Transport protokol

Stranu umístěnou v bezpečném prostředí označme A, stranu umístěnou v prostředí pod možnou kontrolou útočníka (softwarový agent) označme B. Navržený protokol SEAUT se skládá ze dvou částí, autentizační a transportní.

4.1

Autentizační část

Autentizační část navrženého protokolu je založena na 3-průchodovém protokolu ISO9798-2 (dále P3ISO9798-2) pro vzájemnou autentizaci [11]. Je použito následující značení: idA resp. idB jednoznačná identifikace strany A resp. B; NA resp. NB kryptograficky náhodné číslo generované stranou A resp. B; EKXY (data) operace šifrování dat pomocí klíče KXY ; V (X) hodnota proměnné obsahující uloženou hodnotu X; HKx (data) operace jednosměrné klíčované hashovací funkce nad daty s použitým klíčem Kx . KR0 iniciální hodnota klíče KR . Vyměňované zprávy (autentizační část): 1. A ← B : {idB , NB }. 2. A → B : {idA , EKDauth (NA , NB , idB )}. 3. A ← B : {EKEauth (NB , NA )}. 4. KR0 = HK1 (NA |NB |idB |V (NB )|V (idB )) Protokol SEAUT používá klíče KEauth a KDauth na místo jednoho klíče protokolu P3-ISO9798-2. Pro šifrování 2. zprávy je použit klíč KDauth , pro 3. zprávu KEauth . Lze snadno nahlédnout, že strana B využívá klíč KEauth pouze pro zašifrování a klíč KDauth pouze pro dešifrování (opačně pro stranu A). Cílem této úpravy je zajistit, aby na straně B nemusela být přítomna funkčnost pro dešifrování klíčem KEauth . Klíč KEauth tak může být na straně B realizován pouze šifrovací částí WBACR AES tabulek (viz 3). Analogicky pro klíč KDauth . Další modifikací je způsob vyhodnocení korektnosti provedené autentizace na straně B. Kontrola shody keksíku NB a identifikace idB vůči očekávaným hodnotám V (NB ) a V (idB ) z 1. a 2. zprávy je prováděna jen nepovinně, neboť ji útočník může snadno modifikovat nebo odstranit. Namísto toho je ze zaslaných i obdržených hodnot pomocí jednosměrné klíčované hashovací funkce HK1 (viz 5.3) vytvořena iniciální hodnota klíče relace KR0 (číselný index u klíčeKR je zaveden z důvodu pravidelné změny hodnoty KR , viz. 4.2 ). Klíč relace KR bude ustanoven i v případě nekorektní autentizace strany A vůči straně B, bude však odlišný od klíče vzešlého z korektní autentizace. Použití klíčované hashovací funkce (s využitím WBACR AES) pro jeho tvorbu zabraňuje útočníkovi odvodit jeho přímou hodnotu. Vzhledem ke způsobu použití KR v transportní části pak nekorektní KR povede chybnému zpracování vyměňovaných zpráv v případě, že útočník použije zprávy zachycené během předchozí (korektní) komunikace mezi A a B. Vzhledem k dlouhodobému využívání klíčů KEauth a KDauth je vhodné pro ochranu před útoky využívající nenáhodný inicializační vektor pro CBC režim použít techniku ignorování prvního bloku. Před data určená k zašifrování je přidán blok náhodných dat, který je po dešifrování odstraněn.

4.2

Transportní část

Transportní část protokolu zajišťuje důvěrnost a čerstvost vyměňovaných zpráv. K zachování důvěrnosti je využita dvojice šifrovacích klíčů KEtrans a KDtrans , realizovaných a používaných obdobně jako klíče KEauth a KDauth v autentizační části. Pokud strana B pomocí klíče KDtrans korektně dešifruje příchozí zprávu, může si být jista, že pochází od strany A, neboť sama nedisponuje funkčností pro zašifrování


5

tímto klíčem a útočník ji tak nemůže zneužít pro vytvoření podvržené zprávy. Ze stejného důvodu je chráněn před útočníkem obsah zachycených zpráv určených pro stranu A, neboť B nedisponuje funkčností pro jejich dešifrování. Index i u hodnoty KRi označuje stav klíče KR po jeho i − t aktualizaci. XKR (data) značí operace XOR hodnoty KR nad daty. V případě, že délka dat přesahuje délku hodnoty KR , probíhá operace XOR opakovaně po blocích délky KR . Vyměňované zprávy (transportní část): 5. A, B vypočtou: KRi = HK2 (KRi−1 ). 6. A ← B : {idA, idB, XKRi (EKEtrans (data))}. 7. A, B vypočtou: KRi+1 = HK2 (KRi ). 8. A → B : {idA, idB, XKRi+1 (EKDtrans (data))}. Problémem tak zůstává zajištění čerstvosti (na straně B). Metody založené na porovnávacích kontrolách různých typů keksíku (náhodné číslo, čas, pořadové číslo) nelze použít z důvodu snadné manipulace kontrolního kódu. Vzhledem k implementaci šifrovacího algoritmu pomocí WBACR AES nelze využít ani pravidelnou změnu šifrovacího klíče. Navržená implementace využívá klíče relace KR , aktualizovaného pomocí klíčované hashovací funkce HK2 po každé odeslané i přijaté zprávě (KRi+1 = HK2 (KRi )). Klíč KR je použit takovým způsobem (operace XKR ), aby ovlivnil každý bit odesílané i přijímané zprávy (viz 5.3). Jeho nekorektní hodnota vzhledem ke zpracovávané zprávě tak vede k jejímu poškození. Při použití vstupního a výstupního kódování pro aktualizaci KR není na straně B jeho otevřená hodnota použita a je tak ztížena jeho lokalizace nebo modifikace. Vzhledem k použití klíče KR jako inicializačního vektoru není nutné použít techniku ignorování prvního náhodného bloku použitou v autentizační části. WBACR AES tabulky pro šifrovací klíče KEtrans a KDtrans jsou generovány s využitím vstupního a výstupního kódování (narozdíl od KEauth a KDauth ). Data získaná dešifrováním zprávy pomocí klíče KDtrans tak nejsou ihned přístupná v otevřené podobě čitelné pro útočníka. Odstranění použitého kódování může být provedeno postupně v následujícím kódu nebo může sloužit k napojení další operace ve stylu mobilní kryptografie. Zvyšuje se tím provázanost jednotlivých částí kódu, útočník má ztíženo získání dat v otevřené podobě a extrakci nebo nahrazení WBACR AES tabulek. Volbou různého vstupního a výstupního kódování lze provádět personalizaci softwarového agenta strany B nezávisle na straně A. Podrobnější rozbor lze nalézt v [14].

5

Stavební prvky SEAUT

Tato část textu se věnuje popisu implementace jednotlivých prvků protokolu SEAUT v kódu softwarového agenta strany B. Na straně A, u které nepředpokládáme přístup útočníka ke kódu a průběhu zpracování, je implementace prováděna běžným způsobem, například použitím standardní implementace algoritmu AES přijímajícím na vstupu data i klíč a podobně. Strana A ani B nemusí mít žádnou apriorní znalost o způsobu implementace zpracování zpráv protokolu SEAUT na opačné straně. V následujícím textu bude používána zkratka IOC bez indexů pro označení vstupního a výstupního kódování tak, jak bylo zavedeno v 3 ve významu obecného principu použití funkce GIOC . Pokud je použit dolní index IOCX , označujeme tím konkrétní množinu obsahujících jedno nebo více GIOC kódování, která se používá pro transformaci hodnot konkrétní proměnné (například KR ). Konkrétní proměnná se může nacházet ve stavu transformace různými množinami IOCX , v daném okamžiku vždy však nejvýše jednou. Například pro KR je jsou použity množiny IOC1 , IOC2 , IOC3 , IOC4 a IOC7 . Více než jeden prvek má množina IOCX v případě, že velikost m použitelného GIOC (zde typicky 8 bitů) je menší než velikost n transformované proměnné (zde typicky 128 bitů). Proměnná je sekvenčně rozdělena na dn/me částí s různým kódování (zde typicky 16 částí) a každá část je nezávisle transformována. Konkrétní kódování j GIOC z množiny X pro j − tou část proměnné je značeno IOCX .

5.1

I/O kódování pro CBC režim

Vstupní a výstupní kódování (dále IOC), jak je popsáno v [2], poskytuje způsob, jak ztížit použití WBACR AES tabulek, pokud dojde k jejich extrakci. Bez dodatečných úprav však IOC nelze použít pro jiný šifrovací režim než ECB. Použití pro režim CBC by vyžadovalo odstranění resp. aplikaci IOC před každou jeho iterací, což by výrazně snížilo rychlost šifrování. Zároveň by byl kód aplikující kódování s využitím dynamické inspekce snadno lokalizovatelný a jeho použití by ztratilo význam. Pro praktickou možnost využití IOC pro režim CBC byla navržena modifikace znázorněná na obrázku 1. Ke dvojici vstupního 6


h a výstupního kódování f je přidáno datové kódování g. Narozdíl od původního však nejsou jednotlivá kódování nezávislá, ale jsou generována tak, aby byl splněn vztah f (Ci ) XOR g(Pi+1 ) = h(Ci XOR Pi+1 ) (dále V1 ). Po aplikaci funkce XOR na výstup předchozí iterace (kódování f ) a následujícího vstupu (kódování g) získáme hodnotu h(Ci XOR Pi+1 ). Použití IOC během celého procesu šifrování (resp. dešifrování) je transparentní a nevyžaduje žádnou změnu oproti běžnému režimu CBC. Datové kódování g je aplikováno v libovolném místě před počátkem šifrování a může být součástí předchozí operace navržené ve stylu mobilní kryptografie. Analogicky pro výstupní kódování f . Je vhodné poznamenat, že použití IOC je plně záležitostí strany B a nemá žádný vliv na formát zpráv vyměňovaných mezi A a B. Strana A tedy nemusí mít žádnou znalost o hodnotě použitého IOC a sama ho žádným způsobem nevyužívá. Interní struktura WBACR AES prakticky umožňuje použít IOC o maximální velikosti 8 bitů. Nelze tedy použít jediné kódování pro celý 128 bitový šifrovaný blok. Operace XOR je ale „blokovatelnáÿ (výsledek i-tého bitu nezávisí na j-tém bitu), lze tedy použít 16 nezávislých IOC 1 až IOC 16 pro 1. až 16. bajt bloku.

Obrázek 1: Vstupní a výstupní kódování použitelné pro šifrovací režim CBC. Pi značí i-tý blok vstupních dat, Ci značí i-tý blok zašifrovaných dat. Algoritmus generování funkcí f, g, h splňujících V1 vychází z následujících úvah: • Pro splnění vztahu V1 musí být splněn i méně obecný vztah V2 vzniklý volbou x = y: f (x) XOR g(x) = h(x XOR x) = h(0) (V2 ) • Z podmínky bijekce funkce h a V1 plyne: ∀m, n, m0 , n0 ∈ DOM : {m XOR n = m0 XOR n0 } ⇒ ⇒ { h(m XOR n) = h(m0 XOR n0 )} ⇒ {f (m) XOR g(n) = f (m0 ) XOR g(n0 )} (V3 ) • Podmínka bijekce funkce f stanovuje, že: ∀m, n ∈ DOM : m 6= n ⇒ {f (m) 6= f (n)} (V4 ) • Znalost funkční hodnoty h(s) a vztah V3 umožňuje stanovit omezující podmínku na rozsah možných hodnot, kterou musejí splňovat funkční hodnoty f(m) a g(n), pokud s = m XOR n: ∀s, m, n ∈ DOM : (m XOR n = s) ⇒ f (m) XOR g(n) = h(s) (V5 ) • Pomocí operace XOR a operandů z množiny P = {x|x = 2p , p ∈ {0, . . . , k −1}} lze vyjádřit libovolné číslo z intervalu < 0, 2k >. Využitím této vlastnosti, vztahu V5 , volby f(0) a h(0) a volby f(x) pro ∀x ∈ P lze jednoznačně určit všechny funkční hodnoty funkce f. Funkce f, g, h jsou bijektivní a pro praktické použití zadány formou tabulky. Definiční obor i obor funkčních hodnot těchto funkcí jsou přirozená čísla z intervalu DOM = < 0, 2k − 1 > (definiční obor), kde k je velikost argumentu použitého kódování (v bitech). Postup generování: 1. Zvolíme náhodně funkční hodnoty f (0) a h(0). Inicializujeme všechny hodnoty tabulek určující funkce f , g a h hodnotou UNASSIGNED. (U N ASSIGN ED ∈ / DOM ). 2. Využitím V1 , f (0) a h(0) vypočteme g(0). 3. Zvolíme náhodně, ale v souladu s V4 , funkční hodnoty f (s) pro ∀s : s = 2p , p ∈ {0, . . . , k − 1}. 4. Pro všechny zvolené funkční hodnoty f (s) z bodu 3 využitím V1 , f (s) a h(0) vypočteme g(s). 5. Pro všechny zvolené funkční hodnoty f (s) z bodu 3 využitím V1 , f (s) a g(0) vypočteme h(s). 6. Využitím vztahu V5 a již vypočtených funkčních hodnot pro f (r) a h(s) vypočteme funkční hodnotu g(r XOR s) ← f (r) XOR h(s). Z vypočtené hodnoty g(rXORs) a vztahu V2 vypočteme funkční


7

hodnoty pro f (rXORs) a h(rXORs). Bod 6 opakovaně iterujeme přes všechny hodnoty t ∈ DOM , dokud ∃t : f (t) = U N ASSIGN ED. 7. Generujeme WBACR AES tabulky s použitím vstupního kódování h a výstupního kódování f . 8. Před šifrováním v režimu CBC aplikujeme na vstupní bloky dat Pi funkci g. 9. Provedeme kroky šifrovacího režimu CBC standardním způsobem. V případě šifrování dle ECB je počet všech možných různých variant vstupních a výstupních kódování v obou případech [(2k )!] pro kódování o velikosti k bitů. Navržená metoda generování f, g, h díky nutnosti splnit vztah V1 umožňuje vytvořit 2k možných voleb pro f (0), 2k možných voleb pro h(0), a k možností volby jednoznačně neurčitelných funkčních hodnot f v souladu s V4 . Ostatní funkční hodnoty funkcí f , g a h jsou plně determinovány. Celkové množství různých variant bijektivních kódování f , g a h je rovno [2k x2k x(2k − 1)x . . . x(2k − k))]. Pro 8-bitové kódování (k = 8) tedy asi 270 různých variant.

5.2

Klíčovaná hashovací funkce s ukrytím hodnoty klíče

Pro potřeby robustního zajištění čerstvosti vyměňovaných zpráv jsou na aktualizační proces klíče KR kladeny následující požadavky: a) b) c) d)

Útočník Útočník Útočník Útočník

není není není není

schopen schopen schopen schopen

odvodit předchozí hodnotu(y) klíče relace z aktuální hodnoty. odvodit následující hodnoty klíče relace z aktuální hodnoty. smysluplně modifikovat hashovací funkci. smysluplně modifikovat aktuální hodnotu klíče relace.

Splnění požadavku a) je zajištěno, pokud aktualizační proces využívá kryptograficky jednosměrné hashovací funkce. Splnění požadavku b) je zajištěno, pokud je využita klíčovaná hashovací funkce a hodnotu použitého klíče lze utajit před útočníkem. Splnění vlastnosti c) lze zajistit transformací hashovací funkce pomocí technik mobilní kryptografie nebo obfuscation. Požadavek d) lze splnit, pokud je hodnota KR v průběhu celého procesu přítomna pouze v podobě s aplikovaným IOC kódováním a nedochází k jeho odstranění ani během jejího použití. Na základě výše uvedených požadavků byla navržena metoda aktualizace hodnoty klíče relace využívající WBACR AES. Metoda je založena na využití schématu Matyas-Meyer-Oseas [12] (dále MMO) pro tvorbu hashovací funkce z blokového šifrovače, jak je znázorněno na obrázku 2. Vzhledem k fixní velikosti klíče relace dochází vždy pouze k jedinému cyklu MMO a hodnota použitého šifrovacího klíče je vždy rovna předem dané hodnotě IV. Tato vlastnost umožňuje použít blokový šifrovač realizovaný formou šifrovací části WBACR AES tabulek. Navržená metoda zajišťuje vlastnost kryptografické jednocestnosti nejméně na úrovni MMO s jedním cyklem. Použití WBACR AES umožňuje utajit před útočníkem hodnotu klíče IV. Lze použít IOC generované dle 5.1 pro aktualizaci KR bez nutnosti odstranění IOC.

Obrázek 2: Klíčovaná hashovací funkce pro aktualizace klíče relace KR s využitím WBACR AES.

5.3

Použití a aktualizace KR

Klíč relace KR je vytvářen klíčovanou hashovací funkcí (viz 5.2) z očekávaných a obdržených hodnot během autentizační části protokolu SEAUT. Tvorba hashovací funkce z blokového šifrovače realizovaného s využitím WBACR AES zvyšuje bezpečnost KR , neboť útočník nemůže bez extrakce klíče určit ve vlastní 8


režii výslednou hodnotu KR . Hashovací funkce má výstupní kódování odpovídající vstupnímu kódování KR . Hodnota KR je použita dvěma způsoby: 1. Inicializační vektor pro režim CBC – cílem je zajistit, aby chybně ustanovený klíč relace KR vedl k vytváření a zpracování nekorektních zpráv vyměňovaných během transportní části. Pokud útočník modifikuje běh softwarového agenta tak, aby pokračoval i přes nekorektní autentizaci, bude hodnota KR odlišná a vyměňované zprávy nebudou zpracovány korektně. Vzhledem k dlouhodobému využití klíčů KEtrans a KDtrans s neměnící se hodnotou poskytuje změna klíče KR po každé zprávě ochranu proti útokům využívajícím nenáhodný inicializační vektor. 2. Opakovaná aplikace pomocí operace XOR na zašifrovaná data – cílem je zajistit, aby zpracování příchozí zprávy vytvořené pomocí jiné hodnoty KR vedlo k chybnému zpracování celé zprávy, ne pouze prvního bloku jako v případě použití pro inicializační vektor. Hodnota KR je aktualizována po každé přijaté nebo odeslané zprávě. Před další aktualizační iterací je třeba změnit kódovanou hodnotu KR z výstupního na vstupního kódování (viz 5.4). Pokud je IOC pro KR použito, útočník nemá v paměti přístupnou jeho otevřenou hodnotu, což ztěžuje jeho nalezení a modifikaci na konkrétní hodnotu. Je zároveň ztíženo i odstranění samotné opakované aplikace pomocí funkce XOR na data, neboť bez jeho použití nedochází ke změně kódování z IOC4 na IOC8 (viz 3), což v důsledku vede k chybnému zpracování dat bez změny kódování dalším kódem, který očekává data v kódování IOC8 .

5.4

Provázanost IOC

Pro zajištění čerstvosti komunikace je klíčová ochrana hodnoty KR proti podvržení. Z tohoto důvodu je přítomna pouze v chráněné podobě s aplikovaným IOC. Hodnota KR je využívána jako argument funkce XOR a její použití i v kódované podobě lze provést při vhodném generování pro IOC základní bloky využívající WBACR AES (5.3, 4.2). Hodnota KR se tak nikdy neobjeví v paměti softwarového agenta strany B v otevřené podobě. Provázanost korespondujících IOC je zachycena na obrázku 3. Generování IOC dle 5.1 kompatibilního s více jak jednou operací XOR by příliš omezilo celkový počet možných různých kódování a zvýšilo útočníkovu šanci na odhalení předpisu použitého kódování. Proto jsou jednotlivá kódování generována nezávisle a pro změnu kódování dané hodnoty (například klíče KR ) jsou použity předpočtené tabulky. Změnu kódování z IOC1 na IOC2 lze provést pomocí předpočtené tabulky pro operaci identity se vstupním kódováním IC1 a výstupním kódováním OC2 . V případě n-bitového IOC se jedná o tabulku velikosti 2n ∗ n bitů. Alternativou ke změně kódování z důvodu použitelnosti pro operaci XOR je použití předpočtených tabulek pro tuto operaci s odpovídajícím IOC. V případě dvou n-bitových argumentů se jedná o tabulku velikosti 22n ∗n bitů. Výhodou tohoto přístupu je možnost nahradit operaci XOR libovolnou jinou „blokovatelnouÿ funkcí, která by byla vhodnější pro zajištění čerstvosti zpráv. Strana A musí také používat stejnou funkci pro aplikaci KR .

Obrázek 3: Provázanost vstupních a výstupních kódování základních bloků. E1, E2 a E3 označují šifrovací část WBACR AES tabulek pro různé hodnoty klíče. RT(x,y) značí tabulku pro změnu kódování z IOCx na IOCy. P1 označuje první blok otevřeného textu. C1 značí první blok zašifrovaného textu.


9

6

Diskuse

6.1

Celková odolnost implementace

Vzájemná autentizace komunikujících stran není konečným krokem při komunikaci dvou stran. Ve většině případů dochází po úspěšném provedení autentizace k výměně dat. Protokol SEAUT této vlastnosti využívá a obě části prostřednictvím generování a použití KR provazuje. Autentizace útočníka vůči některé straně (následkem úspěšného útoku) tak automaticky nevede k možnosti libovolně manipulovat s následnou komunikací. Samotná autentizace tak nemusí být pro útočníka postačující. Pokud nedochází k výměně dat v transportní části, protokol SEAUT poskytuje pouze ochranu hodnotám nesených autentizačních klíčů, neposkytuje však ochranu proti využití WBACR AES tabulek jako šifrovacích strojů4 . Bezpečnost autentizační části navrženého protokolu není nižší než bezpečnost běžně implementovaného protokolu P3-ISO9798-2. Shodnou volbou hodnoty klíčů KEauth a KDauth získáme zprávy odpovídající protokolu P3-ISO9798-2. Pro stranu A je tedy autentizační část SEAUT stejně bezpečná jako protokol P3-ISO9798-2. Bez extrakce klíčů KEauth a KDauth z WBACR AES tabulek (v současné době není znám výpočetně proveditelný způsob) nezíská útočník autentizační informace strany A. Data vyměňovaná během transportní části jsou šifrována dlouhodobě sdílenými klíči KEtrans a KDtrans . Zprávy od A pro B nelze zaměnit za zprávy od B pro A, neboť je použita jiná hodnota šifrovacího klíče. Kód protokolu v transportní části nepracuje s otevřenými hodnotami zpracovávaných dat. Útočník tak má ztížen jejich zisk nebo cílenou modifikaci. Opakovaně zaslaná zpráva od A k B je chybně dešifrována, neboť již došlo k aktualizaci hodnoty klíče KR . Hodnota KR není přístupná v žádném okamžiku v otevřené podobě, proto je ztížen její zisk a cílená modifikace. Pro odstranění opakované aplikace hodnoty KR na data v kódu strany B útočníkem je nutné zároveň upravit následující funkci(e) tak, aby akceptovala vstupní data v jiném IOC kódování (IOC4 namísto IOC8 ). Extrakce WBACR AES tabulek pro daný klíč vede ve většině případů k úspěšnému útoku (s výjimkou zisku autentizačních informací strany A). Proto je vhodné implementaci kombinovat s obfuscation nástroji, které extrakci tabulek ztíží. Návrh implementace protokolu je motivován snahou zvýšit rozsah modifikací kódu útočníkem pro provedení úspěšného útoku, proto je vhodná kombinace s nástroji pro kontrolu integrity kódu [5, 6].

6.2

Srovnání s asymetrickou kryptografií

Pomocí oddělení šifrovací a dešifrovací části WBACR AES tabulek získáváme výhody plynoucí z asymetrické kryptografie. V kontextu tohoto příspěvku je tento postup výhodnější než standardní algoritmy asymetrické kryptografie (RSA, DSA) z těchto důvodů: • Vyšší rychlost šifrování – Asymetrické kryptografické algoritmy jsou řádově pomalejší, než algoritmy symetrické kryptografie. Hybridní šifrování, při kterém je asymetrická kryptografie použita pouze pro distribuci klíče symetrické kryptografie, nelze použít. Útočník je schopen využitím dynamické analýzy získat otevřenou hodnotu sym. klíče v době jeho dešifrování nebo použití. Naproti tomu u WBACR AES není otevřená hodnota klíče nikdy přístupná v operační paměti. • Není chráněna hodnota privátního klíče – Hodnota privátního klíče asymetrické kryptografie je v kódu přítomna v otevřené podobě a je tedy dostupná útočníkovi s využitím statické a dynamické analýzy. • Vhodnější předpoklady pro dodatečné provedení obfuscation – Šifrování pomocí WBACR AES využívá pouze operace náhledu do předpočetných tabulek (datových polí). Více druhů operací u asymetrické kryptografie zvyšuje sémantickou informaci o probíhající funkci, kterou útočník získá pozorováním aktuální instrukce procesoru. • Vstupní a výstupní kódování zpracovávaných dat – Standardní asymetrické algoritmy vyžadují přístup k otevřené hodnotě zpracovávaných dat a nelze využít možnosti propojení okolního kódu s kódem algoritmu (obsahující hodnotou privátního/veřejného klíče). Lze tedy podvrhnout hodnotu dat určených ke zpracování, lze číst otevřenou hodnotu zpracovaných dat a provést nahrazení hodnot klíčů jinými. 4 Bez

10

znalosti hodnoty obsaženého klíče.


7

Závěr

Příspěvek popsal základní stavební bloky implementace autentizačního a transportního protokolu navrženého s využitím principů mobilní kryptografie, který by měl ztížit útok na autentizaci, důvěrnost a čerstvost i v případě, že se jedna strana nachází ve výpočetním prostředí kontrolovaném útočníkem. Cílem bylo maximálně využít možností poskytovaných implementací šifrovacího algoritmu AES ve stylu mobilní kryptografie pro zvýšení bezpečnosti implementace protokolu. Kromě základní výhody ukrytí hodnoty použitého klíče je využita oddělitelnost šifrovací a dešifrovací části tabulek pro zavedení „směrovostiÿ klíčů tak, aby na straně B nebyla nutná přítomnost zároveň šifrovací i dešifrovací funkčnosti pro daný klíč. Útočník tak není schopen bez extrakce klíče podvrhnout zprávy pocházející od strany A. Důležitá část práce je věnována vhodnému využití možnosti generovat WBACR AES tabulky se vstupním a výstupním kódováním. Je navržen algoritmus generování kódování tak, aby ho bylo možné efektivně používat pro šifrovací režim CBC s možností „napojeníÿ dalších funkčních bloků implementovaných ve stylu mobilní kryptografie. Pro zajištění robustní čerstvosti vyměňovaných dat je navrženo generování a použití klíče relace KR tak, aby útočník nemohl predikovat jeho hodnotu a neměl ji v žádném časovém okamžiku přístupnou v otevřené podobě v paměti. Vhodným provázáním vstupního a výstupního kódování použitého pro různé funkční bloky v rámci protokolu (šifrování, klíčovaná hashovací funkce) je dosaženo stavu, kdy nedochází k odstranění kódování dat přímo v rámci transportní části protokolu a odhalení „poziceÿ v kódu tak nevede přímo ke kompromitaci zpracovávaných dat útočníkem.

Literatura [1] Sander, T., Tschudin, Ch.: Protecting Agents From Malicious Hosts. Springer LNCS 1419, Berlin, 1998, s. 44-60 [2] Chow, S., Eisen, P., Johnson, H., van Oorschot, P.C.: White-Box Cryptography and an AES implementation. Springer LNCS 2595, Berlin, 2003, s. 250-270. [3] Rosenblatt, B. Trippe, B. Mooney, S.: Digital Rights Management: Bussines and Technology. Indianapolis, Hungry Minds, Inc., listopad 2001, ISBN 0-7645-4889-1. [4] Hohl, F.: Time Limited Blackbox Security: Protecting Agents From Malicious Hosts. Springer LNCS 1419, Berlin, 1998, s. 92-113. [5] Horne, B., Matheson, L., Sheehan, C., Tarjan, R.: Dynamic Self-Checking Techniques for Improved Tamper Resistance. Springer LNCS 2320, Berlin, 2001, s. 141-159. [6] Chang, H. Attalah, M.: Protecting Software Code by Guards. Springer LNCS 2320, Berlin, 2001, s. 160-175. [7] NIST: Advanced Encryption Standard http://www.nist.com/aes/ (listopad 2004)

AES,

2000.

Dokument

dostupný

na

URL

[8] Červeň, P.: Cracking a jak se proti němu bránit. Praha, ComputerPress, 2002, ISBN 80-7226-382-X. [9] Zemánek, J.: Cracking bez tajemství. Praha, ComputerPress, 2002, ISBN 80-7226-703-5. [10] Collberg, Ch., Thomborson, C. Low, D.: A Taxonomy Of Obsfuscating Transformations. New Zeland, University Of Aucland, 1997. Dokument dostupný na URL http://www.cs.arizona.edu/∼collberg/Research/Publications/ CollbergThomborsonLow97a/A4.pdf (listopad 2004) [11] ISO/IEC 9798-2:1999 Information technology – Security techniques – Entity authentication – Part 2: Mechanisms using symmetric encipherment algorithms. Popis protokolu je také dostupný v [12]. [12] Menezes, A., van Oorschot, P., Vanstone, S.: Handbook of Applied Cryptography. CRC Press 1996/2001. Dostupné také na URL http://www.cacr.math.uwaterloo.ca/hac/ (listopad 2004). [13] Dusart, P.,Letourneux, G., Vivolo, O.: Differential Fault Analysis on A.E.S., Springer LNCS 2846, Berlin, 2003, s. 293-306. [14] Švenda, P.: Digital Rights Managment. Diplomová práce. Fakulta informatiky, Masarykova universita, Brno, 2004. Dokument dostupný na URL http://www.fi.muni.cz/∼xsvenda/securefw.html. (listopad 2004)


11

Implementace kryptografického protokolu s využitím mobilní kryptografie

Recommend Documents