Review of the Last Article

As our last couple of articles have explored, the Public Key Infrastructure (PKI) is a specialized form of Asymmetric Cryptography. Although the latter is deemed to be secure, the Public Key Infrastructure offers a higher level of security not only by using the Public Key/Private Key combination but also by making use of the Certificate Authority (also known as the “CA”).

The Certificate Authority is considered to be a trusted, third party from within the Public Key Infrastructure. Thus, all Public Key/Private Key issuance is done here, to ensure not only the highest levels of security but also by fortifying the level of integrity amongst these Digital Certificates.

In other words, both the sending and the receiving parties can be assured that the Digital Certificates have indeed remained intact throughout the communications process.

The Certificate Authority also has another mechanism, or fail-safe, in case it the Public Key Infrastructure is the target of a Cyber based attack. This is specifically known as the Registered Authority, (also known as the “RA”).

It does not grant Digital Certificates per se, but it does confirm the identities of the sending and receiving parties that are requesting the Public Key/Private Key combinations (which are also considered to be the Digital Certificates).

However, for the Certificate Authority and the Registered Authority to operate and function within the established permutations, various policies and rules have to be put in place. These were reviewed in detail in the last article.

However, it is also very important to keep in mind that not only new sending and receiving parties are requesting the Digital Certificates, but also the existing ones as well from within the Public Key Infrastructure. Therefore, to reduce the consumption of processing resources as much as possible, whenever a new sending and receiving party requests a new pair of Digital Certificates, this information is recorded into a database.

Thus, once this same sending and receiving party requests another pair of Digital Certificates for the second time (and other subsequent times as well), this same information is called up again, rather than having them go through a brand new iteration of identification. This database is known specifically as the Lightweight Access Directory Protocol, also known as the “LDAP” for short. This too was reviewed in detail in the last article.

In this article, we continue with the theme of Public Key Infrastructure, focusing on the following topics:

  1. The Public Cryptography Standards
  2. The Parameters of the Public Keys and Private Keys
  3. How Many Servers?

For a primer article into the Public Key Infrastructure and how it relates to the Cloud, click here:

http://resources.infosecinstitute.com/public-key-infrastructure-pki-cloud/#gref

The Public Cryptography Standards


The other sets of standards which define a Public Key Infrastructure are as follows:

  1. The Password-Based Cryptography:

    This describes how to encrypt a Private Key with a Secret Key that is derived from a password.

  2. The Extended Certificate Syntax Standard:

    This is merely a set of attributes which are attached to a Digital Certificate which has been assigned by the Certificate Authority.

  3. The Cryptographic Message Syntax Standard:

    This standard specifically outlines how to put the Digital Signatures into a Digital Certificate envelope, and from there, wrapping it into another Digital Certificate envelope.

  4. The Private-Key Information Syntax Standard:

    This standard directly specifies what kind of information and data should be included into a Private Key, and how that specific key should be formatted.

  5. The Selected Attribute Types:

    This is a detailed list that describes the certain encryption attribute types for the last three standards just listed.

  6. The Certificate Request Syntax Standard:

    This provides the details for the syntax of the Digital Certificates. Essentially, this standard simply sets forth the parameters that are needed for the Certificate Authority to understand the Digital Certificate request.

  7. The Cryptographic Token Interface Standard:

    This is an Application Programming Interface (also known as the “API”) for specifying and handling the Cryptographic functions as it relates to the Smart Cards.

  8. The Personal Information Exchange Standard:

    This standard specifies how an end user’s (such as an employee) Private Keys should be transported across the network medium.

  9. The Cryptographic Token Information Format Standard:

    This standard specifies how the applications at a place of business or organization should interface with Smart Cards.

In the world of the Public Key Infrastructure, it should be remembered that the Public Keys and the Private Keys are created simultaneously, with no lag time in between. In fact, Public Keys and Private Keys can be anywhere and everywhere in a Public Key Infrastructure, even when one establishes a Secure Shell (“SSH”) connection.

In fact, there are even Public Keys and Private Keys within the Public Key Infrastructure that are only used once, terminated, and are discarded away. These types of Public Keys and Private Keys are known more commonly as the “Session Keys.”

The Parameters of the Public Keys and Private Keys


Before the actual Public Key or Private Key can be issued and distributed to the sending and the receiving parties, certain parameters have to be set forth and established, which are as follows:

  1. The type of Mathematical Algorithm(s) which should be used;
  2. How many bits of data the Public Keys and the Private Keys should be composed of;
  3. The expiration date of both the Public Keys and the Private Keys.

To keep the Cyber attackers at bay, it is equally important that not all of the Public Keys and Private Keys be used all the time in the communication process between the sending and the receiving parties. It is also important to keep the Public Keys and the Private Keys fresh, in other words, it is important to introduce a sense of “randomness” into the Public Key Infrastructure.

Such randomness is known specifically as “Entropy,” and it is created by using a Random Number Generator and Pseudo-Random Number Generators. Also, in a Public Key Infrastructure, there are many different classes of both Public Keys and Private Keys. These are as follows:

  1. The Signing Keys:

    These are the keys which are used to create the Digital Signatures.

  2. The Authentication Keys:

    These are the keys that are created to authenticate computers, servers, and to confirm the identity of both the sending and the receiving parties.

  3. The Data Encryption Keys:

    These are the keys that are used to encrypt the files which are in transit across the network medium.

  4. The Session Keys:

    These are the types of keys that are used to help secure a channel across an entire network for only a very short period.

  5. The Key Encryption Keys:

    These keys wrap up the Ciphertext to provide an extra layer of protection between the sending and the receiving parties.

  6. The Reof Key:

    This is the Master Key that is used for signing all of the other Public Keys and the Private Keys which originate specifically from the Certificate Authority.

How Many Servers?


Ethical Hacking Training – Resources (InfoSec)

In the Public Key Infrastructure, especially in the small to medium sized businesses, very often, only one Central Server is used to distribute both the Public Keys and the Private Keys. However, the primary disadvantage of this is that these types of Key Servers (which are also the Central Server in a Public Key Infrastructure) can become the single point of failure if it breaks down, or worst yet falls victim to a major Cyber based attack,

To help alleviate this problem, multiple and redundant Key Servers can be utilized, but this too can cause a big financial expense. Because of this, one of the best solutions that a small to medium sized business is outsourcing their entire Public Key Infrastructure needs to a trusted third party, such as that of Verisign.

This type of approach can be considered to be a hosted, and one of the key benefits of it is that it can greatly reduce the expense of running an On-Premises Public Key Infrastructure. Also, the level of security is greatly fortified and enhanced with these trusted, third parties.

However, another key issue that is related to the Public Key and Private Key distribution in a Public Key Infrastructure is setting the appropriate Security Policies for them. Included in this is the determination of which mechanisms are to be used for their storage as well as even furthering the level of security of the Public Key and Private Key combinations.

Conclusions

As one can see, deploying a Public Key Infrastructure can be quite a complex task. Although the main crux of it are the Public Key and Private Key combinations, there is a lot more that goes into it to meet and even surpass the security requirements of the business or the corporation.

As this article, has reviewed, there are many parameters which need to be taken into consideration, which are even different key combinations of themselves. Also, the type of Mathematical Algorithm(s) which is going to be used also needs to take into consideration before they can be implemented into the Public Key Infrastructure.

Apart from the parameters, there are also other key standards which need to be reviewed critically as well during the design phase of the Public Key Infrastructure. Apart from its sheer complexity, a Public Key Infrastructure can also be quite costly to maintain over time, especially as it grows in size. Thus, a business or a corporation may want to consider their Public Key Infrastructure needs to a third party.

Our next article will examine the following topics:

  1. The Security Policies for a Public Key Infrastructure
  2. The techniques involved in securing the Public Key and Private Key combinations
  3. Message Digests and Hashes.

Resources

https://pdfs.semanticscholar.org/4dc3/387459dbe471689cc71096db79290287d299.pdf

http://delta.cs.cinvestav.mx/~francisco/cripto/PKCS.pdf

https://web.cs.ship.edu/~cdgira/courses/CSC434/Fall2004/docs/course_docs/IntroToPKCSstandards.pdf

https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture12.pdf

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

http://www.di.unisa.it/~ads/corso-security/www/CORSO-9900/oracle/pkcsv21.pdf

https://www-ee.stanford.edu/~hellman/publications/27.pdf

https://people.csail.mit.edu/vinodv/6892-Fall2013/rothblum.pdf

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf

http://crypto.stanford.edu/~dabo/papers/ibethresh.pdf

https://oag.ca.gov/sites/all/files/agweb/pdfs/erds1/fips_pub_07_2013.pdf

https://arxiv.org/pdf/cs/0410024.pdf

https://eprint.iacr.org/2014/946.pdf