Key Management Best Practices for EJBCA with Fortanix DSM

Keyfactor EJBCA and Fortanix DSM

Public Key Infrastructure (PKI) is a long-established concept to build trust between different parties and to allow secure and authentic communication between them. It is widely used in e.g., e-commerce, internet banking, and confidential email.

A core element of a PKI is the Certificate Authority (CA), which is built by different vendors. Very popular is Keyfactor’s EJBCA. It is the first choice for many organizations, as it is available as an open source (Community Edition) and a commercial (Enterprise Edition) version.

If your CA keys are important for you, the CA software alone is not sufficient. These CA keys are the root of trust for your whole organization and need to be protected as well as possible, typically within a hardware security module (HSM). This is a tamper-evident crypto keystore, which should be compliant with the NIST standard FIPS 140-2 Level 3.

With the Data Security Manager (DSM), Fortanix provides a perfect solution complying with this standard. It can be installed on-premises as the FX2200 or can be used as a SaaS solution. In both cases, it offers a web-based and feature-rich Key Management System (KMS).

EJBCA / DSM Integration

DSM integrates seamlessly with the EJBCA. The integration procedure is documented in the EJBCA/DSM integration document. The link between the EJBCA and DSM is established via the PKCS#11 API, a proven API managed by the OASIS organization.

Figure 1 depicts the high-level architecture for this solution.

The EJBCA allows setting up CA entities through its administration page. These can be assigned to Crypto Tokens, linking to external key stores. The page for setting up a Crypto Token is shown in Figure 2. When creating a key in such a Crypto Token, the key is actually created within the external key store.

Figure 1 was created within Fortanix DSM. Hereby, it is created in a DSM Group of a customer-specific DSM Account. The UI pane of a DSM group containing two private keys from an EJBCA is depicted in Figure 3.

The joint EJBCA/DSM solution allows triggering the key generation from the EJBCA administration page, as well as from the DSM UI. This allows for key management scenarios like Bring Your Own Key (BYOK).

EJBCA Key Management Best Practices

When you have established a connection between the EJBCA and DSM, you should follow some key management best practices supported by the EJBCA/DSM combination. These are explained in the following sections.

1. CA Key Disable

After some tedious and exhausting work, you have set up your whole PKI with root and lots of subordinate CAs, and you have issued thousands of leaf certificates. Great achievement; a big reason to congratulate yourself. This was a lot of work.

But then, suddenly, you see some fishy actions within your PKI. One of your subordinate CAs has issued certificates without the required authorization. You are not sure what has happened. Maybe this is only a false alarm. But following the best practices, you need to make sure that this CA does not issue more certificates.

And you have to act immediately. The only way is to revoke the CA certificate. This is what you need to do. But after a couple of hours of investigation, you realize that it indeed was a false alarm. However, the damage is done. You will have painful work ahead of you to set up the CA again and exchange all issued leaf certificates.

A major task. Not to mention the loss of credibility this will incur. Many of your colleagues and also your management will disapprove of this, Not to mention the anger of your customers! If you just had the chance to disable the CA for a short period of time. Unfortunately, this is not possible. But, using DSM, you can disable the key.

Then, the CA cannot issue new certificates, which is exactly what you need. It gives you time to investigate the issue. And in case you figure out that it was a false alarm, you just enable the key in DSM again. Problem solved. Nothing else to be done. No disgruntled customers. Lots of CA administrators desire this feature to disable the CA key for a short period of time.

2. Key Undo Policy

Consider you have accomplished setting up a PKI hierarchy and have issued millions of certificates with it. Your Certificate Revocation List (CRL) is filling up, your Online Certificate Status Protocol (OCSP) responder is answering all certificate status requests, and you have a Registration Authority (RA) in place to manage new certificate requests and certificate status change requests.

Perfect, everything looks great. But then by occasion or deliberately, one of your staff members is deleting the private key of your root CA. This would be a disaster. Your whole PKI has become invalid within a blink of an eye.

You would need to invalidate the current PKI and to set up the key hierarchy from scratch. Of course, all issued certificates would need to be revoked and re-issued as well. You really want to avoid this.

Fortunately, Fortanix features a Key Undo Policy. This acts like the recycle bin of your operating system. If this policy is set up, any deleted key lands in this recycle bin and can be restored. After restoring the key, your PKI is fully functional again.

The restoration period can be set according to your needs. The allowed range is from seven to 180 days.

3. Multi-Control

However, if the key is deleted, this can lead to major disruptions within your company's digital services, despite having a key undo policy, as it can lead to downtime. Ideally, accidental or malicious key deletion is prevented in the first place, following a zero-trust policy.

Hereby, you do not allow a single person to perform key management operations. Instead, you set up dual-control or multi-control for this kind of operation. This can be achieved by setting up a quorum approval policy within DSM to protect your valuable keys from misuse.

Now, you need at least two people to agree on a key management operation, eliminating the peril that a single person modifies the key. Fortanix has implemented the quorum approval asynchronously, meaning one person can approve at one location on Monday, and the other can approve at a different location on Tuesday. This eases key ceremonies a lot, which used to be a very painful task in the past.

4. Strong Authentication

A lot of systems only support username/password authentication. Unfortunately, this does not meet the security requirements of most organizations, as this type of authentication has proven to be too weak. A much better solution is using two authentication factors, like the DSM 2FA authentication solution.

DSM also supports leveraging existing IDPs, based on SAML, OAUTH or LDAP.

5. Role Based Access Control

It is a very good practice to follow the need-to-know principle. Users should only see the relevant data for their work and nothing else. In the case of the EJBCA, an organization may want to have different roles for auditors or system administrators.

Furthermore, an organization would want to separate and control the access for the operators of the different entities, like root CA, intermediate CA, or issuing CA. The well-known term here is “separation of duties”.

A very common approach to achieve the separation of duties is to implement a role-based access control (RBAC). Hereby, users are assigned roles that define their privileges within the system. DSM supports the standard roles of Administrator, Auditor, and Account Member. The latter already provides a high flexibility on a need-to-know basis, as it controls users' access to DSM groups.

But Fortanix is taking it to the next level, as it also takes into account the principle of least privileges with custom roles. It allows a customer to construct his own roles on account and group levels. Hereby, a customer can compile his own roles by composing the desired privileges from a large set of DSM rights so that these roles match the customer's specific needs.

5. Crypto Policy

You may have a detailed crypto policy in your organization describing which key algorithms and lengths may be used. But how can you ensure this crypto policy is enforced within your organization? It happens very often that employees do not follow such a crypto policy because they either do not know the policy, do not understand it, or just make a mistake.

Using weak keys in your PKI is a big security risk, and you must avoid that. Therefore, Fortanix has implemented a crypto policy in DSM. Here, you can specify which key algorithms and key lengths shall be allowed. Consequently, the usage of weak keys is prevented in the first place.

If you need guidance on which crypto algorithms are supposed to be used, then look at the BSI recommendations for key lengths [source], a German recommendation adapted by many EU countries, and the more world-wide relevant NIST recommendations for key lengths [source].

6. Multi-Tenancy

If you host your valuable keys inside of an HSM, you will want to make sure that only you as a company has access to it and no one else. This can only be achieved if multi-tenancy is built into the solution.

Each tenant shall have its own secure space inside the HSM that does not interact with the space of other customers. In the case of DSM, this is achieved by Accounts. Each customer will get access to only their own account and nothing else, as each account is cryptographically isolated from others.

Conclusion

Secure storage and a flexible Key Management System are important elements of a PKI, as provided with the EJBCA. By storing the keys in an external HSM, the security can be improved significantly. Furthermore, the management of the keys can be made more secure by applying good practices like strong authentication, 2FA authentication, RBAC, crypto policy, multi-tenancy, key undelete policy, and quorum approval policy.

For more information, please contact Fortanix.