Learn Public Key Infrastructure (PKI) Basics – Part 1

Digital certificate contains the most important information i.e. Public Key (the unique number identifying you in the digital space) and its contents must be protected from tampering. To ensure the integrity of a digital certificate, it is digitally signed by the authority who is issuing the digital certificate. This is important even if it is self signed. See our article on digital signature to know more about it.

Certificates can be easily generated by off the shelf free tools like OpenSSL etc. This raises an important aspect on how can I trust your digital certificate? It could be a fake certificate under a registered company you know. Trust is the key before using any certificate. This brings up the need for trusted authorities called in general CA (Certification Authorities).

You can get a digital certificate from in following ways:

The CA could be:

On the internet world you can’t put your driver license or National ID to login as these are not digital. You hence need a PKI based digital identity and a digital certificate provides you one. A digital certificate is nothing but a claim either from a Certification Authority or could be self claimed, identifying your name, organization, address, country and the associate public key (your unique identifier). A digital certificate is like your Identity card or driver license claiming who you are, till what date this claim is valid, who issued this claim, what public key the user is assigned and lot more.

Digital Certificate = Digitally Signed (Your basic identification + Your public Key + Misc Information)

A digital certificate can be issued to a person, computer, network device (router, switches), mobile. In the modern area this can be expanded to IOT devices like your air Conditioner, fridge, oven etc.

PKI is prevalent every where. In the real world PKI is used in some of the following areas:

• Authentication: Following two authentications are commonly used

  • User Authentication: User can authenticate them selves by providing their digital certificate at login to either their workstation or an internet facing web application. Your digital ID could be either stored on your laptop, USB token or mobile phone. Technically the purpose of digital certificate used for this is for SSL Client Authentication

  • Machine / Application Authentication: Similar like user authentication, machines (PC, switches etc.) or applications (web servers etc.) present their digital certificates to be authenticated. This ensures both to identify the machine whom your are communicating and also to encrypt the communication channel by establishing a secure TLS sessions. Similarly in browser/webserver case:

    • You browser can identify the server and warn if some unknown certificate was presented

    • The communication between your browser and the web server can now be encrypted hence your private information like passwords, Personal Identifiable information remains safe from hackers. If a webserver doesn’t use certificate to be authenticated, the browser raises it as an alert. Technically the purpose of the digital certificate used for this is SSL Server Authentication

• Protecting your data: Your data could be on your laptop or in the cloud. This can be achieved using Bitlocker for Windows and dm-crypt for linux. Cloud based data storage providers also employ similar encryption techniques like in the case of OneDrive.

• Signing: Signing with your digital certificate helps reviewers identify the signer, the time of signing and whether it was changed after signing. Some of the different types of signing are:

  • Document Signing: This is done by creating digital signatures on your PDF, XML, files, Word documents etc. As your digital certificate identifies who you are, signing a document with your digital id identifies who signed it and when it was signed. Any single bit changed in your electronic document breaks the integrity of the document. Nearly all the popular document processing applications like Microsoft Word, Open Office, Libre Office, Adobe Acrobat support document signing. Read our document signing article to know more.

  • Email Signing: Similarly one can sign their emails before sending it out. Receives can see who has signed the email, the time of signing and its integrity. All popular email clients support email signing

Trust doesn’t mean a fraud can’t be committed. Trusting a digital certificate only means you or your computer can happily communicate securely with the certificate holder and any changes can be detected. As an example, if you digitally sign a multi million deal with your digital certificate and later don’t agree or back off, the other party can file a suit as you are now breaking an agreement. You can’t deny that you have signed the document. In short, PKI is just establishing the fact that whom you are communicating is indeed the one you are expecting.

No PKI is complete without a Certification Authority. A Certification Authority is an accredited organisation to issue digital certificates. This is similar like how you get an ID card or driver license from an authorized government entity. Certification Authorities can be private or government orgranisations. To become a CA organisations first need to obtain a license. Licensing require them to demonstrate the capability (planning, resources, features) to the accrediting authority. CA can either be self signed also called as Root Certification Authority or a Subordinate CA certificate. The Subordinate CA which eventually issues certificates to human, computers or devices also called as End-entity certificates.

CAs can be classified as closed/non-public CA and public CA. There are currently hundreds of public and possibly thousands of closed CAs. To find how many CAs are out there, simple open certificates section on your computer.

Public CAs have a legal liability to ensure certain check before issuing a certificate. For a qualified certificate (issued to a person), the true identity of the person is checked before issuing a digital certificate to a person. Similarly different checks are performed for different types of certificates. For an SSL Server Certificate, CA companies check whether the owner has ownership of the domain which it is going to protect. Similarly for code signing, company wide checks are performed. In EV SSL certificate more stringent checks of company is done.

Becoming a Public CA is a costly ordeal as there are cost involved in setting up the process, policies, hardware which takes time from months to few years. Public CAs are eventually bundled with your operating system as default (as shown above). Alternatively if you have closed CA you can trust it manually by importing its Root CA Certificate.

To ensure the utmost security, CA employs Registration Authorities (RA) to do all the public facing, vetting, payment work. This hence isolates bad actors from accessing CAs directly.

Let’s summarize all of what has been discussed to see how PKI are conceptualized and maintained:

Establish the need of a PKI

To establish the needs, following questions needs to be answered:

• What issues the PKI will fix i.e. authentication, signing, encryption etc.

• What types of certificate will be issued and how.

• Are the certificates to be issued for person or machines

• Is it a closed PKI or public. If closed, can it be on-premise or on the cloud

• What time line are being aimed

• Are budgets and management resources already assigned

Make a Project Plan of actions to perform i.e. Key Ceremony

Identify all the milestones in the project plan covering:

• Hardware, PKI software procurement

• Developing policies (CP, CPS), processes for the entire PKI

• Key generation for each the Root CA, Sub CA, End-Entity Certificate etc

• Training of staff

• Auditing of the PKI system

Deploying the PKI

This includes documenting and implementing the PKI as agreed in the project plan. If you are deploying a PKI which needs to be up 24x7x365 and a down time is not acceptable you need a staging, production and disaster recovery sites. If not then just staging and production could be sufficient.

Auditing the PKI

Deploying PKI is exciting for PKI Engineers but not auditing as this checks their performance and hold them accountable. Auditing ensures what’s implemented is as per agreed documentation and find the gaps. This part is repeated multiple times in a year to avoid major non-conformance. This involves reviewing:

• Roles, Rights for operators ensuring least privilege principles for the PKI software (RA, CA etc.) and hardware covering machines, HSMs etc.

• Software and hardware logs

• Any signs of misconfigurations and hacking attacks

• Identify anomalies and reporting the findings to the higher ups

• Optionally if the Root CA is hosted by some other company than share the list of issued certificates to them

See WebTrust Guidelines for setting up your own public Certification Authority.

I am text block. Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

Launching the perfect PKI is not as smooth as it is thought of. It can take few days to years to launch and get your PKI into production. The success and failures is majorly due to the compounded nature of PKI concepts & partially due to the use cases being implemented. Some common concerns of PKI are:

Is PKI is complex?

Yes PKI is complex with more than a dozens of standards and moving pieces. It takes more than few months to years to understand and ensure its working as it should.

Possible PKI Failures

Possible Solutions

Real world Disasters

Is PKI expensive?

It depends upon whether you want a closed PKI which can be built cheaply using Open Source software or a public one using known 3rd party CA solutions out there. Also it depends upon what PKI requirements you have like you want just authentication (server side) to be done or all of authentication (client and server), signing (document, email etc.) and encryption of files (laptop, mobile etc.). Depending on your needs, a solid PKI needs few hundred to few millions dollars. This covers cost for:

• Hardware Secure Modules (HSM) to securely store Root and Subordinate CA keys

• Software (CA, RA, OCSP, Timestamping etc.)

• Training of staff in the PKI domain

• Audit licenses (WebTrust or some local country side license etc.)

Possible Fixes

• Pick a cheap HSM from yubico, open source software (OpenSSL). If you are a Microsoft license holder than choosing Microsoft CA Server could be a quick choice. If Linux, opt for Dogtag CA or RedHat CA

• Choose a managed cloud based PKI solution

Is PKI not 100% secure?

There is no such thing as 100% security. There is only sufficient security or weak security. As PKI is relying on just numbers these can be guessed with brute force attack. Fortunately current computing power takes ages to brute force an RSA 2048 bit key pair but this may change in a decade or so. Quantum computers are being researched and developed. Google Aims to build a useful Quantum Computer by possibly 2029. This is too close and probably scary too.

Possible Fixes

• For now there is no need to panic. We have roughly a decade to see Quantum computers so till then the current cryptography is stable

• Research is being done on Quantum resistant algorithms. By the time a hacker would use a quantum computer to brute force attack keys, newer stronger algorithms should hit the market. PKI will still be prevalent!

Following checklist is aimed at PKI Administrator to ensure they keep their existing PKI infrastructure secure and efficient.

• Ensure the PKI software used is using the latest patch – this is the most common mistake breaking PKI

• Monitor your PKI for rouge certificates being issued. Look at the list of certificates issued or check the subject DN of the certificates

• Review the audit logs of the RA, CA, OCSP, Timestamp servers and HSMs – find patterns of logins at odd time

• Ensure Dual Control employed at critical steps i.e. issuance of a new infrastructure certificate, CA certificate, operator certificate etc.

• Perform promptly certificate revocation for employees who have left or changed their roles

• Always opt for least privilege principle

• Regularly review the Roles and Operator list

• Create alerts against upcoming certificates expiry. This is critically important for your Subordinate and Root CAs. Expired infrastructure certificates can stop resources access instantly effecting resource access

• Generate reports on daily basis to see how many certificates were issued, revoked, renewed and see any irregular patterns

• Train your staff on security and privacy & train them thoroughly! – the last thing you need is your staff storing their password on sticky notes

• Actively look for threats being identified against hashing and encryption algorithms e.g. SHA-1 was once strong enough but no more

• Actively research for Quantum safe algorithms

• Lastly enjoy PKI!

Learn more about digital certificate in Part 2.