[1] For compliance reasons, certain CA systems must conduct a Key Ceremony before issuing any Digital Certificates. Trust Centres and Government projects are two examples where a key ceremony may be required in order to comply with local laws or international standards.
The entire Key Ceremony and is described in this manual. There are typically three phases of the Key Generation Ceremony and these are sub divided and described in the following sub sections:
[2] The Root CA, that is at the top of the hierarchy of the CA environment, as well as Subordinate CAs residing on a lower level of the CA hierarchy, are created using the Key Ceremony. The Key Ceremony is conducted and supervised by the Key Ceremony Administrator with an optional support of Key Generation Ceremony Administrator and the procedure is carried out with the following primary responsibilities:
To meet these responsibilities, the Key Ceremony Administrator is involved in every phase of the CA life cycle. The six phases of the CA life cycle are described in the following sub sections:
2.Definition
3.Preparation
4.Creation
5.Activation
6.Maintenance
7.Recertification
[2] During this phase of the Key Generation Ceremony, a new Key Access Component Card Set, commonly referred to as Operator Card Set, can be created and bound to a cryptographic device’s security infrastructure.
Depending on the organization preference and/or regulatory requirements, all of the generated keys (or alternatively only a specified subset of generated keys, subject to the type of CA that they will be assigned too) may require protection from unauthorized access and may also require encryption using an encryption key that is divided into a specified number of components. These are referred too as Secret Components and once created they are stored on Key Access Component Cards.
If you choose to protect any keys with a set of Key Access Component Cards, you will need to create the new Key Access Component Card Set using the features provided by your cryptographic device vendor (e.g. HSM or other device). This will usually require you to define the card set configuration, such as the total number of cards in a card set and a minimum number of cards required to access the key (if you enable this option), to recover any lost card of the card set (if you enable this option), to recover lost PIN codes, that protect access to each card (if you enable this option) and finally - to recover a private key itself (if you enable this option).
Before a card set can be created, a sufficient number of Card Holders, that is individual persons holding the Key Access Component Holder responsibilities, should be appointed and attend the ceremony. Choose your Card Holders carefully and wisely and ensure they meet Trusted Employee requirements and other personnel related policies within you or your customer’s organization.
Each Card Holder, will need to be supplied with a special smart card, provided by the cryptographic device vendor. During the process of creation of a new Key Access Component Card Set, each Card Holder will be requested to insert the card into the smart card reader interface connected directly to the cryptographic device and enter and confirm a new PIN code they wish to protect their cards with. They must memorize their PIN codes and also store these securely in a well protected place such as safe. Before the process is completed, the Key Ceremony Administrator will also need to enter a Name for the newly generated card set in order to be able to identify it when the particular card set is needed in future use.
Upon successful creation of the new Key Access Component Card Set, the event should be documented in the Key Ceremony Notes Document, that should clearly display the Name assigned to the new Key Access Component Card Set, full name of each Card Holder, their personal details allowing the company, for which the keys are generated for, to easily contact each Card Holder when needed, and finally - the serial numbers of the smart cards they hold. The Key Ceremony Administrator should also ensure, that each Card Holder signs a dedicated Key Access Component Holder Document (a separate document for each Card Holder), which lists all of the Cart Holder responsibilities, their personal details and the Serial Number of the Key Access Component Card they hold.
[2] During this phase of the Key Generation Ceremony, the necessary number of key pairs is generated, subject to the number of CAs that will be created during the Key Ceremony. All private keys are securely generated and saved in an encrypted format on a cryptographic device, most often a hardware device such as Hardware Cryptographic Module commonly referred to as HSM. Public key request files are also saved into a hard disk drive, CD disc, USB flash drive or a diskette.
At this stage, the key pairs are given a Common Name and as an option, a unique key identifier file is named and saved into a hard disk, USB flash drive or a diskette. These values identify the key and will allow the Key Ceremony Administrator to properly setup the cryptographic tools to access the key at a later stage of the Key Ceremony and in future frequent use if necessary.
In order to generate a key pair on a cryptographic device, a command prompt based
cryptographic device support software in combination with Digi-CA™ Cryptographic Toolkit can be used. Subject to your or your customer preference, or regulatory requirements as well as supported algorithms by the Digi-CA™ PKI System and the cryptographic device in use, the Key Generation Administrator needs to ensure, that he has correctly defined the following values describing the type and the size of each private and public key pair:
b. Key Size provided as an integer number of bits [i.e. 2048]
Ensure, that these values are known to the Key Generation Administrator in advance and that your own or your customer’s company understands their meaning, usage limitations and security risks in respect to the current cryptographic security norms and standards [3] for commercial use.
If you intend to protect a particular key with a set of Key Access Component Cards, ensure all Key Access Component Holders are present at the ceremony, have their cards ready for use and confirm that they remember or have access to the PIN codes necessary to read data on the cards. If an Key Access Component Card Set key protection feature is enabled during this phase, configured number of Card Holders will be requested to insert the card into the smart card reader interface connected directly to the cryptographic device and enter the PIN code they used to protect their cards with. Once the last required card is loaded, the cryptographic device will automatically generate the requested key data based on the specified key type algorithm and bit size and output relevant data such as certificate request containing the associated public key and as an option, a unique key identifier file to an appointed location on a hard drive disk, CD disc, USB Flash Drive or a diskette.
At the end of the key generation process, you need to ensure, that the event is documented in the Key Ceremony Notes Document and, that it clearly displays that keys are not only correctly associated with a specific company, for which the key or keys are generated for but also correctly associated with the CA, for which these were generated for. For example, ACME Certification Authority could be assigned to 2048 bit RSA PrivateKey1, etc.
After the Key Ceremony, the CA Operator uses the .x509 certificate file, generated during the ceremony, to map the private key stored on the cryptographic device to the new CA infrastructure.
The above process for generating keys can be completed using a cryptographic device working in a production environment and it does not disrupt the operations of other CAs maintained in your Digi-CA™ PKI System environment. This also enables the CA Operator to bring new CAs online easily, without taking existing CAs offline.
Using Key Generation Ceremony, a new key pair is generated whenever a new Root or Subordinate CA is created. Typically, firstly a Root CA is created and used to sign any new Level 1 Subordinate CA in the CA hierarchy and so on.
[2] During the definition phase of the CA, the Key Ceremony Administrator coordinates and supervises work to define the CA, how to name it, how to use it, what type of hierarchy to choose, and other attributes and requirements of the CA and associated PKI [4] environment. This can be done by using the Preset Certificate Specification Template provided in Appendix II.
There are several other items that must be considered when defining the Key Ceremony and these are explained in the following sub sections:
2. Key Map
3. Key Access Component Holders
4. Key Ceremony Script
5. Video Recording
6. Archive Collateral
[2] The naming document must be completed for all new CAs. Information provided in the naming document precisely describes the CA you are creating for your own organization or for your customer. Because this document is a critical tool in the creation of the CA, it is imperative that the parameters identified in the naming document are carefully defined. The Digi-Sign’s Digi-CAST2™ Consulting Team can support the Key Ceremony Administrator and work with the customer to correctly set these parameters.
Important Note: The Key Ceremony Administrator is responsible for generating the Naming Document and ensuring that its is signed by appropriate representatives or by the customer, to whom the CA is generated for.
The naming document is a critical tool used to prepare for a Key Ceremony. With the naming document in hand, the ceremony is scheduled, the Key Ceremony Script is written and the ceremony attendees are decided upon. The naming document consists of four sections and space for the customer signature (see Appendix II: Preset Certificate Specification template). The information in each section differs, depending on the CA type and unique customer specifications. The typical two types of CAs you create in key ceremonies are:
Elements of the naming document are different for each of these CAs. These differences are summarized in the following table:
[2] The four sections of the Naming Document are explained in the following sub sections:
Section II- Operational Period
Section III - Distinguished Name
Section IV - Certificate Format & Extensions
[2] The second part of this section lists the Distinguished Name of the New Issuing Authority. The New Issuing Authority is the new CA that you create. There are several common attributes that may be required or optional subject to your preferred choice and regulatory requirements:
[2] To track the assignment of pre-generated Keys, a Key Map is maintained and updated before and after every Key Ceremony you conduct (see Appendix III for a sample Key Map template). This file contains the following information that is explained in the sub sections below:
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the date of the Key Ceremony and precise UTC time of assignment is entered in this field.
This field identifies the cryptographic device and the pre-generated (or generated at the beginning of this ceremony) private key residing within your cryptographic device. The device is usually identified by a unique device serial number that the device vendor has assigned to it. If provided by the vendor of your device, you may also enter the integrity key identifier value, that provides an increased level of device identity assurance. As next items in this section, you enter the Common Name and optionally a unique key identifier file name and the checksum byte string of the identifier file for your pre-generated key stored within the cryptographic device. As a last item in this section and if the additional Key Access Component Card based protection was enabled for the generated key, you enter the Name of the Key Access Component Card Set, which was used to protect access to the key. When the key pair is assigned to a new CA, these values will be cross-checked by the appointed Key Ceremony Attendees, to ensure they match the real values, that the Key Ceremony Administrator is using during the ceremony key related activities.
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the Distinguished Name [DN] of the new CA is entered in this field of the spreadsheet.
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the DN of the Issuing CA is entered in this field of the spreadsheet.
This is the name of the file containing the public key and the certification [3] request generated during the Key Ceremony. The request file assigns the CA to a pre-generated key.
This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a certificate for the new CA is created and once this is done the name of the certificate file is entered in this field of the spreadsheet.
This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a validity period will be assigned to the new CA and is entered here once completed.
[2] To track the assignment of pre-generated Keys, a Key Map is maintained and updated before and after every Key Ceremony you conduct (see Appendix III for a sample Key Map template). This file contains the following information that is explained in the sub sections below:
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the date of the Key Ceremony and precise UTC time of assignment is entered in this field.
This field identifies the cryptographic device and the pre-generated (or generated at the beginning of this ceremony) private key residing within your cryptographic device. The device is usually identified by a unique device serial number that the device vendor has assigned to it. If provided by the vendor of your device, you may also enter the integrity key identifier value, that provides an increased level of device identity assurance. As next items in this section, you enter the Common Name and optionally a unique key identifier file name and the checksum byte string of the identifier file for your pre-generated key stored within the cryptographic device. As a last item in this section and if the additional Key Access Component Card based protection was enabled for the generated key, you enter the Name of the Key Access Component Card Set, which was used to protect access to the key. When the key pair is assigned to a new CA, these values will be cross-checked by the appointed Key Ceremony Attendees, to ensure they match the real values, that the Key Ceremony Administrator is using during the ceremony key related activities.
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the Distinguished Name [DN] of the new CA is entered in this field of the spreadsheet.
This field remains blank until the pre-generated key pair is assigned to a new CA. Once the key pair is assigned, the DN of the Issuing CA is entered in this field of the spreadsheet.
This is the name of the file containing the public key and the certification [3] request generated during the Key Ceremony. The request file assigns the CA to a pre-generated key.
This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a certificate for the new CA is created and once this is done the name of the certificate file is entered in this field of the spreadsheet.
This field remains blank until the pre-generated key pair is assigned to a new CA. During the Key Ceremony a validity period will be assigned to the new CA and is entered here once completed.
[2] A CA’s private key is a valuable item because its possessor may activate the CA at any time. To protect against any misuse, Key Access Component Card Sets are created and are required to access the private key.
These Card Sets are formed with a defined number of Key Access Component Cards, that are protected with PIN numbers and store encryption key elements [components] necessary to decrypt the private key and gain access to it in order to bring it into online state inside the cryptographic device. Individuals, that posses the Key Access Component Cards used to protect particular keys are called Key Access Component Holders and the organization that owns the CA must track and record accurate information about Key Access Component Cards and Key Access Component Holders so that a complete list maintained at all times.
[2] The Key Ceremony Administrator ensures that every Key Ceremony and every ceremony related activity is secure and auditable. This means that there must be an unbroken evidentially path demonstrating that your Certificate system is operated in accordance with the methods and procedures described in your organization’s Certificate Practice Statement [5]. In addition to the witnessed script, video record of key ceremonies and logging protocols provide further documentation of the CA creation process. Each of these is explained in the following sub sections:
An Archive Folder must be compiled for every Key Ceremony. The folder should include the Naming Document, the witnessed Key Ceremony Script, the Key Access Component Holder Documents, the Attestation Letters and the Key Map. After the ceremony, the Archive Folder is stored in the secure storage area. This Folder and the video recording provide the primary record of all key ceremonies performed by the organization.
The Archive Folder documents the Key Ceremony and provides evidence of the secure manner in which the CA was created. The Archive Folder is divided into three parts as described in the following sub sections:
2.Key Map
3.Key Access Component Holder Documents
4.Attestation Letter
[2] Once everything is defined and understood the preparation for the Key Ceremony can be considered. This involves preparing the people that will attend, the keys that will be generated and the documentation that is required. These are explained in the following sub sections:
3.11.2.2 Notary Public or Equivalent
In preparing for the Key Ceremony, personnel from your Customer’s organization must attend. It is essential to remember at all times that Digi-CA™ is a security product. Throughout the entire Key Ceremony and beyond, every action must occur in a manner that conveys that care has been taken to ensure the highest possible level of security.
A notary public is an official, public witness whose job it is to identify people who are about to sign a document and to witness that signing. A properly credentialed notary public or some person who is authorized by local law to serve as an official, public witness, observes the witness(es) signing the Attestation Letter and then certifies the witnesses’ signatures.
Once everything necessary to define and prepare for the new CA is completed, the CA is created in a Key Ceremony. This is a set of formal and highly secure procedures that creates a CA. The Root CA should be stored securely and remain in offline state, while Subordinate CAs can be put online for frequent use. There are a number of actions, that should occur on the day of the Key Ceremony and they are explained in the following sub sections:
2.Pre-Check
3.Briefing
4.Ceremony
5.CA Creation
6.Conclusion
7.Post-Check
[2] Key Access Component Retrieval is only required if you are using existing Key Access Components from a previous Key Ceremony and this is decided when the Ceremony Script is being written. Existing Key Access Components are needed each time a CA is being created from a previously generated key, if the key was access protected. The Key Access Component Holders must then be present so that the Key Ceremony Administrator and the Key Access Component Holders can enter the safe room together and retrieve the required smart cards containing Key Access Components (key elements necessary to decrypt the private key and bring it online). The Key Access Component Holders will provide their smart cards as required during the Key Ceremony.
A final check of the Key Ceremony room should be undertaken prior to the arrival of the attending personnel. This could include assisting with the recording equipment, arranging seating and other activities but should always include a check, that the following items are present, will function properly and are usable:
Before the ceremony, the Key Ceremony Administrator, or a Digi-Sign Digi-CAST2™ consultant, meets with the attendees and explains what a Key Ceremony is and what will be occurring during the ceremony. The briefing will include:
The actual Key Ceremony has several vital components that must be understood by everyone that attends the ceremony. There are four parts to the ceremony and the following sub sections explain the components:
[2] On the day of the ceremony, many people become involved in making the ceremony a success. The following identifies the tasks performed on the ceremony day, the time frame, the responsible party, and other participants involved in each task. The following table shows the responsibilities on the day of the Key Ceremony:
Time Frame Task Responsible Party Other Participants
30 minutes-1 hour before ceremony begins Key Access Component retrieval, Video camera setup Key Ceremony Administrator Key Access Component Holders, access personnel, Videographers
15 minutes before ceremony Final check of the ceremony room Key Ceremony Administrator
15 minutes before ceremony Customer briefing Digi-CAST2™ Consultant or Key Ceremony Administrator Customer
Start of ceremony Ceremony introduction Key Ceremony Administrator Key Ceremony Administrator, Key Access Component Holders, and other ceremony participants
During ceremony Create the customer’s CA(s) Key Ceremony Administrator Key Access Component Holders, witnesses, and customer (optional)
End of ceremony Ensure that all ceremony material is properly distributed Key Ceremony Administrator Key Access Component Holders and access personnel
Immediately after ceremony ends Ensure that the archive book and appropriate key management files are updated and stored Key Ceremony Administrator Access personnel Notary Public
After entering the room, follow these steps:
Upon successful completion of the final check, the ceremony room is ready for the ceremony participants. Next, make sure all the participants are present and in their proper location. The participants should be arranged as follows:
[2] The Key Ceremony is a formal procedure in which the CA is created. The security of the procedure must be auditable and evidentially. The ceremony script is the most important tool to ensure compliance [3] with established security procedures. When each ceremony step is documented, witnessed and attested to, you have created your organization’s strongest proof against claims of non-compliance or security compromise. For this reason, the script must be followed exactly as it is written.
During the Key Ceremony, the script will be read aloud for each step. Reading the script aloud helps the ceremony participants follow along, but more importantly, it provides a verbal narrative to accompany the video recording of the event. As each step is completed, the section of the script for that step is initialed by the witnesses.
Important Note: Situations that cause temporarily digression from the script may arise. Any such digression must be thoroughly documented, so that these situations do not compromise the security of the process.
To properly document digressions, notations are made in the script that describe the problem, when it occurred, and what was done to fix the problem. The script is initialed by everyone in attendance.
If the ceremony is particularly long, the participants can take a break from the proceedings. If this occurs, the script has a notation added indicating the time of the break. Another notation indicating the time the proceedings resumed is also made in the script. During the entire break, two trusted employees must remain in the room. The videographers continue recording throughout the break.
Following the ceremony introduction, the scripted steps to create the CA begin. The script is followed exactly so that the witnesses can initial each and every step as it is performed. The following sub sections describe the ceremony activities that will be in the script:
2.Generating Event
3.Signing Event
4.Distribution Event
[2] The initializing event must be built into the script when creating a Root CA or when conducting a Key Generation Ceremony. In the Initializing Event, the Key Access Component Card Set is created (Key Access Component Cards). The Initializing Event provides critical security to protect the private key assigned to the new CA. This event is of paramount importance during the ceremony, and these procedures must be adequately documented in the script.
[2] The Key Ceremony script then lists the steps that will be performed at the conclusion of the ceremony. Before anyone leaves the room all copies of the signed Key Ceremony Script, the Key Access Component Holder Documents, the Attestation Letters and the Video Recordings must be placed in the Archive Folder and sealed.
At this point, the CA is created but it is not yet activated. This is the next event that occurs after the Key Ceremony and is the CA Activation event.
Text needed here
[2] The first component in ensuring a properly configured CA is the naming document. Its formal title is the New Issuing Authority Naming Application. This document contains the information necessary to properly configure a CA:
After the Digi-CAST2™ Consultant and the customer have defined the Customer’s CA, the
Digi-CAST2™ Consultant will give you a copy of the completed naming document that has
been signed by both the Digi-CAST2™ Consultant and the Customer. You will use the information in the naming document to create the CA. Detailed information about the naming document is available in Chapter 4, "Key Ceremony Preparation".
[2] We have a requirement, that the generation of new RSA keys and creation of new Certification Authorities (CAs) must be witnessed by a third party auditor and appointed witnesses. We must therefore generate fresh keys which have been witnessed in the prescribed manner and use these keys to create new Certification Authorities (CAs).
The keys we generate today will be new keys, having no existing keys residing on the HSM device we are about to use during this ceremony. There are therefore no existing keys residing in the HSM device should this note be relevant to any party participating in this ceremony.
It is important to note, that the Key Generation and Certificate Signing operations occur entirely within the HSM device which uses a FIPS 140 approved pseudo random-number generator, which is seeded periodically from a random bit-value accumulator fed with an unpredictable input from an electronic noise source.
The prime number generator used in RSA key pair generation is entirely within the HSM and is covered by FIPS 140.
The software and the procedures were tested to ensure, that the keys were valid, and that the import and export procedures were working as required.
The source code was examined to ensure that its operation was correct.
[2]
Issue |
|
Subject Dn |
Issue Dn |
.req |
.509 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[2] An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].
2. The computer has a hard disk which has been pre-prepared with a fresh installation of a [Red Hat Enterprise Linux, version 5.0] operating system, the requisite HSM driver, nToken authentication PCI device, HSM device Support Software and the
Digi-CA™ PKI System, both acting as the Cryptographic Operation Control Software. The software was tested for correct operation prior to the Key Ceremony by using an HSM reserved for backup purposes.
3. The Key Access Component Cards are going to be distributed to appointed Key Access Component Holders during a later event of this ceremony. It is however important to note, that Key Access Component Holders are the only holders possessing PIN codes necessary to access the data stored on these smart cards. Before this step can be completed, each appointed Key Access Component Holder must now write down their new PIN code on a dedicated PIN paper sheet and put the PIN paper sheet with the written PIN code into an envelope, indicating their full personal name. Each envelope is to be placed on the Inventory Table and remain not sealed for the duration of the entire Key Ceremony. All attending Witnesses must ensure, that Key Access Component Holders are inserting their PIN Code paper sheets into correct envelopes, that indicate their full personal name.
Key Ceremony Administrator should now place a sufficient number of empty Key Access Component Cards on top of the envelopes containing PIN Code paper sheets. It is important to note, that the video camera should constantly record all activities related to access to the Key Access Component Cards and envelopes containing PIN Code paper sheets.
The Key Ceremony Administrator is now going to note the new Name for the newly configured Key Access Component Card Set, the Serial Number of each Key Access Component Card, that is about to be used and the details of each Key Access Component Holder (below) in this script. All attending Key Ceremony Witnesses must ensure, that the date entered into the script, the full personal name of each Key Access Component Holder and the Serial Number of the Key Access Component Card they are about to use is correct. They also must place their signature where indicated (below) in this section of the script.
Key Access Component Card Set
Name: …………………………………………………………………………………………………………………
Key Access Component Holder #1
Full Name: …………………………………………………………………………………………………………………
Card Serial Number: ……………………………………………………………………………………………
Key Access Component Holder #2
Full Name: …………………………………………………………………………………………………………………
Card Serial Number: ……………………………………………………………………………………………
Key Access Component Holder #3
Full Name: …………………………………………………………………………………………………………………
Card Serial Number: ……………………………………………………………………………………………
Key Access Component Holder #4
Full Name: …………………………………………………………………………………………………………………
Card Serial Number: ……………………………………………………………………………………………
Key Access Component Holder #5
Full Name: …………………………………………………………………………………………………………………
Card Serial Number: ……………………………………………………………………………………………
[2] The first HSM device (designated #1) was removed from production and connected to the computer prior to this ceremony and the event was monitored and supervised by an appointed company’s Head of Security.The Cryptographic Operation Control Software is now about to be used to cause the numbered (in section 3 above) operations to occur in the following sequence: 5.
During this phase of the Key Generation Ceremony, a new Key Access Component Card Set is created and bound to our HSM device security infrastructure. The card set configuration we choose is as follows:
b. Minimum number of smart cards required to access the private key: 3
c. Minimum number of smart cards required to recreate any lost smart card: 3
d. Minimum number of smart cards required to recover lost PIN codes: 3
e. Minimum number of smart cards required to recover a private key: 3
During this step, one of the HSM Security Administrators present at the ceremony will be requested by the Key Generation Ceremony Administrator to insert his Administrator’s Smart Card into the smart card reader interface of the HSM device in order to authorize the creation of a new Key Access Component Card Set. This is required by the HSM device, which operates in FIPS 140-2 level 3 modes.
Further during step, each appointed (in previous step) Key Access Component Holder will be requested to actively participate in the ceremony. The Key Generation Ceremony Administrator will require each Key Access Component Holder to separately follow the steps below:
a. Access their PIN envelope, that were previously placed on the Inventory Table
b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet
c. Confirm to memorize their PIN code
d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table
e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device
f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter and confirm their memorized PIN Code.
g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.
The above sequence of steps will be repeated for each appointed new Key Access Component Holder.
All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step.
The new card set will be subsequently used during this ceremony to encrypt and protect access to relevant private keys we are about to generate. The encryption key elements [components] are now stored on each PIN protected Key Access Component Card, which will be required to access newly generated and access protected private keys at any time.
[2] During the Key Access Component Card Set Configuration, at least two people from the Key Ceremony Attendees list of personnel were present at all times. No other personnel were permitted access to the room. The Cryptographic Operation Control Software required a PIN code to be entered before the software could communicate with any smart card (holding encryption key component [Key Access Component Card]) used during the Key Access Component Card Set configuration.
[2] The previous step left the HSM device #1 configured for use with our newly generated keys. The encryption key elements [components] are stored on several PIN protected smart cards, herein referred to as "Key Access Component Cards", which are required to access these keys at any time. The smart cards are currently visible on the Inventory Table and during the later phase of this ceremony will be distributed to the Key Access Component Holders, who are the only holders possessing PIN codes necessary to access the data stored on these smart cards.
We note, that there is no need to delete our encrypted keys from the hard disk within the computer as these keys are strongly encrypted by the HSM device and additional encryption key, that was divided into key elements (components) within a key set. If the key repository data was stolen, it would be useless without the HSM decryption key and additional encryption key elements (components) distributed to Key Access Component Holders inside the PIN protected Key Access Component Cards. The encrypted keys stored within the repository are in offline state and the computer with the hard drive storing the encrypted repository data will be kept safe in an isolated room with strict personnel and network access controls in place as well as video camera monitoring maintained 24 hours per day throughout the year.
All witnesses attending this part of the ceremony must ensure, that the date entered into this script is correct and the checksum values presented on the computer screen upon sequential execution of the checksum calculation commands, that are performed on private key data stored inside the repository as well as on the backup media, and the values written below by the Key Ceremony Administrator, exactly match. They also must place their signatures where indicated (below) in this section of the script.
Date: …………………………………………
Key 1
Common Name: ………………………………………………………………………………………………………
Checksum: …………………………………………………………………………………………………………………
Key 2
Common Name: ………………………………………………………………………………………………………
Checksum: …………………………………………………………………………………………………………………
…
Key N
Common Name: ………………………………………………………………………………………………………
Checksum: …………………………………………………………………………………………………………………
Witnessing Attendees’ Signatures:
[2] The removable media disks holding backup copies of our keys will now be separated placed into sealed envelopes and sent to be held at separate bank deposit facilities immediately after this ceremony. [2] 4. Since the private key we are about to use is encrypted and access protected, the Key Ceremony Administrator will require any 3 (three) Key Access Component Holders from the previously created Key Access Component Card Set, to separately follow the steps below:
b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet
c. Confirm to memorize their PIN code
d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table
e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device
f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter their memorized PIN Code.
g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.
The above sequence of steps will be repeated for the number of Key Access Component Holders, that are selected by the Key Ceremony Administrator.
All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step.
Furthermore, all Witnesses must ensure, that the correct private key is used during this step. This can be achieved by cross-checking whether the private key identifier file name along with the file system path, are both entered correctly by the Key Ceremony Administrator in the command prompt. These must match the private key details stored in the Key Map Document. The private key should be dedicated for use only with the new Root CA we created today hence the cross-check.
5. The previous step left the private key used to sign the newly created Root CA Certificate offline. It also permanently associated that private key with the new Root CA we created.
6. The Root CA Signing is now declared complete.
[2] An IBM compatible computer (hereafter referred to as "the computer") was set up in a room providing strict personnel access control, security camera monitoring [and electronic isolation from any computer networks].During this step, the Key Ceremony Administrator, using the Cryptographic Operation Control Software, will create new Subordinate CA and assign it to a dedicated private key that was previously generated during this ceremony. The newly created Subordinate CA will be signed by the Root CA that was created earlier during this ceremony.
To complete this process, the Key Ceremony Administrator will use a Naming Document, that contains the details of the new Subordinate CA we are about to sign, to create a certificate profile configuration file, containing various certificate related information such as: Subject Distinguished Name, Validity Period, Signature Algorithm, Certificate Serial Number and Certificate extensions. The certificate profile configuration file will be used by the Cryptographic Operation Control Software to create the new Subordinate CA certificate.
All attending Witnesses must ensure, that the certificate details entered into the certificate profile configuration file by the Key Ceremony Administrator, match the details contained in the Naming Document used during this ceremony. The new Subordinate CA Certificate details must be taken from the section of the Naming Document specifically dedicated for the correct Subordinate CA, for which the Subordinate CA Certificate is created.
Key Ceremony Administrator will capture and store during this step any relevant informational output produced on the computer screen by the Cryptographic Operation Control Software in the Key Map Document.
[2] Upon directing the Cryptographic Operation Control Software to sign the new Subordinate CA Certificate, the private key of the Root CA will need to be loaded to the HSM securely protected operational memory.b. Re-read and memorize their PIN codes, that were previously written on their PIN Code paper sheet
c. Confirm to memorize their PIN code
d. Place their PIN Code paper sheet back into their envelope and place the envelope not sealed back on the Inventory Table
e. Take their smart card from the Inventory Table and when requested by the Key Generation Ceremony Administrator, walk towards the HSM device
f. When requested by the Key Generation Ceremony Administrator, insert their smart card into the smart card reader interface of the HSM device and when requested by the Key Generation Ceremony Administrator, enter their memorized PIN Code.
g. When requested by the Key Generation Ceremony Administrator, remove the smart card from the HSM smart card reader interface and place their smart card back on the Inventory Table on top of their PIN envelope.
The above sequence of steps will be repeated for the number of Key Access Component Holders, that are selected by the Key Ceremony Administrator.
All attending Witnesses must ensure, that each Key Access Component Holder accesses only their own Key Access Component Card and PIN envelope. They must also ensure, that all PIN Code paper sheets remain in envelopes, which are not sealed, and that relevant Key Access Component Cards reside on the top of each envelope on the Inventory Table at the end of this step. Furthermore, all Witnesses must ensure, that the correct Root CA private key is used during this step. This can be achieved by crosschecking whether the private key identifier file name along with the file system path, are both entered correctly by the Key Ceremony Administrator in the command prompt. These must match the Root CA private key details stored in the Key Map Document. The correct Root CA private key should be used hence the crosscheck.
It also permanently associated an existing private key, that was generated earlier during this ceremony with the new Subordinate CA we created.
During the Signing Event, at least two people from the Key Ceremony Attendees list of personnel were present at all times. No other personnel were permitted access to the room. The Cryptographic Operation Control Software required a PIN code to be entered before the software could communicate with any smart card (holding encryption key component [Key Access Component Card]) used during the Signing Event.
[2] During this phase of the ceremony, the Key Ceremony Administrator will request each Key Access Component Card Holder to place their Key Access Component Cards in their PIN envelopes place the envelopes sealed on the Inventory Table.
8. Key Ceremony Conclusion
[2] All copies of the signed Key Ceremony Script are now going to be placed in the Archive Folder.
9. Key Ceremony Attendees Present
Name Title Company Signature
[This page printed blank to allow notes to be made]
[2] I am:
_______________________________________________________________________
CA Owner Organization Name:
___________________________________________________________
CA Owner Organization’s Address:
___________________________________________________________
CA Owner Organization’s Telephone Number:
___________________________________________________________
I confirm that I am in receipt of the following Component(s):
Description Details:
_________________________________________________________________________
_________________________________________________________________________
I confirm that:
I have understand that I am an official Component Receipt Shareholder.
I must keep my Component information secret.
I will only reveal my Component information at scheduled Key Ceremony events.
Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.
Signature: ___________________________________ Date: ____________________
I attest that:
I have validated the identity of this Key Access Component Holder
Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.
Notary Signature: _____________________________ Date:____________________
[2] I am:
_______________________________________________________________________
Organization Name:
___________________________________________________________
Organization Address:
___________________________________________________________
Telephone Number: ___________________________________________________________
Professional License and/or Association Number(s):_________________________
This letter of attestation is being provided on behalf of the following entity:
CA Owner Organization’s Name:
________________________________________________________________
CA Owner Organization’s Address:
________________________________________________________________
CA Owner Organization’s Telephone Number:
________________________________________________________________
I attest that:
Under penalties of perjury, I declare to the best of my knowledge and belief, that the information I have provided is true, correct, and complete.
Signature: ___________________________________ Date: ____________________
Notary Signature: _____________________________ Date: ____________________
Appendix III – Entry/Exit Log
________________________________________________________________
CA Owner Organization’s Address:
________________________________________________________________
CA Owner Organization’s Telephone Number:
________________________________________________________________
Links:
[1] https://www.digi-sign.com/downloads/download.php?id=digi-ca-admin-pdf
[2] http://www2.digi-sign.com/downloads/digi-ca-admin-manual
[3] http://www2.digi-sign.com/compliance/introduction
[4] http://www2.digi-sign.com/public+key+infrastructure
[5] http://www2.digi-sign.com/repository/certificate+practice+statement
[6] http://www2.digi-sign.com/digital+certificate