This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)(Learn how and when to remove this template message)
Root Key Signing CeremonyEdit
In public-key cryptography and computer security, a root key ceremony is a procedure where a unique pair of public and private root keys is generated. Depending on the certificate policy, the generation of the root keys may require notarization, legal representation, witnesses and "key holders" to be present, as the information on the system is a responsibility of the parties. A commonly recognized best practice is to follow the SAS 70 standard for root key ceremonies.
At the heart of every certificate authority (CA) is at least one root key or root certificate and usually at least one intermediate root certificate. A root key is a term for a unique passcode that must be generated for secure server interaction with a protective network, usually called the root zone. Prompts for information from this zone can be done through a server. The keys and certificates mentioned are the credentials and safe guards for the system. These digital certificates are made from a public and a private key.
Example A: These passcodes are used for Strong identification and non-repudiation for email and web access
Unless the information being accessed or transmitted is valued in terms of millions of dollars, it is probably sufficient that the root key ceremony be conducted within the security of the vendor's laboratory. The customer may opt to have the root key stored in a hardware security module, but in most cases, the safe storage of the root Key on a CD or hard disk is sufficient. The root key is never stored on the CA server.
Example B: Machine Readable Travel Document [MRTD] ID Card or e Passport
This type of environment requires much higher security. When conducting the root key ceremony, the government or organization will require rigorous security checks to be conducted on all personnel in attendance. Those that are normally required to attend the key ceremony will include a minimum of two administrators from the organization, two signatories from the organization, one lawyer, a notary, and two video camera operators, in addition to the CA software vendor's own technical team.
Example A and B are at opposite ends of the security spectrum and no two environments are the same. Depending on the level of protection required, different levels of security will be used.
The actual root key-pair generation is normally conducted in a secure vault that has no communication or contact with the outside world other than a single telephone line or intercom. Once the vault is secured, all personnel present must prove their identity using at least two legally recognized forms of identification. Every person present, every transaction and every event is logged by the lawyer in a root key ceremony log book and each page is notarized by the notary. From the moment the vault door is closed until it is re-opened, everything is also video recorded. The lawyer and the organization's two signatories must sign the recording and it too is then notarized.
Finally, as part of the above process, the root key is broken into as many as twenty-one parts and each individual part is secured in its own safe for which there is a key and a numerical lock. The keys are distributed to as many as twenty-one people and the numerical code is distributed to another twenty-one people.
The CA vendors and organisations that would implement projects of this nature where conducting a root key ceremony would be a central component of their service would be organisations like, for example; RSA, VeriSign and Digi-Sign.
IBM HSM key ceremonyEdit
Hardware security module (HSM) key ceremony is a procedure where the master key is generated and loaded to initialize use of the HSM. Master key is at the top of the key hierarchy and is the root of trust to encrypt all other keys generated by the HSM. A master key is composed of at least two master key parts. Each key part is normally owned by a different person to enhance security.
Master key typesEdit
The master key is stored within the HSM. IBM HSMs support two types of cryptographic mechanisms:
- The PKCS#11 mechanism, called IBM Enterprise PKCS #11 (EP11), creates a high-security solution for application programs developed for this industry-standard API.
- The IBM Common Cryptographic Architecture (CCA)  mechanism provides many functions of special interest in the finance industry, extensive support for distributed key management, and a base on which custom processing and cryptographic functions can be added.
Depending on the cryptographic mechanisms that the HSM supports and the key objects that are encrypted by the master key, the following types of master keys are available:
- EP11 HSMs 
- EP11 symmetric master key: used to encipher all kinds of sensitive materials including secret key objects and intermediate state information containing secret key materials.
- CCA HSMs 
HSM key ceremony typesEdit
On-premise HSM Key CeremonyEdit
For IBM Z and LinuxONE Systems, the HSMs are used to perform cryptographic operations. The HSM has 85 domains with each having its own set of master keys. Before using the system, the HSM Key Ceremony must be conducted to load the master key securely and properly. For EP11 HSMs, the master key parts are stored on smart cards and are loaded to the HSM with the Trusted Key Entry (TKE) workstation. For CCA HSMs, the master key parts can be stored either on smart cards or in files on the TKE workstation.
Cloud HSM Key CeremonyEdit
EP11 HSM is currently the only type of HSM that supports Key Ceremony in the cloud. Both cloud command-line interface (CLI) or smart cards are provided to load the master key parts to the cloud HSM. IBM Cloud Hyper Protect Crypto Services is now the only service in the cloud that can provide HSM key ceremony through both CLI and smart cards. IBM Cloud Hyper Protect Crypto Services is a key management service and cloud HSM in the cloud to enable hardware-based cryptographic operations. With Crypto Card 4768, the FIPS 140-2 Level 4 certified crypto card, it provides the highest cryptographic security level in the cloud.
Master key part storageEdit
Depending on the key ceremony types, the master key parts can be stored either on smart cards or in files on the workstation.
Smart cards are protected by a personal identification number (PIN) that must be entered on a smart card reader pad. Each master key part owner has one smart card and only the owner knows its PIN. This solution ensures that the master key parts never appear in the clear outside the smart cards.
Compared with the smart card solution, the workstation solution does not require the procurement of smart card readers and smart cards. This solution uses workstation files that are encrypted with a key that is derived from a file password to store master key parts. When the keys are used, file content is decrypted and appear temporarily in the clear in workstation memory.
- "CEX7S / 4769 EP11". www.ibm.com. Retrieved 2020-06-24.
- "CEX7S / 4769 CCA". www.ibm.com. Retrieved 2020-06-24.
- "Enterprise PKCS#11 (EP11) Library structure" (PDF). public.dhe.ibm.com.
- Master key is referred to as Wrapping Key (WK) in the EP11 documentation.
- "Getting Started with Linux on Z Encryption for Data At-Rest". redbooks.ibm.com. 2016-09-30. Retrieved 2020-06-24.
- "Streamline Management of the IBM z Systems Host Cryptographic Module Using IBM Trusted Key Entry". redbooks.ibm.com. 2016-09-30. Retrieved 2020-06-24.
- "IBM Hyper Protect Services - Overview". www.ibm.com. Retrieved 2020-06-24.
- "IBM Cloud Hyper Protect Crypto Services FAQs". cloud.ibm.com.
- Summary of events at DNSSEC KSK Ceremony 22, which took place 13 August 2015 at the ICANN Key Management Facility, El Segundo, CA, USA
- IBM Crypto Cards
- IBM 4768 Crypto Card overview
- IBM Cloud Hyper Protect Crypto Services overview
- z/OS Trusted Key Entry
- Education videos for using TKE to manage crypto modules on IBM Z and LinuxONE