Privacy and Authentication For Wireless Local Area Networks

1
Privacy and Authentication For Wireless Local
Area Networks

• By Ashar Aziz, Whitfield Diffie
• IEEE Personal Communications (First Quarter 1994)
  25-31.

2
Outline

• Abstract
• Design Goals
• Design Overview
• Secure Protocol Description
• Data Packet Issues
• Operation With Multiple CAs

3
Abstract

• Security Problem in Wireless Medium
• Eavesdropping
• Intrusion
• In this article,
• Design of a secure communication protocol
• The placement of the protocol in protocol stack
• Issues relevant to wireless links and mobile
  devices
• Proof of the security of the protocol using Logic
  of Authentication formalism

4
Design Goals

• Favorable transparent integration
• Most of the nodes should remain unmodified.
• Security mechanisms/levels
• Physical wire security.
• End-to-end Application Layer security.
• End-to-end Transport Layer security.

5
Link vs. End-to-end Security(1/2)
6
Link vs. End-to-end Security(2/2)

• End-to-end security
• Application or transport layer would require
  modifying the software.
• Definitely not suitable for internet
• Link level security
• obviates the software upgrade needing.
• Node authentication is conceptually correct for a
  security protocol at the link layer.

7
Multiple Users, Single Link Layer
8
Design Overview

• Use both public key and shared key cryptographic
  techniques.
• The certificate contains the public key, logical
  ID, and digitally signed using the CA's private
  key.
• The two parties, Mobile and Base, exchange
  certificates and engage in a mutual
  challenge-response protocol.
• This protocol allows negotiation of the
  shared-key algorithm.

9
Notations
10
Secure Protocol Description(1/5)

• Message 1. Mobile --gt Base (request to
  join)
• Cert_Mobile, CH1, List of SKCSs
• Mobile side
• Cert_Mobile Signed(Priv_CA, Certificate
  Contents) The format defined in X.509
• CH1 is a randomly generated 128 bit number.
• SKCS supported shared key algorithms list.
• Base
• Verify the signature on Cert_Mobile.

11
Secure Protocol Description(2/5)

• Message 2. Base --gt Mobile (respond to
  mobile)
• Cert_Base, E(Pub_Mobile, RN1), Chosen SKCS,
  Sig(Priv_Base, E(Pub_Mobile, RN1), Chosen SKCS,
  CH1, List of SCKSs)
• Base side
• Certificate
• RN1 is a random number
• Chosen SKCS The Base chose out of the list
  presented by the Mobile.

12
Secure Protocol Description(3/5)

• Mobile side
• Validates the Certificate "Cert_Base".
• Verify under the public key (Pub_Base) of the
  signature on the message.
• Generates another random number RN2.
• Use the value (RN1? RN2) as the session key.

13
Secure Protocol Description(4/5)

• Message 3. Mobile --gt Base (respond to base)
• E(Pub_Base, RN2), Sig(Priv_Mobile,
  E(Pub_Base, RN2), E(Pub_Mobile, RN1))
• Base side
• Verify the signature using "Pub_Mobile"
• Use the value (RN1? RN2) as the session key.
• Two random value for the key limits the damage
  that can occur if the private keys of one of the
  Mobiles gets compromised.

14
(No Transcript)
15
Computation expensive

• To assess the efficiency, we count the total
  number of private key operation.
• In this protocol, the total (private key)
  operations come to four.
• Diffie-Hellman key agreement protocol has a total
  of six operation.

16
Data Packet Issues(1/2)

• Maintain decryptability of data packets in the
  presence of packet losses.
• Depend on the shared key cipher and the mode its
  operating in.
• Stream cipher
• For additive stream ciphers, the "message id"
  contains the total number of bytes previously
  sent, and it be sent in clear.

17
Data Packet Issues(2/2)

• DES cryptography
• For DES in cipher-feedback mode, the "message id"
  is the last 64-bits of cipher-text of the last
  packet.
• Checksum
• 32-bit checksum provide both integrity and
  privacy, but no playback protection.
• Playback attempt will be rejected by higher layer
  protocols like TCP/IP4.

18
Key Change Protocol(1/2)

• Base Initiate
• Base ---gt MobileSinged(Priv_Base, E(Pub_Mobile,
  New_RN1), E(Pub_Mobile, RN1))
• Mobile ---gt BaseSinged(Priv_Mobile, E(Pub_Base,
  New_RN2), E(Pub_Base, RN2))

19
Key Change Protocol(2/2)

• The value RN1? RN2 is used as the new key.
• Each side will verify the signatures on the
  messages and compare RN1 and RN2 with its
  internally stored values.
• This scheme prevent key-change message from being
  playback, without resort to sequence numbers.

20
Operation With Multiple CAs

• Modified Message 2Cert_Path, List of CRLs,
  E(Pub_Mobile, RN1), Chosen SKCS, Sig(Priv_Base,
  E(Pub_Mobile, RN1), Chosen SKCS, CH1, List of
  SKCSs
• The Base can use Certificate path, but the mobile
  not.
• Certificate path allow multiple CAs in the form
  of a CA hierarchy.
• Certificate path allow the mobile unit to verify
  the base certificate.
• Base has the responsibility of supplying the CRL.

21
Summary

• Link vs. End-to-end Security
• Same as TLS
• Use the value (RN1? RN2) as the session key.
• Computation expensive
• Key change protocol
• Certification path for Multiple CAs