Message Integrity and AKA for cdma2000 Release C

1. Message Integrity and AKA for cdma2000 Release C Duncan Ho July 8, 2002

2. Introduction

3. Presentation Outline • Overview of Message Integrity and AKA (Authentication and Key Agreement) • Capability and Negotiation • Key Management • Handoff • Call Flow Examples

4. Overview of Message Integrity and AKA

5. Optionality of Message Integrity and AKA • Release C is separated into two P_REV’s – 9 and 10 • For P_REV = 9 • BS and MS do not support message integrity nor AKA • For PREV = 10 • Message integrity and AKA are mandatory for the MS • Message integrity and AKA are optional for the BS (BS indicates support by the 1-bit MSG_INTEGRITY_SUP flag) • Set to ‘0’ => BS does not support message integrity nor AKA • Set to ‘1’ => BS supports message integrity. BS may or may not support AKA. As a result, the BS may perform modified 2G or AKA with MS, depending on what the AC returns to the BS and what the BS supports

6. Message Integrity • To protect Signaling messages from being modified over-the-air • A Message Authentication Code (MAC-I) is computed based on: • The message itself, the integrity key, and a crypto-sync • Can be performed whenever an integrity key is set-up • An integrity algorithm • Integrity key is set-up by either way: • Modified 2G authentication (AUTHR and CMEA key based. When AKA can not be performed) • AKA (Authentication vector and IK based) • Strength depends on the key size (not physical key size but the entropy) • CMEAkey strength is 64-bit • IK is 128-bit • Receiver validates the MAC-I • If the message is altered during transmission, the MAC-I will not check and the message will be ignored by the receiver

7. Computation Of MAC-I

8. Modified 2G Authentication (1) • Similar to 95B authentication… • RAND, AUTHR based, 64-bit CMEA key • A-key shared between UIM and AC • SSD_A and RAND used for computing AUTHR

9. Modified 2G Authentication Procedures (2) • Steps different than 95B are in red: • BS broadcasts RAND and indicates message integrity capability in MSG_INTEGRITY_SUP flag • MS registers. MS computes AUTHR in Registration, Origination and Page Response Message • AC validates AUTHR and computes the CMEA key associated with the AUTHR • BS repeats the CMEA key to form a 128-bit Integrity Key • BS sends a Registration Accepted Order integrity protected by the Integrity Key • MS computes the same CMEA key associated with the AUTHR • MS validates the Registration Accepted Order. If valid, MS sends back a Registration Completion Message integrity protected by the Integrity Key • BS validates the Registration Completion Message. If valid, the Integrity Key is set-up successfully

10. Modified 2G Authentication (3)

11. AKA (1) • Allows UIM and BS to perform mutual authentication • Root key (K-key) shared by UIM and AC • Entities involved • UIM <->ME<->BS<->MSC/VLR<->HLR/AC • AKA Procedures: • AC pre-computes a set of Authentication Vectors (AV’s) based on K-key • BS sends one AV to the MS when the MS registers • MS authenticates the BS based on the AV • BS authenticates the MS based on the response from the MS • Integrity Key (IK) and User Authentication Key (UAK) are set-up upon completion of AKA • UAK is stored inside the UIM while IK in the ME

12. AKA (2) * If supported by the network

13. Authentication Vector • AV = (RANDA, AUTN, XRES, CK, IK, UAK) • RANDA – the random number to compute the other elements in the vector • AUTN – authentication Token. Contains sequence number and signature of BS • XRES – expected response from the MS • CK – cypher key (key for encryption) • IK – integrity key (key for message integrity) • UAK – user authentication key (key for authenticating the UIM. Optionally supported by the AC)

14. The Need of UAK (1) • To prevent a rogue MS from passing integrity check when the R-UIM is removed • Scenario: • UIM computes IK and transfer it to the ME • ME performs message integrity using the stored IK • If the UIM is removable (R-UIM), a rogue ME could be programmed to send valid messages even after removal of the R-UIM

15. How UAK Works • To avoid the above scenario, UIM Authentication Key (UAK) is introduced • UAK is stored in the UIM only, and never passed to the ME • When ME performs message integrity: • ME passes MAC-I of the message to UIM • UIM converts MAC-I into a User MAC (UMAC) • UMAC is sent with the message, for BS to validate • Now if the UIM is removed, UMAC can not be computed and hence can not be validated by the BS

16. Capability and Negotiation

17. Capability (1) • BS indicates the following fields in the Extended System Parameters Message and ANSI-41 System Parameters Message • MSG_INTEGRITY_SUP • Set to ‘0’ => BS does not support message integrity nor AKA. MS will not perform any enhanced authentication procedures. Regular 95B style authentication procedures will be performed if turned on at the BS • Set to ‘1’ => BS supports message integrity. MS will start with modified 2G authentication. BS then either continues with the modified 2G or initiate AKA, depending on what the AC returns to the BS and whether the BS supports AKA • SIG_INTEGRITY_SUP • Specifies what integrity algorithms, in addition to the default one, the BS supports

18. Capability (2) • MS indicates the following in Registration/Origination/Page Response Msg • SIG_INTEGRITY_SUP • Specifies what integrity algorithms, in addition to the default one, the MS supports • SIG_INTEGRITY_REQ • Specifies the requested integrity algorithm • NEW_KEY_ID • A unique identifier assigned to the CMEAkey associated with the AUTHR of this msg

19. Negotiation (1) • There is one default integrity algorithm defined • When the MSG_INTEGRITY_SUP field is set to 1, the MS and BS both have to perform message integrity • Can only negotiation for different integrity algorithms • MS finds out what integrity algorithm(s) the BS supports • MS then requests for an algorithm that is supported by both BS and MS • BS sends back a command to order the MS to use the one selected by the BS • Indicated by the MAC-I included in the Registration Accepted Order in modified 2G case and Security Mode Command Message in AKA case

20. Key Management • For modified 2G authentication, a new CEMA key is generated every time the MS sends the Registration/Origination/Page Response Msg, the integrity key will also change accordingly • Exception: if the BS decides to rely on using the MAC-I to validate a subsequent registration of a MS that has already been registered, the BS is not required to setup a new CMEA key • For AKA, a new integrity key is generated only if the BS performs AKA and sends a new AV to challenge the MS, or if the MS registers without a valid MAC-I, which triggers AKA • Each integrity protected message includes the crypto-sync, MAC-I and a KEY_ID, which index which integrity key was used to compute the MAC-I • This KEY_ID is assigned to a any integrity key successfully setup by the MS and BS

21. Handoff • When a MS is being handoff to a new BS, the current BS should send the following info to the new BS: • The 128-bit Integrity key currently being used • The 2-bit KEY_ID associated with the integrity key currently being used • The 32-bit crypto-sync value currently being used • The integrity algorithm currently being used • The integrity algorithm(s) supported by the MS (indicated by the 8-bit SIG_INTEGRITY_SUP)

22. Call Flow Examples

23. AV Sequence Number Out-of-Sync

24. Loss of Radio Contact (1)

25. Loss of Radio Contact (2)