Před několika měsíci došlo ke spuštění možnosti využití mojeID pro přístup ke službám státní správy pomocí technologie FIDO. Velká část uživatelů může za tímto účelem použít FIDO klíč integrovaný do svého operačního systému, jako např. Windows Hello případně Android klíč na telefonu nebo tabletu. Jednoznačně se jedná o nejpohodlnější cestu k elektronickým službám státu – bez nutnosti pořizovat jakékoliv zařízení (čtečky, karty) nebo instalovat něco dalšího do svých zařízení (obslužný software, potvrzovací mobilní aplikace). Pro uživatele, kteří možnost využití systémového klíče nemají, jsme chtěli nabídnout dostupnou alternativu v podobě externího klíče použitelného přes USB nebo NFC rozhraní, a to jak v počítači tak v telefonu. K tomuto účelu byl zvolen FIDO klíč GoTrust IdemKey, který si nyní každý může velice jednoduše pořídit. Tento klíč totiž není jen FIDO klíč určený pro potvrzení autentizačních transakcí, ale může také plnit roli čipové karty pro digitální podepisování dokumentů podobně jako např. elektronický občanský průkaz, nebo může fungovat jako HSM (Hardware Security Modul) pro podepisování DNS záznamů technologií DNSSEC.
V případě FIDO klíčů je schopnost fungovat jako čipové karty zapouzdřena do implementace standardu PIV (Personal Identity Verification). Asi nejvíce informací o tomto standardu je možné získat na stránkách firmy Yubico, jejíž některé produkty tuto vlastnost mají také. Pro podepisování a šifrování mohou nicméně jednotlivé klientské aplikace používat zavedený standard PKCS11. Ten je v operačním systému Linux zpřístupněn přes sadu knihoven v rámci projektu OpenSC. Pro komunikaci s konkrétním zařízením se používá protokol CCID (Chip Card Interface Devices), jehož obecný ovladač byl nedávno ve verzi 1.4.34 rozšířen právě o podporu GoTrust IdemKey. V systému použitém pro následující testování, tedy ve Fedoře 33, je již naštěstí tato verze k dispozici. Pro otestování funkcionality připojeného klíče je možné rovnou použít PKCS11 rozhraní nástrojem pkcs11-tool z projektu OpenSC.
$ pkcs11-tool -L Available slots: Slot 0 (0x0): Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 (empty) Slot 1 (0x4): GoTrust Idem Key [FIDO2 DEVICE] (200801000798) 01 00 token label : PIV_II token manufacturer : piv_II token model : PKCS#15 emulated token flags : login required, rng, token initialized, PIN initialized hardware version : 0.0 firmware version : 0.0 serial num : 0000000000000000 pin min/max : 4/8
V tomto případě je vidět, že jsou k dispozici dva sloty pro zařízení. První slot odpovídá integrované čtečce čipových karet od firmy Broadcom, která je prázdná. Druhý slot odpovídá IdemKey a je obsazen tokenem s názvem „PIV_II“. Implementace OpenSC má z pohledu integrace s PIV tokeny jednou slabinu, a to tu, že neumí generovat klíče v tokenu. Naštěstí je implementace PIV v IdemKey kompatibilní s implementací v YubiKey a pro správu klíčů je tedy možné použít nástroj od společností Yubico nazvaný yubico-piv-tool. V parametru -r příkazu je vždy třeba uvádět nějaký podřetězec identifikující název PKCS11 slotu:
$ yubico-piv-tool -r "GoTrust" -a status Version: 1.0.1 Serial Number: No data available CHUID: 30190000000000000000000000000000000000000000000000000034101ea86814c8dde15b613d28ec42a9b0c6350832303530303130313e00fe00 CCC: f015a000000116ff0296b2eed18618db7b441a04458778f10121f20121f300f400f50110f600f700fa00fb00fc00fd00fe00
PIV tokeny umožňují uchovávat klíče ve čtyřech slotech označených jako 9a, 9c, 9d a 9e. Pozor, nezaměňovat s PKCS11 slotem, v tomto případě jde o něco jiného. Zde se jedná o sloty uvnitř PIV tokenu. Přestože každý tento slot podle PIV standardu slouží k jinému účelu, pro naše potřeby jsou zaměnitelné a budeme používat první z nich, tedy 9a. Pro správné fungování tokenu je třeba do tohoto slotu dostat privátní klíč a zároveň certifikát obsahující veřejný klíč. Teprve poté je klíč použitelný. Privátní klíč je možné vytvořit v tokenu nebo je možné nějaký existující klíč do tokenu naimportovat. Druhá možnost se hodí v případě, že chcete mít od klíče kopii, protože klíč generovaný v tokenu není možné exportovat. Přístup k soukromému klíči je chráněn PINem, který má defaultní hodnotu 123456. Následující tři příkazy tedy vytvoří použitelný RSA klíč:
$ yubico-piv-tool -r "GoTrust" -a generate -s 9a -A RSA2048 -o /tmp/pubkey.pem Successfully generated a new private key. $ yubico-piv-tool -r "GoTrust" -a verify-pin -a selfsign -s 9a -S '/CN=my_key/' -i /tmp/pubkey.pem -o /tmp/cert.pem Enter PIN: Successfully verified PIN. Successfully generated a new self signed certificate. $ yubico-piv-tool -r "GoTrust" -a import-certificate -s 9a -i /tmp/cert.pem Successfully imported a new certificate.
Vidíme, že slot uvnitř PIV tokenu je obsazen:
$ yubico-piv-tool -r "GoTrust" -a status Version: 1.0.1 Serial Number: No data available CHUID: 30190000000000000000000000000000000000000000000000000034101ea86814c8dde15b613d28ec42a9b0c6350832303530303130313e00fe00 CCC: f015a000000116ff0296b2eed18618db7b441a04458778f10121f20121f300f400f50110f600f700fa00fb00fc00fd00fe00 Slot 9a: Algorithm: RSA2048 Subject DN: CN=my_key Issuer DN: CN=my_key Fingerprint: 45157c46bd1ff9e32afd93c8c42479f08007fa41b7b997d5f11b2e804ee180c2 Not Before: Feb 12 14:15:00 2021 GMT Not After: Feb 12 14:15:00 2022 GMT
Pozoruhodné je, že z pohledu PKCS11 klienta se nám změnil název tokenu z PIV_II na my_key:
$ pkcs11-tool -L Available slots: Slot 0 (0x0): Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 (empty) Slot 1 (0x4): GoTrust Idem Key [FIDO2 DEVICE] (200801000798) 01 00 token label : my_key token manufacturer : piv_II token model : PKCS#15 emulated token flags : login required, rng, token initialized, PIN initialized hardware version : 0.0 firmware version : 0.0 serial num : 0000000000000000 pin min/max : 4/8
Vypadá to, že se název tokenu odvozuje od názvu prvního certifikátu uloženého na tokenu. To je důležité vědět pro případ, kdy je v PKCS11 klientovi třeba zadat název tokenu. Dále si můžeme z pohledu PKCS11 klienta vypsat např. certifikáty uložené na tokenu.
$ pkcs11-tool -O --slot 0x4 --type cert Certificate Object; type = X.509 cert label: Certificate for PIV Authentication subject: DN: CN=my_key ID: 01
Zde je podstatné ID, s jehož využitím je možné se odkázat na konkrétní klíč v tokenu. Jednotlivým PIV slotům 9a, 9c, 9d a 9e odpovídají ID 01, 02, 03 a 04. Stejně tak se ale může v některých případech hodit identifikace podle hodnoty label.
Nyní je již možné tímto klíčem podepisovat a šifrovat. Zde si ukážeme, jak tento klíč využít jako DNSSEC klíč pro podepsání DNS zóny. K tomu použijeme nástroj kzonesign z projektu DNS serveru KnotDNS. Jako pracovní prostředí použijeme dočasný adresář, do kterého si uložíme vzorovou zónu z projektu. Níže je vidět vzorový konfigurační soubor obsahující pouze nejnutnější parametry pro funkci podepsání DNS zóny. Za pozornost stojí identifikace úložiště klíčů pomocí PKCS11 uri, kde je uveden identifikátor slotu, tentokrát v decimální podobě 16 místo 0x4 a PKCS11 knihovna z projektu OpenSC.
$ cd /tmp/knot/ $ cp /usr/share/doc/knot/samples/example.com.zone ./ $ cat knot.conf database: storage: /tmp/knot/ keystore: - id: pkcs11 backend: pkcs11 config: "pkcs11:slot-id=16;pin-value=123456 /usr/lib64/pkcs11/opensc-pkcs11.so" policy: - id: my_policy keystore: pkcs11 algorithm: RSASHA256 zone: - domain: example.com file: /tmp/knot/example.com.zone dnssec-policy: my_policy
Knot DNS si metadata o používaných klíčích ukládá do tzv. KASP (Key and Signing Policy) databáze. Před vlastním použitím klíče je nutné tato metadata založit pomocí import příkazu utility keymgr. Pro jednoduchost použijeme kombinovaný klíč v roli ZSK (Zone Signing Key) a KSK (Key Signing Key). Pro identifikaci klíče v rámci PKCS11 tokenu se použije jeho ID, tedy 01.
$ keymgr -c knot.conf example.com. import-pkcs11 01 algorithm=RSASHA256 ksk=yes zsk=yes 01 OK $ keymgr -c knot.conf example.com. list 01 ksk=yes zsk=yes tag=39259 algorithm=8 size=2048 public-only=no pre-active=0 publish=1613146697 ready=0 active=1613146697 retire-active=0 retire=0 post-active=0 revoke=0 remove=0
Nyní je možné již zónu podepsat:
$ kzonesign -c ./knot.conf example.com. Next signing: 1613751596
Rychlost podepisování byla v průměru u několika experimentů 0.65 podpisů za vteřinu. Pro podepsání velké DNS zóny je tedy takovéto použití přirozeně nereálné. Např. zónu .CZ by to odhadem podepisovalo několik týdnů. Na druhou stranu Knot DNS umožňuje technologii offline KSK klíče, která spočívá v tom, že KSK je uchováván odděleně od podepisovací infrastruktury a slouží pouze jednou za čas k podepsání několika DNSKEY RRsetů připravených na další období. Zde výkonost nehraje roli a pro bezpečné úložiště KSK může sloužit právě takovýto FIDO klíč. V případě GoTrust IdemKey existuje bohužel omezení na použití pouze RSA klíče o maximální velikosti 2048 bitů. Algoritmy využívající eliptické křivky IdemKey nepodporuje.
Jak je vidět, na těchto stránkách, FIDO klíč implementující PIV je možné použít například i pro zabezpečení SSH komunikace. Při dalším experimentování bylo ověřeno, že je možně do GoTrust IdemKey bez problémů vložit kvalifikovaný certifikát a klíč od certifikační autority PostSignum podepsat a s ním LibreOffice dokument. Je tedy zřejmé že využití tohoto FIDO klíče násobně překračuje pouhé přihlašování ke státní správě prostřednictvím služby mojeID. Jeho využití v roli čipové karty navíc nenutí uživatele pořizovat čtečku, a tak jediný náklad spočívá v pořízení si vlastního klíče, jehož cena je v porovnání například s YubiKey 5 téměř třetinová.
Super clanek, dekuji za neho. Rad bych jen poznamenal jeden detail tykajici se shrnuti, konkretne kvalifikovaneho certifikatu.
Pokud si zakoupite kvalifikovany certifikat, jedina moznost, jak ho nahrat do GoTrust klice je mit par klic+certifikat ulozeny v souboru. Takovy kvalifikovany certifikat nenese priznak, tykajici se QSCD (vygenerovanání pouzitim kvalifikovaneho prostredku) a tudiz s jeho pomoci lze vytvorit pouze elektronicky podpis urovne uznavany, nikoli kvalifikovany. Benefitem tedy je, ze pokud podepisujete na „cizim“ pocitaci, nikdo si nemuze kopirovat vas klic, nicmene neni garantovano, ze ho nikdo nemuze mit v obecnosti (jakmile mate jednou klic v souboru, muze snadno existovat jeho kopie).
Pokud byste chteli vytvaret kvalifikovany elektronicky podpis, je nezbytne jiz samotnou zadost generovat na kvalifikovanem prostredku (token, karta), ozvykle to musi byt zarizeni dodane danou autoritou, ktera do neho „predgeneruje“ servisni klic, ktery se pouzije k dodatecnemu podpisu samotne zadosti pred tim, nez se odesle k certifikacni autorite. Vyjimkou je eOP, kde mistni akreditovane CA vedi jak tuto skutecnost overit, aniz by museli samotnou „kartu“ vydavat sami… Dale takovy klic nelze nijak vyexportovat z daneho zarizeni (z pohledu bezpecnosti, to je prave princip a prinos takoveho zarizeni – nemuze existovat jeho kopie / existuje jen jeden exemplar).
Ne-existence priznaku je dana formou generovani klice a zadosti, neda se tedy dodatecne zmenit. Jakmile klic na takovem zarizeni primo vygenerujete, nikdy ho nevyexportujete / nevytvorite zalohu. Pokud ho vytvorite mimo, muzete ho samozrejme dodatecne importovat (obdobne jako je zmineno v tomto clanku), ale samotnym procesem importu neni zmineny priznak ovlivnen (ten prideluje CA pri vystaveni samotneho certifikatu). Importovany klic s certifikatem je sice kvalifikovany certifikat na kvalifikovanem prostredku, ale take pouzitelny pouze pro vytvoreni uznavaneho podpisu.
Pokud tedy potrebujete vytvaret elekotronicky podpis urovne kvalifikovany, musite pouzit eOP, nebo pouzit jine kvalifikovane zarizeni (token, karta). Pokud chcete mit klic+certifikat v souboru (.p12, .pfx) nebo z nejakeho duvodu nemuzete / nechcete kupovat dalsi zarizeni (s tim, ze vam staci „jen“ podepisovat urovni uznavany), je tato forma ulozeni do GoTrust klice urcite benefitem prispivajicim k bezpecnejsimu pouzivani klice.
Naklady na porizeni ci obnovu kvalifikovaneho certifikatu jsou stejne bez ohledu, jestli je vystaven s vyuzitim QSCD (pro vytvareni kvalifikovaneho podpisu) nebo bez neho (pro vytvareni „jen“ uznavaneho podpisu). Je tedy na zvazeni kazdeho uzivatele, jakou cestu zvoli, jen je potreba volid pred zapocetim procesu generovani zadosti…
Díky za upresnenie. Pomohlo sa zorientovat.
Jelikož v případě IdemKey se nejedná o QSCD a tedy té nejvyšší úrovně podpisu tam nebude možné dosáhnout, nechtěl jsem to tím komplikovat. Každopádně díky za doplnění!