Currently, many virtual private networks (VPN) are showing limited because of the security system is too simple. In this article we will discuss some of the modifications needed to meet the requirements for developing a large, high-security virtual private network. Most virtual private networks today are being exploited without the support of a public key infrastructure (PKI). Endpoints of these VPNs (secure ports or clients) authenticate each other through the establishment of IP "tunnels". In the simplest of ways, this can be done by setting the configuration at both ends of the VPN tunnel to share a common secret - a pair of passwords. This "rudimentary" solution can work well in a small VPN, but it becomes unwieldy and difficult to control in a large VPN when the number of access points reaches hundreds or even thousands of points. . Let's compare it to a small club, where everyone knows each other because of the low number of people and they know each other a lot. It is not difficult to memorize the names and identities of the members in a small group. But with a club with more than one member, it's definitely a membership card. New members can prove who they are when they present their membership card. With this "infrastructure", two completely unfamiliar people can identify and trust each other simply because they believe in each other's membership cards. Likewise, two VPN endpoints can authenticate each other through an electronic certificate - a kind of "electronic membership" that is indispensable in large VPN networks. So why does not every major VPN network now use electronic certificates? Because large network deployments require not only e-certification, but also the requirement to build a complete infrastructure including: the provision of electronic certificates, the means of guaranteeing the creation and delivery of them, Easy access to validate. In short, that's the public key infrastructure - PKI. What is a public key and what is the effect? To understand the requirements and requirements of PKI, we need to know some basic knowledge of public key cryptography. This system is based on a pair of mathematically related keys in which a key is used to encrypt the message and only one key decrypts the message and vice versa. Then we can publicize a key in the key pair. If anyone needs to send us a guaranteed message, they will be able to use this publicly provided key to encrypt the message before sending it, and because we have kept the secret key remaining, Only we can decipher the guarantee message. This key pair is also used to confirm the message. The sender creates a hash of the message - a reduced form of the original message - with some algorithms (eg MD5, SHA-1 ...). The sender encrypts the code with its own key, and the recipient uses the sender's public key to decode the sender's code, then compares it with the received code of the received message (created by same algorithm). If duplicate, the recipient may believe that the received message has not been altered during transmission on the network and originates from the specified sender. This is called an electronic signature. But again, we require not just signatures - we need an electronic membership card. That is why the concept of electronic certification appears. An electronic certificate attaches the name of the member or device to a pair of keys, similar to the membership card that imprints the member's name with their signature and photo. To ensure that the certificate is valid, we usually require the certificate to be issued by a trusted organization. For electronic certificates, this organization is called the CA Certification Authority (CA) How VPNs use electronic certificates? When the IP tunnel is initialized, endpoints authenticate each other through electronic authentication. For example, security gateway X will self-certify and sign (electronic) message with its own encryption key. The security gate Y will receive them electronically from X and use the public key of X to check the digital signature. If correct, security port X is validated because the electronic signature can only be generated by a private key that is associated with the electronic certificate of X. Why is the electronic certificate more extensible than the shared security key? Obviously, we no longer need to provide shared key pairs for each pair of VPN devices. Each VPN device only needs one electronic certificate. And we do not need to re-configure all the existing points of the VPN each time we open a new point. Instead, we can certify each device through a public folder system - for example through LDAP. Furthermore, we can combine two existing VPNs through collaboration between two CAs in database exchange and in the issuance of certificates. It is the same as recognizing another country's passport as a valid proof. As with passports, each electronic certificate must have a valid deadline and may be revoked by the issuer when necessary. Presenting an electronic signature related to an invalid, non-existing or revoked electronic certificate will result in unsuccessful access. This problem can become complicated if the examiner (receiver) does not regularly check the validity of the certificate at the CA. Even if the inspection was carried out, the list of revoked electronic certificates could be "obsolete". Do you need to check these listings monthly, weekly or daily, every hour? This is a matter of fact when applying the security policies of each specific network administrator. Components of PKI VPN is not the only PKI application security service. There are many other security requirements that can be met with the use of PKI such as email-secured with S / MINE, Web transactions secured with SSL, etc. That bridge may be different due to the nature of each service or application, all based on a "Public Key Infrastructure - PKI" that includes the basic components as shown in Figure 1- Building the Key public PKT The foundation of PKI is CA. CA issues electronic certificates. It may belong to a particular business or to an organization outside of the enterprise (specializing in providing services in this field). CAs can delegate trust to each other through hierarchical architecture. The root CA is the CA that directly provides the certificate to the enterprise. The CA is the CA that is recognized indirectly through its relationship to the CA. The root CA can be implicitly recognized (for internal enterprise). Dependent CAs are recognized through the CA's root certificate and create a chain of trusted CAs. Each time a new electronic certificate is generated, a pair of encryption keys is issued to each entity - VPN device, Web server, e-mail user ... The entities that will hold the private key ( private key) used to generate electronic signatures. The public key, the name of the entity, the name of the issuing CA, all will be gathered in the electronic certificate, and all will be confirmed through the CA's own electronic signature. For the sake of avoiding the non-recognition of each entity, only themselves will be able to use the private key. By doing so, the entities can not deny having "signed" the message because no one else can "sign" like that. It is for this reason that this private key needs to be kept secure. When this code is revealed for some reason, the electronic certificate must be revoked. For distribution convenience, certificates are usually published through a credential system. To improve access, search and security of the system, certificates in credentials are often published in multiple shadow directories. Due to the design requirements and actual needs, both CAs need to be well secured, so these two components are often separated not only by logic but also by physical separation. The management authority is assigned to RA - the Registration Authorities component. RA is responsible for administering signatures, initiating or storing key pair pairs, certifying entities in the signing period, requesting CAs to grant certificates, transferring keys to entities, initializing or revoke the electronic certificate. Remote Access CA is a very effective CA support mechanism, and as such, security requirements, RA and CAs are also physically separated and handled by different network administrators. Responsibility. These are the components of a PKI system. In addition, in practice there may be some additional components and services in the PKI or related to the operation of the PKI, as well as not all PKIs that have such basic components. We also have two options for deploying PKI: Using services from a vendor or building your own. Use PKI from your service provider On the Internet there are many PKI infrastructure providers who will sell electronic certificates. Here is a list of some of these providers. Again, if you want to build a VPN using electronic certificate authentication, all entities in your network need to be certified and if the network is too large, the cost of acquiring the certificate Received from the supplier will be no small. Then it is necessary to develop proper administration, administration and security policies. Another point to note is that you should select a supported VPN provider for your VPN device. Build your own public key infrastructure If you choose your own PKI option, here are some commercially available products that you can reference. Different products have different characteristics, and the most important thing to understand is that buying a software product that supports PKI is just a small part of the total cost of building a PKI. Choose a team of consultants to develop a PKI security and architecture policy that fits your needs and needs in the future. Most of the companies listed above can help you with that planning. Conclude The public key infrastructure will play an important role in building successful large VPNs. Whether you are a business looking to build a VPN or a service provider looking to offer VPN services to your customers, now is the time to start researching. PKI. The initial products and services are ready and you can start getting familiar with this technology. Make sure that most of us will see the importance and effectiveness of researching and deploying this technology. Nguyen Duc Kien (Head of Support Station VDC1)
