guidance

Design and build a privately hosted Public Key Infrastructure

Principles for the design and build of in-house Public Key Infrastructure (PKI)
Invalid DateTime

PAGE 11 OF 21

Change
2. Protect your private keys

PAGE 11 OF 21

2. Protect your private keys

Securing your private keys will reduce the likelihood of compromise.

When a public/private key pair is generated, the key must be generated from a good source of randomness and should normally be generated by the end entity that will use it.

Where a private key has to be generated away from the end entity, then it must be encrypted in transit and at rest. Access to the key must be monitored, authenticated and authorised, see principle 3, develop a robust certificate registration procedure.

Once a private key has been generated, it must be protected so that it can only be used by the identity it represents.

The private portion should always be kept secure, while the public portion can be distributed to other users in the system. If the private key came into the hands of an attacker, they could use it impersonate a user and gain access to a system.

Key Storage

A CA's private key should be stored in hardware-based protection, such as a Hardware Security Module (HSM). This provides tamper-resistant secure storage.

A Private key for an end entity could be stored in a Trusted Platform Module (TPM) chip or a USB tamper-resistant security token.

When hosting in the cloud, you should try to use the cloud-native key storage facilities provided by the vendor. For example, a private key could be stored in a hardware-backed key store in the cloud.

Alternatively, if a hardware-based protection method is not available, you should use an operating system secure private key store.

Securely storing your private keys will reduce the likelihood of compromise.

Exporting keys

The type and use of a key will determine whether it needs to leave the device to be backed up. This should be a risk-based decision, taking into account availability requirements and the difficulty of restoring the key in a disaster recovery scenario.

For example, a root CA key should always be securely backed up, so the key can be recovered in the event of a system failure. See principle 2 for more details on backing up a CA key. If the key does have to be exported, it should be encrypted both in transit and while it's stored. The key must be encrypted in a way which protects it, but allows it to be decrypted after an incident.

A key used for an end entity certificate, such as an end-user device key, may not need to be backed up. This type of key should be easy to regenerate and the related certificate can then be issued again.

3. Certificates Authorities should be highly available and resilient to both attack and failure
1. Understand what you are building