Creating root keys
You can use IBM Cloud® Hyper Protect Crypto Services to create root keysA symmetric wrapping key that is used for encrypting and decrypting other keys that are stored in a data service. by using the UI, or programmatically with the Hyper Protect Crypto Services key management service API.
Root keys are symmetric key-wrapping keys that are used to protect the security of encrypted data in the cloud. For more information about root keys, see Envelope encryption.
Creating root keys with the UI
After you create an instance of the service, complete the following steps to create a root key with the UI.
If you enable dual authorization settings for your Hyper Protect Crypto Services instance, keep in mind that any keys that you add to the service require an authorization from two users to delete keys.
-
Go to Menu > Resource list to view a list of your resources.
-
From your IBM Cloud resource list, select your provisioned instance of Hyper Protect Crypto Services.
-
To create a new key, select the KMS keys tab in the side menu.
-
In the Keys table, click Add key, and select Create a key.
Specify the key's details:
Describes the settings to create a key Setting Description Key type The type of key that you would like to manage in Hyper Protect Crypto Services. From the list of key types, select Root key. Key name A unique, human-readable name for easy identification of your key. Length must be within 2 - 90 characters. To protect your privacy, ensure that the key name does not contain personally identifiable information (PII), such as your name or location. Key alias (Optional) One or more unique, human-readable aliases that you want to assign to your key for easy recognition. Alias size can be 2 - 90 characters. You can set up to five key aliases for the key, with each separated by a comma. Note: Each alias must be alphanumeric, case-sensitive, and cannot contain spaces or special characters other than dashes (-) or underscores (_). The alias cannot be a version 4 UUID and must not be a Hyper Protect Crypto Services reserved name:
allowed_ip
,key
,keys
,metadata
,policy
,policies
,registration
,registrations
,ring
,rings
,rotate
,wrap
,unwrap
,rewrap
,version
,versions
.Key ring ID Select a key ring from the list that contains the existing key rings. If you don't assign a key ring, the key is added to the default
key ring. For more information about key rings, see Managing key rings.Expiration date Optional. The date and time that the key expires in the system, in RFC 3339 format (YYYY-MM-DD HH:MM:SS.SS, for example 2019-10-12T07:20:50.52Z). Use caution when setting an expiration date, as keys created with an expiration date automatically transition to the Deactivated state within one hour after expiration. In this state, the only allowed actions on the key are unwrap, rewrap, rotate, and delete. Deactivated keys cannot be used to encrypt (wrap) new data, even if rotated while deactivated. Rotation does not reset or extend the expiration date, nor does it allow the date to be changed. It is recommended that any data encrypted with an expiring or expired key be re-encrypted using a new customer root key (CRK) before the original CRK expires, to prevent service disruptions. Deleting and restoring a deactivated key does not move it back to the Active state. If the expiration_date attribute is omitted, the key does not expire. Description (Optional) Add an extended description for your key. It can be two to 240 characters in length. -
When you finish filling out the key's details, click Create key to confirm.
Keys that are created in the service are symmetric 256-bit keys, supported by the AES-CBC algorithm. For added security, keys are generated by FIPS 140-2 Level 4 certified hardware security modules (HSMs)A physical appliance that provides on-demand encryption, key management, and key storage as a managed service. that are located in secure IBM Cloud data centers.
Creating root keys with the API
Create a root key by making a POST
call to the following endpoint.
https://<instance_ID>.api.<region>.hs-crypto.appdomain.cloud/api/v2/keys
-
Retrieve your service and authentication credentials to work with keys in the service.
-
Call the Hyper Protect Crypto Services key management service API with the following
curl
command.curl -X POST \ "https://<instance_ID>.api.<region>.hs-crypto.appdomain.cloud/api/v2/keys" \ -H "authorization: Bearer <IAM_token>" \ -H "bluemix-instance: <instance_ID>" \ -H "content-type: application/vnd.ibm.kms.key+json" \ -H "x-kms-key-ring: <key_ring_ID>" \ -H "correlation-id: <correlation_ID>" \ -d '{ "metadata": { "collectionType": "application/vnd.ibm.kms.key+json", "collectionTotal": 1 }, "resources": [ { "type": "application/vnd.ibm.kms.key+json", "name": "<key_name>", "aliases": [alias_list], "description": "<key_description>", "expirationDate": "<YYYY-MM-DDTHH:MM:SS.SSZ>", "extractable": <key_type> } ] }'
Replace the variables in the example request according to the following table.
Describes the variables needed to add a root key with the API Variable Description region
Required. The region abbreviation, such as us-south
orau-syd
, that represents the geographic area where your Hyper Protect Crypto Services service instance resides. For more information, see Regional service endpoints.port
Required. The port number of the API endpoint. IAM_token
Required. Your IBM Cloud access token. Include the full contents of the IAM
token, including the Bearer value, in the cURL request. For more information, see Retrieving an access token.instance_ID
Required. The unique identifier that is assigned to your Hyper Protect Crypto Services service instance. For more information, see Retrieving an instance ID. key_ring_ID
Optional. The unique identifier of the target key ring that you want to assign the key to. If unspecified, the header is automatically set to default
and the key belongs to the default key ring in the specified Hyper Protect Crypto Services instance.For more information, see Managing key rings.
correlation_ID
The unique identifier that is used to track and correlate transactions. key_name
Required. A unique, human-readable name for easy identification of your key. Important: To protect your privacy, do not store your personal data as metadata for your key.
alias_list
Optional. One or more unique, human-readable aliases assigned to your key. Important: To protect your privacy, do not store your personal data as metadata for your key.
Each alias must be alphanumeric, case-sensitive, and cannot contain spaces or special characters other than dashes (-) or underscores (_). The alias cannot be a version 4 UUID and must not be a Hyper Protect Crypto Services reserved name:
allowed_ip
,key
,keys
,metadata
,policy
,policies
,registration
,registrations
,ring
,rings
,rotate
,wrap
,unwrap
,rewrap
,version
,versions
. Alias size can be 2 - 90 characters (inclusive).key_description
Optional: An extended description of your key. Important: To protect your privacy, do not store your personal data as metadata for your key.
expiration_date
Optional. The date and time that the key expires in the system, in RFC 3339 format (YYYY-MM-DD HH:MM:SS.SS, for example 2019-10-12T07:20:50.52Z). Use caution when setting an expiration date, as keys created with an expiration date automatically transition to the Deactivated state within one hour after expiration. In this state, the only allowed actions on the key are unwrap, rewrap, rotate, and delete. Deactivated keys cannot be used to encrypt (wrap) new data, even if rotated while deactivated. Rotation does not reset or extend the expiration date, nor does it allow the date to be changed. It is recommended that any data encrypted with an expiring or expired key be re-encrypted using a new customer root key (CRK) before the original CRK expires, to prevent service disruptions. Deleting and restoring a deactivated key does not move it back to the Active state. If the expiration_date attribute is omitted, the key does not expire. key_type
A boolean value that determines whether the key material can leave the service. When you set the
extractable
attribute tofalse
, the service creates a root key that you can use forwrap
orunwrap
operations.If you set the
expirationDate
in your request, the key is moved to the deactivated state within 1 hour past the key's expiration date. The date and time that the key expires in the system, in RFC 3339 format (YYYY-MM-DD HH:MM:SS.SS, for example 2019-10-12T07:20:50.52Z). Use caution when setting an expiration date, as keys created with an expiration date automatically transition to the Deactivated state within one hour after expiration. In this state, the only allowed actions on the key are unwrap, rewrap, rotate, and delete. Deactivated keys cannot be used to encrypt (wrap) new data, even if rotated while deactivated. Rotation does not reset or extend the expiration date, nor does it allow the date to be changed. It is recommended that any data encrypted with an expiring or expired key be re-encrypted using a new customer root key (CRK) before the original CRK expires, to prevent service disruptions. Deleting and restoring a deactivated key does not move it back to the Active state. If the expirationDate attribute is omitted, the key does not expire.You can monitor the usage of keys with expiration dates using IBM Cloud Logs. The logs indicate the expiration date and the number of days remaining using the JSON properties
responseData.expirationDate
andresponseData.daysToKeyExpire
for keys that have expiration date and for the followingaction
values:kms.secrets.wrap
,kms.secrets.unwrap
,kms.secrets.rewrap
,kms.secrets.read
,kms.secrets.readmetadata
,kms.secrets.create
,kms.secrets-with-policy-overrides.create
andkms.secrets.expire
. In addition, a successful REST call toGET /api/v2/keys
returns theexpirationDate
property for each key that has an expiration date.To protect the confidentiality of your personal data, avoid entering personally identifiable information (PII), such as your name or location, when you add keys to the service. For more examples of PII, see section 2.2 of the NIST Special Publication 800-122.
A successful
POST /v2/keys
response returns the ID value for your key, along with other metadata. The ID is a unique identifier that is assigned to your key and is used for subsequent calls to the Hyper Protect Crypto Services key management service API.{ "metadata": { "collectionType": "application/vnd.ibm.kms.key+json", "collectionTotal": 1 }, "resources": [ { "type": "application/vnd.ibm.kms.key+json", "id": "02fd6835-6001-4482-a892-13bd2085f75d", "name": "test-root-key", "aliases": [ "alias-1", "alias-2" ], "description": "A test root key", "state": 1, "extractable": false, "crn": "crn:v1:bluemix:public:hs-crypto:us-south:a/f047b55a3362ac06afad8a3f2f5586ea:12e8c9c2-a162-472d-b7d6-8b9a86b815a6:key:02fd6835-6001-4482-a892-13bd2085f75d", "imported": false, "creationDate": "2020-03-12T03:37:32Z", "createdBy": "...", "algorithmType": "AES", "algorithmMetadata": { "bitLength": "256", "mode": "CBC_PAD" }, "algorithmBitSize": 256, "algorithmMode": "CBC_PAD", "lastUpdateDate": "2020-03-12T03:37:32Z", "keyVersion": { "id": "2291e4ae-a14c-4af9-88f0-27c0cb2739e2", "creationDate": "2020-03-12T03:37:32Z" }, "dualAuthDelete": { "enabled": false }, "deleted": false } ] }
For a detailed description of the response parameters, see the Hyper Protect Crypto Services REST API reference doc.
-
Optional: Verify that the key was created by running the following call to browse the keys in your Hyper Protect Crypto Services service instance.
curl -X GET \ https://<instance_ID>.api.<region>.hs-crypto.appdomain.cloud/api/v2/keys \ -H 'accept: application/vnd.ibm.collection+json' \ -H 'authorization: Bearer <IAM_token>' \ -H 'bluemix-instance: <instance_ID>' \ -H 'correlation-id: <correlation_ID>' \
After you create a root key with the service, the key stays within the bounds of Hyper Protect Crypto Services, and the key material cannot be retrieved.
What's next
- To find out more about protecting keys with envelope encryption, check out Wrapping keys.
- To find out instruction on importing your own key, check out Importing root keys or Importing standard keys.
- To find out more about programmatically managing your keys, check out the Hyper Protect Crypto Services key management service API reference doc.