EAP SIM and AKA

1
EAP SIM and AKA

• Jari Arkko, Henry Haverinen, Joseph Salowey
• (presented by Pasi Eronen)

2
Introduction

• Authentication based on GSM SIM and UMTS USIM
  smart cards
• Neither the users terminal nor EAP server has
  direct access to the shared secret key
• We rely on GSM/UMTS key agreement protocols

3
EAP SIM status

• Quite stable
• Some updates based on Sarvar Patels analysis
• When multiple RANDs used, client checks that they
  are different
• Clarified security considerations section
• Aligned key derivation with 2284bis
• AT_CHECKCODE

4
EAP AKA status

• Stable
• Aligned key derivation with 2284bis
• AT_CHECKCODE

5
N bits of security

• 2284bis If the effective key strength is N
  bits, the best currently known methods to recover
  the key (with non-negligible probability) require
  an effort comparable to 2N operations of a
  typical block cipher.
• Must not mix the probability of 264 and the work
  of 264 operations!
• Attacks with 264 work are interesting attacks
  with success probability of 264 are not very
  interesting

6
N bits of security

• EAP SIM key strength is 64 bits with one
  triplet, and 128 bits with 2 or 3
• New text strongly recommends that both client and
  server require at least 2 triplets
• If the same SIM is used in GSM/GPRS, attacker can
  use their vulnerabilities
• No need to use SRES to increase key strength

7
RAND re-use within one exchange

• Obviously, if multiple triplets are used, the
  server chooses different triplets
• The latest version also requires the client to
  check this

8
RAND re-use in different exchanges

• EAP SIM requires that the server always uses
  fresh RANDs
• Client cant check if RANDs are fresh
• (Keeping a list of all previously seen RANDs is
  not probably feasible)
• Well-known limitation of GSMchanged in UMTS
  (AKA)
• Discussed extensively in security considerations
  section

9
Alternative protocols

• Main goals in current protocol
• Use existing SIM cards without changes
• gt800,000,000 deployed
• When they are redeployed, will support EAP AKA
• Keys that allow impersonating as the user (for
  longer than the current session) are never
  handled outside SIM and AuC
• This would undermine integrity of charging
• Keys that allow impersonation as the network are
  handled in user terminal and EAP server

10
Next steps

• Wait until 2284bis is finished
• Get reviews and publish as informational RFCs