Group 1: Leo Choi, David St Louis, Nina Undug, Janelle Wiebe & Jamie Wong
Many business operations employ public-key cryptography to uphold client privacy rights during the transportation of sensitive data. In public-key cryptography, messages are encrypted using the receiver’s public key, which is publicly available. Consider the following man-in-the-middle attack that may result from such a protocol:
Public Key Infrastructure (PKI) was developed to address this issue. PKI consists of hardware, software, and administrative “elements that a trusted third party can use to establish the integrity and ownership of a public key.” [1] PKI seeks to ensure that public keys are bound to the entities that claim to own them.
PKIs are typically comprised of the following components [1, 2]:
- Digital Certificate: An electronic document that proves the identity of the entity claiming to own a public key. [1]
- Certificate Authority (CA): The root of trust in PKI that provides the services that authenticate the identity of individuals, computers, and other entities. [1]
- Registration Authority (RA): An authority that is certified by the CA for specific uses determined by the root. [1] They are authorized to provide digital certificates on a case-by-case basis. [2]
- Certificate Database: The place where certificate requests, issued certificates, and revoked certificates are saved on the CA or RA. [1]
- Certificate Store: The place where issued certificates and pending/rejected certificate requests are saved on the local computer. [1]
- Key Archival Server: The place where encrypted private keys are saved in the certificate database for backup. [1]
There are two main configurations of PKI: public and private. Public PKI is typically used for public domains and web servers where information is transmitted over the Internet. It is managed by a CA.
Private PKI is typically “used to authenticate entities on an internally hosted service, like a VPN.” [3] It is a system that manages the creation, distribution, and storage of digital certificates for secure internal communication and data transmission within the organization. [3] Private PKI is usually managed by the organization itself or a contracted third party.
So, why implement private PKI?
- Establishing and verifying identities in a network environment is a crucial component of the overall security of the network. [4]
- The cost of acquiring certificates for network entity identification can be potentially exorbitant as many trusted certification authorities charge high prices for issuing certificates. Private PKI implementations provide organizations with a cost-effective method of accomplishing this task. [5,6]
- Incidents on compromised networks where hackers are already inside the network are on the rise. The goal is to make it harder for threat actors to get any information, even if they are already inside the network.
For these reasons, we believe that security professionals should be able implement private PKI. Our project is an interactive training resource complete with a video demonstration to educate new security professionals on implementing one-tier private PKI.
PKI can be implemented with different trust hierarchies that organizations can choose from depending on their needs. These trust hierarchies range from one-tier to three-tier architectures. Three-tier architectures provide the greatest level of protection; however, two-tier hierarchies will typically suffice for what an organization needs. [7] Due to the time limitation on this project, we implement a one-tier private PKI in our demonstration although it is not recommended in practice.
A one-tier hierarchy consists of a single CA that acts as both a root CA and an issuing CA. This hierarchy is not recommended for any production scenario because the compromise of this single CA equates to a compromise of the entire PKI. A one-tier hierarchy may be sufficient for only simple implementations where ease of management and lower costs outweigh the need for greater levels of security or flexibility. [8] The SSL or TLS handshake enables the client and server to securely communicate with the digital certificate signed by the CA. [9]
The best practices for implementing Private PKI are outlined in NIST SP 800-57 Part 3: Recommendation for Key Management. [10] A few general best practices are highlighted below:
- Block ciphers should support AES-128 (at minimum)
- P-384 elliptic curve and SHA-384 must support AES-256
- RSA keys should support three-key triple-DES for legacy system support
Our Private-PKI Implementation Guide goes into further detail on the history of PKI, how CAs verify keys, the differences between public and private PKI, use cases for private PKI, trust hierarchies, TLS/SSL handshake protocols, and common challenges with private PKI. We encourage you to voluntarily subject yourself to our detailed training resource specifically designed so that you cannot skim through the presentation – just as your employers would want! 😀
References:
[1] Microsoft. (2021, January 7). Public Key Infrastructure. Windows App Development. Retrieved January 26, 2023, from https://learn.microsoft.com/en-us/windows/win32/seccertenroll/public-key-infrastructure?redirectedfrom=MSDN
[2] Venafi. (n.d.). What is PKI and How Does It Work? Public Key Infrastructure. Retrieved January 26, 2023, from https://venafi.com/machine-identity-basics/what-is-pki-and-how-does-it-work/#item-0
[3] National Cyber Security Centre. (n.d.). Design and build a privately hosted Public Key Infrastructure. Retrieved January 20, 2023, from https://www.ncsc.gov.uk/collection/in-house-public-key-infrastructure
[4] Rose, S. et al. (2020, August). Zero Trust Architecture. NIST Computer Security Resource Center. Retrieved January 19, 2023, from https://csrc.nist.gov/publications/detail/sp/800-207/final
[5] Compare TLS/SSL Certificates. (n.d.). DigiCert. Retrieved January 19, 2023, from https://www.digicert.com/tls-ssl/compare-certificates
[6] Standard Plus OV SSL. (n.d.). Entrust. Retrieved January 19, 2023, from https://store.entrust.com/default/certificate-services/tls-ssl/standard-plus-ov-ssl.html?_ga=2.67098158.1810026480.1674151902-1295093578.1674151902&_gl=1*goqp5x*_ga*MTI5NTA5MzU3OC4xNjc0MTUxOTAy*_ga_6QRW66BW5T*MTY3NDE1MTkwMi4xLjEuMTY3NDE1MTkyMy4wLjAuMA
[7] Crane, C. (2021, December 15). PKI Architecture: Fundamentals of Designing a Private PKI System. Hashedout by The SSL Store. Retrieved January 16, 2023, from https://www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/
[8] Microsoft. (2016, August 31). Securing PKI: Planning a CA Hierarchy. Retrieved January 20, 2023, from https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786436(v=ws.11)
[9] IBM. (2022, November 30). An overview of the SSL or TLS handshake. Retrieved January 20, 2023, from https://www.ibm.com/docs/en/ibm-mq/7.5?topic=ssl-overview-tls-handshake
[10] Barker, E. and Dang, Q. (2015, January). Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance. NIST Computer Security Resource Center. Retrieved January 19, 2023, from https://csrc.nist.gov/publications/detail/sp/800-57-part-3/rev-1/final
Is it possible to know the real-life challenges to implement the method? Are there any limitations during the implementation?
Thanks Mehedi for your question. 🙂
Yes, the implementation of a private Public Key Infrastructure (PKI) within an organization can present a number of challenges and limitations. Firstly, the complexity of the task at hand necessitates a significant level of technical expertise and ongoing maintenance in order to ensure proper functioning of the system. Additionally, the design of the private PKI system can prove to be a challenge as it necessitates the balancing of multiple system functions, such as key storage, certificate lifetime, and revocation, in accordance with technology and environmental constraints. Furthermore, achieving the necessary security objectives while taking into account technology limitations can be a significant challenge in the implementation process.
The information presented is summarized from National Cyber Security Centre’s n.d. “Design and build a privately hosted Public Key Infrastructure.”
National Cyber Security Centre. (n.d.). Design and build a privately hosted Public Key Infrastructure. Retrieved January 20, 2023, from https://www.ncsc.gov.uk/collection/in-house-public-key-infrastructure
With the private PKI, does it mean that there is no need for certificates.
Thank you for your question, Oluchi. Yes, there is still a need for digital certificates in a private PKI. The main difference is that in a private PKI, the digital certificates are managed and issued internally by the organization (instead of by external certification authorities) to authenticate users, devices, and services and secure communications.
Ahh, had PKI server setup and simulation in one of Security+ PBQ exam questions. Didn’t necessarily enjoy it 🙂 Safe to say not my favorite topic but well explained though in this blog. Do you believe that the drawback of still having to rely on trust of Root CA at the end of the day will force alternatives like Identity-based Crypto and Certificateless Crypto to take over PKI infrastructure soon ?
Thank you, Nikhi, for your question. From my perspective, one way to address this criticism is to implement a private Public Key Infrastructure (PKI) system. 🙂
By doing so, the organization can manage and issue its own digital certificates, rather than relying on external root certificate authorities (CAs) in a private PKI. This allows the organization to have more control over the trustworthiness of the certificate and reduces dependency on external root CAs. Another alternative to PKI is using identity-based cryptography and certificateless cryptography, as you mentioned. These methods use identities or attributes of users, rather than digital certificates, to authenticate and secure communications. However, in my opinion, they may not replace PKI in the near future as they are still being researched and developed to address their own challenges and limitations and may not be as widely supported as PKI soon.
This is a very informative blog. My question is that how does PKI help to protect against insider threats?
Thanks, Anubhav, for your questions. From my perspective, PKI can help protect against insider threats by limiting their ability to access unauthorized systems. Specifically, by issuing digital certificates to only authorized users and devices, PKI can help organizations control and manage access to internal systems and networks, preventing unauthorized access by insiders. Additionally, by encrypting internal communication in PKI, it can protect against potential data breaches, because insiders will not be able to read the information even if they manage to intercept the communication. Moreover, it is essential to implement other security measures in addition to PKI and have comprehensive security control in place to fully protect against insider threats.
I totally agree with Leo. From this and previous classes, we know that there is no total security. Our aim, really, for implementing this kind of solutions, is to make it harder for threat actors to get information from our company until such time that we discover them. PKI helps with this in addition with other security solutions we implement to protect the organization.
I eagerly look forward to the training resource. Thank you so much for taking up an interesting concept. I am interested to know CAs share in liability, if someone is able to pull any attack (like a man-in-the-middle attack) by obtaining certificates from a CA. As we discussed in the course, the process of becoming a CA and their authentication processes might not always be regulated or reliable.
Awesome description guys, private PKI is such a engaging topic and is widely adopted by many IT businesses. With regular certificates used in HTTPS, there have been some instances where Root CAs have accidently or falsely signed malicious Intermediate CAs public keys as labelled them as legitimate. These malicious CAs would then sign anyone’s public keys (mostly evil sites) and and label those as malicious, creating this avalanche of dis-trust within the chain.
Is this type of attack possible with private PKI where the CA mis-assigns the Registration Authority and thus allows for the assignment of illegitimate public certificates for parties within the the organization?
I
Hi Teddy. Thank you for your interesting comment. It really boils down on how an organization design and manage their PKI infrastructure. Private PKIs architecture are usually tailored on the existing infrastructure of the organization as well as its goals and desire for future scalability. I would say that from experience on being an admin of PKI, we have very stringent policy and procedure on which server we assign as an issuing CA. And usually, issuing CAs are assigned from the beginning of PKI deployment and after that, root CAs are to be kept offline, so there is very little chance of accident like this from happening. If we assigned a new issuing CA, then there will be dozens of approval needed, as well as a maker/checker procedure during the implementation of request.
I guess this is the beauty of private PKI for an organization, you get to control and see everything.
As someone who has set up CA for LAN based networks both for personal monkeying around and business use its not difficult with the right understanding but can be a pain if you use too short life spans as you will just spend your poor days updating root certificates your whole day.
Since you control the CA in this situation might as well dial the encryption it up to 11 and use the highest all device can support on the network without undo impact. This is really import with RDS services and windows AD environments and can be even used for signing PowerShell script that run at boot to ensure secure code.
Its a good topic and anyone looking at understanding how CAs work its a fun weekend project.
Thank you so much for adding your personal experience Stephen. Your tips are extremely helpful as I am only learning how to set these things up for the first time through this project. I’ll make sure to keep these things in mind when I pick my weekend to really get a hang of setting up CAs!
It’s a very interesting and challenging topic and my question is that for mid-size network do you recommend two tier or three tier implementation?Because if we increase the level of complexity in implementations, we increase the risk of misconfiguration and this can lead to have some vulnerabilities.
Thanks Moein for your comment. That’s a good question, but I’m afraid there is not a one-size-fits-all answer as it may depend on the specific requirements, needs, and environment of each organization. As you know, compared to a two-tier private PKI, a three-tier private PKI can offer better security and scalability, but it is also more complex and has higher setup and maintenance costs. Therefore, I would recommend the organization conduct a comprehensive evaluation based on various factors, such as budget, technical capacity, priorities, and objectives, to determine which implementation is best suited for them.
Thanks again for your comment Moein.
To add a little bit to Leo’s response. In terms of mitigating the risk of vulnerabilities due to misconfigurations, it is crucial that we follow the best/leading industry practices that are associated with the implementations. It is also important to adopt methods that are tried, tested, and subject to the broadest scrutiny throughout the industry.
First and foremost amazing presentation of the information! I love the initial image and break of information through bullets and other diagrams, a great format that definitely keeps the reader’s attention. Secondly, what an amazing idea to have a training video that I do look forward to seeing. Will you be addressing concerns or limitations to security within the training with the implementation of a one-tier private PKI vs. a 2/3 tier?
Thank you for your nice comment Angelica! Our training resource does get into the security limitations of implementing one-tier private PKI as opposed to two-tier or three-tier. Spoiler alert: we actually mention it’s not recommended for any production scenario because the compromise of one CA equations to compromise of the entire PKI. It can be appropriate for simple implementations where ease of manageability or need to save costs outweighs the need for security. We focus on a one-tier implementation in this project mainly due to the time constraint, but the steps shown can be applied to setting up multiple tiers.
I feel like voluntarily subjecting myself to your detailed training resource *specifically* to try and skim through the presentation. I read this as a challenge!
Unlike Germany and some European countries, where the Government encourages every citizen to have their own private key issued by CAs, Canada does not have this measure. Would you think it is beneficial for the Government to encourage private key adoption for the general public? Though i see that in some countries like Hong Kong, the governments just essentially give up after their decade long effort failed to achieve critical mass in private key adoption. I think some possible explanations are the cost of certificates and the ease or difficulty to apply, use, renew them.
1. Are there statistics or quantitative research that the security levels of 3-tier over 2-tier pki are? Is 3-tier pki worth the effort and investment?
3. Are there propsed expiration lengths of 3-tier pki? Should they be the same as 2-tier pki or longer? Given that 3-tier pki should be more secure and hence longer periods are acceptable, so as to balance the costs and certificate rotation effort?