Introduction

All of our articles in this series have looked at using the principles of Cryptography to secure the lines of communications from the sending party to the receiving party. Simply put, Cryptography is the science (or for that matter, the art of) scrambling and descrambling a message while it is in transit.

The purpose of this process is to make sure that the message remains in an undecipherable state if it should be intercepted by a malicious third party, such as that of a Cyberattacker. However, given the sophistication Cyber hacks and attacks today, even a fully encrypted message can still be hijacked, very covertly.

Thus, in this regard, the true test of a fully encrypted message is that, although it has been hijacked, if it can remain undecipherable despite all of the efforts the Cyber attacker will take to decrypt it. This is where the role of the key combinations come into play.

A key is used to unlock and render the scrambled message back into a decipherable state by the receiving party. In the simplest form, a Private Key can be used to both scramble and descramble a message. In the world of Cryptography, a message is also known as a “Plaintext Message,” and in its scrambled state, it is known as a “Ciphertext.”

Although the Private Key can be considered to be secure the Ciphertext on a theoretical level, it does suffer from one critical flaw: It must be a kept a secret (thus its name) between the sending and the receiving parties. If the Private Key is made known to anybody else, the encryption that has been afforded to the Ciphertext falls to naught. In other words, anybody can read it.

The realm of the Private Key falls under the methodology known as “Symmetric Cryptography.” To counter this specific weakness, another methodology known as “Asymmetric Cryptography” has come about. This has been around for quite a long time, and in fact, many businesses and corporations are using various types of it to fortify their defense perimeters from both internal and external threats.

Asymmetric Cryptography makes use of a combination of keys, specifically known as the Public Key/Private Key pair. Thus, as it is implied, and the extra key is used to help encrypt the Plaintext message into a Ciphertext. So in this regard, another layer of protection is given. In these instances, it is the Public Key which is used to encrypt the Plaintext message.

As its name implies, this type of key is made public, and anybody or any entity can use it. However, once again, the premise of making sure that the Ciphertext remains undecipherable resides in the Private Key. This is what is very often used to descramble the Ciphertext, and just like the Symmetric Cryptography approach, it must be kept secret as well between the sending and the receiving parties.

However, unlike the Symmetric Cryptographic approach, the Private Key can also be used in the reverse fashion, in that it can also be used to encrypt the Plaintext message as well.

However, yet once again, even the Asymmetric Cryptography methodology has its security flaws as well, and thus, a newer form of it has evolved over time. This is known as the “Public Key Infrastructure,” and it too uses the Public Key/Private Key combination. However, the key differentiating factor is that a trusted, outside entity is utilized, which is known specifically as the “Certificate Authority.”

In a traditional Asymmetric Cryptography approach, the Public Key/Private Key combination is issued and distributed from within the infrastructure itself. However, this leads to another security issue: How does one know that these Public Key/Private Key combinations are legitimate, and have not been tampered in any way, shape or form?

This is where the role of the Certificate Authority (also known as the “CA”) comes into play. This is actually a trusted, third party which issues these Public Key/Private Key combinations (also known as the “Digital Certificates”), thus assuring their legitimacy to both the sending and the receiving parties.

However, keep in mind that a Public Key Infrastructure, may start out as a very simple implementation at first, but in most instances, it will scale up over time, as the security needs of the business or corporation also escalate. With this mind, a Public Key Infrastructure can become quite complex in the end.

For example, it will no longer be just one pair of sending and receiving parties which will be using the Digital Certificates, but there could be hundreds and even thousands of them needing Digital Certificates literally 24 X 7 X 365.

After all, the same Digital Certificate combination cannot be used over and over again. Each time that a new line of communications is established, a new set of Digital Certificates have to be issued. Because of this, the Certificate Authority can become bogged down and overloaded, much like a Server facing a Distributed Denial of Service (DDoS) attack. If this happens, the Certificate Authority can become a grave security risk as well.

To combat this, a known as the “Registered Authority” is used. This can be considered to be a subset of the Certificate Authority, and its back up. It should be noted that the Registered Authority by itself does not issue Digital Certificates per se, rather, it just confirms the identity of both the sending and the receiving party that is requesting the Digital Certificates.

However, establishing a Public Key Infrastructure also involves many facets and variables as well, such as implementing the proper set of standards and parameters which are needed to make it run both effectively and smoothly. Regarding the latter, the three most crucial permutations which are required for a successful Public Key Infrastructure include the following:

  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.

In the issuance and distribution of the Digital Certificates, it is important to introduce a sense of randomness into the system; this is known as “Entropy.” This is designed as another protective security mechanism for the Digital Certificate combinations. This is created by using a “Random Number Generator.”

In this article, we conclude our series on Cryptography and the Public Key Infrastructure by examining the following topics:

  1. The Security Policies Associated with a Public Key Infrastructure;
  2. Securing the Public Keys and the Private Keys (the Digital Certificates);
  3. Message Digests and Hashes;
  4. Conclusions-The Security Vulnerabilities of Hashes.

The Security Policies Associated with a Public Key Infrastructure


The exact mechanisms as to how to exactly establish a specific Security Policy is out of the scope of this article, as it will primarily depend on the exact needs of the corporation or the business. This can only be ascertained by conducting a Project Management Analysis, which was reviewed in detail in previous articles.

However, the Security Policy should cover at a minimum, the following key issues as it specifically relates to the Public Key/Private Key generation and distribution from within a Public Key Infrastructure:

  1. Whom are the individuals that are authorized to access the Key Server? This is, of course, assuming that the organization does indeed possess one.
  2. Whom within the business or the corporation is allowed to use the Private Keys and the Public Key combinations?
  3. What types and kinds of Ciphertexts, as well as Content Messages (even including corporate information and data), can use the Encryption methods that are available by the Public Key/Private Key combinations?
  4. If the Public Key/Private Key generation and distribution processes are to be outsourced to a trusted, third party, who to the business entity will have the authority to issue the Public Keys and the Private Keys after they have been generated?
  5. What are the specific requirements for the employees from within the business or the corporation to obtain the Public Key/Private Key combinations?

Securing the Public Keys and the Private Keys (the Digital Certificates)


Related to the issue of both Public Key and Private Key Security is that of how to secure the various Key Combinations themselves. Broadly speaking, there are two ways on how this can be specifically dealt with:

  1. The use of Key Escrow;
  2. The use of Key Recovery.

Key Escrow refers to the storage of the Public Keys and the Private Keys at a safe location, and Key Recovery refers to the breaking up of the Public Keys and the Private Keys at the point of origin. This is when the Ciphertext is first created and sent from the sending party. Key Recovery also involves assembling the Public Key and Private Key combinations when they arrive at the point of destination (which would be once the receiving party receives the Ciphertext and uses the Digital Certificates to decipher it).

Message Digests and Hashes


However, in today’s business world, both of these methods as described in the last section are typically infeasible due to security concerns. Today, the preferred method is done by using what is known as “Message Digests” and “Hashes.” Both of these refer to the same concept and are often used synonymously with each other. Essentially, they both are fixed length of literal data nonsense, such as the following:

!@#$%^&*()_+}{POINNNNHHH!!@@$$%^^^^&&&***((()))%%%%%%%DDDDDDD###@@@@

This is to help ensure the integrity of the Ciphertext while it is in transit across the network medium. In other words, this is proof positive for the receiving party who receives the Ciphertext from the sending party that the Ciphertext has remained intact while it has been in transit, and that it has not been altered in any way, shape, or form.

The Hash, or the Message Digest, can be viewed as a fingerprint of the Ciphertext. The hash is created at the point of the receiving party, and it is then calculated again via a specialized Mathematical Algorithm which is utilized by the receiving party.

If the Mathematical Algorithm used by the receiving party generates the same type of garbled data message such as the one shown in the example, then the receiving party can be 100% sure that the Ciphertext that they have received from the sending party is the original Ciphertext at the point of origination and has remained intact.

Conclusions-The Security Vulnerabilities of Hashes


Ethical Hacking Training – Resources (InfoSec)

However, a major security vulnerability of using Hashes is that they can even be altered while they are en route across the network medium. In other words, a hacker can easily intercept the Ciphertext and its associated Hash, alter both and create a brand new Ciphertext and even a brand new Hash.

As a result, the receiving party is then fooled into believing that this new, altered Ciphertext and the new, altered Hash are the originals sent by the sending party, while the hacker keeps the actual Ciphertext and Hash which were generated the first time around.

To fix this major security vulnerability, the Ciphertext is combined with a “Secret Key” at the point of origination first; then the Hash is subsequently created. As a result, this hash will then contain specific information and data about the secret itself. Because of this, the receiving party can be even further ensured that the Ciphertext that they have received is the 100% original which was delivered by the sending party.

This is so because even if the Ciphertext, the Hash, and the associated Secret Key were to be intercepted, there is very little that a hacker can do to alter the Ciphertext and its associated Hash. This is because the hacker will have to have the information and data about the Secret Key, which is something that he or she will never have access to.

Our next article will examine another secure type of Network Infrastructure the Virtual Private Network or the “VPN” for short.

Resources

http://www.ecs.syr.edu/faculty/chin/cse774/readings/rbac/Paper_Trust.pdf

https://www.entrust.com/wp-content/uploads/2013/05/trustmodels.pdf

https://www.deadiversion.usdoj.gov/ecomm/csos/archive/cp_req.pdf

http://file.scirp.org/pdf/JIS_2015010814030097.pdf

http://www.gao.gov/new.items/d01277.pdf

http://www.au-kbc.org/bpmain1/PKI/PKIieee.pdf

https://www.sans.org/security-resources/policies/general/pdf/end-user-encryption-key-protection-policy

http://www.cse.wustl.edu/~jain/cse571-09/ftp/l_07hsh.pdf

https://arxiv.org/ftp/arxiv/papers/1003/1003.5787.pdf

http://www.utdallas.edu/~muratk/courses/crypto07_files/hash.pdf

https://www.cs.clemson.edu/course/cpsc424/material/Cryptography/Message%20Digest%20Functions.pdf

http://www.ee.ic.ac.uk/pcheung/teaching/ee4_network_security/L04HashMD.pdf

http://cs.ucsb.edu/~koc/ccs130h/notes/mac1.pdf

http://www.nku.edu/~christensen/092mat483%20Cryptographic%20hash%20function.pdf

https://www.rose-hulman.edu/~holden/Preprints/jha-paper.pdf

https://pdfs.semanticscholar.org/0a29/51301405cd1f131f65dece59808d5294cc66.pdf