PKI offers a higher standard of security for organisations than password authentication can. PKI, or public key infrastructure, uses Secure Shell to authenticate logons and privilege users accordingly.
This added security allows for a safer transfer of information and data over cloud-based services and the Internet of Things. PKI is a multi-factor method of authorisation and accessibility employed by organisations looking to further security within their public and private exchanges. PKI requires a root certificate coupled with an issuing authority connected to that certificate.
Pros of Public Key Infrastructure
Initially the cost of PKI turned many organisations off implementing the service. However nowadays there are many outsourcing options available. PKI is an attractive security solution for many reasons, one being the reality of non-repudiation.
algorithms to match user keys and allow access across platforms. This creates a user-friendly experience within organisational hardware and software.
Cost Effectiveness: While for some that initial cost did seem jarring, in the the long run PKI’s fixed algorithm makes things much cheaper for organisations.
Government approved: PKI is often used by federal organisations. These organisations often consider PKI to be strategic to their security goals. Defence, health and banking also rely on PKI for authentication and authorisation.
Cons of Public Key Infrastructure
One of the biggest cons of PKI is the amount of resources it takes to get started. PKI can be an expensive overhead, and while it can be outsourced, policy drafting and assigning and training administrative users can be ongoing, time-consuming and costly.
It’s this overhead that has caused the explosion of PKIaas (PKI-as-a-service) offered by companies that create PKI solutions. This allows for an organisation looking to implement PKI to purchase an externally managed PKI solution without having to create their own.
Managing PKI certificates can be challenging due to overhead. Using HTTPs communication requires some overhead and could be considered a con for smaller organisations.
You may be required to import CA root certificates as a site property when using the Configuration Manager you may find that operating systems will only accept HTTPs client connections. Other scenarios can also result in a necessary CA root certificate import.
The nature of PKI can make it difficult for small organisations to implement effectively without properly trained administrators.
Other mistakes to avoid when using Public Key Infrastructure include:
Use of Older Algorithms – The use of older algorithms where support for newer algorithms is available, can be problematic and allow attacks where bad actors can compromise fraudulent certificates. The SHA2 family was designed by the NSA to overcome the potential breaks in SHA1. SHA2 is considered more secure than SHA1 because of this. When it comes to ECC versus RSA the biggest difference is key size compared to cryptographic strength.
Not storing your Root CA offline – Root certificates should be kept in an offline state where possible. Your Offline certification Authorities will depend on your hierarchy. Hierarchy is divided into tiers, these can operate at 2 tier, 3 tier, or higher. The hierarchy you decide to operate with, will articulate how many offline CAs you work with. A 3 tier hierarchy will need at least 2 offline CAs, a 2 tier hierarchy will need one offline CA.
Not using Hardware key protection for Certification Authorities – Hardware key protection is always recommended to be used to protect the private key of the CA. Attachment can be created via a network, or directly attached to the CA.
Not using validation authority services such as OCSP – Security architects and PKI implementors in the federal space should always use validation authority services such as OCSP (Online Certificate Status Protocol) responders. These responders manage authentication requests by working through CRL limitations to check the status of the certificate using the serial number presented by the client.
Using CRLs that are too long – Revoked certificates cause the CRL to grow. Expired certificates are typically not stored in the CRL. You can keep your CRLs at a manageable length by giving certificates shorter lifespans according to your turnover needs.
Generating keys centrally – A compromised key = game over! Keys need to be protected. Keys should be generated using a suitable random number generator at the end of PKI development.
Cogito Group is an award-winning cybersecurity company specialising in authentication, cloud security, identity management and data protection. Cogito Group protect the authentication methods used to access information through the use of Identity and other security technologies.
