pvsecret verify - Verify that an add-secret request is sane
pvsecret verify [OPTIONS] <FILE>
Verifies that the given request is an Add-Secret request by
testing for some values to be present. If the request contains signed
user-data, the signature is verified with the provided key. Outputs the
arbitrary user-data. All data in the request is in big endian.
verify checks the following:
- •
- The first 6 bytes of the request are equal to: 6173 7263 624d |
asrcbM
- •
- The sizes in the request header are sane and do not point out of the
file
- •
- The request version is supported by the binary
- •
- If user-data contains a signature, verify the signature using a public
key
The content of bytes 6&7 of the request define which kind of
user-data the request contains.
- 0x0000
- no user-data (512 bytes zero)
- 0x0001
- 512 bytes user-data
- 0x0002
- 265 bytes user-data| 139 bytes ecdsa signature | 5 bytes reserved | 2
bytes signature size | ...
- 0x0003
- 256 bytes user-data | 256 bytes rsa2048 signature
- 0x0004
- 128 bytes user-data | 384 bytes rsa3072 signature
The actual user-data may be less than the capacity. If less data
was provided during create zeros are appended. For type 2-4 The
signature is calculated as follows:
- 1.
- The request is generated with the user-data in place and zeros for the
signature data.
- 2.
- The signature is calculated for the request. The signature signs the
authenticated data and the encrypted data, but not the request tag. I.e.
the signature signs the whole request but the last 16 bytes and with the
signature bytes set to zero.
- 3.
- The signature is inserted to its location in the request.
- 4.
- The request GCM tag is calculated.
The verification process works as follows:
- 1.
- copy the signature to a buffer
- 2.
- overwrite the signature with zeros
- 3.
- verify the signature of the request but the last 16 bytes
<FILE>
Specify the request to be checked.
--user-cert <FILE>
Certificate containing a public key used to verify the
user data signature. Specifies a public key used to verify the user-data
signature. The file must be a X509 certificate in DSA or PEM format. The
certificate must hold the public EC, RSA 2048, or RSA 3072 key corresponding
to the private user-key used during `create`. No chain of trust is
established. Ensuring that the certificate can be trusted is the
responsibility of the user. The EC key must use the NIST/SECG curve over a 521
bit prime field (secp521r1).
-o, --output <FILE>
Store the result in FILE If the request contained
abirtary user-data the output contains this user-data with padded zeros if
available. [default: '-']
Create the add-secret request on a trusted system with signed user
datai similar to the example for pvsecret. Let's assume there are three
more files present .user_data contains ascii "some example
user-data", a private user-signing key e.g. rsa3072
usr_sgn_key.priv.pem, and a certificate containing the corresponding public
key to the private rsa3072 key user_cert.pem.
- trusted:~$
- pvsecret create -k hkd.crt --cert CA.crt --cert ibmsk.crt --hdr pvimage -o
addsecreq.bin --user-data user_data --user-sign-key usr_sgn_key.priv.pem
association EXAMPLE
Successfully generated the request
Successfully wrote association info to 'EXAMPLE.yaml'
For example, on the SE-guest, perform verify on the request
to verify the user-signature and the saneness of the request. On success,
The user-data is printed to stdout (if --output was not specified)
and Succesfully verified the request. is printed to stderr.
- seguest:~$
- pvsecret verify --user-cert user_cert.pem -o addsecreq.bin
some example user-data
Successfully verified the request