3 Steps to Implementing Your Public Key Infrastructure (PKI) Architecture

Setting up a public key infrastructure helps you manage digital security certificates, encryption and more.

Popular among both small businesses and large corporations, public key infrastructure (PKI) is a cyber security method of authenticating, validating and encrypting digital information. Recognizing, validating and authorizing identities is a big part of cyber security for all organizations. Encrypting data provides a second layer of security. Originating in the British intelligence community in the early 1970s, the PKI approach for authentication and encryption has been in commercial use for over 20 years.

Here’s how you can implement a public key infrastructure (PKI) architecture in your company.

First, let’s define what a PKI set up entails and what IAM is.

What is PKI and why do we use it?

Public key infrastructure (PKI) consists of policies and procedures that are used to create, manage, use, save and revoke digital security certificates. We use PKI architecture to allow the transfer of electronic information securely for a variety of network activities, that include Internet banking, e-commerce and confidential email. PKI goes beyond mere passwords as authentication and requires more rigorous identity confirmation. After authentication, a PKI system allows data to be encrypted and decrypted, as necessary, in a manner that is more protected from unauthorized, third-parties. This can be used for smart card logins, sending or receiving emails, authentication, open PGP encryption and more.

What is IAM?

Identity and access management (IAM) is the process of managing a user’s login credentials, verifying them and confirming authorization that follows the company’s existing information security policies. IAM offers a two-step identity verification where the person accessing data is first authorized and then allowed access to decrypted data.

A Breakdown of the PKI Environment

The PKI environment consists of five parts:

1. Certificate Authority (CA):

This serves as the ‘root of trust’ and helps authenticate the identity of an individual, computer or entity in the network.

2. Registration Authority (RA):

This is often called a subordinate CA as well, as it is certified by a root CA to issue out certificates for uses designated and permitted by the CA.

3. Certificate Database:

This saves all certificate requests that been issued, as well as all certificates that have been revoked from the RA or CA. It serves fundamentally as a log of all security certification transactions within the system.

4. Certificate Store:
This saves all issued certificates as well as any temporary pending or rejected certificate requests from the local computer. Certificates that are not signed by an authority in the local certificate store will not be trusted by the local system.

5.Key Archival Server:
This saves encrypted private keys in a certificate database. This is used generally for disaster recovery purposes as a backup in case the original Certificate Database is lost or becomes damaged somehow.

Certificates use two cryptographic keys – one public and one private. The public key is provided to other users and systems as a means of decrypting, encrypting and validating data provided by the sender and confirming that this data is unaltered and originated from the sender. The sender will retain the private key.

Tevora’s Two-Tier Hierarchy Design

At Tevora, we have adopted a two-tier hierarchy design for our PKI implementation that meets the needs and requirements of the majority of security-focused organizations.

Our set up entails:

• Segmenting the role of the Root CA and Issuing CA to provide a secure configuration.
• Keeping the Root CA offline, thus allowing the private key of the Root CA to be more secure.
• Allowing multiple deployment of Issuing CAs at different geographical locations.
• Greater control of Issuing CAs at different security levels.
• Less management and implementation than a three-tier design.
• Greater security than a single tier design.
• More scalability for the security environment by deploying more Issuing CA.

 

How You Do It: Tevora Implementation Procedure

Deploying an offline Root CA

1. Standup a non-domain server for the purpose of setting up a Root Certificate Authority (CA).
2. Add the Active Directory Certificate Services role and Certification Authority role services.
3. Specify that this is a Standalone CA with Root CA
4. Create a new Private Key for the Root CA with at least SHA256. Longer key length is more secured but might cause incompatibility issues with some applications (i.e. 4096-bit > 2048-bit).
5. Define the validity of the certificate to be 20 years.
6. Map the namespace of the Active Directory to the Root CA using the Certificate Services.
7. Publish the certificate along with the CRL (Certificate Revocation List) to a location where the Subordinate CA (Issuing CA) can access.

Create the Authority Information Access (AIA) and Certification Revocation List (CRL)

1. For Windows-only environment, establish the AIA and CRL repository to where the LDAP server is located within Active Directory.
2. For all other environments with internal connections (Windows and Linux), deploy an internal webserver to host the certificate repository for the AIA and CRL. Any external connections will then require the AIA and CRL to be publicly hosted instead.

Deploy an Enterprise Subordinate CA (Issuing CA)

1. Standup a server on the enterprise domain for the purpose of setting up an Issuing Certificate Authority (CA).
2. Add the Active Directory Certificate Services role and Certification Authority Certification Authority Web Enrollment role services.
3. Specify that this is an Enterprise CA with Subordinate CA
4. Create a new Private Key for the Root CA with at least SHA256. Longer key length is more secured but might cause incompatibility issues with some applications (i.e. 4096-bit > 2048-bit).
5. Create a request file for a new certificate for the Subordinate CA.
6. Copy the CRL and AIA from the accessible to the designated location to the Subordinate CA.
7. Issue a certificate to the subordinate CA by copying the request file created to the Root CA, submitting a new request, and selecting the recently copied file to issue the certificate.
8. Install the CA certificate to all tasks on the Subordinate CA.
9. Shutdown the Root CA and take it off the network.