PIV rozlišuje 4 druhy klíčů, nebo umí uložit právě čtyři klíče? Pokud to druhé, nedokážu si představit, jak se mění certifikáty.
S obecnými PKCS11 kartami se nechá starý, kterému platnost ještě nevypršela, a přidá se nový. Takže uživateli autentizace funguje, i když se ještě nestihl rozšířit identifikátor nového certifikátu do autorizačních systémů.
Nebo v rámci zbohatnutí výrobců PIV karet si uživatel musí pořídit druhé zařízení, řešit jeho inicializaci, nastavování PINu a pak si pamatovat, které zařízení je které?
Mně jako jednodušší řešení přijde obdoba používaná u serverových certifikátů - nějaký týden před vypršením se vygeneruje nový certifikát s platností od momentu vzniku a ním se nahradí starý na PIV appletu/kartě.
Pokud to už chcete řešit ve větším měřítku, tak je rovnou dobré si ty cerifikáty podepisovat svou vlastní CA a pak nenarazíte na problém, že se nový certifikát nerozšířil do autorizačních systémů.
Jinak přinejhorším šlo použít slot 9c jako extra místo pro další certifikát a klíč. Myslím, že běžné PKCS#11 aplikace to normálně nerozlišují (klíč akorát musí správný flag - "sign", "encrypt", podle aplikace).
Samozřejmě, že se certifikát vydá před vypršením platnosti starého. Jenže certifikát nevyrobíte bez soukromého klíče. A když máte požadavky, že klíč nesmí opustit kartu, tak jej musíte vygenerovat na kartě. A když karta není schopna pojmout více jak jeden klíč, tak musíte smazat nejprve starý.
Taky ve větším měřítku se nepoužívají vlastní autority, ale akreditované veřejné autority. Tam pak musíte po vydání certifikátu distribuovat sériová čísla certifikátů do všelijakých nezávislých informačních systémů. Pak se nevyhnete období, že máte certifikát, ale ne všichni vědí, koho prokazuje.
Můj pocit z PIV je, že je to taková nabušená průkazka, kdy zaměstnanec vyfasuje každý rok novou kartu se zaměstnavatelem předgenerovaným certifikátem. Smyslem není chránit zaměstnance, ale zaměstnavatele.
Jinak u PKCS#11 můžete mít klíčů, kolik chcete. Omezením je jen velikost paměti v kartě. V případě PKCS#15 dokonce můžete mít skupiny klíčů chráněné různým PINem.
A když máte požadavky, že klíč nesmí opustit kartu, tak jej musíte vygenerovat na kartě.
Certifikát vygeneruje certifikační autorita. Pro vytvoření žádosti stačí jen privátní klíč. Pokud byste měl kartu plnou, můžete prodloužit certifikát se stejným klíčem, nebo trochu změkčit to pravidlo „klíč nesmí opustit kartu“, vytvořit a uchovat klíč bezpečným způsobem jinde (např. ho zamknout do trezoru) a na kartu jej pak nahrát jen pro běžné používání. Mít klíč jenom na kartě je nejsnazší způsob, jak o něj přijít (což v případě šifrovacího klíče může být problém).
Taky ve větším měřítku se nepoužívají vlastní autority, ale akreditované veřejné autority. Tam pak musíte po vydání certifikátu distribuovat sériová čísla certifikátů do všelijakých nezávislých informačních systémů. Pak se nevyhnete období, že máte certifikát, ale ne všichni vědí, koho prokazuje.
Koho certifikát prokazuje je v něm napsáno. Proč jako identifikaci používáte sériová čísla certifikátů a ne údaje z něj (jméno, e-mail)?
Jinak u PKCS#11 můžete mít klíčů, kolik chcete. Omezením je jen velikost paměti v kartě.
Yubikey je úplně stejný případ. Ona ta paměť v kartě nebývá velká.
V případě RSA na nový veřejný klíč potřebujete nový soukromý klíč. Tudíž na nový certifikát potřebujte nový soukromý klíč. Všechno ostatní jsou změkčení, která podkopávají smysl výměny certifikátů nebo přímo porušují bezpečnostní pravidla.
Bohužel ze subjectu certifikátu nepoznáte, komu byl vydán. Různé autority mají různá pravidla a hodnoty různě omezují nebo normalizují. Konfliktní jména (stejnojmenní lidé ze stejné organizační jednotky nebo adresy) autority často řeší ad hoc změnami, které nelze předjímat. Takže ten samý člověk může dostat od dvou autorit certifikáty s jiným jménem. E-mail vypadá lákavě, ale za prvé je nepovinný, za druhé někdo má e-mailovou adresu odpovídající roli, nikoliv jménu.
Yubikey není stejný případ. Yubikey má PIV applet (u nových modelů jej dokonce nemůžete vyměnit nebo přidat si další), což je na stejné úrovni jako PKCS#11 profil. Rozdíl je, že PIV, alespoň v podání Yubikey (hledat specifikaci se mi nechce), má principiální omezení. Karty mají obvykle aspoň 32 KB. Tam se těch certifikátů vejde rozhodně více.
Smysl výměny certifikátů je především v tom, aby na certifikátu byly aktuální údaje. Certifikační autorita ověřuje údaje v okamžiku podpisu, jenže mnoho údajů se může později změnit – ale ten podpis na certifikátu už zůstane (a CA se o změně ani nemusí dozvědět, aby ho mohla sama zneplatnit). Pro nový certifikát není principiálně nutný nový veřejný klíč, a pokud mám privátní klíč uložený na zařízení, ze kterého jej nejde snadno získat, nedává výměna klíčů smysl (jediný důvod k případné výměně klíčů je politika CA). Naopak v případě šifrovacích klíčů je výměna kontraproduktivní, protože pak musíte všechny klíče archivovat.
Myslel jsem, že píšete o nějakém uzavřeném systému, kde můžete specifikovat, jak má certifikát vypadat. I tak nevidím problém s použitím e-mailu – prostě kdo bude chtít používat certifikát ve vašem systému, bude v něm muset mít e-mail. Adresa neodpovídající jméno nevadí, e-mail tam slouží jen jako unikátní identifikátor. Psal jste o českých akreditovaných autoritách, v takovém případě je pak asi nejlepší použít IK MPSV – do certifikátu si ho může nechat dát každý, a máte pak jednoznačnou identifikaci osoby, která je platná „navždy“.
Karty, které jsem měl v ruce, měly (starší modely) myslím 4 sloty pro 1kB certifikáty a 2 sloty 2kB certifikáty, novější mají myslím 8 slotů pro 2kB certifikáty (dají se tam nahrát i 1kB). Záleží model od modelu, ale omezení na nízké jednotky kusů je podle mne běžné.
Jenže certifikát nevyrobíte bez soukromého klíče.
Ale vy nepotřebujete privátní klíč té karty pro vygenerování certifikátu. Jenom její veřejný klíč. Který bude součástí CSR (certificate signing request).
Taky ve větším měřítku se nepoužívají vlastní autority, ale akreditované veřejné autority.
Tak to teda absolutně ne. Toto je shodou okolností případ, pro který bylo celé X.509 puvodně vlastně navržené - každá firma má vlastní hierarchii. A vlastní CA.
Jinak u PKCS#11 můžete mít klíčů, kolik chcete.
PKCS#11 je standard pro C interface, takže samozřejmě závisí jen od velikosti karty.
O PKCS#15 jsem mimojiné psal v souvislosti s tokenem Feitian ePass 2003 tady na root článek, který PKCS#15 podporuje.
Jak jsem napsal výše, veřejný klíč je duální soukromému. Jeden bez druhého neexistuje.
Každá firma může mít vlastní CA, ale bez patřičných certifikací vám ji nikdo příčetný neuzná. Rozhodně ne státní správa. Nakonec PIV byl vytovořen pro potřeby americké administrativy (NIST Special Publication 800-73).
Mně přijde, že pořád řešíte nějaký problém a jeho workaround v usecase, který jste nesdělil a mně ho nezbývá než hádat.
Původně jsme řešili, že existuje lepší cesta než poor man's key pinning kopírovaním certifkátu, resp. veřejného klíče všude. To je víceméně celá pointa X.509 a X.500.
Privátní klíč je nutný jenom pro vytvoření CSR. CSR může být podepsáno klidně offline u registrační autority (RA, ekvivalent validačního místa). Člověk přijde, ověří, že je to skutečně on - celá pointa osobní identifikace. Pak se u RA podepíše CSR, a bam! Nový certifikát. Ten bude fungovat i když byl podpis vygenerován offline. Člověk si ho okamžitě může nahrát do původního slotu.
Je někde prosím nějaký příklad jak klíč použít? Napadá mě přihlašování k systému a přihlašování ke KeePasu. Šlo by to? Ideál je něco jako přijdu k PC, vložim USB klíč a ten mi odmkne de facto všechny přihlášení, který potřebuju...
...tak k tomu KeePasu jsem našel nějaký popis zde: http://keepass.info/help/kb/yubikey.html
Nejake info o moznostiach priamo na strankach vyrobcu Yubico.
Přihlašovaní k počítači lze nastavit přes PAM modul pam_yubico nebo pam_u2f. Taky lze tak udělat třeba autentizaci na sudo.
Vyčerpávající seznam možností, co s Yubikey udělat, asi pohromadě nikde není. Dobrý rozcestník sem dal diskutující nade mnou. Yubico uvádí navíc možnosti pro business nasazení nebo vývojáře. Na tom developer portálu se nachází asi nejvíc návodů, ale to je spíš pro lidi, co se snaží Yubikey přiohnout svým potřebám.
Pro KeePass mají rovnou návod na Yubico stránkách.
Lze taky najít plugin CryptoKi, který funguje na jiném principu než OtpProvider výše, ale nevím v jakém stadiu podporovanosti se tento plugin nachází.
Je dobrý nápad vystavovat USB port počítače, a strkat do něj zařízení které je potenciálně nedůvěryhodné? To USB zařízení může například přepětím odpálit celý počítač, nebo se identifikovat jako human interface device a poslat stisky kláves, které spustí shell, stáhnou malware a spustí ho.
http://arstechnica.com/security/2015/10/usb-killer-flash-drive-can-fry-your-computers-innards-in-seconds/
http://arstechnica.com/security/2014/07/this-thumbdrive-hacks-computers-badusb-exploit-makes-devices-turn-evil/
Ještě než se tu objeví názor někoho, kdo se nad tím nezamyslel, a napíše „to jako budeš každý den povolovat svoji klávesnici“ a „jak povolím klávesnici, když nemám klávesnici“.
Ad. 1) Samozřejmě že ne. Svoji klávesnici připojuji doma, případně v práci. To je pro notebook poměrně dobře definované, protože se právě probudil, visí to na hubu (přičemž útočník by musel naemulovat hub, myš i klávesnici včetně správných USB ID a pořadí portů) a vidí kolem sebe třeba určité WPA wifi sítě nebo je v ethernetu, kde se může zeptat nějakého vnitřního SSH serveru.
Další možností je koncept, na který přistoupil QubesOS. Počítače mají hodně USB portů a některé prohlásíme za důvěryhodné a některé ne.
Ad. 2) Já mám PS/2, ale řekněme, že nemáte. Mohlo by to třeba akceptovat první klávesnici připojenou při bootu. A abychom se nedostali do deadlocku při výměně klávesnice, bylo by též možné "Pro autorizaci napište na klávesnici nc1y". Pokud by to byla interaktivní klávesnice, mohu ty čtyři klávesy zmáčknout a tím se to potvrdí.
Další možnost je mít desktop s přepínáním různých úrovní zabezpečení, což je stejně rozumné, abyste neměli třeba v ssh-agentovi trvale odemčený SSH klíč od důležitých serverů, i když zrovna jenom kecáte na Rootu. Některá úroveň by pak počítala s připojováním USB zařízení, některá ne.
A jinak na Linuxu se to dá částečně implementovat pomocí options usbcore authorized_default=0 a /sys/zařízení/authorized.
Coz uz na rozdil od "Vase klavesnice napsala ALT-2 rm -rf /" dava smysl (zda to za tu praci stoji je jina, neni lepsi proste nestrkat do pocitace nezname veci a vyresit tak 95% posobnych problemu?). Navic jeste musis pocitat pri takovemhle nastavovani s tim, ze chces, aby se YubiKey choval jako klavesnice, takze trebas pravidlo "jen prvni klavesnice" stacit nebude.
Ostatne s tim strkanim veci do portu se muzes dockat daleko horsich veci, nez klicenky, co umi psat.
> zda to za tu praci stoji je jina, neni lepsi proste nestrkat do pocitace nezname veci a vyresit tak 95% posobnych problemu?
Není volbou, pokud tvoje práce zahrnuje kopírování věcí ostatním lidem na flashku nebo prostě používání různých USB periferií. Od JTAG debuggeru po softwarově definované rádio.
> Ostatne s tim strkanim veci do portu se muzes dockat daleko horsich veci, nez klicenky, co umi psat.
Povídej.
To je jedna možnost, i když asi dražší - lze přiřadit více tokenů k jednomu účtu (alespoň Google a Yubico to umožňují). U Google účtu lze použít další 2-factor variantu (záložní), např. právě tím Google Authenthicatorem, SMS, nebo jednorázový recovery code. Samozřejmě recovery možnosti se musí nastavit předem.
Každá služba to bude mít řešeno asi jinak.
Přesně v době psaní článku vydalo Yubico další token, Yubikey 4.
Hlavní rozdíl proti Neo je je, že Yubikey 4 umí 4096-bit RSA klíče v OpenPGP appletu, nemá NFC a je levnější o $10. Pokud člověk nepotřebuje použít NFC pro mobilní autentizaci, je asi Yubikey 4 lepší volba než Neo.
NFC s GPG bylo vyzkoušeno (čtečka Omnikey Cardman 5321) a fungovalo, ale osobně bych se na to moc nespoléhal. Je to bohužel jedna z těch věcí, na kterou nikdo nedělá regresní testy, protože to má málo uživatelů.
na www.yubikeys.cz mají oficiální zastoupení. už to někdo zkoušel?