Hlavní navigace

Využití FIDO klíče GoTrust IdemKey pro digitální podpis, například DNSSEC

16. 2. 2021
Doba čtení: 7 minut

Sdílet

 Autor: GoTrust
FIDO klíč GoTrust IdemKey může 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).

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 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 0×4 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.

root_podpora

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á.

(Původně vyšlo na blogu CZ.NIC.)

Byl pro vás článek přínosný?

Autor článku

Jaromír Talíř pracuje v CZ.NIC a má na starosti především architekturu a další technické parametry systému správy domén a autentizační služby mojeID.