Masarykova univerzita Fakulta informatiky

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. Úvod... 2 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: <http://lasecwww.epfl.ch/pub/lasec/doc/oech03.pdf>. 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 V systémech Windows XP/Vista je kombinace CTRL+ALT+DEL ve výchozím nastavení vypnuta 5 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 7 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 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. LM haš NTLM haš Maximální délka hesla 14 znaků 256 znaků Abeceda omezená ASCII, case-insensitive ASCII, case-sensitive Rozdělení hesla 7 znaků Ne Použitá funkce DES MD4 Délka klíče 56 bitů 128 bitů 3.2. LM vs. NTLM haš 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: <http://web.mit.edu/kerberos/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

Mezidoménové přihlášení 3.3. Autentizace pomocí protokolu Kerberos [15] 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