C SC 481.20 Lecture 16: Integrity and Authentication
major resource: Computer Networking (4th Edition), Kurose and Ross, Addison Wesley, 2008

[ previous | schedule | next ]

Integrity

• To assure integrity of a message from Alice to Bob, Bob needs to verify that
  1. the message was not altered after it left Alice, and
  2. the message really came from Alice (not Trudy)
• Integrity sometimes called authentication
• The term authentication sometimes used to refer to just the "really came from Alice" part
• Integrity can be considered separately from confidentiality
  • Encryption may not be required
  • Router link-state messages, for instance, must be authenticated
  • Link-state message need not be encrypted because secrecy not needed
• Integrity part "a" (not altered) is achieved through cryptographic hash functions
• Integrity part "b" (really came from Alice) is achieved through digital signatures
• These are described below

Cryptographic Hash Functions

• Recall hashing technique from CSC 205 ( Autumn 2007 notes): constant time function that transforms data/key value into index for direct access searching (avg time O(1)).
• Checksums and CRC are superficially hashing techniques, but serve different purpose
• Cryptographic hash is somewhat like a special checksum or CRC value.
  • It is like checksum/CRC because it is a fixed length value computed from message contents
  • It goes beyond checksum/CRC because every different message produces different hash value! (perfect hash)
  • The message M can have hash H(M) appended for transmission
  • Receiver calculates hash against received message and compares to H(M)
  • If the message M has been modified, receiver hash calculation will not equal H(M)!
• The above protocol is vulnerable
  • Trudy can modify M to M' then calculate and append H(M')
  • Bob receives M' and H(M'), calculates hash and it matches
  • Solution is secret authentication key S shared between Alice and Bob
  • Alice calculates H(M+S), then appends and transmits M and H(M+S)
  • Receiver Bob calculates hash from received message + S and compares to H(M+S)
  • Only sticking point is how Alice and Bob learn key S; can use public key encryption if necessary
• Example: MD5 hash, by Rivest (of RSA fame)
  • Works on 16-word message blocks
  • Produces 4-word (128 bit) hash
  • Uses multi-round algorithm
  • See RFC 1321 for details
• Since the goal is tamperproofing not confidentiality of message, message encryption is optional

Digital Signatures

• Assuring that message comes from who it says it does : digital signature
• Can implement this by extending public key encryption, given fourth characteristic: E(D(M)) = M
• RSA has this characteristic, so can be used for authentication
• Authentication procedure, without message encryption:
  1. sender applies its private D_S to M
  2. sender transmits result: D_S(M)
  3. receiver applies sender's public E_S to get E_S(D_S(M)), which is M
• If the message had come from a different sender, last step would fail.
• Authentication procedure, used in conjunction with message encryption:
  1. sender applies its private D_S to M
  2. sender encrypts the result using receiver's public E_R
  3. sender transmits result: E_R(D_S(M))
  4. receiver applies its private D_R to get D_R(E_R(D_S(M))), which is D_S(M)
  5. receiver applies sender's public E_S to get E_S(D_S(M)), which is M
• If the message had come from a different sender, last step would fail.

Combining the Two

• These techniques can be combined to provide both aspects of integrity
• Example of Alice sending message M to Bob; suppose confidentiality not required
1. Alice computes hash on message, H(M)
2. Alice applies her private key to the hash, D_A(H(M))
3. Alice transmits the D_A(H(M))
4. Bob receives D_A(H(M))
5. Bob applies Alice's public key to the encrypted hash, E_A(D_A(H(M))) -> H(M)
6. Bob computes hash on message and compares to H(M)
7. If hash and received H(M) equal, integrity has been achieved
• Confidentiality can be easily added to this example; try it

Playback Attacks

• Even with the above, a playback attack is possible
• Trudy eavesdrops on message from Alice to Bob
• Trudy records the message then later sends it to Bob, impersonating Alice
• Note that encryption, passwords, etc will all appear legit.
• Playback can be thwarted using a nonce
• Nonce is one-time value that Bob sends to Alice in response to the message
• Subsequent messages from Alice in this conversation need to include the nonce for authentication
• If Trudy is only recording and playing back, the playback will not include the correct nonce
• Timestamp is good choice for nonce value

How to obtain/verify secret (symmetric) or public key?

• For secret (symmetric) keys,
  • obtain from mutually trusted intermediary called Key Distribution Center (KDC)
  • KDC is key server with repository of secret keys between it and each of its clients
  • Kerberos is a well-known authentication protocol developed at MIT and incorporated into Windows; it uses KDCs
• For public (e.g. RSA) keys,
  • Consider obtaining a public key for Bob
  • Bob may post it in public place (e.g. web page), good for manual operations but not good for embedded automated encryption (e.g. web communication or secure IP routers)
  • Bob can register with mutually trusted intermediary called Certification Authority (CA)
    • verifies Bob’s identify through an authentication procedure
    • creates a certificate containing Bob’s i.d., public key, expiration date
    • digitally signs the certificate
  • Alice then requests and obtains Bob's certificate from the CA.
  • To be sure certificate really came from the CA, Alice checks certificate's digital signature. This requires it to have the CA's public key. If it does not, it needs to obtain it in a recursive fashion! Fun and games….
• VeriSign is a well-known CA, see www.verisign.com

Man-In-The-Middle Attacks

• Applies to public key situations
• man-in-the-middle: Trudy is able to impersonate Bob to Alice, and Alice to Bob
• It can occur when Alice requests Bob's public key from Bob
  • Trudy can intercept, pass the request on to Bob, then respond to Alice with her own public key
  • Bob then asks Alice for her public key -- Trudy can intercept and similarly pose as Alice
  • Trudy now controls both ends of the transmissions, transparently to both Alice and Bob
• This is prevented if both Alice and Bob request each other's public keys from Cetificate Authority instead.
• Note that man-in-the-middle does not apply if Alice and Bob communicate using a shared secret (symmetric) key instead of public key

Aside: Authentication and confidentiality w/o encrypting data!

• Technique developed by Ron Rivest ( the "R" in RSA) at MIT: chaffing and winnowing.
• Issue it addressed was statutory limits at the time on encryption key length (for export); since the data are not encrypted, such limits would not apply
• Never widely applied (the limits were relaxed) but at least has rated a Wikipedia entry
• Basic concept:
• message is partitioned into packets
• each packet consists of triple < sequence #, data, authentication code >
• authentication code uses public key technology and based on sequence # and data.
• Sender (or intermediary) also sends fake packets with same sequence # but random data and code (this process is "creating chaff")
• Receiver knows how to decipher authentication code so will know which packets are real and which are fake (this process is "winnowing"). Intruder will not.
• Note that data themselves are not encrypted, and data field could be as short as 1 bit!
• Very high overhead
• For more info, see: http://people.csail.mit.edu/rivest/Chaffing.txt