3GPP TSG-T3 (USIM) Meeting #8
Bonn, Germany, August 23 - 25, 1999	S3-99274	

Source:	T3 secretary
Title: 	Draft report from the joint S2/S3/T3 session on USIM security issues

The report below is an extract from section 7 of the draft T3 #8 meeting report. It covers all issues dealt with on the 24th August under the agenda item 7 "Joint sesion with S2/S3 on USIM security issues". All T3 documents mentioned and the full draft T3 meeting report (when available) are available on the 3GPP server:
	ftp://ftp.3gpp.org/tsg_t/wg3_usim/tsgt3_08/docs/

7	Joint session on USIM security issues
7.1	Addressing of algorithms and keys 
T3-99207 (S3-99212) is an LS that was sent from T3 to S3 on multiple authentication algorithms and keys. It informs them that T3 is currently designing the implementation of the 3GPP security architecture into the USIM. It requests S3 feedback on whether provisions should be made to allow for multiple authentication algorithms and  multiple authentication keys within a USIM. 
T3-99246 (S3-99259) is a reply from S3. S3 agrees that an explicit feature to support algorithm and/or key version identification would be useful for disaster recovery such as all the authentication keys in the network being disclosed. S3 are now planning to produce a mechanism to support such a feature. S3 notes that such a feature does not necessarily imply, as claimed in the liaison statement, that “in an authentication request from the network, an algorithm indicator and a key indicator would need to be sent”.  During a discussion on the issue, the following points were noted:
-	it was proposed that such a signal to change keys could be sent via SMS-PP or SMS-CB. Each authentication could be accompanied by an indication of which key to use (e.g. 1, 2 or 3). This would avoid the requirement of modifying core network signalling;

-	it was suggested that more effort should be put into making the security measures secure in the first instance rather than designing a recovery scheme;

-	the advantage of indicating it each time the command is sent across the USIM/ME interface would be a more flexible solution;

-	in order the optimise the signalling on the radio interface, the ME/USIM interface could allow a default (for a specific operator) algorithm. This could be a particular one or the last used one, for example;

-	S3 agreed at their last meeting that every MM message must be protected.
The main conclusions of the discussion were:
-	selection (possibly non-reversible) of algorithms and keys was agreed to be necessary;

-	the solution should preferably not involve changes to the signalling on the core network;

-	it should be investigated whether the algorithm (or key) should be specified each time the command is used or whether ther should there be an activation command? A third possibility would be a combination of both where the algorithm may be selected each time and, at some later point, be permanently used as the default algorithm;

-	it should be investigated how the non-reversible change of the algorithm/keys could be done on a mass scale;

-	it should be investigated what level of security should be used to change the algorithm/key (enciphering, integrity protection);

-	it should be investigated how the "spare" algorithm(s) could be protected to avoid attacks;

-	it was agreed that S3 should investigate the following potential solution for the selection of algorithm and key. It was porposed to use a few bits of the challenge to indicate the algorithm and key to be used. This would have the advantage that no change to would be required to the radio interface signalling, that the information on algorithm and key would be protected as the challenge is signed and that the precise method could be left to each operator. The latter would mean that there is no need ofr a general specification but that a recommendation in the relevant security specification (e.g. in the form of an informative annex) would be sufficient.

7.2	Handover/Roaming/Interoperation between GSM and UMTS
T3-99248 is a presentation on four different  UMTS-GSM Interworking-Scenarios. During a discussion of the presentation the following points were noted:
-	it was proposed that the 3rd solution could be modified such that when the user roams back to UMTS they get UMTS level security (see separate proposal in T3-99247);
-	the meeting agreed that IMUI should be recommended to be 15 digits. GSM allowed for shorter IMSIs, but experience has shown that such IMSIs might cause problems for some terminals on the market;
-	the issue of the 3-digit MNC has been solved in the USA;
-	it was agreed that the issue of allocation of Network Codes by regulators should be raised at the next SA meeting. UMTS and GSM networks operated by the same operator should use the same network code as otherwise it would substantially change the specification of the support of GSM and UMTS in a single UICC with implications for the user (e.g. authentication on handover).

No recommendations were made as to which solution should be used as this was felt to be an S3 issue and that further discussion of the scenarios was required.
T3-99215 (S3-99190) is an LS from S3 to T3 on interoperation between GSM and UMTS. For the situation where there is a GSM SIM with GSM ME or dual mode ME, the following conclusions were reached:
-	the conversion function GSM <-> UMTS security vectors would have to be in the terminal.
-	an "up-conversion" mechanism is necessary for the requirement of using a 2G SIM in 3G terminal. This would need to reside in the terminal.
-	part of the "down-conversion" mechanism would reside on the USIM. This could either be the same for all networks or network dependant. S3 will have to decide on this issue and T3 would then have to specify the USIM relevant parts.

T3-99224 (S2-99633) is an LS from S2 informing them that S2 has considered the issues regarding security related issues on GSM/UMTS interoperation. S2 supports the S3 view regarding the feasibility of re-authentication at inter-system handover. Regarding the location of the conversion function, S2 is of the opinion that it would be preferable that this should be done in the the HLR. It was noted that that this is a first analysis, and that does not prevent further analysis of the different solutions.
T3‑99234 is a discussion document commenting on the three handover scenarios mechanisms in T3‑99248. It was noted that this document would need to be further discussed within S3.
T3-99243 is a discussion document (presented for information to the joint session) proposing a set of mechanisms for interoperation between UMTS and GSM that provide. This would allow:
-	interoperation between upgraded 3G VLR and non-upgraded 2G VLRs, providing a 2G level of security both to 3G users and 2G users;
-	interoperation between GSM BSS and UTRAN both connected to upgraded 3G VLR, providing a 3G level of security to 3G users.

It was suggested that it would be useful to for S3 to send an LS to S2 (during their August meeting) so that they may consider the issue from the systems architecture point of view.
T3-99247 is a discussion document with comments on the proposal in T3-99234. It proposes a modification of mechanism 3a. The benefit of the modification would be to reduce the impact on existing GSM infrastructure. The document was noted and will be discussed further within S3.
7.3	Resources for cryptographic algorithms in the USIM 
T3-99216 is an LS from S3 to T3 in which they request information on characteristic values for the following USIM properties of word size, clock speed and memory size (i.e. ROM for storing the algorithm and RAM required for processing). Discussion concluded that the following figures should be used:
-	word size should be 8 bits. It was noted that within 2 years, 32 bit processors would be available on the SIM, but that this was not relevant for the purposes of the S3 calculations. 
-	clock speed would be at least 13/4 (3,25) MHz. The maximum frequency for 1,8 V chips was not yet known, but it was concluded that it would have to be 3,25 MHz to avoid problems. 
-	the amount of ROM required by the algorithm should not exceed 4 KBytes of memory. In addition 4 KBytes should be allocated to allow manufacturers to counteract certain types of attacks. 
-	the amount of RAM required would be 300 bytes, not taking into account hardware attack counter measures.

It was agreed that the above figures are provided for guidance only as it is an operator decision to decide on algorithm strength and SIM configuration.
Regarding the execution time of the algorithm in the USIM, it was agreed that 500 mS should be considered as a maximum time.
T3-99227 is an LS from S2 to S3 (cc T3) in response to the S3 request for information out the time constraints on the execution of cryptographic algorithms. The LS it was noted.
7.4	Enhanced user identity confidentiality
T3-99218 (S3-99123) is an LS from S3  informing several groups about their plans to improve the level of security by specifying a new feature called "user identity confidentiality" in 33.102 (Security Architecture). This would have the property that the permanent user identity (IMUI) of a user to whom a service is delivered cannot be eavesdropped on the radio access link. During a discussion of the document, the following points were noted:
-	user identity confidentiality must be supported by all UMTS networks as a mandatory feature (as the feature is a network feature and is either “on” or “off”). This has been endorsed by TSG-SA;
-	the IMSI/IMUI should be readable in clear text by the terminal as the terminal ... but it should not be sent over the radio interface;
-	currently, the IMSI is sent only during the first time a SIM is used in the home network;
-	the home environment has the option to encipher or not encipher the IMUI;
-	if the IMUI and enciphered IMUI had the same length, then the visited network would automatically support the feature without modification;
-	the key would be stored in the USIM;
-	a counter (of length 64 bits, as specified in 33.102) to serve as a cryptographic TVP (time variant parameter) would also be needed on the USIM;
-	the length of the IMUI could be used to indicate whether or not it is enciphered (i.e. one extra bit could indicate this);
-	this feature would result in a major incompatibility issue between R98 and R99 networks.
-	the issue of terminal paging is currently is currently under consideration within S3. 

T3-99225 is an LS from S2 in reply to the LS in T3-99281. S2 state that they would be against the feature if it required modifications to visited networks. The LS was noted.
T3-99226 is an LS.... It was noted.
7.5	IMUI / IMSI relationship
During a general discussion about the relationship between the IMUI and IMSI, it was agreed that coding should be the same but that the name should remain different (IMUI and IMSI). This in line with a proposal in an LS sent from S3 to S2. It was felt that the IMSI range currently available would be enough for UMTS. See also 
7.6	Different algorithms for SIM/USIM/multiple USIM
No documents were registered under this agenda item nor were any issues brought forward during the meeting.
7.7	Termination point of integrity protection at the user side (USIM or UE?)
No documents were registered under this agenda item nor were any issues brought forward during the meeting.
7.8	The timing of delivery of cipher/integrity keys 
No documents were registered under this agenda item nor were any issues brought forward during the meeting.
7.9	Definition of a message for immediate call termination from USIM to terminal
No documents were registered under this agenda item nor were any issues brought forward during the meeting.
7.10	Visibility in the USIM of the ciphering/integrity process in the terminal
No documents were registered under this agenda item nor were any issues brought forward during the meeting.
7.11	Other issues
T3-99238 is a discussion document about USIM security requirements currently contained in S3 specifications but not yet reflected in T3 specifications. It concluded that the following features need to be addressed by T3:
-	User Identify Confidentiality;
-	Identification by temporary identities;
-	Identification by a permanent identity;
-	User authentication;
-	User-to-USIM authentication;
-	USIM-Terminal Link;
-	Message authentication of signalling information sent to/from UE;
-	USIM application security.

T3-99244 is a discussion document listing several USIM requirement from 33.103 v1.0.0 that require clarification. 
T3-99245 is a proposal as to how some of the features listed in T3-99238 could be incorporated into T3 specifications.
It was concluded that many of the issues raised in T3-99238, T3-99244 and T3-99245 have already been discussed within S3 and that the next version of 33.103 (current version is v1.0.1, 1999-06) would contain clarifications. S3 undertook to provide an updated version of 33.103 after their September meeting (i.e. by 1st October 1999). Since the document would only be available to T3 immediately before their October meeting, it was also requested that the 33.103 rapporteur (or other suitable S3 expert) should attend the T3 meeting in Korea to assist with questions that are likely to arise.
During the discussion, clarification was requested about which security features specified by S3 were mandatory. It was noted that the S3 work plan submitted to the TSG-SA meeting #4 contained a list of which features were planned to be mandatory.