PKI Usage Example
The following example outlines an exchange between two entities and illustrates how the concepts explained above are implemented. In this example, Alice will send a message to Bob and provide proof that the message actually came from Alice.
- A user authenticates to their local system, giving them access to their private key.
- Alice performs a one-way hash on the message.
- Alice encrypts the message hash with her private key and forwards the message and encrypted hash to Bob with a copy of her certificate. Note that a private key encrypted hash is known as a digital signature.
- Bob received the data and uses the certificate to extract Alice’s public key. He then uses the public key to decrypt the hash that came with the message.
- Bob takes the message that he received and generates a new hash. He compares the new has with the one that was just decrypted. If they match it means he was able to decrypt the data (and has verified Alice’s identity) and that the data has not been altered in any way.
You will probably note that there are some serious security issues with this example.
- We have not verified Bob’s identity.
- We have not provided privacy for the message.
- We have not verified that Alice’s certificate has not been tampered with.
- We have not ensured that Alice’s certificate has been cancelled, or revoked.
These topics will be covered later in this article and in the next PKI article.
The Role of the CA
A CA is a software package that controls the issuance of certificates. When an entity (user, computer, router, or other) requires a certificate, the software on that device generates the private key and public key pair. The private key is securely stored locally, and the public key is sent to the CA for verification. Along with a copy of the public key, information such as the name, organization, and other relevant information is submitted to the CA in the form of a certificate request. The administrator of the CA will then verify the identity of the requestor and generate the certificate file. This file is then sent back to the user or device as a certificate.
One important thing that must be understood regarding CA’s is the process of verifying the requestor. Depending on the implementation, this may occur automatically via user credentials (Active Directory) or through a manual process, involving paperwork, email verification, and in extreme cases, public verification (police documents, photo ID, etc…) The trust you can place in a certificate is directly related to the level of trust you place in the CA that issues the certificate. If the CA has very weak issuance policies or very poor verification mechanisms in place then the likelihood that fraudulent certificates exist increases. This was the case last year when Verisign, a large commercial CA issued certificates to an entity impersonating Microsoft.
Once a CA has verified that the certificate request is legitimate, they sign the certificate. The act of signing the certificate is an important leap of faith for the CA, as they are now staking their reputation that the identity of the certificate holder is valid. The certificate is signed in the same manner that any other data structure is signed. The certificate is hashed, and then the hash is encrypted using the private key of the CA. If a CA issues many certificates then it’s private key must be kept very secure, as disclosure of the private key would result in a breach in trust affecting many entities.
CA’s are very rarely found alone. CA’s are often implemented in hierarchies consisting of Root CA’s, and Subordinate CA’s. Generally a Root CA is a computer that is offline and stored in a physically secure location. Subordinate CA’s are then created to serve specific functions and are secured according to the sensitivity of the function they perform. The process of an entity validating all certificates up to the root certificate is called path verification or certificate chain verification.