1. Summary of 3GPP TR 33.868 3GPP2 TSG-S WG4 S40-20120725-003 Source: Qualcomm Incorporated Contact(s): Anand Palanigounder, apg@qualcomm.comapg@qualcomm.com Aram Perez, aramp@qualcomm.comaramp@qualcomm.com Recommendation: For Discussion 1 Notice QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non- discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

2. Overview Glossary Background Proposed Solutions Applicability to 3GPP2 2

3. Glossary 3 TermMeaning APDUApplication Protocol Data Unit CATCard Application Toolkit, a secure application that provides proactivity (ETSI) CCATCDMA Card Application Toolkit, CAT as defined by 3GPP2 CNNCore Network Node HLRHome Location Register HSSHome Subscriber Server, similar to HLR IMEIInternational Mobile Equipment Identity IMEISVInternational Mobile Equipment Identity with Software Version IMSIInternational Mobile Subscriber Identity M2MMachine-To-Machine, equivalent to MTC MEMobile Equipment, equivalent to UE MTCMachine-Type Communications, equivalent to M2M OTAOver The Air PSKPre-shared Key UEUser Equipment, equivalent to ME UICCA physically secure device (an IC card/smart card) that executes secure applications USATUSIM Application Toolkit, CAT as defined by 3GPP USIMUniversal Subscriber Identity Module

4. BACKGROUND 4

5. 3GPP TR 33.868 (1) Studies the security aspects of MTC – Based on: TS 22.368 – The requirements for MTC TR 23.888 – A report on MTC related system improvements Section 5.6.3 covers the requirement in TS 23.368 (see slide on TS 23.368) 5

6. 3GPP TR 33.868 (2) Section 7.5 provides solutions for the mentioned requirement The document used for this summary is available at http://www.3gpp.org/ftp/tsg_sa/WG3_Securi ty/TSGS3_68_Bratislava/Docs/S3-120774.zip 6

7. 3GPP TS 22.368 Sets the requirements for MTC Has the following requirement: “The network operator shall be able to restrict the use of a USIM to specific MEs/MTC Devices.” In the “Access Control with billing plan Use Case”, it states: “It should be possible to associate a list of UICC to a list of terminal identity such as IMEISV so that if the UICC is used in an other terminal type, the access will be refused.” This document is available at http://www.3gpp.org/ftp/Specs/archive/22_series/22. 368/22368-b50.zip 7

8. PROPOSED SOLUTIONS 8

9. Types of Solutions At a high level, two types of solutions exist: – UICC-based solutions – Network-based solutions 9

10. UICC-based Solutions (1) There are several proposed solutions: – 1a) Secure Channel – PSK – 1b) Secure Channel – Certificates – 2) USAT application – 3) PIN presentation Solutions 1b and 2 use a file EF IMEISV that contains a list of authorized UEs based on their IMEISVs – File can be updated via an OTA mechanism Solutions 2 and 3 can be used together 10

11. UICC-based Solutions (2) Solutions 1b and 2 use a file EF pairing to contain the status of the last IMEISV to access the UICC – “OK”: IMEISV is authorized – “KO”: IMEISV is not authorized File also records the last IMEISV attempting access 11

12. Secure Channel Based on ETSI TS 102 484, Application-to- Application Secured APDU Two options: use a PSK or a certificate exchange “The provisioning of certificates and pre-shared key can be performed during personalization phase of the MTC ME or UICC” – However, “Provisioning during the personalization phase is out of scope” UE must establish secure channel before access is granted to the network 12

13. USAT Application The UICC contains a USAT application USAT app retrieves the UE’s IMEISV during initialization – Checks if IMEISV is in EF IMEISV – Updates EF pairing depending on result of check Access is denied if UE’s IMEISV is not in EF IMEISV 13

14. PIN Verification The UE must present a valid PIN before the USIM executes PIN can be updated via an OTA mechanism Can be used to enhance to the USAT Application solution 14

15. Network-based Solutions There are several proposed solutions: – 1) IMSI-IMEI binding in HSS/HLR – 2a) Enhanced AKA – HSS/HLR provides root certificate – 2b) Enhanced AKA – HSS/HLR provides the UE’s public key – 3) Symmetric Shared Secret 15

16. IMSI-IMEI Binding in HSS(1) 16 UE CNN HSS 1. Attach Request(IMSI) 2. AKA Procedure 3. Security Mode AKA Procedure 4. Identification 5. Location Update Note: The exact sequence may vary depending on the radio technology (e.g. GERAN, UTRAN, LTE)

17. IMSI-IMEI Binding in HSS(2) 1.The UE attaches to the network 2.The normal AKA procedure is performed 3.The Security Mode procedure is performed 4.The Identification procedure is performed during which the UE sends its IMEI 5.The CNN updates the UE’s location, informing the HSS of the IMSI and IMEI – The HSS decides whether to grant access based on the IMSI IMEI combination 17 Note: The exact sequence may vary depending on the radio technology (e.g. GERAN, UTRAN, LTE)

18. Enhanced AKA (1) 18 UE CNN HSS 1.Attach Request, Authentication and Security Establishment 2. Identification 3. Check IMSI-IMEI and get challenge data 6. Start new security mode Subscription and Authentication Material retrieval 4. UE authentication challenge 5. UE authentication response Note: The exact sequence may vary depending on the radio technology (e.g. GERAN, UTRAN, LTE)

19. Enhanced AKA (2) 1.Normal messages for the access network 2.The CNN requests and the UE provides its identification (its IMEI and/or certificate) 3.The HSS validates the IMSI-IMEI combination 4.The CNN challenges the UE using a secret value encrypted by the UE’s public key 5.The UE responds to the challenge using the secret value it decrypted from step 4 – This secret value is used to enhance the normal AKA 6.If the response to the challenge is valid, the new enhanced AKA security mode is used 19 Note 1: The exact sequence may vary depending on the radio technology (e.g. GERAN, UTRAN, LTE) Note 2: The steps are worst case for the first access by a particular IMSI-IMEI pair and can be optimized on subsequent access attempts.

20. Enhanced AKA Variations HSS Provides Root Certificate Step 2 – CNN requests UE’s IMEI and certificate and the UE provides them Step 3 – HSS validates IMSI-IMEI pair – HSS returns root certificate for UE HSS Provides UE’s Certificate Step 2 – CNN requests the UE’s IMEI and the UE provide it Step 3 – HSS validates IMSI-IMEI pair – HSS sends the public key for the UE 20

21. Symmetric Shared Secret (1) 21 USIM CNN HSS 3. Authentication Vector UE 1. Attach Request(IMSI) 2. Authentication Request(IMSI) 4. UE authentication challenge 6. Rand 5. Decrypt Rand 5. Decrypt Rand 7. RES 8. UE authentication response 9. Allow/Den y

22. Symmetric Shared Secret (2) A secret symmetric key is provisioned at the UE and HSS Could also be considered an “enhanced AKA” 1.UE attempts to attach to the network 2.CNN requests authentication from the HSS 3.HSS sends authentication vectors which have RAND encrypted by the shared key 4.CNN sends authentication challenge to UE 22

23. Symmetric Shared Secret (3) 5.UE decrypts RAND 6.UE sends RAND to USIM 7.USIM calculates RES and gives it to the UE 8.The UE sends the authentication response to the CNN 9.The CNN allows or denies access to the UE 23

24. APPLICABILITY TO 3GPP2 24

25. Device Binding in 3GPP2 Networking messaging need to be adapted to 3GPP2 messaging & architecture 25