How a VPN Fits into a Public Key Infrastructure
Introduction
Before our series on the Virtual Private Network Infrastructure, we had also written a series of articles on the science and technology of Cryptography. Essentially, this is a sophisticated way in which to scramble a text message, also known as a "Plaintext." Once this message has been converted over to its garbled format, this becomes known as the "Ciphertext." This specific process is known formally as "Encryption."
However, to scramble the text (which originates from the sending party) and to descramble it (when the Ciphertext reaches the destination party), a tool as "Keys" must be used. In its simplest form, only one set of keys are needed, and these can be referred to as the "Private Keys." One key is used to scramble the Plaintext, and the other key is used to descramble the Ciphertext.
Earn your CISSP, guaranteed!
Although the primary advantage of this is that it is very simple to use, there is one primary caveat to it: The secrecy of these Private Keys must remain within the sending and the receiving parties. If this is compromised in any way, or if the secrets of the Private Key are revealed to an outside third party, then the point of Encryption becomes totally meaningless, as anybody at this point can decipher the Ciphertext.
This kind of structure where only one set of keys are used is known in technical terms as "Symmetric Cryptography." To combat this major security vulnerability, a different version has been introduced, which is known as "Asymmetric Cryptography." As its name implies, there are two different kinds of keys which are being used.
This is known as the "Public Key and Private Key" combination. In other words, one separate key is used to encrypt the Plaintext message into the Ciphertext (this is usually done by the Public Key), and the other, separate key is used to descramble the Ciphertext (this is usually done by the Private Key).
By using this type of specific key combination, an extra layer of security is thus afforded, with the use of the Public Key. However, however, it should be noted that the Public Key is available for anybody to use, it is not just specific to any one entity.
Because of this, there is still one major flaw of Asymmetric Cryptography which remains, and in fact, it is still the same one as the Symmetric Cryptography approach: That is, the Private Key still must remain a secret between the sending and the receiving parties.
Once again, if this is every compromised in any way, then the Ciphertext can be decrypted very easily and very quickly. As a result of this, a newer approach to encrypting and decrypting Plaintext and Ciphertext messages was created, which is specifically known as a "Public Key Infrastructure," or "PKI" for short.
With this newer methodology, there are more mechanisms which are now in place to secure only the Plaintext and the Ciphertext messages, but also even the Public Key/Private Key combinations as well. This type of infrastructure allows for the multiple sending and receiving parties to exist. Our previous examples only used one sending party and one receiving party.
One of the main issues of Cryptography is ensuring the validity as well as the integrity of the Public Key/Private Key combinations. For example, how does one know if a key is genuine and authentic? Also, how does one know that the integrity of the key has not compromised by an outside third party?
These issues have been resolved by what is known as a "Certificate Authority," also known as a "CA" for short. This is a trusted, third-party mechanism which creates, manages, and distributes the various Public Key/Private Key combinations which are issued. By doing so, the integrity and the secrecy of the keys can be maintained from within the Public Key Infrastructure itself.
Also, the use of Virtual Private Networks can be used in a PKI as well, thus even adding an extra layer of security as well. With this specific mechanism, the communication channels between the sending and the receiving parties are also "layered" amongst one another.
This simply means one line of communications remains publicly open on the Internet, while the other line of communications is "hidden." This is where the associated Data Packets from the corresponding Ciphertext messages traverse upon.
This article examines how a Virtual Private Network Infrastructure can fit into a PKI, by examining the following topics:
- Managing the Public and Private Key Exchanges;
- The Access Control List.
Managing the Public and Private Key Exchanges
One very important aspect to remember about the procurement and deployment of a Virtual Private Network Infrastructure is that of the of the Key Exchange mechanism when the VPN being implemented into a PKI.
Managing the Key Exchange mechanism comes in three different types of methodologies:
-
The Manual Key Exchanges:
With this type of mechanism, a VPN administrator must manually configure each VPN system with its own set of Public Keys and Private Keys. Also, this configuration includes the interoperability of the Public Key/Private Key combinations with other Virtual Private Network Infrastructures. The primary disadvantage with this methodology is the sheer lack of scalability.
-
The Simple Key Interchange Protocol, also known as "SKIP":
This protocol is only available highly commercialized applications and implementations of a Virtual Private Network Infrastructure.
-
The ISAKAAMP/Oakley Protocol:
The ISAKAMP is the de facto standard for the IPv6 network VPN based protocol. It creates the framework for both the Public Key and the Private Key Management. This type of Virtual Private Network Infrastructure Protocol does not create the Public Key/Private Key combinations, rather, it is used with the Oakley Network Protocol to produce and establish the Public Keys and the Private Keys for the VPN system.
It is important to note that a key principle to fortify the security for the Public Key/Private combinations is to administer the remote Virtual Private Network Infrastructure Gateways centrally and to ensure that the interface to the VPN software is not available on any other type or kind of network interface or device.
The Digital Certificates are a very important component of the Cryptographic portion of a VPN system. Moreover, they also play a very crucial role with the with the Public Key/Private Key combinations as well.
Since the primary function of a VPN is to filter in and out both the "good" and "bad" data packets, these same types of Digital Certificates can be used to control access to all of the primary servers at the business or the corporation.
The Access Control List
The governing of the actual Public Key/Private Key combinations is done via the Access Control Lists, also known as the "ACL" for short. Essentially, this correctly identifies the list of approved end users (such as the employees) who are allowed to be issued these Digital Certificates.
In fact, the Digital Certificate can even be used as a proxy for the corresponding username and password for each and every employee in the corporation or business. To make this happen, these Digital Certificates are associated with the Access Control List. They are logically mapped to it, and thus, can be used to determine and ascertain the rights and privileges of each and every end user.
To make this process happen, the following process must be utilized:
- Have the Access Control List direct each end user to brand new Digital Certificate for each separate site access.
- The end user may have to select a new username/password combination.
- The end user can then log back into the Virtual Private Network Infrastructure, and from there, the Digital Certificate is then mapped each end user's brand new username/password combination.
However, it is important to keep in mind that that as the access rights and privileges of the end users change over a period of time, then a new Digital Certificate will have to be issued. This can be a huge administrative overhead and burden, as a result. To avoid from having to engage in this manual process, a Secret Key, known as the "X.509", can be deployed and issued.
To accomplish this task, this methodology must be adhered to:
- Generate a random X.509 Private Key.
- Because the Digital Certificate is already embedded into the Virtual Private Network Infrastructure, a challenge/response system is also needed.
- Once this challenge/response system has been successfully implemented in the IT environment, it can then create its own challenge and automatically assign the end result, which will then use the Private Key that is associated with the X.509 Digital Certificate.
- The signed end user Digital Certificate is then sent back to the servers which reside in the Virtual Private Network Infrastructure.
- The verification of the end user's Digital Certificate is then performed.
- If the Digital Certificate is proven to be valid, the end user's challenge is then checked, utilizing the Public Key in the end user's own Digital Certificate.
- If the Digital Certificate is proven again to be valid, the resultant challenge is then checked against the original challenge to ensure that they match.
- If this particular challenge matches all of the previous steps just detailed above, then the information/data can be extracted from the Digital Certificate number. As a result, this can be used to as a lookup into the various Access Control Lists that contain those particular end user's access rights and privileges.
Conclusions
In summary, this article continues our theme of the Virtual Private Network Infrastructure. As it was eluded to earlier in the article, Cryptography is one of the primary means in which a business or a corporation can fortify their lines of defense.
However, this methodology, too, has its limitations, especially if either a Symmetric or an Asymmetric Cryptographic approach is used.
Although both of these approaches do offer reasonable levels of Encryption, their main Security flaw lies in the secrecy of the Private Key. If this released to the public, then the Ciphertext can be decoded very quickly.
An alternative to this is the Public Key Infrastructure (PKI), which has, even more, mechanisms in place to protect the integrity of the Public Key/Private Key combinations.
In addition to this, a Virtual Private Network Infrastructure can fit very readily into a PKI, thus offering even greater levels of Confidentiality, Authorization, and Integrity (this is very often referred to as the "CIA").
This article has reviewed in detail as to how a VPN can work in this regard, by focusing on the management of the Public Key/Private Key Exchanges, and properly configuring the Access Control List(s).
Earn your CISSP, guaranteed!
Our next article will conclude our in-depth examination of the Virtual Private Network Infrastructure, by examining the related Internet Drafts and the major Security vulnerabilities of a VPN.
Resources
- http://www4.ncsu.edu/~kksivara/sfwr4c03/projects/4c03projects/JPatel-Project.pdf
- https://www.cl.cam.ac.uk/~rja14/Papers/IEEE-PSCE-1.pdf
- https://www.snia.org/sites/default/files/Hubis-W_Introduction_to_Key_Management.pdf
- http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf
- https://www.emsec.rub.de/media/crypto/attachments/files/2011/03/soenmez.pdf
- http://www.cisco.com/c/en/us/support/docs/ip/access-lists/44541-tacl.html
- https://support.sonicwall.com/kb/sw3884
- https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-acl
- http://www.routeralley.com/guides/access_lists.pdf
- http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_overview.pdf
- http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/configuration/firewall/asa-97-firewall-config/access-acls.pdf
- http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/acl_overview.pdf
- http://files.bluecrow.net/docs/CCNA%20PDFs/CCNA%20CH22%20-%20Access%20Control%20Lists.pdf