Public Key Infrastructure [PKI] - An Introduction

PKI is one of the important concepts in field of security, here the confidentiality, integrity and authentication is achieved. Providing enterprise wise secure infrastructure.

To build the PKI infrastructure, it requires many pieces. Today we will see most common parts  about the architecture of the PKI.

Agenda

• Keys
• Secret Key
• Public Key and Private Key
• PKI
• Certificate Authorities
• Certificate Practice Statement - CSP
• PKI Trust Models
• Singe CA
• Hierarchical CA
• Online vs Offline CA
• Bridge Model CA
• Registration Authorities
• Digital Certificates
• Certificate Signing Request - CSR
• Certificate Attributes
• Types of Certificate
• Certificate Formats
• Key Recovery
• Key Escrow
• Certification Revocation Lists - CRL
• Online Certificate Status Protocol - OSCP
• OSCP Stapling
• Certificate Pinning
• OpenSSL
• PKI Challenges

Keys

One of the encryption method is using the key which is a random set of characters to mathematically convert your text to some junk content, which cannot be understood unless decrypted.

Secret Key

Using a single key for both encryption and decryption. Either parties use the same key. The performance is fast here. The challenge here is sending the secret key before starting the encryption is a challenge.

Public Key and Private Key

For encryption and authentication, in public key cryptography we use a pair, public and private key. There are two most common use cases for using this:

• To share the confidential information, we encrypt the message using the public key of the receiver, which can be only decrypted using the paired private key and this is only with the receiver never shared with anyone. 
• To authenticate oneself, one can encrypt the message using its private key, which will be only decrypted by using public key. As public key is the only key use to decrypt the message signed by the private it comes one has the private key and can be authenticated as success.

PKI

The most important problem with public key cryptography is are we talking to the legitimate user, as any one can have the pair of public and private keys. PKI helps consists of technologies and policies for the creation and use of digital certificates. To validate this we have CA - Certificate Authority. The CA validates this using various models.

PKI protects information by providing:

• Identity authentication
• Integrity verification
• Privacy assurance
• Access authorization
• Transaction authorization
• Nonrepudiation support 

Certificate Authorities

The Certificate Authority - CA is an entity responsible for issuing and guaranteeing certificates. For secured communication the CA must trust both the party, and vice versa. There are primary two kinds of CA:

• Private CAs 
• Internal to an organization
• Public CAs
• 3rd party 
• Eg CAsGoDaddy, IdenTrust, Digicert, GobalSign, etc

Functions of CA: Provide various certificate services, such as:

• Key generation, creating secure public and private key pair for the chosen cipher, algorithm and strength
• Issue certificate, subject submits the request to CA passing its public key and its details, CA verifies the user and on success provide certificate
• Validation of the certificate
• Validation of the parties applying for the certificate
• Establish the trust by users, government and organizations
• Manage servers storing the certificates, private keys
• Perform key and certificate life cycle management
• Revoke invalid certificates, could be due to expiring of valid duration or if the primary key is compromised revoke it from users trusting the public key
• Renewal, new certificates generated either with the same key or new key. Usually when the old key is not long enough or risky, new key is used. Need to make sure if any data encrypted with the old key need to be decrypted and encrypted back with the new key.

Certificate Practice Statement - CSP

• CSP is the legal document CA creates and publishes the information to the subjects depend on this.
• CSP generally holds the below:
• Identification of the CA
• Types of certificates issued
• Applicable certificate policies
• Procedures for issuing, renewing and revoking certificates
• Security controls maintained
• Certificate policy indicates the rules applied to an issued certificate.

PKI Trust Models

Trust model is an important concept in PKI. Here we would see how users and different CAs are able to trust each other.

Credits: https://www.sysadmins.lv/content/images/pages/1998/hierarchy.png

Single CA

• Only single CA serves request to the users and issues certificates
• An issue with this is its single point failure, if compromised the entire PKI collapses
• Would be good enough for small organizations.

Hierarchical CA

• Here the CA is architect like tree model, the root CA will issue certificates to the next level node CAs called as intermediate CAs
• The good part here is, each intermediate CAs can have its own policies for issuing certificate and acts as a load balancer.
• The intermediate CA can issue certificate, referred as trust hierarchy. As each intermediate CAs can be tracked back to the root CA is called certificate chaining or chain of trust. Eg:
• The root certificate verifies certificate A.
• Certificate A verifies certificate B.
• Certificate B verifies certificate C.
• Here also we have issue of single point failure, as root CA is the primary CA. 
• Also cross certification is a limitation here, that is the CA trust another organization.

Fig: Hierarchical CAs

Online vs Offline CA

• An online CA, which we usually refer as intermediate CAs will be responsible for issuing certificate  and management of certificates to the users or further down intermediate CAs. 
• An offline CA, as there is high risk of root CA getting compromised will collapse the entire system, we have this offline and used only to add or remove the one level down intermediate CAs. This is usually powered off and disconnected from network.

Cross Certification Model CA 

• An alternative to hierarchical model is called as cross certification model, and it is also known as web of trust model.
• Here we do not have single root dependency as the CAs are considered as peers to each other.
• But configuration of this over a period of time becomes a challenge. 

Bridge Model CA 

• To solve the cross certification problem, bridge model was introduced as here to have single CA called bridge CA to combine two or more hierarchical models.

Credits: http://www.pkiglobe.org/pki_models.html

Registration Authorities

• Registration is the process by which end users create an account with the CA and become authorized to request for certificates.
• RA performs the identity validation and submit CSRs on behalf of end users to the CA, but they do not actually sign or issue certificates, that is only performed by CA.
• Some CAs themselves performs this.
• The registration function may be delegated by the CA to one or more RAs. 
• Commercial CAs might perform a range of tests to ensure that a subject is who he or she claims to be. It is in the CA's interest to ensure that it only issues certificates to legitimate users, or its reputation will suffer.

Digital Certificates

• Digital certificates - DG, are like your signatures, which you can deny after you have used it. The additional in digital certificate is signed to prove it is issued by trusted CA.  
• DGs are used for identification and authentication purposes.
• The DG is a wrapper for the public key, where is also subject details, certificate's issuer or guarantor.
• Digital certificates are based on the X.509 standard approved by the International Telecommunications Union and standardized by the Internet Engineering Taskforce (tools.ietf.org/html/rfc5280). PGP uses its own certificate standards.
• In general the digital certificate is created using CSR.

Certificate Signing Request - CSR

• When a subject wants to obtain a certificate, it needs to generate the special request and submit it to the CA. The applicant applying for the certificate is called as certificate signing request - CSR.
• The CSR is a Base64 ASCII file containing the information that the subject wants to use in the certificate, including its public key. Information such as :
• Fully qualified domain name
• City, state, country
• Email address
• The CA reviews the certificate and validates that the information is valid. 
• If the request is accepted, the CA signs the certificate and sends it to the subject.

Certificate Policy

• A certificate policy applies the rules to be certificate.
• Different certificate serves different purposes, will see that below for now eg: email, code signing.
• Information within certificate policy includes such as:
• Key management requirements
• Lifetime of the certificate
• Rules for exporting the private key
• Private and public key minimum lengths

Certificate Attributes

The X.509 standard defines the attributes that needs to be present in the certificate.

Fig: Example certificate attributes

• Serial Number
• Unique number identify the certificate within the domain of its CA
• Version Number
• Version of X.509 standard the certificate complies with
• Signature algorithm
• Algorithm used by the CA to sign
• Issuer
• Name of the CA which has signed this certificate
• Valid from/to
• Validation period of the certificate, ofter is set to 1yr
• Subject
• Name of the certificate holder
• Public Key
• Holds Public Key and other information as well, key size, algorithm, etc
• Extensions
• X.509 Version 3 optionally provides certificates provision to define additional/extended attributed such as email, algorithms, intended key usage
• Signature Value
• Provides to digital signature, ensures the validity of the certificate 
• Subject alternative name - SAN
• Initially certificates used to validate CN attribute to identify the FQDN by which the subject is accessed such as www.google.com.
• Now SAN extension field is preferred mechanism to identify DNS or names of the host it is identified. 
• If the value is present in SAN the subject (eg: browser) should validate it ignoring CN.
• Below is the SAN values are provided in the google certificate,
• But the challenge with this approach is if new domain is added, new certificate needs to be issued. Whereas if wildcard is preset in the SAN, such as *.abc.com the certificate issued to the parent is to accept all the valid sub domains.

Fig: SAN sample

Types of Certificates

• Domain Validation (DV) Certificate
• Providing the ownership of the particular domain, and includes only the domain name. It is highly vulnerable. 
• DV certificates are quickest and least expensive certificate to acquire.
• Organization Validation (OV) Certificate
• Provides stronger assurance the DV, here verification is done manually to verify the organization and takes time to be issued.
• Extended Validation (EV) Certificate
• Provides verified owner details, and in green in padlock.
• Rigorous checks performed on the subject.
• EV certificate can't have wildcard domain.
• EV certificates are designed to provide assurance against phishing attacks.
• Here this is also takes time to be issued, after validation.
• Server Certificate
• Part of web server certificate, guarantees the identity and data should be valid and confidential.
• Machine Computer Certificate
• Certificate issued to machines/servers/routers/switches.
• Can disallow to the machines without valid certificate in the network. 
• Email Certificate
• Certificate issued to decrypt and encrypt messages, used but the secure layer protocols such S/MIME, POPv3S, PGP, IMAPS and so on.
• Code Signing Certificate
• Software publisher uses this certificate to verify source code.
• Root Certificate
• One use to identify itself root.
• Having usually the key size from 2048 bytes to 4096 bytes and more.
• Self Signed Certificate
• Creating certificate for themselves, but usually not trusted and used for testing purpose. 
• User Certificate
• Identifies individuals, also known as client certificate, works similar way as passwords works.

Certificate Formats

• DER - Binary format of the certificate
• PEM - Binary data represented in ASCII text format using Base64 encoding, generally used.

Credits: https://i.stack.imgur.com/9mPIB.png

• CER - Used in windows, file extension with *.cer. Not a standard form.
• CRT - Used in linux, file extension with *.crt. Not a standard form.
• PKCS - Binary certificate, the contents of the file with this extension holds more than one certificate. Usually these files are and need to be password protected. In windows this are created with .PFX extension and in Mac or iOS it is with .P12 extension. In linux keys are stored in separate files. The use of this file is to transfer keys or backup.
• P7B - Similar to PKCS but stores the information in the ASCII format and doesn't contain primary key. Usually used in chain of trust or secure email.
• KEY - Only when the file holds primary key.

Key Recovery

• Private keys should be shelved with highest security with minimal access controls.
• One of the common way the access provided to use the key is M-of-N control, here the N number of admins are permitted to access and M should be present to provide the access. 
• The key also is needs to be backed up, if lost the access of the encrypted information would be become serious.
• Also key backup increases the complexity of making it secure.
• Key recovery defines of secure way to save backups, to retrieve key when lost. 

Key Escrow

• Key Escrow, here the private keys associated with public keys are archived and secured by the third party.
• Here the complete control is provided to the third party, to perform actions on behalf of the users.
• It would lead to harmful results if misused.
• Though it point to debate, organizations use this as it has full control on the information at rest or in transit.

Certificate Revocation Lists - CRL

• Certificates can be revoked or suspended for various reasons such as  if compromised or not it use or not needed now.
• Suspended keys is given a code Certificate Hold.
• CA maintains the list of all these suspended, revoked certificates to avoid usage.
• Any validation of certificates does a precheck if they exist here, if yes its not taken further and returns with error.
• CRL is a mechanism for distributing the certificate revocation information. This needs to be updated constantly with the latest revoked details, usually 2 weeks once.

Online Certificate Status Protocol - OCSP

• Alternate way of CRL is OCSP servers, here instead of the validating against whole set, the requested certificate status is just communicated.
• Most OCSP servers can query the certificate database directly and obtain the real-time status of a certificate. 
• Other OCSP servers actually depend on the CRLs and are limited by the CRL publishing interval, which at times holds not the up-to-date information.

OCSP Stapling

• One of the issue with the OCSP server is it requires to server heavy load of the request responses, also it can record the requests asked from the clients leading to privacy issues.
• OCSP Stapling resolves these by SSL/TLS server periodically obtain a time stamped OCSP response from the CA. 
• The OCSP stapling process involves the following steps:
• A TLS-encrypted web server presents its certificate to the CA to check the validity.
• The CA responds with the certificate status, including a digitally signed time stamp.
• The web server staples the CA’s signed time stamp to the certificate when a client web browser connects.
• When the client makes a OCSP request, the server returns time stamped response rather making the client talk to the OCSP server itself.
• The client web browser verifies the signed time stamp
• The privacy issue has been reduced here, as the browser does not needs to contact the 3rd party or even to say internal CA and reveal the browsing history.

Certificate Pinning

Credits: https://labs.nettitude.com/wp-content/uploads/2018/03/word-image.jpeg

• There is possibility of using the compromised certificate which could lead to man in the middle - MITM attacks.
• Certificate pinning extends beyond certificate validations to avoid MITM attacks
• Pinning refers to the techniques used to make sure client inspects the proper certificate.
• This could be achieved either embedding the certificate along with the data so that we can decrypt and then validate the public key or using more than one public keys. 
• A similar (though now deprecated) variation, known as HTTP Public Key Pinning (HPKP), used public key pins, which are essentially hashed values of the public key communicated to the browser client from the server in the HTTP header. After obtaining the server certificate, the client verified the public key against the hash of the public key. Found the below image to which matches the concept.

Credits: https://www.mdpi.com/entropy/entropy-21-01136/article_deploy/html/images/entropy-21-01136-g002.png

OpenSSL

• Using the openssl command we can manage the CA services such as:
• create the public and private key
• configure root CA
• configure certificate to host
• create CSRs
• key and certificate management

PKI Issues

• Increases the operational cost maintaining this infrastructure.
• Need to maintain the synchronization in times between server and client, if the client or server rejecting the certificate.
• Overhead of the maintaining the keys securely, and disposing them carefully only after decryption.
• Constant involvement of efforts, in validation if the keys are compromised or if algorithm needs to be changed or CRL list too long.

References and Credits:

https://ssd.eff.org/files/2018/05/14/16_0.png

Comptia Security+ Course materials