How we built a PKI and a TSA and got them certified in 6 monthsPart 3: Public Key Infrastructure

Wait! Did you read part 1 and 2 of this blog post already?
If you didn’t, you can do it now: Part 1; Part 2

If you read first two parts of this blog post, you probably remember that after analyzing the ETSI documents for the eIDAS regulation we concluded that we had to build a Public Key Infrastructure (PKI) before building a Time Stamping Authority.

But why did we need to build a PKI?

• The ultimate goal is to be able to generate digital time stamps.
• A time stamp is basically a digital signature performed on a given data plus a trusted time reference.
• Because a time stamp is essentially a digital signature, it is performed by a pair of asymmetric keys.
• Along with this pair of asymmetric keys, we need a digital certificate that’s associated with the public key (and therefore with the private key) that proves that the identity of its owner is the Signaturit TSA.
• Because we want to issue Qualified Time Stamps, there’s an extra requirement stating that to be considered as Qualified, the private key that performs the digital signatures must’ve been generated and kept protected by a QSCD.

These are all the reasons that explain why we had to build our own PKI so we could generate and issue our own TSA key pair and certificate keeping the private key safeguarded inside the HSM so we could issue Qualified Time Stamps.

Building a PKI…

Before starting to put pieces together we must analyze our needs and design a PKI according to these so we don’t take false steps during the implementation part.

Design

Physical Design

Architecture
PKIs are build following a hierarchical construction structured in tiers.

The first tier corresponds to the Root Certification Authority, which is the only mandatory element to build a PKI. You could build a PKI composed only by the Root CA. Any other component of a PKI “extends” from this one.

A two tier PKI is composed by the Root CA, which would typically be offline for security reasons in this case, and N Issuing Certification Authorities, which would be the ones responsible for the certificate issuance to “end users”.

The way this works is each issuing CA has a key pair and a certificate that it uses to sign the certificates it issues. The certificates for each issuing CA have been signed by the Root CA. So there’s a trust relationship established stating that the Root CA trusts and allows the N issuing Certification Authorities to issue the “end user” certificates.

In the case of a three tier PKI, we would have one root CA, as always, which will be offline. N Policy Intermediate Certification Authorities, the certificates from which have been issued by the root CA. These Policy CAs would typically be kept offline. And N Issuing CAs which would be the ones responsible to issue the end user certificates.
As with the two tier PKI, in the three tier PKI each inferior level CA certificate has been issued by the upper level CA, establishing a hierarchical relationship of trust.

In our case we decided to go for a two tier PKI, which is a compromise between security (the root CA which is the PKI’s key element would be kept offline) and functionality and usage of resources.

Other architectures are perfectly valid depending on the organization’s security needs and amount of activity for the issuing Certification Authorities.

Hardware Infrastructure

We have decided which PKI architecture we’re going to use, now we have to plan how many machines we’re going to need and what services will each one host.

In our case we decided to have one physical server and deploy the PKI machines as Virtual Machines inside the server so we could have an easier management of each one of them, including snapshots, backups etc.

The physical server would be deployed in the data center we had recently rented, so each VM (configured with a bridge network adapter) would be on the same network as the Hardware Security Module.

So our current planned infrastructure was composed by:

• VM for the Root CA
• VM for the issuing CA
• VM that will host the OCSP service and the web server publishing the CRLs and PKI certificates and documentation

Security
Private Key Protection

In our case we purchased an HSM specifically to guarantee the PKI private keys protection.

In order to achieve this we’ll have to configure each Certification Authority to use the HSM as their key store. We’ll talk more about this when we discuss the software used for the PKI’s Certification Authorities.

Additionally, we have set up an extra protection measure for the Root CA private key. In our case, the HSM model that we purchased has support for card set protection.

The way card set protection works is you specify a quorum of N/K where:

• N is the total amount of smart cards that you assign to N employees
• K (being K <= N) is the number of smart cards that you are required to use to unlock the private key that’s protected using card set protection

In our case we created a quorum of 5/3 for our Root CA private key protection. That means that for each operation that needs access to the CA private key (e.g.: certificate or CRL issuance), three out of the five employees who were given a smart card must collaborate.

Role Separation

It’s a good practice to establish different roles to manage the PKI. One user should not have more than one role.

In our case we have defined the following roles:

• CA Administrators: Manage general CA configuration
• Certificate Managers: Manage CA certificate templates
• CA Backup operators: Are allowed to copy and restore sensitive directories and files
• CA Auditors: Responsible to review the CA logs and activity

Physical Security

In our case, because we rented a rack inside a data center, the physical security measures are delegated to the ones provided by the data center itself, so if it complies with some physical security standards you are covered.

CA Configuration
Certificate Validity Period

Choosing the appropriate certificate lifetime for Certification Authorities is a key aspect for which we have to take into account two key points:

• A lifetime too large provides bigger span of time for the private key to be compromised, and the longer the lifetime is, more certificates would become untrusted in that case.
• A lifetime too short is useless considering that issued certificates lifetime can not extend beyond CA’s certificate lifetime

We have to choose a certificate lifetime that’s a compromise between functionality and security.

In our case we decided to set root CA’s certificate lifetime to 20 years and issuing CA to 10 years, which are pretty standard numbers. The issuing CA’s certificate would be renewed at the 5 year mark and the root CA at the 10 year mark.

Key Length

Choosing an appropriate key length for current security standards is a key aspect in the design of a PKI. Usually the National Institute of Standards and Technology (NIST) is a good source of reference for information about this matter.

In our case, because we’re using RSA keys, we chose 4096 bit keys for both root and issuing CAs. 2046 bit keys could have been a possible option but we’re better off with a higher security level, specially considering the lifetime of CA certificates. In case of RSA, 1024 bit keys would have been an option with insufficient security level, and not only for CA keys.

If you’re using EC keys, you’re probably good choosing 384 bit keys.

AIA Location

AIA stands for Authority Information Access, and it points to a repository from where CA certificates can be downloaded by clients when validating end user certificates.

This information shall be specified in every certificate issued by the CA.

In our case we set up a web server to host the PKI certificates at:
https://pki.signaturit.com/cert/

CDP Location

As with AIA, CDP is another attribute that’s also specified in every certificate issued by the CA. In this case it stands for CRL Distribution Point, and, as the name indicates, it points to a repository from which CA’s CRLs can be downloaded.

A CRL is a list of the certificates that have been revoked by the CA, and it’s a required element when validating CA’s issued certificates (unless your querying the OCSP service directly).

CRL Validity

Certificate Revocation Lists also have an specific lifetime on which they’re valid. This span of time will depend upon the CA’s activity. A CA that’s expected to issue a huge number of certificates will have to renew he CRLs more often. Instead, a CA which has very low activity might issue a new CRL only once a year.

In our case we set the root CA CRL lifetime to one year, as it only issues certificates to intermediate CAs.

For the issuing CA we set the CRL lifetime to one week, as it’s expected to only issue the TSA certificates (the certificate that’s used when performing digital timestamps).

Delta CRL

A delta CRL is another type of CRL that’s issued in between base CRL renewals. For example, we could set a base CRL to renew weekly and a delta CRL to be issued daily.

Delta CRLs are not a mandatory feature to implement. In our case, the root CA does not use delta CRL because of its low activity. For the issuing CA’s CRL we configured it to issue a daily delta CRL.

OCSP URI

As an alternative to CRLs, we can set up an OCSP service to which clients can request certificate’s validation information. The reason for which Online Certificate Status Protocol was created was because, for Certification Authorities that had a high level of activity, CRLs become very big with time, which complicates the whole validation process initiated from the client.

In case we want to use an OCSP service, we have to specify its URL because it will be included inside the AIA information section on every issued certificate by the CA.

In our case we only set up the OCSP service for the issuing CA because the root CA has very low activity.

CA Policy

The purpose of a Certification Authority is to issue certificates, these certificates are issued following a given template, and under a set of conditions like security measures, management procedures, etc. This combination of attributes define an issuance policy.

A CA must specify at least one issuance policy which states the conditions under which the certificate corresponding to that policy have been issued.

Each policy must be identified by an OID and a policy statement document which specifies the issuance conditions.

The OID is derived from a private enterprise number assigned by IANA. In our case the enterprise number for Signaturit is 50646, which along with the iso.org.dod.internet.private.enterprise prefix (1.3.6.1.4.1) results in our organization base OID as 1.3.6.1.4.1.50646. And the policy OID as 1.3.6.1.4.1.50646.3.1.

Software

Now that we have specified most important CA configuration attributes, we need to sort out the key implementation aspect. Which software are we going to use to build the PKI?

Of course you could try to implement your own PKI software but that goes way beyond the scope of this blog post, plus you would have to certify that product itself before being able to use it in a production environment.

Instead, we will look for an available product in the market. The range for PKI solutions is pretty heterogeneous, it goes from a simple PKI built using OpenSSL, to a full blown product that costs over 20k.

In our case we decided to choose a solution that was, in our view, a compromise between cost, functionality and online support. We decided to build our PKI using Windows Server 2016 and its Active Directory Certification Services.

Implementation

The final PKI infrastructure looks like this:

We set up 4 VMs:

• Windows Server 2016 with Active Directory Certification Services using standalone Certification Authority profile for the root CA
• Windows Server 2016 with Active Directory Domain Services which acts as the Domain Controller for the other VMs (except for the root CA which is out of the domain)
• Windows Server 2016 with Active Directory Certification Services using an enterprise Certification Authority profile for the issuing CA
• Windows Sever 2016 with Active Directory Certification Services using the Online Certificate Status Protocol service profile along with an Internet Information Services role that sets up a web server to host the PKI certificates and CRLs

The 4 VMs are deployed inside one physical server using Virtual Box.

Each VM is deployed using a bridge network adapter so they are attached to the same network as the HSM (except for the root CA, which is detached from network and offline).

The two CAs and the VM that hosts the OCSP service have a middleware software provided by the HSM vendor installed which allows them to communicate with the Hardware Security Module.

This middleware communicates with the application (in our case the Active Directory Certification Services) by means of the libraries provided by the HSM vendor that we mentioned in Part 2 (link)

For Windows Server 2016, the Active Directory Certification Services delegates the cryptographic operations to libraries accessible through the Cryptography API: Next Generation (CNG) interface.

The way the “hook” is performed is that, besides the middleware, there’s also a library provided by the HSM vendor that implements the CNG interface. So the flow is:

1. Active Directory Certification Services has to perform an operation that requires the usage of a resource protected by the HSM. For example sign a CSR with the CA’s private key.
2. ADCS requests a digital signature operation for a given data and using the CA’s private key through the CNG interface
3. The request is processed by the CNG implementation provided by the HSM vendor relaying on the middleware to perform the communication with the HSM

With all this, along with some other tricks, like enabling the inclusion of QCStatements for issued certificates, we built up our own PKI.

If you have more deep technical questions about Active Directory Services feel free to ask in the comments section, as we had to battle with it a little bit to work around some functionalities.

About Signaturit

Signaturit is a trust service provider that offers innovative solutions in the field of electronic signatures (eSignatures), certified registered delivery (eDelivery) and electronic identification (EID).

Open Positions

We are always looking for talented people who share our vision and want to join our international team in sunny Barcelona :) Be a SignaBuddy > jobs