Zabezpieczanie kluczy kryptograficznych poprzez HSM na przykładzie YubiHSM 2 FIPS

YubiHSM 2 FIPS w EuroLinux – zabezpieczanie kluczy kryptograficznych

YubiHSM 2 FIPS jest sprzętowym modułem kryptograficznym przeznaczonym do zastosowań serwerowych. Służy głównie do generowania, ochrony i przechowywania kluczy kryptograficznych, które zabezpieczają krytyczne aplikacje, tożsamości i wrażliwe dane. W firmie EuroLinux korzystamy z HSM (Hardware Security Module) m.in. w celu bezpiecznego podpisywania dokumentów, pakietów rpm wszystkich naszych produktów oraz bootchaina systemu EuroLinux 8 na potrzeby technologii Secure Boot.

Moduł YubiHSM 2 FIPS umożliwia bezpieczne podpisywanie plików – bez ekspozycji klucza prywatnego. Obsługuje zarówno kryptografię symetryczną, jak i asymetryczną (z kluczem publicznym). Fizyczne oddzielenie modułu HSM uniemożliwia potencjalnym napastnikom dostęp do pamięci i innych identyfikowalnych zasobów, które mogłyby zostać wykorzystane do naruszenia tajemnic firmy. Możliwości YubiHSM 2 obejmują generowanie, zapisywanie, podpisywanie, dekodowanie, haszowanie i opakowywanie kluczy. Ultra płaska obudowa „nano” urządzenia bez problemów mieści się w wewnętrznym porcie USB serwera.

YubiHSM 2 FIPS

Obsługa modułu YubiHSM 2 FIPS jest możliwa poprzez integrację z otwartym zestawem narzędzi do tworzenia oprogramowania (SDK) dla szerokiej gamy aplikacji Open Source, jak i aplikacji o zamkniętym kodzie. Komunikacja z modułem może odbywać się poprzez Yubico Key Storage Provider (KSP), standard PKCS#11 lub Microsoft CNG, a także przez natywne biblioteki Windows, Linux i macOS.

YubiHSM 2 FIPS

Integralność i prywatność poleceń oraz danych przesyłanych między HSM a aplikacjami jest chroniona za pomocą wzajemnie uwierzytelnionego, zabezpieczonego tunelu. Aplikacje mogą nawiązać wiele równoczesnych sesji z YubiHSM 2 w celu wykonania operacji kryptograficznych.

Tworzenie kopii zapasowych i wdrażanie kluczy kryptograficznych na wielu modułach HSM jest krytycznym elementem architektury bezpieczeństwa przedsiębiorstwa i nie powinno być wykonywane pod kontrolą jednego administratora. YubiHSM wspiera ustawienie M z N reguł na kluczu „wrap” używanym do eksportu kluczy w celu wykonania kopii zapasowej lub transportu danych modułu. Dzięki tej możliwości potrzebnych jest wielu administratorów, posiadaczy części klucza wrapującego, do importu i pełnego odszyfrowania klucza, aby można go było użyć na dodatkowych HSM-ach. Na przykład w przedsiębiorstwie klucz prywatny Active Directory root CA może być opakowany kluczem wrapującym przeznaczonym dla 6 administratorów (N=6) i co najmniej 4 z nich (M=4) musi zaimportować swoje części klucza, aby przenieść dane na nowy moduł HSM.

Komunikacja z HSM

Wygenerujemy klucz asymetryczny RSA bezpośrednio w module oraz zaimportujemy do modułu istniejący na naszym dysku, prywatny klucz RSA. Oba klucze posłużą nam do podpisywania plików. Utwórzmy więc na początek taką przykładową parę kluczy w systemie – jeszcze przed rozpoczęciem komunikacji z HSM:

[eurolinux@el ~]$ openssl genrsa -out private.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..................................+++++
.....................+++++
e is 65537 (0x010001)
[eurolinux@el ~]$ openssl rsa -in private.pem -outform PEM -pubout -out public.pem
writing RSA key
[eurolinux@el ~]$ ls
private.pem
public.pem

Po instalacji oprogramowania yubihsm2-sdk uruchamiamy polecenie:

sudo yubihsm-connector &>/dev/null &

W przeglądarce WWW otwieramy adres:

http://localhost:12345/connector/status

i sprawdzamy status połączenia z modułem. Wyświetlone informacje powinny być zbliżone do poniższych:

status=OK
serial=*
version=3.0.2
pid=45428
address=localhost
port=12345

W ten sposób utworzony został bezpieczny tunel służący do komunikacji z modułem.

Zanim przeprowadzimy pełną konfigurację, warto utworzyć klucz autoryzujący ze wszystkimi możliwymi uprawnieniami, ale chroniony naszym hasłem. Dzięki temu możliwe będzie dokonywanie operacji blokowanych domyślnym kluczem autoryzującym oraz łatwe, software’owe przywrócenie urządzenia do ustawień fabrycznych. Zalecanego usunięcia takiego klucza będziemy mogli dokonać po zakończeniu wszystkich prac konfiguracyjnych i po przetestowaniu konfiguracji. W rezultacie nie będzie wymagane sprzętowe przywrócenie ustawień fabrycznych HSM, które nie jest zbyt przyjemne ani dla modułu, ani dla portu USB, ponieważ operacji tej dokonuje się poprzez „siłowe”, mocne dociśnięcie urządzenia do portu USB.

Na początek uruchamiamy więc polecenie:

yubihsm-shell

a następnie w interfejsie urządzenia kolejne polecenia:

yubihsm> connect
Session keepalive set up to run every 15 seconds
yubihsm> session open 1
Enter password:
Created session 0

session open 1 oznacza otworzenie sesji kluczem autoryzującym o ID 1 (hex 0x0001) domyślnie umieszczonym w module, którego pierwotnym hasłem jest słowo: password. Dla odmiany, przy zamykaniu sesji na końcu wskazujemy ID zamykanej sesji, a nie ID klucza, pomimo że struktura poleceń otwierania i zamykania sesji wygląda bardzo podobnie.

Wylistujmy obiekty umieszczone w module, aby mieć pewność, że ustawienia fabryczne są poprawne – po poleceniu list objects konieczne jest podanie ID sesji, które wynika z wcześniej wykonanych poleceń. W tym przypadku ID nowo utworzonej sesji wynosi 0:

yubihsm> list objects 0
Found 1 object(s)
id: 0x0001, type: authentication-key, sequence: 0

W module mamy obecnie tylko jeden klucz autoryzujący logowanie do urządzenia. Brak innych obiektów. Możemy więc dodać nasz MasterKey:

yubihsm> put authkey 0 0x0009 MasterKey all all all
Enter password:
Stored Authentication key 0x0009

Powyższe polecenie tworzy w sesji 0 klucz o ID 9 (hex 0x0009) z wygodną nazwą MasterKey i z maksymalną ilością domen i właściwości. Jest to konieczne, ponieważ tworzony poleceniem yubihsm-setup (o nim za chwilę) domyślny klucz autoryzujący, nie daje możliwości resetu, czyli przywracania urządzenia do ustawień fabrycznych.

Sprawdźmy jeszcze możliwości tak utworzonego klucza:

yubihsm> get objectinfo 0 0x0009 authentication-key

Otrzymamy następującą listę:

id: 0x0009, type: authentication-key, algorithm: aes128-yubico-authentication, label: "MasterKey", length: 40, domains: 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16, sequence: 0, origin: imported, capabilities: change-authentication-key:create-otp-aead:decrypt-oaep:decrypt-otp:decrypt-pkcs:delete-asymmetric-key:delete-authentication-key:delete-hmac-key:delete-opaque:delete-otp-aead-key:delete-template:delete-wrap-key:derive-ecdh:export-wrapped:exportable-under-wrap:generate-asymmetric-key:generate-hmac-key:generate-otp-aead-key:generate-wrap-key:get-log-entries:get-opaque:get-option:get-pseudo-random:get-template:import-wrapped:put-asymmetric-key:put-authentication-key:put-mac-key:put-opaque:put-otp-aead-key:put-template:put-wrap-key:randomize-otp-aead:reset-device:rewrap-from-otp-aead-key:rewrap-to-otp-aead-key:set-option:sign-attestation-certificate:sign-ecdsa:sign-eddsa:sign-hmac:sign-pkcs:sign-pss:sign-ssh-certificate:unwrap-data:verify-hmac:wrap-data, delegated_capabilities: change-authentication-key:create-otp-aead:decrypt-oaep:decrypt-otp:decrypt-pkcs:delete-asymmetric-key:delete-authentication-key:delete-hmac-key:delete-opaque:delete-otp-aead-key:delete-template:delete-wrap-key:derive-ecdh:export-wrapped:exportable-under-wrap:generate-asymmetric-key:generate-hmac-key:generate-otp-aead-key:generate-wrap-key:get-log-entries:get-opaque:get-option:get-pseudo-random:get-template:import-wrapped:put-asymmetric-key:put-authentication-key:put-mac-key:put-opaque:put-otp-aead-key:put-template:put-wrap-key:randomize-otp-aead:reset-device:rewrap-from-otp-aead-key:rewrap-to-otp-aead-key:set-option:sign-attestation-certificate:sign-ecdsa:sign-eddsa:sign-hmac:sign-pkcs:sign-pss:sign-ssh-certificate:unwrap-data:verify-hmac:wrap-data

Klucz wygląda poprawnie. Możemy więc dodać kolejne klucze RSA służące nam do podpisywania plików. Klucz o ID 5 zaimportujemy z wcześniej utworzonego na dysku pliku private.pem, a klucz o ID 6 utworzymy bezpośrednio w urządzeniu. W przykładach opieramy się na jednej domenie, dlatego skorzystamy z identyfikatora domeny „1”:

yubihsm> put asymmetric 0 5 rsakey 1 sign-pkcs,exportable-under-wrap private.pem
Stored Asymmetric key 0x0005
yubihsm> generate asymmetric 0 6 genrsa 1 sign-pkcs,exportable-under-wrap rsa2048
Generated Asymmetric key 0x0006

Czas generowania tego ostatniego klucza wynosi około 7 sekund. Jeżeli nie dodamy możliwości exportable-under-wrap, to klucz umieszczony w module nigdy już nie będzie mógł być wydobyty z urządzenia. Dlatego w powyższym przypadku zostawiamy możliwość eksportu z opakowaniem kluczem wrapującym.

Zamknijmy teraz sesję 0 utworzoną domyślnym kluczem o ID 1 i przetestujmy logowanie naszym kluczem Master o ID 9. Następnie w tej samej sesji wyświetlmy klucz publiczny wygenerowanego w urządzeniu klucza RSA o ID 6, skopiujmy go do schowka i zamknijmy połączenie z modułem:

yubihsm> session close 0
yubihsm> session open 9
yubihsm> get pubkey 0 6
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz+xtOVKo9rZfy2jtziw1
I5pIEkDS3ftZFFdxOv9e98ui4mBXBQKzqlRP6jMqMi1MtIyBAhv2rmqCDc7VOctj
T6jtam5IK6388Y617BZ3T6PHUvaq1X2Pkzp/yDw4mw6oCB2cjxT4xuTk3Ki5JeRn
/KDLKaXfEZnseBmypfBBtv9E+ZET3ZpOBRLIS3PEl+65gug3oimVuRcLjzvUErcg
NkI+bwzBjA/kCPKCzL5BX5H5LanqeoDe8vObZKn8g3YHuSjl6nhHREBH9YNjmgl+
jO0Q8rQ8xRnZF5IHK3Px5s7jwhG9oJrBxs01O25NnVSO7qoCBL2Ek6GfCqjOXI6L
5QIDAQAB
-----END PUBLIC KEY-----
yubihsm> session close 0
yubihsm> disconnect
yubihsm> quit

Zapiszmy klucz znajdujący się w schowku do pliku genpublic.pem.

Konfiguracja YubiHSM2 FIPS

Przeprowadzimy teraz pełną konfigurację modułu w oparciu o KSP (Key Storage Provider). Konfigurację taką można przeprowadzić, korzystając z polecenia yubihsm-shell, ale polecenie yubihsm-setup jest dużo wygodniejsze w obsłudze:

yubihsm-setup ksp

Bez podania dodatkowych parametrów powyższe polecenie skorzysta z klucza autoryzującego o ID 1, który jest obecny w urządzeniu zaraz po przywróceniu ustawień fabrycznych. Domyślnym hasłem tego klucza jest zwrot: password

Enter authentication password: password
Using authentication key 0x0001
Would you like to add RSA decryption capabilities? (y/n)

Wyświetli się informacja o wykorzystaniu domyślnego klucza autoryzującego o ID 1 (hex: 0x0001) i pytanie o wykorzystanie możliwości RSA – wybieramy opcję „y”.

W tym praktycznym przykładzie wystarczy nam tylko jedna domena. Pod poniższym pytaniem wpisujemy tylko cyfrę 1:

Enter domains: 1
Using domains:
	 One

Poniżej podajemy ID klucza jako 2, ponieważ przestrzeń dla ID 1 jest tymczasowo zajęta kluczem dostarczonym fabrycznie:

Enter wrap key ID (0 to choose automatically): 2
Stored wrap key with ID 0x0002 on the device

Wyświetli się informacja o zapisaniu klucza wrapującego pod ID 2 na urządzeniu.

Następnie ukażą się trzy części klucza wrapującego. Każda z nich musi być zapisana oddzielnie przez trzech administratorów (każda z części wyświetla się po wcześniejszym wyczyszczeniu ekranu). Do przywrócenia danych z backupu na drugie urządzenie HSM, wymagane będą tylko dwie części klucza:

Enter the number of shares: 3
Enter the privacy threshold: 2                    

*************************************************************
* WARNING! The following shares will NOT be stored anywhere *
* Record them and store them safely if you wish to re-use   *
* the wrap key for this device in the future                *
*************************************************************
Press Enter to start recording key shares 

2-1-fY/UAf6cK1/vklhSoM++u9QziaSqXGM2XDv9B1jAjEOBGh8NLmrpFGu/verU4gw5XsyNpg
Have you recorded the key share? (y/n)

2-2-+gW1AeElVr7DOeCkXYNha7ZlTVhzyIQN7zJaeoAnjbEmZmvY9zMHmfaJa5AlPnArTH5clg
Have you recorded the key share? (y/n)

2-3-h4hhAR+5feEsq4j2/Uzf0GNX+gzPT9nvdTXMUch6eRSwuUdgSwRd4nab0k2Bga8lQhAThg
Have you recorded the key share? (y/n)

Teraz utworzymy nowy klucz autoryzujący o ID 3, ale o dużo bardziej ograniczonych właściwościach w stosunku do klucza domyślnego, dostarczonego fabrycznie:

Enter application authentication key ID (0 to choose automatically): 3
Enter application authentication key password: rhL#Yrz)eh9X_S
Stored application authentication key with ID 0x0003 on the device
Saved wrapped application authentication key to ./0x0003-authentication-key.yhw

Jak widać w powyższych komunikatach, klucz autoryzujący został również zapisany w katalogu roboczym na dysku komputera.

W następnym kroku utworzymy klucz audytu o ID 4. YubiHSM wewnętrznie przechowuje log wszystkich zdarzeń zarządzania i operacji kryptograficznych, które występują w urządzeniu. Log ten może być wyeksportowany do monitorowania i raportowania pracy urządzenia. Każde zdarzenie (wiersz) w dzienniku jest połączone łańcuchem haszującym z poprzednim wierszem i podpisane. Dzięki temu możliwe jest ustalenie, czy jakiekolwiek zdarzenia zostały zmodyfikowane lub usunięte.

Tworzenie klucza audytu, który umożliwia wyłącznie dostępu do danych dziennika, jest kolejnym automatycznym krokiem polecenia yubishm-setup:

Would you like to create an audit key? (y/n) y
Enter audit key ID (0 to choose automatically): 4
Enter audit authentication key password: Ar$@w_d+5G49x3
Stored audit authentication key with ID 0x0004 on the device
Saved wrapped audit authentication key to ./0x0004-authentication-key.yhw
Previous authentication key 0x0001 deleted
All done

Konfiguracja została zakończona. Klucz dostarczony fabrycznie został automatycznie usunięty z urządzenia, a nowe klucze: autoryzujący i audytu, zostały zapisane również w katalogu roboczym systemu:

[eurolinux@el85 ~]$ ls *.yhw
0x0003-authentication-key.yhw  0x0004-authentication-key.yhw

Podpisywanie plików z wykorzystaniem HSM

Zanim rozpoczniemy podpisywanie plików modułem HSM, musimy utworzyć odpowiednie wpisy umożliwiające komunikację YubiHSM 2 FIPS poprzez interfejs PKCS #11. Tutaj odsyłam już do dokumentacji modułu – zaznaczę jednak, że wpisy w pliku ~/.bashrc powinny wyglądać podobnie do poniższych (w zależności od używanej dystrybucji mogą się nieznacznie różnić):

export YUBIHSM_PKCS11_CONF=/etc/pki/tls/yubihsm_pkcs11.conf
export YUBIHSM_PKCS11_MODULE=/usr/lib64/pkcs11/yubihsm_pkcs11.so
alias yhsm2-tool='pkcs11-tool --module ${YUBIHSM_PKCS11_MODULE} --login'

Teraz podpiszmy naszymi kluczami RSA przykładowe pliki. Uwaga: jako PIN podajemy tym razem ID klucza autoryzującego, ale w hexie i po odcięciu początkowych znaków „0x” oraz doklejając do niego hasło klucza – przykładowo: 0003rhL#Yrz)eh9X_S. Wskazujemy również ID 5 naszego zaimportowanego klucza RSA, który posłuży do wykonania podpisu:

[eurolinux@el ~]$ echo $RANDOM | tee test-file-1.txt
[eurolinux@el ~]$ yhsm2-tool --sign --id 0005 -m SHA256-RSA-PKCS -i test-file-1.txt -o test-file-1.sig
Using slot 0 with a present token (0x0)
Logging in to "YubiHSM".
Please enter User PIN: 
Using signature algorithm SHA256-RSA-PKCS

i już bezpośrednio w systemie software’owo zweryfikujmy tak złożony podpis, korzystając z klucza publicznego public.pem:

[eurolinux@el ~]$ openssl dgst -sha256 -verify public.pem -signature test-file-1.sig test-file.txt
Verified OK

Jak widać w ostatniej linii – podpis został zweryfikowany poprawnie.

W identyczny sposób możemy przeprowadzić test podpisu dla klucza o ID 6 wygenerowanego bezpośrednio w HSM. Przy weryfikacji należy jednak skorzystać z klucza publicznego genpublic.pem.

Kopia bezpieczeństwa danych modułu HSM

Konfigurację i testy podpisów możemy uznać za zakończone. Należy więc wykonać backup kluczy zawartych w module. Ponieważ domyślny klucz autoryzujący o ID 0x0001 został usunięty z urządzenia, musimy po parametrze -k wskazać ID nowego klucza autoryzującego – w tym przypadku ID 3 (hex: 0x0003).

[eurolinux@el ~]$ yubihsm-setup -k 3 dump
Enter authentication password: rhL#Yrz)eh9X_S
Using authentication key 0x0003
Enter the wrapping key ID to use for exporting objects: 2
Found 6 object(s)
Unable to export object authentication-key with ID 0x0009: Wrong permissions for operation. Skipping over ...
Successfully exported object asymmetric-key with ID 0x0005 to ./0x0005-asymmetric-key.yhw
Successfully exported object asymmetric-key with ID 0x0006 to ./0x0006-asymmetric-key.yhw
Unable to export object wrap-key with ID 0x0002: Wrong permissions for operation. Skipping over ...
Successfully exported object authentication-key with ID 0x0003 to ./0x0003-authentication-key.yhw
Successfully exported object authentication-key with ID 0x0004 to ./0x0004-authentication-key.yhw
All done

[eurolinux@el ~]$ ls
0x0003-authentication-key.yhw  genpublic.pem
0x0004-authentication-key.yhw  private.pem
0x0005-asymmetric-key.yhw      public.pem
0x0006-asymmetric-key.yhw

Na pytanie o ID klucza wrapującego, którym mają zostać opakowane wszystkie eksportowane obiekty, wskazaliśmy ID 2. Z powyższych informacji wynika, że niemożliwe było wyeksportowanie klucza MasterKey oraz klucza wrapującego 0x0002, a reszta kluczy została opakowana i zapisana na dysku w katalogu roboczym. Części klucza wrapującego 0x0002 mamy jednak już podzielone na trzech naszych administratorów, dzięki czemu możliwe jest zaimportowanie reszty kluczy do nowego, zapasowego modułu HSM.

Zalogujmy się jeszcze raz do modułu kluczem autoryzującym o ID 3 i wyświetlmy wszystkie obiekty w urządzeniu, dane o zajętej przestrzeni i ogólne informacje o module:

[eurolinux@el ~]$ yubihsm-shell
Using default connector URL: http://127.0.0.1:12345
yubihsm> connect
Session keepalive set up to run every 15 seconds
yubihsm> session open 3
Enter password: 
Created session 0
yubihsm> list objects 0
Found 6 object(s)
id: 0x0002, type: wrap-key, sequence: 0
id: 0x0003, type: authentication-key, sequence: 0
id: 0x0004, type: authentication-key, sequence: 0
id: 0x0005, type: asymmetric-key, sequence: 0
id: 0x0006, type: asymmetric-key, sequence: 0
id: 0x0009, type: authentication-key, sequence: 0
yubihsm> get storage 0
free records: 250/256, free pages: 1004/1024 page size: 126 bytes
yubihsm> get deviceinfo
Version number:		2.2.0
Serial number:		16499959
Log used:		55/62
Supported algorithms:	rsa-pkcs1-sha1, rsa-pkcs1-sha256, rsa-pkcs1-sha384, 
			rsa-pkcs1-sha512, rsa-pss-sha1, rsa-pss-sha256, 
			rsa-pss-sha384, rsa-pss-sha512, rsa2048, 
			rsa3072, rsa4096, ecp256, 
			ecp384, ecp521, eck256, 
			ecbp256, ecbp384, ecbp512, 
			hmac-sha1, hmac-sha256, hmac-sha384, 
			hmac-sha512, ecdsa-sha1, ecdh, 
			rsa-oaep-sha1, rsa-oaep-sha256, rsa-oaep-sha384, 
			rsa-oaep-sha512, aes128-ccm-wrap, opaque-data, 
			opaque-x509-certificate, mgf1-sha1, mgf1-sha256, 
			mgf1-sha384, mgf1-sha512, template-ssh, 
			aes128-yubico-otp, aes128-yubico-authentication, aes192-yubico-otp, 
			aes256-yubico-otp, aes192-ccm-wrap, aes256-ccm-wrap, 
			ecdsa-sha256, ecdsa-sha384, ecdsa-sha512, 
			ed25519, ecp224, rsa-pkcs1-decrypt, 
			
yubihsm> session close 0

Otwórzmy nową sesję korzystając z klucza audytu o ID 4 i wyświetlmy log zdarzeń kryptograficznych:

yubihsm> session open 4
Enter password: 
Created session 0
yubihsm> audit get 0
0 unlogged boots found
0 unlogged authentications found
Found 58 items
item:     1 -- cmd: 0xff -- length: 65535 -- session key: 0xffff -- target key: 0xffff -- second key: 0xffff -- result: 0xff -- tick: 4294967295 -- hash: 37223398636214763cb25f56370d261a
item:     2 -- cmd: 0x00 -- length:    0 -- session key: 0xffff -- target key: 0x0000 -- second key: 0x0000 -- result: 0x00 -- tick: 0 -- hash: 20093cb7a5ccba04e7ccaabc66617f37
item:     3 -- cmd: 0x03 -- length:   10 -- session key: 0xffff -- target key: 0x0001 -- second key: 0xffff -- result: 0x83 -- tick: 44011 -- hash: ee9a3e41ebaaf69cbf24cabe1335ffd8
item:     4 -- cmd: 0x04 -- length:   17 -- session key: 0xffff -- target key: 0x0001 -- second key: 0xffff -- result: 0x84 -- tick: 44011 -- hash: 029ba4e75b02529003515fe2a32b90ca
(...)
item:    58 -- cmd: 0x04 -- length:   17 -- session key: 0xffff -- target key: 0x0004 -- second key: 0xffff -- result: 0x84 -- tick: 199145 -- hash: 9d654498b49407dd84ebd15c66dc48fd
yubihsm> session close 0

Po zamknięciu sesji otwórzmy nową i już ostatnią sesję za pomocą naszego MasterKey o ID 9 i software’owo przywróćmy urządzenie do ustawień fabrycznych:

yubihsm> session open 9
Enter password: 
Created session 0
yubihsm> reset 0
Device successfully reset
yubihsm> quit

Przywracanie danych modułu HSM z backupu

Aby przywrócić zdumpowane wcześniej klucze, musimy poprosić o pomoc przynajmniej dwóch administratorów posiadających po jednej części klucza wrapującego o ID 2, którym zaszyfrowane są wszystkie klucze umieszczone w katalogu roboczym. Tym razem uruchomimy polecenie yubihsm-setup z przełącznikiem -d, dzięki któremu nie zostanie skasowany klucz autoryzujący o ID 1, domyślnie dostarczony z urządzeniem. Ponieważ moduł jest zresetowany, korzystamy ze standardowego hasła: password. W polu number of shares podajemy tylko wymaganą liczbę części, czyli w naszym przypadku 2.

[eurolinux@el ~]$ yubihsm-setup -d restore
Enter authentication password: password
Using authentication key 0x0001
Enter the number of shares: 2
Enter share number 1: 2-1-fY/UAf6cK1/vklhSoM++u9QziaSqXGM2XDv9B1jAjEOBGh8NLmrpFGu/verU4gw5XsyNpg
Received share 2-1-fY/UAf6cK1/vklhSoM++u9QziaSqXGM2XDv9B1jAjEOBGh8NLmrpFGu/verU4gw5XsyNpg
Enter share number 2: 2-3-h4hhAR+5feEsq4j2/Uzf0GNX+gzPT9nvdTXMUch6eRSwuUdgSwRd4nab0k2Bga8lQhAThg
Received share 2-3-h4hhAR+5feEsq4j2/Uzf0GNX+gzPT9nvdTXMUch6eRSwuUdgSwRd4nab0k2Bga8lQhAThg
Stored wrap key with ID 0x0002 on the device

reading ./0x0003-authentication-key.yhw
Successfully imported object authentication-key, with ID 0x0003
reading ./0x0004-authentication-key.yhw
Successfully imported object authentication-key, with ID 0x0004
reading ./0x0005-asymmetric-key.yhw
Successfully imported object asymmetric-key, with ID 0x0005
reading ./0x0006-asymmetric-key.yhw
Successfully imported object asymmetric-key, with ID 0x0006
Previous authentication key 0x0001 *not* deleted. Make sure you know what you are doing
All done

Nasze dwa klucze RSA (jeden zaimportowany z pliku, a drugi utworzony bezpośrednio w module) zostały ponownie umieszczone w HSM-ie i ponownie możliwe jest podpisywanie nimi plików oraz weryfikacja podpisów za pomocą obecnych na dysku kluczy publicznych public.pem i genpublic.pem. Klucz autoryzujący o ID 3 i klucz audytu o ID 4 również zostały poprawnie zaimportowane. Po wykonaniu kilku dodatkowych operacji moduł może być używany produkcyjnie po skasowaniu klucza dostarczonego fabrycznie o ID 1:

yubihsm> delete 0 1 authentication-key

Podsumowanie

Sprzętowy moduł bezpieczeństwa zapewnia najwyższy stopień ochrony w naszej firmie, co obejmuje delegację usług kryptograficznych poza obszar aplikacji, ochronę integralności i poufności dokumentów, ochronę certyfikatów i kluczy przed atakami fizycznymi oraz sieciowymi. Zastosowanie modułów HSM w EuroLinux Sp. z o.o. gwarantuje bezpieczeństwo kluczy oraz korzystających z nich aplikacji zgodnie z procedurami kryptograficznymi zawartymi w amerykańskiej normie FIPS 140-2 level 3.