USECA. Project Number Project Title Deliverable Type. USECA: UMTS Security Architecture. Deliverable Number Title of Deliverable

Transcription

1 SEC Project Number Project Title Deliverable Type Security Class Deliverable Number Title of Deliverable Nature of the Deliverable Document reference Contributing WPs Contractual Date of Delivery ctual Date of Delivery Eitor C336 SEC: MTS Security rchitecture Report Public D04 Intermeiate report on the MTS SIM Intermeiate eliverable C336/G&D/W25/DS/P/004/b1 WP2.5 February 1999 (Y1M12) 1 pril1999 lrich Heckmanns, Giesecke & Devrient bstract Keywors This report contains intermeiate results of WP2.5 about the SIM in MTS. In particular, a protocol escription language for authentication will be escribe. This language focuses on public-key infrastructure, but can also be applie to symmetric crypto-systems. CTS, SEC, MTS, SIM, Protocol escription language

2 SEC SEC D04 Intermeiate report on the MTS SIM Page 2 of Executive Summary In work package 2.5 the SIM, the smart car for MTS, is investigate. Results of WP2.5 will influence WP2.7, "Demonstrations". The main objective of the SIM part of these work packages is to give a viable specification for the SIM. When work for WP2.5 (in particular for this eliverable) starte, it was still assume that authentication in MTS coul be base on a public key infrastructure with new features compare to GSM. mong other avantages, a great flexibility of authentication proceures coul have been achieve using public key techniques. For this, a protocol escription language was evelope. sing this language, all participating parties of MTS will be able to communicate on protocols for authentication in MTS in a stanarise way. Moreover, it will be easy to evelop an implement new protocols. Even if the protocol escription language focuses on public key techniques, it inclues symmetric key techniques as a special case. Thus, it is feasible to apply it also for MTS phase 1. This will allow a smooth migration to later phases which might be base on public key techniques. Furthermore, SEC anticipates the use of PK for application security an e-commerce. This eliverable gives a high-level escription of the protocol escription language an of a proposal for the smart car in MTS. In later papers an eliverables a low-level specification will follow. C336/G&D/W25/DS/P/004/b1

3 SEC SEC D04 Intermeiate report on the MTS SIM Page 3 of Table of contents 1. EXECTIE SMMRY TBLE OF CONTENTS DOCMENT MNGEMENT CONTRIBTORS DOCMENT HISTORY REFERENCES BBREITIONS INTRODCTION GENERLITIES DISCSSION OF THE REQIREMENTS ND THEIR INTERRELTION THE PROTOCOL DESCRIPTION LNGGE (PDL) GENERLITIES The protocol execution elements Equations for the protocol escription Functions an keys in the protocol escription first example for an algorithm Further agreements on protocol escriptions First example of a protocol escription Symmetric crypto-systems RELISTION ON THE SIM J ND DOWNLODING CONCEPT RELISTION IN MTS SMPLE LISTS List of equations List of algorithms List of protocols CERTIFICTES ENHNCED FETRES OF THE PROTOCOL DESCRIPTION LNGGE THENTICTION PROCEDRES FOR MTS GENERL SSMPTIONS SIEMENS PROTOCOL G&D SMPLE PROTOCOL Scenario Scenario B...27 C336/G&D/W25/DS/P/004/b1

4 SEC SEC D04 Intermeiate report on the MTS SIM Page 4 of Scenario C GSM THENTICTION MTS PHSE CONCLSIONS ND OTLOOK...31 C336/G&D/W25/DS/P/004/b1

5 SEC SEC D04 Intermeiate report on the MTS SIM Page 5 of Document management 3.1 Contributors lrich Heckmanns (Eitor) Giesecke & Devrient, Prinzregentenstr. 159, D München, Germany Phone: / Fax: ulrich.heckmanns@gm.e 3.2 Document history ersion Date Comment 23/12/1998 Initial raft B 1/3/ n raft C 5/3/ r raft D 22/3/1999 Final raft E 1/4/99 ersion for PMC approvla 3.3 References [SP-D02] CTS SPeCT C095 eliverable 02, Initial report on security requirements, 1996 [SP-D15] CTS SPeCT C095 eliverable 15, The IM: First specification, 1997 [SP-D20] CTS SPeCT C095 eliverable 20, Project final report an results of trials, 1999 [GSM02.19] GSM Digital cellular telecommunications system (Phase 2+) Subscriber Ientity Moule pplication Programming Interface (SIM PI); Service escription; Stage 1, ersion Release 1998 [GSM03.19] GSM Digital cellular telecommunications system (Phase 2+); Subscriber Ientity Moule pplication Programming Interface (SIM PI); Java Car SIM PI; Stage 2, ersion [GSM03.48] GSM Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the SIM application toolkit; stage 2, ersion [GSM11.11] GSM Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Ientity Moule - Mobile Equipment (SIM - ME) interface, ersion [GSM11.14] GSM Digital cellular telecommunications system (Phase 2+); Specification of the SIM pplication Toolkit for the Subscriber Ientity Moule - Mobile Equipment (SIM- ME) interface, ersion 7.1.0, November 1998 [HP98] G. Horn an B. Preneel, uthentication an payment in future mobile systems. In: Computer Security - ESORICS 98, Louvain-la-Neuve, Belgium, , Proceeings, p , publishe as LNCS 1485, Springer, [MeOoa]. Menezes, P. van Oorschot, S. anstone: Hanbook of pplie Cryptography; CRC Press, Boca Raton, 1997 [SG-169/96] ETSI SMG SG DOC 169/96, General authentication framework for MTS, June 1996 [MTS21.11] MTS niversal mobile telecommunication system (MTS); SIM an IC Car Requirements, ersion ( ) C336/G&D/W25/DS/P/004/b1

6 SEC SEC D04 Intermeiate report on the MTS SIM Page 6 of 31 [MTS22.71] [MTS33.21] [MTS33.23] [SE-D03] [SE-D06] MTS niversal mobile telecommunication system (MTS); Service aspects; utomatic Establishment of Roaming Relationships, ersion ( ) MTS niversal mobile telecommunication system (MTS); Security Requirements, ersion ( ) MTS niversal mobile telecommunication system (MTS); Security Mechanisms an rchitecture, ersion ( ) CTS SEC C336 eliverable 3, Requirements on a PKI for MTS CTS SEC C336 eliverable 6, Intermeiate report on MTS security mechanisms 3.4 bbreviations 3GPP CTS PI SPeCT ETSI GSM HE IMI JCF MS OT PDL PK PKI PLMN SIM SMG SN TTP MTS SEC SIM OP Thir Generation Partnership Project vance Communications Technologies an Services pplication Program Interface PI vance Security for Personal Communications Technologies European Telecommunications Stanarisation Institute Global System for Mobile communications Home Environment International Mobile ser Ientity Java Car Forum Mobile Station Over the air Protocol Description Language Public Key Public Key Infrastructure Public Lan Mobile Network Subscriber Ientity Moule Special Mobile Group Serving Network Truste Thir Party niversal Mobile Telecommunication System MTS SECurity rchitecture ser Services Ientity Moule isa Open Platform C336/G&D/W25/DS/P/004/b1

7 SEC SEC D04 Intermeiate report on the MTS SIM Page 7 of Introuction 4.1 Generalities In this eliverable we propose a protocol escription language for use in MTS. In particular protocols for authentication of MTS users to networks an vice versa can be formulate using this language. However, here we will give only a high-level escription of a possible realisation of the protocol escription language on the SIM, the equivalent of the SIM car for MTS. We still have to evelop a low-level specification for the SIM - comparable to [GSM11.11] an [SP-D15] - in forthcoming papers, either in SEC eliverables or intermeiate input ocuments to SEC. The structure of this eliverable was evelope when stanarisation of MTS was still carrie out by ETSI. t this time it was expecte to base MTS on a public key structure an to implement a lot of new features into MTS. However, in the meantime, the time scheule for introucing MTS in the fiel has largely change. Due to a much shorter uration for the specification of MTS, many structures from GSM will still exist in phase 1 of MTS. In particular, authentication will still be base on symmetric key structures. nother reason for that is the greater complexity of PK techniques. However, for later phases, it is possible that the security structure will migrate to public key base systems. Therefore, both cryptographic structures shoul be taken into consieration as well as the possibility of a smooth migration from one that is symmetric key base to one that is public key base. Thus, it is worth mentioning that the protocol escription language escribe in this paper serves both systems. However, here we focus on public key structures. Since, roughly speaking, symmetric key structures are less complex, a reuction to the latter coul easily be achieve. Even if there is currently no final ecision on how MTS will look, the following goals concerning security in MTS seem to be esire: 1. To make MTS safer than GSM an other contemporary networks, both fixe an mobile ([MTS33.21, section 4]). 2. Flexibility in the authentication process, even after the SIM has been issue. 3. Support of automatic roaming agreements (see [MTS22.71]). 4. voiing traffic, in particular between the home environment an a (visite) network. 4.2 Discussion of the requirements an their interrelation In GSM, roaming mainly takes place between network operators in orer to allow their customers to use telecommunication services when they are not situate in their home PLMN. However, this alreay causes a lot of effort which, from the network operator s point of view, shoul be reuce. In MTS the nee for such roaming agreements will largely increase. One reason is that it is thought that the number of network operators an users will expan. nother is that service proviers can also issue MTS subscriptions rather than only network operators. Therefore it is propose to involve truste thir parties which coul perform one or several of the following tasks: - negotiation an management of roaming agreements - issuing of certificates for serving networks - issuing of certificates for users - management of revocation lists. Of course, this will make the authentication process of a MTS subscriber, represente by his or her smart car, to the (visite) network more ifficult. Following the current proceure in GSM, this woul mean that, at least, a two-way communication between mobile - serving network, serving network - truste thir party an truste thir party - home environment, respectively, is necessary, in contrast to requirement 4. solution to this problem can be achieve by the employment of a public key infrastructure, in C336/G&D/W25/DS/P/004/b1

8 SEC SEC D04 Intermeiate report on the MTS SIM Page 8 of 31 particular public certification techniques. The online employment of truste thir parties for phase 1 is not very promising. However, one coul also think of certification techniques using symmetric key structures. These structures coul easily be escribe using the protocol escription language. However, since they are currently not uner iscussion, we o not treat them comprehensively. Moreover, they usually imply a quite costly key management. Of course, truste thir parties coul support at least the first of the above bullets offline, comparable to clearing houses in GSM. However, offline structures of MTS are beyon the scope of this paper. smooth migration from GSM to such a system also has impact on Req. 2, since it is likely that in an early MTS phase many structures from GSM will still exist, e.g. roaming agreements between network operators. Of course, the stanarisation of MTS shoul then allow a later change to more involve systems. Therefore the protocols use in MTS have to be flexible an easy changeable. Req. 2 is also relate to Req. 1: successfully attacke algorithm has to be replace. This coul be one over-the-air. However, an over-the-air replacement of either algorithms or protocols involves a big threat. This is in particular true, if ownloaing of the new algorithm has to be authenticate by the ol, attacke one. However, this problem coul be solve by implementing a fall back algorithm which will be use only for such purposes. Naturally, in authentication processes secret keys of the subscriber are involve. These keys shoul never leave the SIM in plain format. Therefore all calculations for authentication etc. shoul performe completely within the SIM. Currently, there are several proposals uner iscussion how to make MTS safer than GSM. Whereas the current GSM authentication of the user to the network can be consiere as safe, it causes some problems that the network oes not authenticate itself to the user. Current proposals for countermeasures are base on two requests: first, to be realisable within a symmetric key structure an, secon, to be close to the GSM authentication proceure. Compare 5.7. In this paper we are mainly concerne with Req. 2. In particular, we escribe a protocol escription language which permits the evelopment of a certain protocol an to escribe its effect even without fixing particular cryptographic algorithms prior to its execution. C336/G&D/W25/DS/P/004/b1

9 SEC SEC D04 Intermeiate report on the MTS SIM Page 9 of The protocol escription language (PDL) 5.1 Generalities The protocol execution elements The boy of a protocol escription consists of an arbitrary sequence of the five protocol execution elements: 1. Calculate 2. Sen 3. Execute subprotocol 4. If-then-else control structure 5. Counter "calculate element" mainly consists of symbols for certain ata, e.g. keys or alreay calculate values, an symbols for functions. The functions, together with the use keys, are liste in the heaing of the protocol escription. Prior to execution of the protocol, these symbols have to be replace by concrete functions. Then "calculating" means obtaining the necessary input ata an apply these functions as prescribe in the calculate element, thus proucing a certain output value. "sen element" might, for instance, specify: " sens m to B" which has a straightforwar meaning. However, in authentication protocols for MTS, might be a user, represente by his SIM an B might be a network. Therefore, the specification of the SIM shoul, in this example, force the car to eliver m to the mobile, together with the comman to forwar m to the network. In the following, we always agree on this proceure - an vice versa - when we speak about a sen element in connection with a MTS user or a SIM, respectively. However, for certain purposes it might be esirable to ifferentiate between SIM an ME. Note that this can easily be one, even if this increases the complexity of the iagrams of the protocols. In particular, for security analysis of protocols this shoul be taken into consieration. For example, ata exchange between SIM an mobile coul have been manipulate by a compromise mobile. In an "execute subprotocol element" it is especially important to specify the interface. For instance, such an element has to efine which concrete functions have to be replace for the function symbols occurring in the subprotocol, similar for keys an other ata. See 5.7 for explanatory examples of subprotocols, ifthen-else control structures an counters. The meaning of an "if-then-else control structure" is straightforwar. To each entity participating in the protocol execution a counter C (or several counters C 1, C 2,...) is assigne. Each counter has a value in the set of natural numbers 0, 1, 2,.... During protocol execution this value can be change by the following commans of the protocol escription language: - INC(C ) Increases the value of C by 1. - SET(C, N) Sets the value of C = N, where N is a natural number, also enote by "C := N". Moreover, the following tests for a counter exist (N enotes a natural number): - EQ(N,C ) True, if the value of C equals N, also enote by "N = C ". - GRE(N,C ) True, if N is greater than the value of C, also enote by "N > C ". Note that, in contrast to the other elements, a counter epens on the history of protocol executions. counter is always proprietary to one protocol. Thus, the protocol P cannot change or test the value of a counter which is proprietary to a ifferent protocol Q. For further etails see 5.7 an 5.2. C336/G&D/W25/DS/P/004/b1

10 SEC SEC D04 Intermeiate report on the MTS SIM Page 10 of Equations for the protocol escription Of course, up to now we have nothing escribe which allows the preiction of the output of the protocol, since we o not have any control over which functions will be substitute in calculate elements. However, for most protocols it suffices to specify certain simple equations for the functions rather than their concrete values. Thus, together with the function symbols, the equations require for the replace functions are liste in the heaing of the protocol escription Functions an keys in the protocol escription nalysing conceivable cryptographic applications allows us to be more specific. t a first glance one coul try to cover cryptographic algorithms by means of two function symbols, e.g. one for encryption an one for ecryption. However, especially in public key environments one shoul avoi these terms, since, for instance, in signature schemes the function for ecryption is usually applie to the plain message. sually, the following notation is use: "To apply (a concrete algorithm) with someone s public / secret key." Since we o not want to specify a concrete algorithm a priori, by an abuse of language we will speak of public an secret functions. This will inicate the function which is applie with the public or secret key, respectively. Note that, by Kerkhoff s principle, no function use in a cryptographic system shoul be secret, but the security of the whole system shoul epen only on the keys. However, for many cryptosystems it turns out that they cannot be escribe by only two functions. For instance, algorithms base on the iscrete logarithm problem in cyclic groups require three ifferent actions: exponentiation of the public key, exponentiation with the secret key an exponentiation of the generating element. Therefore, in the protocol escription, we cover a cryptographic algorithm by the three function symbols D, E, F. When we efine a cryptographic algorithm, it is convenient to enote also the concrete functions of the algorithm by D, E, F. sually, these are functions which transform certain values (e.g., numbers) of its omains to certain output ata of its ranges in epenence of (secret or public) keys. Each function is linke with at most one key. These are enote by, e, f an, as a general rule, we agree that D has always to be applie with, E with e an F with f. Thus, we have the functions D : m a D (m), E e : F f : m a E e (m) an m a F f (m). In contrast to the above rule we also apply these functions with temporary keys although these keys will have ifferent names. For instance, a temporary key K may have been negotiate in the course of a protocol. Then the following steps of the protocol escription may contain the terms "D K (m)" etc. (We will always assume that K has the appropriate format.) This situation appears, in particular, in connection with symmetric crypto-systems, see, for example, the Siemens protocol below. Of course, in the efinition of an algorithm, apart from the prescription of these functions, we also have to specify their omains an ranges. They can consist of certain numbers, pairs of numbers, elements of a group etc. lso, the format of the keys has to be specifie in the efinition. s we mentione in 5.1.2, we wish that certain equalities hol, for instance, ( ) D o Ee = Ff. This means that D (E e (x)) = F f (x) for all elements x of the omain of E which has to be same as the omain of F. In other wors, if x (for instance, a number) is first "ciphere" by E with the key e, an then "eciphere" by D with the key, the result has to be the same as the manipulation of x by F with the key f. (Especially the term "to ecipher" oes not really fit here.) We cannot expect such an equality, if there is no other requirement for the keys (otherwise these functions woul have no cryptographic meaning). Thus, in the efinition of an algorithm we will also require some equalities for the involve keys. C336/G&D/W25/DS/P/004/b1

11 SEC SEC D04 Intermeiate report on the MTS SIM Page 11 of first example for an algorithm Diffie-Hellman key exchange with one public key in a cyclic group G with generator g Keys: is a number, f:= g is an element of G. DHP := (D, E, F) with D : G G, D ( x): = x E: N G, E( n): = g n F : N G, F ( n): = f f f n Here, N = {0,1,...} enotes the set of natural numbers. G is an arbitrary, but fixe, cyclic group with generator g. To be more precise, for each such G an g we have efine a ifferent algorithm DHP G, g. For instance, G might be the multiplicative group Z/5Z * = {1,2,3,4}an g = 2 (of course, this group is by far too small for any cryptographic use). Obviously, the above equality ( ) hols. Note that in this example, E is key-less, i.e. E oes not epen on any key. Of course, in this case we nee not specify e an we simply write "E(n)", although in the protocol escription this term might have been enote by "E e (n)". However, E epens on the generator g which is assume to be the same for all users of the system. In most algorithms either E or F will be keyless. If a party, say, likes to participate in a protocol which uses DHP, then has to retrieve keys, f which fulfil the above equality. Here woul ranomly generate the number an efine f:= g. The inex "" inicates that these keys are proprietary to. s a secon general rule, we agree that is always secret (i.e. known only to or can be applie only by ), whereas e an f (if the occur at all) are the public keys of (i.e. everyone in the system, or at least everyone involve in a protocol execution with, knows these keys). Thus, by the above flexibility of terminology, D is the secret function an E, F are the public functions Further agreements on protocol escriptions If in a protocol more than one algorithm is use, these are successively numbere by exponents: (D 1, E 1, F ) with keys, e, f, (D 2, E 2, F ) with keys, e, f etc. The reaer shoul be aware that, in this context, this oes not mean "square of D" etc. Of course, the substitute functions for, e.g. D 1 an D 2, may be the same as far as the require equalities hol. I enotes the ientity map where the omain (= range) results from the context. Moreover, in some of the following protocol escriptions we will nee a hash function h with appropriate omain an range. This function shoul be publicly known. For simplicity, we will always use the same symbol h, even if in some protocols h might iffer. Hence, these protocols epen also on h rather than only on a cryptographic algorithm (D, E, F). Here we will not specify any further requirements for h. " " means concatenation. (In some places instea of "a b" also "a XOR b" or something similar coul be use.) If the elements which have to be concatenate are not numbers, one has to map these elements to integers by an injective function an then to concatenate the values (see, for example, 6.2). RND enotes a ranom number of appropriate format which is freshly generate by. Requirements on ranom numbers involve the usual ones in cryptography (e.g., unpreictability). nless state otherwise, RND will be secret, i.e., only known by. Mentioning of "RND " in a protocol implies that this ranom number has been generate just prior to its first occurrence, even if not state explicitly. Similarly, RND B for another entity B. Similar as for a hash function h, such protocols epen also on the concrete substitution for RND. Finally, we nee the following simple functions acting on pairs with appropriate components: C336/G&D/W25/DS/P/004/b1

12 SEC SEC D04 Intermeiate report on the MTS SIM Page 12 of 31 TRE, if m = n EQ(m,n) :=, PR1(m,n) := m, PR2(m,n) := n. FLSE, else By abusing notation, we will also apply these functions to a "pair" m n with its obvious meaning. The security of all protocols epens at least on the requirement that in practice it shoul be impossible to calculate D ( m) without knowlege of. However, here we consier security threats only very briefly First example of a protocol escription Next we give an example of a protocol escription, rather to explain the concept than to provie any mechanisms for MTS. SCS: Sharing a common secret Purpose: an B want to negotiate about a common secret via an unsecure channel. Triplets involve: (D, E, F) ssociate keys:, e, f Equations require: D o Ee = Ff (( ) from above, (2) from below) B 1. m: = E ( RND ) 2. m e B 3. Ff ( RND B ) 4. D ( m) Since DHP fulfils the require equation, an B can execute this protocol by replacing (D, E, F) by DHP, for instance. We enote this by "SCS(DHP)". Of course, this assumes that has retrieve its secret key an public key f, an that B knows the latter. When executing SCS(DHP), in step 1, B generates a ranom number RND B an calculates m g RND B :=. RND In 2, B sens m to. In 3, B calculates f B. In 4, calculates RND RND m = ( g ) = ( g ) = f RND B B B which is the common secret between an B. Note that the last equality also follows from D o Ee = Ff. Thus, after executing SCS with any algorithm which fulfils this equation, an B will have a commonly share secret, namely F ( RND ) = D ( m). f B C336/G&D/W25/DS/P/004/b1

13 SEC SEC D04 Intermeiate report on the MTS SIM Page 13 of Symmetric crypto-systems Even if this protocol escription language was evelope with public key systems in min, it is interesting that it can also be applie with symmetric key systems. To give an example, consier again the above protocol escription. In orer to process SCS with a symmetric algorithm, we only have to change the meaning of the keys, namely, e, f now are known by, an only by, an B. We give an easy (an cryptographically quite unsecure) example of a symmetric algorithm which can be inserte in SCS. gain E is key-less. To justify the name "symmetric" we require that an f are equal. Note that there is no formal ifference to the escription of public key systems. However, in such a system the terms secret or public keys or functions are not justifie anymore. Hoping that this will not cause any confusion though we will use the same names as for public systems. Xoring numbers of bitlength l M is the set of all numbers in binary representation with l bits. Keys: = f are elements of M. XOR := (D, E, F) with D : M M, D ( m): = m E := I: M M F : M M, F ( m): = m f f f Since the above equality ( ) hols, an B can execute SCS(XOR) in orer to get a commonly share secret, namely D ( m) = m = m f = F ( m). 5.2 Realisation on the SIM f gain, consier the above example. First SCS will be esigne in the protocol escription language as above, for instance by a service provier. The SIM of a subscriber shall have the capability to run SCS behaving as B. Therefore this high-level escription has to be broken own to a level which can be execute by the car. This "executable coe" will be store on the SIM. Of course, the car has to know only the calculation elements which have to be processe by B. In a programming language-like formulation the above woul become: proceure SCS(Γ(, e, f) ); begin x:= RND; m:= E e (x); SEND(m); RETRN(F f (x)); en; DHP coul have been formulate as: triple DHP(, e, f); begin D ( x):= x ; C336/G&D/W25/DS/P/004/b1

14 SEC SEC D04 Intermeiate report on the MTS SIM Page 14 of 31 En ( ):= ; g n F ( n):= f ; f en; n Then the comman "RN SCS(DHP(-, -, 123))" woul execute the SIM s part of the protocol where "123" is the public key of. For instance, this key coul have been store on the SIM an retrieve from its storage for this particular protocol execution. The hyphens inicate that these keys are not use by B, hence not transmitte. (Of course, is not known by B an E is key-less). However, SCS coul also be execute with an algorithm where E is not key-less. Then the secon hyphen has to be replace by the value of e, the other public key of. Certain proposals of protocols for authentication in MTS phase 1 are base on counters (see [MTS33.23], [SE-D03]). In these protocols there exists one counter (or several) on the SIM which cannot be manipulate an a counterpart at the HE. During each authentication proceure the value of the SIM counter (an the network counter) is increase by 1. If these values iffer in certain ways, authentication is refuse. These mechanisms are propose as a countermeasure to the false base station attack (see the above mentione ocuments). From the technical point of view, it is important to implement an appropriate ata fiel on the smart car which can securely be upate many times. However, car manufacturers alreay gaine some experience with such counters in the EEPROM of SIMs. The only inappropriate behaviour was etecte at power failures. In such a case the counter is not increase. However, this oes not essentially effect the functionality of these protocols. p to now we have not etermine what exactly the level is which can be execute by the car. One possibility is that the car coul interpret a similar coe to the above. However, this woul require the esign of a, more or less, new programming language only for MTS. This oes not appear to be a very satisfactory solution. The other possibility is that, after the esign of the protocol, it will be translate into a coe that can be execute by the car, for instance into Java (compare [SE-D03, 5.5] an 5.3). This translation is proceee at the same place where the protocol was esigne, e.g. at the service provier. Of course, it coul be one automatically. Then this coe is ownloae to the SIM. Moreover, it seems to be likely, that a certain protocol will most often be run with the same algorithms an that these will alreay be etermine uring esign. Therefore, the ownloae coe coul alreay fix these algorithms. However, the algorithms are store in a library on the SIM. Thus, the coe for a protocol contains the aress of the algorithm rather than the algorithm itself. 5.3 Java an ownloaing concept The Java concept represents a common software platform for many ifferent systems. Due to this universality it is valuable also in the area of smart cars an mobile communication. Currently, smart car suppliers are eveloping Java (smart) cars which will be (or alreay are) available in the near future. Moreover, the stanarisation boies for GSM are alreay working at stanars for the employment of Java (see below). Therefore we give the following short overview on Java cars. s usual, the Java functionality is implemente in the ROM, whereas the EEPROM is fully available for (MTS) applications. The universality of Java allows its use for MTS as well as for other applications like mobile banking. Since the run of Java programs is automatically controlle by a state machine, this concept will ensure a higher level of security, in particular when software is ownloae to the car. The following iagram shows the interaction of the ifferent stanarisation boies with each other. The SMG9 PI working party is preparing input papers for approval by SMG9 which are base on regular meetings with the Java Car Forum (JCF) an the Java Car Task Force Telecommunications. The Java Car Forum itself is represente by members from the banking sector, IT sector, car manufacturers, telecom operators an, of course, SN Microsystems. The Java Car Task Force Telecommunications is mainly represente by companies involve in the telecommunications business (both operators an car manufacturers). C336/G&D/W25/DS/P/004/b1

15 SEC SEC D04 Intermeiate report on the MTS SIM Page 15 of 31 JCF SMG9 Task Force Telecom. SMG9- PI The following ocuments are being create by the ifferent boies: SMG9- PI GSM GSM GSM 03.xx Task Force Telecom. GSM Prg Concept STK PI Loaer Concept GSM PI C336/G&D/W25/DS/P/004/b1

16 SEC SEC D04 Intermeiate report on the MTS SIM Page 16 of 31 Whereas [GSM02.19] an [GSM03.19] are currently uner review by SMG9 PI an SMG9, the loaing concept for GSM Java cars is not yet specifie. This ocument (GSM03.XX) is a crucial element of the whole GSM Java car system, as it efines a secure an stanarise loaing mechanism for GSM Java applets. Furthermore, the loaing concept offere in the IS Open Platform (OP) specification is now also iscusse to be integrate in the ETSI ocument. ll GSM Java cars which are currently available, are more or less base on proprietary loaing mechanisms which o not allow the inepenent exchange of applets between cars from ifferent manufacturers. However, since this interoperability is the key element of Java cars an it will soon become stanarise for GSM, it is most recommenable to await the appropriate ETSI ocuments. Furthermore, since this structure will inclue a secure an stanarise concept for ownloaing, it shoul be taken into consieration for any proposal of ownloaing mechanisms for MTS. This is in particular true for phase 1 issues, since there will be no public key infrastructure available. 5.4 Realisation in MTS In the easiest moel, we assume that all parties involve in MTS have agree on three fixe lists. The first list contains all necessary equations, a typical entry woul be " D o Ee = Ff ". The secon list contains protocol escriptions, as the above SCS, of course for more avance purposes, e.g. authentication. The last one contains suitable algorithms, e.g. DHP. These lists have been esigne by, for instance, network operators or service proviers. Each user carries some protocol escriptions an some algorithms of these lists on his or her SIM, of course in an executable format, together with appropriate keys. If this user wants to enlist MTS services from a network, both parties agree on a common protocol with common algorithms, e.g. SCS(DHP). Of course, for this example, the user has to have SCS as well as DHP on the SIM. When executing the corresponing protocol, the SIM replaces the function symbols in SCS by the concrete functions efine in DHP, using the special keys for DHP, most likely its secret one or a public one from someone else (e.g. the network operator) which is alreay store on the SIM. This proceure is somewhat contraictory to what was sai above, since there we propose to have protocols with fixe algorithms on the car. However, for a first trial the easier solution from the above seems to be appropriate. With some more programming effort it can still be increase to the moel escribe in this paragraph. However, none of these lists really nee to be fixe. Of course, after any change, SIMs issue before this change, still carry the ol protocols an algorithms. Therefore the lists shoul rather be expane than existing entries be change. Then the new entries coul be store on newly issue SIMs or be ownloae to alreay existing cars, for instance over-the-air. Since the SIM has in general the capability to interpret the protocol escription language (or a coe which is retrieve from such a protocol escription), it can easily process the new protocols with its alreay store algorithms. However, the situation is more tricky with ownloaing of new algorithms, since every PK algorithm uses ifferent types of key. Thus, for new algorithms probably also new keys have to be generate, either by the car itself or by the home environment. In the first case, at least the home environment has to be informe about the new public key of the user. Moreover, the SIM has to have the capability for this key generation. In this generality, this seems to be quite unlikely taking into account that not even the format of keys is fixe a priori. In the secon case, the secret key of the SIM has to be transferre from the home environment to the car. Of course, it woul be encrypte, but there is still a high risk. Moreover, even the name is misleaing, since then the "secret" key is also known to the home environment. For both cases cryptographic algorithms which are still safe have to be on the SIM, either for signing the new public key or for ecrypting the new secret key. countermeasure to this last objection is the general implementation of a fall back crypto-system on the car. Moreover, a new algorithm might require new calculation facilities which cannot be processe by ol SIMs, in particular if a co-processor is involve. Furthermore, ue to processing time, many algorithms are store as executable coe. If the car permitte ownloaing of such coe, it woul have no security mechanisms against what is ownloae. Talking about flexibility again, note that these lists nee not be generally agree upon. Each service provier coul esign its proprietary protocols an, less likely, its proprietary algorithms. Of course, it has to be ensure that in a roaming situation there is at least one common protocol with common algorithms. However, this coul be guarantee, for instance, by a worl-wie agreement on at least one common set. C336/G&D/W25/DS/P/004/b1

17 SEC SEC D04 Intermeiate report on the MTS SIM Page 17 of Sample Lists In the following we provie examples for such lists, rather to emonstrate their feasibility an practical use than to introuce new crypto-systems List of equations (1) D o E = I (typically for encryption) e (2) D o Ee = Ff (typically for ientification) (3) Ee o D = Ff (typically for igital signature) (4) D = F (typically for ientification in symmetric key systems) f In the following we will refer to these numbers rather than mentioning the equations itself. However, in a large environment it might be more practical to cite the equations itself. Of course, for each equality the appropriate omains an ranges have to coincie, e.g. in (2), om(e) = om(f), range(e) = om(d), range(d) = range(f). Note that (1), with F = I, implies (2). For most applications, F shoul be at least "almost" injective, since otherwise an aversary coul succee just by guessing an appropriate result List of algorithms In the following, G is a finite, cyclic group (multiplicatively written) with generator g. In orer that the function D can practically not be calculate, the iscrete logarithm problem in G has to be har. RS Keys: = (, n), e = (e, n) with numbers e,, n such that e 1mo( p 1)( q 1 ) for n = pq, p,q istinct primes. RS := (D, E, F) with D, E, F: {0, 1,..., n-1} {0, 1,..., n-1}, D ( m): = m mo n, E ( m): = m mo n, F( m): = m. (, n) By Euler s theorem, (1), (2) an (3) hol. ( en, ) e ElGamal encryption scheme Keys: is a number, e:= g is an element of G. EGenc := (D, E, F) with D : G x G G, D (x,y) := x -y E e : G G x G, E e (m) := (m e RND, g RND ) F: G G, F(m) := m. The player who processes E, has to generate RND freshly for each encryption an to keep it secret. Thus, E also epens on RND. However, this can be neglecte, since the esire equality hols for all RND. It is easy to see, that (1) hols. Here the same remark concerning G an g applies as for Diffie-Hellman key exchange. C336/G&D/W25/DS/P/004/b1

18 SEC SEC D04 Intermeiate report on the MTS SIM Page 18 of 31 ElGamal signature scheme Let p be a prime an g a primitive root moulo p. Keys: is a number, e:= g mo p is a number < p. EGsig := (D, E, F) with D : N {1,..., p-1} x {0,..., p-2}, D (m) := (g RND mo p, (m ( g RND mo p)) RND -1 mo (p-1)) E e : {1,..., p-1} x {0,..., p-2} {1,..., p-1}, E e (r,s) := e r r s mo p F: N {1,..., p-1}, F(m) := g m mo p. The player who processes D has to generate RND with gc(rnd, p-1) = 1 freshly for each signature an to keep it secret. few calculations show that (3) hols for all RND. Note, that F is key-less List of protocols This list contains protocol escriptions for some simple cryptographic applications. It is not performe for MTS. However, protocol escriptions for MTS may contain these protocols as subprotocols. In some of these protocol escriptions we combine the protocol execution elements Calculate an Sen, e.g. in a) 1. Then, of course, first the inicate value has to be calculate by the sener an then it has to be sent to the recipient. a) ENC: Encryption Purpose: B wants to sen a confiential message m to via an unsecure channel. Triplets involve: (D, E, I) ssociate keys:, e Equations require: (1) 1. n: = E ( m) e B 2. D ( n) Hence, by (1), knows m= D ( n). b) SCS : Sharing a common secret with key-less function E Purpose: an B want to negotiate about a common secret via an unsecure channel. Triplets involve: (D, E, F) ssociate keys:, f Equations require: (2) C336/G&D/W25/DS/P/004/b1

19 SEC SEC D04 Intermeiate report on the MTS SIM Page 19 of m: = E( RND B ) B 2. Ff ( RND B ) 3. D ( m) Thus, by (2), Ff ( RNDB) = D ( m) is the common secret between an B. In contrast to SCS, B can alreay start with messaging even if B has no information about s public key. Of course, in the sequel B has to get this information. On the other han, it might be more risky to have only one such master function for a whole system. Furthermore, this is not applicable if (1) (with F = I) hols, since then the transformation with the secret key woul almost coincie for all users. c) SCSF: Sharing a common secret with fresh input of both sies In SCS the common secret epens on fresh input only from B. However, it might be esirable, that it also epens on fresh input from. This can be achieve either by mirroring the above protocol (uner the assumption that also B has such public an secret keys) an then concatenating both secrets, or as follows (compare the Siemens protocol, 6.2): Purpose: an B want to negotiate about a common secret via an unsecure channel. Triplets involve: (D, E, F) ssociate keys:, e, f Equations require: (2) 1. m: = E ( RND ) e B B 2. RND 3. c: = h( F ( RND ) RND ) 4. hd ( ( m) RND ) f B Thus, by (2), c= h( D ( m) RND ) is the common secret between an B. Note that, however, here part of the secret was sent in plain format. ) DSG: Digital signature Purpose: sens a (non-confiential) message m to B. B wants to ensure that m inee was written an sent by an has not been falsifie. C336/G&D/W25/DS/P/004/b1

20 SEC SEC D04 Intermeiate report on the MTS SIM Page 20 of 31 Triplets involve: (D, E, F) ssociate keys:, e, f Equations require: (3) 1. n: = D ( h( m)) B 2. (m, n) 3. EQ ( F ( h ( m )), E ( n )) f e TRE means that the authenticity of m is consiere to be verifie. (Note that, by (3), the two values have to coincie). Note that the first purpose is not completely fulfille, since an attacker coul have intercepte such an (originally written by ) message ( md, ( hm ( ))) an sen it again to B at a later time, pretening to be. On the other han, this protocol can easily be combine with e). In the literature the pair (m,n) is frequently enote by " ( msign, ( m)) ". e) IDF: Ientification Purpose: B wants to ensure s ientity. Triplets involve: (D, E, F) ssociate keys:, e, f Equations require: (3) B 1. RND B 2. m: = D ( RND ) B 3. EQ ( E ( m ), F ( RND )) e f B TRE means that B has establishe s ientity. f) IDF : Ientification, 2 n possibility Purpose: B wants to ensure s ientity. C336/G&D/W25/DS/P/004/b1

21 SEC SEC D04 Intermeiate report on the MTS SIM Page 21 of 31 Triplets involve: (D, E, F) ssociate keys:, e, f Equations require: (2) 1. m: = E ( RND ) e B B 2. c: = h( D ( m)) 3. EQ( h( F ( RND )), c) f B TRE means that B has verifie s ientity. This protocol has the sie effect that Ff ( RNDB) = D ( m) is a secret share by an B. If this is not esire, the protocol can be run without h, i.e. h:= I. Note that this protocol can be use in particular, if (1) (with F = I) is fulfille. In this case, in 3. B has to calculate only EQ( h( RND B), c). E might be key-less. 5.6 Certificates In the above we assume that B unambiguously knows the public key(s) of. However, if an B have never met, this might cause a security threat. solution to a secure key exchange is provie by a truste thir party T: Prerequisites - T has the possibility to sign messages, e.g. to apply DSG. Thus we nee a triplet (D, E, F) an keys T, et, ft such that (3) hols. - B has unambiguous knowlege of e, f an "trusts" T (see below). T T - T has unambiguous knowlege of the ientity of an of the public keys e, f of. This might have been achieve by personal inspection of the ientity car of. Furthermore, to ensure knowlege of e the appropriate equality hols., f, these might have been generate at or by T, or T checks that Then T will issue a certificate for : Cert ( ): = (( i, ( e, f ), val ( )), D ( h( i, ( e, f ), val ( )))), T T T where i uniquely ientifies (at least in the given system), e.g. i coul be s name, an val T () is a time-limit for the valiity of the certificate, etermine by T. Note that in many algorithms F is key-less. Hence in Cert T (), instea of ( e, f ), we coul have one single (probably quite lengthy) number. It shoul be remarke that there exist certain stanars for certificates. The above form is not in accorance with any of these. However, since this paper is intene merely to be a high level escription, we prefer to focus on what is really neee. For a concrete implementation, formats of the certificates shoul probably follow existing stanars. T C336/G&D/W25/DS/P/004/b1

22 SEC SEC D04 Intermeiate report on the MTS SIM Page 22 of 31 Cert T () might be store in a publicly available net or by himself. In the latter, will appen Cert T () to any (or, at least, to the very first) message sent to B. In the former, B will retrieve s certificate from the net. In any case, now B is able to verify the authenticity of s public key(s) by verifying the authenticity of ( i,( e, f), val T ( )) with T s public keys as escribe in DSG. Of course, B has to trust T in so far as B has to believe that T actually checke s ientity an public keys. In the above we assume that B knows e T an f T. Of course, this can be achieve by involving a secon truste party which, for its part, issues a certificate for T. Continuing this process leas to a certification hierarchy. For a more comprehensive iscussion on certificates, especially for use in MTS, see [SE- D03, 8.1]. 5.7 Enhance features of the protocol escription language In the examples in we i not consier the protocol execution elements "Execute subprotocol.", "Ifthen-else control structure" or "Counter". Rather than giving an exact specification of these elements we will escribe their meaning by the following two examples. In the first example we consier two entities an which might be a user an a visite network in MTS. The purpose of this protocol is mutual ientification between an. The iea is to mirror the protocol "IDF: Ientification" in For this purpose we nee to exactly quote the involve entities, algorithms an keys. Thus, we will use the following etaile heaer instea of "IDF": IDFB, (( D, E, F)(, e, f)) (, B are the same as in the above protocol escription.) MID: Mutual ientification Purpose: Mutual ientification between an. Triplets involve: (D, E, F) (D, E, F) ssociate keys:, e, f, e, f Equations require: (3) (3) Executes IDF with, in the roles of, B, respectively. The input of this if-then-else structure results from the output of the last operation in IDF, i.e. it is true if B has establishe s ientity. Otherwise the protocol execution stops. Executes IDF with, in the roles of, B, respectively. True, if has establishe B s ientity. s for the other protocols, for execution of MID a concrete algorithm has to be specifie which replaces (D, E, F) in the above. Note that we coul have formulate this protocol escription with ifferent symbols (D 1, E 1, F 1 ) an (D 2, E 2, F 2 ) for the two calls of IDF. This woul allow to use ifferent algorithms for IDF, an IDF,, respectively. Since this C336/G&D/W25/DS/P/004/b1

23 SEC SEC D04 Intermeiate report on the MTS SIM Page 23 of 31 is still a high-level escription it is not essentially whether it is written own in a linear form or as a flow chart. However, here the above shape is certainly more reaable. Note that the break own to s functionality of MID cannot be formulate with subprotocols, since the tasks of an B in IDF totally iffer. The secon example illustrates the use of counters. It is extracte from a proposal for authentication in MTS, phase 1 (see [MTS33.23]). However, here our main purpose is just to emonstrate the counter facility. Therefore we consier (an moify) only such parts an o not escribe the whole protocol. Moreover, we simplify this protocol by consiering only a user an a home environment H. The general iea of employment of counters is to guarantee freshness of messages ( to in case of this protocol). For etails see the above mentione paper. Note that this protocol is base on a symmetric key infrastructure. FRE: Freshness Purpose: wants to be sure about freshness of a message Triplets involve: ssociate keys: Equations require: (D, D, I), known by, an only by, an H none H 1. INC(C H ) 2. m: = C RND D ( C RND ) H H H H 3. EQ (D (PR1(m) PR2(m)), PR3(m)) 4. N := PR1(m) 5. GR(N, C ) 6. SET(C, N) In 3., verifies the originality of C H RND H. Note that N = C H. In case N is less than or equal to C, stops the protocol execution in 5. Note that this happens, if the same message m is sent again. Hence, can be sure that m is fresh. In [MTS33.23] D is a MC function. C336/G&D/W25/DS/P/004/b1

24 SEC SEC D04 Intermeiate report on the MTS SIM Page 24 of uthentication proceures for MTS 6.1 General assumptions In orer to emonstrate the usage of the above machinery, we will escribe two proposals for authentication in MTS. The first is erive from one propose by Siemens (see [HP98]), the secon one was recently evelope at Giesecke & Devrient. Since we o not inten to provie complete solutions for authentication, we make some simplifying assumptions. However, these protocols can easily be extene in orer to use them in reality. We consier four entities: - a home environment H - a user (= subscriber of H; here we consier the mobile, the smart car an the person as a unit) - a serving network - a certification authority C (this is one of our simplifications: in reality there will be several certification authorities which will lea to a certification chain for authentication). We assume the following: - has a vali MTS subscription at H. - is situate in the network area of an woul like to use MTS services offere by. - Both H an trust C. (The meaning of trust has to be specifie.) - can verify certificates issue by C, i.e. knows the public key(s) of C which occur in the following protocols. - has a (vali or invali) certificate issue either by C or H. (This will be specifie below. Of course, in the latter we assume that H is able to issue certificates for its users.) - has a vali certificate Cert C () issue by C. - can verify certificates issue by C (see above). Moreover, whenever we mention protocols, algorithms or keys we assume that the corresponing entity is able to procee these protocols or algorithms, has erive the necessary keys an that these are available at the appropriate places. Similar for terms relate with certificates. In particular, i is a number which uniquely ientifies. However, for the purpose of user confientiality, a personal ientification shall only be possible for H. Moreover, i shoul never be sent plain, an not even in the same encrypte version, over the air. iolating this rule woul not affect the authentication security but the user's confientiality. i will contain a subnumber by which H (or C) can be ientifie (there is no reason to keep this one secret). Here security issues are base on a public key infrastructure. This allows to reuce traffic between an H. Moreover, key management for H is easier, since H nees no longer keep the keys of all its subscribers secret. However, for some reasons there is still symmetric encryption neee, e.g.: - for sening 's certificate OT in the Siemens protocol (see below) - for processing GSM authentication - for real-time encryption (e.g., speech). C336/G&D/W25/DS/P/004/b1