4 Access link security
33.1033G security3GPPIntegration guidelinesTS
4.1 Functional network architecture
Figure 1 shows the functional security architecture of UMTS.
Figure 1: UMTS functional security architecture
The vertical bars represent the network elements:
In the user domain:
USIM (User Service Identity Module): an access module issued by a HE to a user;
UE (User Equipment);
In the serving network (SN) domain:
RNC (Radio Network Controller);
VLR (Visited Location Register), also the SGSN;
In the home environment (HE) domain:
HLR/AuC;
UIDN.
The horizontal lines represent the security mechanisms:
EUIC: mechanism for enhanced user identity confidentiality (optional, between user and HE);
UIC: conventional mechanism for user identity confidentiality (between user and serving network);
AKA: the mechanism for authentication and key agreement, including the functionality to trigger a re-authentication by the user, i.e., to control the access key pair lifetime;
DC: the mechanism for data confidentiality of user and signalling data;
DI: the mechanism for data integrity of signalling data;
DEC: the mechanism for network-wide data confidentiality.
In the remaining section of this specification we describe what data elements and functions need to be implemented in each of the above network elements for each of the above mechanisms and functions.
4.2 User services identity module
4.2.1 Void
4.2.2 Authentication and key agreement (AKAUSIM)
The USIM shall support the UMTS mechanism for authentication and key agreement described in 6.3 of 3G TS 33.102.
The following data elements need to be stored on the USIM:
a) K: a permanent secret key;
b) SQNMS: a counter that is equal to the highest sequence number SQN in an AUTN parameter accepted by the user;
c) RANDMS: the random challenge which was received together with the last AUTN parameter accepted by the user. It is used to calculate the re-synchronisation message together with the highest accepted sequence number (SQNMS);
d) KSI: key set identifier;
e) THRESHOLD: a threshold defined by the HE to trigger re-authentication and to control the cipher key lifetime;
f) CK The access link cipher key established as part of authentication;
g) IK The access link integrity key established as part of authentication;
h) HFNMS: Stored Hyper Frame Number provides the Initialisation value for most significant part of COUNT-C and COUNT-I. The least significant part is obtained from the RRC sequence number;
i) AMF: A 16-bit field used Authentication Management. The use and format are unspecified in the architecture but examples are given in an informative annex;
j) The GSM authentication parameter and GSM cipher key derived from the UMTS to GSM conversion functions.
Table 3 provides an overview of the data elements stored on the USIM to support authentication and key agreement.
Table 3: USIM – Authentication and key agreement – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
K | Permanent secret key | 1 (note 1) | Permanent | 128 bits | Mandatory |
SQNMS | Highest previously accepted sequence number counter | 1 | Updated when AKA protocol is executed | 48 bits | Mandatory |
SQNMS[ ] array | array of last accepted sequence number | 1 | Updated when AKA protocol is executed | at least 32 entries | Optional |
RANDMS | Random challenge received by the user. | 1 | Updated when AKA protocol is executed | 128 bits | Mandatory |
KSI | Key set identifier | 2 (note 2) | Updated when AKA protocol is executed | 3 bits | Mandatory |
THRESHOLD | Threshold value for cipher key | 1 | Permanent | 24 bits | Mandatory |
CK | Cipher key | 2 (note 2) | Updated when AKA protocol is executed | 128 bits | Mandatory |
IK | Integrity key | 2 (note 2) | Updated when AKA protocol is executed | 128 bits | Mandatory |
HFNMS: | Initialisation value for most significant part for COUNT-C and for COUNT-I | 1 | Updated when connection is released | 25 bits | Mandatory |
AMF | Authentication Management Field (indicates the algorithm and key in use) | 1 | Updated when AKA protocol is executed | 16 bits | Mandatory |
Kc | GSM cipher Key | 2 (note 2) | Updated when GSM AKA or UMTS AKA protocol is executed | As for GSM | Optional |
NOTE 1: HE policy may dictate more than one, the active key signalled using the AMF function.
NOTE 2: one for circuit-switched domain, one for packet-switched domain.
The following cryptographic functions need to be implemented on the USIM:
– f1: a message authentication function for network authentication;
– f1*: a message authentication function for support to re-synchronisation;
– f2: a message authentication function for user authentication;
– f3: a key generating function to derive the cipher key;
– f4: a key generating function to derive the integrity key;
– f5: a key generating function to derive the anonymity key for normal operation;
– f5*: a key generating function to derive the anonymity key for re-synchronisation;
– c2: Conversion function for interoperation with GSM from XRES (UMTS) to SRES (GSM);
– c3: Conversion function for interoperation with GSM from Ck and IK (UMTS) to Kc (GSM).
Figure 2 provides an overview of the data integrity, data origin authentication and verification of the freshness by the USIM of the RAND and AUTN parameters received from the VLR/SGSN, and the derivation of the response RES, the cipher key CK and the integrity key IK. Note that the anonymity Key (AK) is optional.
Figure 2: User authentication function in the USIM
Figure 3 provides an overview of the generation in the USIM of a token for re-synchronisation AUTS.
a) The USIM computes MAC-S = f1*K(SQNMS || RAND || AMF*), whereby AMF* is a default value for AMF used in re-synchronisation.
b) If SQNMS is to be concealed with an anonymity key AK, the USIM computes AK = f5K(RAND), and the concealed counter value is then computed as SQNMS AK.
c) The re-synchronisation token is constructed as AUTS = SQNMS [ AK] || MAC-S.
Figure 3: Generation of a token for re-synchronisation AUTS (note 1)
NOTE 1: The lengths of AUTS and MAC-S are specified in table 20.
Table 4 provides a summary of the cryptographic functions implemented on the USIM to support authentication and key agreement.
Table 4: USIM – Authentication and key agreement – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f1 | Network authentication function | 1 | Permanent | Proprietary | Mandatory |
f1* | Message authentication function for synchronisation | 1 | Permanent | Proprietary | Mandatory |
f2 | User authentication function | 1 | Permanent | Proprietary | Mandatory |
f3 | Cipher key generating function | 1 | Permanent | Proprietary | Mandatory |
f4 | Integrity key generating function | 1 | Permanent | Proprietary | Mandatory |
f5 | Anonymity key generating function (for normal operation) | 1 | Permanent | Proprietary | Optional |
f5* | Anonymity key generating function (for re-synchronisation) | 1 | Permanent | Proprietary | Optional |
c2 and c3 | Conversion functions for interoperation with GSM | 1 of each | Permanent | Standard | Optional |
4.3 User equipment
4.3.1 User identity confidentiality (UICUE)
The UE shall support the UMTS conventional mechanism for user identity confidentiality described in 6.1 of 3G TS 33.102.
The UE shall store the following data elements:
– TMUI-CS: a temporary identity allocated by the CS core network;
– LAI: a location area identifier;
– the TMUI-PS: a temporary identity allocated by the PS core network;
– the RAI: a routing area identifier
Table 5: UE – User Identity Confidentiality – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
TMUI-CS | Temporary user identity | 1 per user | Updated when TMUI allocation protocol is executed by CS core network | As per GSM TMSI | Mandatory |
LAI | Location area identity | 1 per user | Updated when TMUI allocation protocol is executed by CS core network | Mandatory | |
TMUI-PS | Temporary user identity | 1 per user | Updated when TMUI allocation protocol is executed by PS core network | Mandatory | |
RAI | Routing area identity | 1 per user | Updated when TMUI allocation protocol is executed by PS core network | Mandatory |
4.3.2 Data confidentiality (DCUE)
The UE shall support the UMTS mechanism for confidentiality of user and signalling data described in 6.6 of 3G TS 33.102.
The UE shall store the following data elements:
a) UEA-MS: the ciphering capabilities of the UE;
b) CK: the cipher key;
c) UEA: the selected ciphering function;
In addition, when in dedicated mode:
d) COUNT-CUP: a time varying parameter for synchronisation of ciphering for the uplink;
e) COUNT-CDOWN: a time varying parameter for synchronisation of ciphering for the downlink;
f) BEARER: a radio bearer identifier;
g) DIRECTION: An indication of the direction of transmission uplink or downlink to ensure a different cipher is applied.
Table 6 provides an overview of the data elements stored on the UE to support the mechanism for data confidentiality:
Table 6: UE – Data Confidentiality – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
UEA-MS | Ciphering capabilities of the UE | 1 per UE | Permanent | 16 bits | Mandatory |
CK | Cipher key | 1 per mode | Updated at execution of AKA protocol | 128 bits | Mandatory |
UEA | Selected ciphering capability | 1 per UE | Updated at connection establishment | 4 bits | Mandatory |
COUNT-CUP | Time varying parameter for synchronisation of ciphering | 1 per radio bearer | Lifetime of a radio bearer | 32 bits | Mandatory |
COUNT-CDOWN | Time varying parameter for synchronisation of ciphering | 1 per radio bearer | Lifetime of a radio bearer | 32 bits | Mandatory |
BEARER | Radio bearer identifier | 1 per radio bearer | Lifetime of a radio bearer | 5 bits | Mandatory |
DIRECTION | An indication of the direction of transmission uplink or downlink | 1 per radio bearer | Lifetime of a radio bearer | 1 bit | Mandatory |
The following cryptographic functions shall be implemented on the UE:
– f8: access link encryption function (note 1).
– c4: Conversion function for interoperation with GSM from Kc (GSM) to CK (UMTS).
NOTE 1: The security architecture TS 33.102 refers to UEA , f8 is a specific implementation of UEA as defined in Cryptographic algorithm requirements TS 33.105.
Table 7 provides an overview of the cryptographic functions implemented on the UE to support the mechanism for data confidentiality.
Table 7: UE – Data Confidentiality – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f8 | Access link encryption function | 1-16 | Permanent | Standardised | One at least is mandatory |
c4 | Conversion function for interoperation with GSM | 1 | Permanent | Standardised | Optional |
4.3.3 Data integrity (DIUE)
The UE shall support the UMTS mechanism for integrity of signalling data described in 6.4 of 3G TS 33.102.
The UE shall store the following data elements:
a) UIA-MS: the integrity capabilities of the UE.
In addition, when in dedicated mode:
b) UIA: the selected UMTS integrity algorithm;
c) IK: an integrity key;
d) COUNT-IUP: a time varying parameter for synchronisation of data integrity in the uplink direction;
e) COUNT-IDOWN: a time varying parameter for synchronisation of data integrity in the downlink direction;
f) DIRECTION An indication of the direction of transmission uplink or downlink to ensure a different cipher is applied;
g) FRESH: a network challenge;
Table 8 provides an overview of the data elements stored on the UE to support the mechanism for data confidentiality:
Table 8: UE – Data Integrity – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
UIA-MS | Ciphering capabilities of the UE | 1 per UE | Permanent | 16 bits | Mandatory |
UIA | Selected ciphering capability | 1 per UE | Updated at connection establishment | 4 bits | Mandatory |
IK | Integrity key | 1 per mode | Updated by the execution of the AKA protocol | 128 bits | Mandatory |
DIRECTION | An indication of the direction of transmission uplink or downlink | 1 per radio bearer | Lifetime of a radio bearer | 1 bit | Mandatory |
COUNT-IUP | Synchronisation value | 1 | Lifetime of a connection | 32 bits | Mandatory |
COUNT-IDOWN | Synchronisation value | 1 | Lifetime of a connection | 32 bits | Mandatory |
FRESH | Network challenge | 1 | Lifetime of a connection | 32 bits | Mandatory |
MAC-I XMAC-I | Message authentication code | 1 | Updated by the execution of the AKA protocol | 32 bits | Mandatory |
The following cryptographic functions shall be implemented on the UE:
– f9: access link integrity function (note 1).
– c5: Conversion function for interoperation with GSM Kc (GSM) > IK (UMTS)
NOTE 1: The security architecture TS 33.102 refers to UIA, f9 is a specific implementation of UIA as defined in Cryptographic algorithm requirements TS 33.105.
Table 9 provides an overview of the cryptographic functions implemented in the UE:
Table 9: UE – Data Integrity – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f9 | Access link data integrity function | 1-16 | Permanent | Standardised | One at least is mandatory |
c5 | Conversion function for interoperation with GSM | 1 | Permanent | Standardised | Optional |
4.3.4 Void
4.4 Radio network controller
4.4.1 Data confidentiality (DCrnc)
The RNC shall support the UMTS mechanism for data confidentiality of user and signalling data described in 6.6 of 3G TS 33.102.
The RNC shall store the following data elements:
a) UEA-RNC: the ciphering capabilities of the RNC;
In addition, when in dedicated mode:
b) UEA: the selected ciphering function;
c) CK: the cipher key;
d) COUNT-CUP: a time varying parameter for synchronisation of ciphering for the uplink;
e) COUNT-CDOWN: a time varying parameter for synchronisation of ciphering for the downlink;
f) DIRECTION: An indication of the direction of transmission uplink or downlink to ensure a different cipher is applied
g) BEARER: a radio bearer identifier.
Table 10 provides an overview of the data elements stored in the RNC to support the mechanism for data confidentiality:
Table 10: RNC – Data Confidentiality – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
UEA-RNC | Ciphering capabilities of the RNC | 1 | Permanent | 16 bits | Mandatory |
UEA | Selected ciphering capability | 1 per user and per mode | Updated at connection establishment | 4 bits | Mandatory |
CK | Cipher key | 1 per user and per mode | Updated at connection establishment | 128 bits | Mandatory |
COUNT-CUP | Time varying parameter for synchronisation of ciphering | 1 per radio bearer | Lifetime of a radio bearer | 32 bits | Mandatory |
COUNT-CDOWN | Time varying parameter for synchronisation of ciphering | 1 per radio bearer | Lifetime of a radio bearer | 32 bits | Mandatory |
BEARER | Radio bearer identifier | 1 per radio bearer | Lifetime of a radio bearer | 5 bits | Mandatory |
DIRECTION | An indication of the direction of transmission uplink or downlink | 1 per radio bearer | Lifetime of a radio bearer | 1 bit | Mandatory |
The following cryptographic functions shall be implemented in the RNC:
– f8: access link encryption function.
Table 11 provides an overview of the cryptographic functions implemented in the RNC to support the mechanism for data confidentiality:
Table11: RNC – Data confidentiality – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f8 | Access link encryption function | 1-16 | Permanent | Standardised | One at least is mandatory |
4.4.2 Data integrity (DIrnc)
The RNC shall support the UMTS mechanism for data integrity of signalling data described in 6.4 of 3G TS 33.102.
The RNC shall store the following data elements:
a) UIA-RNC: the integrity capabilities of the RNC;
In addition, when in dedicated mode:
b) UIA: the selected UMTS integrity algorithm;
c) IK: an integrity key;
d) COUNT-IUP: a time varying parameter for synchronisation of data integrity in the uplink direction;
e) COUNT-IDOWN: a time varying parameter for synchronisation of data integrity in the downlink direction;
f) DIRECTION An indication of the direction of transmission uplink or downlink to ensure a different cipher is applied;
g) FRESH: an MS challenge.
Table 12 provides an overview of the data elements stored on the RNC to support the mechanism for data confidentiality:
Table12: RNC – Data Integrity – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
UIA-RNC | Data integrity capabilities of the RNC | 1 | Permanent | 16 bits | Mandatory |
UIA | Selected data integrity capability | 1 per user | Lifetime of a connection | 4 bits | Mandatory |
IK | Integrity key | 1 per user | Lifetime of a connection | 128 bits | Mandatory |
DIRECTION | An indication of the direction of transmission uplink or downlink | 1 per radio bearer | Lifetime of a radio bearer | 1 bit | Mandatory |
COUNT-IUP | Synchronisation value | 1 per radio bearer | Lifetime of a connection | 32 bits | Mandatory |
COUNT-IDOWN | Synchronisation value | 1 per radio bearer | Lifetime of a connection | 32 bits | Mandatory |
FRESH | MS challenge | 1 per user | Lifetime of a connection | 32 bits | Mandatory |
MAC-I XMAC-I | Message authentication code | 1 per user | Updated by the execution of the f9 function | 32 bits | Mandatory |
The following cryptographic functions shall be implemented on the RNC:
– f9: access link integrity function.
Table 13 provides an overview of the cryptographic functions implemented in the RNC:
Table 13: RNC – Data Integrity – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f9 | Access link data integrity function | 1-16 | Permanent | Standardised | One at least is mandatory |
4.5 SN (or MSC/VLR or SGSN)
4.5.1 User identity confidentiality (UICSN)
The VLR (equivalently the SGSN) shall support the UMTS conventional mechanism for user identity confidentiality described in 6.1 of 3G TS 33.102.
The VLR shall store the following data elements:
– TMUI-CS: a temporary identity allocated by the CS core network;
– LAI: a location area identifier;
Table 14: VLR – User Identity Confidentiality – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
TMUI-CS | Temporary user identity | 2 per user | Updated when TMUI allocation protocol is executed by CS core network | Mandatory | |
LAI | Location area identity | 2 per user | Updated when TMUI allocation protocol is executed by CS core network | Mandatory |
Equivalently, the SGSN shall store the following data elements:
– TMUI-PS: a temporary identity allocated by the PS core network;
– RAI: a routing area identifier.
Table 15: SGSN – User Identity Confidentiality – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
TMUI-PS | Temporary user identity | 1 per user | Updated when TMUI allocation protocol is executed by PS core network | Mandatory | |
RAI | Routing area identity | 1 per user | Updated when TMUI allocation protocol is executed by PS core network | Mandatory |
4.5.2 Void
4.5.3 Authentication and key agreement ( AKASN)
The VLR (equivalently the SGSN) shall support the UMTS mechanism for authentication and key agreement described in 6.3 of 3G TS 33.102.
The following data elements need to be stored in the VLR (and SGSN):
a) AV: Authentication vectors;
Table 16 provides an overview of the composition of an authentication vector
Table 16: Composition of an authentication vector
Symbol | Description | Multiplicity | Length |
RAND | Network challenge | 1 | 128 |
XRES | Expected response | 1 | 32-128 |
CK | Cipher key | 1 | 128 |
IK | Integrity key | 1 | 128 |
AUTN | Authentication token | 1 that consists of: | 128 |
SQN or SQN AK | Sequence number or Concealed sequence number | 1 per AUTN | 48 |
AMF | Authentication Management Field | 1 per AUTN | 16 |
MAC-A | Message authentication code for network authentication | 1 per AUTN | 64 |
b) KSI: Key set identifier;
c) CK: Cipher key;
d) IK: Integrity key;
e) GSM AV: Authentication vectors for GSM.
Table 17 provides an overview of the data elements stored in the VLR/SGSN to support authentication and key agreement.
Table 17: VLR/SGSN – Authentication and key agreement – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
UMTS AV | UMTS Authentication vectors | several per user, SN dependent | Depends on many things | 528-640 | Mandatory |
KSI | Key set identifier | 1 per user | Updated when AKA protocol is executed | 3 bits | Mandatory |
CK | Cipher key | 1 per user | Updated when AKA protocol is executed | 128 bits | Mandatory |
IK | Integrity key | 1 per user | Updated when AKA protocol is executed | 128 bits | Mandatory |
GSM AV | GSM Authentication vectors | As for GSM | As for GSM | As for GSM | Optional |
The following cryptographic functions shall be implemented in the VLR/SGSN:
– c4: Conversion function for interoperation with GSM from Kc (GSM) to CK (UMTS);
– c5: Conversion function for interoperation with GSM from Kc (GSM) to IK (UMTS).
Table 18 provides an overview of the cryptographic functions implemented on the UE to support the mechanism for data confidentiality.
Table 18: VLR/SGSN Authentication and Key Agreement – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
c4 | Conversion function for interoperation with GSM | 1 | Permanent | Standardised | Optional |
c5 | Conversion function for interoperation with GSM | 1 | Permanent | Standardised | Optional |
4.6 Home location register / Authentication centre
4.6.1 Authentication and key agreement (AKAhe)
The HLR/AuC shall support the UMTS mechanism for authentication and key agreement described in 6.3 of 3G TS 33.102.
The following data elements need to be stored in the HLR/AuC:
a) K: a permanent secret key;
b) SQNHE: a counter used to generate SQN from;
c) AV: authentication vectors computed in advance;
Table 19 provides an overview of the data elements stored on the HLR/AuC to support authentication and key agreement.
Table 19: HLR/AuC – Authentication and key agreement – Data elements
Symbol | Description | Multiplicity | Lifetime | Length | Mandatory / Optional |
K | Permanent secret key | 1 | Permanent | 128 bits | Mandatory |
SQNHE | Sequence number counter | 1 | Updated when AVs are generated | 48 bits | Mandatory |
UMTS AV | UMTS Authentication vectors | HE option | Updated when AVs are generated | 544-640 bits | Optional |
GSM AV | GSM Authentication vectors | HE option that consists of: | Updated when AVs are generated | As GSM | Optional |
RAND | GSM Random challenge | 128 bits | Optional | ||
SRES | GSM Expected response | 32 bits | Optional | ||
Kc | GSM cipher key | 64 bits | Optional |
Table 20 shows how the construction of authentication token for synchronisation failure messages used to support authentication and key agreement.
Table 20: Composition of an authentication token for synchronisation failure messages
Symbol | Description | Multiplicity | Length |
AUTS | Synchronisation Failure authentication token | that consists of: | 112 |
SQN | Sequence number | 1 per AUTS | 48 |
MAC-S | Message authentication code for Synchronisation Failure messages | 1 per AUTS | 64 |
Figure 4 provides an overview of how authentication vectors are generated in the HLR/AuC.
Figure 4: Generation of an authentication vector
The following cryptographic functions need to be implemented in the HLR/AuC:
– f1: a message authentication function for network authentication;
– f1*: a message authentication function for support to re-synchronisation;
– f2: a message authentication function for user authentication;
– f3: a key generating function to derive the cipher key;
– f4: a key generating function to derive the integrity key;
– f5: a key generating function to derive the anonymity key for normal operation;
– f5*: a key generating function to derive the anonymity key for re-synchronisation;
– c1: Conversion function for interoperation with GSM from RAND (UMTS) > RAND (GSM);
– c2: Conversion function for interoperation with GSM from XRES (UMTS) to SRES (GSM);
– c3: Conversion function for interoperation with GSM from CK and IK (UMTS) to Kc (GSM).
Table 21 provides a summary of the cryptographic functions implemented on the USIM to support authentication and key agreement.
Table 21: HLR/AuC – Authentication and key agreement – Cryptographic functions
Symbol | Description | Multiplicity | Lifetime | Standardised / Proprietary | Mandatory / Optional |
f1 | Network authentication function | 1 | Permanent | Proprietary | Mandatory |
f1* | Message authentication function for synchronisation | 1 | Permanent | Proprietary | Mandatory |
f2 | User authentication function | 1 | Permanent | Proprietary | Mandatory |
f3 | Cipher key generating function | 1 | Permanent | Proprietary | Mandatory |
f4 | Integrity key generating function | 1 | Permanent | Proprietary | Mandatory |
f5 | Anonymity key generating function (for normal operation) | 1 | Permanent | Proprietary | Optional |
f5* | Anonymity key generating function (for re-synchronisation) | 1 | Permanent | Proprietary | Optional |
A3/A8 | GSM user authentication functions | 1 | Permanent | Proprietary | Optional |
c1, c2 and c3 | Functions for converting UMTS AV’s to GSM AV’s | 1 for each | Permanent | Standard | Optional |