1. Manuals
  2. Tumbleweed
  3. s390-tools
  4. pvsecret-verify(1)

Scroll to navigation

pvsecret-verify(1) UV-Secret Manual pvsecret-verify(1)

NAME

pvsecret verify - Verify that an add-secret request is sane

SYNOPSIS

pvsecret verify [OPTIONS] <FILE>

DESCRIPTION

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

OPTIONS

<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: '-']

EXAMPLES

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.

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.

pvsecret verify --user-cert user_cert.pem -o addsecreq.bin
some example user-data
Successfully verified the request

SEE ALSO

pvsecret(1)

2024-01-30 s390-tools