15.2.8.6 HSM Security Environment

All data related to Security World is stored in the Security World directory on the disk of the host PC. The actual path is determined during installation and defaults to:

C:\ProgramData\nCipher\Key Management Data\local

The Security World directory contains all Security World data and can be backed up, restored, copied, or moved to another HSM as a whole. It contains HSM identity information and should be backed up periodically.

Security World data includes the following:

• Security World identity and configuration settings
• Data of HSM module(s) connected to Security World (the SPPS U-HSM and M-HSM support single module setup only)
• Data for the ACS cards associated with Security World
• Keys used by HSM internally
• Private component of the private/public key infrastructure for communication
• Public keys of the other HSMs for secure data exchange
• Microchip Manufacturing Keys (used during bitstream generation by the U-HSM and used during protocol execution by the M-HSM)

The following figure shows an example of U-HSM Security World directory content.

Note: The M-HSM has similar Security World data structure. The main difference between the two is the length of the UUID used by both HSM types (32 for the U-HSM UUID, 40 for the M-HSM UUID) and key name prefixes: "cu" for the U-HSM and "cm" for the M-HSM, respectively.

New Security World creation instructions are provided in the User HSM Installation and Setup User Guide for the U-HSM and the Manufacturer HSM Installation and Setup User Guide for the M-HSM. This process also includes initialization of the Administrator Card Set (ACS). ACS cards are used for administrative actions performed on Security World, such as connecting new HSM modules, and so on.

Information about Security World is placed into the file named "world", as shown in Figure 15-48.

Information about each card in ACS is stored in the file with prefix "card_", for example, card_7fb2caf3494e585d4664febf7d624ab1b99e7d50_1

The process of Security World creation makes use of the HSM module connected to the host PC. The HSM module is connected to Security World, and as a result, the Thales nCipher software creates a file that contains information about the module in the Security World directory. The file follows the pattern "module_<module serial number>", as shown in the example in Figure 15-48.

This HSM module can be replaced with another module at any time after Security World creation.

The HSM hardware module executes two types of the firmware:

• Standard nShield firmware provided by Thales.
• Custom firmware that implements Microchip security protocols and makes use of various keys created for the SPPS. This custom firmware is referred to as the SEE machine.

Standard firmware controls execution of the SEE machine. This control includes load, decryption, and security integration between SEE machine firmware, security keys used by SPPS, and data stored inside HSM module non-volatile memory (NVRAM).

• The Microchip SEE machine is signed by the private component of the SEE Integrity Key.
• The public component of the SEE Integrity Key is installed in the Security World directory upon HSM setup in the file key_seeinteg_userdata_signer (shown in Figure 15-48).
• All keys created and used by SPPS are cryptographically signed by the public component of the SEE Integrity Key. This signature carries the hash of the private component of the key, thus allowing standard nShield firmware to enforce ACL policy by matching signatures on the SEE machine and keys used by it.

For each HSM server, the user creates two private/public key pairs. One private/public key pair is used for encryption and decryption. These keys appear with the prefix "key_simple_g4cu_seepk" and "key_simple_g4cu_seesk" as shown in Figure 15-48. The public key is sent to the other HSM servers for encryption of the data sent back to this HSM. The HSM then uses the private key component to decrypt.

received data. The private component is a persistent key created in the Security World directory stored in the encrypted form.

The other private/public key pair is used for signing and verifying signature. These keys appear with prefix "key_simple_g4cu_seessk" and "key_simple_g4cu_seespk" as shown in Figure 15-48. The HSM uses the private key component to sign the data that is sent to other HSM servers. The public key is sent to other HSM servers for verifying the signature of data sent by this HSM, which allows checking the authenticity (that is, assurance of signatory's identity) and integrity (that is, tamper and corruption detection) of the data being imported. The private component is a persistent key created in the Security World directory stored in the encrypted form.

The public key of the HSM server carries cryptographic proof that it was created by an nShield HSM module. This binding is done through the HSM Warrant file and is checked by the other HSMs when importing this public key component. This mechanism makes it nearly impossible for the intruder to gain access to any HSM server used by SPPS by sending them a falsely generated public key.

The HSM warrant is a file created by Thales. It is unique and included with every nShield Solo or Edge HSM module provided by Microchip as part of the module acquisition process.

Data inside the warrant file ensures that an nShield module with a specific module serial number (ESN) and KLF value has been certified by Thales.

The ISK is a persistent Security World key generated by the customer. The ISK is stored in the Security World directory in a file with the default name key_simple_g4see_isk, as shown in the example in Figure 15-48. The actual name of the file is user-configurable per instructions provided in the User HSM Installation and Setup User Guide and the Manufacturer HSM Installation and Setup User Guide .

The ISK value is randomly generated by the HSM module and is unique within Security World. This key can only be used by the SEE application.

Before an HSM can communicate with other HSMs, the public keys need to be manually exchanged in a trusted manner. As a part of key exchange, every HSM server used by SPPS should import two public keys from each of the other HSMs. This mechanism mirrors the process explained in Private/Public HSM Keys. See the User HSM Installation and Setup User Guide and the Manufacturer HSM Installation and Setup User Guide , which explains how to import these public keys.

Public key import includes a strict check of the key generation certificate of the key being imported. This check validates that the key was generated by a valid HSM of the official SPPS application.

After the check has been done, the ISK is used to sign imported public key as proof of warrant check done upon the key import. This signature is required for the key to be used by the SEE application.

An example of the imported public keys is shown in Figure 15-48. This sample Security World has the following imported public keys:

• key_simple_g4cm-seepk-0000000000000000000000000000000000000002
  • This is the encryption public key of the M-HSM with UUID "0000000000000000000000000000000000000002"
  • Note that the M-HSM has UUID length of 40
• key_simple_g4cu-seepk-00000000000000000000000000000001
  • This is the encryption public key of this U-HSM
  • Note that the UUID length is only 32 hex symbols
  • This is to enable the M-HSM function of this U-HSM server
• key_simple_g4cm-seespk-0000000000000000000000000000000000000002
  • This is the verify public key of the M-HSM with UUID "0000000000000000000000000000000000000002"
  • Note that the M-HSM has UUID length of 40
• key_simple_g4cu-seespk-00000000000000000000000000000001
  • This is the verify public key of this U-HSM
  • Note that the UUID length is only 32 hex symbols
  • This is to enable the M-HSM function of this U-HSM server

These special Microchip keys are imported per device type as a part of obtaining the DFK DB. For more information, see the User HSM Installation and Setup User Guide for the U-HSM and the Manufacturer HSM Installation and Setup User Guide for the M-HSM.

Every imported key is created in a file starting with the prefix "key_simple_f4mf-" key. These keys are used by both the U-HSM and the M-HSM. They are sent to either HSM from the Microchip Manufacturing HSM. The key values are encrypted with the public key of the receiving HSM.

The U-HSM ​Initiater Key is created by the user. This is a symmetric key that allows the U-HSM to protect KeySet files and Job Ticket initiater keys.

The U-HSM ​Initiater Key encrypts the Job Ticket ​Initiater Key, which in turn protects all private Job Ticket data. To send ticket data to the M-HSM, the U-HSM only needs to rewrap the Job Ticket ​Initiater Key with the M-HSM public key.

DFK DB is used by the M-HSM during initial key loading (see Diversified Factory Key (DFK) and DFK Database). It can also be used during a test run by the U-HSM.

DFK DB is generated by Microchip for the specific U-HSM UUID. All DFK values in the generated database are encrypted by per-device type DFK DB ticket keys. DFK DB ticket keys are protected by the U-HSM public key imported into the Microchip Manufacturing HSM during the previous steps. This scheme allows the U-HSM access to the DFK values in the received database.

To use DFK DB on the M-HSM side, the user exports the DFK DB ticket keys and sends them to the Microchip Manufacturing server for rewrap with the M-HSM public key. Rewrapped ticket keys are imported by the user back to the DFK DB. When the DFK DB has ticket keys encrypted with the M-HSM public key, it can be used by the M-HSM.

All private data and key material is used by the Job Manager during bit stream generation and job preparation is protected by the Ticket ​Initiater Key. This is a symmetric encryption key encrypted by the U-HSM ​Initiater Key (see U-HSM ​Initiater Key).

During HSM job export (Job Creation), all Job Tickets are rewrapped with the target the M-HSM public key. This grants the M-HSM access to all job data protected by the Job Ticket ​Initiater keys.

Other types of communication between the U-HSM and the M-HSM, such as Job Request/Reply protocol execution (Job Preparation) and returning job end sending job end certifiers from the M-HSM for validation to U-HSM, also make use of the counterpart HSM public key to protect private information.