Q: I’ve heard that EAP-TLS is the most secure way to do Wi-Fi authentication. I know that EAP-TLS relies on digital certificates, but I’m a little fuzzy on how certificates work. Can you start at the beginning and walk me through?
A: That’s a great question, but with a long answer. Out of fairness to those with short attention spans, I’m going to break this up into a few parts. Let’s start first with some cryptography basics that apply when we talk about certificates.
Secret Key versus Public Key Cryptography
----------------------------------------------------
At a basic level, cryptography is about hiding secrets. Most modern encryption schemes use a secret key to encrypt data, thus obscuring the contents of the data we wish to protect. The intended receiver of this data decrypts the data using the same secret key. This is a very simple system, and many of the cryptosystems we are familiar with operate this way, such as AES, DES, 3DES, and RC4. However, this type of system brings up the thorny issue of key management: How do we ensure that both the sender and the receiver have the same secret key, and how to we ensure that others don’t find out the secret key? This is where public key cryptography comes in.
In public key cryptography, there are two keys instead of just one. The two keys, known as a public key and a private key, are mathematically related to each other such that data encrypted with a private key can only be decrypted by the public key, and data encrypted with the public key can only be decrypted by the private key. As the names imply, the private key is something you keep private – only you have this key. The public key, on the other hand, is made available to anyone in the world who wants it. The system works as an encryption scheme because the keys are very large numbers, and factoring (finding all the prime numbers that, multiplied together, equal the number) a very large number is a computationally difficult problem.
To use public key cryptography with another person, for example to exchange encrypted emails, you must know the other person’s public key. When sending an email, you will encrypt the email with the other person’s public key. Upon receipt, the other person will decrypt your message using his private key.
Signing
---------
Public key cryptography is commonly used to encrypt data as well as to sign it. Encryption is about keeping data secret, while signing is about the integrity of the data – making sure it was not tampered with. Very often we may want to leave data in the clear (plaintext or cleartext) but want some assurance that data has not been modified in transport, by a “man in the middle” for example. Signing can also be used as a “digital signature” for documents in lieu of signing a document in ink. Adobe Acrobat, for example, allows one to embed a digital signature block in a document. Clicking on this block, you will be prompted to digitally sign the document using public key cryptography. By signing a document with a private key, this proves that you and only you signed the document, since only you have the private key. This brings us to the other major use of signing: non-repudiation. This principle establishes that you and only you signed a document, and that the document was not modified after the time you signed it.
Signing is very simple: Take the document or data that you wish to sign and compute a hash of the document using your favorite hash algorithm such as MD5 or SHA1. Since the odds of two documents that generate the same MD5 hash are extremely (extremely!) low, we now have a solid guarantee of document integrity, right? Wrong: Anyone modifying the document during transport could simply recompute the MD5 hash and replace it. This is where digital signing comes in. Take the MD5 hash and encrypt it using your private key, then attach it to the end of the document. A recipient of the document will decrypt the block at the end using your public key (if you want to make it easy, attach the public key to the document) to get back the MD5 hash. The recipient then computes the MD5 hash of the document, and compares it to the received MD5 hash. If the two match, the document was not altered in transport.
The astute among you will immediately notice a flaw in the document signing example above: “if you want to make it easy, attach the public key to the document” and that’s where we’ll pick up next time with a discussion around key distribution.