Proving IEEE 802'11i Secure

1
Proving IEEE 802.11i Secure

• Changhua He, Mukund Sundararajan, Anupam Datta,
  Ante Derek,
• John C. Mitchell
• Stanford U.

2
Evolution of WLAN Security

• Ongoing efforts at IEEE to develop WLAN security
  standards
• WEP issues
• WEP lacks key mgt
• Bad crypto
• 802.11i is designed to fix these issues (June
  2004)

3
802.11i Key Management
Auth Server
Laptop
Access Point
(Shared Secret-PMK)
4
Main result 802.11i is secure

• A Formal Proof in Protocol Composition Logic
  (PCL) of
• On execution of an 802.11i role, properties
  listed in the standard are satisfied.
• Characterize protocols that may keys with 802.11i
  
• Previous work finite-state of the 4-Way, DOS
• HM04, HM05

5
Properties of 802.11i Key Mgt.

• 802.11i / D10.0, RFC 2246 for TLS
• Roughly
• Only authorized devices can join n/w
• Devices do not join rogue n/w
• Peer device is alive
• Keys set up for data and group communication are
  fresh and secret
• Attacker model (perfect crypto)
• Intercept, read, reorder, delete any message on
  the n/w
• Construct, send messages

6
Flaws Due to Modular Design

• Secure modules may interact insecurely
• TLS Benaloh et. al. 95
• Confusion of signed messages used in main
  protocol and resumption protocol
• GDOI Meadows, Pavlovic 04, Chosen protocol
  attacks Kelsey et. al. 98
• Moral Not sufficient to check correctness of
  modules
• Focus of this talk!

7
The security checklist
Laptop
A.P.
A.S.
Group key Authenticator
802.11i
8
Presentation Flow

• Basic motivation and statement of problem
• Statement of result
• Flaws from modularity
• Security of TLS client
• Security of 802.11i
• Error handling
• 802.11i lessons

9
TLS Client (S, suiteC)

• 1. Hello send C, S, nc,
  suiteC
• 2. Hello Reply receive S, C, ns,
  suiteS, certS
• 3. Check Cert check certS
• 4. Key Xfer send C, S, secKs ,
  certC, SIGC(hndshk1)
• 5. Server View receive S, C
  hashsec(hndshk2)
• 6. Check View check hashsec(hndshk2)
  

10
Security Properties of TLS

• The client and the server agree on
• Value of the secret
• Version and crypto suite
• Identities
• Protocol completion status
• The secret term is not known to a principal who
  is not the client or the server

11
TLS Client Guarantee Auth

• Honest(S) ? (S, suiteC) TLS ClientC
• ? S. Send ( C, Hello)
• ? Receive ( S, Hello )
• ? Send ( S, Hello Response)
• ? Receive( C, Hello Response )
• ? Send ( C, KeyXfer)
• ? Receive ( S, KeyXfer)
• ? Send( S, ServerView)
• ? Receive( C, ServerView)

12
TLSClient Network Invariants

• Honest(S) ? Send (S, hashsec(hndshk2)) ?
• Receive ( S , ltC, S, nc, suiteC gt)
• ? Send ( S , ltS, C, ns, suiteS, certS gt)
• ? Receive ( S , lt C, S, secKs , certC,
  SIGC(hndshk1) gt)
• ? Send ( S ,lt hashsec(hndshk2) gt)
• 2. New(S, ns )

13
TLS Client Auth Proof Sketch

• 1. C sees hashsec(messages), concludes someone
  who knows sec sent it
• 2. From secrecy proof, C is assured that only C
  and honest S know sec
• 3. Concludes honest S sent hashsec(messages)
• 4. If honest S sent hashsec(messages), then it
  also executed TLS server role
• 5. Order actions based on nonces used
• 6. Intended execution

14
Correctness of TLS Client
Laptop
A.S.
A.P.
Group key Authenticator
15
Proof of TLS Authentication in PCL
Verify hash
Secrecy proof
EC Server executed
16
TLS Authentication Matching Conversations
Order actions
This is the intended execution!
17
Proof structure of 11i

• One proof per role
• Each role has invariants
• Some roles have preconditions
• TLS Server
• 4-Way Handshake Laptop
• 4-Way Handshake Access Point
• Group Key Handshake Laptop
• Group Key Handshake Access Point
• See paper for details

18
Why is 802.11i safe? Formally,

• We prove
• Individual Modules function correctly assuming
  n/w invariants, preconditions hold on entry
• Prior modules set up shared secrets,
  preconditions are implied by post-conditions of
  prior modules
• All Network Invariants are preserved by all
  modules of the system

19
Linear flows of 11i are safe
Composition theorem Datta et. al. 04
Preconditions satisfied on entry, Network
invariants preserved
20

802.11i Design Decisions

• Key derivation
• Subsequent protocols do not use keys directly
• decryption oracles, authenticator confusion
  across modules
• Within modules,
• Authenticators have sufficient information
• Except - lack of identity in 4Way, Group Key
  protocols
• Principals do not play both roles
• Is an assumption on the deployment

21
Error Handling HM05
22
802.11i Is Secure Under Family of Error Handling
Strategies
Staged Composition
23
Protocol insights

• 802.11i is secure under a family of error handing
  mechanisms -gt pick one!
• Other modes are safe
• Using Cached PMKs and Pre-shared Keys is safe
• Protocols can share certificates with TLS as
  long as conditions listed in paper are satisfied

24
Summary

• 802.11i Key Management is secure
• Network invariants characterize safe operating
  conditions
• Modular proofs
• Consider replacing TLS by PEAP
• Help rationalize architecture
• Error handling
• Divide and conquer

25
PCL Proofs Are Sound in the Symbolic Execution
Model

• Attacker model
• Signature, encryption require keys.
• Learning contents of encryption requires
  decryption key.
• Hashes collision free, second pre-image
  resistant, hard to invert.
• Intercept, read, reorder, delete any message on
  the n/w.
• Construct, send messages.
• Efforts to extend logical framework to more
  realistic models.
• - M. Backes, B. Ptzmann, and M. Waidner. A
  universally composable crypto-graphic library.
  Cryptology ePrint archive, report 2003/015,
  2003.- D. Micciancio and B. Warinschi. Soundness
  of formal encryption in thepresence of active
  adversaries. In theory of cryptography conference
  -proceedings of TCC 2004, volume 2951 of lecture
  notes in computer science,pages 133151.
  Springer- Verlag, 2004.- A. Datta, A. Derek, J.
  C. Mitchell, V. Shmatikov, M. Turuani,probabilist
  ic polynomial-time semantics for a protocol
  security logic, inproceedings of 32nd
  international colloquium on automata, languages
  andprogramming, pp. 16-29, July 2005.

26
TLS Flaw

• Two protocols
• Key establishment protocol
• Resumption protocol
• Client signs encryption of secret term
• Authenticators are identical
• I breaks weak crypto in real time
• C initiates resumption protocol with S
• I Initiates new session with strong crypto S uses
  C to authenticate

27
GDOI flaw

• Two protocols
• IKE
• Group Key pull protocol
• Client demonstrates proof of possession of
  credentials by signing terms
• Lack of Binding
• Allows rouge server (I) to join group of honest
  server (S) by using session running with honest
  client (C).

28
4Way Handshake

• Protocol description
• Uses shared secret , exchanged nonces to create
  PTK (Pair-wise Transient Key) , performs exchange
  of authenticators
• Properties
• The PTK generated is fresh and correctly
  generated from the PMK
• Messages 2 and 4 indicate to the Authenticator
  that the Supplicant is alive
• Message 3 indicates to the Supplicant that the
  Authenticator is alive.

29
Network Invariants for the 4way Handshake

• Condition that principal does not play both roles
  simultaneously
• Else, reflection attack
• A deployment constraint
• And other conditions

30
The Group Key Handshake

• Protocol description
• Uses PTK to distribute group key
• Sequence numbers and keyed hashes provide
  authentication and ordering
• Properties
• Supplicant is guaranteed that current GTK was
  generated and sent by the client after the old
  GTK was generated and sent
• Authenticator is guaranteed that anyone who knows
  the GTK must share a PTK with it
• Similar Environmental Conditions

31
Network Invariants for the Group Key Handshake

• For Authentication and ordering
• Honest principal does not play both role
• Needs secrecy of PTK
• Honest A.P. uses sequence numbers in an ascending
  manner
• For Secrecy of GTK
• Honest principals do not send out the contents of
  terms learnt via decryption
• Unless they received the term in the clear earlier

32
Network Invariants Proved by Induction
33
Checking Network Invariants

• Honest principals execute role programs P1, P2,
  P3 Pn
• Check network invariants against initial
  segments of every Pi

34
Network Invariants and Flaws

• Consider failure of invariant of clientAuth
  proof
• Server peer malfunctions
• Client reflection attack
• Other role authenticator confusion
• Invariants need to hold for all modules in the
  n/w