Summary of 3GPP TR 33.868

3GPP2 TSG-S WG4S40-20120725-003

Source: Qualcomm IncorporatedContact(s):

Anand Palanigounder, apg@qualcomm.comAram Perez, aramp@qualcomm.com

Recommendation: For Discussion

1

NoticeQUALCOMM 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.

Overview

• Glossary• Background• Proposed Solutions• Applicability to 3GPP2

2

Glossary

3

Term MeaningAPDU Application Protocol Data UnitCAT Card Application Toolkit, a secure application that provides proactivity (ETSI)CCAT CDMA Card Application Toolkit, CAT as defined by 3GPP2CNN Core Network NodeHLR Home Location RegisterHSS Home Subscriber Server, similar to HLRIMEI International Mobile Equipment IdentityIMEISV International Mobile Equipment Identity with Software VersionIMSI International Mobile Subscriber IdentityM2M Machine-To-Machine, equivalent to MTCME Mobile Equipment, equivalent to UEMTC Machine-Type Communications, equivalent to M2MOTA Over The AirPSK Pre-shared KeyUE User Equipment, equivalent to MEUICC A physically secure device (an IC card/smart card) that executes secure

applicationsUSAT USIM Application Toolkit, CAT as defined by 3GPPUSIM Universal Subscriber Identity Module

BACKGROUND

4

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

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_Security/TSGS3_68_Bratislava/Docs/S3-120774.zip

6

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

PROPOSED SOLUTIONS

8

Types of Solutions

• At a high level, two types of solutions exist:– UICC-based solutions– Network-based solutions

9

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 EFIMEISV 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 together10

UICC-based Solutions (2)

• Solutions 1b and 2 use a file EFpairing 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

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

USAT Application

• The UICC contains a USAT application• USAT app retrieves the UE’s IMEISV during

initialization– Checks if IMEISV is in EFIMEISV

– Updates EFpairing depending on result of check

• Access is denied if UE’s IMEISV is not in EFIMEISV

13

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

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

IMSI-IMEI Binding in HSS(1)

16

UEUE CNNCNN HSSHSS

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)

IMSI-IMEI Binding in HSS(2)

1. The UE attaches to the network2. The normal AKA procedure is performed3. The Security Mode procedure is performed4. The Identification procedure is performed

during which the UE sends its IMEI5. 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)

Enhanced AKA (1)

18

UEUE CNNCNN HSSHSS

1. Attach Request, Authentication and Security Establishment

2. Identification3. Check IMSI-IMEI and

get challenge data

6. Start new security mode

Subscription and AuthenticationMaterial retrieval

4. UE authenticationchallenge

5. UE authenticationresponse

Note: The exact sequence may vary depending on the radio technology (e.g. GERAN, UTRAN, LTE)

Enhanced AKA (2)1. Normal messages for the access network2. The CNN requests and the UE provides its

identification (its IMEI and/or certificate)3. The HSS validates the IMSI-IMEI combination4. The CNN challenges the UE using a secret value

encrypted by the UE’s public key5. 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.

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

Symmetric Shared Secret (1)

21

USIMUSIM CNNCNN HSSHSS

3. AuthenticationVector

UEUE

1. Attach Request(IMSI)2. Authentication

Request(IMSI)

4. UE authenticationchallenge

6. Rand

5. DecryptRand

5. DecryptRand

7. RES8. UE authentication

response 9. Allow/De

ny

9. Allow/De

ny

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 network2.CNN requests authentication from the HSS3.HSS sends authentication vectors which have

RAND encrypted by the shared key4.CNN sends authentication challenge to UE

22

Symmetric Shared Secret (3)

5. UE decrypts RAND6. UE sends RAND to USIM7. USIM calculates RES and gives it to the UE8. The UE sends the authentication response to

the CNN9. The CNN allows or denies access to the UE

23

APPLICABILITY TO 3GPP2

24

Device Binding in 3GPP2

• Networking messaging need to be adapted to 3GPP2 messaging & architecture

25