NAME¶
pvsecret create - Create a new add-secret request
SYNOPSIS¶
pvsecret create [OPTIONS] --host-key-document <FILE> --hdr <FILE> --output <FILE> <--no-verify|--cert <FILE>> <COMMAND>
DESCRIPTION¶
Create add-secret requests for IBM Secure Execution guests. Only
create these requests in a trusted environment, such as your workstation.
The pvattest create command creates a randomly generated key
to protect the request. The generated requests can then be added on an IBM
Secure Execution guest using pvsecret add. The guest can then use the
secrets with the use case depending on the secret type.
Such a request is bound to a specific IBM Secure Execution image
specified with --hdr. Optionally, the request can be bound to a
specific instance when bound to the Configuration Unique ID from
pvattest using --cuid
OPTIONS¶
-k, --host-key-document <FILE>
Use FILE as a host-key document. Can be specified
multiple times and must be used at least once.
--no-verify
Disable the host-key document verification. Does not
require the host-key documents to be valid. Do not use for a production
request unless you verified the host-key document beforehand.
-C, --cert <FILE>
Use FILE as a certificate to verify the host key or keys.
The certificates are used to establish a chain of trust for the verification
of the host-key documents. Specify this option twice to specify the IBM Z
signing key and the intermediate CA certificate (signed by the root CA).
--crl <FILE>
Use FILE as a certificate revocation list. The list is
used to check whether a certificate of the chain of trust is revoked. Specify
this option multiple times to use multiple CRLs.
--offline
Make no attempt to download CRLs
--root-ca <ROOT_CA>
Use FILE as the root-CA certificate for the verification.
If omitted, the system-wide root CAs installed on the system are used. Use
this only if you trust the specified certificate.
--hdr <FILE>
Specifies the header of the guest image. Can be an IBM
Secure Execution image created by genprotimg or an extracted IBM Secure
Execution header. The header must start at a page boundary.
-f, --force
Force the generation of add-secret requests on IBM Secure
Execution guests. If the program detects that it is running on an IBM Secure
Execution guest, it denies the generation of add-secret requests. The force
flag overwrites this behavior.
-o, --output <FILE>
Write the generated request to FILE
--extension-secret <FILE>
Use the content of FILE as an extension secret. The file
must be exactly 32 bytes long. If this request is the first, all subsequent
requests must have the same extension secret. Only makes sense if bit 1 of the
secret control flags of the IBM Secure Execution header is 0. Otherwise the
ultravisor rejects the request.
--cck <FILE>
Use the content of FILE as the customer-communication key
(CCK) to derive the extension secret. The file must contain exactly 32 bytes
of data. If the target guest was started with bit 1 of the secret control flag
set, the ultravisor also derives the secret from the CCK. Otherwise, the
ultravisor interprets the extension secret as a normal one. This still works
if you use the same CCK for all requests.
--cuid-hex <HEXSTRING>
Use HEXSTRING as the Configuration Unique ID. Must be a
hex 128-bit unsigned big endian number string. Leading zeros must be provided.
If specified, the value must match with the Config-UID from the attestation
result of that guest. If not specified, the CUID will be ignored by the
ultravisor during the verification of the request.
--cuid <FILE>
Use the content of FILE as the Configuration Unique ID.
The file must contain exactly 128 bit of data, a hex string, or a yaml with a
`cuid` entry. If specified, the value must match the Config-UID from the
attestation result of that guest. If not specified, the CUID will be ignored
by the Ultravisor during the verification of the request.
--flags <FLAGS>
Flags for the add-secret request.
Possible values:
-
disable-dump: Disables host-initiated dumping
for the target guest instance.