BioAPI

Základním kamenem softwarové implementace nejen na unixu je standard vzniklý v rámci Biometric konsorcia nazvaný BioAPI. Před velmi krátkou dobou vyšla specifikace verze 2.0, avšak v současné chvíli jsou dostupné pouze implementace postavené na verzi 1.1 respektive 1.2 a i kdyby v budoucnu přišla zařízení BioAPI 2.0 kompatibilní, budou zároveň kompatibilní i s BioAPI 1.1.

Tento standard je velmi důležitý především proto, že de facto sjednocuje komunikaci jednotlivých aplikací s různými "drivery", v názvosloví BioAPI nazývaných BSP.

Z UML diagramu je velice dobře vidět způsob práce s BioApi. V zásadě může být v systému i více zařízení různých výrobců a každé je pak přístupné přes svoje BSP. Api je stejné pro MS Windows i ostatní systémy, avšak implementace se samozřejmě liší a tím je také dáno to, že BSP až na některé velmi specifické případy jsou nepřenosné mezi platformami.

Problémem na unixu však zůstává fakt, že ani po více než roce existence unixové implementace BioAPI téměř žádné aplikace s existencí biometrické autentizace nepočítají. Je to dáno tím, že teprve na konci září se objevil první BSP umožňující práci s reálným zařízením (konkrétně to byla beta verze zařízení firmy UPEK).

PAM

Jednou z mála aplikací, které spolupracují s BioAPI (kromě několika ukázkových) je pam_bioapi modul. Je to velmi důležité, protože pam modul umožňuje využít autentizace přes BioAPI nepřímo i drtivé většině ostatních aplikací.

To znamená, že jakmile úspěšně nainstalujeme BSP příslušného zařízení a správně nakonfigurujeme PAM, rázem jsme schopni používat biometrický snímač pro ověření například pro utilitu su, provést enroll pomocí standardní utility passwd, přihlašování pomocí login atd.

Má to ovšem svůj háček. Současná implementace pam_bioapi je velmi omezená a řekl bych skoro až minimalistická. Tak například při pokusu o přihlášení na konzolu se nevyhnete zadání username a až potom místo výzvy k zadání hesla vás systém požádá o provedení autentizace pomocí fingerprintu. Jinak řečeno, současná implementace pam_bioapi vůbec neimplementuje mechanizmus identifikace, tak jak jsem ho popsal v podkapitole autentizace versus autorizace a identifikace.

BioAPI má pro identifikaci speciální funkci a měl by ho tedy implementovat BSP, ale například právě driver pro čtečku v laptopech IBM/Lenovo podporuje pouze funkce samotné one-to-one autentizace. I kdyby ale BSP UPEKu měl implementovanou funkci identifikace, pam_bioapi tuto funkci zatím neumí využít. Je to dáno především datovým modelem, který využívá pam_bioapi. V současné implementaci dostane modul při svém natažení jako první parametr identifikaci BSP, které se pro autentizaci má použít a jako druhý parametr pak cestu k adresáři, kde jsou ukládány jednotlivé BIR, každý v jednom souboru.

Tento systém je sice naprosto transparentní pro uživatele, ale je velmi málo přizpůsobitelný. Znamená mimo jiné to, že uživatel může mít definován pouze jeden BIR, i když prstů na rukou má člověk obvykle 10!

Jsou tu také nezanedbatelné bezpečnostní problémy: jak zaručit, že uživatel si bude moci vytvořit BIR ze svého kontextu, ale přitom nebude moci vytvořit soubor pro jiného uživatele? První část požadavku by splňovalo nastavení sticky bitu na příslušném adresáři, ale tím právě dosáhneme nesplnitelnosti druhého požadavku.

Mít celou databázi BIR záznamů v jednom souboru a kontrolu autorizace přístupu k příslušnému záznamu nechat na aplikaci, jejíž běh bude povýšen pomocí suid bitu na úroveň roota (tak jako když passwd přistupuje k /etc/passwd souboru) se zdá být lepším řešením.

Když už hovořím o /etc/passwd zdůrazním zde, proč se nehodí ukládat BIR záznamy zde (respektive na moderních unix systémech v /etc/shadow), například místo hashe reprezentující heslo. Především bychom tím ztratili možnost alternativního přihlášení heslem. Dále bychom jen velice ošklivě mohli jednomu uživateli přiřadit více BIR záznamů. Jediný způsob, na který jsem přišel, by vedl na případ, kdy každý BIR jednoho uživatele by měl definovaný rozdílný řetězec reprezentující username, ale stejné UID by zapříčinilo, že po přihlášení by takovýto "pseudo uživatelé" měli stejná práva. Nejzásadnější je ale problém velikosti. Sice BIR vytvořený zařízením firmy UPEK má cca 200 B, ale pokud budeme vycházet z toho, že v budoucnu mohou na trh dorazit další zařízení s podporu v unixech a představíme si třeba, že takovýto záznam bude obsahovat obrazová data oční rohovky nebo nekomprimovaný záznam hlasu, může pak dosáhnout i několika desítek MiB a tedy pro uložení v textovém souboru, kde by navíc mělo docházet k parsování a prohledávní, se rozhodne takováto data nehodí.

Daleko lepší řešení je nasadit pro správu BIR záznamů některou z takzvaných embedded databází. Na základě srovnávacího testu embedded databazí jsem původně chtěl doporučit databázi TDB, která je součástí projektu samba. Embedded databáze jsou v podstatě jen implementací hash tabulky nad souborem. Nepříjemné ale je, že jedno klíčové slovo smí mít pouze jedna data. Dalo by se to sice řešit přidáním nějakého rozlišujícího znaku za username a číslem, takže do databáze by se druhý BIR uživatele guest uložil pod klíčovým slovem guest:2, ale je to řešení polovičaté a hlavně jen o velmi málo lepší než řešení s ukládáním BIR do souborů.

Nejlepší by zřejmě bylo použití jiné embedded databáze a sice SQLite. Zde již je možné mít klasickou databázovou strukturu s několika tabulkami, které ale ve výsledku jsou uloženy v jediném binárním souboru. Další obrovskou výhodou je licence této knihovny. Knihovna je vyvíjena jako public domain, což znamená, že i proprietární projekt může bez problémů přilinkovat staticky tuto knihovnu (čímž se zvětší o pouhých 250 KiB). Důsledkem je, že v budoucnu může vniknout proprietární BSP, který bude schopen přistupovat ke stejným datům jako pam_bioapi a používat je například k identifikaci.

Nespornou výhodou je také to, že všechny dotazy již budou v kódu definovány jako SQL (SQLite je téměř kompatibilní s SQL-92) a tedy, pokud by z nějakého důvodu v budoucnu bylo třeba podporu pro nějakou velkou databázi jako je MySQL nebo Postgresql, byl by přechod velmi bezbolestný.

Naopak nevýhodou je overhead s vyhodnocováním dotazů. Troufnu si ale říci, že na dnešních strojích bude tato nevýhoda zanedbatelná.

Screensaver

Na unixech již jen velmi zřídka setkáte s používáním zastaralého xlock, a tak jsem se zaměřil především na xscreensaver. Základní problém, který každý hned zaznamenal po instalaci pam_bioapi je, že xscreensaver vždy nabídne box pro heslo a až potom zavolá funkce PAM a tedy dojde k zobrazení okénka příslušného BSP. Dokonce je to tak nepohodlné, že když nevyplníte žádné heslo, PAM se ani nezavolá!

Proto jsem napsal velmi jednoduchý patch, který přidá do konfigurace volbu, zda nejprve zavolat PAM a až potom zobrazit při neúspěchu box pro heslo. Jednoduché, ale velmi účinné.

Patch však ještě neřeší jednu situaci: totiž pokud omylem zavadíte o klávesnici, ale nechcete ještě odemknout počítač, pak už natrvalo v takovém případě zůstane zobrazena výzva k verifikaci pomocí biometrického snímače. Tady je třeba předat do pam_bioapi hodnotu timeoutu definovaného v konfiguraci xscreensaveru tak, aby pam_bioapi mohlo tuto hodnotu předat jako parametr funkci z BioAPI.

Knihovna PAM má pro tento případ speciální funkci pam_misc_paste_env() pomocí níž je možné tento parametr předat PAM modulu.

XDM

Tato aplikace je takzvaným session managerem. Pokud situaci poněkud zjednoduším, dá se říci, že se jedná v podstatě o grafickou obdobu textové utility login, která se stará o přihlášení do systému.

Základním problémem XDM (a potažmo i ostatních session managerů, které se od XDM liší jen šíří nastavení, které je možné provést v logon dialog, a knihovnou, na které jsou postaveny) je, že automaticky počítá s klasickou metodou přihlašování a tak vždy nabídne username a password a teprve po jejich vyplnění volá PAM pro ověření a autorizaci.

Zde již ale nevystačíme případným patchem, který by rovnou zavolal PAM modul. Zatímco u xscreensaveru je uživatelské jméno jasné (je stejné jako uživatele, který počítač zamkl), tak zde se předpokládá, že uživatel musí být teprve nějak určen. Je tedy zde nutné použít buď modul, který implementuje identifikaci, nebo alespoň dopsat do pam_bioapi identifikaci typu one-to-few.

Firefox

Webový prohlížeč Firefox má zabudovanou správu hesel. Pro autentizaci je ale problém v tom, že hlavní přístupové heslo šifruje privátní klíč (v profilu uživatele jako key3.db) a ten je pak použit pro zašifrování hesel ukládaných v souboru signons.txt. Bohužel, přečtený BIR není zdaleka vždy stejný, dokonce se dá říci, že podle pozorování je vždy jiný a tedy jako heslo sám o sobě použít nejde.

V BioAPI je na podobný problém pamatováno a při vytváření BIRu je možné funkci BioAPI_Enroll() podstrčit payload, který je při budoucí shodě při autentizaci vrácen. Myšlený účel je přesně stejný: místo hesla mít možnost použít otisk prstu a při porovnání a ověření totožnosti použít toto uschované heslo.

Problém je ale s oním uschováním. Heslo je totiž součást BIRu a záleží jen na dodavateli BSP, jestli bude nějak heslo chráněno a jak. Na aplikační úrovni se s tím již mnoho dělat nedá. Přímo od autora BSP UPEKu mám informaci, že payload v jejich BSP nijak dál chráněno není. Určitým řešením by bylo, kdyby BIR nebyl uložen na disku, ale kupříkladu přímo v čtečce. Čtečky UPEKu v sobě na to paměť mají (je to paměť používaná kupříkladu při ověřování otisku prstu na úrovni BIOSu). Naneštěstí však pomocí unixového BSP nelze nijak tuto paměť využít (prý tato funkce byla zakázána IBM).

Každopádně pro náš případ domácí uživatel je zřejmě řešení payloadu v rámci BIR záznamu dostatečné, ale pro druhý případ rozhodně ne. Problém je vlastně takový nekonečný had, který si požírá vlastní ocas: abychom zabezpečili heslo v BIRu, museli bychom databázi zašifrovat - jenže jak zašifrovat databázi bezpečně bez použití jednosměrné hashe a bez použití hesla?

Doporučené laptopy IBM/Lenovo Thinkpad mají zabudovaný TCPA chip, který mimo jiné umožňuje PKI správu přímo uvnitř vestavěného obvodu. Jinak řečeno, uvnitř tohoto chipu je možné vygenerovat privátní klíč a ten se nikdy nedostane ven z tohoto obvodu.

Na Linuxu existuje implementace TSS 1.1 nazvaná TrouSerS. Na kompletní popis této technologie zde není dost prostoru, ale pokud dopíšeme do knihovny umožňující přístup k tomuto zařízení autentizaci uživatele pomocí BioAPI, máme v podstatě vyhráno. K privátnímu klíči, který šifruje ostatní hesla se dostaneme jen na aktuálním počítači (laptopu) a jen přes knihovnu, která bude místo hesla vyžadovat biometrickou autentizaci. Aby se celý systém nedal obejít pomocí prostého nabootování CD, doporučuji využití TrustedGrub, který zpřístupňuje další možnost TCPA chip chipu, totiž že kontroluje na úrovni BIOSU hash uloženou v chipu a pokud nesouhlasí s hashí aktuálně natahovaného kernelu (tedy například při pokusu nabootovat CD), tak zablokuje další práci. Kernel bez podpory dynamického natahování modulů je pak na zabezpečeném systému dnes už samozřejmostí.

Abychom se vrátili k samotnému Firefoxu, tak tady je možné zpřístupnit TCPA pomocí nastavení takzvaného "Security device manageru". Jedná se vlastně o možnost nastavit zde knihovnu s definovaným API, která je pak používána jako šifrovací zařízení.

gnupg

V tomto případě je situace velice podobná jako v předchozí kapitole. Za normálních okolností zde je na disku uložený privátní klíč, který je zašifrován za pomocí hesla symetrickou šifrou. Po rozšifrování stejným heslem je pak možné privátní klíč použít k podepisování emailů, v nejnovější verzi 1.9.19 pak také k rozšifrování zprávy S/MIME a nebo k autentizaci ssh pomocí gnupg-agenta, který je náhradou za ssh-agenta.

Pro přidání pohodlnější autentizace pomocí biometrie stačí upravit gnupg, aby používalo TCPA chip funkce, před které bude autentizace přes BioAPI.

Závěr

V textu jsem se snažil postihnout rozbor nejpoužívanějších aplikací a to, jak jsou na nástup těchto zařízení připraveny. Zjistil jsem, že současný stav není vůbec povzbuzující, většina aplikací prostě předpokládá "natvrdo" použí hesla, ale zároveň jsem ukázal, že existuje řešení a že se dá dosáhnout i poměrně bezpečné implementace.