Jump to content

Key ceremony: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Pen2ra (talk | contribs)
m added comma
No edit summary
 
(47 intermediate revisions by 40 users not shown)
Line 1: Line 1:
{{Short description|Event in cryptography}}
{{Multiple issues|{{More citations needed|date=January 2021}}
{{Multiple issues|{{More citations needed|date=January 2021}}
{{cite check|reference to SAS70|date=March 2014}}
{{advert|date=September 2021}}
{{confusing|date=April 2022}}}}
{{confusing|date=April 2022}}}}
In [[cryptography]], a '''key ceremony''' is a [[ceremony]] held to generate or use a [[cryptographic key]].<ref>{{Cite web |title=Cybersecurity, a step further - Secrets, vaults and key ceremonies |url=https://www.ewon.biz/all-resources/ewon-iiot-blog/cybersecurity-a-step-further-secrets-vaults-and-key-ceremonies |access-date=2022-04-18 |website=www.ewon.biz}}</ref><ref>{{Cite web |title=The Key to the Internet and Key Ceremonies — An explainer |url=https://kimdavies.com/key-ceremony-primer/ |access-date=2022-04-18 |website=kimdavies.com}}</ref>{{Better source needed|reason=The current source is insufficiently reliable ([[WP:NOTRS]]).|date=April 2022}}


In [[cryptography]], a '''key ceremony''' is a ceremony held to generate or use a [[cryptographic key]].<ref>{{Cite journal |last=Ellison |first=Carl |date=2007 |title=Ceremony Design and Analysis |url=https://eprint.iacr.org/2007/399 |journal=Cryptology ePrint Archive, Paper 2007/399 |access-date=2023-08-13 |archive-date=2022-09-01 |archive-url=https://web.archive.org/web/20220901053645/https://eprint.iacr.org/2007/399 |url-status=live }}</ref>
A public example is the signing of the [[DNS root zone]] for [[DNSSEC]].<ref>{{Cite web |title=The DNSSEC Root Signing Ceremony |url=https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ |access-date=2022-11-20 |website=Cloudflare |language=en-us}}</ref>


A public example is the signing of the [[DNS root zone]] for [[DNSSEC]].<ref>{{Cite web |title=The DNSSEC Root Signing Ceremony |url=https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ |access-date=2022-11-20 |website=Cloudflare |language=en-us |archive-date=2022-11-20 |archive-url=https://web.archive.org/web/20221120120817/https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ |url-status=live }}</ref>
==Root Key Signing Ceremony==
In [[public-key cryptography]] and [[computer security]], a '''root key ceremony''' is a procedure during which a unique pair of public and private root keys gets 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 the responsibility of the parties. A commonly recognized practice is to follow the SAS 70 standard for root key ceremonies.{{citation needed|date=August 2023}}


==Root key signing ceremony==
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. "Root key" is the 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 safeguards for the system. These digital certificates are made from a public and a [[private key]].
In [[public-key cryptography]] and [[computer security]], a '''root-key ceremony''' is a procedure for generating a unique pair of public and private root keys. Depending on the [[certificate policy]] of a system, the generation of the root keys may require notarization, legal representation, witnesses, or “key-holders” to be present. A commonly recognized practice is to follow the [[Statements on Auditing Standards (United States)|SAS 70]] standard for root key ceremonies.<ref>{{Cite report |url=https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/00/ |title=Security and Operational considerations for manufacturer generated IDevID |last=Richardson |first=Michael |last2=Pan |first2=Wei |publisher=Internet Engineering Task Force |issue=draft-richardson-secdispatch-idevid-considerations-00}} Section 2.2 para.2 (''"The SAS70 audit standard is usually used as a basis..."'')</ref>


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. This “root key” is a unique key that must be generated for secure server interaction with a protective network, often called the "root zone". Prompts for information from this zone can be made through a server. The keys and certificates serve as the credentials and safeguards for the system. These digital certificates are made from a public key and a [[private key]].{{Citation needed|date=May 2024}}
===Examples===


===Instances===
'''Example A: These passcodes are used for strong identification and non-repudiation for email and web access'''
The following examples 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.


==== Possibility A: 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 generally adequate 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 admissible. The root key is never stored on the CA server.
Unless the information that is being accessed or transmitted is valued in terms of millions of dollars, it is generally adequate 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 admissible. The root key is never stored on the CA server.


==== Possibility B: MRTD Cards and e-Passports ====
'''Example B: [[Machine Readable Travel Document]] [MRTD] ID Card or e-Passport'''
[[Machine readable travel documents|Machine Readable Travel Documents]] (MRTDs) require a much higher level of security. When conducting the root key ceremony, the government or organization will require rigorous security checks on all personnel in attendance. Those normally required to attend the key ceremony 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 technical team.

This type of environment requires a much higher level of security. When conducting the root key ceremony, the government or organization will require rigorous security checks on all personnel in attendance. Those normally required to attend the key ceremony 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 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.


===Overview===
===Overview===
The actual generation of the root key-pair typically occurs in a secure vault, with no external communication except for a single telephone line or intercom. Upon securing the vault, all present personnel must verify their identity using at least two legally recognized forms of identification. The lawyer in charge logs every person, transaction, and event in a root key ceremony log book, with each page notarized. From the moment the vault door closes until its reopening, everything is also video recorded. The lawyer and the organization's two signatories sign the recording, which is also notarized.


As part of the process, the root key is divided into up to twenty-one parts, each secured in a safe with a key and numerical lock. The keys are distributed to up to twenty-one people, and the numerical codes are distributed to another twenty-one people.{{Citation needed|date=April 2024}}
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. Each part is secured in a safe with 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.


===Providers===
===Providers===
The CA vendors and organizations, such as [[RSA (security firm)|RSA]], [[VeriSign]], and Digi-Sign, implement projects of this nature where conducting a root key ceremony would be a central component of their service.<ref>{{Cite web |last=Wessels |first=Duane |date=2023-03-01 |title=Verisign’s Role in Securing the DNS Through Key Signing Ceremonies |url=https://blog.verisign.com/security/verisign-dns-key-signing-ceremony/ |access-date=2024-04-02 |website=Verisign Blog |language=en-US}}</ref>

The CA vendors and organisations, such as [[RSA (security firm)|RSA]], [[VeriSign]] and Digi-Sign, implement projects of this nature where conducting a root key ceremony would be a central component of their service.


==IBM HSM key ceremony==
==IBM HSM key ceremony==
[[Hardware security module|Hardware security module (HSM)]] key ceremony is a procedure where the master key is generated and loaded to initialize the use of the HSM. The 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.
A [[Hardware security module|hardware security module (HSM)]] key ceremony is a procedure where the master key is generated and loaded to initialize the use of the HSM. The 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 parts. Each key part is normally owned by a different person to enhance security.


===Master key types===
===Master key types===
The master key is stored within the HSM. IBM HSMs support two types of cryptographic mechanisms:
The master key is stored within the HSM. IBM HSMs support two types of cryptographic mechanisms:


* The [[PKCS 11|PKCS#11]] mechanism, called IBM Enterprise PKCS #11 (EP11),<ref>{{Cite web|title=CEX7S / 4769 EP11|url=https://www.ibm.com/security/cryptocards/pciecc4/ep11|access-date=2020-06-24|website=www.ibm.com|language=en-us}}</ref> creates a high-security solution for application programs developed for this industry-standard API.
* The [[PKCS 11|PKCS#11]] mechanism, called IBM Enterprise PKCS #11 (EP11),<ref>{{Cite web|title=CEX7S / 4769 EP11|url=https://www.ibm.com/security/cryptocards/pciecc4/ep11|access-date=2020-06-24|website=www.ibm.com|language=en-us|archive-date=2020-02-21|archive-url=https://web.archive.org/web/20200221220809/https://www.ibm.com/security/cryptocards/pciecc4/ep11|url-status=live}}</ref> creates a high-security solution for application programs developed for this industry-standard API.
* The IBM Common Cryptographic Architecture (CCA) <ref>{{Cite web|title=CEX7S / 4769 CCA|url=https://www.ibm.com/security/cryptocards/pciecc4/cca|access-date=2020-06-24|website=www.ibm.com|language=en-us}}</ref> 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.
* The IBM Common Cryptographic Architecture (CCA)<ref>{{Cite web|title=CEX7S / 4769 CCA|url=https://www.ibm.com/security/cryptocards/pciecc4/cca|access-date=2020-06-24|website=www.ibm.com|language=en-us|archive-date=2020-02-21|archive-url=https://web.archive.org/web/20200221215307/https://www.ibm.com/security/cryptocards/pciecc4/cca|url-status=live}}</ref> 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:
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 <ref>{{Cite web|last=|first=|date=|title=Enterprise PKCS#11 (EP11) Library structure|url=http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf|url-status=live|archive-url=|archive-date=|access-date=|website=public.dhe.ibm.com}}</ref>
* EP11 HSMs<ref>{{Cite web|last=|first=|date=|title=Enterprise PKCS#11 (EP11) Library structure|url=http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf|url-status=live|archive-url=https://web.archive.org/web/20200629065353/http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf|archive-date=2020-06-29|access-date=|website=public.dhe.ibm.com}}</ref>
** EP11 symmetric master key:<ref>Master key is referred to as Wrapping Key (WK) in the [http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf EP11 documentation].</ref> used to encipher all kinds of sensitive materials including secret key objects and intermediate state information containing secret key materials.
** EP11 symmetric master key:<ref>Master key is referred to as Wrapping Key (WK) in the [http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf EP11 documentation] {{Webarchive|url=https://web.archive.org/web/20200629065353/http://public.dhe.ibm.com/security/cryptocards/pciecc4/EP11/docs/ep11-structure.pdf |date=2020-06-29 }}.</ref> used to encipher all kinds of sensitive materials, including secret key objects and intermediate state information containing secret key materials.
* CCA HSMs <ref>{{Cite book|date=2016-09-30|title=Getting Started with Linux on Z Encryption for Data At-Rest|url=http://www.redbooks.ibm.com/abstracts/sg248436.html?Open|access-date=2020-06-24|website=redbooks.ibm.com|language=en-US}}</ref>
* CCA HSMs<ref>{{Cite book|date=2016-09-30|title=Getting Started with Linux on Z Encryption for Data At-Rest|url=http://www.redbooks.ibm.com/abstracts/sg248436.html?Open|access-date=2020-06-24 |language=en-US|archive-date=2020-10-15|archive-url=https://web.archive.org/web/20201015011820/http://www.redbooks.ibm.com/abstracts/sg248436.html?Open|url-status=live}}</ref>
** SYM master key: used to encipher [[Data Encryption Standard|DES]] symmetric key objects
** SYM master key: used to encipher [[Data Encryption Standard|DES]] symmetric key objects
** ASYM master key: used to encipher [[Public-key cryptography|PKA]]-[[RSA (cryptosystem)|RSA]] asymmetric key objects
** ASYM master key: used to encipher [[Public-key cryptography|PKA]]-[[RSA (cryptosystem)|RSA]] asymmetric key objects
Line 55: Line 50:
===HSM key ceremony types===
===HSM key ceremony types===


==== On-premise HSM Key Ceremony ====
====On-premise HSM Key Ceremony====
For [[IBM Z]] and [[Linux on IBM Z|Linux One]] Systems, the HSMs are used to perform cryptographic operations. The HSM has 85 domains, with each having its own set of master keys.<ref>{{Cite book|date=2016-09-30|title=Streamline Management of the IBM z Systems Host Cryptographic Module Using IBM Trusted Key Entry|url=http://www.redbooks.ibm.com/abstracts/redp5305.html?Open|access-date=2020-06-24 |language=en-US|archive-date=2020-06-26|archive-url=https://web.archive.org/web/20200626192617/http://www.redbooks.ibm.com/abstracts/redp5305.html?Open|url-status=live}}</ref> 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 card]]s and 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.

For [[IBM Z]] and [[Linux on IBM Z|LinuxONE]] Systems, the HSMs are used to perform cryptographic operations. The HSM has 85 domains, with each having its own set of master keys.<ref>{{Cite book|date=2016-09-30|title=Streamline Management of the IBM z Systems Host Cryptographic Module Using IBM Trusted Key Entry|url=http://www.redbooks.ibm.com/abstracts/redp5305.html?Open|access-date=2020-06-24|website=redbooks.ibm.com|language=en-US}}</ref> 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 card]]s and 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 Ceremony ====


====Cloud HSM Key Ceremony====
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 presently the only [[key management]] service and cloud HSM in the cloud to provide HSM key ceremony through both CLI and smart cards. <ref>{{Cite web|title=IBM Hyper Protect Services - Overview|url=https://www.ibm.com/cloud/hyper-protect-crypto|access-date=2020-06-24|website=www.ibm.com|language=en-us}}</ref>
EP11 HSM is currently the only type of HSM that supports Key Ceremony in the cloud. Both the cloud [[command-line interface]] (CLI) and smart cards are provided to load the master key parts to the cloud HSM. IBM Cloud Hyper Protect Crypto Services is presently the only [[key management]] service and cloud HSM in the cloud to provide HSM key ceremony through both CLI and smart cards.<ref>{{Cite web|title=IBM Hyper Protect Services - Overview|url=https://www.ibm.com/cloud/hyper-protect-crypto|access-date=2020-06-24|website=www.ibm.com|language=en-us|archive-date=2020-06-09|archive-url=https://web.archive.org/web/20200609163622/https://www.ibm.com/cloud/hyper-protect-crypto|url-status=live}}</ref>


===Master key part storage===
===Master key part storage===
Line 68: Line 61:
Smart cards are protected by a [[Personal identification number|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.
Smart cards are protected by a [[Personal identification number|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 encrypted with keys 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.<ref>{{Cite web|last=|first=|date=|title=IBM Cloud Hyper Protect Crypto Services FAQs|url=https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operations#faq-how-to-initialize|url-status=live|archive-url=|archive-date=|access-date=|website=cloud.ibm.com}}</ref>
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 encrypted with keys 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.<ref>{{Cite web|last=|first=|date=|title=IBM Cloud Hyper Protect Crypto Services FAQs|url=https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operations#faq-how-to-initialize|url-status=live|archive-url=https://web.archive.org/web/20230406012206/https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-faq-provisioning-operations#faq-how-to-initialize|archive-date=2023-04-06|access-date=|website=cloud.ibm.com}}</ref>


== In blockchain technology ==
==In blockchain technology==
{{Expand section|date=April 2022}}
{{Expand section|date=April 2022}}
A key ceremony can be used to generate the [[private key]] for a [[cryptocurrency wallet]].<ref>{{Cite web |date=February 2022 |title=EURL: A reliable euro-pegged digital asset |url=https://uploads-ssl.webflow.com/619256062c09aa2073086270/6231a74ee83fb309ff7040ba_Whitepaper%20-%20Lugh.pdf |url-status=live |archive-url=https://web.archive.org/web/20220316093151/https://uploads-ssl.webflow.com/619256062c09aa2073086270/6231a74ee83fb309ff7040ba_Whitepaper%20-%20Lugh.pdf |archive-date=16 March 2022 |access-date=18 April 2022 |website=uploads-ssl.webflow.com }}</ref>{{Better source needed|reason=The current source is insufficiently reliable ([[WP:NOTRS]]).|date=April 2022}}For Multiparty Computation(MPC), key ceremonies are used to split parts of keys to participants in a secure way. It is also use in Zero-Knowledge Proofs (zKP) protocols for key generation.
A key ceremony can be used to generate the [[private key]] for a [[cryptocurrency wallet]].<ref>{{Cite web |date=February 2022 |title=EURL: A reliable euro-pegged digital asset |url=https://uploads-ssl.webflow.com/619256062c09aa2073086270/6231a74ee83fb309ff7040ba_Whitepaper%20-%20Lugh.pdf |url-status=live |archive-url=https://web.archive.org/web/20220316093151/https://uploads-ssl.webflow.com/619256062c09aa2073086270/6231a74ee83fb309ff7040ba_Whitepaper%20-%20Lugh.pdf |archive-date=16 March 2022 |access-date=18 April 2022 |website=uploads-ssl.webflow.com }}</ref><ref>{{Cite web |title=Key Ceremony Guidelines |url=https://d1c2gz5q23tkk0.cloudfront.net/assets/uploads/2956620/asset/CVA_Trusted_Key_Ceremony_Guidelines.pdf |access-date=14 December 2023 }}</ref> For Multiparty Computation (MPC), key ceremonies are used to split parts of keys to participants securely. It is also used in Zero-Knowledge Proofs (zKP) protocols for key generation.


==See also==
==See also==
Line 78: Line 71:
* [[Public-key cryptography]]
* [[Public-key cryptography]]


== References ==
==References==
{{reflist}}
{{reflist}}


==External links==
==External links==
* [https://www.iana.org/dnssec/ceremonies/22 Summary of events at DNSSEC KSK Ceremony 22], which took place 13 August 2015 at the [[ICANN]] Key Management Facility, El Segundo, CA, USA
* [https://www.iana.org/dnssec/ceremonies/22 Summary of events at DNSSEC KSK Ceremony 22], which took place 13 August 13, 2015, at the [[ICANN]] Key Management Facility, El Segundo, CA, USA
* [https://www.ibm.com/security/cryptocards IBM Crypto Cards]
* [https://www.ibm.com/security/cryptocards IBM Crypto Cards]
* [https://www.ibm.com/security/cryptocards/pciecc3/overview IBM 4768 Crypto Card overview]
* [https://www.ibm.com/security/cryptocards/pciecc3/overview IBM 4768 Crypto Card overview]

Latest revision as of 18:36, 19 December 2024

In cryptography, a key ceremony is a ceremony held to generate or use a cryptographic key.[1]

A public example is the signing of the DNS root zone for DNSSEC.[2]

Root key signing ceremony

[edit]

In public-key cryptography and computer security, a root-key ceremony is a procedure for generating a unique pair of public and private root keys. Depending on the certificate policy of a system, the generation of the root keys may require notarization, legal representation, witnesses, or “key-holders” to be present. A commonly recognized practice is to follow the SAS 70 standard for root key ceremonies.[3]

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. This “root key” is a unique key that must be generated for secure server interaction with a protective network, often called the "root zone". Prompts for information from this zone can be made through a server. The keys and certificates serve as the credentials and safeguards for the system. These digital certificates are made from a public key and a private key.[citation needed]

Instances

[edit]

The following examples 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.

Possibility A: Identification and non-repudiation for email and web access

[edit]

Unless the information that is being accessed or transmitted is valued in terms of millions of dollars, it is generally adequate 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 admissible. The root key is never stored on the CA server.

Possibility B: MRTD Cards and e-Passports

[edit]

Machine Readable Travel Documents (MRTDs) require a much higher level of security. When conducting the root key ceremony, the government or organization will require rigorous security checks on all personnel in attendance. Those normally required to attend the key ceremony 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 technical team.

Overview

[edit]

The actual generation of the root key-pair typically occurs in a secure vault, with no external communication except for a single telephone line or intercom. Upon securing the vault, all present personnel must verify their identity using at least two legally recognized forms of identification. The lawyer in charge logs every person, transaction, and event in a root key ceremony log book, with each page notarized. From the moment the vault door closes until its reopening, everything is also video recorded. The lawyer and the organization's two signatories sign the recording, which is also notarized.

As part of the process, the root key is divided into up to twenty-one parts, each secured in a safe with a key and numerical lock. The keys are distributed to up to twenty-one people, and the numerical codes are distributed to another twenty-one people.[citation needed]

Providers

[edit]

The CA vendors and organizations, such as RSA, VeriSign, and Digi-Sign, implement projects of this nature where conducting a root key ceremony would be a central component of their service.[4]

IBM HSM key ceremony

[edit]

A hardware security module (HSM) key ceremony is a procedure where the master key is generated and loaded to initialize the use of the HSM. The 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 parts. Each key part is normally owned by a different person to enhance security.

Master key types

[edit]

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),[5] creates a high-security solution for application programs developed for this industry-standard API.
  • The IBM Common Cryptographic Architecture (CCA)[6] 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[7]
    • EP11 symmetric master key:[8] used to encipher all kinds of sensitive materials, including secret key objects and intermediate state information containing secret key materials.
  • CCA HSMs[9]
    • SYM master key: used to encipher DES symmetric key objects
    • ASYM master key: used to encipher PKA-RSA asymmetric key objects
    • AES master key: used to encipher AES, HMAC symmetric key objects
    • APKA master key: used to encipher PKA-ECC asymmetric key objects

HSM key ceremony types

[edit]

On-premise HSM Key Ceremony

[edit]

For IBM Z and Linux One Systems, the HSMs are used to perform cryptographic operations. The HSM has 85 domains, with each having its own set of master keys.[10] 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 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 Ceremony

[edit]

EP11 HSM is currently the only type of HSM that supports Key Ceremony in the cloud. Both the cloud command-line interface (CLI) and smart cards are provided to load the master key parts to the cloud HSM. IBM Cloud Hyper Protect Crypto Services is presently the only key management service and cloud HSM in the cloud to provide HSM key ceremony through both CLI and smart cards.[11]

Master key part storage

[edit]

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 encrypted with keys 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.[12]

In blockchain technology

[edit]

A key ceremony can be used to generate the private key for a cryptocurrency wallet.[13][14] For Multiparty Computation (MPC), key ceremonies are used to split parts of keys to participants securely. It is also used in Zero-Knowledge Proofs (zKP) protocols for key generation.

See also

[edit]

References

[edit]
  1. ^ Ellison, Carl (2007). "Ceremony Design and Analysis". Cryptology ePrint Archive, Paper 2007/399. Archived from the original on 2022-09-01. Retrieved 2023-08-13.
  2. ^ "The DNSSEC Root Signing Ceremony". Cloudflare. Archived from the original on 2022-11-20. Retrieved 2022-11-20.
  3. ^ Richardson, Michael; Pan, Wei. Security and Operational considerations for manufacturer generated IDevID (Report). Internet Engineering Task Force. Section 2.2 para.2 ("The SAS70 audit standard is usually used as a basis...")
  4. ^ Wessels, Duane (2023-03-01). "Verisign's Role in Securing the DNS Through Key Signing Ceremonies". Verisign Blog. Retrieved 2024-04-02.
  5. ^ "CEX7S / 4769 EP11". www.ibm.com. Archived from the original on 2020-02-21. Retrieved 2020-06-24.
  6. ^ "CEX7S / 4769 CCA". www.ibm.com. Archived from the original on 2020-02-21. Retrieved 2020-06-24.
  7. ^ "Enterprise PKCS#11 (EP11) Library structure" (PDF). public.dhe.ibm.com. Archived (PDF) from the original on 2020-06-29.
  8. ^ Master key is referred to as Wrapping Key (WK) in the EP11 documentation Archived 2020-06-29 at the Wayback Machine.
  9. ^ Getting Started with Linux on Z Encryption for Data At-Rest. 2016-09-30. Archived from the original on 2020-10-15. Retrieved 2020-06-24.
  10. ^ Streamline Management of the IBM z Systems Host Cryptographic Module Using IBM Trusted Key Entry. 2016-09-30. Archived from the original on 2020-06-26. Retrieved 2020-06-24.
  11. ^ "IBM Hyper Protect Services - Overview". www.ibm.com. Archived from the original on 2020-06-09. Retrieved 2020-06-24.
  12. ^ "IBM Cloud Hyper Protect Crypto Services FAQs". cloud.ibm.com. Archived from the original on 2023-04-06.
  13. ^ "EURL: A reliable euro-pegged digital asset" (PDF). uploads-ssl.webflow.com. February 2022. Archived (PDF) from the original on 16 March 2022. Retrieved 18 April 2022.
  14. ^ "Key Ceremony Guidelines" (PDF). Retrieved 14 December 2023.
[edit]