Masarykova univerzita Fakulta informatiky
Autentizace uživatelů v OS Windows Bakalářská práce
Pavel Krkoška 2009
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Poděkování Děkuji svému vedoucímu bakalářské práce panu Ing. Mgr. Zdeňku Říhovi, Ph.D. za odbornou pomoc při vzniku této práce.
Shrnutí Tato práce je zaměřena na autentizaci uživatelů operačního systému Windows. Popsány jsou tři metody autentizace – pomocí hesel, čipových karet a biometrik. Práce čtenáře seznamuje s architekturou a bezpečnostními politikami systému, všímá si použité technologie, způsobu a místa uložení citlivých údajů. Těžištěm je přehled autentizačních metod a jejich vzájemné porovnání. Součástí práce je popis praktických zkušeností autora se zkoumanými metodami autentizace.
Klíčová slova Autentizace, Windows, heslo, NTLM, Kerberos, token, čipová karta, PC/SC, biometrika, otisk prstu
Obsah 1. 2.
Úvod ................................................................................................................................. 2 Základní autentizační principy OS Windows .............................................................. 3 2.1 Úvod do autentizace............................................................................................... 3 2.2 Přehled autentizačních metod ................................................................................ 4 2.2.1 Autentizace pomocí hesel .................................................................................. 4 2.2.2 Autentizace pomocí tokenů................................................................................ 5 2.2.3 Autentizace pomocí biometrik........................................................................... 6 2.3 Koncepty autentizace OS Windows....................................................................... 7 2.3.1 Interaktivní vs. neinteraktivní přihlášení ........................................................... 7 2.3.2 Autentizační architektura OS Windows............................................................. 8 3. Autentizace pomocí hesel ............................................................................................. 11 3.1 Základy kryptografie............................................................................................ 11 3.2 Hesla v systému Windows ................................................................................... 12 3.2.1 Použité kryptografické protokoly .................................................................... 12 3.2.1.1 Autentizace na bázi NTLM.............................................................................. 12 3.2.1.2 Autentizace na bázi protokolu Kerberos.......................................................... 14 3.2.2 Fyzické uložení hesel v systému...................................................................... 17 3.2.3 Politiky bezpečných hesel................................................................................ 18 3.3 Zkouška prolomení hesel ..................................................................................... 19 4. Autentizace pomocí tokenů .......................................................................................... 21 4.1 Koncepty podpory čipových karet v systému Windows...................................... 21 4.1.1 Standardy PC/SC ............................................................................................. 21 4.2 PC/SC architektura v systému Windows ............................................................. 22 4.2.1 Poskytovatelé služeb (service providers)......................................................... 23 4.2.2 Resource manager............................................................................................ 23 4.2.3 Specifické ovladače zařízení............................................................................ 24 4.3 Použití čipových karet k přihlášení...................................................................... 24 4.3.1 PKI infrastruktura ............................................................................................ 25 4.3.1.1 Certifikační autorita ......................................................................................... 25 4.3.1.2 Proces přihlášení .............................................................................................. 25 4.3.2 Uložení klíčů a certifikátů................................................................................ 27 4.4 Zkušenosti s přihlášením pomocí čipových karet ACOS5/2 ............................... 27 5. Autentizace pomocí biometrik ..................................................................................... 30 5.1 Biometrické technologie v dnešní praxi .............................................................. 30 5.2 Začlenění biometrik do autentizační architektury systému Windows ................. 32 5.2.1 GINA vs. Credential Providers ........................................................................ 32 5.2.2 Způsob uložení a zabezpečení biometrických údajů ....................................... 32 5.2.3 Třífaktorová autentizace .................................................................................. 33 5.3 Aktuální možná řešení pro biometrickou autentizaci v OS Windows................. 33 5.3.1 Biometric Framework pro Windows 7 ............................................................ 34 5.4 Zkušenosti s přihlášením do Windows pomocí biometrik................................... 35 6. Závěr .............................................................................................................................. 36 6.1 Podpora autentizačních metod v různých verzích OS Windows ......................... 36 6.2 Srovnání autentizačních metod ............................................................................ 37 6.3 Závěrečné shrnutí................................................................................................. 38 Použitá literatura ................................................................................................................... 39
1. Úvod Autentizace uživatelů, o které pojednává tato práce, je klíčovým prvkem zabezpečení všech operačních systémů. V různých formách, avšak ve všech novějších verzích systému Windows zajišťuje autentizace ověření identity uživatele a v návaznosti na něj povoluje nebo zakazuje přihlášení do systému a přístup k dalším zdrojům. Služby operačního systému, o kterých bude v textu řeč, umožňují bezpečné skladování přístupových údajů a jejich opakované ověření. Hašovací a šifrovací protokoly naproti tomu poskytují technologické zázemí pro zamezení neoprávněného přístupu k údajům uživatelů. Ale není to jen místo a způsob uložení autentizačních dat, ale zejména celková bezpečnostní politika a její prvky, které rozhodují o tom, jestli případný útočník bude úspěšný a získá neoprávněně přístup do systému nebo jeho zdrojům. S rozšířením systému Windows do podnikového sektoru byly na proces autentizace a zabezpečení přístupu kladeny stále větší nároky, které vyústily v potřebu lepším způsobem (a tedy vícefaktorově) ověřovat identitu uživatele. Při vytváření bezpečnostní politiky firmy máme na výběr z více metod autentizace uživatelů vůči systému – mohou být ověřeny jejich fyziologické kvality, vlastnictví autentizačního předmětu nebo jednoduše testována znalost přístupového tajemství. Autentizační metody mohou být různým způsobem kombinovány, používány současně nebo postupně (víceúrovňová autentizace), vůči lokálnímu stroji nebo v rámci domény. Myšlenka vícefaktorové autentizace se kromě podnikového užití pomalu, ale jistě stěhuje také do soukromého sektoru – poměrně běžným zabezpečením přístupu k Windows jsou v dnešní době čtečky otisků prstů, případně jiných fyziologických charakteristik. Jednotlivé autentizační metody se od sebe výrazným způsobem liší, ať už mírou zabezpečení, snadností implementace, pohodlností obsluhy či cenou pořízení. Cílem práce je poskytnout přehled tří hlavních autentizačních metod doplněný vlastními zkušenostmi a následným srovnáním, které doporučí vhodné metody pro různé autentizační scénáře.
2
2. Základní autentizační principy OS Windows V úvodní přehledové kapitole rozdělíme autentizační metody na tři základní a budeme se věnovat principům autentizace v operačním systému.
2.1
Úvod do autentizace
Než začneme s popisem základních konceptů operačního systému, dovolte mi malou odbočku k obecným základům. Následující odstavce slouží k seznámení s problematikou autentizace. Proces přihlášení Typický autentizační proces začíná požadavkem uživatele k přihlášení, který zasílá své přihlašovací údaje k ověření tzv. autentizační autoritě (authentication authority). Autentizační autoritu může ve světě OS Windows představovat lokální pracovní stanice nebo jeden či více autentizačních serverů (authentication servers). Přihlášení je na takových strojích zajištěno konkrétní přihlašovací službou (authentication service), která uživatelem vložené údaje porovná s údaji uloženými v databázi (credential database). Přihlašovací údaje může představovat uživatelské jméno a heslo, údaje uložené na hardwarovém tokenu nebo fyzikální a behaviorální charakteristiky uživatele. Autentizační autorita ověří, zda jsou uživatelem vložené údaje platné (typicky shodou s uloženými záznamy) a pokud ano, povolí mu přístup k požadovanému systému či zdrojům. Jako doklad o provedené autentizaci je zároveň uživateli vystaven tzv. autentizační token 1 , který může uživatel následně použít pro přístup k dalším zdrojům v systému autorizační autority. Bezpečnost autentizační infrastruktury Na základě uvedených informací je na místě položit si nyní otázku, co vyjadřuje a jak můžeme hodnotit bezpečnost konkrétního informačního systému. S jistou mírou zobecnění je možné říci, že bezpečnost procesu autentizace určují zejména dva faktory: použité autentizační metody a v ruku v ruce jdoucí autentizační protokoly, které zajišťují zabezpečení autentizačních dat. Předpokladem každé správně fungující bezpečnostní infrastruktury je však zejména důsledně prosazovaná bezpečnostní politika (security policy), proto nás v následujícím textu bude zajímat i míra bezpečnosti aplikovaná na uložení hesel (místo uložení, fyzické zabezpečení, řízení přístupu). V dalším textu si mimo jiné ukážeme, že známá poučka „systém je právě tak bezpečný, jako je bezpečné jeho nejslabší místo“ platí bezezbytku i u systémů rodiny Windows a že ústupky v pohodlnosti obsluhy či zpětné kompatibility jdou často na úkor bezpečnosti systému 2 . Autentizační protokoly Autentizační protokol je typem bezpečnostního protokolu používaného při autentizaci uživatelů (typicky spolu s návaznými požadavky autorizace). Protokol dosahuje kýženého zabezpečení použitím různých šifrovacích metod a hašovacích funkcí. Příkladem autentizačních protokolů jsou kupříkladu NTLM, Kerberos, SSL/TLS, CHAP, EAP, PAP. Protokolům bude věnován značný prostor v dalších částech práce.
1
Abychom předešli nedorozumění, pokud nebude řečeno jinak, budeme v dalším textu pojmem token označovat prostředek k jedné z autentizačních metod. Token ve významu dokladu o přihlášení budeme označovat pojmem tiket (podle vzoru protokolu Kerberos). 2 Narážka na systémy Windows 2000 a novější (kromě Server 2008 / Vista), které ukládají a posílají data slabě zabezpečená protokolem Lan Manager, přestože podporují novější protokol NTLM
3
2.2
Přehled autentizačních metod
Autentizační metoda vyjadřuje to, co od uživatele potřebujeme získat (čím se musí prokázat) pro účely ověření identity. Podle běžného dělení rozlišujeme autentizaci tím, co uživatel zná (typicky znalost účtu a hesla, příp. PINu), tím, co uživatel má (čipová karta, token) a tím, čím uživatel je (otisk prstu, sken duhovky, tváře, pohybové charakteristiky atd.) – druhé dvě zmíněné metody jsou z hlediska bezpečnosti považovány za silné [6, str. 15]. Kvalitu autentizačních metod určuje jednak samotná kvalita přístupových údajů (v případě hesel například délka hesla a abeceda použitých znaků, v případě biometrik kvalita sejmutých vzorků), jednak počet faktorů vyžadovaných autorizační autoritou. Rozlišujeme autentizaci jednofaktorovou (politika vyžaduje jen jednu metodu ověření, typicky ověření jména a hesla) a vícefaktorovou (vyžadována kombinace více metod, například token nebo otisk prstu v kombinaci s PINem). Je nasnadě, že vícefaktorová autentizace poskytuje větší míru zabezpečení, podmínkou je opět adekvátní implementace odpovídající bezpečnostní politiky.
2.2.1 Autentizace pomocí hesel Jak již bylo naznačeno, autentizace pomocí hesla je drtivě nejvyužívanější autentizační technikou, při jejímž použití uživatel zadává typicky přihlašovací jméno (není podmínkou) v kombinaci s heslem, které zná (v horším případě má uloženo nebo někde napsáno). Pro úspěšnou autentizaci uživatele vůči autentizační autoritě je používán typicky haš hesla uloženého v systému, konkrétní způsob ověření zadaných údajů závisí na použitém autentizačním protokolu. Bezpečnost hesel Konkrétní soupis možností, kde a jak hesla ukládat a jaké bezpečnostní principy na ně aplikovat, je daleko nad rámec této práce, přesto uvedeme alespoň základní pravidla pro dosažení rozumné míry zabezpečení. V první řadě je to ukládání hesel v šifrované (hašované) podobě a nikoli plain-textu. S úspěchem můžeme rovněž bránit uživatelům nebo aplikacím v přístupu k souboru s hesly nebo jej alespoň co nejvíce omezit. Bezpečnostní politika by měla vyžadovat určitou kvalitu hesla, která je kritická v případě odchycení haše hesla a možnosti použití offline útoku. Pro kvalitu je rozhodující počet znaků abecedy a délka hesla, které exponenciálně zvyšují čas potřebný k jeho prolomení útokem hrubou silou – použitím číslic a jiných nepísmenných znaků navíc můžeme zabránit útoku slovníkovému. Vzhledem k tomu, že útočník potřebuje určitý čas k prolomení a zneužití hesla, můžeme se bránit nastavením maximální doby platnosti hesla, po jejímž uplynutí musí uživatel heslo změnit – systém by měl v takovém případě rovněž zabránit cyklickému opakování stejných hesel. Vynikajícím pomocníkem je i technika solení, kdy je před spočítáním haše k heslu přidána pro uživatele unikátní hodnota (sůl) – solení efektivně zabraňuje útočníkovi v použití útoku slovníkového typu. Útoky V první řadě rozlišujeme online (jsou vedeny přímo v interakci s autentizační autoritou) a offline útoky. Obecně platí, že offline útoky jsou rychlejší a nebezpečnější, z čehož plyne potřeba zabránit v první řadě odposlechu haše (šifry) hesla na přenosové lince (problematika šifrování přenosu). Pokud již útočník disponuje znalostí haše hesla, může na něj použít různé techniky k jeho prolomení, v některých případech se s jeho využitím dokonce může vůči systému úspěšně autentizovat. Rozlišujeme několik běžných typů útoků – v prvé řadě je to útok hrubou silou (brute-force attack), v rámci kterého útočník použije hašovací funkci na veškeré kombinace hesel určité délky v rámci dané abecedy a zjišťuje případnou shodu se získaným hašem. Tímto typem útoku lze během několika sekund prolomit slabá hesla uživatelů, problémem jsou naopak pro tento typ „naivního“ útoku hesla delší. Druhou možností útočníka je použití tzv. slovníkového útoku, kdy je haš hesla porovnáván s haši běžných slov v daném jazyce, případně oborových slovníků – takto lze úspěšněji prolomit jednodušší
4
hesla o větší délce. Určitou kombinací je technika zvaná rainbow-attack 3 , kdy si útočník předem vytvoří databázi hašů a při útoku je již pouze porovnává se získaným hašem. Nevýhodou je velikost databáze hašů, která při větší délce hesla a obsáhlejší abecedě může zabírat desítky gigabytů místa. PINy PINy jsou zvláštním typem hesel, uplatňující se výhradně při vícefaktorové autentizaci. Jsou obvykle kratší a jednodušší než hesla, typicky tvořeny pouze číslicemi nebo písmeny. Způsob zabezpečení PINů spočívá v omezení počtu pokusů, které máme k dispozici pro jejich správné zadaní. Po překročení tohoto počtu je PIN na daném autentizačním tokenu nebo čipové kartě zablokován a další přístup je možný až po odblokování (vynulování počítadla pokusů). Výhodou tohoto přístupu je, že pro odblokování může být aplikován bezpečnější mechanizmus, který vyžaduje kupříkladu znalost jiného kódu (tzv. PUK kód) nebo prokázání identity osobními doklady.
2.2.2 Autentizace pomocí tokenů Autentizační token je zařízení, pomocí kterého se může uživatel přihlásit do systému – podmínkou je, aby jej uživatel měl v okamžiku přihlášení u sebe. Tokeny mohou mít více forem – nejběžnější jsou čipové a paměťové karty, dalšími typy jsou USB tokeny (v podstatě čipová karta a její čtečka „v jednom“) a autentizační kalkulátory. Minimální funkcí všech tokenů je možnost uložení citlivých údajů (případ „obyčejných“ paměťových karet), sofistikovanější zařízení osazené procesorem jsou schopny samy provádět kryptografické výpočty. Tokeny nabízejí obecně bezpečnější a efektivnější metodu autentizace než hesla a společně s biometrikami jsou označovány jako silné autentizační metody. Výhody a nevýhody Mluvíme-li o výhodách či nevýhodách tokenů, je vhodné o nich mluvit v kontrastu se slabým zabezpečením hesly. Mezi největší výhody patří snadná kontrola přístupu – pokud mám token v držení (a za předpokladu, že nefunguje na bezdotykovém principu), nikdo jiný jej nemůže použít nebo z něj získat citlivé údaje. Stejně tak ukradení tokenu je, na rozdíl od prolomení hesla, jednoduše zjistitelné a můžeme mu také snadněji předcházet. Druhou stranou mince je odmítnutí přístupu do systému v případě ztráty zařízení, což je problém, na který musí umět bezpečnostní politika reagovat. Útoky Základním kamenem bezpečnosti tokenu je jeho odolnost vůči útokům všeho druhu. U tokenů existuje obecně nebezpečí, že útočník provede kryptoanalýzu na jednom kusu zařízení, čímž odhalí slabá místa a může se tak dobře připravit na „reálný“ útok. V případě takového útoku je také důležité, jestli útočník „pouze“ přečte údaje v tokenu nebo jej dokáže také replikovat. U tokenů rozlišujeme tři základní typy útoků: invazivní, neinvazivní a semiinvazivní [6, str. 42-43]. V případě invazivních útoků útočník potřebuje přímý přístup ke komponentům čipu a typicky se snaží pomocí testování, analýzy komponent a technik reverzního inženýrství o replikaci funkcí tokenu a získání údajů obsažených v jeho paměti. K provedení tohoto typu útoku je zapotřebí specializované laboratoře s drahým vybavením. K seminvazivním útokům není potřeba přímý přístup, útok může probíhat například změnami teplot nebo vystavením čipu různým druhům záření (mikrovlny, UV, laser). Cílem je pozměnit chování čipu a získat tak přístup k citlivým údajům. Do kategorie semiinvazivních útoků patří také chybová analýza, která obnáší pozměnění dat či kódu a následnou analýzu generovaných chyb. Neinvazivní útoky naopak funkci tokenů povětšinou neovlivňují, jsou naopak zaměřeny na zkoumání jeho charakteristik za provozu. Mezi nejběžnější typy těchto sofistikovaných útoků patří časová a odběrová analýza kryptografických operací. Stejně jako útoky 3
Více informací viz OECHSLIN, Philippe. Making a Faster Cryptanalytic Time-Memory Trade-Off [online]. [2003] [cit. 2008-12-13]. Dostupný z WWW:
.
5
můžeme kategorizovat i obrany proti nim. Základní dělení rozlišuje hardwarovou ochranu (senzory detekující útok, zařízení bránící útoku) a softwarovou ochranu (vícenásobné cykly v kódu, vkládání šumu apod.). Čipové karty Čipové karty jsou v současné době bezesporu nejrozšířenějšími tokeny. Každý z nás vlastní minimálně dvě – SIM kartu v telefonu a platební kartu v peněžence. Karty mohou být buď paměťové (obsahují jen statickou paměť) nebo procesorové. Paměťové karty jsou jednoduché, snadno zneužitelné a replikovatelné, oproti tomu karty procesorové jsou ve své podstatě malými počítači schopnými vlastních kryptografických operací spolu s efektivní ochranou uložených dat (klíčů a certifikátů). Karty se obvykle skládají z až 32-bitového procesoru, ROM paměti pro operační systém karty, EEPROM paměti pro uložení citlivých dat a malé energeticky závislé RAM paměti pro provádění výpočtů. Ke komunikaci karty s okolím slouží vstupně-výstupní rozhraní, které potřebuje speciální čtečku, typicky připojenou k počítači přes USB rozhraní.
2.2.3 Autentizace pomocí biometrik Třetí, dnes již poměrně běžnou metodou používanou pro autentizaci uživatelů v informačních systémech je autentizace pomocí biometrik. Na rozdíl od předchozích dvou metod, kdy uživatel něco vlastnil nebo věděl a tedy předkládal systému „entitu“ na něm teoreticky nezávislou, v případě autentizace biometrikami uživatel předkládá k ověření část svého těla (fyziologickou kvalitu), případně od ní odvozený vzorec chování (behaviorální kvalitu). V případě použití této metody můžeme mít tedy alespoň teoretickou jistotu, že je uživatel fyzicky přítomen u počítače a že se za něj neautentizuje stroj nebo jiná osoba. Prakticky bohužel nejsme schopni ověřit, jestli není uživatel k přihlášení nucen útočníkem a narážíme také na nový problém tzv. živosti, kdy neumíme rozhodnout, jestli je vzorek předkládaný k ověření skutečně živý (nejedná se o napodobeninu) a, v užším slova smyslu, jestli je předkládaný vzorek opravdu „součástí“ autentizované osoby. Biometrické autentizační techniky a problémy s nimi související Biometrických autentizačních technik registrujeme v dnešní době mnoho, a ještě mnohem více jich je ve stádiu vývoje nebo ve formě teoretických konceptů. Jen některé z těchto technik jsou již komerčně dostupné, jiné jsou ve stádiu testování nebo prozatím z důvodu enormních finančních nákladů omezeny na laboratorní využití [18]. Jak již bylo řečeno výše, autentizační techniky se podle zkoumané charakteristiky dělí na fyziologické a behaviorální. Mezi fyziologické charakteristiky patří například otisk prstu, vzor duhovky, tvar ruky nebo obličeje, mezi charakteristiky behaviorální naopak vzorek hlasu, dynamika podpisu, dynamika psaní na klávesnici a jiné. Při použití biometrických technik narážíme na nový druh problému při ověření údajů – zatímco v případě tokenů i hesel se jednalo o exaktní a ve své podstatě triviální porovnání dvou (ať už jakkoli složitých) hodnot, u biometrických dat narážíme na vysokou míru entropie lidského jedince a z ní plynoucí nepřesnosti při měření. Prakticky u každého člověka a jakýchkoli dvou měřených vzorků lze najít rozdíly a tak nemůže být porovnání nikdy stoprocentní. Tento problém zachycují dvě sledované veličiny, které reflektují přesnost měření – jedná se o koeficient nesprávného odmítnutí (False Rejection Rate, FRR) a koeficient nesprávného přijetí (False Acceptance Rate, FAR). V prvním případě jde o procentuální vyjádření počtu neprávem odmítnutých oprávněných uživatelů, v druhém naopak počtu uživatelů, kterým byl přístup do systému neoprávněně garantován. Grafy těchto veličin jsou ze své podstaty nepřímo úměrné a jejich výše pro konkrétní zařízení je dána nastavenou prahovou hodnotou. Prahová hodnota v procentech vyjadřuje míru vyžadované shody vzorku sejmutého se vzorkem uloženým, při jejíž dosažení je požadavek na autentizaci uživatele uznán jako oprávněný.
6
Výhody a nevýhody Výhody biometrických autentizačních metod jsou vcelku zřejmé z předchozích odstavců. Oproti slabé autentizaci heslem se tentokrát prokazujeme něčím, co nemůžeme zapomenout – fyzikální charakteristiky se navíc v čase nemění nebo se mění pouze málo. Negativní aspekty tohoto faktu se projeví při kompromitaci našich biometrických charakteristik – pokud se útočníkovi podaří kupříkladu replikovat otisk prstu uživatele, je tato charakteristika pro účely autentizace do budoucna problematická. Přidáme-li k tomu problém přesného měření popsaný v předcházejícím odstavci, lze říci, že možnosti využití biometrik pro autentizační účely jsou v současné době omezené. Ideální se z tohoto pohledu jeví kombinace biometrik a zabezpečení heslem (PINem), případně třífaktorová autentizace [6, str. 25]. Určitě není sporu o tom, že biometrikám patří v zabezpečení informačních systémů budoucnost, ale až poté, co budou překonány technologické překážky bránící jejímu rozšíření.
2.3
Koncepty autentizace OS Windows
Každý uživatel přihlašující se k systému Windows je jednoznačně rozlišitelný svým identifikátorem (security identifier, SID). Proces autentizace zajišťuje ověření totožnosti uživatelů – každá uživatelská entita (security principal) prokazuje svými přístupovými údaji svou příslušnost k uživatelskému účtu uloženém v databázi autentizační autority. V běžném případě postačí k přihlášení znalost názvu a hesla uživatelského účtu, OS Windows však podporuje více typů přihlašovacích údajů. V následujících podkapitolách jsou popsány koncepty interaktivního (lokálního) a neinteraktivního (síťového) přihlášení, možnosti přihlašovacího rozhraní v systémech Windows a použité autentizační architektury pro oba typy přihlášení.
2.3.1 Interaktivní vs. neinteraktivní přihlášení Typické přihlášení k systémům Windows začíná pro uživatele stisknutím kombinace kláves CTRL+ALT+DEL 4 (Secure Attention Sequence, SAS). Toto přihlášení, ve kterém systém vyzývá uživatele k zadání jeho přístupových údajů, je ve Windows nazýváno interaktivní (nebo také poněkud nešťastně lokální). Pomocí interaktivního přihlášení se může uživatel autentizovat vůči lokálnímu stroji či doménovému serveru. Výsledkem úspěšného interaktivního přihlášení je vytvoření sezení (logon session), v rámci kterého může následně docházet k neinteraktivnímu přihlášení k externím zdrojům, kdy jsou místo vkládání údajů uživatelem použity systémem kešované přihlašovací údaje. Interaktivní přihlášení V OS Windows existuje více možností, jak uskutečnit interaktivní přihlášení do systému. Klasický model známý z operačních systémů Windows 95/98 a Windows NT/2000 začíná výše zmíněnou kombinací CTRL+ALT+DEL. Vynucení zadání této sekvence kláves zvyšuje bezpečnost přihlášení, jelikož eliminuje možnost, že uživatel své údaje vloží do aplikace, která se pouze „tváří“ jako běžné přihlašovací rozhraní. Nutnosti použít CTRL+ALT+DEL se dá zamezit v registru v klíči služby Winlogon 5 . Po zadání sekvence je uživatel vyzván k vložení svého loginu a hesla spolu s možností zvolení si domény, do které se bude přihlašovat. V novějších desktopových systémech počínaje Windows XP se ve výchozím nastavení zobrazuje uvítací obrazovka (Welcome Screen), ve které má uživatel na výběr z lokálních uživatelských účtů a zadává tak pouze své heslo. Je zřejmé, že tento krok je ústupkem bezpečnosti před pohodlností – případný útočník zná díky uvítací obrazovce celou polovinu přístupových údajů uživatele. Kromě výše uvedených existují ještě speciální případy
4 5
V systémech Windows XP/Vista je kombinace CTRL+ALT+DEL ve výchozím nastavení vypnuta HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DisableCAD
7
interaktivního přihlášení – pomocí funkce přepínání uživatele (Fast User Switching, FUS) a pomocí vzdálené plochy nebo terminálových služeb. Systémy Windows 2000 a novější umožňují automatizaci přihlášení do systému – ač by se v takových případech mohlo zdát, že se již nejedná o interaktivní přihlášení (uživatel není vyzván k zadání údajů a je přihlášen automaticky), opak je pravdou – heslo uživatele je pouze uloženo na zvláštním místě v registru a použito automaticky. Neinteraktivní přihlášení Pokud v rámci sezení (logon session) ustaveného po proběhnuvším interaktivním přihlášení uživatel požádá o přístup ke vzdáleným zdrojům (například sdílená složka na počítači v rámci domény), spouští se neinteraktivní přihlášení. Podmínkou pro jeho spuštění je právě příslušnost zdroje ke stejné doméně (autentizační autoritě), ke které již je uživatel přihlášen. V případě tohoto typu přihlášení automaticky dochází k zaslání přístupových údajů operačním systémem klienta – může se jednat o kešované přihlašovací údaje (NTLM) nebo o tiket protokolu Kerberos 6 . Analogicky s interaktivním přihlášením je výsledkem úspěšného neinteraktivního přihlášení ustavení sezení, tentokrát síťového (network session). Autentizační autorita, která je použita pro ověření přístupových údajů uživatele, se liší podle toho, kam se uživatel přihlašuje. Služba operačního systému zodpovědná za provedení autentizace se nazývá LSA (Local Security Authority) – pokud přihlášení probíhá k lokálnímu stroji, uživatel se autentizuje vůči lokální LSA, pokud se jedná o přihlášení k doméně, vůči odpovídající službě běžící na serveru, který je zodpovědný za autentizaci – tzv. řadiči domény (Domain Controller, DC). Způsob a místo uložení přístupových údajů se, jak bude vysvětleno v následující podkapitole, značně liší právě v závislosti na autentizační autoritě.
2.3.2 Autentizační architektura OS Windows Následující podkapitola pojednává o autentizační architektuře operačního systému Windows – popisuje služby systému zodpovědné za celý autentizační proces, všímá si uživatelského rozhraní pro přihlášení, provázání tohoto rozhraní se službami autentizační autority a poskytuje přehled databází používaných pro uložení přístupových údajů. Důležitou součástí podkapitoly je popis spolupráce služeb autentizační autority s různými autentizačními protokoly, které zprostředkovávají samotné zabezpečení citlivých údajů. Následující text by se měl stát odrazovým můstkem pro hlavní obsahovou část práce, která se bude na níže uvedené poznatky odvolávat. Jak si ukážeme, autentizační architektura operačního systému Windows je navržena natolik unifikovaně, že využití jejích služeb je dostupné širokému spektru různých implementací všech tří autentizačních metod. Základem tohoto návrhu je princip modularity – dalo by se dokonce říci, že klíčovou část změn v autentizačním návrhu ve vývoji systému Windows od verze 2000 (včetně produktů Windows Server) tvoří dodatečné balíčky rozšiřující možnosti systému při zachování funkcionality a zpětné kompatibility. Autentizační architektura pro interaktivní přihlášení Interaktivní přihlášení k systému Windows řídí služba operačního systému zvaná Winlogon. Po stisknutí SAS sekvence, pokud je vyžadováno, zavolá Winlogon modul GINA (Graphical Identification and Authentication), který je zodpovědný za zobrazení přihlašovacího rozhraní, získání přístupových údajů od uživatele a jejich poskytnutí službě LSA 7 . Local Security Authority je komponentou jádra operačního systému Windows, která funguje jako autentizační autorita –
6
Tématu se podrobně věnuje třetí kapitola GINA je v systémech Vista a Server 2008 nahrazena moduly CSP (Credential Service Providers), o kterých bude pojednáváno v páté kapitole
7
8
spolupracuje s lokální bezpečnostní databází a autentizačními balíčky a ovládá tak přihlášení uživatele 8 . Architektura procesu interaktivního přihlášení je zjednodušeně ilustrována na obrázku 2.1.
2.1 Architektura pro interaktivní přihlášení [1] Autentizační balíčky (Authentication Packages, AP) jsou softwarové implementace jednotlivých protokolů zajišťující interaktivní přihlášení uživatele. Systémy Windows do verze NT4 nabízí jediný autentizační balíček MSV1_0 (msv1_0.dll), systémy Windows 2000 a novější navíc také balíček Kerberos (kerberos.dll) 9 , který představuje implementaci stejnojmenného autentizačního protokolu. MSV1_0 se používá vždy a všude k lokálnímu přihlášení a podporuje také pass-through autentizaci pomocí autentizačního protokolu NTLM (verze 1 i 2). Kerberos nelze využít pro lokální přihlášení, jelikož ke svému běhu vyžaduje službu KDC (Key Distribution Center) dostupnou na řadiči domény Windows 2000, Server 2003 a 2008. Pro systémy Windows 2000 a novější je výchozím balíčkem pro doménové přihlášení právě Kerberos, pokud se k doméně připojuje klient s operačním systémem Windows NT nebo starším, použije se k ověření údajů uživatele automaticky balíček MSV1_0 [13, str. 66]. Na pracovních stanicích Windows, stejně jako ve všech verzích produktu Windows Server, jsou údaje k lokálním uživatelským účtům uloženy v databázi SAM (Security Accounts Manager) 10 . V produktech rodiny Server počínaje Windows 2000 jsou doménové uživatelské účty ukládány rovněž v databázi Active Directory (AD), která nabízí kromě prostoru pro údaje uživatelů mnoho dalších bezpečnostních funkcí [7]. Ke klasickému doménovému přihlášení k řadičům domény Windows je používána právě databáze AD, lokální SAM databáze na těchto strojích slouží pouze jako záložní. Přihlašovací údaje klienta jsou po úspěšném doménovém přihlášení na jeho straně kešovány a mohou být po určitou dobu využity k přihlášení k lokální stanici klienta pokud není k dispozici řadič domény (například pokud uživatel cestuje s laptopem). 8
Služby LSA, autentizační balíčky, autentizační databáze a další procesy jsou ve Windows zapouzdřeny v procesu lsass.exe 9 Klíč registru HKEY_LOCAL_MACHINES\System\CurrentControlSet\Control\Lsa\AuthenticationPackages uchovává seznam všech dostupných autentizačních balíčků 10 O fyzickém umístění loginů a hesel, stejně jako o možnostech nastavení bude konkrétně pojednáno v třetí kapitole
9
Autentizační architektura pro neinteraktivní přihlášení Architektura pro neinteraktivní přihlášení, zahrnující dva stroje s OS Windows (v roli klienta a serveru), je ilustrována na obrázku 2.2. Typickým příkladem použití neinteraktivního přihlášení je připojení poštovního klienta MS Outlook k serveru MS Exchange. Důležitými komponentami tohoto modelu jsou rozhraní SSPI (Security Support Provider Interface) a balíčky SSP (Security Support Provider). SSPI je aplikační rozhraní, které zprostředkovává spojení mezi běžnými komunikačními protokoly (HTTP, POP3, SMTP apod.) a bezpečnostními protokoly (Kerberos, NTLM, SSL/TLS a jinými). Jeho důležitou funkcí je také abstrakce od konkrétních implementačních specifik jednotlivých bezpečnostních protokolů.
2.2 Architektura pro neinteraktivní přihlášení [1] SSP balíčky jsou podobně jako v případě autentizačních balíčků pro interaktivní přihlášení konkrétními softwarovými implementacemi jednotlivých protokolů, které mohou být do systému zapojeny právě prostřednictvím SSPI rozhraní. Operační systémy Windows podporují více SSP balíčků jako jsou NTLM, Kerberos, SChannel, DPA nebo Digest Authentication [2, str. 1] a poskytují prostředky k implementaci dalších balíčků založených na vlastních autentizačních modelech 11 . Počínaje Windows 2000 je v systému obsažen speciální bezpečnostní balíček Negotiate SSP, který již z názvu obstarává vyjednávání o použití konkrétního protokolu mezi vzdálenými stroji [3, str. 249]. Dalším konceptem neinteraktivního přihlášení je z obrázku 2.2 vyplývající fakt, že balíčky SSP přistupují k autentizačním balíčkům a potažmo i údajům v bezpečnostní databázi prostřednictvím služby LSA. Důležitým poznatkem pro tuto práci je závislost většiny bezpečnostních balíčků podporovaných systémy Windows na tzv. CSP modulech (Cryptographic Service Providers), které obstarávají samotné kryptografické operace (příkladem může být DES nebo MD5 šifrování). Díky další abstrakční vrstvě s názvem CryptoAPI dostupné v systémech Windows počínaje verzí NT4 mohou jednotlivé SSP balíčky využívat služeb různých CSP modulů [9]. O autentizačních balíčcích, ve kterých se prolínají funkce pro interaktivní i neinteraktivní přihlášení, hovoříme jako o SSP/AP. Příkladem takových kombinovaných balíčků jsou kupříkladu MSV1_0 a Kerberos.
11
Klíč registru HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Package obsahuje seznam všech dostupných SSP v systému
10
3. Autentizace pomocí hesel Mluvíme-li o autentizaci k OS Windows pomocí hesel, budou nás zajímat bezpečnostní politiky systému, místa uložení hesel a – možná nejdůležitěji – použité kryptografické protokoly, které hesla fyzicky zabezpečují hesla proti přečtení. Zatímco u bezpečnostní politiky a místa uložení hesel u operačních systémů Windows již máme potřebné teoretické základy uvedeny v druhé kapitole, nezmínili jsme se ještě o základech kryptografických protokolů, o jejichž implementacích bude v následující kapitole především řeč. Dovolte mi tedy nyní krátkou odbočku ke kryptografii.
3.1
Základy kryptografie
Kryptografie neboli volně přeloženo „psaní skrytě“ je disciplínou, která se k zabezpečení různých vojenských či státních tajemství používala již od starověku. Největší teoretické i praktické posuny zažila kryptografie za obou světových válek, kdy její vývoj kromě hledání nových metod utajení stimuloval i vznik bezdrátové telegrafie. Moderní éra kryptografie započala v půlce dvacátého století, kdy byly položeny základy symetrické kryptografie. V polovině sedmdesátých let byly objeveny možnosti mladší asymetrické kryptografie a o pár let později pak vznikají také první asymetrické protokoly (RSA, DES), které se v upravených variantách používají dodnes. Kryptografické metody řeší potřebu utajení obsahu textové zprávy tajnou informací, tzv. šifrovacím klíčem, pomocí kterého se citlivá data zakódují a následně, je-li potřeba, dekódují. Jak si později kupříkladu ukážeme, při běžném lokálním přihlášení ke stanicím Windows dochází pouze k opakovanému jednosměrnému zašifrování zprávy (hesla). Jak vyplývá z výše napsaného, důležité pro bezpečnost kryptografických metod jsou možnosti utajení samotné metody (principu jejího fungování) a šifrovacího klíče. Historie ukázala, že je výhodnější neutajovat metodu a naopak ji prezentovat co nejširší odborné veřejnosti pro pravděpodobnější odhalení jejích slabých míst. Většina moderních kryptografických algoritmů je založena na matematické teorii čísel, kryptografický systém tedy můžeme popsat jako sestavu parametrických transformací (zobrazení) z množiny celých čísel na množinu celých čísel. Každý algoritmus lze matematicky popsat, zajímá nás kupříkladu, jaké množství informace lze ze zakódované zprávy odvodit o zprávě původní nebo kolik informace o klíči nám dá určité množství dvojic původních a zašifrovaných zpráv. Na základě těchto hodnot pak můžeme určit, jak je určitá kombinace algoritmu a jeho klíče odolná vůči různým typům útoků (chosen-plaintext attack, known-plaintext attack a jiné). Klíčovým prvkem kvality každé šifry je právě její klíč a především jeho délka, která je kompromisem mezi přijatelnou bezpečností a náročností zpracování kryptografických operací. Je nasnadě, že požadavky na délku klíče s postupem času vzhledem k rostoucím výpočetním schopnostem počítačů a možnostem distribuovaných výpočtů narůstají. V roce 1999 byla kupříkladu kryptoanalýzou rozbita RSA šifra s klíčem o délce 512 bitů, dnes se běžně používají šifry s délkou klíče 1024 bitů, jejichž prolomení je exponenciálně náročnější. Symetrická kryptografie Klasická symetrická kryptografie využívá pro potřeby zakódování i dekódování zprávy jediný klíč, který je v tomto modelu sdíleným tajemstvím mezi odesílatelem a příjemcem. Aby vyhovovala výše zmíněnému kompromisu, musí symetrická šifra odolat útoku hrubou silou, jinými slovy vyzkoušení všech možností klíče musí trvat dostatečně dlouhou dobu vzhledem k výpočetní síle soudobých počítačů. Běžná délka klíče v dnešních symetrických kryptografických protokolech je 128 až 256 bitů. Rozlišujeme také tzv. proudové (zpráva se kóduje bit po bitu) a častěji používané blokové šifry – mezi nejběžnější symetrické blokové šifry patří DES (Data Encryption Standard) šifra (dnes už není bezpečná), její nástupkyně 3DES a standardizovaná AES (Advanced Encryption Standard) založená na blokové šifře Rijndael. Mezi výhody symetrické kryptografie patří zejména její rychlost, která je obecně až tisíckrát větší než u srovnatelných asymetrických metod. Zřejmým (a největším) problémem symetrických metod je potřeba zaslání sdíleného klíče zabezpečeným kanálem, což může být v praxi velice obtížné.
11
A konečně, překážkou v používání symetrické kryptografie v komunikaci mezi větším množstvím uživatelů je počet nutných symetrických klíčů, jehož funkce má vzhledem k počtu uživatelů kvadratickou složitost. Asymetrická kryptografie Asymetrická kryptografie naproti tomu využívá konceptu dvojice klíčů – tzv. veřejný klíč je uživatelem poskytnut odesílateli a probíhá pomocí něj zašifrování zprávy. Soukromý klíč musí být naopak bezpečně v držení příjemce zprávy, který ji pomocí klíče může dešifrovat. V tomto modelu nemusí být veřejný klíč uživatele přenášen zabezpečenou cestou – takový odchycený klíč se dá „zneužít“ pouze k zakódování zprávy, kterou opět přečte jenom vlastník soukromého klíče z páru. Asymetrická kryptografie (na rozdíl od symetrické) nepracuje s celou množinou celých čísel, ale pouze s vybranou konkrétní podmnožinou (například prvočísly). V důsledku toho, že ani případný útočník nemusí procházet celý obor čísel, jsou v tomto modelu na délku klíčů vztaženy větší nároky – pohybují se v rozmezí 1024 až 2048 bitů. Z předchozího odstavce plynou také největší výhody asymetrických metod – při jejich používání není třeba nikam zasílat soukromý klíč (nemůže dojít k jeho prozrazení odposlechem), stejně tak množství klíčů je podstatně omezeno – každému účastníkovi komunikace stačí pouze dvojice klíčů. Nevýhodou asymetrického šifrování je naopak rychlost a problém důvěryhodnosti veřejného klíče příjemce. K zamezení možnosti podvržení veřejného klíče jednotlivých entit je zapotřebí přítomnosti třetí strany – důvěryhodné certifikační autority (CA, Certificate Authority), která je databází entit s ověřenou totožností a jejich veřejných klíčů. Certifikační autorita, ke které se v dalším textu vrátíme, je ve světě Windows součástí infrastruktury veřejných klíčů (PKI, Public Key Infrastructure). V praxi se často kombinují přístupy obou kryptografických metod, přičemž jsou využívány jejich silné stránky. Konkrétně se bezpečnější asymetrické protokoly využívají k zašifrování symetrického klíče, který pak slouží k zakódování samotné zprávy.
3.2
Hesla v systému Windows
Následující text obrací svoji pozornost od obecných předpokladů ke konkrétním implementacím autentizace hesly v systému Windows.
3.2.1 Použité kryptografické protokoly V předchozí kapitole jsme si vyjmenovali dva implicitní kryptografické SSP/AP balíčky, které v systému Windows implementují požadavky na bezpečné uložení a přenos hesel, MSV1_0 a Kerberos. Již bylo řečeno, že balíček MSV1_0 využívá protokolu NTLM (s různými tzv. příchutěmi – anglicky flavours) a je schopen zabezpečit lokální i doménové přihlášení, naproti tomu balíček Kerberos využívá kryptografického protokolu stejného jména a zabezpečuje výhradně doménové přihlášení. V této podkapitole odhlédneme od jednotlivých případů použití a budeme se věnovat konkrétně oběma protokolům – cílem je rovněž popsat rozhodující přednosti systému Kerberos oproti klasickému NTLM. 3.2.1.1
Autentizace na bázi NTLM
O protokolu NTLM mluvíme jako o klasickém z toho důvodu, že se jedná o vlastní, patentovaný protokol společnosti Microsoft, jehož různé implementace se při autentizaci uživatele používají již od nejstarších verzí operačního systému Windows. Již jsme se zmínili, že ačkoli je od verze 2000 výchozím autentizačním protokolem Kerberos, NTLM je v operačních systémech stále podporován z důvodu zpětné kompatibility – toto se týká i nejnovějších produktů Vista a Server 2008.
12
Základní vlastnosti protokolu NTLM si odvodíme z popisu šesti kroků síťové autentizace uživatele (viz obrázek 3.1): 1. Klient požádá server o autentizaci (Authentication Request) 2. Server zašle klientovi „náhodný“ řetězec znaků (NTLM výzvu) 3. Klient zasílá serveru dvě odpovědi: a. LM (Lan Manager) odpověď, která sestává z NTLM výzvy a stejné výzvy zašifrované DES protokolem za použití LM haše hesla uživatele jako symetrického klíče b. NTLM (NT Lan Manager) odpověď, která opět sestává ze samotné výzvy a výzvy zašifrované stejným způsobem; jako klíč nyní slouží NTLM haš hesla uživatele 4. Server požádá řadič domény (DC) o ověření údajů uživatele – tento princip je znám jako NTLM pass-through autentizace 5. Řadič domény ověří údaje uživatele – nejprve porovná NTLM odpověď s uloženým NTLM hašem (server musí provést stejné operace jako klient v kroku 3), poté to samé provede s LM hašem; pokud se v kterémkoli z obou případů výsledky rovnají, je uživatel autentizován 6. Řadič domény zasílá serveru informaci o úspěchu či neúspěchu uživatelského přihlášení
3.1 Autentizace pomocí NTLM [2] Jak z výše uvedeného vyplývá, NTLM ve skutečnosti sestává ze dvou různých kryptografických protokolů, LM a NTLM – opět z důvodů zpětné kompatibility se staršími verzemi systému. 12 Vzhledem k již poměrně dávnému prolomení DES šifry rovnou odhalujeme jednu z největších slabin protokolu: v současné době jsou vcelku běžné programy na odposlechnutí NTLM odpovědi a extrakci hašů uživatele – ty mohou být následně podrobeny útoku, jehož ukázku provedeme ke konci kapitoly. A aby nebylo nevýhod málo, samotný přenos NTLM výzvy a odpovědi není protokolem nijak zabezpečen a jediné tajemství, které tak v celém přenosu existuje, jsou haše hesla uživatele. Případný útočník tak vůbec nemusí přistupovat k rozlomení odposlechnutého haše, ale pouze jej využít pro vytvoření odpovědi na výzvu serveru – tato metoda útoku je známa jako tzv. pass-the-hash útok [2, str. 264]. Důležitým aspektem je také jednosměrnost celého protokolu, kdy se autentizuje výhradně uživatel serveru, nikdy ne naopak, což umožňuje další typy útoků.
12
Tématu různých verzí Windows a jimi podporovaných protokolů se věnuje šestá kapitola
13
LM vs. NTLM V souvislosti s popsanou nevýhodou protokolu NTLM, kdy jsou serveru zpět zasílány odpovědi zašifrované dvěma různými klíči – LM a NTLM hašem hesla uživatele, je třeba popsat rozdíl mezi oběma protokoly. Rozdíl je v tomto případě opravdu jen jeden, a to právě způsob uložení hesla uživatele v systému; funkce protokolu popsaná výše je identická. Srovnání LM a NTLM hašů poskytuje tabulka 3.2 – je patrné, že LM haš není oproti NT haši využívající algoritmus MD4 opravdovým hašem, ale spíše jednoduchou jednocestnou šifrou, ze které se dá snadno odvodit počet znaků hesla [2, str. 269]. Z toho můžeme vyvodit i nebezpečnost LM protokolu, jež byl původně využíván staršími operačními systémy MS DOS, Windows 3.x a Windows 95/98/NT. Maximální délka hesla Abeceda Rozdělení hesla Použitá funkce Délka klíče
LM haš 14 znaků omezená ASCII, case-insensitive 7 znaků DES 56 bitů 3.2. LM vs. NTLM haš
NTLM haš 256 znaků ASCII, case-sensitive Ne MD4 128 bitů
NTLMv2 Operační systémy Windows NT (SP4)/2000 a novější podporují upravený protokol s názvem NTLMv2 (NTLM verze 2), který do značné míry odstraňuje neduhy předešlé verze. Ve verzi 2 již konečně není používán LM haš, ale pouze NT haš, čímž je doba potřebná pro případné prolomení hesla mnohonásobně navýšena. Druhou důležitou změnou je možnost vyjednávání o použitém zabezpečení sezení mezi klientem a serverem, kde lze vyžadovat kupříkladu kontrolu integrity nebo zakódování zprávy. A konečně, protokol NTLMv2 již pro generování odpovědi nepoužívá zastaralý DES algoritmus, ale bezpečnější HMAC-MD5 podpořený solením a přidáním časového razítka [15, str. 15]. K výzvě generované serverem také přidává výzvu na ověření serveru ze strany klienta. Možnosti nastavení pro zabezpečení sezení, stejně jako samotné povolení protokolu NTLMv2 ve Windows NT4, 2000, XP a 2003 Server (ve výchozím nastavení vypnuto) budou diskutovány v sekci 3.2.3. 3.2.1.2
Autentizace na bázi protokolu Kerberos
Windows Kerberos je implementací otevřeného standardu RFC 4210 (nahrazuje předchozí RFC 1510), který definuje verzi 5 původního autentizačního protokolu vyvinutého v rámci projektu MIT Athena 13 . Základní protokol Kerberos 14 , stejně jako NTLM, využívá symetrické kryptografie – existuje však jeho rozšíření PKINIT, které je založeno na asymetrické kryptografii. Kerberos PKINIT je ve Windows využíván pro podporu autentizace čipovou kartou a jako takový bude diskutován ve čtvrté kapitole. Základní výhodou protokolu Kerberos oproti NTLM je jeho rychlost v důsledku použití unikátního systému tiketů, díky kterým protokol nepotřebuje pass-through autentizaci. Samozřejmostí je rovněž vzájemná (mutual) autentizace, kdy se server ihned po provedeném ověření autentizuje zpět klientovi. Rozšíření použitelnosti znamená podporovaná tranzitivní důvěra (transitive trust) mezi doménami používajícími stejného protokolu, v doménách s řadičem domény Server 2003 a 2008 rovněž mezi doménami v různých doménových lesech. Díky tomu, že je Kerberos otevřeným standardem, poskytuje také možnost vzájemné autentizace mezi stroji s různými operačními systémy a Single-Sign-On (SSO) k různým tzv. kerberizovaným síťovým aplikacím. 13
Více informací viz Kerberos: The Network Authentication Protocol [online]. 2007 [cit. 2008-12-13]. Dostupný z WWW: . 14 Od této chvíle budeme mluvit pouze o Windows implementaci protokolu Kerberos
14
Funkce protokolu Kerberos Pro fungování protokolu Kerberos v doméně Windows je nezbytná důvěryhodná třetí strana – tzv. Key Distribution Center (KDC), který je součástí řadičů domény serverů Windows 2000 a novějších. Pro porozumění procesu autentizace je třeba zavést některé důležité pojmy: v první řadě je to master key – tajný klíč uživatele, kterým se klient autentizuje KDC a session key – klíč relace, který vydává KDC a jímž se klient prokazuje KDC a zdrojovému serveru. Klíč relace je bezpečnější než tajný klíč uživatele, jelikož je generován KDC při přihlašování uživatele a má pouze krátkodobou platnost. Služba KDC na řadiči domény Windows sestává ze dvou částečně samostatných služeb – Ticket Granting Service (TGS), která vydává klientům tikety pro přístup ke zdrojům, a Authentication Service (AS), která provádí samotnou autentizaci uživatele 15 . Pro ukládání tajných klíčů (master keys) využívá KDC služeb Active Directory (AD) – klíče pro potřeby protokolu Kerberos jsou odvozeny od hašů hesel uživatele, jejichž ukládání v AD bude diskutováno dále v této kapitole. Důležitým aspektem protokolu Kerberos je čas – veškerá komunikace obsahuje časová razítka a je platná pouze po omezenou dobu, důležitá je tedy synchronizace aktuálního času v rámci domény. Autentizace pomocí protokolu Kerberos probíhá ve třech po sobě následujících fázích (v závorkách jsou uvedeny standardní názvy jednotlivých zpráv) znázorněných na obrázku 3.3: 1. Vzájemná autentizace klienta a Windows KDC (jednou za přihlášení) a. Klient posílá KDC požadavek na autentizaci (KRB_AS_REQ), který obsahuje tzv. authenticator – ten sestává ze jména uživatele a časového razítka a je zabezpečený pomocí tajného klíče uživatele b. AS dešifruje zaslaný authenticator, zkontroluje časové razítko a uživatele autentizuje c. AS posílá klientovi odpověď (KRB_AS_REP), jejíž obsahem je klíč relace (budeme mu říkat SK1) pro další komunikaci mezi klientem a KDC zabezpečený opět tajným klíčem uživatele. Spolu s SK1 zasílá AS jeho další kopii, tentokrát zabezpečenou tajným klíčem KDC – tato kopie je nazývána Ticket-Granting Ticket (TGT) 2. Vytvoření klíče relace pro přístup klienta ke zdrojovému serveru (jednou pro každý server) a. Klient posílá KDC požadavek na vystavení klíče relace pro přístup ke zdrojovému serveru (KRB_TGS_REQ), který opět obsahuje authenticator a v předešlém kroku vystavený TGT klienta b. TGS dešifruje přijatý TGT, získá obsažený SK1 a pomocí něj ověří authenticator c. TGS vytvoří klíč relace pro komunikaci mezi klientem a zdrojovým serverem (SK2), zakóduje jej pomocí SK1 a zasílá zpět klientovi (KRB_TGS_REP). Součástí odpovědi je i tiket pro použití zdroje na serveru, který obsahuje SK2 a je zašifrovaný pomocí tajného klíče zdrojového serveru 3. Vzájemná autentizace klienta a zdrojového serveru a. Klient zasílá zdrojovému serveru požadavek na použití zdroje (KRB_AP_REQ), který obsahuje authenticator zabezpečený pomocí SK2 a tiket vystavený TGS b. Cílový server dešifruje SK2 z tiketu a ověří authenticator klienta c. Server posílá klientovi authenticator s novým časovým razítkem zabezpečený opět pomocí SK2 (KRB_AP_REP), na základě kterého klient ověří server. Další komunikace probíhá po kanálu zabezpečeným právě tímto klíčem relace. Kdykoli v rámci přihlášení požádá klient o další zdroj v rámci domény, spustí se neinteraktivní přihlášení, které opakováním kroků 2 a 3 zaručí vystavení a použití nového tiketu. Jakmile je jednou spojení mezi klientem a serverem ustanoveno, nepřeruší se do vypršení platnosti tiketu – když se tak stane, vrátí server chybu, načež klient automaticky zareaguje žádostí k TGS o nový tiket. Pokud v rámci přihlášení dojde k expiraci TGT, je obnoven automaticky pomocí uživatelova tajného klíče, který je na systémech Windows uložen v cache [2, str. 329].
15
Windows implementace neumožňuje na rozdíl od standardu RFC 4210 provozovat tyto dvě služby na různých serverech
15
3.3. Autentizace pomocí protokolu Kerberos [15] Mezidoménové přihlášení Podobný scénář jako výše popsané přihlášení v rámci domény (single-domain logon) má přihlášení k prostředí s více doménami (multi-domain logon), respektive z počítače v jedné doméně ke zdrojům v doméně jiné (klient má účet vedený v jiné doméně než ze které se přihlašuje). K vysvětlení funkce mezidoménového přihlášení je třeba přiblížit princip tranzitivní důvěry (transitive trust). Představme si doménu muni.cz, která má dva potomky: alfa.muni.cz a beta.muni.cz. Mezi mateřskou doménou muni.cz a jejími potomky existuje přímá důvěra (trust), které se také říká reálná nebo netranzitivní, což znamená, že KDC v jedné doméně důvěřuje uživatelům domény druhé. Důsledkem je tranzitivní důvěra mezi doménami alfa.muni.cz a beta.muni.cz, která umožňuje uživatelům v jedné doméně používat zdrojů v druhé, právě s využitím přímé důvěry k mateřské doméně muni.cz. Do schématu mezidoménového přihlášení musíme zařadit ještě dva pojmy: doporučující tiket (referral ticket) a mezidoménový klíč. Nyní budeme uvažovat nad situací, kdy se klient domény alfa.muni.cz bude chtít přihlásit ke stroji v doméně beta.muni.cz. Vzhledem k tomu, že mezi oběma doménami neexistuje přímá důvěra, nemůže KDC domény alfa.muni.cz vydat klientovi platný tiket pro přístup ke stroji. Místo toho vydává doporučující tiket zašifrovaný mezidoménovým klíčem, což je speciální klíč, který existuje mezi doménami s přímou důvěrou, v tomto případě alfa.muni.cz a muni.cz. Klient zasílá tento doporučující tiket KDC domény muni.cz, který jej dešifruje a zašle klientovi nový doporučující tiket, tentokrát zašifrovaný mezidoménovým klíčem, který sdílí muni.cz s doménou beta.muni.cz. KDC domény beta.muni.cz doporučující tiket dešifruje a na jeho základě vystaví klientovi platný tiket pro přihlášení ke stroji ve své doméně. Neinteraktivní mezidoménové přihlášení probíhá podobně: pokud je klient přihlášený ke své doméně alfa.muni.cz a žádá přístup ke zdroji v doméně beta.muni.cz, musí nejprve kontaktovat KDC své vlastní domény. KDC alfa.muni.cz vystaví doporučující tiket dešifrovatelný KDC muni.cz, který obratem vydává doporučující tiket pro beta.muni.cz. Po obdržení tohoto klíče vydává KDC domény beta.muni.cz klientovi platný tiket pro použití zdroje ve své doméně. Pokročilá témata protokolu Kerberos Závěrem této části se zmíníme o pokročilých vlastnostech protokolu Kerberos, které jsou již nad rámec tohoto textu. Předně Kerberos podporuje tzv. delegaci požadavků – znamená to, že se server může autentizovat k jinému serveru jménem klienta, který mu to dovolí zasláním tzv. přeposlatelného (forwardable) TGT. Tento přístup má nesporné bezpečnostní výhody, jelikož se dá lépe kontrolovat přístup k cílovému serveru [2, str. 347-350]. Pracovní stroje a servery Windows rovněž poskytují extenze základního protokolu pro zajištění důvěrnosti dat (KRB_PRIV) a ověření pravosti a integrity (KRB_SAFE). Obě extenze používají klíč
16
relace, kterým jednak můžou zašifrovat haš zprávy (tzv. MAC) nebo rovnou celou zprávu. Jako výchozí šifrovací algoritmus je používán RC4-HMAC, Kerberos ve Windows dále podporuje DESCBC-MD5 a CBC-CRC (v Active Directory ve výchozím nastavení jsou ukládány jak RC4, tak DES klíče jednotlivých účtů). Kerberos verze 5 také podporuje předautentizaci (preauthentication), která efektivně brání proti offline útokům na použitý klíč. Poslední poznámka se týká obsahů tiketů vystavených KDC, ať už se jedná o TGT nebo tikety pro přístup ke zdrojům. Z obou můžeme vyčíst mimo jiné verzi protokolu, název domény, klíč relace, čas přihlášení, TTL, IP adresu klienta nebo autorizační data. Oba také obsahují různé příznaky (flags), které určují vlastnosti jednotlivých tiketů, například forwardable (přeposlatelný), forwarded (přeposlaný), proxiable (možno vystavit pro jinou IP klienta), proxy (vystaven pro jiné IP), preauthenticated (předautentizován), renewable (obnovitelný) a další.
3.2.2 Fyzické uložení hesel v systému V následujících odstavcích bude diskutováno fyzické uložení hesel v systémech Windows, ve kterém musíme opět rozlišovat mezi autentizací vůči pracovní stanici a vůči řadiči domény. Již v první kapitole jsme se zmínili o databázi SAM, která uchovává údaje o uživatelských účtech na lokálním stroji, nyní si ukážeme, kde přesně jsou fyzicky data uložena a jak jsou zabezpečena. Jiný případ nastává při doménovém přihlášení – řadiče domény Windows používají k ukládání citlivých údajů služeb Active Directory. Lokální přihlášení SAM databáze přihlašovacích údajů je na pracovních stanicích Windows uložena ve vyhrazené části (tzv. hive) registru pod klíčem HKEY_LOCAL_MACHINE\SAM. Ve výchozím nastavení má k tomuto klíči přístup výhradně uživatel SYSTEM 16 , administrátor systému však může toto nastavení změnit. Na disku je SAM databáze uložena v adresáři %SystemRoot%\system32\config\SAM, který je však systémem uzamknut [13, str. 63]. Každý záznam uložený v databázi SAM má své unikátní SID, které jej v systému jednoznačně identifikuje. Hesla uživatelů jsou ukládány v závislosti na použitém protokolu – jedná se o výše popsané LM a NT haše. Doménové přihlášení Jak již bylo řečeno, systémy Windows Server 2000 a novější používají k ukládání uživatelských záznamů databázi Active Directory. Tato databáze je na řadičích domény Windows uložena v souboru ntds.dit 17 , který se nachází v adresáři %SystemRoot%\ntds 18 . Databáze je tvořena hierarchickou strukturou objektů – zdrojů, služeb a uživatelů v rámci domény a jejich atributů; s její pomocí může administrátor uplatňovat bezpečnostní politiky, rozmísťovat software nebo instalovat kritické aktualizace pro pracovní stanice. Pokud se v doméně nachází více řadičů domény, dochází k replikaci uživatelských záznamů a jiných objektů mezi databázemi Active Directory na jednotlivých serverech 19 . Pro zabezpečení Active Directory platí podobná pravidla jako u SAM. Hesla uživatelů jsou uložena v šifrované formě v podobě NTLM haše nebo tajného klíče (master key) protokolu Kerberos, jejichž vlastnosti jsme uvedli již dříve. V doménách Windows můžeme úspěšně hledat přístupové údaje ještě na dvou místech. Každý řadič domény obsahuje SAM databázi s uživatelskými účty, jednak z důvodů kompatibility a jednak 16
Systémový uživatel s neomezenými právy NTDS je původní název pro Active Directory na serverech Windows NT 18 Více informací viz Active Directory database file NTDS.DIT [online]. 2004 [cit. 2008-12-13]. Dostupný z WWW: . 19 Princip tzv. multi-master modelu 17
17
pro účely zálohy a obnovení databáze Active Directory v případě jejího kolapsu. Druhé místo najdeme na pracovních stanicích, které si ukládají haše hesel nedávných doménových přihlášení pro možnost práce na počítači v případech, kdy je řadič domény nedostupný či mimo provoz. Vypsat z cache lokálně uložené tikety umí aplikace Kerbtray a její varianta v příkazovém řádku Klist [1, str. 7]. Dodatečným zabezpečením pro oba typy LSA databází je tzv. syskey neboli systémový klíč, který chrání citlivé údaje ve chvíli, kdy systém neběží – při startu Windows je nahrán do paměti a následně použit pro dešifrování údajů. Syskey má 128 bitů a je výchozím způsobem uložen v registru lokálního systému [2, str. 42], může však být umístěn i na přenosný disk a následně vyžadován při startu. Shrneme-li si tedy zabezpečení uživatelských hesel pracovních stanic, pak první vrstvou je kontrola přístupu k souborům s hesly a druhou samotné šifrování hesel. Vzhledem k tomu, že existují poměrně snadné možnosti rozbití zejména LM haše, zůstává klíčovým řízení přístupu. Mezi základní starosti každého správce systému by mělo patřit adekvátní zabezpečení administrátorského účtu spolu s omezením jeho používání. Zejména pro kvalitu hesel poskytuje systém Windows více možností nastavení, které by měly být aplikovány pro dosažení optimální bezpečnosti.
3.2.3 Politiky bezpečných hesel Pro politiku bezpečných hesel jsou z pohledu této práce zajímavé následující dvě: politika uživatelských účtů (Account Policy) a lokální politika (Local Policy). V politice uživatelských účtů nás bude nejvíce zajímat vyžadovaná kvalita hesel a politika zacházení s nimi, u lokální politiky pak možnosti pro nastavení NTLM protokolu. Za tato a další nastavení je v systému Windows zodpovědná služba secpol.msc (Local Security Settings) dostupná přes dialog Start | Spustit. Politika uživatelských účtů Politika uživatelských účtů je v systémech Windows rozdělena na politiku hesel a politiku uzamčení účtů. Jednotlivé možnosti nastavení popisují tabulky 3.4 a 3.5.
20
Politika Enforce Password History Max. Password Age Min. Password Age Min. Password Length Password must meet complexity requirements
Popis politiky Počet bývalých hesel uživatele, které si systém pamatuje a u kterých zabraňuje jejich opětovnému použití Maximální doba platnosti hesla Minimální doba platnosti hesla (souvisí s první volbou) Minimální délka hesla uživatelů Zapíná filtr komplexity hesla, vyžadováno heslo délky nejméně 6 znaků, tvořeno alespoň třemi ze znakových množin [A-Z], [a-z], [0-9] a speciálních znaků. Nejsou povoleny části uživatelského jména [13, str. 22]. 3.4. Politika hesel (secpol.msc)
Doporučeno 20 5 a více
Politika Account lockout duration Account lockout treshold Reset account lockout counter after
Popis politiky Délka zablokování uživatelského účtu, po které je účet systémem automaticky odblokován Počet chybných přihlášení, po nichž dojde k automatickému zablokování účtu Počet minut od posledního chybného přihlášení, po nichž dojde k vynulování počítadla 3.5. Politika uzamčení účtů (secpol.msc)
Doporučeno 30-60 minut
30-90 dní 15 dní 8 znaků a více Zapnuto
5 30 minut
Doporučené nastavení pro podnikové systémy vyžadující vysokou míru zabezpečení, převzato z [14]
18
Lokální politika Lokální politika obsahuje široké spektrum nastavení z oblastí bezpečnostních auditů (logování přístupů) a řízení přístupových práv, my se však zaměříme pouze na politiky klíčové pro autentizaci uživatelů. Možnosti nastavení lokální politiky systémů Windows XP/Vista a Server 2003/2008 21 přehledně popisuje tabulka 3.6. Politika Network Security: Do not store LAN Manager hash value on next password change Network Security: LAN Manager Authentication level
Popis politiky Zabraňuje ukládání LM haše v SAM databázi uživatelů (uplatní se při další změně hesla)
Doporučeno
Nastavení zasílání/odpovědí na autentizační výzvy protokolů LM, NTLM a NTLMv2
Send NTLMv2 response only \ Refuse LM Require NTLMv2 session security
Network Security: Minimum session security for NTLM SSP based clients/servers
Zapnuto
Zabezpečení NTLM relace – vyžadována může být důvěrnost, integrita, 128-bitové šifrování, NTLMv2 zabezpečení relace (souvisí s předchozí volbou) 3.6. Lokální politika – nastavení pro autentizaci uživatelů (secpol.msc)
Důležité nastavení z našeho pohledu poskytuje zejména volba Network Security: LAN Manager Authentication level, pomocí které můžeme nastavit chování systému ohledně používání různých verzí NTLM protokolu (LM, NTLM a NTLMv2). V rámci této volby může uživatel nastavit různé kombinace pro zasílání a přijímání výzev, od povolení všech verzí protokolu pro zasílání i příjem, přes zasílání pouze NTLMv2 výzev a přijímání všech až po vyžadování NTLMv2 protokolu pro veškerou komunikaci [9]. Jako poslední volby nastavení v této sekci zmíníme nastavení protokolu Kerberos, dostupné výhradně na straně KDC serveru. Mezi nejdůležitější volby patří maximální délka platnosti (lifetime) tiketu ke využívání zdrojového serveru, maximální délka platnosti TGT a maximální doba, po kterou jde vydané TGT obnovit [2, str. 391-392].
3.3
Zkouška prolomení hesel
V praktické části této kapitoly otestujeme provedení útoku na v systému uložená hesla uživatelů. Zkouška bude koncipována jako porovnání LM a NT (MD4) hašů hesel uložených v databázi SAM. K prolomení hesel použijeme volně dostupný program Cain 22 , z jehož pomocí získáme hesla přímo z registru systému. Pro účely testu se k systému přihlašujeme jako administrátoři, jelikož aplikace nefunguje při přihlášení v kontextu účtu s omezeným oprávněním 23 . V rámci testu zvolíme čtyři různě kvalitní hesla a budeme sledovat celkovou dobu, během které dojde k prolomení hesel útokem hrubou silou (brute-force). Útok bude spuštěn na běžném notebooku 24 , tedy nikoli na stroji s optimalizovaným výkonem pro provedení útoku – na výkonnějším stroji lze předpokládat poměrné zkrácení doby potřebné pro rozlomení hesel, které však není z hlediska srovnání relevantní. Nebude-li uvedeno jinak, bude zvolena abeceda alfanumerických znaků (anglická abeceda s čísly), pro NTLM s rozlišením na velká i malá písmena. Pro zvýšení relevance výsledků útoku hrubou silou, které jsou ovlivněny pořadím, ve kterém jsou jednotlivé kombinace znaků zkoušeny, jsou brány v úvahu střední doby potřebné k rozlomení hesel o maximálně takové délce, jakou mají hesla zvolená. 21
Některé z těchto možností nejsou dostupné v systému Windows 2000 Program je dostupný na internetové adrese http://www.oxid.it/cain.html 23 Jinou možností je síťové odposlouchávání NTLM výzev a odpovědí nebo fyzický útok na disk 24 Dvoujádrový procesor o frekvenci 1,66GHz s 1,5 GB RAM 22
19
Tabulka 3.7 shrnuje výsledky testu pro prolomení hesel „ahoj2“, „mojeveci“, „petaA4“ a „m4alahruSka“ útokem hrubou silou na LM a NTLM haše: brute-force attack ahoj2 mojeveci 26 petaA4 m4alahruSka
LM NTLM 7 sekund 7 sekund 25 16 minut 6 hodin, 22 minut 4 minuty 20 sekund 1 hodina 42 minut 2 hodiny 30 minut 173 tis. let 3.7. Útok hrubou silou na hesla uložená v systému Windows
Z provedeného testu lze odvodit několik skutečností. Při všech útocích došlo ke znatelně delší výdrži hesla NTLM s výjimkou hesla prvního, jehož složitost nedosáhla omezení LM haše v délce ani abecedě. Toto heslo nelze v žádném případě považovat za bezpečné, a to v jakémkoli systému. Ani další dvě hesla nejsou bezpečná – u druhého hesla je problémem použitá abeceda, u třetího jeho délka. U těchto hesel se již však začínají projevovat slabiny LM hašů – druhé heslo je delší než sedm znaků, heslo třetí pak obsahuje velká i malá písmena. Markantní rozdíl mezi dobami prolomení obou hašů se ukazuje u kvalitního čtvrtého hesla, které naplno odhaluje nedostatky LM hašů (viz tabulka 3.2). Test vyvozuje tyto dva závěry: 1. Použijeme-li slabé heslo, pak nehledě na to, jaký protokol používáme k zabezpečení hesel v systému Windows, bude heslo prolomeno v krátkém časovém úseku 2. Ukládáme-li heslo ve formátu LM haše, pak i kvalitní heslo bude prolomeno v krátkém časovém úseku
25 26
Použita abeceda alfanumerických znaků (malých písmen a číslic) Použita abeceda 26 znaků anglické abecedy (malých písmen)
20
4. Autentizace pomocí tokenů V systému Windows je od verze 2000 implementována nativní podpora pro čipové karty různých typů s možností přidání jádra systému obsluhující tyto karty i do dřívějších verzí. Vzhledem k tomuto faktu se v této části práce výhradně zaměříme na popis existující infrastruktury, zatímco obecnými možnostmi rozšíření systému o další autentizační moduly se budeme zabývat v kapitole o biometrické autentizaci, pro kterou zatím ve Windows neexistuje nativní podpora 27 . V následujících sekcích budou diskutovány součásti rozhraní pro čipové karty, služby systému pro jejich obsluhu i prostředky, které systém poskytuje vývojářům. V závěru kapitoly si prakticky ukážeme přihlášení k doméně i lokální stanici pomocí čipové karty. Pro potřeby této práce odhlédneme od méně sofistikovaných zařízení a v rámci funkční generalizace budou od této chvíle čipové karty a tokeny synonymem.
4.1
Koncepty podpory čipových karet v systému Windows
Čipové karty jsou klíčovou součástí PKI infrastruktury integrované do systému Windows, poskytující bezpečnější řešení pro přihlášení uživatelů, autentizaci klientů vůči serveru nebo e-mailovou komunikaci. Karta je důležitým prostředkem pro konvergenci soukromých klíčů uživatelů a k nim náležících certifikátů, jelikož poskytuje jejich bezpečné úložiště a ochranu, zajišťuje izolaci kritických výpočtů týkajících se autentizace či vytváření klíčů od zbytku systému a umožňuje přenositelnost citlivých dat mezi různými počítači. Přístup společnosti Microsoft k vývoji prostředků pro čipové karty lze shrnout do těchto bodů (převzato ze [3]): a) standardní model rozhraní mezi čipovými kartami, čtečkami a počítačem umožňující komunikaci mezi zařízeními různých výrobců b) aplikační rozhraní nezávislá na konkrétním zařízení poskytující abstrakci od změn hardwaru a zjednodušující implementaci konkrétních funkčních požadavků c) nástroje pro vývoj softwaru, již implementované společné komponenty d) integrace se všemi platformami operačního systému
4.1.1 Standardy PC/SC Konsorcium PC/SC vzniklo v roce 1996 s cílem vyvinout specifikace pro komunikaci mezi počítači a čipovými kartami a vyřešit tak problém v komunikaci zařízení různých výrobců. Koncem roku 1997 vznikla první verze specifikací PC/SC 1.0, která je počínaje systémem Windows 2000 závazným standardem a zároveň podmínkou funkčnosti čipových karet v operačním systému. Členové konsorcia jsou mimo společnosti Microsoft také Sun Microsystems, IBM, Hewlett-Packard nebo Toshiba, stejně jako přední výrobci čipových karet – Schlumberger, Gemplus a další. Specifikace PC/SC 1.0 navazují na předchozí průmyslové specifikace EMV (Europay, MasterCard, VISA) a GSM (Global System For Mobile Communications) a stejně jako ony jsou založeny na požadavcích, které na fyzické, elektrické a datové parametry karet kladou normy ISO/IEC 7816 28 . Oproti předchozím normám se PC/SC zaměřují právě na problémy týkající se interoperability – společných uživatelských rozhraní, vývojářských nástrojů a sdílení zdrojů 29 .
27
V době psaní práce je ve vývoji systém Windows 7 (nástupce Windows Vista), který by měl poskytovat rozhraní pro autentizaci biometrikami (tzv. Biometric Framework) 28 Týká se dotykových karet, standardy pro bezdotykové karty určují normy ISO/IEC 14443 29 Více informací viz PC/SC Workgroup Specifications Overview [online]. [2007] [cit. 2008-12-13]. Dostupný z WWW: .
21
Koncem roku 2004 byly vydány PC/SC specifikace verze 2.0, které znamenají rozšíření podpory pro bezkontaktní čipové karty, synchronní protokoly nebo vylepšené rozpoznávání karet (Plug-andPlay) 30 . I přes některé dílčí pokroky, které například představují USB-CCID ovladače čipových karet, systémy Windows včetně Vista podporují v době vzniku této práce pouze PC/SC verze 1.0.
4.2
PC/SC architektura v systému Windows
V systému Windows jsou podle výše uvedených specifikacích integrovány některé základní komponenty pro systém čipových karet (Smart Card Base Components). Tyto komponenty tvoří (viz obrázek 4.1): a) Resource Manager, využívající API Windows b) uživatelské rozhraní (UI) pro Resource Manager c) několik základních poskytovatelů služeb (base service providers) poskytujících přístup ke specifickým službám karet prostřednictvím COM rozhraní (v protikladu uživatelského rozhraní)
4.1. Spolupráce mezi základními komponentami PC/SC architektury [3] V následujících odstavcích se podrobněji zaměříme na podporované poskytovatele služeb, Resource manager a ovladače zprostředkovávající komunikaci mezi zařízením a základními komponentami PC/SC architektury. 30
Více informací viz Presentation of the Interoperability specification for ICCs and Personal Computer Systems, Revision 2.0 [online]. 1999 [cit. 2008-12-13]. Dostupný z WWW: .
22
4.2.1 Poskytovatelé služeb (service providers) Ke každé čipové kartě musí existovat alespoň jeden poskytovatel služeb pro přístup aplikací ke specifickým službám karty. Existuje obecné dělení poskytovatelů služeb na kryptografické (Cryptographic Service Providers) a nekryptografické poskytovatele – toto dělení je důležité zejména z důvodu omezování importu a exportu kryptografických technologií vládami jednotlivých států 31 . V rámci tématu této práce se zaměříme výhradně na kryptografické CSP knihovny. CSP CSP jsou balíčky kryptografických funkcí, které zajišťují šifrování a dešifrování dat na kartě nebo přímo v systému Windows. Právě podle místa výkonu kryptografických operací dělíme CSP na softwarové (šifrování vykonává software), hardwarové (šifrování vykonává kryptografické zařízení) nebo kombinaci obou. Softwarové řešení je rychlejší a flexibilnější, zatímco hardwarové poskytuje větší bezpečnost oddělením kryptografických operací a soukromých klíčů od operačního systému. V PKI modelu domény Windows, který bude diskutován dále v této kapitole, je softwarových CSP využíváno na straně řadiče domény (certifikační autority a KDC), zatímco hardwarových pro implementaci kryptografických funkcí čipové karty. Operační systém Windows poskytuje softwarové CSP pro většinu moderních kryptografických protokolů, přičemž základní CSP implementují kryptografické protokoly společnosti RSA [8]. CSP asociované s čipovými kartami jsou ve Windows označovány také jako SCCP (Smart Card Cryptographic Provider) za účelem logického odlišení od ostatních CSP. CSP i SCCP poskytují dle standardu PC/SC své služby výhradně prostřednictvím unifikovaného rozhraní CryptoAPI. CSP čipových karet jsou typicky dodávány výrobcem přímo s kartami a jejich vývojáři musí zajistit jejich digitální podepsání společností Microsoft. Při každém nahrání CSP modulu je platnost tohoto podpisu ověřena a operační systém rovněž CSP periodicky kontroluje pro případ jeho kompromitace nebo útoku na něj. Počínaje Windows Vista nabízí operační systém univerzální SCCP, tzv. Microsoft Base Smart Card Cryptographic Service Provider. Tento poskytovatel nabízí výrobcům zařízení usnadnění při vývoji CSP, když sjednocuje obecná specifika pro více druhů zařízení. CSP dodané výrobcem pak již nemusí implementovat celou požadovanou kryptografickou funkcionalitu, ale pouze její části, které nejsou pokryty v univerzálním SCCP. Časti specifické kryptografické funkcionality jsou vkládány ve formě modulů, tzv. Smart Card Mini Drivers [10]. CryptoAPI CryptoAPI neboli Cryptographic Application Programming Interface je rozhraní, které v operačních systémech Windows poskytuje vývojářům prostředky k dosažení požadované aplikační funkcionality bez nutné znalosti konkrétních kryptografických operací. Ve své podstatě je CryptoAPI souborem DLL knihoven, které tvoří abstraktní vrstvu mezi aplikačním kódem a implementací kryptografických funkcí v CSP. CryptoAPI je schopno pracovat s více nainstalovanými CSP, které v modelu CAPI/CSP fyzicky vykonávají šifrování dat. Windows Vista obsahují inovovanou verzi CryptoAPI, tzv. CNG (CryptoAPI: Next Generation), která podporuje novější algoritmy 32 , umožňuje připojování CSP za běhu a poskytuje obecně větší flexibilitu.
4.2.2 Resource manager Při instalaci CSP typicky dochází k registraci rozhraní zařízení u služby Resource Manager (RM). RM je důležitá součást SC infrastruktury, přes kterou fyzicky probíhá komunikace mezi aplikacemi a 31 32
Proslavená je v tomto smyslu kauza Bernstein vs. USA Například kryptografické funkce založené na bázi eliptických křivek
23
kartou. Každý požadavek přístupu ke kartě je obsluhován právě touto důvěryhodnou službou, která jej přesměrovává do čtečky obsahující požadovanou kartu. RM je tedy zodpovědný za řízení a kontrolu přístupu veškerých aplikací do jakékoli karty připojené k systému. Funkci RM lze shrnout do tří bodů (převzato z [11]): a) identifikuje zdroje a jejich rozhraní b) alokuje zdroje čtečky/karty mezi více aplikací c) na z principu jednovláknovém zařízení řídí složitější transakce, které vyžadují více příkazů k dokončení jediné operace (zabraňuje přerušení transakce a porušení přechodného stavu jiným procesem) Z obrázku 4.1 vyplývají dva způsoby, kterými se dá ke službě RM přistupovat – přímo prostřednictvím poskytovaného rozhraní (Smart Card Resource Manager API) nebo nepřímo přes CSP. I když jsou oba přístupy z převážné většiny nahraditelné a poskytují podobné služby, k provedení některých operací musí aplikace využívat výhradně přímého rozhraní. Přístup přes CSP, jak ostatně vyplývá i z předchozích odstavců, je naproti tomu pro vývojáře obecně snazší pro implementaci [11].
4.2.3 Specifické ovladače zařízení V prvotním modelu čipových karet neexistoval žádný Plug-and-Play model pro automatickou instalaci čteček čipových karet. V systému Windows 2000 existovala pouze společná knihovna ovladačů (součást Smart Card Base Components) pro usnadnění vývoje specifických ovladačů zařízení. Kvůli rozšíření modelu WDM 33 a obecně sběrnice USB byly kladeny větší požadavky na unifikované ovladače zařízení, které vyústily ve vytvoření třídy ovladačů USB-CCID (Chip/Smart Card Interface Devices). Jakákoli USB čtečka karet, která splňuje požadavky kladené USB-CCID, bude fungovat ve Windows ihned po jejím připojení bez nutnosti instalace dalších ovladačů. Pro zařazení ovladače zařízení na seznam podporovaných operačním systémem Windows musí výrobce splnit podmínky programu WHQL 34 . Po otestování dostane povolení používat Windows Logo a odpovídající ovladače jsou zařazeny do Windows Update. Čtečky a karty podporované systémy Windows Přes avizovanou větší bezpečnost mají majitelé některých čipových karet a čteček problémy s kompatibilitou v systému Windows Vista. Obecně by měly být funkční karty fungující na principu modulů Mini Drivers a čtečky splňující požadavky USB-CCID. Z čistě hardwarových CSP jsou v současné době podporovány výhradně CSP karet Cryptoflex výrobce Schlumberger (Axalto), do jehož konsorcia patří po fůzi i Gemplus [16, str. 11].
4.3
Použití čipových karet k přihlášení
V následující části si podrobněji popíšeme využití čipových karet pro autentizaci uživatelů v doménách MS Windows. Jak jsme již rozebírali v části 3.2.1.2, systém Windows počínaje 2000 využívá k autentizaci uživatelů služeb otevřeného protokolu Kerberos. V této části jsme se také zmínili o rozšíření PKINIT (Public Key Cryptography for Initial Authentication), které v systémech Windows spojuje funkcionalitu protokolu s možnostmi asymetrické kryptografie. Z faktu, že autentizace na bázi čipových karet je ve Windows založena výhradně na protokolu Kerberos, můžeme odvodit také základní možnosti a omezení této metody. Předpokladem nasazení 33
Windows Driver Model, zahrnuje zařízení USB a IEEE 1394 Více informací viz Microsoft Corporation. Windows Logo Program: Overview [online]. c2008 [cit. 2008-1213]. Dostupný z WWW: .
34
24
autentizace kartami je přítomnost KDC systému Kerberos, stejně jako řadiče domény se službou Active Directory. K omezení na doménové přihlášení musíme u přihlášení čipovými kartami přidat také nutnou přítomnost infrastruktury veřejných klíčů, o které budou pojednávat následující odstavce.
4.3.1 PKI infrastruktura Infrastruktura veřejných klíčů ve Windows zabezpečuje vytváření, distribuci, správu a ověřování klíčů uživatelů domény. Díky úzké spolupráci s protokolem Kerberos používá PKI infrastruktura většinu služeb využívaných také při klasickém přihlášení pomocí hesel. V PKI tedy také nalezneme služby KDC a AD, které ve Windows typicky běží na jediném stroji, řadiči domény. Ke KDC a AD nově přibývá nová služba, a to certifikační autorita (Certification Authority, CA). Jak si ukážeme, pro přihlášení čipovými kartami je CA službou vůbec nejdůležitější a musí k ní existovat důvěra ze strany uživatele, KDC a všech strojů domény. 4.3.1.1
Certifikační autorita
V infrastruktuře veřejných klíčů zprostředkovává certifikační autorita do jisté míry funkcionalitu autentizační služby (AS) klasického systému Kerberos. Jak jsme si vysvětlili, AS je schopno autentizovat uživatele na základě sdíleného tajemství, zašifrovaného hesla. V modelu PKI je tajemstvím soukromý klíč uživatele a právě CA službou, která provádí prvotní ověření jeho důvěryhodnosti. Certifikační autorita systému Windows je zodpovědná za následující úkony: a) vytváření dvojic soukromých a veřejných klíčů uživatelů (spolu s jejich certifikáty) b) zabezpečenou distribuci soukromých klíčů uživatelům a publikování certifikátů jejich veřejných klíčů v AD c) ověřování platnosti certifikátů veřejných klíčů entit V rámci procesu vytváření klíčů a k nim náležících certifikátů je typicky ukládán soukromý klíč uživatele a certifikát jeho veřejného klíče na čipovou kartu. Certifikační autorita musí být správně nastavena k tomuto úkonu, a to jak pro vystavování jak certifikátů pro přihlášení čipovou kartou, tak kupříkladu pro podepisování e-mailů soukromým klíčem uživatele. V PKI modelu Windows může certifikáty vytvářet administrátor domény nebo zprostředkovaně sám uživatel. Certifikáty vydané CA a jejich uložení spolu dalšími údaji o uživateli splňují formát definovaný standardem X.509. 4.3.1.2
Proces přihlášení
Architektura na bázi čipových karet je založena na SSP/AP balíčku Kerberos, jehož začlenění mezi služby zodpovědné za autentizaci bylo popsáno v sekci 2.3.2. Níže popsaný proces přihlášení čipovou kartou je založen na asymetrické kryptografii a pro jeho účely je tajný klíč (master key) uživatele nahrazen vždy jedním z dvojice soukromý/veřejný klíč. Šifrování a dešifrování na straně uživatele probíhá prostřednictvím čipové karty s využitím soukromého klíče uživatele, zatímco stejné operace na straně KDC s využitím jeho veřejného klíče. Přihlášení ke stanicím Windows pomocí čipových karet probíhá v těchto krocích (ilustrováno na obrázku 4.2): 1. Po vložení čipové karty zavolá služba Winlogon zavolá rozhraní GINA (analogie se stiskem SAS sekvence) 2. Uživatel je vyzván k zadání PIN kódu (namísto jména a hesla)
25
3. GINA zasílá PIN službě LSA, která použije PIN k přístupu na kartu a extrakci certifikátu s veřejným klíčem uživatele 4. Kerberos SSP na počítači klienta zasílá KDC (AS) požadavek na vystavení TGT (PA-PKAS-REQ), která obsahuje UPN 35 uživatele a časovou známku, obojí zakódováno uživatelovým soukromým klíčem, a také kopii certifikátu uživatele 5. Po přijetí požadavku KDC nejprve zkontroluje u CA platnost certifikátu, poté v AD ověří příslušnost certifikátu k danému uživatelskému účtu. Pokud najde shodu, vygeneruje KDC nový klíč relace a zasílá jej klientovi zašifrovaný veřejným klíčem uživatele spolu s TGT (PA-PK-AS-REP) 6. Uživatel svým soukromým klíčem dešifruje klíč relace. Další komunikace mezi klientem, KDC a ostatními servery v doméně již je zabezpečena symetrickými klíči relace stejně jako v případě klasického přihlášení pomocí hesel, kterému se věnovala sekce 3.2.1.2. Stejně tak průběh neinteraktivního přihlášení ke zdrojovým serverům v doméně již probíhá v režii standardního protokolu Kerberos.
4.2. Schéma přihlášení čipovou kartou [2] Kromě podpory doménového přihlášení poskytují čipové karty v systému Windows další možnosti pro podepisování a šifrování e-mailů, zabezpečení přístupu k 802.1x sítím a VPN sítím, které leží mimo rámec tohoto textu. Nastavení pro přihlášení Stejně jako v případě hesel existuje více možností nastavení pro přihlášení čipovou kartou, tentokrát na straně KDC. Konkrétně může KDC vyžadovat čipovou kartu k přihlášení a specifikovat akci použitou při vyjmutí karty ze čtečky (odhlášení, zamknutí stanice, žádná akce).
35
Přihlašovací jméno uživatele (User Principal Name) ve tvaru [email protected], kde company.com je název stromu, ve kterém je uživatel registrován
26
4.3.2 Uložení klíčů a certifikátů Již v předchozí části jsme mluvili o uložení klíčů a certifikátů na straně řadiče domény – pro uložení těchto údajů je využíváno služeb AD v produktech Windows Server, která obsahuje certifikáty veřejných klíčů uživatelů. Na straně klienta je pak soukromý klíč a certifikát veřejného klíče uložen výhradně na čipové kartě, typicky paměti typu EEPROM. Platí také, že soukromý klíč jakožto tajemství uživatele je od ostatních veřejných objektů (veřejné klíče, certifikáty) oddělen.
4.4
Zkušenosti s přihlášením pomocí čipových karet ACOS5/2
V rámci praktické části kapitoly došlo k vyzkoušení čipových karet výrobce Advanced Card Systems Ltd. K testu byla použita čipová karta ACOS5 36 , plnokrevná PKI karta s 32 kB EEPROM paměti a karta ACOS2 s 16 kB EEPROM paměti podporující pouze symetrické šifrování. Zatímco karta ACOS5 sloužila k otestování přihlášení s využitím PKI systému Windows, pomocí karty ACOS2 bylo vyzkoušeno lokální přihlášení programem Dekart Logon 37 . Doménové přihlášení čipovou kartou Při doménovém přihlášení čipovou kartou je využíváno kryptografických funkcí karty a soukromého klíče uživatele umístěného v její paměti. Pro vytvoření soukromého klíče a publikaci certifikátu veřejného klíče v doméně Windows potřebujeme služeb certifikační autority, která byla v našem případě instalována na serveru Windows Server 2008 (viz obrázek 4.3).
4.3. Instalace služeb CA v produktu Windows Server 2008
36
Více informací o kartě viz Advanced Card Systems Ltd.. ACOS5 Reference Manual [online]. 2006 [cit. 200812-14]. Dostupný z WWW: . 37 Program je dostupný na internetové adrese http://www.dekart.com/products/access_control/logon (trial verze)
27
K uložení certifikátu na kartu jsme využili služeb webového rozhraní CA, ve kterém lze požádat o vystavení certifikátu pro přihlášení čipovou kartou (obsahuje soukromý klíč uživatele). Po exportu certifikátu (viz obrázek 4.4) jsme jej uložili na kartu prostřednictvím softwaru dodaném výrobcem karty 38 .
4.4. Detaily vystaveného certifikátu Po uložení soukromého klíče a certifikátu na kartu již je přihlášení do Windows jednoduché. Vzhledem k nativní podpoře není již ze strany výrobce softwaru nutné upravovat modul GINA – rovněž v našem případě (na stroji klienta instalován systém Windows XP Professional) došlo automaticky ke změně přihlašovací obrazovky (viz obrázek 4.5). Po vložení karty do čtečky a zadání PINu došlo automaticky k přihlášení uživatele dle bodu 4.3.1.2.
4.5. Přihlašovací rozhraní (Smart Card Logon)
38
Požadované CSP balíčky byly instalovány spolu se softwarem
28
Lokální přihlášení čipovou kartou Lokální přihlášení čipovou kartou není srovnatelné s výše popsaným doménovým a nevyužívá ke svému průběhu služeb PKI infrastruktury. Na rozdíl od předchozího případu, kdy byl na kartu uložen soukromý klíč uživatele a speciální certifikát, ukládá program Dekart Logon na čipovou kartu pouze login a haš hesla uživatele. Čipová karta je v tomto modelu využívána pouze jako úložiště a nezprostředkovává žádné vlastní kryptografické operace. Během prvního spuštění dojde k zformátování a tzv. aktivaci karty, během které jsou na kartu nahrány přihlašovací údaje jednoho nebo více uživatelů (na námi použité kartě ACOS2 je prostor pro 64 účtů). Program Dekart Logon umožňuje stejně jako v případě PKI nastavení akce použité při vytažení karty. Jak je vidět z obrázku 4.6, program podporuje rovněž tokeny s uloženými biometrickými údaji. Na rozdíl od doménového přihlášení zajišťuje v tomto případě Dekart Logon rovněž náhradu přihlašovacího modulu GINA – při přihlášení je opět vyžadováno vložení PINu uživatelem, po němž jsou údaje uložené na čipové kartě předány službě LSA.
4.6. Nastavení programu Dekart Logon Jak již bylo řečeno, dvě výše testované metody přihlášení k Windows čipovou kartou jsou neporovnatelné z principu, přesto je na místě malé shrnutí. Přihlášení pomocí obou metod je pro uživatele stejně pohodlné a obě metody poskytují podobné možnosti nastavení přístupu. Za zmínku stojí potíže při testování programu Dekart Logon (a tedy lokálního přihlášení) s čipovou kartou ACOS5, se kterou program nekomunikuje. Bohužel výrobce programu nebyl schopen ani po reklamaci dodat fungující verzi, podle dodavatele karty je důvodem fakt, že ACOS5 není přímým nástupcem karty ACOS2 (jedná se o funkčně zcela odlišné zařízení).
29
5. Autentizace pomocí biometrik Přihlášení biometrickými údaji je bezesporu nejpokrokovější metodou autentizace k operačnímu systému Windows. Vzhledem k logickým i technickým problémům popsaným ve druhé kapitole se však implementace konkrétních technologií a zejména nativní podpora operačním systémem neustále oddalují. Již v roce 2000 oznámila společnost Microsoft spolupráci se společností I/O Software Inc. s cílem začlenit biometrickou podporu do systému Windows, avšak dnes, po téměř devíti letech, je podpora biometrických technologií ve Windows stále velice skromná. Kvůli výše uvedeným skutečnostem se následující sekce zaměří na konkrétní možnosti přihlášení pomocí řešení softwarových a hardwarových dodavatelů, kupříkladu o integraci čteček otisků prstů a jiných technologií výrobci laptopů. Menší část této kapitoly bude věnována možnostmi pro integraci biometrických zařízení do Windows spolu s novými informacemi o připravovaném systému Biometric Framework, který chce Microsoft integrovat do nové verze operačního systému Windows.
5.1
Biometrické technologie v dnešní praxi
Následující odstavce mají za účel shrnout nejpoužívanější typy biometrických systémů v bezpečnostní praxi spolu s vymezením jejich klíčových vlastností z hlediska využití k autentizaci uživatelů v systémech Windows. Informace uvedené v této kapitole vycházejí převážně z [14]. Otisk prstu Snímání otisku prstu je bezesporu nejstarší a nejrozšířenější biometrickou metodou, jejíž kořeny sahají až do 19. století. Předmětem snímání jsou obrazce papilárních linií na spodní straně prstů u ruky nebo nohy člověka. Samotný proces snímání je relativně jednoduchý, otisk prstu vysoce unikátní a přitom stálý v čase. Spolehlivost metody zvyšuje i množství sebraných vzorků u jedné osoby (10 prstů na rukou). Nutnost digitalizace snímání otisků prstů si navíc vynutilo široké rozšíření této metody v kriminalistice. U otisků prstů registrujeme více způsobů snímání i fyzikálních principů snímačů. Z hlediska způsobu snímání rozlišujeme statické snímače (snímá se celý prst najednou) nebo šablonované snímače, po nichž uživatel během snímání přejíždí. Výhodou druhého řešení je menší plocha snímače a tedy i levnější snímací zařízení, první řešení je naopak pohodlnější. Podle použitého fyzikálního principu rozlišujeme snímače optické, elektro-optické, kapacitní, tlakové, tepelné a další. Pro nasazení této biometriky na lokálních stanicích hovoří zejména rozumná cena a velikost snímače, proti relativně jednoduché zkopírování otisku. Geometrie ruky Měření geometrie ruky je jednou z nejstarších biometrických technologií. Speciální CCD kamery měří délku, šířku, tloušťku a povrch jednotlivých prstů a celé ruky. Ač se jedná o technologii jednoduchou a v bezpečnostních systémech rozšířenou, jejím základním nedostatkem je nízká míra unikátnosti tohoto fyzického znaku a z ní plynoucí vysoká míra FAR. Využití metody k přihlašování k počítačům rovněž zamezuje velikost snímacího aparátu. Geometrie tváře Naproti tomu geometrie tváře je jednou z nejprogresivnějších biometrických technologií současnosti. Trojrozměrné modely lidské tváře poskytují vysokou míru komplexity při zachování rozumné složitosti získání biometrického vzorku. Klíčovými vlastnostmi pro úspěšnou autentizaci jsou tvar obličeje a vzájemná poloha jeho významných prvků. Algoritmů pro snímání obličeje je využíváno několik, od ukládání ve formě matice jasů jednotlivých částí obličeje až po vzdálenosti jednotlivých jeho prvků. Problémem metody je vysoká míra chybovosti při špatném osvětlení nebo sejmutí vzorku
30
ve špatném úhlu. Výhodou pro autentizaci uživatelů na pracovních stanicích je možnost sejmutí vzorku jednoduchou webkamerou. Duhovka oka Systémy pro rozpoznávání lidské duhovky patří k nejpřesnějším vůbec. Jsou založeny na vzorkování duhovky, svalu umožňujícímu akomodaci čočky, které není dáno geneticky, ale formuje se náhodně během prenatálního vývoje. Ověření probíhá porovnáním uložené duhovkové mapy se získaným vzorkem – podmínkou jeho sejmutí je infračervené světlo a kvalitní digitální kamera. Právě kvůli požadavkům na kvalitu technického vybavení je tato technologie určena spíše pro použití v prostředí vysoké bezpečnosti než na pracovních stanicích uživatelů. Sítnice oka Další z příkladů biometrických systémů s velkou mírou spolehlivosti vyžaduje stejně jako snímání duhovky speciální technologii snímání a zdroj světla. Kromě náročnosti na vybavení brání širšímu použití také nepohodlnost při snímání vzorků a z ní plynoucí vysoká míra FRR. Verifikace DNA Jedna z metod autentizace budoucnosti, která je již tři desetiletí využívána v kriminalistické praxi. Nepoužitelnost v tzv. real-time autentizačních systémech prozatím způsobuje časová náročnost analýzy vzorku, problémy činí rovněž cena a požadavky na vybavení. Kritickou nevýhodou pro použití v pracovních stanicích je opět problém živosti. Dynamika podpisu Výhodou dynamických metod obecně je jejich odolnost proti zfalšování. Vzhledem k přidanému prvku času je nemožné provést úspěšnou autentizaci pouze na základě podvržení statických dat (obrázek podpisu, heslo v případě dynamiky psaní na klávesnici). Základními veličinami, které jsou snímány u podpisu člověka, jsou rychlost, zrychlení, časování, tlak a směr tahu – ty jsou zaznamenávány do trojrozměrného souřadnicového systému. Výhodou této biometrické metody je z hlediska přihlašování k pracovní stanici možnost využití již existujícího zařízení (PDA, tablet), nevýhodou je pouze verifikační funkce zařízení (vzhledem ke komplexnosti podpisu). Dynamika psaní na klávesnici Pro dynamiku psaní na klávesnici platí podobné skutečnosti jako u předchozího snímání podpisu. Jako základní veličiny jsou měřeny doby stisků kláves a prodlevy mezi nimi. Využití klávesnice jako jediného autentizačního nástroje přímo předurčuje možnosti použití této metody k přihlášení k lokální stanici. Nutností je dostatečná délka snímaného vzorku, jinak mohou být vzorky více uživatelů zaměnitelné. Nevýhodou je (ve větší míře než u podpisu), že se dynamika psaní na klávesnici s časem mění, stejně tak v případě použití jiné klávesnice. Zajímavá je naopak možnost jejího využití jako sekundární metody autentizace, která může běžet na pozadí a vynutit v případě nutnosti další autentizační žádost. Charakteristika hlasu Zatím nepříliš rozšířená biometrická metoda poskytuje zajímavé možnosti pro přihlášení k pracovním stanicím. Jedná se rovněž o dynamickou metodu, jejíž komplexnost spočívá jednak v charakteristikách hlasu a jednak v použitých namluvených větách. Snímání je do jisté míry jednoduché a levné (stačí kvalitnější mikrofon), výhodou je také možnost použití ke vzdálené autentizaci. Problémem je požadavek na přesnost snímání v reálném prostředí s vyšší mírou hluku a možnost odchycení a analýzy uloženého vzorku a následného napodobení (hlasové syntetizátory).
31
5.2
Začlenění biometrik do autentizační architektury systému Windows
Jak již bylo naznačeno výše, až do verzí Vista / Server 2008 včetně neposkytují operační systémy Windows žádnou nativní podporu pro autentizaci biometrickými údaji. Pro výrobce softwarových a hardwarových řešení to v principu znamená, že nemohou využít sjednocující a zjednodušující prvky při jejich implementaci, což může vést k různorodým a často nestandardním řešením. V praxi musí výrobci implementovat konkrétní SSP/AP balíčky využívající pro přihlášení autentizační službu LSA. Spolupráce jednotlivých komponent je ilustrována na obrázcích 1.1 a 1.2, přičemž zopakujeme, že SSP/AP autentizační balíčky pro lokální a doménové přihlášení zajišťují potřebnou specifickou funkcionalitu, obsluhují vzorky získané biometrickým zařízením a ve své podstatě softwarově autentizační služby zajišťují.
5.2.1 GINA vs. Credential Providers Kromě vlastních autentizačních balíčků musí dodavatel biometrického nebo jiného vícefaktorového řešení dodat ještě upravenou verzi přihlašovacího rozhraní. Ve verzích Windows 95/98 a NT/2000/XP zprostředkovává funkce tohoto rozhraní modul GINA popsaný v kapitole 2, naproti tomu systém Vista přináší jiný způsob úpravy přihlašovacího rozhraní – tzv. Credential Providers. V následujících odstavcích se zaměříme na popis rozdílů mezi nimi a výhod nového systému oproti původnímu. GINA Základní nevýhodou modulu GINA je jeho komplexnost. I když je jeho základním posláním opravdu získání přihlašovacích údajů od uživatele a jejich předání LSA, má funkcionalita GINy ve skutečnosti záběr mnohem větší, kupříkladu automatické přihlášení, dále dialog bezpečnostních možností vyvolaný za běhu systému stiskem CTRL+ALT+DEL obsahující možnosti odhlášení, přepnutí uživatele, restart systému a další. Důsledkem byly velké problémy výrobců dodat funkční náhradu – často docházelo k výjimkám při přepínání uživatele nebo přihlašování pomocí čipových karet [4]. Další problémy se projevily při aktualizaci systému bezpečnostními balíčky (Security Packs), po kterých museli výrobci často nefunkční implementace nahrazovat jinými. Credential Providers Problémy s implementací náhrady za GINu byly vyřešeny ve Windows Vista zavedením modulárního řešení nazývaného Credential Providers (CP). Hlavní změny lze rozdělit na strukturní a aplikační. Ohledně strukturních změn došlo k oddělení instance služby Winlogon a modulu GINA (součást procesu Winlogon) od kritických částí jádra operačního systému běžících v tzv. session zero. Aplikační změny byly provedeny v návaznosti na problémy popsané v minulém odstavci. Dodavatelé dodatečných autentizačních metod se díky nim již nemusí starat o grafický vzhled, který je plně v režii operačního systému, pouze pomocí modulů CP přidávají požadované prvky přihlašovacího rozhraní a implementují požadovanou funkcionalitu. CP moduly jsou registrovány v operačním systému a při startu systému volány procesem LogonUI, který je namísto GINy zodpovědný právě za vzhled přihlašovacího rozhraní [4].
5.2.2 Způsob uložení a zabezpečení biometrických údajů Stejně jako u autentizačních balíčků, ani v případě způsobu uložení a zabezpečení biometrik není v systémech Windows používán žádný společný standard. Je nasnadě, že přidání biometrických prvků do zabezpečení přihlášení nemá valného smyslu, pokud pro ně neexistuje bezpečný přenos a úložiště. Možností úložišť je více – jednou z nich je vlastní řešení uložení i zabezpečení na lokálním disku, které rozhodně není ideální, avšak z nedostatku jiných možností nejrozšířenější. Druhou je spolupráce s databázemi LSA (Active Directory), která poskytuje větší míru zabezpečení, na druhou stranu nelze
32
předpokládat obecnější podporu bez přímé spolupráce se společností Microsoft. Problémem nadále zůstává zabezpečení přenosu biometrické informace mezi klientem a autentizační autoritou. Třetím řešením, které se momentálně nabízí k uložení citlivých biometrických údajů, je čipová karta (token) – biometrická charakteristika poté doplňuje znalost hesla a držení autentizačního předmětu a stává se součástí tzv. třífaktorové autentizace.
5.2.3 Třífaktorová autentizace Níže popsaný odstavec přímo předpokládá uložení biometrických dat na čipové kartě (autentizačním tokenu) a jeho spolupráci v ověření biometrických dat vložených uživatelem. Postup třífaktorové autentizace je zjednodušeně následující [5, str. 25-26]: a) b) c) d) e) f)
uživatel vloží autentizační token (čipovou kartu) uživatel je vyzván k vložení PINu token ověří PIN uživatel vloží svou biometrickou informaci token porovná vloženou informaci s uloženým vzorkem token zahájí komunikaci s autentizační autoritou s využitím důvěrných dat obsažených v tokenu (např. soukromý klíč) g) na základě komunikace s autentizační autoritou uživatel je autentizován
Vzhledem k výše popsaným skutečnostem lze momentálně považovat uložení biometrik na čipové kartě a jejich ověřování bezpečnostním tokenem za jedinou opravdu bezpečnou metodu přihlášení s využitím biometrik. Všimněme si, že stejně jako znalost PINu je v tomto modelu biometrická informace spíše prostředkem k přístupu k datům na tokenu, nežli samostatnou autentizační metodou. V současné době jsou k dispozici čtečky čipových karet, které obsahují integrované snímače otisků prstů – analýza vzorků je pak možná softwarově nebo hardwarově. Druhé řešení je z hlediska bezpečnosti ideální, jelikož biometrická data nikdy neopustí čtečku a potažmo čipovou kartu.
5.3
Aktuální možná řešení pro biometrickou autentizaci v OS Windows
Následující podkapitola bude věnována praktickým řešením biometrické autentizace, které jsou v době psaní práce dostupné pro přihlášení k OS Windows, bez nároku na jejich úplnost. Závěrem se zmíníme o modelu Biometric Framework připravovaném v novém systému Windows 7. Čtečky otisků prstů Čtečky otisků prstů jsou v současné době bezkonkurenčně nejrozšířenější biometrickou metodou pro přihlašování ke strojům s OS Windows. Na trhu je dostupné větší množství různých řešení – z nejpoužívanějších jsou to bezesporu zařízení integrovaná do laptopů a samostatné čtečky připojitelné přes USB rozhraní. Velkou slabinou těchto zařízení je zmíněný způsob přenosu a ukládání biometrických dat, které jsou od opravdu bezpečného řešení kus cesty vzdáleny. Spíše okrajovou záležitostí jsou zatím biometrické tokeny umožňující třífaktorovou autentizaci. Jednou z rozšířených externích čteček otisků prstů je Fingerprint Reader společnosti Microsoft, která je pro nás zajímavá zejména kvůli jejímu výrobci. O to víc možná překvapí, že firma samotná doporučuje využití zařízení výhradně k zabezpečení přístupových hesel k webovým stránkám v domácnostech a naopak odrazuje od používání v prostředí s požadovanou vysokou mírou zabezpečení [17]. Toto konstatování můžeme vnímat jako trochu ironické potvrzení současného tristního stavu biometrické autentizace v systému Windows – je vidět, že ani Microsoft samotný není schopen vyrobit spotřební produkt spolupracující s LSA databázemi a poskytující bezpečnou metodu přenosu dat ze zařízení do systému.
33
Integrovaných řešení čteček otisků prstů objevíme u výrobců laptopů poměrně velké množství. Vlastní řešení autentizace k OS Windows nabízí společnosti Hewlett-Packard, Toshiba, IBM Lenovo, Gateway nebo Asus. Řešení pomocí integrované čtečky přitom může poskytnout mnohem větší míru zabezpečení než čtečky externí. Technologie průkopníka v oboru, společnosti IBM, například využívá čip na základní desce k ukládání biometrických dat a zabezpečení jejich přenosu z čtečky. Vložení biometrik lze vyžadovat při startu počítače nebo pro přístup na zašifrovaný disk. Zajímavou možností je také zašifrování lokálních loginů a hesel a jejich následné poskytnutí při přihlášení. Nevýhodou zůstává výhradně lokální uložení biometrických dat, které znemožňuje využití technologie v síťovém prostředí. Geometrie tváře V posledních několika měsících (druhá polovina roku 2008) se objevily na trhu laptopy umožňující přihlášení ke stanicím Windows pomocí sejmutí obrazu tváře. V současné době tuto metodu podporují notebooky IBM Lenovo 39 a ASUS 40 , které snímají tváře uživatelů pomocí integrovaných webkamer. Řešení je podobné jako v případě otisků prstů, tedy uložení biometrických dat hardwarově na čipu základní desky. Vzhledem k možnostem integrovaných webkamer je omezeno přihlašování ve zhoršených světelných podmínkách, problémem také může být neoprávněné přihlášení uživatele s podobnými rysy (například příbuzného). Nevýhody popsané výše přetrvávají a odsuzují systém spíše pro použití v domácnostech – i marketingová kampaň spuštěná oběma výrobci je zaměřena spíše na větší míru pohodlí, nikoli bezpečnosti. Dynamika podpisu Dynamiku podpisu jako metodu autentizace k Windows nabízela několik let nazpátek ve svých tabletech společnost Toshiba. Systém byl schopen analyzovat styl psaní, akceleraci nebo tlak na pero. Problematická byla implementace systému, který si uchovával zašifrované údaje uživatele a po ověření podpisu je předkládal autentizační službě. Informace o uložení údajů a jejich ochraně známy nejsou. Dynamika psaní na klávesnici Velkou výhodou programů, které zaznamenávají dynamiku psaní na klávesnici, je univerzálnost použití vzhledem k minimálním požadavkům na vybavení. Jeden z produktů, který takovou funkcionalitu nabízí, je BioKeyLogon 41 . Jako nadstavba zmíněných hardwarových řešení existuje několik programů, které jsou teoreticky schopné poskytnout širší možnosti použití i v síťovém prostředí (například pomocí spolupráce s tokeny). Příkladem takových programů jsou například Ceelox ID podporující techniky SSO nebo SecureSuite XS společnosti I/O Software. Problémem těchto programů je vcelku pochopitelně menší kompatibilita vzhledem k chybějícím standardům v této oblasti zabezpečení.
5.3.1 Biometric Framework pro Windows 7 Na konferenci WinHEC 2008 začátkem listopadu představila společnosti Microsoft nový systém pro podporu autentizace pomocí biometrických charakteristik s názvem Windows Biometric Framework. Tento systém umožňuje nativní podporu biometrik v přihlašovacím procesu a bude s největší pravděpodobností obsažen v systému Windows 7, nástupci Windows Vista. Krátce po veletrhu 39
Lenovo Notebook's Veriface Security Technology ASUS SmartLogon Face Recognition Technology, možno také v kombinaci se čtečkou otisků prstů 41 Více informací o tomto a podobných produktech viz Biometric Authentication In Windows [online]. c2008 [cit. 2008-12-13]. Dostupný z WWW: . 40
34
oznámily podporu nového systému největší dodavatelé biometrických zařízení do laptopů, společnosti UPEK Inc. a AuthenTec. O konkrétních funkcích systému je v současné době známo velice málo, je však pravděpodobné, že systém bude podporovat zatím pouze přihlašování pomocí otisků prstů. Co je důležité, systém by měl konečně vyřešit softwarové řešení bezpečného skladování biometrických údajů.
5.4
Zkušenosti s přihlášením do Windows pomocí biometrik
V rámci praktické části páté kapitoly bylo vyzkoušeno přihlášení právě pomocí produktu společnosti Microsoft, čtečky otisků prstů Fingerprint Reader. Výrobce dodává k tomuto softwaru ovladače a program DigitalPersona Password Manager, který umí ukládat otisky jednoho až deseti prstů uživatele a nahrazením GINy zprostředkovává přihlášení. Práce s programem je velice jednoduchá – program nejprve musí zaregistrovat otisky uživatele, přičemž u každého prstu sejme čtyři otisky (viz obrázek 5.1).
5.1. Sejmutí vzorků otisků prstů Aplikace zprostředkovává v modelu autentizace otisky prstů náhradu modulu GINA a předává autentizační službě sebrané otisky prstů. Uživatel má možnost přihlásit se prostým přiložením jednoho ze sejmutých prstů (v tomto případě již nezadává PIN) nebo klasicky zadáním jména a hesla. Program samotný poskytuje pouze několik málo základních nastavení a neumožňuje například přesněji specifikovat požadovanou prahovou hodnotu, tedy míru shody uloženého a sejmutého vzorku. Program byl podroben krátkému testování, během kterého došlo k uložení otisků jednoho prstu – následně čtyři různí uživatelé testovali možnost přihlášení pomocí svých prstů (celkem tedy 39 vzorků mimo zaregistrovaného) – neúspěšně. Spolehlivě fungovala čtečka i v případě přihlášení „správným“ prstem, kdy se podařilo přihlášení v drtivé většině pokusů. Dodavatel softwaru bohužel neposkytuje údaje o použité prahové hodnotě, lze se tedy jen domnívat, že relativní spolehlivost čtečky v případě přihlášení oprávněného uživatele je vyvážena vysokou mírou FAR, která však vzhledem k omezeným možnostem testování nebyla prokázána.
35
6. Závěr 6.1
Podpora autentizačních metod v různých verzích OS Windows
Tato podkapitola shrnuje poznatky získané v předchozích kapitolách a poskytuje srovnání podpory jednotlivých autentizačních metod v různých verzích operačního systému počínaje Windows 95/98. Svým zaměřením představuje základ pro srovnání jednotlivých autentizačních metod. Autentizace pomocí hesel Autentizace heslem je základní metodou autentizace podporovanou systémy Windows od nejstarších verzí, ještě u Windows 95/98 je však situace problematická vzhledem k tomu, že systém umožňoval přihlášení ke stanici i bez znalosti jakýchkoli údajů. Rozumnou míru zabezpečení tedy jako první nabízel až systém Windows NT, potažmo Windows 2000, což jej předurčilo k použití v produkčním prostředí. Kromě zamezení přihlášení bez znalosti údajů již byly v systému implementovány nové bezpečnější protokoly pro přenos citlivých dat – NTLM různých verzí nahrazující ve Windows NT a novějších původní LM; a konečně otevřený standard protokolu Kerberos, který nabídl do té doby nedostupnou širokou škálu možností pro různé autentizační scénáře. Systémy Windows XP a pozdější Server 2003 pokračují v cestě započaté v předchozí verzi a rozšiřují možnosti již používaných autentizačních balíčků. Změny se dočkala kupříkladu přihlašovací obrazovka a některé možnosti nastavení. Také Windows Vista a Server 2008 nenabízí významnější rozšíření stávajícího modelu. Nejdůležitějšími změnami popsanými v předchozí kapitole je nahrazení modulu pro přihlašovací rozhraní uživatele a odstranění podpory původního protokolu LM ve výchozím nastavení systému. Za zmínku také stojí podpora protokolu AES v rámci systému Kerberos a přidání některých nových autentizačních balíčků a funkcí [12]. Autentizaci hesly v různých verzích Windows shrnuje tabulka 6.1. Hesla LM NTLM NTLMv2 Kerberos/PKINIT Windows 95/98 Ano Ne Ne Ne Windows NT Ano Ano Ano (SP4) Ne Windows 2000 Ano Ano Ano Ano Windows XP Ano Ano Ano Ano Windows Vista/7 Ano Ano Ano Ano 6.1. Podpora protokolů pro přihlášení hesel v různých verzích systému Windows Autentizace pomocí tokenů Podporu pro přihlášení tokeny, úzce svázanou s protokolem Kerberos, nabízí Windows počínaje verzí Windows 2000 – součástí systému jsou komponenty zajišťující bezpečnou komunikaci s různými čtečkami a paměťovými kartami. Následující úpravy (tedy ve verzích XP a Vista) jsou zaměřeny na rozšíření flexibility a použitelnosti systému – systém nově nabízí univerzální SCCP balíčky a systém rozšiřujících modulů. USB-CCID ovladače představené v roce 2003 dále zjednodušují práci vývojářům a výrobcům čteček paměťových karet. Systém Windows kromě výše uvedeného také zjednodušuje požadavky na certifikáty obsažené v paměťových kartách čímž rozšiřuje možnosti jejich použití [12]. Prostředky pro autentizaci tokeny v různých verzích Windows shrnuje tabulka 6.2. Tokeny Smart Card Base Components Base SCCP + MiniDriver Windows 95/98/NT Ne Ne Windows 2000/XP Ano Ne Windows Vista/7 Ano Ano 6.2. Prostředky pro podporu přihlášení čipovými kartami v různých verzích systému Windows
36
6.2
Srovnání autentizačních metod
V rámci této práce jsme si představili všechny tři metody, které momentálně systémy Windows podporují a pomocí nichž zajišťují autentizaci svých uživatelů. Pozorný čtenář by již po přečtení textu měl mít ucelenou představu o výhodách či slabinách jednotlivých metod, přesto je na místě krátké shrnutí. Výhody a nevýhody jednotlivých metod Autentizace hesly jako základní metoda poskytuje rozumnou míru zabezpečení a velkou flexibilitu – za předpokladu znalosti hesla se uživatel přihlásí kdykoli a bez nutnosti dále systému prokazovat svou identitu. Více než u ostatních metod se zde projevuje nutnost adekvátní politiky, problémem jsou zejména jednoduchá hesla i nevhodné nakládání s hesly ze strany uživatelů. Prvnímu problému se dá vyhnout správným nastavením, druhý naopak jednoduše řešitelný není. Kvůli flexibilitě a rozšířenosti autentizace hesly ve Windows existuje na internetu množství dostupných nástrojů pro odchycení hesel, čímž se pro útočníka stává rozlomení hesla pouze otázkou času. Autentizace tokeny je z hlediska bezpečnosti metodou kvalitnější, která má ve Windows dlouholetou nativní podporu. Zejména v podnikovém sektoru je možno naplno využít možností, které nabízí PKI infrastruktura v produktech rodiny Windows Server. Výhodou je také dobrá flexibilita daná dlouhodobým vývojem, umožňující používat čteček a karet různých výrobců spolu s různými autentizačními protokoly. Nevýhody jsou spíše obecného charakteru, především se jedná o nutnost reakce na nové formy útoků související s čipovými kartami, karty ztracené uživateli a karty případně získané útočníkem. Autentizace biometrikami dodává nový rozměr do autentizačních modelů, když umožňuje lépe rozlišit uživatele od stroje, který se za něj může vydávat. Již bylo řečeno, že využití biometrik v systémech Windows je v současné době omezeno a neexistuje pro něj nativní podpora. Problémem je zejména bezpečný přenos a uložení dat, stejně jako nemožnost jejich použití v síťovém prostředí. Doporučení pro autentizaci uživatelů Tak jako v případě bezpečnosti obecně můžeme konstatovat, že optimální řešení pro autentizaci ve Windows neexistuje. Platí, že nejslabším místem systému je lidský prvek, který dokáže efektivně vynulovat výhody jednotlivých přístupů například zapsáním svého hesla na lístek u monitoru. Částečným řešením tohoto problému je vyžadování kombinace autentizačních metod a tedy využití některé silnější autentizační metody jako doplňku ke klasické autentizaci hesly. Použití více metod najednou chrání systém před „náhodnými“ útoky nezkušených uživatelů a efektivně komplikují život i zkušenému útočníkovi. Standardem pro autentizaci k systému zůstává autentizace hesly s adekvátní bezpečností politikou specifikující kvalitu hesel a způsob nakládání s nimi (viz podkapitola 3.2.3). Pro domácnosti a jejich v podstatě izolované systémy postačí tato základní autentizační metoda, která zabrání jednoduchým útokům 42 . Pro systémy s vyšší požadovanou bezpečností by mělo být povinností vyžadování dodatečného autentizačního prvku – v současné době se jeví jako vhodnější (a levnější) jednoznačně autentizace tokeny. Optimální cestou pro podnikové řešení je i třífaktorová autentizace (popsaná v části 5.2.3), která přidává k autentizaci i biometriky a obchází jejich nevýhodu, kterou je omezená podpora systémem Windows.
42
Autor předpokládá, že zkušený útočník bude mít možnost, jak dodatečné zabezpečení obejít, kupříkladu se fyzicky zmocnit pevného disku
37
6.3
Závěrečné shrnutí
Práce je zaměřena na autentizační metody podporované systémy Windows. Kromě základního rozdělení a popisu obecných principů nabízí přehled implementačních specifik a standardů, které se vážou k jednotlivým metodám. Cílem práce bylo seznámit odborného čtenáře s aktuální situací autentizace uživatelů v systému Windows, poskytnout mu přehled a srovnání tří metod autentizace. První část práce poskytuje úvod do problematiky a popis služeb systému, které slouží k obsloužení autentizačních žádostí uživatelů. Důležitý pro další část textu je zejména popis autentizační architektury pro interaktivní i neinteraktivní přihlášení uživatelů. Klíčové kapitoly práce se dopodrobna věnují jednotlivým autentizačním metodám z pohledu jejich prosazování v operačním systému. Práce sleduje a hodnotí způsob zabezpečení citlivých údajů, místa jejich uložení v systému i požadavky na jejich kvalitu. Práce se věnuje i popisu podporovaných autentizačních protokolů a autentizačních zařízení. Součástí práce byla praktická část, která shrnuje zkušenosti autora s přihlášením pomocí všech tří metod. V rámci testů bylo vyzkoušeno rozlomení uložených hesel, přihlášení k systému pomocí tokenů a biometrické charakteristiky. Závěrem se práce věnuje vývoji autentizačních schémat v různých verzích systému Windows, shrnuje získané poznatky, poskytuje srovnání autentizačních metod a navrhuje adekvátní řešení pro autentizaci uživatelů.
38
Použitá literatura 1.
DE CLERCQ, Jan, BALLADELLI, Micky. Windows 2000 Authentication. [online]. 2001 [cit. 2008-12-13]. Dostupný z WWW: .
2.
DE CLERCQ, Jan, GRILLENMEIER, Guido. Microsoft Windows Security Fundamentals. Oxford : Elsevier Digital Press, 2007. 805 s. ISBN 978-1-55558-340-8.
3.
DE CLERCQ, Jan. Smart Cards [online]. c2008 [cit. 2008-12-13]. Dostupný z WWW: .
4.
GRIFFIN, Dan. Desktop Security : Create Custom Login Experiences With Credential Providers For Windows Vista [online]. 2007 [cit. 2008-12-13]. Dostupný z WWW: .
5.
MATYÁŠ, Vašek, KRHOVJÁK, Jan, et al. Autorizace elektronických transakcí a autentizace dat i uživatelů. Brno : Masarykova univerzita/Nakladatelství, 2008. 125 s. ISBN 978-80-210-4556-9.
6.
Microsoft Corporation. Authentication (Windows) [online]. c2008 , 25.9.2008 [cit. 2008-11-20]. Dostupný z WWW: .
7.
Microsoft Corporation. Directory Services (Windows) [online]. c2008 , 17.9.2008 [cit. 2008-12-13]. Dostupný z WWW: .
8.
Microsoft Corporation. Microsoft CryptoAPI and Cryptographic Service Providers [online]. c2008 [cit. 2008-12-13]. Dostupný z WWW: .
9.
Microsoft Corporation. Network security: LAN Manager authentication level [online]. 2005 [cit. 2008-1213]. Dostupný z WWW: .
10. Microsoft Corporation. Smart Card Minidriver Specification [online]. c2008 [cit. 2008-12-13]. Dostupný z WWW: . 11. Microsoft Corporation. Smart Card Resource Manager [online]. c2008 [cit. 2008-12-13]. Dostupný z WWW: < http://msdn.microsoft.com/en-us/library/aa380148(VS.85).aspx>. 12. Microsoft Corporation. Windows Vista Security : New Authentication Functionality in Windows Vista [online]. 2006 [cit. 2008-12-13]. Dostupný z WWW: . 13. O'DEA, Michael. HackNotes Windows Security Portable Reference : A Must-have Resource for Critical Security Information. McGraw-Hill Professional, 2003. 250 s. ISBN 978-00-722-2785-7. 14. ŠČUREK, Jaromír. Biometrické metody identifikace osob v bezpečnostní praxi [online]. 2008 [cit. 2008-1213]. Dostupný z WWW: . 15. ŠEVEČEK, Ondřej. Architektura Microsoft Windows : Autentizace ve Windows [online]. [cit. 2008-12-13]. Dostupný z WWW: . 16. ŠEVEČEK, Ondřej. Architektura Microsoft Windows : Smart Cards [online]. 2007 [cit. 2008-12-13]. Dostupný z WWW: . 17. WETTERN, Joern. The State of Biometric Authentication. Redmond magazine [online]. 2005 [cit. 2008-1213]. Dostupný z WWW: .
39
