Network Security Threats
Before delving into the PKI, let us have a brief review of the various types of threats that can be posed against Network Security.
Loss of Privacy: When the message is transferred across the network in plain text, anyone who has the ability to monitor the network can read through the message. Sniffer programs are available to trace through the network traffic.
Impersonation: Refers to the act in which malicious attackers pose as a legitimate user and try to gain access to network resources. He may either use stolen credentials OR experiment with guest credentials and System vulnerabilities to gain access to the system.
Loss Of Integrity: Messages that are being transmitted in clear text form are vulnerable to modification by the attackers during transmission.
Anti Replay: Anti Replay is an attack in which the attackers trap the network traffic and send the traffic after a delay. The intention for this type of attack could be motivated by various business reasons.
Non-repudiation: Non repudiation is the case where a user refutes the network transactions that he had made with his peer earlier. Again, the motive for this type of attack could stem from various business reasons.
The network security requirements that can be derived from the above discussion of security threats are,
Confidentiality: i.e. encoding the information into a format which is incomprehensible to the attackers.
Authentication: It is a process in which the identity of the individual or the origination of information is being verified.
Integrity: the mechanism to check whether the information received from the peer of communication is intact.
Public key Cryptography
The application of public key involves two keys. The encryption of the information is being done with one of keys and the decryption takes place with the other key. The key values are computed such that the key values meet the following criteria:
- if one of keys has been used for encryption then the information can be retrieved only by using the other key.
- it is not possible to derive one key from the other.
Using different keys for encryption and decryption solves the problem of sharing keys in conventional cryptography.
Now let us look at how the Public key Cryptography is applied to achieve the requirements of network security. Generally the characters, Alice and Bob assume the role of genuine peers who need to achieve secure transactions.
Confidentiality
Suppose Alice and Bob want to transact information between each other in a secure manner, then each of them would generate two keys and send one of their keys to each other and keep the other key as secret.
The key, which is published to others is called public key and the key which is retained as the secret is known as private key.
For example, let us assume that the keys that Alice generates are APu and APr and keys that Bob generates are BPu and BPr Then Alice would send her public key APu to Bob and similarly Bob would send his public key BPu to Alice.
To achieve secure communication, Alice will encrypt the information using Bob’s public key BPr and sends it to Bob. Bob will decrypt the information using his private key BPr.
Since the encryption takes place with Bob’s public key it can be decrypted only by using Bob’s private key and none of other keys would not be used for decryption.
Alice: E = AlPu (M) Encrypts the message using Bob’s public key
Alice: Sent the encrypted message to Bob
Bob: M = AlPr (E) Decrypts the message using his private key
In the same way if Bob wants to send the information to Alice securely, he would use Alice's public key.
Even though public key cryptography can be used to accomplish secured transactions, it is not generally used in practice, as the public key cryptography involves more computation overhead than conventional cryptography does. Instead, the public key cryptography is used to negotiate the dynamically generated symmetrical key when the peers of communication establish sessions with other and then the symmetrical is used to encrypt the information during that session period.
Authentication, Integrity and Non repudiation
For Bob to authenticate Alice or to verify the origin of the message sent from Alice, Alice would encrypt the message using her private key AlPr. When Bob is able to decode the encrypted message using Alice public key AlPu, He can make sure that the message could have originated only from Alice and nobody else, since Alice keeps her private key as secret.
Alice also cannot refute the message later, since the message is being encrypted using her private key for which she is sole owner.
Alice: E = AlPr (M) Encrypts the message using her private key
Alice: Sent the encrypted message to Bob
Bob: M = AlPu (E) Decrypts the message using Alice public key
When Integrity needs to be attained, Alice would compute the hash value for the message that she needs to transact with Bob and encrypt the hash value with her private key. On the receiving end, Bob would decrypt the hash value using Alice public key, compute the hash value from the message and then compare the values. If the hash values matches, then he can ensure the integrity of the message.
Alice: h = H (M) Compute the hash over the message
Alice: E = AlPr (Mh) Append it with original message and encrypt the whole using her private key
Alice: Sent the encrypted message to Bob
Bob: Mh = AlPu (E) Decrypt it with Alice public key and get the hash and the original message.
Bob: hr = H (M) Recompute the hash from the message
Bob: hr == h Compare the hash values.
When integrity as well as encryption needs to be achieved, then two levels of encryption would take place.
Alice: h = H (M) Compute the hash over the message
Alice: E = AlPr (Mh) Append it with original message and encrypt the whole using her private key
Alice: E’ = BPu (E) Alice encrypt the whole again with Bob’s public key
Alice: Sent the encrypted message to Bob
Bob: E = BPr (E’) Bob does the first level decryption with his private key
Bob: Mh = AlPu (E) Decrypt it with Alice public key and get the hash and the original message.
Bob: hr = H (M) Recompute the hash from the message
Bob: hr == h Compare the hash values.
The hash value encrypted with sender’s private key is known as Hash Based Message Authentication Code aka HMAC aka digital signature. Digital signatures play a vital role in Public key infrastructure.
After looking at how public key cryptography is being using for achieving the security goals, now we can find that whole concept relies on the following assumptions:
- The secrecy of private key is important for using PKI.
- It should not be practically possible to derive the private key by knowing the public key and vice versa.
- Each person (could be an individual OR a corporate) should have some authenticative way of distributing his public keys to others to which he wants to securely communicate.
If we do not have the authenticative way of distributing certificates, then the attackers can spoof the public key.
For example the malicious attacker can send his public key to Alice with Bob’s name. If Alice does not have a way to assert the key owner, then she would believe that the key she received pertains to Bob and would attempt to communicate to Bob with the key. In this scenario, Bob would be able to get anything from Alice message, but the attacker would be able to decode the Alice’s message, since it would have actually been encrypted with attacker’s public key.
To overcome this issue, PKI introduces the concept of Digital certificates and Certification Authorities.
Public Key Infrastructure
Public key infrastructure allows participants of secure communication to publish their public keys in authenticative manner.
PKI uses the digital signatures to attest the public key of individual entities. The certification authorities aka CA which play the central role in PKI, issue certificates signing the public key of the individual entities with the digital signatures created by encrypting the public key of the individual with its private key. The CA is considered as the trusted third party that can authorize the public keys of individuals.
Assuming the same example of Alice and Bob, Alice will generate the key pairs and send a request to CA to sign her public key. After verifying the identity of Alice, the CA will generate the certificate with signing the public key of Alice with CA’s private key.
The certificate would contain the following information: Issuing Certificate Authority, Validity period of the certificate, the public key of the individual for the which the certificate has been created and digital signature that can be used to verify the certificate.
If the signature information were derived (encryption of public key) from the corresponding private key of the individual entity itself, then it would be known as the self signed certificate.
For example, the certificates that uses X509 standard would have the following information. (See Figure 1)
Figure 1
Version
This identifies which version of the X.509 standard applies to this certificate, which affects what information can be specified in it. Thus far, three versions are defined.
Serial Number
The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues. This information is used in numerous ways, for example when a certificate is revoked its serial number is placed in a Certificate Revocation List (CRL).
Signature Algorithm Identifier
This identifies the algorithm used by the CA to sign the certificate.
Issuer Name
The name of the entity that signed the certificate. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate. (Note that in some cases, such as root or top-level CA certificates, the issuer signs its own certificate.)
Validity Period
Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period chosen depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate. This is the expected period that entities can rely on the public value, if the associated private key has not been compromised.
Subject Name
The name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. This is the Distinguished Name (DN) of the entity.
Subject Public Key Information
This is the public key of the entity being named, together with an algorithm identifier that specifies which public key crypto system this key belongs to and any associated key parameters.
When Alice and Bob want to talk with each other, Alice will send the certificate to Bob. Bob will verify the public key stated in the certificate by executing the following steps:
- Check the validity period
- Decrypt the signature included in the certificate using the public key of the Certification Authority.
- Compare the resultant with the public key included in the certificate.
Since, the signature information was encrypted using CA’s private key, it can be decrypted only by using CA’s public key and if Bob is able to do that successfully, then he can ensure that the certificate originated only from the CA.
The presumption made here is that the users who use PKI for their secured transactions should know the public key of Certification Authority from which they get their public keys signed.
The Certification Authorities distribute their public keys using self signed certificates signed with their own private keys. The certificate that has information about CA’s public key is known as CA’s root certificate.
As it is not possible to have a single certification authority to issue certificates to all, the concept of Hierarchical CA’s exists in which the root CA will issue certificates to authorize the Subordinate CA’s and the individual entities can get their public keys signed from the Subordinate CA’s. In this case the client, who want to verify the public key information of it’s peer, will iterate through the chain of certificates for validation.
The browser applications like IE and Netscape usually have the certificates of well established root certification authorities and subordinate CA’s, which they will use to verify the certificates when we connecting to web sites that uses certificates from those CA’s. (See Figure 2).
Figure 2
Issues with PKI
The PKI makes the assumption that the individuals need to trust a third party to secure their transactions. In the real business world, it is not necessarily the case that the individuals would always be willing to trust the third party entities for their business transactions. The involvement of third party may also lead to social engineering attacks. Somebody can try to impersonate and try to get the certificate signed on behalf of a corporate and try to use that certificate with the name of the corporate entity for business reasons. Of course, it is the responsibility of the CA to verify the identity of the entities, which request for certificate signing and issue the certificate. But the tactic intruders can try to use social engineering techniques to evade the process.
The second presumption that the PKI makes is that the owner of the key should ensure that he keeps the private key as secure as possible. Storing keys in hard disks are susceptible to theft. A considerable number of the attacks reported on the Internet are related to the break in of corporate servers and stealing the information from the servers. Most of the applications that use PKI have provisions to store the private key in the encrypted based on user entered password or key string. Again, the attacker can try to use password crack tools, guess passwords or use brute force attacks to break the password and get the private key.
When the individual or corporate decides to not use a particular key pair, then it is needed to make sure that it revokes the corresponding certificate. For e.g. when an employee who registered for the use particular certificate leaves the company, then the company needs to make sure that it revokes the certificate, so that the employee cannot use that certificate any more.
Certificate Revocation check enforces the requirement of connectivity with CRL servers. When an entity revokes the certificate, the CA adds the certificate to the Certification Revocation list. When the peer of communication receives a certificate during a transaction, they need to connect with CRL server and ensure that the certificate has not been revoked. For this to happen the CA should ensure the availability of CRL Distribution point and the peers of communication should have connectivity to the CRL Distribution point. The unavailability of CRL server OR loss of connectivity would hinder the peers of communication in verifying the certificate and would pose definite security threats of misusing certificates. In fact, in a real business scenario, the business may not be able to expect connectivity with the third party entities all the time. The business entities may expect to establish the contract at the initial stages and would want to use that contract for later business transactions without requiring the connectivity with third party entities.
The assumption of trusted third party itself is questionable, as some business entities may not prefer to rely on the third party entities for establishing the contracts between peers.