The use of a Public Key Infrastructure (PKI) by an organization demonstrates a dedication to the security of the network and the effectiveness of public key encryption and certificate-based networks. The purpose of a PKI is to manage the public keys used by the network for public key encryption, identity management, certificate distribution, certificate revocation, and certificate management. Once enabled, users who enroll for a certificate are identified for later authentication or certificate revocation. The PKI allows users and systems to verify the legitimacy of certificate-holding entities and securely exchange information between them over the air. The introduction of a PKI enables stronger, certificate-based security, as well as identity services and management tools to maximize network efficiency and security.
Table of Contents
- What are the components of a PKI?
- What can a PKI be used for?
- Does SSL Inspection use a PKI?
- Does EAP-TLS use a PKI
- What are examples of a PKI in use?
What are the components of a PKI?
The components of a PKI include the public key, private key, Certificate Authority, Certificate Store, Certificate Revocation List, and Hardware Security Module.
A public key system relies on asymmetric cryptography, which consists of a public and private key pair. The Certificate Authority (CA) certifies the ownership of the key pairs and completes the PKI setup.
A Public Key is a cryptographic key that can be distributed to the public and does not require secure storage. Messages encrypted by the public key can only be decrypted by the corresponding private key.
Private Keys are used by the recipient to decrypt a message that is encrypted using a public key. Since the message is encrypted using a given public key, it can only be decrypted by the matching private key. This establishes the ownership of the private and public key, ensuring the message is only read by the approved parties.
Certificate Authority (CA)
A CA issues certificates to be used to confirm that the subject imprinted on the certificate is the owner of the public key. In a PKI system, the client generates a public-private key pair. The public key and information to be imprinted on the certificate are sent to the CA. The CA then creates a digital certificate consisting of the user’s public key and certificate attributes. The certificate is signed by the CA with its private key. Once the certificate is distributed to the user, they can present the signed certificate and the receiver can trust that it belongs to the client because of the matching public-private key pair.
Root Certificate Authority
A Root CA is a trusted CA that is entitled to verify the identity of a person and signs the root certificate that is distributed to a user. The certificate is considered valid because it has been verified and signed by a trusted root CA.
Intermediate Certificate Authority
An Intermediate CA is also a trusted CA, and is used as a chain between the root CA and the client certificate that the user enrolls for. Since the root CA has signed and trusts the intermediate CA, certificates that are generated from the intermediate CA are trusted as if they were signed by the root CA. SecureW2’s PKI always uses the intermediate CA to generate client certificates for Wi-Fi authentication, as it’s a best practice. SecureW2’s intermediate CA can never be compromised, since a hardware level of encryption is used for the private key of intermediate CAs.
Certificate Revocation List (CRL)
A CRL is a list of certificates that have been revoked by the CA that issued them before they were set to expire. Those that owned a certificate that was revoked are no longer granted secure network access with that organization. There are two types of CRLs: Delta and Base. A base CRL is a large file containing all revoked certificates. This file is published and updated at infrequent intervals. A delta CRL is a small file containing the certificates that have been revoked since the last base CRL was published. When the base CRL is updated, the certificates are moved from delta to base.
A Certificate Store is used to store certificates and can potentially contain certificates from multiple CAs. For example, different Windows certificates are stored in the certificate store and can be viewed using MMC snap-in, while in macOS, certificates are stored in the keychain.
Hardware Security Module (HSM)
A Hardware Security Module isn’t a mandatory component of a PKI, but it improves the security of the PKI as a whole when implemented. This device protects and manages digital keys and serves as the groundwork for building a secure enterprise PKI infrastructure. The HSM contributes to managing the complete lifecycle of cryptographic keys, which includes creation, rotation, deletion, auditing, and support for API’s to integrate with various applications.
What can a PKI be used for?
A PKI has a multitude of uses, but how your organization designs it depends largely on what your security needs are, which vendor you choose, or if you decide to construct your own. The most common applications of a PKI include Wi-Fi authentication, web application authentication, email security, and VPN. Below we’ll demonstrate how each is tied to the PKI.
Users with a certificate signed by the trusted CA can connect to the secure SSID and be authenticated by the RADIUS server using EAP-TLS. EAP-TLS authentication encrypts data sent through it and protects from over-the-air attacks. The certificate is sent and the RADIUS confirms their identity, establishing trust that grants secure network access.
Web Application Authentication:
Similar to Wi-Fi authentication, a user connecting to a web application will have their identity confirmed by the web application server. Since the certificate is signed by the trusted CA, they are able to gain access to the application.
Certificates can be used to authenticate users for VPN access. Since VPNs can grant access to critical information, certificates are a preferred method of authentication over passwords. Usually the Root/Intermediate CA is stored on the Firewall and once the user is authenticated, a secure tunnel is created to access the network the user is trying to access.
Encrypting emails with certificates utilizes the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol. Both the receiver and sender are required to have a certificate signed by the CA to establish trust between the users. S/MIME provides the cryptographic security required to guarantee the origin of the message with the digital signature from the certificate, encrypt the message, and authenticate the recipient’s certificate to decrypt the message. If you’d like to learn more about how this protocol protects the integrity of internal communications, learn more here.
Does SSL Inspection use a PKI?
An SSL certificate is used to ensure that there is an encrypted connection for online communications with a secured website. SSL certificates are installed in the certificate store of the PKI and decrypt HTTPS traffic to maintain network visibility for administrators.
Does EAP-TLS use a PKI?
The EAP-TLS authentication method does use a PKI. EAP-TLS is a WPA2-Enterprise network protocol that is used for encrypted, certificate-based authentication. As a user connects or enrolls to the secure network, EAP-TLS authentication confirms the identity of the user and the server in an encrypted EAP tunnel that prevents outside users from intercepting credentials or other information sent over-the-air. They can safely transmit data through the tunnel, resulting in a fast, secure, and successful authentication.
What are examples of a PKI in use?
The physical installation of a PKI to existing infrastructure is a common method of deployment. The setup process involves the setup and configuration of all the PKI components, as well as ongoing maintenance and a requirement to store it in a secure area to protect against a physical breach. Maintaining strong security around the PKI is of utmost importance. If the public key or Root CA is compromised, every certificate would be at risk and need to be replaced and the organization would be highly susceptible to data theft. The term for responding to such an event is Disaster Recovery, and restoring a local PKI can be an intensive process.
A cloud PKI solution, like the PKI offered by SecureW2, requires no forklift upgrades to integrate directly with existing infrastructure. IT need only connect the PKI to the network and configure the settings and onboarding software to distribute certificates. Since the PKI is externally hosted, the responsibility of maintaining and securing the PKI falls to the vendor. A cloud PKI also has strong scalability, so as an organization grows, they do not have to consider how to accommodate the new users as you would with a local PKI. The costs over the lifetime of a cloud PKI are significantly lower than the costs of a local PKI because of the lack of traditional costs, such as the installation or on-premise security.
In conclusion, the configuration of a PKI on your network brings stronger security and the tools to simplify and expand the network management scope. Users outfitted with certificates and browsing on the secure network are protected from all manner of over-the-air attacks. The network admins are saved from manually configuring each device for certificates, and they can easily monitor network activity, investigate connection issues, and revoke certificates when they are no longer needed. A PKI provides straightforward solutions to many problems and inefficiencies faced by all organizations with unsecured wireless networks.