3GPP TSG SA WG3 Meeting #9 Helsinki, Finland, 7th-9th December Source: BOSCH Telecom

S3-99510

Title: 3GPP terminal identity security: levels, requirements and mechanisms Agenda !tem: Terminal security 8.3 "ocument #or: Discussion /decision ___________________________________________________________________________

This is a living document to discuss the presents and future security levels of terminal identity ( !" #$ The re%uirements and services are defined for each security level in consideration$ &ossible mechanisms are given to be proposed to evaluate the impact of secure identity on '(&& )ecurity *rchitecture$ The first version of this document is prepared based on Doc s' 99-+,- based on .-/ to .-,/ 0hich includes a digest to the documents presented so far in s' group$ Doc s' 99-+'9 is also involved, it includes a proposal for essential re%uirements for secured terminal identity for '(&& terminals$ Two security levels are identified, protected IMEI without provability and protected IMEI with provability.

-$ &rotected !" 0ithout provability (current ()! status#

-$- 1e%uirements2 The requirements are defined after being improved by change request [ ! "#$ to %&M '(.') * . .', +oc ,-)).')/0. The wording is as follows1 1. It shall not be possible to change the IMEI after the MEs final production process. It shall resist tampering by any means (e.g. physical, electrical or software) 2. he security policy for the !oftware "ersion #umber (!"#) is such that it cannot be readily changed by the user, but can be updated with changes to the software. he security of the !"# shall be separate from that of the IMEI.

2ig.3 shows a basic scenario to realise these requirements.

dentity re%uest

dentity 50ner
Manufacturer Identity IMEI

!" ($pen Identity) !" )ystem )oft0are

3&4

Identity Module

Tamperproof hard0are entity

!"

Tamperproof area

$ig% & 'urrent Terminal !dentity conce(t in GSM

-$6 )ecurity level IMEI is sent in clear "open identity0. The following characterise the security of that terminal identity . $elatively simple to implement 4o proof of origin or type approval is possible #loning is basically possible. ,s sending an arbitrary IMEI is always possible from other terminal or other software source. , certain terminal can not be securely identified if the software is not provable. (

If the software is secured then IMEI is secure "software dependability0. 4o secured software e5ecution is 6nown without cryptographic means. 4etwor6 failed in %&M to control illegal terminals whatever the reason is for such control.

It is noted that the software security can not be separated from IMEI security and vice versa. The reasons are1 The software is the last source of IMEI and is the entity which defines IMEI. The stored IMEI is not necessary the same as the sent one If the software can be changed, then any forged IMEI could be sent. Many attac6 scenarios are possible If the software is made provable, then IMEI could be seen as somehow secure. 7owever a substitution attac6 is always possible "one scenario is to substitute the software with other copied piece of software which satisfy the software security rules0. , basic security rule is violated in this system. 8 unidentified entity is a part of the system9, this eases substitution attac6s. The same holds for the base station.

The above re%uirement 7o$ 6 appear to be contradictory 88 -$' 4sage9relevant service2 +eter using stolen terminals :lac6listing type non.approved terminals Identify emergency call terminal &IM loc6

-$+ mpact on security architecture2 4o impact. The methodology to protect IMEI by manufacturers is up to the manufacturer, as no common proof mechanism is necessary. -$: *dvantages2 3. $elatively simple to reali;e (. 4o standardi;ation is necessary

6$ &rotected and provable !"

, cryptographically secured requirements and applications IMEI is proposed for /%-- to cope with future /%--

6$- 1e%uirements proposal (source ;osch Telecom#2 3. ,n open IMEI and its corresponding secret part &IMEI is to be stored in a non.volatile memory in a tamperproof physical entity which is hard to remove from the terminal (. , common proof algorithm is to be defined to cryptographically prove that the &IMEI corresponding to IMEI resides in the terminal. /. IMEI should not be easy to modify, but if modified the proof algorithm should fail "see also <0 . The manufacturer should electronically sign IMEI before leaving the factory. 4o body other than the manufacturer should be able to generate equivalent signature. =. ,ny operator and other legitimate party should be able to offer a time varying challenge to the terminal to prove the manufacturer signature. The manufacturer publishes some open or secret means to enable the proof of its signature "prove terminal origin and thus the originally manufactured terminal quality and capability0. >. The terminal should include multiple provable mobile identities MI?s as IMEI which could be separately defined by other identity owners as operator, user, regulator, authority and others "> ! ?s with > :its and corresponding )! ?s with 3(@ :its each appear to be adequate for future needs0. The same scenario 3 to = should be possible. <. The signature &I% should also be possible to be generated from many predefined &MI?s and many predefined challenges #7?s. @. It should be possible to modify MI and &MI by the owner of &MI by presenting &MI again to the tamperproof device. This is to enable the reuse of identities by legal identity owners.

6$6 )ecurity level IMEI is sent in clear together with its "time variant challenged0 proof of signature . The following characterise the security of that terminal identity 3. -roof of origin or type approval is possible (. #loning is not possible. ,s imitating the right signature needs the secret &IMEI. /. , certain terminal can be securely identified either if the software is not secure. 4o dependency between software and identity. . 4etwor6 can identify and control illegal terminals to carry out any relevant security action without destroying other services.

6$' 4sage9relevant service2 +eter using stolen terminals :lac6listing type non.approved terminals Identify emergency call terminal $estricting some service to some class of terminals with special quality Effective implementation of the ME5E and Mobile I- security requirements

6$+ mpact on security architecture2 ,s standardised architectures are necessary, the following possible impact on security architecture is identified.

*rchitecture9possible mechanisms (source ;osch Telecom#2 , common methodology to proof IMEI via common proof.mechanism is necessary. If a provable identity is to be integrated and standardi;ed in the /%-- terminals, the following two technical requirements appear to be essential1 Hard0are 1e%uirements To be able to cryptologically identify a unique terminal, the following two physical entities are essential1 "2ig. ( shows the overall concept0 3. , tamperproof 0rite-only secret nonvolatile identity to store )! (-$$<+# 0ith -6= ;its each "whatever tamperproof means in the current state of the art technology0. The corresponding ! (-$$<+# with > bits each is also stored not necessarily protected in a write once Aread non.volatile memory (. +efine a commonly known &ignature 2unction )F. This could be achieved by using1 Either ()F-#2 a one way function " say f@ or f) or as in [>!0 which maps this secret identity &MI or many identities &MI3, &MI(....and a challenge #7 or many challenges #73, #7(....into a signature response &I% to prove the e5istence of the secret identities in the terminal ) ( > )F- ( 9)! -,)! 6$$9 , 93H-, 3H6$$$9# (symmetric function#

$r (!%2) 2 some public.6ey one way function &2( "say squaring function as $abin.Boc60 [<! which proves the e5istence of the write.only secret identities in the terminal. =

) ( > )F6 (9)! -, )! 6$$$$9, 93H-, 3H6 $$$9#

(asymmetric function#

There should be no hardware possibility "trap door0 to read any &MI. The tamperproof device should physically tied into some terminal core function.

dentity 50ner
Manufacturer Identity IMEI

5pen dentity
<+ ;its Mobile Identity 3

)ecret dentity
-6= ;its &ecret Mobile Identity 3

#hallenge 3H

! -> !"
Mobile Identity 3

)! ->) !"
&ecret Mobile Identity 3

! 6
Mobile Identity 3

)! 6
&ecret Mobile Identity 3

! '

)! '

)F )ignatur Function
"Cne way function0

&ignature )(

3&4

Identity Module

Mobile Identity 3

&ecret Mobile Identity 3

! <+

)! <+

Tamperproof area

$ig% ) Terminal identity security conce(t #or 3GPP

>

)ystem 1e%uirements These requirements are highly application and protocol dependent "tbd0. 3. Cne or many system protocols which proves the identity for relevant applications (. , central data base for some applications. This should be avoided as far as possible

6$: *dvantages2 /. . =. >. <. @. $elatively simple to reali;e D #loning is not possible &ecured proof of origin and terminal type are possible Identification security does not depend on software security Illegal terminals could be identified, counteractions do not disturb other system functions 4ew application hori;ons in /%--

1eferences2 [3! #harles :roo6son, +TI,EF, Terminal &ecurity1 $equirements for a &ecure Identity , draft discussion document, included in +oc. s/ )). '3. [(! &ecurity mechanisms for the IMEI, Ericsson, s/.)) ()> [/! -rovable Terminal Identity , &tatus and future applications, :osch . +oc s/.))(='. [ ! #$ to %&M '(.') * . .', +oc ,-)).')/ [=! #hange $equest to %&M '(.'), %&M '(.3>, %&M '/.'/ and %&M 33.3' to ensure IMEI security . +oc s/.))(3 . [>! &ecret.Fey Mechanisms for &ecured Terminal Identification , :osch, +oc s/.))3(<. [<! -rovable Terminal Identity with a -ublic.Fey Mechanism, :osch, +oc s/ .))3>@ [@! The use of Gero.Fnowledge Identification mechanisms for /% Terminal Identification , *odafone, +oc s/.))/'/. [)! $epor /%-- T&%.&, H%/ "&ecurity0 t to &, Meeting I ,Miami, (3.(/ June 3))) Michael Hal6er #hairman /%-- T&%.&, H%/ +oc s/.))()/ [3'! -roposal for IMEI &ecurity, Mannesmann, T.Mobil, +oc s/.))3'>. [33! Mobile &tation ,pplication E5cution Environment "ME5E0 /% T& (/.'=< *3./.'

<