SSH a GPG klíče na čipové kartě

10.4.2014 01:13 | Přečteno: 2450× | | poslední úprava: 10.4.2014 11:12

Poslední dobou jsem řešil, jak se bezpečně a pohodlně přihlašovat přes SSH ke strojům, o které se starám. Doposud jsem většinou používal SSH klíče uložené na lokálním disku a SSH agenta. To má ale nevýhody. Není to pohodlné ve chvíli, pokud člověk používá mnoho různých počítačů či se občas potřebuje přihlásit odněkud z cest. A klíč na disku, nebo dokonce na flashce, může být také poměrně snadno zcizen.

Začal jsem se tedy rozhlížet po způsobech autentizace, které tyto problémy řeší. Tedy něco přenosného, hůře zkopírovatelného a použitelného třeba i na počítačích, které nejsou úplně důvěryhodné. Jako ideální se zde jeví čipová karta kompatibilní se standardem OpenPGP. Na té je možné buď klíče vygenerovat, nebo je tam zkopírovat z PC, a následně je nosit všude s sebou.

Jak jsem se dostal od SSH k PGP? GnuPG agent se mimo cachování PGP klíčů, což je jeho původní úkol, také umí tvářit jako SSH agent. Lze do něj pak vkládat jak klasické SSH klíče pomocí ssh-add, tak právě i klíče na čipových kartách standardu OpenPGP. Vzhledem k tomu, že PGP samotné občas používám a budu tak tedy mít možnost umístit na tutéž kartu i klíče na podpisy a šifrování, volba je jasná.

Kde a co koupit?

V podstatě se nabízí tři možnosti:

1. OpenPGP karta a Gemalto Token. Tuto variantu jsem volil já. Nezapomeňte si kartu objednat ve vylamovací variantě, pokud ji tedy nechcete krájet nebo stříhat. Čtečky samozřejmě můžete použít i jiné. Zajímavé jsou ty, které umožňují zadání PINu z vlastní klávesnice a jsou odolné proti keyloggerům, ale zase nejsou typicky příliš vhodné na přenášení.
2. YubiKey NEO vyniká svou velikostí, pohodlně se dá nosit na klíčích a cenově se příliš neliší od předchozí varianty. Zajímavá je i podpora NFC, ale nejsem si jist, nakolik funguje v OpenPGP režimu. Zde zatím nemám zkušenost, ale rozhodně se chystám vyzkoušet.
3. GPF CryptoStick je zdaleka nejzajímavější, ale starší verze je delší dobu vyprodaná a na nové se teprve pracuje. Takže tady prozatím nic.

Určitě jsou i další, ale jsou o dost méně zdokumentované. Pokud máte jeden notebook, který všude nosíte s sebou, doporučuji se podívat i na TPM čipy. O tom ale třeba někdy jindy.

Příprava karty

Budeme potřebovat nějaký ten software - GnuPG (balík gnupg nebo gnupg2, verze alespoň 2.0.18) a ovladače (pro USB čtečku pcsc-lite a ccid). Pokud ve vašem distru existují oddělené balíky gpgsm a gnupg-agent, potřebujete i ty. Na některých distribucích se spustí pcscd automaticky po vložení karty, jinde ho budete muset spustit ručně. Tenhle software budete potřebovat jak pro inicializaci, tak i pro každodenní provoz na každém počítači, kde chcete kartu použít. Dále se vám může hodit opensc pro některé méně časté operace s kartou, jako je třeba smazání klíčů.

Výpisy z GnuPG budu často krátit o ty méně podstatné informace. Zároveň se nebudu zmiňovat o místech, kdy se ptá GnuPG na heslo či PIN, protože je to během celého procesu zhruba 153x.

Po vložení karty nejprve vyzkoušíme, jestli GnuPG kartu vidí:

$ gpg --card-status

Application ID ...: 
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 0000729B
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Pokud se vám podobný výpis nezobrazí, je na čase začít ladit - ověřit, jestli pcscd opravdu běží, jestli má přístup k USB zařízení a podobně.

Před použitím karty je nutné nastavit PIN. Karta má dva - administrativní, kterým se upravují nastavení karty a pracuje s klíči, a PIN pro běžné operace, jako je podpis, dešifrování a přihlášení.

$ gpg --card-edit
gpg/card> admin
Admin commands are allowed
gpg/card> passwd

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 1
PIN changed.

A následně uděláme totéž pro Admin PIN. PIN nemusí obsahovat pouze čísla, může to být libovolné heslo o délce alespoň 6 znaků pro běžný PIN a 8 znaků pro admin PIN. Pozor na to, že karta se zablokuje po třech chybných pokusech o jeho zadání. V gpg --card-edit můžete dále nastavit množství metadat na kartě, ale kromě URL k veřejnému klíči, ke kterému se dostanu později, je GnuPG k ničemu nepoužívá.

Klíče

Nyní musíme na kartu dostat klíče. Ty buď můžeme vygenerovat přímo na kartě, nebo je vygenerovat v počítači a do karty následně nahrát. Osobně preferuji druhou možnost, která dává možnost klíč někam před uložením na kartu zálohovat a dobře uschovat. Pokud ho vygenerujeme na kartě, ven už ho nedostaneme a pokud karta někdy později přestane fungovat, bude veselo. Navíc nám tento postup umožňuje použít již existující PGP klíče, pokud nějaké máme, což budu dále předpokládat.

Pokud ne, můžete si je vygenerovat pomocí gpg --gen-key, typ RSA a RSA o velikosti 4096 bitů. Na kartě je sice napsáno, že umí klíče pouze do velikosti 3072, ale to platilo pouze pro GnuPG starší než 2.0.18. Nějaké další informace o tom, jak klíče generovat, najdete třeba zde, zejména část o použitých algoritmech je u trochu starších verzí GnuPG nutné čtení.

Ať už nějaký máme, nebo jsme ho třeba vygenerovali, bude vypadat nějak takhle.

$ gpg --list-keys
pub   4096R/8F1DD759 2014-04-07
uid                  nobody <nobody@nowhere>
sub   4096R/6FE9D59F 2014-04-07

$ gpg --expert --edit-key nobody@nowhere
pub  4096R/8F1DD759  created: 2014-04-07  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/6FE9D59F  created: 2014-04-07  expires: never       usage: E   
[ultimate] (1). nobody <nobody@nowhere>

Ve výpisu vidíme jeden hlavní klíč určený k podepisování a jeden podklíč určený k šifrování. Musíme si tedy vyrobit ještě jeden, který bude určen k přihlašování (usage: A). Proto jsme použili --expert, jinak GnuPG tuto možnost nezobrazuje.

gpg> addkey

Please select what kind of key you want:
   (8) RSA (set your own capabilities)
Your selection? 8

Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Sign Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Zde je třeba, aby klíč podporoval pouze authenticate, tudíž postupně vybereme S, E, A a Q.

Possible actions for a RSA key: Sign Encrypt Authenticate 
Current allowed actions: Authenticate 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q
What keysize do you want? (2048) 4096
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

Really create? (y/N) y

pub  4096R/8F1DD759  created: 2014-04-07  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/6FE9D59F  created: 2014-04-07  expires: never       usage: E   
sub  4096R/0D69BC63  created: 2014-04-07  expires: never       usage: A   
[ultimate] (1). nobody <nobody@nowhere>

Teď už jen klíče nahrát na kartu. Pokud je chcete zálohovat, teď je vhodná chvíle napsat 'save' a buď někam odzálohovat adresář ~/.gnupg, nebo provést gpg --export-secret-keys.

Karta má k dispozici celkem 3 pozice na klíče. "Signature key" na klíč na podpisy, "Encryption key" pro šifrovací klíč a "Authentication key" pro přihlašování různého druhu (pro naše účely to bude SSH).

Poznámka pro pokročilé: Tohle může být trochu problém ve chvíli, pokud se držíte doporučené konvence a chcete používat i samostatný podklíč pro podpisy. V takovém případě bych asi postupoval tak, že bych na kartu uložil tři podklíče, a hlavní klíč následně uložil někam do chládku a nechal ho tam až do doby, než token ztratím, podklíčům vyprší platnost nebo do příchodu domů z nějaké podpisovací párty. Ha-ha.

Prvně přesuneme hlavní klíč:

$ gpg --expert --edit-key nobody@nowhere

gpg> toggle

gpg> keytocard
Really move the primary key? (y/N) y

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

Pokračujeme podpisovým klíčem.

gpg> key 1 

gpg> keytocard

Please select where to store the key:
   (2) Encryption key
Your selection? 2

A nakonec klíč přihlašovací.

gpg> key 2

gpg> keytocard

Please select where to store the key:
   (3) Authentication key
Your selection? 3

sec  4096R/8F1DD759  created: 2014-04-07  expires: never     
                     card-no: 0005 0000729B
ssb  4096R/6FE9D59F  created: 2014-04-07  expires: never     
                     card-no: 0005 0000729B
ssb* 4096R/0D69BC63  created: 2014-04-07  expires: never     
                     card-no: 0005 0000729B
(1)  nobody <nobody@nowhere>

gpg> save

Všechny tři klíče jsou teď na svém místě na kartě a zároveň odstraněny z disku.

Nastavení GnuPG agenta

Teď potřebujete zajistit, aby se vám gpg-agent spouštěl v rámci session, což bude typicky záležitost dost závislá na distribuci a na prostředí, které používáte. Je hlavně potřeba zajistit, aby se spouštěl s parametrem --enable-ssh-support, a zároveň zneškodnit běžného SSH agenta a GNOME Keyring, který se také jako SSH agent umí tvářit. To se dá udělat tak, že je prostě nebudete spouštět, nebo alespoň nějak zajistíte, aby proměnné prostředí GPG_AGENT_INFO a SSH_AUTH_SOCK ukazovaly tam, kde naslouchá GnuPG agent.

Pokud jsme udělali všechno správně, po spuštění ssh-add -l by se nám měl zobrazit fingerprint klíče, který leží na kartě. Pomocí ssh-add -L potom dostaneme veřejný klíč.

$ ssh-add -l
4096 64:f5:e5:a1:d9:77:af:27:75:2b:0e:7b:26:57:3d:a4 cardno:00050000729B (RSA)

$ ssh-add -L
ssh-rsa AAAAB3N....F3J4w== cardno:00050000729B

Teď už stačí celý řádek s veřejným klíčem zkopírovat do ~/.ssh/authorized_keys na všech počítačích, kam se chceme pomocí karty přihlašovat, a máme hotovo.

Co dál?

Asi je vhodné se chvíli dívat do manuálových stránek a trochu si GnuPG dokonfigurovat a více se s ním sžít. Nejspíše si budete chtít vyladit dobu, po kterou si agent pamatuje zadaný PIN.

Pokud budete chtít použít kartu jinde, než kde jste ji vytvořili, pro SSH to jde v podstatě rovnou. Pokud je nainstalován software uvedený výše, stačí zprovoznit a spustit agenta. Pokud chcete používat i GnuPG část, je potřeba natahat veřejné klíče. To se dělá v gpg --card-edit příkazem fetch. GnuPG pro nalezení klíče buď použije URL uložené v metadatech karty, nebo použije veřejný keyserver.

Dokumentace je dost mizerná a tohle jsem posbíral asi z patnácti různých blogů. Obecně jsem z těch pár dnů, kdy jsem se tomuhle věnoval, nabyl dojmu, že GnuPG je naprostá hrůza a potřebovalo by spoustu lásky. Zejména v oblasti uživatelského rozhraní, dokumentace, lepších defaultů, dokumentace, celkové snadnosti použití a dokumentace. Uvědomuji si, že tento způsob použití je celkem nestandardní, ale bez karty to není o tolik lepší. End-to-end šifrování potřebujeme víc než kdy jindy, ale celý ekosystém kolem PGP je hluboko v minulosti. Nedávno jsem zahlédl zmínku o projektu, který se snaží vývoj GnuPG oživit. Vedle toho se zase objevují první kryptovlaštovky typu keybase.io, které se snaží vylepšit koncept sítě důvěry. Jsou to sice zajímavé kroky, ale spíše mám pocit, že by bylo vhodnější GnuPG udržovat pro těch pár případů, kde dobře slouží a zapracovat na novém a transparentnějším systému. Protože ve chvíli, kdy se PGP zeptá běžného uživatele, jestli důvěřuje klíči málo, středně, úplně nebo ultimátně, jsme prostě prohráli, ať už umíme šifrovat sebelépe. A pokud náhodou uživatel neuteče hned, dopadne to pak třeba takhle.        

Komentáře

[petr_p]

Teď už stačí celý řádek s privátním klíčem zkopírovat do ~/.ssh/authorized_keys

s/privátním/veřejným/

[SPM]

Yubikey NEO funguje NFC i v gpg režimu, ale zase jenom pro OTP... na druhou stranu OTP autentizace na tom má výhodu - pokud si to na tom serveru povolíš taky, tak se s tím přihlásíš i z podezřelých počítačů, víceméně všude, kde funguje USB klávesnice. Na druhou stranu do Yubikey nejdou klíče nahrát, musí se tam vygenerovat...

ad veřejné klíče - musíš je napřed nahrát aspoň na ten keyserver, jinak máš smůlu :))

Čistě na SSH jdou použít i klasické smart karty (nebo tokeny), tedy na ukládání X509 certifikátů + PK. Ty sice na gpg nepoužiješ, ale zase můžeš podepisovat/šifrovat certifikátem (S/MIME). ssh-agent přes PKCS#11 s tim umí komunikovat, nicméně ještě jsem neměl v ruce verzi, kde by to fungovalo spolehlivě. Resp. klasický problém je, že tam přidáš token, všechno funguje, ale ve chvíli, kdy token vytrhneš, aniž bys z agenta klíče odstranil, tak už to fungovat nebude, dokud se agent nespustí znovu.

[SPM]

ehm, mělo to být nové vlákno, ale to už je fuk...

[xm]

Klíči vygenerovanému nějakým uzavřeným hardwarem bych osobně tedy nedůvěřoval Jedině vygenerovat v PC a na klíčenku nahrát.

[SPM]

Ono to má i druhej pohled. Klíč vygenerovanej v nějakym hardwaru pak typicky existuje jenom v tom hardwaru a nikde jinde. Což u PC s nějakým OS ten klíč už může mít hned po vygenerování NSA Lidi si kupujou i HSMka za děsný peníze, mimojiný aby ty klíče se neválely někde na disku.

[xm]

O klíči vygenerovaném uzavřeným proprietárním hardwarem či softwarem mohu automaticky předpokládat, že k němu má NSA zadní vrátka (ve smyslu že byl vygenerován třeba s nějakým úmyslně poškozeným RNG, atp.). Samotný klíč sice třeba nijak nezíská, ale vše co je s ním zašifrované dokáže rozšifrovat

[SPM]

Tak on ten hardware v počítači máš víceméně taky proprietární; nepočítám, že by sis CPU lepil pájkou :) Software možná sice ne, ale ruku na srdce, kdo ty zdrojáky OpenSSL četl a rozumí jim.

Nicméně, jaké jsou šance, že budeš zajímat NSA/KGB/whatever tak, aby ti strkali hw s backdoorem a nějak zásadně tě to trápilo (pač na takové úrovni už se dá dělat hromada jiných věcí, že čtení šifrované komunikace bude to poslední, co člověka zajímá) a jaké jsou šance, že se ti do někdo bude snažit do PC dostat kus softwaru, kterému defakto jenom stačí zkopírovat soubor z filesystemu a někam ho poslat? :)

[xm]

Tady nejde o to, že zrovna tobě by cíleně poslali upravený hardware s backdoorem (to se děje jen high-value cílů), ale o to že takové jednoúčelové zařízení na generování klíčů je lákavý cíl, aby tam byl nějaký obecný backdoor ve všech.

Prostě všechny klíče vygenerované tím zařízením by byly pro NSA děravé. Po leaknutých informacích o věcech jako Dual EC DRBG bych se tomu vůbec nedivil (a pokud by výrobce byl americká firma, očekával bych i že mohli klidně dostat příkaz tam tam takový backdoor umístit a nikomu o tom nesmět říct - viz National Security Letters, Lavabit, atp.)

[SPM]

Oproti tomu s klíčem na disku ten tvůj klíč má každej, kdo se na minutu dostane k shellu, kus malwaru, kterej se dostane na FS normálního uživatele a tak podobně. A konec konců kdoví, jestli ten NSA backdoor neni i v CPU, takže čert ví, co PC vygeneruje :) Nemyslim si, že to ve finále bude lepší :)

Navíc ty "backdoorový" hardwary pro generování klíčů budou mít instituce jako banky apod., takže stejně by o tobě měli dost informací i bez tvého přičinění :))

[xm]

Pokud bych používá bezpečný systém (speciálně čistý image jen na práci s citlivými údaji) bootovaný třeba z flashky, tak je to dle mého názoru mnohem méně pravděpodobné, než že bude backdoorovaný nějaký proprietární hardwarový klíč.

[SPM]

A vážně když chceš pokaždé poslat e-mail, tak rebootneš počítač, nabootuješ na flash vyndanou z trezoru, pošleš mail a pak zase rebootuješ zpátky, aby jsi mohl koukat i na web? Ono pak je nejbezpečnější si to napsat na počítači bez netu a zašifrované vytisknout, akorát to uživatelské pohodlí je pak někde úplně jinde... takže buď se na to šifrování/podepisování pak kašle úplně nebo se používá běžně za cenu, že privátní klíč je na ráně (nebo uložen v proprietárním HW).

[xm]

Pozor! Uložen v proprietárním hardware mi nevadí, vadí mi _vygenerovaný_ proprietárním hardware. O tom byla přeci od začátku threadu celou dobu řeč, na to vygenerování jsem reagoval.

[SPM]

Óká, vygenerovaným. Mně to pořád ve výsledku vychází bezpečnostně lépe, než to dělat na PC, kde se může stát cokoliv (hromada chyb v zrovna nainstalované openssl, stejný backdoor v CPU, pozůstatek klíče na HDD i po smazání, malware co to rovnou z toho PC pošle někam jinam, ...). Ono nakonec kdyby to generovalo jenom nějakou malou množinu párů klíčů, tak by na to časem taky někdo přišel (stejně jak u openssl na debianu se to taky zjistilo až při praktické kolizi klíčů).

Jinak kde to vyrábějí ani nevím. Ten můj šel ze Švédska, ale nějaké kanceláře maj i v USA...

[Jendа]

Ono nakonec kdyby to generovalo jenom nějakou malou množinu párů klíčů, tak by na to časem taky někdo přišel (stejně jak u openssl na debianu se to taky zjistilo až při praktické kolizi klíčů).

<tinfoil hat>Pokud se to neudělá tak debilně jako u Debianu (neříkám, že tvůrce 32Ki backdooru v Debianu byl debil - je to open source, kvalitní generátor backdoornutých klíčů se tam těžko ukryje),</tinfoil hat> tak ne. Stačí generovat deterministické RSA z hardware_serial_number || key_serial_number. Kolik entropie může spapat takový generátor deterministických RSA klíčů? Určitě alespoň 128b. Tak to rozdělíme 64:64. No a pak když chceš něco cracknout, tak musíš zkusit (kolik HW tokenů se vyrobilo)*(kolik klíčů token vygeneroval). Nejspíš to bude něco jako milión*1. A kolizi ti to nevyrobí, dokud na tom někdo nespočítá 2**64 klíčů, což asi nespočítá.

[xm]

Nicméně každopádně pokud bych dělal s něčím tak explozivním jako třeba Snowdenovy dokumenty, pak přesně to co popisuješ je jediný správný přístup. S tím že se musí jednat i nejlépe o samostatný generický PC/notebook koupený někde ve velkém obchodě, nikoliv objednaný na jméno přes Internet (viz leaky o tom jak NSA odchycuje high-value cílům objednávky z Amazonu a implantuje do nich jejich backdoory).

[Jendа]

Nicméně každopádně pokud bych dělal s něčím tak explozivním jako třeba Snowdenovy dokumenty

Tak zrovna těm by zveřejnění prospělo. A že si NSA bude moct po cracknutí té komunikace přečíst své vlastní dokumenty? Yo dawg.

[zofrrey]

nemusis restartovat agenta, staci odebrat ten token ssh-add -e token a po zastrceni zase pridat

[SPM]

Z toho co jsem zkoušel, tak sice ne, ale musí se to udělat před tím, než se token vyndá. Což, když na to zapomeneš, nemáš čas a potřebuješ jít, atd., a vytáhneš ho bez odebrání klíče, tak už se to znova nerozjede...

[psonek]

Taky bych rekl...

[fissie]

Díky, opraveno.

[rastos]

Fajn blog. Aj článok z toho mohol byť.

Ako je to s nákupom HW? Je to tu bežne dostať, alebo si objednával zo zahraničia? Koľko ťa ten HW vyšiel a koľko zo toho bolo poštovné?

[fissie]

Kupoval jsem na kernelconcepts, na který vedou ty linky. Na první pohled jsem v ČR nic nenašel, ale přiznávám se, že jsem moc nehledal. Naklikal jsem, druhý den poslali fakturu, proplatil jsem paypalem a během dalších tří dní to bylo doma. Poštovné v řádu několika eur.

[St4nd3l]

Nemáte nějaké další typy na eTokeny? Chvíli jsem si hrál s ePass2003, ale u toho byl velký problém po jeho odpojení a znovu připojení.

[SPM]

Co se týče těch PKI tokenů, tak celkem úspěšně mi funguje SafeNet eToken 5100 (dříve SafeNet eToken PRO 72k Java, ještě dříve to byl Alladin). Má to linuxovou "podporu", tedy, když si s tím člověk dostatečně dlouho hraje, tak se to rozchodit dá, ale že by to fungovalo out of the box, to teda ne.

Poměrně dobře taky fungovaly Rainbow iKey 3000, ale ty se jednak dnes už ani nevyrábí, jednak jsou zastaralé (jen 1024b RSA) a navíc co se v distribucích začalo kompilovat opensc proti pcsc (místo openct), tak mi taky zrovna fungovat nechtěly.

[User682]

zdravim,

diky za potvrzeni toho Safenetu. Rozbehat kryptokarty (Protect Server Gold/Eracom) na Debianu je taky zazitek, kdyz je podpora pouze pro RedHat. Ta "linuxova podpora" je presny nazev. Ale porad lepsi nez pak neco ladit na Win.

gf

[St4nd3l]

Mě celkem s těch SafeNet zaujal model SafeNet eToken 7200. Asi odzkouším a pak dám vědět výsledek. Děkuji za rady.