search

Yubico / yubihsm-shell

yubihsm-shell and libyubihsm
https://developers.yubico.com/yubihsm-shell/
Apache License 2.0
93 stars 54 forks source link

Cannot put wrap according to the documentation #59

Closed v6ak closed 5 years ago

v6ak commented 5 years ago

I have tried to follow the guide and use the command yubihsm-shell (authentication options) -a put-wrap-key -i 20 -c all --delegated all --informat bin --in wrap.key. It has ended with the following error:

Session keepalive set up to run every 15 seconds
Created session 0
Failed to store wrapkey: Malformed command / invalid data
Unable to put wrapkey

I have also added --verbose=9:

[LIB - INF 09:17:39.648542] yubihsm.c:4052 (yh_init_connector): Loading http backend
[LIB - INF 09:17:39.654880] yubihsm_curl.c:88 (backend_connect): Trying to connect to http://XXX.YYY.ZZZ.AAA:12345/connector/status
[LIB - INF 09:17:39.700006] lib_util.c:129 (parse_status_data): response from connector
[LIB - INF 09:17:39.700035] lib_util.c:130 (parse_status_data): has device: yes
[LIB - INF 09:17:39.700041] lib_util.c:132 (parse_status_data): version: 2.0.0
[LIB - INF 09:17:39.700045] lib_util.c:133 (parse_status_data): pid: 17400
[LIB - INF 09:17:39.700050] lib_util.c:134 (parse_status_data): address: 0.0.0.0
[LIB - INF 09:17:39.700055] lib_util.c:135 (parse_status_data): port: 12345
[LIB - INF 09:17:39.700059] yubihsm_curl.c:129 (backend_connect): Found working connector
Session keepalive set up to run every 15 seconds
[LIB - INT 09:17:39.705290] yubihsm.c:666 (yh_create_session): Host challenge: 629c9dcf0a676bd5
[LIB - INF 09:17:39.727969] yubihsm.c:699 (yh_create_session): Received Session ID: 0
[LIB - INT 09:17:39.727992] yubihsm.c:702 (yh_create_session): Card challenge: 8bc2f4027b7cfee8
[LIB - INT 09:17:39.728005] yubihsm.c:703 (yh_create_session): Card cryptogram: 9fe021ad171e0daa
[LIB - INT 09:17:39.728021] yubihsm.c:721 (yh_create_session): S-ENC: 436ec1cc404503f9 4f984a0fcd6fab6f
[LIB - INT 09:17:39.728040] yubihsm.c:722 (yh_create_session): S-MAC: 11c796d63780a372 dc4a2c4fd4b3c1d1
[LIB - INT 09:17:39.728060] yubihsm.c:723 (yh_create_session): S-RMAC: eba33bcfc501def1 a553b6b75cba0c46
[LIB - INF 09:17:39.728080] yubihsm.c:732 (yh_create_session): Card cryptogram successfully verified
[LIB - INT 09:17:39.728088] yubihsm.c:2954 (yh_authenticate_session): Host cryptogram: 87fa25519ec59904
Created session 0
[LIB - INF 09:17:39.762697] yubihsm.c:4583 (yh_string_to_domains): Domains parsed as ffff
Failed to get input data
[LIB - INF 09:17:39.762743] yubihsm.c:304 (_send_secure_msg): Sending cmd 40 (  3 Bytes): 400000
[LIB - INF 09:17:39.780365] yubihsm.c:365 (_send_secure_msg): Response MAC successfully verified

Possibly related issues

Software version

apt-cache policy yubihsm-shell  | grep Installed
  Installed: 2.0.1-1
klali commented 5 years ago

Can you re-run this with --verbose=0xff (this will print sensitive data to the screen, so please only do this with dummy data).

I would guess that the "Failed to get input data" that we can see in your log is failing to read the wrap.key file. This example does work for me, can you check that the file wrap.key does exist in the current directory and only contains the 16 bytes it should?

v6ak commented 5 years ago

(Sorry, I was too fast…)

OK, there is the output: https://gist.github.com/v6ak/0a412fe28445a74859b9845b8bf6b270

(There should be no sensitive data, the device is not in production and it is going to be reset and use a different password for that.)

The problem is not in a bad filename. When I modify the filename, it writes Key length not matching, should be 16, 24 or 32. The wrap.key is owned by the current user and has 0600 mode.

klali commented 5 years ago

So something fails while reading the wrap.key can you hexdump that file? it should look like:

$ hexdump wrap.key 
0000000 1100 3322 5544 7766 9988 bbaa ddcc ffee
0000010
$
klali commented 5 years ago

Sorry, I didn't read your gist log correctly. You have different errors in your gist log and the first one you posted here. In the gist it gets an error from the HSM.

Can you do a get deviceinfo on the hsm and post the result here? (feel free to censor serial number)

v6ak commented 5 years ago

Hmm, because I cannot reproduce the first error, it seems that the latter log (with --verbose=0xff) is the relevant.

There is the device info:

yubihsm> get deviceinfo
Version number:     2.0.0
Serial number:      XXXXXXX
Log used:       62/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,

EDIT: If you are concerned about the “62/62”, then this should not be an issue. I haven't enabled strict logging. Also, if it was disabled, signing would not work, which is not our case.

v6ak commented 5 years ago

Oh, I missed your comment about hexdump. I have checked the wrap.key with wc -c, which shows it has 16 bytes, which should be OK for a binary file. The hexdump is here:

hexdump wrap.key 
0000000 1100 3322 5544 7766 9988 bbaa ddcc ffee
0000010
klali commented 5 years ago

It works for me with a 2.0.0 hsm.

I think this is a permissions related thing with the authkey you're using.

v6ak commented 5 years ago

Does it have the capability put-wrap-key?

Yes, it has:

yubihsm> get  objectinfo 0 0x0002 authentication-key
id: 0x0002, type: authentication-key, algorithm: aes128-yubico-authentication, label: "newadmin", length: 40, domains: 1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16, sequence: 0, origin: imported, capabilities: 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: sign-pkcs

Does it have all delegated capabilities?

Oops…

So, this looks like:

  1. My failure. I did not have all the capabilities I need.
  2. YubiHSM or YubiHSM-shell cannot report useful error message. It could have reported something like you wrote in the last comment.
klali commented 5 years ago

Glad that we got that figured out.

Yes, very much agreed, the error reported for this case should be better.

edit: and as a side-note, this is a bit better with a newer YubiHSM, the error reported in that case would've been "Wrong permissions for operation".