Lecture 24: Secure Communications

The first thing we talked about in this lecture was message integrity. We need to be able to verify that a message, once received, is in its original form and has been received unmodified. This task is accomplished by generating a message digest for the message at its origin before it is sent and generating another one once it has been received and then compare the two digests. Two such algorithms were mentioned: MD5 which has a 128-bit message digest for output and SHA-1 which has a 160-bit message digest output. When then discussed MAC or message authentication codes which is basically a hash of the message being sent that is keyed by a value that is shared between the sender and the receiver, this provides a guarantee for who created the message but not necessarily who sent it. This problem can be solved by using nonce values as part of the key used in the hash to prevent playback attacks.

Later we discussed digital signatures, which is another way to verify the origin of a message. For short messages it is sufficient to encrypt a message using one's private key before sending it to a recipient who can then verify the sender by decrypting it using the public key. However, for large messages this is not efficient, so instead of signing the message itself, one can generate a message digest for the message and sign the digest instead. The recipient can then verify a message by decrypting the signed hash value as well as generating a message digest for the received message and check if they match.

Then we went over public key certification and authorities. Basically, without them there is no way to know if a provided public key belongs to the person that provided it. What is done now, is public keys are submitted to a certification authority who verifies the identity of the person that submitted the key, then signs it using their own private key, which is the certificate. So when someone wants someone else's public key, they can get a certificate from either that person or another source, decrypt it using the CA's public key, and they will know that the key they have is the legitimate public key of the other person.

The second to last topic that was covered was SSL, which is a security protocol that is implemented above the transport layer and provides confidentiality, integrity, and authentication. SSL supports many encryption algorithms, meaning that a client and server must decide on which one to use, this is done by a client sending a server a list of acceptable cipher suites and the server will then pick a one and tell the client which one it chose. SSL communication starts with a handshake during which the identity of the server is authenticated via public key certificate, nonces are exchanged along with cipher suite choice, as well as MACs of all messages passed during handshaking. The encryption and MAC keys are computed using the information that is exchange during the handshake, the MACs of the handshake messages are used to verify that no one has modified the initial handshake messages that were not encrypted. To detect the tampering of data during communication, all MACs are computing using a sequence number, MAC key, message type, and the data being carried in the packet.

The last thing we discussed was IPsec which is implemented above the network layer and provides for data integrity, origin authentication, replay attack prevention, and confidentiality. IPsec has two modes of operation, the first is Transport mode in which the end systems take care of IPsec, the other is tunneling mode in which IPsec is handed by the routers (first hop routers from each of the end systems). There are then two different protocols that can be used in IPsec, the first is Authentication Header which provides for the authentication of the source as well as the integrity of the data being transmitted, however, there is no confidentiality. The second is Encapsulation Security Protocol which provides all the features that AH does but adds confidentiality. The most popular service used is Tunneling with ESP. When using Tunneling with ESP the original IP datagram gets encrypted using an agreed upon algorithm, a sequence number and an SPI (Security Parameter Index, basically an index for a lookup table for a router to figure out how to process the packet) are appended before the encrypted packet. Then the whole datagram gets run through a MAC algorithm, whose results are then appended to the message, and finally a new IP header is attached to the beginning of the new message before it gets sent. A receiving router will then have to use the SPI in the packet to figure out how to handle the payload, verify its integrity, then send the original packet to its intended destination.