Autentizační hardwarový token nové generace Daniel KOUŘIL1, Vašek LORENC2, Vašek MATYÁŠ2, Daniel CVRČEK3 1
Ústav výpočetní techniky, Masarykova univerzita
[email protected] 2
Fakulta informatiky, Masarykova univerzita (lorenc, matyas)@fi.muni.cz
3
Fakulta informačních technologií, Vysoké učení technické v Brně
[email protected]
Abstrakt. Příspěvek v úvodu představuje přístupy v oblasti autentizace uživatelů v distribuovaném prostředí využívajícím autentizaci na bázi speciálních hardwarových prvků – tokenů. Dále diskutuje bezpečnostní aspekty samotných tokenů a především pak představuje další úvahy vedoucí k návrhu a vlastní návrh obecné architektury tokenu nové generace, který by využil funkčnosti a bezpečnostních vlastností kvalitní kryptografické čipové karty. Tento token by byl nezávislý na zranitelném primárním pracovním prostředí – počítači – což umožní výrazně lepší ochranu kryptografických dat, která jsou na tokenu uložena. Klíčová slova: autentizace, autorizace, hardwarový token, nedůvěryhodné prostředí.
1
Úvod
Zajištění dostatečné úrovně autentizace je nezbytným předpokladem pro budování současných informačních systémů a jiných produktů, které využívají výpočetní kapacitu. Při hledání bezpečných metod autentizace uživatelů vycházíme z obvyklých tří skupin metod, kdy uživatel musí ukázat: • něco, co zná, např. heslo nebo PIN; • něco, co je, na základě biometrik – např. otisk prstu; • něco, co vlastní, tj. fyzický (hardwarový) token. Úkolem bývá vybrat cenově dostupnou kombinaci některých z těchto autentizačních faktorů tak, aby současně poskytovala co největší možnou míru zabezpečení. Příkladem takové kombinace jsou např. čipové karty, které umožňují tzv. dvoufaktorovou autentizaci, kdy uživatel musí prokázat vlastnictví tokenu (tj. karty) a zároveň znalost PINu či hesla, které zpřístupňuje citlivé informace uložené na kartě. V současnosti existuje více druhů autentizačních tokenů. Vedle čipových karet se používají např. autentizační kalkulátory (generátory jednorázových hesel), USB tokeny obsahující přístupové heslo, RFID čipy, apod. V tomto příspěvku se zaměříme na tokeny, které se připojují přímo k hostitelskému počítači. Aplikace na tomto počítači s tokenem přímo komunikují, předávají mu data, která je potřeba zpracovat pomocí kryptografických údajů na tokenu a přebírají zpět výsledky. Typickým představitelem tohoto typu jsou zmíněné čipové karty.
Peter Vojtáš (ed.), DATAKON 2006, Brno, 14.-17. 10. 2006, pp. 1-4.
Autentizační hardwarový token nové generace Použitím tokenů, které chrání uložené kryptografické údaje, lze výrazně zvýšit bezpečnost systému, kde jsou nasazeny. Zároveň ale tokeny přináší nová rizika, která je nutno uvážit před jejich nasazením. V následující kapitole popisujeme distribuované prostředí využívající řešení založené na použití tokenů a identifikujeme možné problémy plynoucí z jejich použití v reálném nasazení. Ve zbývající části příspěvku se soustředíme na bezpečnostní aspekty vlastních hardwarových (HW) zařízení a popisujeme řešení, které řeší některé zmíněné problémy.
2
Hardwarové tokeny v projektu METACentrum
Projekt METACentrum je aktivita sdružení CESNET, které je provozovatelem české akademické vysokorychlostní sítě CESNET2 a provádí výzkum a vývoj v oblasti aplikací využívajících toto prostředí. Jednou z klíčových aplikací je METACentrum, které nad sítí CESNET2 buduje a produkčně provozuje infrastrukturu pro realizaci náročných výpočtů, tzv. grid. Cílem projektu je vybudovat národní gridové prostředí, které skrývá rozdíly v jednotlivých zapojených systémech a vytváří uživatelům iluzi jediného výpočetního uzlu. METACentrum je využíváno několika stovkami uživatelů z nejrůznějších vědeckých a inženýrských oborů, z celé České republiky. Bezpečnost infrastruktury METACentra je primárně založena na použití systému Kerberos [8] a na autentizaci pomocí uživatelského hesla. Protože v současné době se v českém akademickém prostředí také významně rozvíjí infrastruktura veřejných klíčů (Public Key Infrastructure – PKI), mohou uživatelé používat i tento typ autentizace. PKI umožňuje vybudovat vysoce škálovatelnou autentizační infrastrukturu, která umožňuje uspokojit i náročnou bezpečnostní politiku. Na druhé straně praktické nasazení PKI odhaluje i slabiny, které plynou z jeho principů, na kterých je založena a které musí být řešeny již v době návrhu. Jedním ze základních problémů je bezpečná správa soukromých klíčů. Klíče používané v PKI jsou velmi dlouhé řetězce znaků a na rozdíl od hesel si je člověk nemůže zapamatovat. Musí být proto uloženy v nějaké elektronické podobě tak, aby byly přístupné aplikaci, kterou uživatel používá. Nejčastěji se dnes klíče ukládají na lokální disk počítače, buď ve formě samostatného souboru nebo ve specializovaném úložišti, které poskytuje aplikace, příp. operační systém. Vždy se ale jedná o data, která jsou uložena na disku počítače a tudíž čitelná kýmkoliv, kdo má oprávnění číst příslušnou část disku. Pro ochranu před neoprávněným přístupem k těmto datům se používá šifrování souborů heslem, které musí uživatel zadat při přístupu k soukromému klíči. Navíc, pokud to použitý souborový systém dovoluje, bývá přístup k datům na disku chráněn proti přístupu jiných uživatelů na úrovni operačního systému. Úroveň takové ochrany soukromého klíče je ale velmi malá, zejména pokud se případnému útočníkovi podaří získat práva majitele soukromého klíče nebo administrátora příslušného systému. Mezi hlavní techniky pro získání dat z lokálního disku patří použití počítačových virů, zneužití různých chyb v aplikacích běžících na daném počítači, ale i techniky sociálního inženýrství. Pokud se útočníkovi povede získat soubor se soukromým klíčem, může se pokusit najít správné heslo k rozšifrování tohoto souboru. Nejjednodušší je odposlechnout heslo při zadávání uživatelem. Alternativně je možné lámat hesla hrubou silou nebo slovníkovým útokem. Zásadním problémem v oblasti správy klíčů je fakt, že zabezpečení souboru s klíčem je z velké části v rukách samotného uživatele, což se ukazuje jako
Vybraný příspěvek nedostatečné. Navíc v oblasti PKI neexistují mechanismy, které by spolehlivě zajistily patřičnou ochranu, tj. že použité heslo je dostatečně silné proti běžným útokům, že jsou správně nastavena přístupová práva k souboru s klíčem apod. Uživatelé také mohou (a často tak také činí) libovolně manipulovat s klíčem, např. jej kopírovat na jiné počítače, kde klíč potřebují a při těchto operacích může také dojít k prozrazení obsahu soukromého klíče. Důsledkem je relativně nízká bezpečnost klíče, i když sám klíč je dostatečný z hlediska kryptografie. Cílem METACentra bylo zavést PKI tak, aby byly minimalizovány problémy týkající se správy soukromých klíčů. Rozhodli jsme se proto použít technologii čipových karet (obecně tokenů), která umožňuje spolehlivé uložení PKI dat a jejich ochranu před zneužitím. Na tuto aktivitu jsme získali projekt Fondu rozvoje sdružení CESNET, který nám umožnil nákup potřebného hardwarového vybavení a také provedení změn v infrastruktuře METACentra. Podrobnější informace o tomto projektu lze nalézt např. v [5]. 2.1
Zapojení tokenů do infrastruktury METACentra
Ve fázi výběru nejvhodnějšího typu tokenu jsme testovali několik vzorků jak čipových karet a čteček, tak i USB tokenů. Od začátku jsme sice preferovali spíše USB tokeny, zejména pro jejich snadnější fyzickou přenositelnost, ale chtěli jsme ověřit, že USB zařízení jsou skutečně ekvivalentní klasickým čipovým kartám. Mezi kritéria, která jsme vyhodnocovali, patřila zejména schopnost tokenu či karty provádět kryptografické operace a chránit soukromý klíč. Dále jsme se zaměřili na podporu příslušného typu tokenu v současných open-source produktech a možnosti používat zařízení na různých OS. Ověřovali jsme také podporu pro běžně používané standardy PKCS11 a PKCS15, které umožňují vyvíjet a používat aplikace nezávisle na konkrétním typu zařízení. Vyhodnocení ukázalo, že testované USB tokeny jsou skutečně funkčně zcela ekvivalentní čipovým kartám. K dalšímu testovaní a pilotnímu provozu jsme vybrali USB token iKey 3000 od firmy Rainbow (nyní SafeNet). Každý token se dodává s ovladači a základním programovým vybavením pro OS Windows a Linux a bez výraznějších problémů se povedlo zprovoznit podporu tokenů ve běžných aplikacích, jako jsou e-mailoví klienti nebo WWW prohlížeče. Obecně lze říci, že podporu tokenů lze zprovoznit ve většině aplikací, které podporují rozhraní PKCS11. Nedílnou součástí projektu byla úprava stávající infrastruktury METACentra tak, aby umožnila hladké nasazení hardwarových tokenů. Vedle zprovozňování a konfigurace dodaného vybavení jsme se soustředili na vývoj vlastního softwaru, který umožnil propojení se současným prostředím. Nejdůležitějším úkolem bylo připravit autentizační infrastrukturu tak, aby umožňovala použití PKI autentizace pomocí hardwarových tokenů. Bezpečnostní infrastruktura METACentra je založena na mechanismu Kerberos, který standardně podporuje autentizaci pouze pomocí hesla a symetrické kryptografie. Jedním z prvních úkolů projektu tedy bylo upravit protokol Kerberos tak, aby umožňoval i autentizaci pomocí PKI certifikátů. Podle tehdejší verze specifikace protokolu PK-INIT [10] jsme navrhli a realizovali změny do implementace protokolu Kerberos. Výsledkem byla funkční a kompatibilní realizace tohoto rozšíření, která byla i přejata do standardní distribuce Heimdal a v současné době je dále vyvíjena a používána i dalšími organizacemi ve světě, které nasazují čipové technologie v prostředí s protokolem Kerberos.
Autentizační hardwarový token nové generace V průběhu roku 2005 jsme začali distribuovat tokeny mezi koncové uživatele. Úzce spolupracujeme s certifikační autoritou sdružení CESNET, která je uznávaná v celosvětovém akademickém a gridovém prostředí a držitelé certifikátů této CA mají snadnější přístup ke zdrojům mimo ČR. Abychom usnadnili proces vydávání tokenů uživatelům, uspořádali jsme specializovaná školení, na nichž uživatelé nejen získali USB token, ale především jim byla názorně předvedena práce s ním a mohli rovnou své nové tokeny registrovat u Registrační autority CESNET CA. Kromě dedikovaných školení byly využívány i další příležitosti přidělení tokenů uživatelům (např. akce pořádané METACentrem), uživatelé mají rovněž možnost získat USB token osobní návštěvou pracovišť v Brně a v Praze. Distribuce tokenů a zejména motivace uživatelů k používání tokenů se ukázala jako jeden z významných problémů při zavádění tokenů. Ale vzhledem k tomu, že METACentrum se bude stále více zapojovat do nadnárodních aktivit, kde certifikát je jedinou možností autentizace, snažíme se uživatele motivovat k používání tokenů tak, aby byli na tyto možnosti připraveni. Mezi motivační prvky patří např. zavádění nových služeb, které rozšiřují funkčnost METACentra – ale které jsou přístupné jen uživatelům, kteří se prokazují certifikátem apod. Tokeny se ukázaly jako vhodný prostředek řešící problém správy soukromých klíčů, jejich zavedení ve větším měřítku ale také ukazuje nová rizika, která použití tokenů přináší. Především tokeny vytváří pocit dokonalého zabezpečení, který může snadno vést k nesprávnému zacházení s tokenem a ke kompromitování soukromého klíče. Ve své současné podobě jsou tokeny velmi závislé na zabezpečení hostitelského počítače, ke kterému se připojují. V případě METACentra, kdy většina uživatelů často cestuje a připojuje se z různých počítačům, vzrůstá potřeba kvalitního zabezpečení tokenu, které bude co nejméně závislé na hostitelském počítači.
3
Bezpečnost kryptografického hardwaru
Aby mohl hardwarový token bezpečně poskytnout autentizaci uživatele a autorizaci jeho operací, je nutné, aby především on sám byl navržen s ohledem na požadovanou míru bezpečnosti. Ačkoliv se může zdát, že zařízení dostupná v současné době na trhu mají v tomto smyslu obdobné vlastnosti, ani zdaleka tomu tak není. V této části nastíníme některé otázky a problémy, které se týkají oblasti zabezpečení HW tokenů. Základní rozdělení kryptografického hardwaru je dle jeho ceny a schopnosti odolávat určitým útokům. Z tohoto pohledu rozlišujeme mikrokontrolery, čipové karty (paměťové, procesorové či kryptografické) a hardwarové bezpečnostní moduly (HSM). Aby bylo možné se alespoň trochu zorientovat v jejich odlišnostech, je dobré si zavést členění. Nejjednodušší takové členění je dle existujících útoků, a to do dvou skupin, logických (softwarových) a fyzických (hardwarových). Liší se mezi sebou náročností přípravy a vedení útoku, ale také obtížností jeho aplikovatelnosti na další typy tokenů. 3.1
Logické útoky
U logických útoků nezáleží na vzdálenosti mezi útočníkem a cílovým kryptografickým zařízením, útočník pouze potřebuje přístup k šifrovanému provozu. Podle způsobu vedení takového útoku je možné uvažovat dělení na aktivní a pasivní
Vybraný příspěvek útoky, kdy v první případě útočník vstupuje do komunikace a na základě podvržených dotazů analyzuje odpovědi. Pasivní útočník pouze odposlouchává a analyzuje provoz. Známé jsou útoky na jednotlivé druhy poskytovaných kryptografických nebo bezpečnostních API, ať už hledáním chyb v jejich implementacích nebo jejich použitím nezamýšleným způsobem za účelem získání tajných klíčů, nevhodnou práci s PINy (např. útok přes decimalizační tabulku), nebo využívání vzájemných závislostí mezi vygenerovanými klíči. V případě, že zařízení používá ke komunikaci USB rozhraní, jsou možné i útoky na samotné rozhraní nebo kryptografický čip, například pomocí zasílání nevalidních USB paketů nebo nepovolených argumentů. Zdaleka ne všechna zařízení si totiž předávané hodnoty kontrolují. Vyjmenované principy útoků je možné aplikovat na čipové karty i HSM – tím, že nepracujeme fyzicky se zařízením, jsme omezeni pouze na nástroje, které nám komunikaci s ním zprostředkují. Společnou a velmi nebezpečnou vlastností všech logických útoků je snadnost jejich opětovného použití. Nehledě na to, jak dlouho trvalo objevit slabinu v implementaci některé části kryptografického zařízení, softwarová aplikace útoku je téměř vždy automatizovatelná a tím pádem zneužitelná programy typu malware. Způsoby obrany proti softwarovým chybám spočívají zejména v důsledné kontrole kódu, ideálně včetně formálního důkazu jeho správnosti. Náklady na takovou kontrolu jsou však natolik vysoké, že se v praxi většinou používají testy jednotlivých komponent, používání jednoduchých operací a typově bezpečných operací a kvalitní kontrola přístupu k datům. 3.2
Fyzické útoky
Fyzické útoky bývají, až na výjimky, náročné na vybavení útočníka. Také jejich opakovaná aplikace není snadná, neboť i po počátečním objevení slabých míst v hardwaru bývá stále nutné alespoň některé kroky provádět s každým dalším útokem na jiné kusy zařízení. V tuto chvíli je možné pozorovat zásadní rozdíly mezi dříve uvedenými třídami kryptografického hardwaru – jiné, jinak drahé a náročné útoky jsou možné na mikrokontrolery, jiné na čipové karty a jinak je třeba postupovat zejména v případě specializovaných HSM. I přesto je však možné najít společné rozdělení fyzických útoků na tři skupiny – invazivní, neinvazivní a semi-invazivní. I přesto je však možné najít společné rozdělení fyzických útoků na tři skupiny – invazivní, neinvazivní a semi-invazivní. Invazivní útoky jsou nejnáročnější na vybavení – v případě čipových karet, kde se používají obvody s vysokým stupněm integrace a pokročilými ochranami pro skrytí jednotlivých částí čipu, je nutné mít vybavení až na hranici drahých elektronových mikroskopů, mikrosond a dalšího specializovaného vybavení, obdobného tomu, co používá výrobce. Semi-invazivní techniky [9] jsou mnohem méně náročné na zdroje a přesto poskytují široké možnosti, zejména pro napadání mikrokontrolerů. Nejběžněji využívají některého dostupného záření (UV, rentgenového) v kombinaci s podchlazováním paměťových čipů. Neinvazivní útoky je možné aplikovat bez ohledu na typ zařízení – jejich myšlenka spočívá zejména ve sledování charakteristik hardwaru při provádění nejrůznějších operací nad různými daty. Typickým zástupcem je výkonová analýza.
Autentizační hardwarový token nové generace Velké nebezpečí těchto technik je zejména v tom, že po sobě nezanechávají viditelné stopy. Vybavení potřebné pro jejich provedení však není běžně dostupné a omezuje tak množinu potenciálních útočníků. Proti většině těchto útoků jsou nejlépe chráněny právě hardwarové bezpečnostní moduly, díky svým specializovaným obalům a aktivním technikám obrany. 3.3
Odolnost zařízení vůči útokům
Pro rozdělení útočníků podle jejich schopností se v současné době používá dělení do tří tříd, publikované v [1]. Do této klasifikace jsme přidali dvě třídy pro lepší ilustraci obtížnosti útoků. Rozdělení pak vypadá následujícím způsobem: • Třída 0 (script kiddies) – využívají volně dostupné nástroje a zveřejněné zranitelnosti. • Třída 1 (clever outsiders) – inteligentní útočníci bez dostatku informací o systému. • Třída 1.5 – inteligentní útočníci hledající i nové slabiny (např. specializovaná univerzitní pracoviště provádějící výzkum v dané oblasti). • Třída 2 (knowledgeable insiders) – jedinci nebo týmy s nákladným vybavením, schopni provést analýzu v dostatečném čase. • Třída 3 (funded organizations) – vysoce kvalifikované týmy využívající zařízení, která nejsou běžně na trhu, jsou schopni vyvíjet komplexní útoky a využívat nejnovější analytické nástroje (např. americká NSA). Problémem této klasifikace ovšem ještě stále je, že většina známých útoku je do kategorie 1.5, protože útoky z vyšších tříd nebývají publikovány. V [6] je uvedena tabulka shrnující přehledným způsobem schopnosti jednotlivých tříd kryptografického hardwaru odolávat jednotlivým třídám útoků podle schopností útočníka a času, který má k dispozici. Ačkoliv by bylo z pohledu odolnosti nejlepší používat HSM, cena i další vlastnosti těchto modulů (např. hmotnost), je pro použití širším spektrem mobilních uživatelů činí nevhodnými.
4
Vliv prostředí na bezpečnost tokenu
Předchozí útoky se týkaly tokenu jako takového, kdy se předpokládalo, že útočník bude určitým způsobem manipulovat přímo s ním – ať již fyzicky nebo s jeho programovým vybavením. V případě mobilních uživatelů, kteří často nemají možnost používat vlastní počítače a je nutné využívat dostupných zdrojů, však přichází v úvahu další bezpečnostní riziko, kterým je nedůvěryhodné prostředí. Tokeny nemohou být použity samostatně, ale vždy přes hostitelský počítač nebo jiné zařízení, které zprostředkovává komunikaci s tokenem. V případě, že tento logický prostředník není důvěryhodný, bezpečnostní rizika pro zneužití tokenu se výrazně zvyšují. Lze si například představit, že na hostitelském počítači je nainstalován trojský kůň, který se zaměřuje na neautorizovaný přístup k tokenu. Potom stačí, aby uživatel připojil token k tomuto počítači a aktivoval přístup k němu zadáním PINu. Trojský kůň pak může komunikovat s tokenem po celou dobu, kdy je token připojen k počítači, a nechat jej vyrábět např. elektronické podpisy pro podvržené dokumenty. Vytvořené podpisy potom odešle útočníkovi, např. elektronickou poštou. Takový neautorizovaný přístup
Vybraný příspěvek lze těžko detekovat, protože token samotný neposkytuje žádné informace o prováděných operacích, ani nevede žádné záznamy o použití. Úzce související problém se vyskytuje překvapivě i v oblasti bankovního sektoru při autorizaci plateb platební kartou, ať již magnetickou nebo čipovou. Podle našeho průzkumu už samotný proces zadávání PINu v prostředí, kdy se kolem mohou vyskytovat případní útočníci, je riskantní. Ukázalo se, že i netrénovaní jedinci jsou schopni úspěšně odpozorovat přibližně polovinu číslic v případě PINpadů chráněných tzv. bezpečnostním krytem v masivním provedení (který je v praxi výrazně redukovaný). U PINpadů bez krytu je tato pravděpodobnost až 80% [7]! Dle existujících studií [2,3] je však možné provést i následující typ útoku: Zajdete společně s obchodním partnerem na oběd do restaurace, netuše nic zlého ze strany restaurace. Požádáte o účet, budete chtít platit kartou a číšník donese příruční terminál až ke stolu. Mezitím, na opačném konci města, přešlapuje komplic číšníka v drahém klenotnictví a čeká na SMS o tom, že budete platit. V ten moment komplic vybere zamýšlené zboží a spěchá k pokladně, platit kartou. V jednom okamžiku je tedy vaše platební karta v nedůvěryhodném terminálu restaurace, který umí veškerý provoz poslat bezdrátovou sítí do jiné, speciálně upravené karty. Ta se v tuto chvíli nachází v platebním terminálu klenotnictví. Nu a teď jen stačí, abyste vyťukali správný PIN a v domnění, že platíte pouhý oběd, jste právě koupili darebákovi diamant. Nabízí se otázka, existuje-li tedy pro potřeby METACentra i bankovního sektoru nějaké použitelné řešení. V tomto případě je snazší se zaměřit pouze na specifické potřeby METACentra, neboť počet uživatelů je řádově menší, než uživatelů platebních karet.
Obrázek 1: Bezpečný PINpad se čtečkou čipové karty (banka UBS). Přímočarým a zjevně nejsnazším na provedení je projekt bezpečného PINpadu. Základním požadavkem na takovéto zařízení je odolnost vůči narušení a související detekce narušení, aby měl uživatel možnost zařízení věřit a alespoň na první pohled ověřit jeho neporušenost. Dle diskuzí na renomovaném serveru s bezpečnostní problematikou Light Blue Touch Paper [4] však ani konkrétní projekty s těmito požadavky nejsou dokonalé a dá se předpokládat, že sebedokonalejší zařízení se dá vždy nahradit jeho replikou. Navíc se z pohledu využití pro METACentrum potýkají i s tím, že jejich nošení mobilními uživateli není zdaleka tak pohodlné, aby to odůvodnilo jejich účelnost. Mnohem bezpečnější a použitelnější se jeví myšlenka o elektronickém zástupci (electronic attorney) [3]. Nelze-li věřit prostředí, ve kterém se token používá, bylo by vhodné obohatit token samotný o takové vlastnosti, aby byl schopen uživatele
Autentizační hardwarový token nové generace informovat o typu a průběhu prováděných operací a aby uživatel sám mohl následně určit, kterou z těchto transakcí zařízení povolí. Na obrázcích (obr. 1, obr. 2) je možné vidět dva různé typy zařízení, které se snaží tento problém nějakým způsobem řešit. Obě zařízení využívají jako základ kryptografické čipové karty, což zaručuje odolnost důvěrného materiálu vůči většině běžných útočníků, obsahují současně další prvky pro zvýšení zabezpečení, první z nich dokonce i (na samotné čipové kartě) nezávislé rozhraní pro člověka. Ani jedno z nich však neposkytuje poslední důležitou součást pro potřeby METACentra, tj. důvěryhodné rozhraní směrem k počítači, čímž jsou vhodná pouze pro autentizaci uživatelů, nikoliv pro autorizaci operací prováděných počítačem.
5
Nový typ tokenu pro nedůvěryhodné prostředí
Konstrukce současných tokenů předpokládá, že jsou používány v důvěryhodném prostředí, což ale nelze vždy zaručit. V předcházející kapitole jsme demonstrovali potenciální problémy, které mohou být způsobeny použitím tokenů v prostředí, jehož bezpečnost nemá uživatel pod kontrolou. Použití současných tokenů v takovém prostředí může vést až k zneužití dat uložených na tokenu, často bez vědomí jejich majitele.
Obrázek 2: „Super Smart Card“ s klávesnicí a displejem. Vzhledem k nedostatečným vlastnostem zařízení dostupných v současnosti, navrhujeme architekturu nového typu tokenu, který splňuje nastíněné požadavky. Naše řešení rozšiřuje stávající koncept čipových karet o komponentu nezávislou na hostitelském počítači, která zprostředkovává komunikaci mezi uživatelem a tokenem. Navrhovaná architektura, která je znázorněna na obr. 3, je postavena na následujících součástech: 1. fyzický základ tvoří zařízení – token – s rozhraním USB, 2. citlivá data (kryptografické klíče) jsou uložena a operace s nimi prováděny jen na kryptografické čipové kartě, 3. token má tlačítko (či několik) na potvrzování transakcí apod. – autorizaci použití citlivých dat, 4.součástí je i miniaturní displej, kam token zobrazuje informace o prováděných akcích a dotazy přímo pro uživatele.
Naformátováno: Odrážky a číslování
Vybraný příspěvek 4. Základem architektury je čipová karta uchovávající citlivé informace, která je vhodným kompromisem mezi cenou a schopností kryptografických funkcí tokenu odolávat útokům. Tato karta je integrována s tělem tokenu a provázána s ostatními komponentami. Vzhledem k velikosti není však přímo nutné používat formát čipové karty jako takové. Namísto klasických karet lze použít SIM karty vkládané do hostitelského zařízení, které se k počítači připojuje přes USB rozhraní. Tato hostitelská zařízení nedisponují vnitřní logikou a pouze zprostředkovávají rozhraní pro připojení čipové karty. V naší architektuře navrhujeme rozšířit tento pasivní prvek tak, aby byl také schopen komunikovat s uživatelem a s připojenou kartou. K tomuto účelu hostitelský token bude obsahovat displej, kam budou zobrazovány informace o operacích, které používají citlivá data uložená na vložené kartě. Před jejich provedením bude možné (a v zásadě toto bude doporučený režim), aby token vyžádal explicitní souhlas uživatele s provedením dané operace. O ten se postará vstupní jednotka obsahující jedno nebo více tlačítek, kterými uživatel může vyjádřit souhlas s operací, která je indikována na displeji. Z hlediska důvěry je podstatná skutečnost, že displej i potvrzovací tlačítka a jejich obsluha jsou přímo součástí tokenu, bez návaznosti na hostitelský počítač nebo aplikace, které na něm běží. Pomocí těchto prvků může token komunikovat přímo s uživatelem bez nutnosti použít hostitelský počítač, který by mohl komunikaci modifikovat, případně ji odchytávat nebo blokovat. Token tak poskytuje uživateli spolehlivou a okamžitou zpětnou vazbu o operacích, které se chystá provádět. Např. v případě elektronického podpisu může na displej zobrazovat vstupní data ve formě, kterou uživatel může nezávisle zkontrolovat (např. hash celého vstupního řetězce). Uživatel tak může snadno detekovat, pokud by se aplikace snažila instruovat token, aby vykonal nějaké operace s citlivými daty a zejména je schopen těmto operacím včas zabránit.
Naformátováno: Odsazení: Vlevo: 0.25", Předsazení: 0.25", Číslování + Úroveň: 1 + Styl číslování: 1, 2, 3, … + Začít od: 1 + Zarovnání: Vlevo + Zarovnat na: 0" + Tabulátor za: 0.5" + Odsadit na: 0", Přístupy klávesou tabelátor: 0.5", (Zarovnání vlevo) + 1", (Zarovnání vlevo) + 2", (Zarovnání vlevo) Naformátováno: Odsazení: První řádek: 0.2", Mezera Za: 6 b., Přístupy klávesou tabelátor: není na 1" + 2"
Naformátováno: Písmo: není Kurzíva
Autentizační hardwarový token nové generace Naformátováno: Písmo: Kurzíva, Čeština
Obrázek 3: Schéma navrhovaného tokenu. Základem architektury je čipová karta uchovávající citlivé informace, která je vhodným kompromisem mezi cenou a schopností kryptografických funkcí tokenu odolávat útokům. Tato karta je integrována s tělem tokenu a provázána s ostatními komponentami. Vzhledem k velikosti není však přímo nutné používat formát čipové karty jako takové. Namísto klasických karet lze použít SIM karty vkládané do hostitelského zařízení, které se k počítači připojuje přes USB rozhraní. Tato hostitelská zařízení nedisponují vnitřní logikou a pouze zprostředkovávají rozhraní pro připojení čipové karty. V naší architektuře navrhujeme rozšířit tento pasivní prvek tak, aby byl také schopen komunikovat s uživatelem a s připojenou kartou. K tomuto účelu hostitelský token bude obsahovat displej, kam budou zobrazovány informace o operacích, které používají citlivá data uložená na vložené kartě. Před jejich provedením bude možné (a v zásadě toto bude doporučený režim), aby token vyžádal explicitní souhlas uživatele s provedením dané operace. O ten se postará vstupní jednotka obsahující jedno nebo více tlačítek, kterými uživatel může vyjádřit souhlas s operací, která je indikována na displeji. Z hlediska důvěry je podstatná skutečnost, že displej i potvrzovací tlačítka a jejich obsluha jsou přímo součástí tokenu, bez návaznosti na hostitelský počítač nebo aplikace, které na něm běží. Pomocí těchto prvků může token komunikovat přímo s uživatelem bez nutnosti použít hostitelský
Vybraný příspěvek počítač, který by mohl komunikaci modifikovat, případně ji odchytávat nebo blokovat. Token tak poskytuje uživateli spolehlivou a okamžitou zpětnou vazbu o operacích, které se chystá provádět. Např. v případě elektronického podpisu může na displej zobrazovat vstupní data ve formě, kterou uživatel může nezávisle zkontrolovat (např. hash celého vstupního řetězce). Uživatel tak může snadno detekovat, pokud by se aplikace snažila instruovat token, aby vykonal nějaké operace s citlivými daty a zejména je schopen těmto operacím včas zabránit. Díky USB lze získat rychlý přenosový kanál mezi kartou a aplikacemi na počítači. Pomocí tohoto připojení je možné, aby token komunikoval přímo s počítačem bez nutnosti dodatečné uživatelské interakce a je tak možné předávat i větší objemy dat. S ohledem na rozměry předpokládáme, že token bude ve srovnání se současnými USB paměťovými tokeny větší – tak, aby mohl obsahovat displej a řídící tlačítka. Celková velikost srovnatelná s velikostí čipové karty by stále umožňovala snadné přenášení i používání, a to i pro často cestující uživatele. Z hlediska používání bude největší změnou požadavek autorizovat každou operaci s citlivými daty, na což uživatelé v současné době nejsou zvyklí. Věříme však, že tento požadavek na dodatečnou interakci je plně vyvážen výrazně vyšší úrovní ochrany dat, kterou tato nová architektura nabízí. Toto řešení by využilo schopností a bezpečnostních vlastností kvalitní kryptografické čipové karty, přitom ale uživateli poskytlo zásadní informace (kontrolní kód ap.) a také získalo uživatelovo vyjádření ohledně použití kryptografických klíčů nezávisle na hostitelském počítači. Právě tato popsaná nezávislost – na více zranitelném primárním pracovním prostředí – je podle našeho názoru kritická pro důvěryhodnost operací prováděných s danými kryptografickými klíči a jejich ochranu vůbec. Tato nová architektura také vyžaduje jen minimální změny na straně současných aplikací (uživatelské rozhraní pro zobrazení), bude proto možné jej snadno integrovat se systémy, kde se čipové technologie již používají a přímočaře tak zvýšit jejich bezpečnost.
6
Závěr
Představená architektura tokenu nabízí výrazně lepší ochranu kryptografických dat, která jsou na tokenu uložena, protože znemožňuje jejich použití bez explicitního souhlasu majitele tokenu. Aplikace tak např. nemohou nechat token vytvořit elektronický podpis libovolných dat, což je v současném modelu použití čipových karet proveditelné. Ve srovnání se současnými řešeními tak tokeny založené na prezentované architektuře poskytují řádově lepší zabezpečení a důvěru v informace, které byly byly vytvořeny pomocí dat spravovaných těmito tokeny.
Literatura 1. 2.
D.G. Abraham, G.M. Dolan, G.P. Double, J.V. Stevens. Transaction Security System. IBM Systems Journal v30 no 2. 1991. B. Adida, M. Bond, J. Clulow, A. Lin, S. Murdoch, R. Anderson, R. Rivest: Phish and Chips . Traditional and New Recipes for Attacking EMV. 2006 International Workshop on Security Protocols, Cambridge, UK. To appear in Springer Verlag Lecture Notes in Computer Science.
Autentizační hardwarový token nové generace 3.
R. Anderson, M. Bond: The Main-in-the-Middle Defence. 2006 International Workshop on Security Protocols, Cambridge, UK. To appear in Springer Verlag Lecture Notes in Computer Science. 4. Kolektiv přispěvatelů, server Light Blue Touch Paper. URL: http://www.lightbluetouchpaper.org/2006/05/10/the-mythical-tamper-proof-pinpad/ 5. D. Kouřil, M. Procházka: Zkušenosti s nasazováním HW tokenů pro uživatele METACentra. Sborník příspěvků z XXVIII. konference EurOpen.CZ 2006. 6. V. Lorenc, V. Matyáš: Odolnost kryptografického hardwaru s ohledem na nasazení. Sborník příspěvků z XXVIII. konference EurOpen.CZ, 2006. 7. V. Matyáš, D. Cvrček, J. Krhovják. PIN & Chip or signature – beating the cheating? 2005 International Workshop on Security Protocols, Cambridge, UK. To appear in Springer Verlag Lecture Notes in Computer Science. 8. B.C. Neuman, Theodore Ts’o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9):33-38. September 1994. 9. S.P. Skorobogatov. Semi-invasive attacks. A new approach to hardware security analysis. University of Cambridge Computer Laboratory Technical Report 630, 2005. http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-630.html 10. L. Zhu, B. Tung. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). IETF RFC 4556. June 2006. Annotation:
An Authentication Hardware Token of New Generation In this paper we describe a new architecture of hardware tokens focusing on better protection of cryptographic keys stored on the tokens. The paper begins with a short case-study describing deployment of HW tokens in a grid environment, where the needs for a proper token protection are illustrated. We then discuss security of hardware tokens themselves, and finally present an approach that allows for secure use of tokens in a hostile environment.
