Computer Science 461

Distributed Computing and Networking

Fall 1997

Protocol Weaknesses

The AcmeNet protocol is not secure enough for critical applications. In its design we traded off security against complexity, to design an assignment that would give you the idea of how security programming works, without forcing you to write too much complicated code.

Key Management

The first weakness is in key management. Keys are set up via an email exchange, and they are stored in a protected file on a Unix machine. Anyone who can compromise the Unix system can learn all of the secret keys and thus impersonate anybody. Keys could be manually changed but that would be cumbersome.

A better system would use public-key crypto to identify students. That way, no critical keys would have to be stored on-line. The system would have a central signing key that was stored on a laptop that spent most of its time turned off and locked in a safe. It would have to be taken out only when a student wanted to change his or her password.

No Message Integrity Guarantee

There is no strong mechanism to prevent an adversary from modifying a message in transit. Although an adversary cannot guess the plaintext corresponding to a particular block of ciphertext, the adversary does know that flipping a bit of the ciphertext will cause the corresponding bit of the decrypted text to be flipped. In some cases, this is enough for the adversary to cause trouble. For example, if we used AcmeNet for a secure banking transaction, and if the adversary could guess where the "amount" field of a transaction was in the data stream, then the adversary could inject a transaction with a known amount and make a known change in the amount while the message was in transit.

This problem could be fixed by adding some redundancy to the data stream. For example, each message could be followed by its cryptographic hash. Then if the adversary tampered with a message, the hash would not match.

Authentication Ticket Prone to Tampering

Similarly, the "ticket" sent during the authentication protocol does not contain redundancy, so it is prone to tampering via the same bit-flipping trick described above. The ticket contains the identity of the initiator; a malicious initiator could flip bits in the ticket to change the initiator identity that is encoded in the ticket. This would allow an initiator to impersonate another host.

The fix is to add some kind of redundancy to the ticket.

Session Key Lives Forever

Once a secure connection is set up, the session key (the key used for encrypting data on the connection) is never changed. If an attacker can somehow compromise one end of the connection, the attacker can continue to read and modify traffic on that connection forever.

A better approach is to do periodic Diffie-Hellman exchanges on the connection to generate new keys. Switching keys in this fashion limits the window of vulnerability due to any one session key compromise.

Needham-Schroder Protocol Weakness

We inherit a weakness of the Needham-Schroeder authentication protocol. Suppose A sets up a connection to B. If an adversary can record the "ticket" and somehow learn the corresponding key, that that adversary can impersonate A to B forever.

The problem is that B has no way of knowing that the ticket is "fresh". Adding a timestamp or some kind of sequence number to the ticket would allow B to detect reused tickets.

The Bottom Line

Designing a secure protocol is very difficult, and designing a secure system is even harder.

Even professional cryptographers make mistakes, designing and implementing protocols that have serious weaknesses. That's why it is so important to have detailed public review of protocols and systems before they are deployed in critical applications.

Last modified: Tuesday, November 4, 1997 9:15 AM