Professional Documents
Culture Documents
Etsi TS 133 102
Etsi TS 133 102
Etsi TS 133 102
0 (2002-12)
Technical Specification
Reference
RTS/TSGS-0333102v510
Keywords
UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N 348 623 562 00017 - NAF 742 C
Association but non lucratif enregistre la
Sous-Prfecture de Grasse (06) N 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
European Telecommunications Standards Institute 2002.
All rights reserved.
TM
TM
TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/key .
ETSI
Contents
Intellectual Property Rights ................................................................................................................................2
Foreword.............................................................................................................................................................2
Foreword.............................................................................................................................................................6
1
Scope ........................................................................................................................................................7
References ................................................................................................................................................7
3.1
3.2
3.3
3.4
Definitions..........................................................................................................................................................8
Symbols..............................................................................................................................................................9
Abbreviations ...................................................................................................................................................10
Conventions......................................................................................................................................................10
Security features.....................................................................................................................................12
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.3
5.3.1
5.3.2
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.5
5.5.1
5.5.2
6
6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
6.4
6.4.1
6.4.2
ETSI
6.4.3
6.4.4
6.4.5
6.4.6
6.4.7
6.4.8
6.4.9
6.4.9.1
6.4.9.2
6.5
6.5.1
6.5.2
6.5.3
6.5.4
6.5.4.1
6.5.4.2
6.5.4.3
6.5.4.4
6.5.4.5
6.5.5
6.5.6
6.6
6.6.1
6.6.2
6.6.3
6.6.4
6.6.4.1
6.6.4.2
6.6.4.3
6.6.4.4
6.6.4.5
6.6.5
6.6.6
6.7
6.8
6.8.1
6.8.1.1
6.8.1.2
6.8.1.3
6.8.1.4
6.8.1.5
6.8.2
6.8.2.1
6.8.2.2
6.8.2.3
6.8.2.4
6.8.3
6.8.4
6.8.4.1
6.8.4.2
6.8.5
6.8.5.1
6.8.5.2
6.8.6
6.8.6.1
6.8.6.2
6.8.7
6.8.7.1
6.8.7.2
Void........................................................................................................................................................49
ETSI
8.1
8.2
8.3
Void..................................................................................................................................................................49
Void..................................................................................................................................................................49
Mobile IP security ............................................................................................................................................49
C.1.1
C.1.1.1
C.1.1.2
C.1.1.3
C.1.2
C.2
C.2.1
C.2.2
C.2.3
C.3
C.3.1
C.3.2
C.3.3
C.3.4
C.4
F.2
F.3
Setting threshold values to restrict the lifetime of cipher and integrity keys .........................................60
ETSI
Foreword
This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
Scope
This specification defines the security architecture, i.e., the security features and the security mechanisms, for the third
generation mobile telecommunication system.
A security feature is a service capability that meets one or several security requirements. The complete set of security
features address the security requirements as they are defined in "3G Security: Threats and Requirements"
(TS 21.133 [1]) and implement the security objectives and principles described in TS 33.120 [2]. A security mechanism
is an element that is used to realise a security feature. All security features and security mechanisms taken together form
the security architecture.
An example of a security feature is user data confidentiality. A security mechanism that may be used to implement that
feature is a stream cipher using a derived cipher key.
This specification defines 3G security procedures performed within 3G capable networks (R99+), i.e. intra-UMTS and
UMTS-GSM. As an example, UMTS authentication is applicable to UMTS radio access as well as GSM radio access
provided that the serving network node and the MS are UMTS capable. Interoperability with non-UMTS capable
networks (R98-) is also covered.
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1]
3GPP TS 21.133: "3rd Generation Partnership Project (3GPP); Technical Specification Group
(TSG) SA; 3G Security; Security Threats and Requirements".
[2]
3GPP TS 33.120: "3rd Generation Partnership Project (3GPP); Technical Specification Group
(TSG) SA; 3G Security; Security Principles and Objectives".
[3]
3GPP TR 21.905: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Services and System Aspects; Vocabulary for 3GPP Specifications (Release 1999)".
[4]
3GPP TS 23.121: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Services and System Aspects; Architecture Requirements for Release 99".
[5]
3GPP TS 31.101: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Terminals; UICC-terminal interface; Physical and logical characteristics".
[6]
3GPP TS 22.022: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Services and System Aspects; Personalisation of UMTS Mobile Equipment (ME); Mobile
functionality specification".
[7]
3GPP TS 23.048: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Terminals; Security Mechanisms for the (U)SIM application toolkit; Stage 2".
[8]
ETSI GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related
network functions".
[9]
3GPP TS 23.060: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Digital cellular telecommunications system (Phase 2+); General Packet
Radio Service (GPRS); Service description; Stage 2".
ETSI
[10]
[11]
3GPP TS 35.201: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document
1: f8 and f9 specifications".
[12]
3GPP TS 35.202: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document
2: Kasumi algorithm specification".
[13]
3GPP TS 35.203: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document
3: Implementers' test data".
[14]
3GPP TS 35.204: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Specification of the 3GPP confidentiality and integrity algorithms; Document
4: Design conformance test data".
[15]
3GPP TS 31.111: "3rd Generation Partnership Project; Technical Specification Group Terminals;
USIM Application Toolkit (USAT)".
[16]
3GPP TS 22.048: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Terminals; Security Mechanisms for the (U)SIM Application Toolkit; Stage 1".
[17]
3GPP TS 25.331: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; RRC Protocol Specification".
[18]
3GPP TS 25.321: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; MAC protocol specification".
[19]
3GPP TS 25.322: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; RLC Protocol Specification".
[20]
3GPP TS 31.102: "3rd Generation Partnership Project (3GPP); Technical Specification Group
Terminals; Characteristics of the USIM Application".
[21]
3GPP TS 22.101: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Service aspects; Service principles".
3.1
Definitions
In addition to the definitions included in TR 21.905 [3] and TS 22.101 [21], for the purposes of the present document,
the following definitions apply:
NOTE:
'User' and 'Subscriber' have been defined in TR 21.905 [3]. 'User Equipment', 'USIM', 'SIM' and 'IC Card'
have been defined in TS 22.201 [21].
Confidentiality: The property that information is not made available or disclosed to unauthorised individuals, entities
or processes.
Data integrity: The property that data has not been altered in an unauthorised manner.
Data origin authentication: The corroboration that the source of data received is as claimed.
Entity authentication: The provision of assurance of the claimed identity of an entity.
Key freshness: A key is fresh if it can be guaranteed to be new, as opposed to an old key being reused through actions
of either an adversary or authorised party.
UMTS Entity authentication and key agreement: Entity authentication according to this specification.
ETSI
GSM Entity authentication and key agreement: The entity Authentication and Key Agreement procedure to provide
authentication of a SIM to a serving network domain and to generate the key Kc in accordance to the mechanisms
specified in GSM 03.20.
User: Within the context of this specification a user is either a UMTS subscriber (Section 6.8.1) or a GSM Subscriber
(Section 6.8.2) or a physical person as defined in TR 21.905[3] (Section 5.3 and 5.5).
UMTS subscriber: a Mobile Equipment with a UICC inserted and activated USIM-application.
GSM subscriber: a Mobile Equipment with a SIM inserted or a Mobile Equipment with a UICC inserted and activated
SIM-application.
UMTS security context: a state that is established between a user and a serving network domain as a result of the
execution of UMTS AKA. At both ends "UMTS security context data" is stored, that consists at least of the UMTS
cipher/integrity keys CK and IK and the key set identifier KSI. One is still in a UMTS security context, if the keys
CK/IK are converted into Kc to work with a GSM BSS.
GSM security context: a state that is established between a user and a serving network domain usually as a result of
the execution of GSM AKA. At both ends "GSM security context data" is stored, that consists at least of the GSM
cipher key Kc and the cipher key sequence number CKSN.
Quintet, UMTS authentication vector: temporary authentication and key agreement data that enables an VLR/SGSN
to engage in UMTS AKA with a particular user. A quintet consists of five elements: a) a network challenge RAND, b)
an expected user response XRES, c) a cipher key CK, d) an integrity key IK and e) a network authentication token
AUTN.
Triplet, GSM authentication vector: temporary authentication and key agreement data that enables an VLR/SGSN to
engage in GSM AKA with a particular user. A triplet consists of three elements: a) a network challenge RAND, b) an
expected user response SRES and c) a cipher key Kc.
Authentication vector: either a quintet or a triplet.
Temporary authentication data: either UMTS or GSM security context data or UMTS or GSM authentication
vectors.
R98-: Refers to a network node or ME that conforms to R97 or R98 specifications.
R99+: Refers to a network node or ME that conforms to R99 or later specifications.
Rel4- ME: Refers to a ME that conforms to Rel4 or R99 specifications.
Rel5+ ME: Refers to a ME that conforms to Rel5 or later specifications.
ME capable of UMTS AKA: either a Rel-4- ME that does support USIM-ME interface or a Rel-5+ ME.
ME not capable of UMTS AKA: a Rel-4- ME that does not support USIM-ME interface or a R98- ME.
3.2
Symbols
For the purposes of the present document, the following symbols apply:
||
f1
f1*
f2
f3
f4
f5
f5*
K
Concatenation
Exclusive or
Message authentication function used to compute MAC
Message authentication function used to compute MAC-S
Message authentication function used to compute RES and XRES
Key generating function used to compute CK
Key generating function used to compute IK
Key generating function used to compute AK in normal procedures
Key generating function used to compute AK in re-synchronisation procedures
Long-term secret key shared between the USIM and the AuC
ETSI
3.3
10
Abbreviations
In addition to (and partly in overlap to) the abbreviations included in TR 21.905 [3], for the purposes of the present
document, the following abbreviations apply:
AK
AKA
AMF
AUTN
AV
CK
CKSN
CS
HE
HLR
IK
IMSI
KSI
KSS
LAI
MAC
MAC
ME
MS
MSC
PS
P-TMSI
Q
RAI
RAND
SQN
SQNHE
SQNMS
SGSN
SIM
SN
T
TMSI
UEA
UIA
UICC
USIM
VLR
XRES
3.4
Anonymity Key
Authentication and key agreement
Authentication management field
Authentication Token
Authentication Vector
Cipher Key
Cipher key sequence number
Circuit Switched
Home Environment
Home Location Register
Integrity Key
International Mobile Subscriber Identity
Key Set Identifier
Key Stream Segment
Location Area Identity
The message authentication code included in AUTN, computed using f1
The message authentication code included in AUTN, computed using f1*
Mobile Equipment
Mobile Station
Mobile Services Switching Centre
Packet Switched
Packet-TMSI
Quintet, UMTS authentication vector
Routing Area Identifier
Random challenge
Sequence number
Individual sequence number for each user maintained in the HLR/AuC
The highest sequence number the USIM has accepted
Serving GPRS Support Node
(GSM) Subscriber Identity Module
Serving Network
Triplet, GSM authentication vector
Temporary Mobile Subscriber Identity
UMTS Encryption Algorithm
UMTS Integrity Algorithm
UMTS IC Card
User Services Identity Module
Visitor Location Register
Expected Response
Conventions
All data variables in this specification are presented with the most significant substring on the left hand side and the
least significant substring on the right hand side. A substring may be a bit, byte or other arbitrary length bitstring.
Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0,
the next most significant is numbered 1, and so on through to the least significant.
ETSI
11
(IV)
User Application
Provider Application
(I)
(I)
(III)
USIM
HE
(II)
(I)
(I)
Home
stratum/
Serving
Stratum
SN
Transport
stratum
(I)
ME
Application
stratum
AN
Network access security (I): the set of security features that provide users with secure access to 3G services,
and which in particular protect against attacks on the (radio) access link;
Network domain security (II): the set of security features that enable nodes in the provider domain to securely
exchange signalling data, and protect against attacks on the wireline network;
User domain security (III): the set of security features that secure access to mobile stations;
Application domain security (IV): the set of security features that enable applications in the user and in the
provider domain to securely exchange messages;
Visibility and configurability of security (V): the set of features that enables the user to inform himself
whether a security feature is in operation or not and whether the use and provision of services should depend on
the security feature.
Figure 2 gives an overview of the ME registration and connection principles within UMTS with a CS service domain
and a PS service domain. As in GSM/GPRS, user (temporary) identification, authentication and key agreement will take
place independently in each service domain. User plane traffic will be ciphered using the cipher key agreed for the
corresponding service domain while control plane data will be ciphered and integrity protected using the cipher and
integrity keys from either one of the service domains. In clause 6 the detailed procedures are defined and when not
otherwise stated they are used in both service domains.
ETSI
12
Common subscription
data base
HLR
PS location
CS location
CS service
domain
3G SGSN
3G MSC/VLR
PS service
domain
PS state
CS state
UTRAN with
distribution
functionality
UTRAN
PS state
UE
Figure 2: Overview of the ME registration and connection principles within UMTS for the separate CN
architecture case when the CN consists of both a CS service domain with evolved MSC/VLR,
3G_MSC/VLR, as the main serving node and an PS service domain with evolved SGSN/GGSN,
3G_SGSN and 3G GGSN, as the main serving nodes (Extract from TS 23.121 [4] Figure 4-8)
Security features
5.1
5.1.1
The following security features related to user identity confidentiality are provided:
-
user identity confidentiality: the property that the permanent user identity (IMSI) of a user to whom a services
is delivered cannot be eavesdropped on the radio access link;
user location confidentiality: the property that the presence or the arrival of a user in a certain area cannot be
determined by eavesdropping on the radio access link;
user untraceability: the property that an intruder cannot deduce whether different services are delivered to the
same user by eavesdropping on the radio access link.
To achieve these objectives, the user is normally identified by a temporary identity by which he is known by the visited
serving network. To avoid user traceability, which may lead to the compromise of user identity confidentiality, the user
should not be identified for a long period by means of the same temporary identity. To achieve these security features,
in addition it is required that any signalling or user data that might reveal the user's identity is ciphered on the radio
access link.
ETSI
13
Clause 6.1 describes a mechanism that allows a user to be identified on the radio path by means of a temporary identity
by which he is known in the visited serving network. This mechanism should normally be used to identify a user on the
radio path in location update requests, service requests, detach requests, connection re-establishment requests, etc.
5.1.2
Entity authentication
user authentication: the property that the serving network corroborates the user identity of the user;
network authentication: the property that the user corroborates that he is connected to a serving network that is
authorised by the user's HE to provide him services; this includes the guarantee that this authorisation is recent.
To achieve these objectives, it is assumed that entity authentication should occur at each connection set-up between the
user and the network. Two mechanisms have been included: an authentication mechanism using an authentication
vector delivered by the user's HE to the serving network, and a local authentication mechanism using the integrity key
established between the user and serving network during the previous execution of the authentication and key
establishment procedure.
Clause 6.3 describes an authentication and key establishment mechanism that achieves the security features listed above
and in addition establishes a secret cipher key (see 5.1.3) and integrity key (see 5.1.4) between the user and the serving
network. This mechanism should be invoked by the serving network after a first registration of a user in a serving
network and after a service request, location update request, attach request, detach request or connection reestablishment request, when the maximum number of local authentications using the derived integrity key have been
conducted.
Clause 6.5 describes the local authentication mechanism. The local authentication mechanism achieves the security
features user authentication and network authentication and uses an integrity key established between user and serving
network during the previous execution of the authentication and key establishment procedure. This mechanism should
be invoked by the serving network after a service request, location update request, attach request, detach request or
connection re-establishment request, provided that the maximum number of local authentications using the same
derived integrity key has not been reached yet.
5.1.3
Confidentiality
The following security features are provided with respect to confidentiality of data on the network access link:
-
cipher algorithm agreement: the property that the MS and the SN can securely negotiate the algorithm that
they shall use subsequently;
cipher key agreement: the property that the MS and the SN agree on a cipher key that they may use subsequently;
confidentiality of user data: the property that user data cannot be overheard on the radio access interface;
confidentiality of signalling data: the property that signalling data cannot be overheard on the radio access
interface;
Cipher key agreement is realised in the course of the execution of the mechanism for authentication and key agreement
(see 6.3). Cipher algorithm agreement is realised by means of a mechanism for security mode negotiation between the
user and the network (see 6.6.9). This mechanism also enables the selected ciphering algorithm and the agreed cipher
key to be applied in the way described in 6.6.
5.1.4
Data integrity
The following security features are provided with respect to integrity of data on the network access link:
-
integrity algorithm agreement: the property that the MS and the SN can securely negotiate the integrity
algorithm that they shall use subsequently;
integrity key agreement: the property that the MS and the SN agree on an integrity key that they may use
subsequently;
ETSI
14
data integrity and origin authentication of signalling data: the property that the receiving entity (MS or SN)
is able to verify that signalling data has not been modified in an unauthorised way since it was sent by the
sending entity (SN or MS) and that the data origin of the signalling data received is indeed the one claimed;
Integrity key agreement is realised in the course of the execution of the mechanism for authentication and key
agreement (see 6.3). Integrity algorithm agreement is realised by means of a mechanism for security mode negotiation
between the user and the network (see 6.6.9). This mechanism also enables the selected integrity algorithm and the
agreed integrity key to be applied in the way described in 6.4.
5.1.5
In certain cases, SN may request the MS to send it the mobile equipment identity of the terminal. The mobile equipment
identity shall only be sent after authentication of SN with exception of emergency calls. The IMEI should be securely
stored in the terminal. However, the presentation of this identity to the network is not a security feature and the
transmission of the IMEI is not protected. Although it is not a security feature, it should not be deleted from UMTS
however, as it is useful for other purposes.
5.2
5.2.1
Void
5.2.2
Void
5.2.3
Void
5.2.4
NOTE:
Some feature will be provided which will allow fraud information to be exchanged between 3GMS
providers according to time constraints that yet have to be defined.
5.3
5.3.1
User-to-USIM authentication
This feature provides the property that access to the USIM is restricted until the USIM has authenticated the user.
Thereby, it is ensured that access to the USIM can be restricted to an authorised user or to a number of authorised users.
To accomplish this feature, user and USIM must share a secret (e.g. a PIN) that is stored securely in the USIM. The user
gets access to the USIM only if he/she proves knowledge of the secret.
This security feature is implemented by means of the mechanism described in TS 31.101 [5].
5.3.2
USIM-Terminal Link
This feature ensures that access to a terminal or other user equipment can be restricted to an authorised USIM. To this
end, the USIM and the terminal must share a secret that is stored securely in the USIM and the terminal. If a USIM fails
to prove its knowledge of the secret, it will be denied access to the terminal.
This security feature is implemented by means of the mechanism described in TS 22.022 [6].
ETSI
15
5.4
Application security
5.4.1
USIM Application Toolkit, as specified in TS 31.111 [15], provides the capability for operators or third party providers
to create applications which are resident on the USIM (similar to SIM Application Toolkit in GSM). There exists a need
to secure messages which are transferred over the network to applications on the USIM, with the level of security
chosen by the network operator or the application provider.
Security features for USIM Application Toolkit are implemented by means of the mechanisms described in
TS 23.048 [7]. These mechanisms address the security requirements identified in TS 22.048 [16].
5.4.2
Void
5.4.3
Void
5.4.4
Void
5.5
5.5.1
Visibility
Although in general the security features should be transparent to the user, for certain events and according to the user's
concern, greater user visibility of the operation of security features should be provided. This yields to a number of
features that inform the user of security-related events, such as:
-
indication of access network encryption: the property that the user is informed whether the confidentiality of user
data is protected on the radio access link, in particular when non-ciphered calls are set-up;
indication of the level of security: the property that the user is informed on the level of security that is provided
by the visited network, in particular when a user is handed over or roams into a network with lower security level
(3G 2G).
5.5.2
Configurability
Configurability is the property that that the user can configure whether the use or the provision of a service should
depend on whether a security feature is in operation. A service can only be used if all security features, which are
relevant to that service and which are required by the configurations of the user, are in operation. The following
configurability features are suggested:
-
Enabling/disabling user-USIM authentication: the user should be able to control the operation of user-USIM
authentication, e.g., for some events, services or use.
Accepting/rejecting incoming non-ciphered calls: the user should be able to control whether the user accepts or
rejects incoming non-ciphered calls;
Setting up or not setting-up non-ciphered calls: the user should be able to control whether the user sets up
connections when ciphering is not enabled by the network;
Accepting/rejecting the use of certain ciphering algorithms: the user should be able to control which ciphering
algorithms are acceptable for use.
ETSI
16
6.1
6.1.1
General
This mechanism allows the identification of a user on the radio access link by means of a temporary mobile subscriber
identity (TMSI/P-TMSI). A TMSI /P-TMSI has local significance only in the location area or routing area in which the
user is registered. Outside that area it should be a accompanied by an appropriate Location Area Identification (LAI) or
Routing Area Identification (RAI) in order to avoid ambiguities. The association between the permanent and temporary
user identities is kept by the Visited Location Register (VLR/SGSN) in which the user is registered.
The TMSI/P-TMSI, when available, is normally used to identify the user on the radio access path, for instance in paging
requests, location update requests, attach requests, service requests, connection re-establishment requests and detach
requests.
The procedures and mechanisms are described in GSM 03.20 [8] and TS 23.060 [9]. The following sections contain a
summary of this feature.
6.1.2
The purpose of the mechanism described in this subsection is to allocate a new TMSI/LAI pair to a user by which he
may subsequently be identified on the radio access link.
The procedure should be performed after the initiation of ciphering. The ciphering of communication over the radio
path is specified in clause 6.6. The allocation of a temporary identity is illustrated in Figure 3.
MS
VLR/SGSN
TMUI Allocation Command
TMUIn, LAIn
TMUI Allocation Complete
Figure 3: TMSI allocation
6.1.3
If the serving network does not receive an acknowledgement of the successful allocation of a temporary identity from
the user, the network shall maintain the association between the new temporary identity TMSIn and the IMSI and
between the old temporary identity TMSIo (if there is any) and the IMSI.
For a user-originated transaction, the network shall allow the user to identify itself by either the old temporary identity
TMSIo or the new temporary identity TMSIn. This allows the network to determine the temporary identity stored in the
mobile station. The network shall subsequently delete the association between the other temporary identity and the
IMSI, to allow the temporary identity to be allocated to another user.
ETSI
17
For a network-originated transaction, the network shall identify the user by its permanent identity (IMSI). When radio
contact has been established, the network shall instruct the user to delete any stored TMSI. When the network receives
an acknowledgement from the user, the network shall delete the association between the IMSI and any TMSI to allow
the released temporary identities to be allocated to other users.
Subsequently, in either of the cases above, the network may initiate the normal TMSI reallocation procedure.
Repeated failure of TMSI reallocation (passing a limit set by the operator) may be reported for O&M action.
6.1.4
Location update
In case a user identifies itself using a TMSIo/LAIo pair that was assigned by the visited VLRn the IMSI can normally
be retrieved from the database. If this is not the case, the visited VLRn should request the user to identify itself by
means of its permanent user identity. This mechanism is described in 6.2.
In case a user identifies itself using a TMSIo/LAIo pair that was not assigned by the visited VLRn and the visited VLRn
and the previously visited VLRo exchange authentication data, the visited VLRn should request the previously visited
VLRo to send the permanent user identity. This mechanism is described in 6.3.4, it is integrated in the mechanism for
distribution of authentication data between VLRs. If the previously visited VLRo cannot be contacted or cannot retrieve
the user identity, the visited VLRn should request the user to identify itself by means of its permanent user identity.
This mechanism is described in 6.2.
6.2
The mechanism described in here allows the identification of a user on the radio path by means of the permanent
subscriber identity (IMSI).
The mechanism should be invoked by the serving network whenever the user cannot be identified by means of a
temporary identity. In particular, it should be used when the user registers for the first time in a serving network, or
when the serving network cannot retrieve the IMSI from the TMSI by which the user identifies itself on the radio path.
The mechanism is illustrated in Figure 4.
ME/USIM
VLR/SGSN
User identity request
User identity response
IMSI
6.3
6.3.1
General
The mechanism described here achieves mutual authentication by the user and the network showing knowledge of a
secret key K which is shared between and available only to the USIM and the AuC in the user's HE. In addition the
USIM and the HE keep track of counters SQNMS and SQNHE respectively to support network authentication. The
sequence number SQNHE is an individual counter for each user and the sequence number SQNMS denotes the highest
sequence number the USIM has accepted.
The method was chosen in such a way as to achieve maximum compatibility with the current GSM security architecture
and facilitate migration from GSM to UMTS. The method is composed of a challenge/response protocol identical to the
GSM subscriber authentication and key establishment protocol combined with a sequence number-based one-pass
protocol for network authentication derived from ISO/IEC 9798-4 [10] (section 5.1.1).
ETSI
18
VLR/SGSN
HE/HLR
Distribution of
authentication
vectors from HE
to SN
ETSI
19
A procedure to distribute authentication information from the HE/AuC to the VLR/SGSN. This procedure is described
in 6.3.2. The VLR/SGSN is assumed to be trusted by the user's HE to handle authentication information securely. It is
also assumed that the intra-system links between the VLR/SGSN to the HE/AuC are adequately secure. It is further
assumed that the user trusts the HE.
A procedure to mutually authenticate and establish new cipher and integrity keys between the VLR/SGSN and the MS.
This procedure is described in 6.3.3.
A procedure to distribute authentication data from a previously visited VLR to the newly visited VLR. This procedure is
described in 6.3.4. It is also assumed that the links between VLR/SGSNs are adequately secure.
6.3.2
The purpose of this procedure is to provide the VLR/SGSN with an array of fresh authentication vectors from the user's
HE to perform a number of user authentications.
VLR/SGSN
HE
Authentication data request
IMSI
Authentication data response
AV(1..n)
ETSI
20
Generate SQN
Generate RAND
SQN
RAND
AMF
K
f1
MAC
f2
f3
f4
f5
XRES
CK
IK
AK
ETSI
21
a message authentication code MAC = f1K(SQN || RAND || AMF) where f1 is a message authentication function;
an expected response XRES = f2K (RAND) where f2 is a (possibly truncated) message authentication function;
6.3.3
The purpose of this procedure is to authenticate the user and establish a new pair of cipher and integrity keys between
the VLR/SGSN and the USIM. During the authentication, the USIM verifies the freshness of the authentication vector
that is used.
USIM
VLR/SGSN
User authentication request
RAND || AUTN
User authentication response
RES
User authentication reject
CAUSE
ETSI
22
AUTN
RAND
f5
SQN AK
AK
AMF
MAC
SQN
K
f1
f2
f3
f4
XMAC
RES
CK
IK
ETSI
23
SQNMS
K
RAND
AMF
f1*
MAC-S
f5*
xo r
AK
SQNMS AK
ETSI
6.3.4
24
The purpose of this procedure is to provide a newly visited VLR/SGSN with temporary authentication data from a
previously visited VLR/SGSN within the same serving network domain.
The procedure is shown in Figure 11.
VLRn/SGSNn
VLRo/SGSNo
(TMSIo || LAIo)
or (P-TMSIo || RAIo)
IMSI || ({Qi} or {Ti}) ||
((CK || IK || KSI) or (Kc || CKSN))
Figure 11: Distribution of IMSI and temporary authentication data within one serving network domain
The procedure shall be invoked by the newly visited VLRn/SGSNn after the receipt of a location update request (resp.
routing area update request) from the user wherein the user is identified by means of a temporary user identity TMSIo
(resp. P-TMSIo) and the location area identity LAIo (resp. routing area identity RAIo) under the jurisdiction of a
previously visited VLRo/SGSNo that belongs to the same serving network domain as the newly visited VLRn/SGSNn.
The protocol steps are as follows:
a) The VLRn/SGSNn sends a user identity request to the VLRo/SGSNo, this message contains TMSIo and LAIo
(resp. P-TMSIo and RAIo).
b) The VLRo/SGSNo searches the user data in the database.
If the user is found, the VLRo/SGSNo shall send a user identity response back that:
i) shall include the IMSI,
ii) may include a number of unused authentication vectors (quintets or triplets) ordered on a first-in / first-out
basis, and
iii) may include the current security context data: CK, IK and KSI (UMTS) or Kc and CKSN (GSM).
The VLRo/SGSNo subsequently deletes the authentication vectors which have been sent and the data elements
on the current security context.
If the user cannot be identified the VLRo/SGSNo shall send a user identity response indicating that the user
identity cannot be retrieved.
c) If the VLRn/SGSNn receives a user identity response with an IMSI, it creates an entry and stores any
authentication vectors and any data on the current security context that may be included.
If the VLRn/SGSNn receives a user identity response indicating that the user could not be identified, it shall
initiate the user identification procedure described in 6.2.
ETSI
6.3.5
25
Re-synchronisation procedure
A VLR/SGSN may send two types of authentication data requests to the HE/AuC, the (regular) one described in
subsection 6.3.2 and one used in case of synchronisation failures, described in this subsection.
Upon receiving a synchronisation failure message from the user, the VLR/SGSN sends an authentication data request
with a "synchronisation failure indication" to the HE/AuC, together with the parameters:
-
AUTS received by the VLR/SGSN in the response to that request, as described in subsection 6.3.3.
An VLR/SGSN will not react to unsolicited "synchronisation failure indication" messages from the MS.
The VLR/SGSN does not send new user authentication requests to the user before having received the response to its
authentication data request from the HE/AuC (or before it is timed out).
When the HE/AuC receives an authentication data request with a "synchronisation failure indication" it acts as
follows:
1. The HE/AuC retrieves SQNMS from Conc(SQNMS) by computing Conc(SQNMS) f5*K(RAND).
2. The HE/AuC checks if SQNHE is in the correct range, i.e. if the next sequence number generated SQNHE using
would be accepted by the USIM.
3. If SQNHE is in the correct range then the HE/AuC continues with step (6), otherwise it continues with step (4).
4. The HE/AuC verifies AUTS (cf. subsection 6.3.3).
5. If the verification is successful the HE/AuC resets the value of the counter SQNHE to SQNMS.
6. The HE/AuC sends an authentication data response with a new batch of authentication vectors to the
VLR/SGSN. If the counter SQNHE was not reset then these authentication vectors can be taken from storage,
otherwise they are newly generated after resetting SQNHE. In order to reduce the real-time computation burden
on the HE/AuC, the HE/AuC may also send only a single authentication vector in the latter case.
Whenever the VLR/SGSN receives a new batch of authentication vectors from the HE/AuC in an authentication data
response to an authentication data request with synchronisation failure indication it deletes the old ones for that user in
the VLR/SGSN.
The user may now be authenticated based on a new authentication vector from the HE/AuC. Figure 12 shows how resynchronisation is achieved by combining a user authentication request answered by a synchronisation failure message
(as described in section 6.3.3) with an authentication data request with synchronisation failure indication answered by
an authentication data response (as described in this section).
VLR/SGSN
UE/USIM
HLR/AuC
RAND, AUTN
AUTS
RAND, AUTS
{Qi}
Figure 12: Resynchronisation mechanism
ETSI
6.3.6
26
The purpose of this procedure is to provide a mechanism for reporting authentication failures from the serving
environment back to the home environment.
The procedure is shown in Figure 13.
VLR/SGSN
HLR
Authentication failure report
The procedure is invoked by the serving network VLR/SGSN when the authentication procedure fails. The
authentication failure report shall contain:
1. Subscriber identity;
2. Failure cause code. The possible failure causes are either that the network signature was wrong or that the user
response was wrong;
3. Access type. This indicates the type of access that initiated the authentication procedure;
4. Authentication re-attempt. This indicates whether the failure was produced in a normal authentication attempt or
it was due to an authentication reattempt (there was a previous unsuccessful authentication);
5. VLR/SGSN address;
6. RAND. This number uniquely identifies the specific AV that failed authentication.
The HE may decide to cancel the location of the user after receiving an authentication failure report and may store the
received data so that further processing to detect possible fraud situations could be performed.
6.3.7
ETSI
6.4
27
6.4.1
Authentication and key setting are triggered by the authentication procedure and described in 6.3. Authentication and
key setting may be initiated by the network as often as the network operator wishes. Key setting can occur as soon as
the identity of the mobile subscriber (i.e. P-TMSI, TMSI or IMSI) is known by the VLR/SGSN. The CK and IK are
stored in the VLR/SGSN and transferred to the RNC when needed. The CK and IK for the CS domain are stored on the
USIM and updated at the next authentication from this domain. The CK and IK for the PS domain are stored on the
USIM and updated at the next authentication from this domain.
If an authentication procedure is performed during a connection (PS or CS mode), the new cipher key CK and integrity
key IK shall be taken in use in both the RNC and the ME as part of the security mode set-up procedure (see 6.4.5) that
follows the authentication procedure.
6.4.2
When an MS wishes to establish a connection with the network, the MS shall indicate to the network in the MS/USIM
Classmark which cipher and integrity algorithms the MS supports. This information itself must be integrity protected.
As it is the case that the RNC does not have the integrity key IK when receiving the MS/USIM Classmark this
information must be stored in the RNC. The data integrity of the classmark is performed, during the security mode setup procedure by use of the most recently generated IK (see section 6.4.5).
The network shall compare its integrity protection capabilities and preferences, and any special requirements of the
subscription of the MS, with those indicated by the MS and act according to the following rules:
1) If the MS and the network have no versions of the UIA algorithm in common, then the connection shall be
released.
2) If the MS and the network have at least one version of the UIA algorithm in common, then the network shall
select one of the mutually acceptable versions of the UIA algorithm for use on that connection.
The network shall compare its ciphering capabilities and preferences, and any special requirements of the subscription
of the MS, with those indicated by the MS and act according to the following rules:
1) If the MS and the network have no versions of the UEA algorithm in common and the network is not prepared to
use an unciphered connection, then the connection shall be released.
2) If the MS and the network have no versions of the UEA algorithm in common and the user (respectively the
user's HE) and the network are willing to use an unciphered connection, then an unciphered connection shall be
used.
3) If the MS and the network have at least one version of the UEA algorithm in common, then the network shall
select one of the mutually acceptable versions of the UEA algorithm for use on that connection.
Because of the separate mobility management for CS and PS services, one CN domain may, independent of the other
CN, establish a connection to one and the same MS. Change of ciphering and integrity mode (algorithms) at
establishment of a second MS to CN connection shall not be permitted. The preferences and special requirements for
the ciphering and integrity mode setting shall be common for both domains. (e.g. the order of preference of the
algorithms).
6.4.3
Authentication and key agreement, which generates cipher/integrity keys, is not mandatory at call set-up, and there is
therefore the possibility of unlimited and malicious re-use of compromised keys. A mechanism is needed to ensure that
a particular cipher/integrity key set is not used for an unlimited period of time, to avoid attacks using compromised
keys. The USIM shall therefore contain a mechanism to limit the amount of data that is protected by an access link key
set.
ETSI
28
Each time an RRC connection is released the values STARTCS and STARTPS of the bearers that were protected in that
RRC connection are compared with the maximum value, THRESHOLD. If STARTCS and/or STARTPS have reached
the maximum value (THRESHOLD), the ME marks the START value in the USIM for the corresponding core network
domain(s) as invalid by setting the STARTCS and/or STARTPS to THRESHOLD, deletes the cipher key and the integrity
key stored on the USIM and sets the KSI to invalid (refer to section 6.4.4). Otherwise, the STARTCS and STARTPS are
stored in the USIM. The maximum value THRESHOLD is set by the operator and stored in the USIM.
When the next RRC connection is established START values are read from the USIM. Then, the ME shall trigger the
generation of a new access link key set (a cipher key and an integrity key) if STARTCS and/or STARTPS has reached the
maximum value THRESHOLD, for the corresponding core network domain(s).
This mechanism will ensure that a cipher/integrity key set cannot be reused beyond the limit set by the operator.
When the user is attached to a UTRAN, a R99+ ME with a SIM inserted shall use a default value for maximum value of
STARTCS or STARTPS as described in section 6.8.2.4.
6.4.4
The key set identifier (KSI) is a number which is associated with the cipher and integrity keys derived during
authentication. The key set identifier is allocated by the network and sent with the authentication request message to the
mobile station where it is stored together with the calculated cipher key CK and integrity key IK. KSI in UMTS
corresponds to CKSN in GSM. The USIM stores one KSI/CKSN for the PS domain key set and one KSI/CKSN for the
CS domain key set.
The purpose of the key set identifier is to make it possible for the network to identify the cipher key CK and integrity
key IK which are stored in the mobile station without invoking the authentication procedure. This is used to allow reuse of the cipher key CK and integrity key IK during subsequent connection set-ups.
KSI and CKSN have the same format. The key set identifier is three bits. Seven values are used to identify the key set.
A value of '111' is used by the mobile station to indicate that a valid key is not available for use. At deletion of the
cipher key and integrity key, the KSI is set to '111'. The value '111' in the other direction from network to mobile station
is reserved.
6.4.5
This section describes one common procedure for both ciphering and integrity protection set-up. It is mandatory to start
integrity protection of signalling messages by use of this procedure at each new signalling connection establishment
between MS and VLR/SGSN. The four exceptions when it is not mandatory to start integrity protection are:
-
If the only purpose with the signalling connection establishment and the only result is periodic location
registration, i.e. no change of any registration information.
If there is no MS-VLR/SGSNsignalling after the initial L3 signalling message sent from MS to VLR/SGSN, i.e.
in the case of deactivation indication sent from the MS followed by connection release.
If the only MS-VLR/SGSN signalling after the initial L3 signalling message sent from MS to VLR/SGSN, and
possible user identity request and authentication (see below), is a reject signalling message followed by a
connection release.
If the call is an emergency call teleservice as defined in TS 22.003, see section 6.4.9.2 below.
When the integrity protection shall be started, the only procedures between MS and VLR/SGSN that are allowed after
the initial connection request (i.e. the initial Layer 3 message sent to VLR/SGSN) and before the security mode set-up
procedure are the following:
-
The message sequence flow below describes the information transfer at initial connection establishment, possible
authentication and start of integrity protection and possible ciphering.
ETSI
29
MS
SRNC
VLR/SGSN
Start ciphering/deciphering
ETSI
30
5. The VLR/SGSN initiates integrity and ciphering by sending the RANAP message Security Mode Command to
SRNC. This message contains an ordered list of allowed UIAs in order of preference, and the IK to be used. If
ciphering shall be started, it contains the ordered list of allowed UEAs in order of preference, and the CK to be
used. If a new authentication and security key generation has been performed (see 3 above), this shall be
indicated in the message sent to the SRNC. The indication of new generated keys implies that the START value
to be used shall be reset (i.e. set to zero) at start use of the new keys. Otherwise, it is the START value already
available in the SRNC that shall be used (see 1. above).
6. The SRNC decides which algorithms to use by selecting the highest preference algorithm from the list of
allowed algorithms that matches any of the algorithms supported by the MS (see 6.4.2). The SRNC generates a
random value FRESH and initiates the downlink integrity protection. If the requirements received in the Security
mode command can not be fulfilled, the SRNC sends a SECURITY MODE REJECT message to the requesting
VLR/SGSN. The further actions are described in 6.4.2.
7. The SRNC generates the RRC message Security mode command. The message includes the ME security
capability, optionally the GSM ciphering capability (if received during RRC Connection establishment), the UIA
and FRESH to be used and if ciphering shall be started also the UEA to be used. Additional information (start of
ciphering) may also be included. Because of that the MS can have two ciphering and integrity key sets, the
network must indicate which key set to use. This is obtained by including a CN type indicator information in the
Security mode command message. Before sending this message to the MS, the SRNC generates the MAC-I
(Message Authentication Code for Integrity) and attaches this information to the message.
8. At reception of the Security mode command message, the MS controls that the "UE security capability" received
is equal to the "UE security capability" sent in the initial message. The same applies to the GSM ciphering
capability if it was included in the RRC Connection Establishment. The MS computes XMAC-I on the message
received by using the indicated UIA, the stored COUNT-I and the received FRESH parameter. The MS verifies
the integrity of the message by comparing the received MAC-I with the generated XMAC-I.
9. If all controls are successful, the MS compiles the RRC message Security mode complete and generates the
MAC-I for this message. If any control is not successful, the procedure ends in the MS.
10. At reception of the response message, the SRNC computes the XMAC-I on the message. The SRNC verifies the
data integrity of the message by comparing the received MAC-I with the generated XMAC-I.
11. The transfer of the RANAP message Security Mode Complete response, including the selected algorithms, from
SRNC to the VLR/SGSN ends the procedure.
The Security mode command to MS starts the downlink integrity protection, i.e. this and all following downlink
messages sent to the MS are integrity protected using the new integrity configuration. The Security mode complete
from MS starts the uplink integrity protection, i.e. this and all following messages sent from the MS are integrity
protected using the new integrity configuration. When ciphering shall be started, the Ciphering Activation time
information that is exchanged between SRNC and MS during the Security mode set-up procedure sets the RLC
Sequence Number/Connection Frame Number when to start ciphering in Downlink respective Uplink using the new
ciphering configuration.
6.4.6
The supervision of failed integrity checks shall be performed both in the MS and the SRNC. In case of failed integrity
check (i.e. faulty or missing MAC) is detected after that the integrity protection is started the concerned message shall
be discarded. This can happen on the RNC side or on the MS side.
6.4.7
The following procedure is used by the RNC to periodically perform a local authentication. At the same time, the
amount of data sent during the RRC connection is periodically checked by the RNC and the UE. The RNC is
monitoring the COUNT-C value associated to each radio bearer. The procedure is triggered whenever any of these
values reaches a critical checking value. The granularity of these checking values and the values themselves are defined
by the visited network. All messages in the procedure are integrity protected.
ETSI
31
UE
RNC
1. Counter Check
6.4.8
The ciphering and integrity protection algorithms are driven by counters (COUNT-C and COUNT-I) that at connection
establishment need to be initialised. For that purpose the ME and the USIM have the ability to store a START value.
The ME and the USIM store a STARTCS value for the CS cipher/integrity keys and a STARTPS value for the PS
cipher/integrity keys. The length of START is 20 bits.
The ME only contains (valid) START values when it is powered-on and a USIM is inserted. When the ME is poweredoff or the USIM is removed, the ME deletes its START values. After power-on or insertion of a USIM, the USIM sends
its START values to the ME, and the ME stores them. During idle mode, the START values in the ME and in the USIM
are identical and static.
At radio connection establishment for a particular serving network domain (CS or PS) the ME sends the STARTCS and
the STARTPS value to the RNC in the RRC connection setup complete message. The ME marks the START values in
the USIM as invalid by setting STARTCS and STARTPS to THRESHOLD.
The ME and the RNC initialise the 20 most significant bits of the RRC HFN (for integrity protection), the RLC HFN
(for ciphering) and the MAC-d HFN (for ciphering) to the START value of the corresponding service domain; the
remaining bits are initialised to 0. Also the RRC SN (for integrity protection) and the RLC SN (for ciphering) are
initialised to 0.
During an ongoing radio connection, the STARTCS value in the ME and in the SRNC is defined as the 20 most
significant bits of the maximum of all current COUNT-C and COUNT-I values for all signalling radio bearers and CS
user data radio bearers protected using CKCS and/or IKCS, incremented by2, i.e.:
STARTCS' = MSB20 ( MAX {COUNT-C, COUNT-I | all radio bearers (including signalling) protected with CKCS
and IKCS}) +2.
-
If current STARTCS < STARTCS' then STARTCS = STARTCS', otherwise STARTCS is unchanged.
ETSI
32
Likewise, during an ongoing radio connection, the STARTPS value in the ME and in the SRNC is defined as the 20 most
significant bits of the maximum of all current COUNT-C and COUNT-I values for all signalling radio bearers and PS
user data radio bearers protected using CKPS and/or IKPS, incremented by2, i.e.:
STARTPS' = MSB20 ( MAX {COUNT-C, COUNT-I | all radio bearers (including signalling) protected with CKPS
and IKPS}) +2.
-
If current STARTPS < STARTPS' then STARTPS = STARTPS', otherwise STARTPS is unchanged.
If any of the COUNT-C or COUNT-I assigned to the radio bearers of the same CN domain reaches its maximum value,
the ME and SRNC shall set START of the corresponding CN domain to its maximum value.
Upon radio connection release and when a set of cipher/integrity keys is no longer used, the ME updates STARTCS and
STARTPS in the USIM with the current values.
During authentication and key agreement the START value associated with the new key set of the corresponding
service domain is set to 0 in the USIM and in the ME.
6.4.9
PLMNs shall support an emergency call teleservice as defined in TS 22.003 which fulfils the additional service
requirements defined in TS 22.101.
6.4.9.1
The security mode procedure shall be applied as part of emergency call establishment as defined in TS 24.008. Thus,
integrity protection (and optionally ciphering) shall be applied as for a non-emergency call. If authentication of the
(U)SIM fails for any reason, the emergency call shall proceed as in 6.4.9.2 d) below. Once the call is in progress with
integrity protection (and optionally ciphering) applied, failure of integrity checking or ciphering is an unusual
circumstance and must be treated in the same manner as other equipment failures, that is, the call will terminate.
6.4.9.2
As a serving network option, emergency calls may be established without the network having to apply the security
mode procedure as defined in TS 24.008.
The following are the only cases where the "security procedure not applied" option may be used:
a) Authentication is impossible because the (U)SIM is absent;
b) Authentication is impossible because the serving network cannot obtain authentication vectors due to a network
failure;
c) Authentication is impossible because the (U)SIM is not permitted to receive non-emergency services from the
serving network (e.g. there is no roaming agreement or the IMSI is barred);
d) Authentication is possible but the serving network cannot successfully authenticate the (U)SIM.
6.5
6.5.1
General
Most control signalling information elements that are sent between the MS and the network are considered sensitive and
must be integrity protected. A message authentication function shall be applied on these signalling information elements
transmitted between the ME and the RNC.
After the RRC connection establishment and execution of the security mode set-up procedure, all dedicated MS <>
network control signalling messages (e.g. RRC, MM, CC, GMM, and SM messages) shall be integrity protected. The
Mobility Management layer in the MS supervises that the integrity protection is started (see section 6.4.5).
ETSI
33
All signalling messages except the following ones shall then be integrity protected:
HANDOVER TO UTRAN COMPLETE
PAGING TYPE 1
PUSCH CAPACITY REQUEST
PHYSICAL SHARED CHANNEL ALLOCATION
RRC CONNECTION REQUEST
RRC CONNECTION SETUP
RRC CONNECTION SETUP COMPLETE
RRC CONNECTION REJECT
RRC CONNECTION RELEASE (CCCH only)
SYSTEM INFORMATION (BROADCAST INFORMATION)
SYSTEM INFORMATION CHANGE INDICATION
TRANSPORT FORMAT COMBINATION CONTROL (TM DCCH only)
DIRECTION
MESSAGE
IK
COUNT-I
FRESH
DIRECTION
MESSAGE
IK
f9
FRESH
f9
MAC -I
XMAC -I
Sender
UE or RNC
Receiver
RNC or UE
ETSI
6.5.4
6.5.4.1
34
RRC SN
(4 bits)
COUNT-I
6.5.4.2
IK
6.5.4.3
FRESH
ETSI
6.5.4.4
35
DIRECTION
6.5.4.5
MESSAGE
The signalling message itself with the radio bearer identity. The latter is appended in front of the message. Note that the
radio bearer identity is not transmitted with the message but it is needed to avoid that for different instances of message
authentication codes the same set of input parameters is used.
6.5.5
There may be one IK for CS connections (IKCS), established between the CS service domain and the user and one IK for
PS connections (IKPS) established between the PS service domain and the user.
The data integrity of radio bearers for user data is not protected.
The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service
domains. These signalling radio bearers are data integrity protected by the IK of the service domain for which the most
recent security mode negotiation took place. This may require that the integrity key of an (already integrity protected)
ongoing signalling connection has to be changed, when a new connection is established with another service domain, or
when a security mode negotiation follow a re-authentication during an ongoing connection. This change should be
completed by the RNC within five seconds after receiving the security mode command from the VLR/SGSN.
NOTE:
6.5.6
For the behaviour of the terminal regarding key changes see section 6.4.5.
UIA identification
Each UMTS Integrity Algorithm (UIA) will be assigned a 4-bit identifier. Currently, the following values have been
defined:
"00012"
UIA1, Kasumi.
6.6
6.6.1
General
User data and some signalling information elements are considered sensitive and should be confidentiality protected. To
ensure identity confidentiality (see section 6.1), the temporary user identity (P-)TMSI should be transferred in a
protected mode at allocation time and at other times when the signalling procedures permit it.
These needs for a protected mode of transmission are fulfilled by a confidentiality function which is applied on
dedicated channels between the ME and the RNC.
ETSI
6.6.2
36
Layer of ciphering
The ciphering function is performed either in the RLC sub-layer or in the MAC sub-layer, according to the following
rules:
-
If a radio bearer is using a non-transparent RLC mode (AM or UM), ciphering is performed in the RLC sublayer.
If a radio bearer is using the transparent RLC mode, ciphering is performed in the MAC sub-layer (MAC-d
entity).
Ciphering when applied is performed in the S-RNC and the ME and the context needed for ciphering (CK, HFN, etc.) is
only known in S-RNC and the ME.
6.6.3
Ciphering method
Figure 16b illustrates the use of the ciphering algorithm f8 to encrypt plaintext by applying a keystream using a bit per
bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same
keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext.
COUNT-C
COUNT-C
DIRECTION
BEARER
CK
LENGTH
BEARER
CK
f8
KEYSTREAM
BLOCK
PLAINTEXT
BLOCK
DIRECTION
LENGTH
f8
KEYSTREAM
BLOCK
CIPHERTEXT
BLOCK
Sender
UE or RNC
PLAINTEXT
BLOCK
Receiver
RNC or UE
Figure 16b: Ciphering of user and signalling data transmitted over the radio access link
The input parameters to the algorithm are the cipher key CK, a time dependent input COUNT-C, the bearer identity
BEARER, the direction of transmission DIRECTION and the length of the keystream required LENGTH. Based on
these input parameters the algorithm generates the output keystream block KEYSTREAM which is used to encrypt the
input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT.
The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.
6.6.4
6.6.4.1
ETSI
37
COUNT-C is composed of two parts: a "short" sequence number and a "long" sequence number. The "short" sequence
number forms the least significant bits of COUNT-C while the "long" sequence number forms the most significant bits
of COUNT-C. The update of COUNT-C depends on the transmission mode as described below (see figure 16c).
RLC TM
MAC-d DCH
RLC UM
RLC AM
CFN (8 bits)
RLC SN (7 bits)
COUNT-C
For RLC TM on DCH, the "short" sequence number is the 8-bit connection frame number CFN of COUNT-C. It
is independently maintained in the ME MAC-d entity and the SRNC MAC-d entity. The "long" sequence
number is the 24-bit MAC-d HFN, which is incremented at each CFN cycle.
For RLC UM mode, the "short" sequence number is the 7-bit RLC sequence number (RLC SN) and this is part
of the RLC UM PDU header. The "long" sequence number is the 25-bit RLC UM HFN which is incremented at
each RLC SN cycle.
For RLC AM mode, the "short" sequence number is the 12-bit RLC sequence number (RLC SN) and this is part
of the RLC AM PDU header. The "long" sequence number is the 20-bit RLC AM HFN which is incremented at
each RLC SN cycle.
The hyperframe number HFN is initialised by means of the parameter START, which is described in section 6.4.8. The
ME and the RNC then initialise the 20 most significant bits of the RLC AM HFN, RLC UM HFN and MAC-d HFN to
START. The remaining bits of the RLC AM HFN, RLC UM HFN and MAC-d HFN are initialised to zero.
When a new radio bearer is created during a RRC connection in ciphered mode, the HFN is initialised by the current
START value (see section 6.4.8).
6.6.4.2
CK
ETSI
38
At handover, the CK is transmitted within the network infrastructure from the old RNC to the new RNC, to enable the
communication to proceed. The cipher CK remains unchanged at handover.
6.6.4.3
BEARER
6.6.4.4
DIRECTION
6.6.4.5
LENGTH
6.6.5
There is one CK for CS connections (CKCS), established between the CS service domain and the user and one CK for
PS connections (CKPS) established between the PS service domain and the user.
The radio bearers for CS user data are ciphered with CKCS.
The radio bearers for PS user data are ciphered with CKPS.
The signalling radio bearers are used for transfer of signalling data for services delivered by both CS and PS service
domains. These signalling radio bearers are ciphered by the CK of the service domain for which the most recent
security mode negotiation took place. This may require that the cipher key of an (already ciphered) ongoing signalling
connection has to be changed, when a new connection is established with another service domain, or when a security
mode negotiation follows a re-authentication during an ongoing connection. This change should be completed by the
RNC within five seconds after receiving the security mode command from the VLR/SGSN.
NOTE:
6.6.6
For the behaviour of the terminal regarding key changes see section 6.4.5.
UEA identification
Each UEA will be assigned a 4-bit identifier. Currently the following values have been defined:
"00002"
UEA0, no encryption.
"00012"
UEA1, Kasumi.
6.7
Void
ETSI
39
6.8
6.8.1
6.8.1.1
General
For UMTS subscribers, authentication and key agreement will be performed as follows:
-
UMTS AKA shall be applied when the user is attached to a GSM BSS, in case the user has a ME capable of
UMTS AKA and also the VLR/SGSN is R99+. In this case, the GSM cipher key Kc is derived from the UMTS
cipher/integrity keys CK and IK, by the VLR/SGSN on the network side and by the USIM on the user side.
GSM AKA shall be applied when the user is attached to a GSM BSS, in case the user has a ME not capable of
UMTS AKA. In this case, the GSM user response SRES and the GSM cipher key Kc are derived from the
UMTS user response RES and the UMTS cipher/integrity keys CK and IK. A R98- VLR/SGSN uses the stored
Kc and RES and a R99+ VLR/SGSN derives the SRES from RES and Kc from CK, IK.
NOTE:
To operate within a ME not capable of UMTS AKA, the USIM may support the SIM-ME interface as
defined in GSM 11.11, and support GSM AKA which provides the corresponding GSM functionality for
calculating SRES and Kc based on the authentication key K and the 3G authentication algorithm
implemented in the USIM. Due to the fact that the UMTS authentication algorithm only computes CK/IK
and RES, conversion of CK/IK to Kc shall be achieved by using the conversion function c3, and
conversion of RES to SRES by c2.
GSM AKA shall be applied when the user is attached to a GSM BSS, in case the VLR/SGSN is R98-. In this
case, the USIM derives the GSM user response SRES and the GSM cipher key Kc from the UMTS user response
RES and the UMTS cipher/integrity keys CK, IK.
The execution of the UMTS (resp. GSM) AKA results in the establishment of a UMTS (resp. GSM) security context
between the user and the serving network domain to which the VLR/SGSN belongs. The user needs to separately
establish a security context with each serving network domain.
Figure 18 shows the different scenarios that can occur with UMTS subscribers in a mixed network architecture.
ETSI
40
Release 99+
HLR/AuC
Quintets
Kc
[Kc]
UTRAN
RAND
AUTN
RES
RAND
AUTN
RES
CK, IK
Kc
Kc
[Kc]
GSM BSS
ME capable of
UMTS AKA
CK, IK
Release 98VLR/SGSN
CK, IK Kc
RES SRES
[Kc]
CK
IK
Triplets
CK, IK Kc
RES SRES
RAND
[AUTN]
SRES
ME not
capable of UMTS
AKA
ME
Kc
Kc
CK, IK
Kc
CK, IK
Kc
RAND
SRES
CK, IK Kc
RES SRES
CK, IK Kc
RES SRES
USIM
UMTS security
GSM security
6.8.1.2
R99+ HLR/AuC
Upon receipt of an authentication data request from a R99+ VLR/SGSN for a UMTS subscriber, a R99+ HLR/AuC
shall send quintets, generated as specified in 6.3.
Upon receipt of an authentication data request from a R98- VLR/SGSN for a UMTS subscriber, a R99+ HLR/AuC
shall send triplets, derived from quintets using the following conversion functions:
a) c1: RAND[GSM] = RAND
b) c2: SRES[GSM] = XRES*1 xor XRES*2 xor XRES*3 xor XRES*4
c) c3: Kc[GSM] = CK1 xor CK2 xor IK1 xor IK2
whereby XRES* is 16 octets long and XRES* = XRES if XRES is 16 octets long and XRES* = XRES || 0...0 if XRES
is shorter than 16 octets, XRES*i are all 4 octets long and XRES* = XRES*1 || XRES*2 || XRES*3 || XRES*4, CKi and
IKi are both 64 bits long and CK = CK1 || CK2 and IK = IK1 || IK2
ETSI
6.8.1.3
41
R99+ VLR/SGSN
When the ME is capable of the USIM-ME interface, then UMTS AKA is performed and the VLR/SGSN receives the
UMTS response RES.
UMTS AKA results in the establishment of a UMTS security context; the UMTS cipher/integrity keys CK and
IK and the key set identifier KSI are stored in theVLR/SGSN.
When the user is attached to a UTRAN, the UMTS cipher/integrity keys are sent to the RNC, where the
cipher/integrity algorithms are allocated.
When the user is attached to a GSM BSS, UMTS AKA is followed by the derivation of the GSM cipher key
from the UMTS cipher/integrity keys. When the user receives service from an MSC/VLR, the derived cipher key
Kc is then sent to the BSC (and forwarded to the BTS). When the user receives service from an SGSN, the
derived cipher key Kc is applied in the SGSN itself.
UMTS authentication and key freshness is always provided to UMTS subscribers with R99+ ME independently
of the radio access network.
When the ME is not capable of the USIM-ME interface, then GSM AKA is performed and the VLR/SGSN receives the
GSM response SRES.
GSM AKA results in the establishment of a GSM security context; the GSM cipher key Kc and the cipher key
sequence number CKSN are stored in the VLR/SGSN.
The R99+ VLR/SGSN shall reject authentication if SRES is received in response of a UMTS challenge (RAND,
AUTN) over an Iu-Interface.
The R99+ VLR/SGSN shall accept authentication if a valid SRES is received in response of a UMTS challenge
(RAND, AUTN) over A or Gb-Interface. This will happen in case a UICC is inserted in a ME that is not capable of
UMTS AKA and is attached to a GSM BSS. In this case the R99+ VLR/SGSN uses function c2 to convert RES (from
the quintet) to SRES to verify the received SRES.
UMTS subscriber with R98- ME
When the user has R98- ME, the R99+ VLR/SGSN sends the ME a GSM authentication challenge using a triplet that is
either:
a) derived by means of the conversion functions c2 and c3 in the R99+ VLR/SGSN from a quintet that is:
i) retrieved from the local database,
ii) provided by the HLR/AuC, or
iii) provided by the previously visited R99+ VLR/SGSN, or
b) provided as a triplet by the previously visited VLR/SGSN.
NOTE:
NOTE:
For a UMTS subscriber, all triplets are derived from quintets, be it in the HLR/AuC or in an VLR/SGSN.
ETSI
42
GSM AKA results in the establishment of a GSM security context; the GSM cipher key Kc and the cipher key sequence
number CKSN are stored in the VLR/SGSN.
In this case the user is attached to a GSM BSS. When the user receives service from an MSC/VLR, the GSM cipher key
is sent to the BSC (and forwarded to the BTS). When the user receives service from an SGSN, the derived cipher key
Kc is applied in the SGSN itself.
UMTS authentication and key freshness cannot be provided to UMTS subscriber with R98- ME.
6.8.1.4
R99+ ME
Release 99+ ME that has UTRAN radio capability shall support the USIM-ME interface as specified in TS 31.102 [20].
Rel-4 ME that has no UTRAN radio capabilities may support the USIM-ME interface as specified in TS 31.102 [20].
Rel5+ ME that has no UTRAN radio capabilities shall support the USIM-ME interface as specified in TS 31.102 [20].
A ME capable of UMTS AKA with a USIM active and attached to a UTRAN shall only participate in UMTS AKA and
shall not participate in GSM AKA.
A ME capable of UMTS AKA with a USIM active and attached to a GSM BSS shall participate in UMTS AKA and
may participate in GSM AKA. Participation in GSM AKA is required to allow registration in a R98- VLR/SGSN.
A ME that not capable of UMTS AKA with a USIM active can only participate in GSM AKA.
The execution of UMTS AKA results in the establishment of a UMTS security context; the UMTS cipher/integrity keys
CK and IK and the key set identifier KSI are passed to the ME. If the USIM supports conversion function c3 and/or
GSM AKA, the ME shall also receive a GSM cipher key Kc derived at the USIM.
The execution of GSM AKA results in the establishment of a GSM security context; the GSM cipher key Kc and the
cipher key sequence number CKSN are stored in the ME.
6.8.1.5
USIM
The USIM shall support UMTS AKA and may support backwards compatibility with the GSM system, which consists
of:
Feature 1:
GSM cipher key derivation (conversion function c3) to access GSM BSS attached to a R99+
VLR/SGSN using a dual-mode R99+ ME;
Feature 2:
GSM AKA to access the GSM BSS attached to a R98- VLR/SGSN or when using ME not capable
of UMTS AKA;
Feature 3:
SIM-ME interface (GSM 11.11) to operate within ME not capable of UMTS AKA.
When the ME provides the USIM with RAND and AUTN, UMTS AKA shall be executed. If the verification of AUTN
is successful, the USIM shall respond with the UMTS user response RES and the UMTS cipher/integrity keys CK and
IK. The USIM shall store CK and IK as current security context data. If the USIM supports access to GSM cipher key
derivation (feature 1), the USIM shall also derive the GSM cipher key Kc from the UMTS cipher/integrity keys CK and
IK using conversion function c3 and send the derived Kc to the ME. In case the verification of AUTN is not successful,
the USIM shall respond with an appropriate error indication to the ME.
When the ME provides the USIM with only RAND, and the USIM supports GSM AKA (Feature 2), GSM AKA shall
be executed. The USIM first computes the UMTS user response RES and the UMTS cipher/integrity keys CK and IK.
The USIM then derives the GSM user response SRES and the GSM cipher key Kc using the conversion functions c2
and c3. The USIM then stores the GSM cipher key Kc as the current security context and sends the GSM user response
SRES and the GSM cipher key Kc to the ME.
In case the USIM does not support GSM cipher key derivation (Feature 1) or GSM AKA (Feature 2), the ME shall be
informed. A USIM that does not support GSM cipher key derivation (Feature 1) cannot operate in any GSM BSS. A
USIM that does not support GSM AKA (Feature 2) cannot operate under a R98- VLR/SGSN or in a both ME that is not
capable of UMTS AKA.
ETSI
6.8.2
6.8.2.1
43
Kc
CK, IK
Triplets
Release 99+
VLR/SGSN
CK
IK
Release 98VLR/SGSN
[Kc]
[Kc]
UTRAN
RAND
SRES
GSM BSS
RAND
SRES
RAND
SRES
R99+ UE
Kc
RAND
SRES
R98- UE
R99+ UE
or
R98- UE
Kc
Kc
CK, IK
Kc
[Kc]
Kc
SIM
6.8.2.2
R99+ HLR/AuC
Upon receipt of an authentication data request for a GSM subscriber, a R99+ HLR/AuC shall send triplets generated as
specified in GSM 03.20.
ETSI
6.8.2.3
44
VLR/SGSN
The R99+ VLR/SGSN shall perform GSM AKA using a triplet that is either:
a) retrieved from the local database,
b) provided by the HLR/AuC, or
c) provided by the previously visited VLR/SGSN.
NOTE: All triplets are originally provided by the HLR/AuC.
GSM AKA results in the establishment of a GSM security context; the GSM cipher key Kc and the cipher key sequence
number CKSN are stored in the VLR/SGSN.
When the user is attached to a UTRAN, the R99+ VLR/SGSN derives the UMTS cipher/integrity keys from the GSM
cipher key using the following conversion functions:
a) c4: CK[UMTS] = Kc || Kc;
b) c5: IK[UMTS] = Kc1 xor Kc2 || Kc || Kc1 xor Kc2;
whereby in c5, Kci are both 32 bits long and Kc = Kc1 || Kc2.
The UMTS cipher/integrity keys are then sent to the RNC where the ciphering and integrity algorithms are allocated.
When the user is attached to a GSM BSS and the user receives service from an MSC/VLR, the cipher key Kc is sent to
the BSC (and forwarded to the BTS). When the user receives service from an SGSN, the cipher key Kc is applied in the
SGSN itself.
6.8.2.4
R99+ ME
6.8.3
The distribution of authentication data (unused authentication vectors and/or current security context data) between
R99+ VLRs/SGSNs of the same service network domain is performed according to chapter 6.3.4. The following four
cases are distinguished related to the distribution of authentication data between VLRs/SGSNs (of the same or different
releases). Conditions for the distribution of such data and for its use when received at VLRn/SGSNn are indicated for
each case:
a) R99+ VLR/SGSN to R99+ VLR/SGSN
UMTS and GSM authentication vectors can be distributed between R99+ VLRs/SGSNs. Note that originally all
authentication vectors (quintets for UMTS subscribers and triplets for GSM subscribers) are provided by the
HLR/AuC.
ETSI
45
Current security context data can be distributed between R99+ VLRs/SGSNs. VLRn/SGSNn shall not use
current security context data received from VLRo/SGSNo to authenticate the subscriber using local
authentication in the following cases:
i) Security context to be established at VLRn/SGSNn requires a different set of keys than the one currently in
use at VLRo/SGSNo. This change of security context is caused by a change of ME release
(R99 ME
R98 ME) when the user registers at VLRn/SGSNn.
ii) Authentication data from VLRo includes Kc+CKSN but no unused AVs and the subscriber has a R99 ME
(under GSM BSS or UTRAN). In this situation, VLRn have no indication of whether the subscriber is GSM
or UMTS and it is not able to decide whether Kc received can be used (in case the subscriber were a GSM
subscriber).
In these two cases, received current security context data shall be discarded and a new AKA procedure shall be
performed.
b) R98- VLR/SGSN to R98- VLR/SGSN
Only triplets can be distributed between R98- VLRs/SGSNs. Note that originally for GSM subscribers, triplets
are generated by HLR/AuC and for UMTS subscribers, they are derived from UMTS authentication vectors by
R99+ HLR/AuC. UMTS AKA is not supported and only GSM security context can be established by a R98VLR/SGSN.
R98- VLRs are not prepared to distribute current security context data.
Since only GSM security context can be established under R98- SGSNs, security context data can be distributed
and used between R98- SGSNs.
c) R99+ VLR/SGSN to R98- VLR/SGSN
R99+ VLR/SGSN can distribute to a new R98- VLR/SGSN triplets originally provided by HLR/AuC for GSM
subscribers or can derive triplets from stored quintets originally provided by R99+ HLR/AuC for UMTS
subscribers. Note that R98- VLR/SGSN can only establish GSM security context.
R99+ VLRs shall not distribute current security context data to R98- VLRs.
Since R98- SGSNs are only prepared to handle GSM security context data, R99+ SGSNs shall only distribute
GSM security context data (Kc, CKSN) to R98- SGSNs.
d) R98- VLR/SGSN to R99+ VLR/SGSN.
In order to not establish a GSM security context for a UMTS subscriber, triplets provided by a R98- VLR/SGSN
can only be used by a R99+ VLR/SGSN to establish a GSM security context under GSM-BSS with a R98- ME.
In all other cases, R99+ VLR/SGSN shall request fresh AVs (either triplets or quintets) to HE. In the event, the
R99+ VLR/SGSN receives quintets, it shall discard the triplets provided by the R98- VLR/SGSN.
R98- VLRs are not prepared to distribute current security context data.
R98- SGSNs can distribute GSM security context data only. The use of this information at R99+ SGSNn shall be
performed according to the conditions stated in a).
6.8.4
If ciphering has been started when an intersystem handover occurs from UTRAN to GSM BSS, the necessary
information (e.g. Kc, supported/allowed GSM ciphering algorithms) is transmitted within the system infrastructure
before the actual handover is executed to enable the communication to proceed from the old RNC to the new GSM
BSS, and to continue the communication in ciphered mode. The RNC may request the MS to send the MS Classmarks 2
and 3 which include information on the GSM ciphering algorithm capabilities of the MS. This is necessary only if the
MS Classmarks 2 and 3 were not transmitted from UE to UTRAN during the RRC Connection Establishment. The
intersystem handover will imply a change of ciphering algorithm from a UEA to a GSM A5. The GSM BSS includes
the selected GSM ciphering mode in the handover command message sent to the MS via the RNC.
The integrity protection of signalling messages is stopped at handover to GSM BSS.
ETSI
46
The START values (see section 6.4.8) shall be stored in the ME/USIM at handover to GSM BSS.
6.8.4.1
A UMTS security context in UTRAN is only established for a UMTS subscriber with a ME that is capable of UMTS
AKA. At the network side, three cases are distinguished:
a) In case of a handover to a GSM BSS controlled by the same MSC/VLR, the MSC/VLR derives the GSM cipher
key Kc from the stored UMTS cipher/integrity keys CK and IK (using the conversion function c3) and sends Kc
to the target BSC (which forwards it to the BTS).
b) In case of a handover to a GSM BSS controlled by other R98- MSC/VLR, the initial MSC/VLR derives the
GSM cipher key from the stored UMTS cipher/integrity keys (using the conversion function c3) and sends it to
the target BSC via the new MSC/VLR controlling the BSC. The initial MSC/VLR remains the anchor point
throughout the service.
c) In case of a handover to a GSM BSS controlled by another R99+ MSC/VLR, the initial MSC/VLR sends the
stored UMTS cipher/integrity keys CK and IK to the new MSC/VLR. The initial MSC/VLR also derives Kc and
sends it to the new MSC/VLR. The new MSC/VLR store the keys and sends the received GSM cipher key Kc to
the target BSC (which forwards it to the BTS). The initial MSC/VLR remains the anchor point throughout the
service.
At the user side, in either case, the ME applies the derived GSM cipher key Kc received from the USIM during the last
UMTS AKA procedure.
6.8.4.2
A GSM security context in UTRAN is only established for a GSM subscribers with a R99+ ME. At the network side,
two cases are distinguished:
a) In case of a handover to a GSM BSS controlled by the same MSC/VLR, the MSC/VLR sends the stored GSM
cipher key Kc to the target BSC (which forwards it to the BTS).
b) In case of a handover to a GSM BSS controlled by another MSC/VLR (R99+ or R98-), the initial MSC/VLR
sends the stored GSM cipher key Kc to the BSC via the new MSC/VLR controlling the target BSC. The initial
MSC/VLR remains the anchor point throughout the service.
If the non-anchor MSC/VLR is R99+, then the anchor MSC/VLR also derives and sends to the non-anchor
MSC/VLR the UMTS cipher/integrity keys CK and IK. The non-anchor MSC/VLR stores all keys. This is done
to allow subsequent handovers in a non-anchor R99+ MSC/VLR.
At the user side, in either case, the ME applies the stored GSM cipher key Kc.
6.8.5
If ciphering has been started when an intersystem handover occurs from GSM BSS to UTRAN, the necessary
information (e.g. CK, IK, START value information, supported/allowed UMTS algorithms) is transmitted within the
system infrastructure before the actual handover is executed to enable the communication to proceed from the old GSM
BSS to the new RNC, and to continue the communication in ciphered mode. The GSM BSS requests the MS to send the
UMTS capability information, which includes information on the START values and UMTS security capabilities of the
MS. The intersystem handover will imply a change of ciphering algorithm from a GSM A5 to a UEA. The target
UMTS RNC includes the selected UMTS ciphering mode in the handover to UTRAN command message sent to the
MS via the GSM BSS.
The integrity protection of signalling messages shall be started immediately after that the intersystem handover from
GSM BSS to UTRAN is completed. The Serving RNC will do this by initiating the RRC security mode control
procedure when the first RRC message (i.e. the Handover to UTRAN complete message) has been received from the
MS. The UE security capability information, that has been sent from MS to RNC via the GSM radio access and the
system infrastructure before the actual handover execution, will then be included in the RRC Security mode command
message sent to MS and then verified by the MS (i.e. verified that it is equal to the UE security capability information
stored in the MS).
ETSI
6.8.5.1
47
A UMTS security context in GSM BSS is only established for UMTS subscribers with a ME that is capable of UMTS
AKA under GSM BSS controlled by a R99+ VLR/SGSN. At the network side, two cases are distinguished:
a) In case of a handover to a UTRAN controlled by the same MSC/VLR, the stored UMTS cipher/integrity keys
CK and IK are sent to the target RNC.
b) In case of a handover to a UTRAN controlled by another MSC/VLR, the initial MSC/VLR sends the stored
UMTS cipher/integrity keys CK and IK to the new RNC via the new MSC/VLR that controls the target RNC.
The initial MSC/VLR remains the anchor point for throughout the service.
The anchor MSC/VLR also derives and sends to the non-anchor MSC/VLR the GSM cipher key Kc. The nonanchor MSC/VLR stores all keys. This is done to allow subsequent handovers in a non-anchor R99+ MSC/VLR.
At the user side, in either case, the ME applies the stored UMTS cipher/integrity keys CK and IK.
6.8.5.2
Handover from GSM BSS to UTRAN with a GSM security context is possible for a GSM subscriber with a R99+ ME
or for a UMTS subscriber with a R99+ ME when the initial MSC/VLR is R98-. At the network side, two cases are
distinguished:
a) In case of a handover to a UTRAN controlled by the same MSC/VLR, UMTS cipher/integrity keys CK and IK
are derived from the stored GSM cipher key Kc (using the conversion functions c4 and c5) and sent to the target
RNC. In case of subsequent handover in a non-anchor R99+ MSC/VLR, a GSM cipher key Kc is received for a
UMTS subscriber if the anchor MSC/VLR is R98-.
b) In case of a handover to a UTRAN controlled by another MSC/VLR, the initial MSC/VLR (R99+ or R98-) sends
the stored GSM cipher key Kc to the new MSC/VLR controlling the target RNC. That MSC/VLR derives UMTS
cipher/integrity keys CK and IK which are then forwarded to the target RNC. The initial MSC/VLR remains the
anchor point for throughout the service.
At the user side, in either case, the ME derives the UMTS cipher/integrity keys CK and IK from the stored GSM cipher
key Kc (using the conversion functions c4 and c5) and applies them.
6.8.6
6.8.6.1
A UMTS security context in UTRAN is only established for UMTS subscribers. At the network side, three cases are
distinguished:
a) In case of an intersystem change to a GSM BSS controlled by the same SGSN, the SGSN derives the GSM
cipher key Kc from the stored UMTS cipher/integrity keys CK and IK (using the conversion function c3) and
applies it.
b) In case of an intersystem change to a GSM BSS controlled by another R99+ SGSN, the initial SGSN sends the
stored UMTS cipher/integrity keys CK and IK to the new SGSN. The new SGSN stores the keys, derives the
GSM cipher key Kc and applies the latter. The new SGSN becomes the new anchor point for the service.
c) In case of an intersystem change to a GSM BSS controlled by a R98- SGSN, the initial SGSN derives the GSM
cipher key Kc and sends the GSM cipher key Kc to the new SGSN. The new SGSN stores the GSM cipher key
Kc and applies it. The new SGSN becomes the new anchor point for the service.
At the user side, in all cases, the ME applies the derived GSM cipher key Kc received from the USIM during the last
UMTS AKA procedure.
ETSI
6.8.6.2
48
A GSM security context in UTRAN is only established for GSM subscribers. At the network side, two cases are
distinguished:
a) In case of an intersystem change to a GSM BSS controlled by the same SGSN, the SGSN starts to apply the
stored GSM cipher key Kc.
b) In case of an intersystem change to a GSM BSS controlled by another SGSN, the initial SGSN sends the stored
GSM cipher key Kc to the (new) SGSN controlling the BSC. The new SGSN stores the key and applies it. The
new SGSN becomes the new anchor point for the service.
At the user side, in both cases, the ME applies the GSM cipher key Kc that is stored.
6.8.7
6.8.7.1
A UMTS security context in GSM BSS is only established for UMTS subscribers with a ME that is capable of UMTS
AKA and connected to a R99+ VLR/SGSN. At the network side, two cases are distinguished:
a) In case of an intersystem change to a UTRAN controlled by the same SGSN, the stored UMTS cipher/integrity
keys CK and IK are sent to the target RNC.
b) In case of an intersystem change to a UTRAN controlled by another SGSN, the initial SGSN sends the stored
UMTS cipher/integrity keys CK and IK to the (new) SGSN controlling the target RNC. The new SGSN becomes
the new anchor point for the service. The new SGSN then stores the UMTS cipher/integrity keys CK and IK and
sends them to the target RNC.
At the user side, in both cases, the ME applies the stored UMTS cipher/integrity keys CK and IK.
6.8.7.2
ETSI
49
c) In case of an intersystem change from an R98-SGSN to a UTRAN controlled by another SGSN, the initial
SGSN sends the stored GSM cipher key Kc to the (new) SGSN controlling the target RNC. The new SGSN
becomes the new anchor point for the service. To ensure use of UMTS keys for a possible UMTS subscriber
(superfluous in this case), a R99+ SGSN will perform a new AKA when a R99+ ME is coming from a R98SGSN.
At the user side, in all cases, the ME derives the UMTS cipher/integrity keys CK and IK from the stored GSM
cipher key Kc (using the conversion functions c4 and c5) and applies them. In case c) these keys will be overwritten with a new CK, IK pair due to the new AKA.
Void
8.1
Void
8.2
Void
8.3
Mobile IP security
The introduction of Mobile IP functionality for end users in 3G has no influence on the security architecture for 3G.
Mobile IP terminals may be equipped with security functionality independent of the 3G network access security in order
to allow security functions outside the 3G network.
3G networks, supporting Mobile IP services, should support its inherent security functionality.
On the other hand, 3G network access security architecture can not be influenced or reduced by the Mobile IP option.
The Mobile IP security functionality must thus be separate from the 3G network access security and it is developed in
an other forum, IETF.
ETSI
50
Annex A (informative):
Requirements analysis
[In this part of the document we will address the question "do the features meet the requirements?"]
ETSI
51
Annex B:
Void
ETSI
52
Annex C (informative):
Management of sequence numbers
This annex is devoted to the management of sequence numbers for the authentication and key agreement protocol.
C.1
C.1.1
ETSI
53
2. By setting the parameters in C.1.1.1 (1) to (5) in an appropriate way the general scheme specified in this
subsection also includes the cases where either SEQ2 is void and SEQ = SEQ1 or else, SEQ1 is void and SEQ =
SEQ2, as follows:
(a) If SEQ2 is void the generation of sequence numbers is not time-based. We then formally set SEQ2 GLC
0 (identical to zero) and D = 1. Conditions (4)(i) to (iii) do not apply as there is no clock. Then (5)(ii) always
holds, and SEQ is incremented by 1 at each request. For better readability, this case is separated out in C.1.1.2.
(b) If SEQ1 is void then we set D = 1. Assuming a start condition SEQ2HE < GLC and the absence of failures in
the AuC, the condition (5)(i) then always holds, and SEQ = GLC for each request, i.e. the generation of sequence
numbers is entirely time-based. In order to also accommodate potential failures in the AuC for entirely timebased sequence number , the variant described in the following Annex C.1.1.3 may be used.
C.1.2
C.2
This section assumes that sequence numbers are generated according to Annex C.1.
The USIM keeps track of an array of sequence number values it has accepted. Let SQNMS = SEQMS || INDMS denote the
highest sequence number in the array.
ETSI
C.2.1
54
The USIM will not accept arbitrary jumps in sequence numbers, but only increases by a value of at most .
Therefore (before applying the freshness conditions of Annex C.2.2) the received sequence number SQN shall only be
accepted by the USIM if SEQ-SEQMS . If SQN can not be accepted then the USIM shall generate a synchronisation
failure message using SQNMS.
Conditions on the choice of :
(1) shall be sufficiently large so that the MS will not receive any sequence number with SEQ - SEQMS > if the
HE/AuC functions correctly.
(2) In order to prevent that SEQMS ever reaches the maximum batch number value SEQmax during the lifetime of the
USIM the minimum number of steps SEQmax / required to reach SEQmax shall be sufficiently large.
C.2.2
The USIM shall maintain an array of a previously accepted sequence number components: SEQMS (0), SEQMS (1),
SEQMS (a-1). The initial sequence number value in each array element shall be zero.
To verify that the received sequence number SQN is fresh, the USIM shall compare the received SQN with the sequence
number in the array element indexed using the index value IND contained in SQN, i.e. with the array entry SEQMS (i)
where i = IND is the index value.
(a) If SEQ > SEQMS (i) the USIM shall consider the sequence number to be guaranteed fresh and subsequently shall
set SEQMS (i) to SEQ.
(b) If SEQ SEQMS (i) the USIM shall generate a synchronisation failure message using the highest previously
accepted sequence number anywhere in the array, i.e. SQNMS.
The USIM shall also be able to put a limit L on the difference between SEQMS and a received sequence number
component SEQ. If such a limit L is applied then, before verifying the above conditions (a) and (b), the sequence
number shall only be accepted by the USIM if SEQMS - SEQ < L. If SQN can not be accepted then the USIM shall
generate a synchronisation failure message using SQNMS.
C.2.3
Notes
1. Using the above array mechanism, it is not required that a previously visited VLR/SGSN deletes the unused
authentication vectors when a user de-registers from the serving network (super-charger concept). Retaining the
authentication vectors for use when the user returns later may be more efficient as regards signalling when a user
abroad switches a lot between two serving networks.
2. The array mechanism may also be used to avoid unjustified rejection of user authentication requests when
authentication vectors in two VLR/SGSNs from different mobility management domains (circuit and packet) are
used in an interleaving fashion.
3. When a VLR/SGSN uses fresh authentication vectors obtained during a previous visit of the user, the USIM can
reject them although they have not been used before (because the array size a and the age limit L are finite).
Rejection of a sequence number can therefore occur in normal operation, i.e., it is not necessarily caused by
(malicious) replay or a database failure.
4. The mechanism presented in this section may allow the USIM to exploit knowledge about which authentication
vectors were sent to the same VLR/SGSN. It may be assumed that authentication vectors sent to the same
VLR/SGSN are always used in the correct order. Consequently, only one sequence number among those sent to
the same VLR/SGSN has to be stored.
5. With the exception of SQNMS , the entries of the array need not be stored in full length if a limit L (age limit) on
the difference between SEQMS and a received sequence number component SEQ is applied.
6. Condition (2) of Annex C.2.1 on means that SQNMS can reach its maximum value only after a minimum of
SEQmax / successful authentications have taken place.
ETSI
55
7. There is a dependency of the choice of and the size n of global counter GLC in Annex C.1.1.1: shall be
chosen larger than 2n.
C.3
This section provides examples how values for the parameters defined in sections C.1 and C.2 may be chosen in a
coherent way. These examples may serve as references when specifying practical sequence number management
schemes. There is one example set of values for each of the three types of sequence number generation schemes:
-
C.3.1
ETSI
C.3.2
56
C.3.3
ETSI
57
User anonymity: the value of SQN does not allow to trace the user over longer periods. Therefore, there may be no
need to conceal SQN by an anonymity key as specified in section 6.3.
C.3.4
-
General rule: index values IND used in the array scheme, according to Annex C.1.2, shall be allocated
cyclically within its range 0, ... , a-1. This means that the index value IND used with the previously generated
authentication vector is stored in SQNHE , and the next authentication vector shall use index value IND +1 mod a.
It may be useful to allow exceptions to this general rule when additional information is available. This includes:
-
Authentication vectors distributed within the same batch shall have the same index value.
The Authentication Data Request MAP message contains information about the domain type (CS or PS) of the
requesting serving node from which the request originates. It is recommended to use this information in the
following way. Support for this use is, however, not required for an implementation to claim compliance to
Annex C.
Authentication vectors distributed to different service domains shall have different index values (i.e. separate
ranges of index values are reserved for PS and CS operation).
In future releases there may be additional information about the requesting node identity. If this information is available
it is recommended to use it in the following way:
-
C.4
If the new request comes from the same serving node as the previous request, then the index value used for the
new request shall be the same as was used for the previous request.
The specification of a sequence number management scheme affects only the USIM and the AuC which are both under
the control of one operator. Therefore, the specification of such a scheme is entirely at the discretion of an operator.
Nevertheless, certain operators may not want to define a scheme of their own. Instead, they may want to rely on vendors
implementing one of the schemes according to the profiles in C.3 or variants thereof. If these operators have multiple
vendors for USIMs and/or AuCs, and the operators wish to move subscribers from the AuC of one vendor to that
supplied by another one implementing a different scheme then this will work smoothly only when the following
guidelines are adhered to by all the sequence number management schemes implemented in the operators domain.
-
The array mechanism specified in clauses C.1.2 and C.2 is used in the USIM to verify SQNs. The length of the
IND used by the USIM to index the array shall be not less than the length of the IND used by the AuC when
allocating index values. However, it is recommended that the same IND length of 5 bits is used in USIMs and
AuCs. This is the same IND length as proposed for all profiles in clause C.3.
Relation to Annex F: if the AMF field is used to signal further parameters relevant to sequence number
management (age limit L) then the formats of the AMF and its interpretation by the USIM must be the same for
all implementations in the operators domain.
There are no requirements on the synchronicity of clocks in different AuCs for the time-based schemes. For the
entirely time-based scheme, the following is recommended when moving users from one AuC to another one:
The DIF value is updated in an appropriate manner when moving subscribers from an AuC to another AuC.
More specifically, assume a user is moved from AuC1 to AuC2. If AuC1 is of profile 3 and AuC2 is of any
profile then AuC1 sends GLC+DIF as SEQ_HE to AuC2. In the receiving end, if AuC2 is of profile 3 while
AuC1 is of any profile then AuC2 sets DIF value for this user as DIF = SEQ_HE - GLC.
ETSI
58
Annex D:
Void
ETSI
59
Annex E:
Void
ETSI
60
Annex F (informative):
Example uses of AMF
F.1
A mechanism to support the use of multiple authentication and key agreement algorithms is useful for disaster recovery
purposes. AMF may be used to indicate the algorithm and key used to generate a particular authentication vector.
The USIM keeps track of the authentication algorithm and key identifier and updates it according to the value received
in an accepted network authentication token.
F.2
This mechanism is used in conjunction with the mechanism for the verification of sequence number freshness in the
USIM described in C.2.2.
The USIM shall also be able to put a limit L on the difference between SEQMS (the highest SEQ accepted so far) and a
received sequence number SEQ. A mechanism to change this parameter L dynamically is useful since the optimum for
these parameters may change over time. AMF is used to indicate a new value of L to be used by the USIM.
F.3
According to section 6.4.3, the USIM contains a mechanism to limit the amount of data that is protected by an access
link key set. The AMF field may be used by the operator to set or adjust this limit in the USIM. For instance, there
could be two threshold values and the AMF field instructs the USIM to switch between them.
The USIM keeps track of the limit to the key set life time and updates it according to the value received in an accepted
network authentication token.
ETSI
61
Annex G (informative):
Change history
TSG SA
#
SP-03
SP-11
SP-11
SP-11
SP-11
Version
CR
Tdoc SA
2.0.0
3.7.0
3.7.0
3.7.0
3.7.0
135
136
137
140
SP-010131
SP-010131
SP-010131
SP-010131
SP-11
SP-11
SP-11
3.7.0
3.7.0
3.7.0
141
142
143
SP-010131
SP-010131
SP-010131
SP-11
SP-11
SP-12
SP-12
SP-12
SP-12
3.8.0
3.8.0
4.0.0
4.0.0
4.0.0
4.0.0
138
139
145
147
150
152
SP-010132
SP-010132
SP-010313
SP-010314
SP-010316
SP-010317
SP-12
SP-13
4.0.0
4.1.0
154
155r1
SP-010319
SP-010492
SP-14
SP-14
SP-14
SP-16
SP-16
4.2.0
4.2.0
4.2.0
4.3.0
4.3.0
157
159
161
166
170r1
SP-010608
SP-010609
SP-010610
SP-020340
SP-020342
SP-16
SP-16
SP-18
SP-18
4.3.0
4.4.0
5.0.0
5.0.0
172
174r1
175
178
SP-020343
SP-020385
SP-020700
SP-020790
Change history
New
Subject/Comment
Version
3.0.0
Approved at SA#3 and placed under TSG SA Change Control
3.8.0
RES has to be a multiple of 8 bits
3.8.0
Add bit ordering convention
3.8.0
Timing of security mode procedure
3.8.0
Correction to the handling of re-transmitted authentication request
messages on the ME
3.8.0
Optional Support for USIM-ME interface for GSM-Only ME
3.8.0
Definition corrections
3.8.0
GSM ciphering capability Handling in Security Mode set up
procedure
4.0.0
Add requesting node type to authentication data request
4.0.0
Provide additional information to HE to detect fraud conditions.
4.1.0
Correction to periodic local authentication
4.1.0
Correction to COUNT-C description
4.1.0
Calculation and Wrap-around of START value
4.1.0
Correction to integrity protection when the user is attached to a
UTRAN with R99+ ME with a SIM inserted
4.1.0
THRESHOLD Check at RRC connection establishment
4.2.0
Removing the list of access type codes from authentication failure
report
4.3.0
Annex F.2 (changing list parameters) modification
4.3.0
Sequence Number Management Corrections
4.3.0
SQNMS retrieval in AuC during resynchronisation
4.4.0
Optional use of Access Link Data Confidentiality
4.4.0
Encryption/Integrity algorithms ordered by preference in Security
Mode command
4.4.0
Correction of (U)SIM toolkit security reference
5.0.0
Clarification of sequence number management (Rel-5 created)
5.1.0
USIM support in GERAN only terminals
5.1.0
Correction to the START formula
ETSI
62
History
Document history
V5.0.0
June 2002
Publication
V5.1.0
December 2002
Publication
ETSI