Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

The Inner Components and Policies/Rules of a Public Key Infrastructure


In today’s world, Cyber threats are an almost everyday occurrence. It is a cat and mouse game, where the victim (which is the mouse, whether it be an individual or a business/corporation) is always trying to elude away from the cat (the Cyber Attacker).

The goal of the Cyber Attacker is always to break down whatever walls of defense are in front of them, to gain their coveted prizes: The username/password combinations and other confidential information and data which can be leveraged into launching a massive Identity Theft campaign.

However, it is important to keep in mind that the weakest link in the chain that the Cyber attacker preys upon as well is the line of communication which exists between the sending and the receiving parties.

We often think that this is always safe and secure, but this far from the truth. Even communicating via a wireless protocol on your Smartphone with another entity are often being covertly snooped by the prying eyes of the Cyber Attacker.

What can be done to secure this line of communications? One of the best lines of defense is that of Cryptography. Our past few articles have reviewed the concept of this topic, both from Symmetric and an Asymmetric standpoint.

With the former, only one set of keys are used, and while this does secure the lines of communications, if these keys were ever compromised, then the Cyber attacker will have access to all of the information. The latter is much more secure because it is two sets of keys which are being used, which is also known as the Public Key/Private Key combination.

If one set of keys were compromised, the line of communications would still be secure, because there is still another key which is not known. However, the primary disadvantage here is that if this second key were to be hijacked, then the communication channel is compromised.

To combat this weakness, a specialized subset of Cryptography known as the “Public Key Infrastructure” (PKI) has been developed. Our last article examined this topic in depth, and critically examined the following concepts:

The Mathematical Algorithms Used in a Public Key Infrastructure: The RSA Algorithm The Diffie-Hellman Algorithm The Elliptical Wave Theory Algorithm An introduction to the Public Key Infrastructure which included an examination of the following sub-topics: The Certificate Authority The Digital Certificate The LDAP or X.500 Directories The Registration Authority Digital Certificates.

In this article, we continue deeper into our theme of the Public Key Infrastructure, by examining the following topics:

How the Public Key Infrastructure Actually Works; The Public Key Infrastructure Policies and Rules; The Lightweight Directory Access Protocol (also known as the “LDAP”).

For a primer article into the Public Key Infrastructure, click on the following link:


How the Public Key Infrastructure Actually Works
The Inner Components and Policies/Rules of a Public Key Infrastructure

The PKI Infrastructure can come in various configurations, which will be of course contingent upon the specific security needs of the business or corporation. However, in general, this is how a PKI is structured and set up to run:

The request for the Digital Certificate is sent to the appropriate Certificate Authority (also known as the “CA”). After this specific request has been processed, the Digital Certificate is then issued to the entity that is requesting it. The Digital Certificate then gets signed by confirming the actual identity of the person who is requesting that specific Digital Certificate. The Digital Certificate can now be used to further encrypt the plaintext into the Ciphertext that is sent from the sending party to the receiving party.

The Registered Authority (also known as the “RA”) is only an actual subset of the Certificate Authority; or rather, it is not intended to replace or take over the role of the Certificate Authority. Instead, it is designed to help out if the Certificate Authority if it becomes too bogged down with request traffic for Digital Certificates.

However, the Registered Authority itself does not grant any type or kind of Digital Certificate, nor does it confirm the identity of the person or entity who is requesting it. Rather, its specific role is to help process the requests until the processing queue at the Certificate Authority becomes much more manageable.

The Registered Authority sends all of the Digital Certificate requests in one big batch, rather than one at a time. This process is known specifically as “Chaining Certificates.” The Registered Authority is typically found in very large, multinational businesses and corporations.

In these instances, each branch office would have its own Registered Authority, and the actual Certificate Authority would reside at the corporate headquarters.

Finally, all Digital Certificate requests that are processed by the Registered Authority are also associated with a Chain of Custody Trail, which is used for auditing purposes. In the end, the Registered Authority can be viewed as a support vehicle for the Certificate Authority in which a hierarchal mathematical relationship exists.

The Public Key Infrastructure Policies and Rules
The Inner Components and Policies/Rules of a Public Key Infrastructure

It should be noted that for either the Certificate Authority or the Registered Authority to function properly, it is important to have a distinct set of rules and policies in place. These surround the use of the issuance, storage, and the revocation of the expired Digital Certificates. Although it is out of the scope of this article to get into the exact details of all of these rules and policies, the following is just a sampling of some of the points which need to be addressed when a Public Key Infrastructure is deployed:

Where and how the records and the audit logs of the Certificate Authority are to be kept, stored, and archived. The administrative roles for the Certificate Authority. Where and how the Public Keys are the Private Keys are to be kept, stored, and also backed up. What the length of time is for how long the Public Keys and the Private Keys will be stored. If Public Key or Private Key Recovery will be allowed by the Certificate Authority. The length of the time of the validity period for both the Public Keys and the Private Keys. The technique in which the Certificate Authority can delegate the responsibilities to the Registered Authority. If the Digital Certificates which are to be issued by the Certificate Authority are to be delivered. If the Digital Certificates to be issued by the Certificate Authority are to be used for the sole purpose of just encryption of the Ciphertext. If there are any types of applications that should be refused to have Digital Certificates. When a Digital Certificate is initially authorized by the Certificate Authority if there will be a finite period when the Digital Certificate will be subject to revocation.

As one can see, based on the establishment of the many rules and policies which need to be set into place, the actual deployment and establishment of a Public Key Infrastructure can become quite complex. This is, of course, dependent upon the specific security requirements of the business or corporation.

The Lightweight Directory Access Protocol
The Inner Components and Policies/Rules of a Public Key Infrastructure

Ethical Hacking Training Resources (InfoSec)

Regarding the database structure for the Digital Certificates, this is most useful and effective when the Lightweight Directory Access Protocol (also known as the “LDAP”) servers are utilized. The LDAP is simply a database oriented protocol that is used for the updating and searching of the directories that run over the TCP/IP network protocol (this is also the network protocol that is primarily used by the Public Key Infrastructure).

It is the job of the LDAP server of the Public Key Infrastructure to contain such information and data as it relates to the Digital Certificates, the Public Key and the Private Key storage locations, as well as the matching of the Public Key and Private Key labels.

The Certificate Authority uses a combination of the end user name and the matching tags to locate the Digital Certificates on the LDAP server specifically. From that point onwards, it is the LDAP server that then checks to see if the requested Digital Certificate is valid or not.

If it is indeed valid, it then retrieves from the database a Digital Certificate that can then be sent to the end user (actually, the employee). Although all Digital Certificates that are issued have a finite lifespan when they are first issued, they can also be revoked for any reason at any time by the Public Key Infrastructure administrator.

To accomplish this very specific task, a Certificate Revocation List (also known as the “CRL”) is used. This list is composed of the Digital Certificate serial numbers that have been assigned by the Certificate Authority. However, looking at this type of information and data can be very taxing on the system resources and processes.

Therefore, in this regard, it is much easier to re-issue the Digital Certificates as they expire, rather than having to revoke them and then each time re-issue a Digital Certificate. At this point, the CRL will then have to be updated each and every time manually by the Systems Administrator.


The Public Key Infrastructure is governed by a body known as the Public Key Cryptography Standards, also known as the “PKCS.” The first of these standards has been the RSA Algorithms, the Diffie-Hellman Key Agreement Standard, and the Elliptical Wave Theory. These were all reviewed extensively in the last article.

Our next article will review these standards in much more detail, as the technical parameters which are associated with the Public Keys and Private Keys, and ascertaining how many servers a business or a corporation requires when they are implementing a Public Key Infrastructure for the very first time. T

The common error here is in the thinking that too many servers are better than too few, but this very often leads to a phenomenon known as “Server Sprawl.” In the end, this can be very taxing to an organization, both regarding computing and financial resources.















Viewing all articles
Browse latest Browse all 12749