eToken 72k Java PRO a SAC 8.1 na (Gentoo) Linuxu

Krátké howto o rozchození dalšího USB tokenu na nezastaralé distribuci Linuxu. Dříve jsem se zmiňoval o tom, jak rozchodit Rainbow iKey 3000 s pomocí OpenSC. Jelikož iKey 3000 už dnes svými parametry asi příliš nezaujme (jen 1024b RSA klíče) a navíc už ani není moc k dostání. Bylo tedy na místě poohlédnout se po nějaké náhradě. Kandidátem se stal SafeNet eToken PRO 72k Java (dříve Aladdin, nyní označovaný jako SafeNet eToken 5100 – nicméně všechno to jsou shodné tokeny). Ten již není podporovaný pomocí OpenSC (alespoň ne nijak jednoduše), za to ale originální middleware (SAC – SafeNet Authentication Client) podporuje celou škálu operačních systémů (Linux, MacOS X, Windows). Nicméně; podpora na Linuxu lehce pokulhává, pokud je distribuce novější 2 let, ale dá se to rozchodit :) 

K rozchození je potřeba SafeNet Authentication Client 8.1 (SAC) – tedy Linuxová verze originálního middlewaru. Dodává se jako RPM balík pro některá RPM distra a deb balík pro Ubuntu. Po vyzkoušení na Ubuntu 12.04 stačilo deb balík nainstalovat a vše fungovalo. Nicméně tak trochu závisí na tom, co pcscd zrovna načte (viz dále). Na gentoo je dále problém s tím, že narozdíl od Ubuntu zde zcela chybí HAL. SAC zjevně bez HALu fungovat dokáže, nicméně daná knihovna musí v systému existovat, jinak middleware nelze spustit a spadne. Celou instalaci včetně nabastlení HALu však lze usnadnit – existuje overlay, ve které se nachází ebuild pro SAC. Ebuildu stačí předhodit RPM balík, sám jej rozbalí a SAC nainstaluje. Potřebujeme tedy funkční naši overlay. Pokud nemáme, tak do /etc/make.conf přidáme:
  1. PORTDIR_OVERLA­Y=„/usr/local/por­tage“

A v /usr/local vytvoříme sloužku portage a do ní stáhneme ze zmíněné overlay app-crypt/etoken-sac – včetně celé cesty! Následně pomocí emerge etoken-sac nainstalujeme SAC. V první fázi nás instalace ebuildu vyzve k umístění RPM balíku do /usr/portage/dis­tfiles. Pokud se tak provede, měla by proběhnout instalace. V mém případě z nějakého důvodu se portage nelíbí, že nemá uživatelské patche a proces spadne. To lze vyřešit úpravou ebuildu a ve funkci src_prepare zakomentovat řádky začínající epatch (case in-sensitive). Mělo by stačit v adresáři s ebuildem vytvořit složku patches (mkdir patches). Ta zde chybí patrně kvůli tomu, že v git repozitáři v ní žádný patch není a git pracuje se soubory, takže prázdnou složku nevytvoří. Dřívější postup je stále možný a funkční, nicméně je pak třeba ještě příkazem ebuild etoken-sac-8.1.ebuild digest přegenerovat kontrolní součty, které teď kvůli změněnému ebuildu nesedí. Nyní bysme měli mít nainstalováno, ale stále to bohužel neznamená, že to funguje :)

SAC přichází s vlastním ovladačem pro pcscd. Ten ovšem nefunguje jak má a jeho načtení do pcscd se nepovede; tím není detekován ani žádný token a nefunguje to. Naproti tomu máme ovladač ccid, což by mělo mít něco jako generický ovladač pro smartcard, tedy alespoň pro ty, které se drží nějakých standardů. Když se podíváme na web projektu, tak se dozvíme, že náš eToken 72k je zařazen v unsupported zařízeních. Když zkoumáme dál, tak zjistíme, že je to pro to, že token jaksi nezkousne warm reset, který třeba OpenSC defaultně dělá. Naštěstí, jak se zdá, SAC to nedělá a s tímto generickým ovadačem, narozdíl od originálního, funguje dobře. Nutno ještě dodat, že tyhle operace dosti závisí na verzích. Pro info, sestava na které mi to chodí, je ccid 1.4.5 (s flagem usb) a pcsc-lite 1.8.3 (s use flagem udev). Nainstalujeme tedy ccid. Potom ještě v /usr/lib/reader­s/usb odmažeme aks-ifdh.bundle – tedy smažeme originální pcsc ovladač, čímž zabráníme tomu, aby se načítal místo ccid. Restartneme pcsc-lite, nastartujeme eTSrv (má initscript v /etc/init.d) a budeme se modlit. Spustíme grafickou utilitu pro správu tokenu (etProps) a zasuneme token do USB portu. Pokud to vyšlo, v levé části obrazovky se objeví detekovaný token.

Jestliže jsme na 64b systému a chceme token používat i v 32b aplikacích, máme ještě jeden oříšek. Ebuild, ze kterého jsme instalovali, automaticky instaloval i dodávané 32b comapibility knihovny. Tedy PKCS#11 knihovnu zkompilovanou i pro 32b. Ta ovšem nejspíše při vyzkoušení nebude ještě fungovat. Je to patrně kvůli chybějícímu nebo nevyhovujícímu pcsc-lite v 32b verzi. Pro rozchození pomůže stáhnout z webu pcsc-lite zdrojáky stejné verze jakou máme nainstalovanou. Následně je ručně zkompilujeme pro 32b – stačí v terminálu, ze kterého spustíme svatou trojici, spustit:
  1. export CFLAGS=-m32
a nainstalujeme. Nyní by token už měl fungovat i v 32b aplikacích.

Token by v tuhle chvíli měl být normálně funkční. V aplikacích je nutno přidat PKCS#11 knihovnu, ta by se měla nacházet v cestě /usr/lib/libeT­Pkcs11.so. Zároveň je nainstalován i grafický správce od SafeNetu – lze ho spustit příkazem etProps. Bohužel nemá všechny funkcionality, které by pro správu byly ideální, ale existuje jedno řešení. V balíku opensc se nachází i utilita pkcs11-tool (neplést s pkcs15-tool). Umí podobné věci co pkcs15-tool, nicméně lze ji parametrem –module předat libovolnou PKCS#11 knihovnu. Pomocí pkcs11-tool lze potom například i generovat RSA klíče přímo v tokenu a podobně. pkcs11-tool

EDIT 19.8.2012

Na základě komentářů provádím pár úprav:

  • V textu jsem přehodnotil nutnost upravovat ručně ebuild. Viz ta škrtnutá část :)
  • Grafická utilita potřebuje ještě postarší libpng-1.2. Toho jsem si dost možná nevšiml kvůli tomu, že už se mi instalovala díky nějaké jiné aplikaci. Napravit by to měl příkaz emerge –1 =libpng-1.2.49
  • Pro jistotu ještě přikládám initscript pro eTSrv, který jsem dost možná v editačním záchvatu upravoval (a i to množství zakomentované části tomu nasvědčuje…). Minimálně tahle verze mi eTSrv startuje bez problémů. Tady je:
  1. #!/sbin/runscript
  2.  
  3. # Distributed under the terms of the GNU General Purpose License v2
  4. # $Header: $
  5. # Description:       eTSrv This starts, stops, and reloads the eToken eTSrv daemon
  6.  
  7. NAME=eTSrv
  8. DAEMON=${NAME}
  9. name=„eToken eTSrv daemon“
  10. command=„/usr/bin/${NA­ME}“
  11. command_args=„${EX­TRA_OPTS}“
  12. pidfile=„/var/run­/${NAME}.pid“
  13.  
  14. start_stop_da­emon_args=„-q -u pcscd:pcscd -n ${NAME}“
  15. start_stop_da­emon_start_ar­gs=„-k 000“
  16. start_stop_da­emon_stop_args=„-R TERM/2/KILL/5“
  17.  
  18. depend() {
  19.         need pcscd
  20. }
  21.  
  22. checkconfig() {
  23.         „${DAEMON}“ –test > /dev/null || return 1
  24. }
  25.  
  26. start_pre() {
  27.         if [ „${RC_CMD}“ != „restart“ ] ; then
  28.                 checkconfig || return 1
  29.         fi
  30. }
  31.  
  32. stop_pre() {
  33.         if [ „${RC_CMD}“ = „restart“ ] ; then
  34.                 checkconfig || return 1
  35.         fi
  36. }
  37.  
  38. #start() {
  39. #       checkconfig || return 1
  40. #       ebegin „Starting ${SVCNAME}“
  41. #               start-stop-daemon -k 000 -S -q -p „${PIDFILE}“ -x „${DAEMON}“ -n „${NAME}“ – „${DAEMON_ARGS}“
  42. #        eend $?
  43. #}
  44.  
  45. #
  46. # Function that stops the daemon/service
  47. #
  48. #stop() {
  49. #       if [ „${RC_CMD}“ = „restart“ ] ; then
  50. #               checkconfig || return 1
  51. #       fi
  52. #
  53. #       ebegin „Stopping ${SVCNAME}“
  54. #               start-stop-daemon -K -q -R TERM/2/KILL/5 -p „${PIDFILE}“ -n „${NAME}“
  55. #               # Many daemons don't delete their pidfiles when they exit.
  56. #               rm -f „${PIDFILE}“
  57. #               rm -f „/tmp/${NAME}“
  58. #       eend $?
  59. #}

Díky za commenty :)

Komentáře

Výborný návod, už dlouho jsem hledal něco na rozchození SAC na Gentoo. Mám ale následující připomínky (všechny jsou k chybám v ebuild):
- problém s patches lze vyřešit vytvořením prázdné složky "patches" ve "files" místo mazáním v ebuildu
- manifest jsem musel vygenerovat znovu pomocí "ebuild etoken-sac-8.1.ebuild digest"
- init script z ebuildu je zřejmě nedodělaný a má chyby, SPM nemohl bys postnout tvůj init script ?

V každém případě díky, jestli to bude fungovat, tak mně to ušetří otravné spouštění Windows XP v qemu virtualizaci na Gentoo, kdykoliv potřebuji použít token.

Úpravy jsem provedl. Předpokládám, že po vytvoření adresáře patches (nějak mi nedošlo, že to stačí a je to tím, že prázdný adresář z gitu se nevytvoří) není potřeba přepočítávat crc ebuildu, jelikož k jeho změně nedošlo. Doplnil jsem informaci o libpng (zjevně už mi kvůli něčemu v systému trčela) a přiložil jsem svůj initscript k eTSrv. Nezkoumal jsem jak vypadal originál, ale podle toho množství zakomentovaných věcí jsem se v něm hrabal :) Je teda, upřímně řečeno, pěkně zprasený a nebude v něm fungovat stop a restart, nicméně na samotné spuštění eTSrv mi zjevně funguje dobře - eTSrv jede a po rebootu všechno funguje hladce :)

etProps potřebuje archaickou knihovnu libpng12.so.0, která je dávno nahrazena libpng15.so.0, je tedy třeba provést:

emerge -1 =libpng-1.2.49

Díky za opravy. Co se týče init skriptu, tak jediná změna, kterou tam máš, je přidání řádky "DAEMON=${NAME}". Zdá se mi ale, že tento skript ti eTSrv nestartuje (nebo alespoň mně ne :-) ). Když jsem zrušil komentáře u start a stop, tak už to eTSrv nastartuje, ale stejně mi to token nedetekuje (eToken 5100). Grafická utilita mi chodí, ale všechno je zašedivělé. Nemůžeš zkusit zjistit jak opravdu eTSrv startuješ, protože mám takové tušení, že to bude v těch parametrech ?

Tak už to jede. V původním init skriptu jsem přidal řádku z tvého skriptu "DAEMON=${NAME}", odkomentoval jsem start a stop procedury a řádek v checkconfig proceduře jsem odkomentoval a přidal "return 0". Pak je ještě třeba zadat bezpečnostní zařízení do Firefoxu v Předvolby, Rozšířené, Šifrování, Bezpečnostní zařízení dát tlačítko Načíst a jako název souboru modulu dát /usr/lib/libeTPkcs11.so .

Řádek v checkconfig proceduře jsem samozřejmě "zakomentoval" :-)

checkconfig() {
# "${DAEMON}" --test > /dev/null || return 1
return 0
}

OK, jinak jsem to teď zkoušel a po rebootu ni to eTSrv nastartovalo samo (je spuštěné právě s parametrem --test) a token jede. Ale čert ví, na čem všem je to ještě závislé :) Ale tak hlavně že se nakonec zadařilo :)