Public Key Infrastructure
{LANG_NAVORIGIN} Authentication PKI
Vinoth K Anandan
05/02/2005
Public Key Infrastructure aka PKI vaunted as the solution for addressing the network security issues in the cyberspace using cryptographic techniques. This article discusses about how the PKI attempts to address network security threats and issues associated with the PKI.
Network Security Threats:
Before dwelling into the PKI, let us have a brief review at the various types of threats that can be posed against Network Security.
Loss of Privacy:
When the message transferred across the network in plain text, anybody who does have facility 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 imposes himself as legitimate user and try to gain the access to the network resources. He may either use the 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 be modified by the attackers during transmission.
Anti Replay:
Anti Replay is the attack in which the attackers the trap the network traffic and sends the traffic after a delay. The intention for this type of attack could be originating from 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 be motivated 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 being applied to achieve the requirements of network security. Generally the characters, Alice and Bob are assumed as the genuine peers who are in need to achieve the secure transactions.
Confidentiality:
Suppose of Alice and Bob want to transact information between each other in 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 public key.
Even though the public key cryptography can be used to accomplish secured transactions, generally it is not used in practice, as the public key cryptography involves more computation overhead than the conventional cryptography. 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 been 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 the Integrity is needed to attained, Alice would compute the hash value for the message that she need to transact with Bob and encrypt the hash value with her private key. On the receiving enc, 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 for attest the public key of individual entities. The certification authorities aka CA which play the central role in PKI issues 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 about the 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)
- 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.
Figure 1
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 necessary that the individuals would always be willing to trust the third party entities for their business transactions. The involvement of third party also may lead to social engineering attacks. Somebody can try to impersonate and try to get the certificate signed on behalf a corporate and try to use that certificate with the name of the corporate entity for business reasons. Of course, it is the response 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 make is that the owner of the key should ensure to keep the private key as secure as possible. Storing keys in hard disks are susceptible to theft. Considerable amount of the attacks reported in the Internet 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 need 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 the real business scenarios, the business may not be able to expect the 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 believe on the third party entities for establishing the contracts between peers.
E-Mail Link
Your IP address will be sent with this e-mail
