Putting it all Together
We have looked at the three critical pieces of technology – symmetric cryptography, asymmetric cryptography and hashing. Each technology a core technology found in almost all current security systems. A brief summary is shown below:
Technology
Main Usage
Major Pro
Major Con
Symmetric Cryptography
Bulk encryption of large quantities of data
Fast and secure
Key exchange
Asymmetric (Public key) Cryptography
Authentication of entities
Secure – no key exchange
Very slow, high overhead
Hashing
Data integrity
Stable technology, very secure
Hashes are subject to alteration, rendering them useless
Neither of these technologies alone is secure, nor can it provide a holistic solution for secure communication. To mitigate the risks associated with each technology, we must use the technologies together. Consider an example of two users who wish to exchange a secure message.
Alice wishes to send a secure message to Bob such that only Bob can receive the message; Bob can verify that the message came only from Alice, and that the message was not tampered with during transmission. In practical terms, this is the procedure that is followed by S/MIME.
- Alice generates a message M.
- Alice Bob’s public key to encrypt the message Epub(Bob){M} as eM.
- Alice produces a hash H of message eM by performing H{eM}
- Alice uses her private key to encrypt the hash Epvt(Alice){H} as eH.
- Alice assembles the complete message as eM:eH. And forwards the structure to Bob.
- Bob separates eM and eH.
- Bob validates that the message has come from Alice AND the message has not been altered by decrypting the hash that arrived and comparing it with a new hash. This can be represented as Dpub(Alice){H} = H{eM}.
- Bob uses his private key to decrypt the body of the message by performing Dpvt(Bob){eM} = M.
- Bob reads the message.
In step 7 and 8, Bob performs three fundamental operations that warrant analysis. The act of regenerating the hash and then comparing it to a decrypted version of the attached hash (eH) provides two functions. If the document has been tampered with OR the message did not come from Alice, this operation will fail. The only information available to Bob will be that the intended hash (his new version) does not match the one that was attached to the document. This could be caused by one of two possible conditions.
- Recall that Alice’s public key is mathematically related to her private key. This means that if a private key other than Alice’s was used to encrypt the message, then the subsequent use of her public key to decrypt it will fail, resulting in an invalid hash error.
- If an attacker alters the document in any way to change its contents, rehashes the document, and attaches a new hash, the comparison will fail resulting in an invalid hash error.
Note that this does not protect against an attacker gaining unauthorized access to Alice’s private key. As far as Asymmetric encryption is concerned, at that point the attacker is Alice. Protection of Alice’s private key is the function of her key management system. In addition to trusting that the encryption protocols in use are not venerable to attack, we must also trust that Alice’s key management system has taken sufficient steps both protect her key and authenticate her before it to be used.
Now that we have solved the problems of authentication of both parties, encryption of the data, and integrity of the data we can begin to see the strength of Asymmetric (Public Key) encryption. The only outstanding issue is that of speed. Asymmetric encryption is to slow for most bulk encryption operations. This issue is solved by combining both symmetric and asymmetric cryptography. Instead of using the above mechanism to exchange meaningful data, Alice and Bob can use it to exchange a secret key. This secret key can then be used for future communications, key exchanges, and bulk encryption