7 USIM Commands
31.1023GPPCharacteristics of the Universal Subscriber Identity Module (USIM) applicationRelease 17TS
7.1 AUTHENTICATE
7.1.1 Command description
The function can be used in several different contexts:
– a 5G security context, when 5G authentication vectors (RAND, XRES, CK, IK, AUTN) are available (i.e. the UE is located in a 5GS domain, as specified in TS 33.501 [105] or
– a EPS security context, when EPS authentication vectors (RAND, XRES, CK, IK, AUTN) are available (i.e. the UE is located in an EPS domain, as specified in TS 33.401 [52] or
– a 3G security context, when 3G authentication vectors (RAND, XRES, CK, IK, AUTN) are available (i.e. the UE is located in the UTRAN, or in a GSM radio access network which is connected to a 3G or 3G capable VLR/SGSN), or
– a GSM security context, when GSM authentication data are available only (i.e. the UE is located in the GSM radio access network which is connected to a non-3G capable VLR/SGSN)
– a VGCS/VBS security context, when VGCS/VBS authentication data is available
– a GBA_U security context, when a GBA bootstrapping procedure is requested
– a MBMS security context, when a MBMS security procedure is requested
– a Local Key Establishment security context, when a Local Key Establishment procedure is requested.
The function is used in GSM or 3G/EPS/5G security context during the procedure for authenticating the USIM to its HE and vice versa. In addition, a cipher key and an integrity key are calculated. For the execution of the command the USIM uses the subscriber authentication key K, which is stored in the USIM.
The function is used in VGCS/VBS security context during the procedure for retrieving the VGCS/VBS Short Term Key (VSTK) used by the terminal in establishing VGCS/VBS calls.
The function is used in GBA security context in two different modes:
a) Bootstrapping Mode: during the procedure for mutual authenticating of the USIM and the Bootstrapping Server Function (BSF) and for deriving bootstrapped key material from the AKA run.
b) NAF Derivation Mode: during the procedure for deriving Network Application Function (NAF) specific keys from previous bootstrapped key material.
The function is used in MBMS security context in two different modes:
a) MSK Update Mode: during the procedure for updating an MBMS Service Key (MSK).
b) MTK Generation Mode: during the procedure for retrieving the MBMS Traffic Key (MTK) used by the terminal to decrypt MBMS data.
The function is related to a particular USIM and shall not be executable unless the USIM application has been selected and activated, and the current directory is the USIM ADF or any subdirectory under this ADF and a successful PIN verification procedure has been performed (see clause 5).
7.1.1.1 3G/EPS/5G security context
The USIM first computes the anonymity key AK = f5K (RAND) and retrieves the sequence number SQN = (SQN AK) AK.
Then the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with the MAC which is included in AUTN. If they are different, the USIM abandons the function.
Next the USIM verifies that the received sequence number SQN is previously unused. If it is unused and its value is lower than SQNMS, it shall still be accepted if it is among the last 32 sequence numbers generated. A possible verification method is described in TS 33.102 [13].
NOTE: This implies that the USIM has to keep a list of the last used sequence numbers and the length of the list is at least 32 entries.
If the USIM detects the sequence numbers to be invalid, this is considered as a synchronisation failure and the USIM abandons the function. In this case the command response is AUTS, where:
AUTS = Conc(SQNMS) || MACS;
Conc(SQNMS) = SQNMS ⊕ f5*K(RAND) is the concealed value of the counter SQNMS in the USIM; and.
MACS = f1*K(SQNMS || RAND || AMF) where:
RAND is the random value received in the current user authentication request;
the AMF assumes a dummy value of all zeroes so that it does not need to be transmitted in clear in the resynchronisation message.
If the sequence number is considered in the correct range, the USIM computes RES = f2K (RAND), the cipher key CK = f3K (RAND) and the integrity key IK = f4K (RAND) and includes these in the command response. Note that if this is more efficient, RES, CK and IK could also be computed earlier at any time after receiving RAND.
The use of AMF is HE specific and while processing the command, the content of the AMF has to be interpreted in the appropriate manner. The AMF may e.g. be used for support of multiple algorithms or keys or for changing the size of lists, see TS 33.102 [13].
If Service n°27 is "available", the USIM calculates the GSM response parameter KC, using the conversion function defined in TS 33.102 [13].
Input:
‑ RAND, AUTN (AUTN:= SQN AK || AMF || MAC).
Output:
– RES, CK, IK if Service n°27 is "not available".
Or
– RES, CK, IK, KC if Service n°27 is "available".
Or
– AUTS.
7.1.1.2 GSM security context
USIM operation in an GSM security context is supported if Service n°38 is "available".
The USIM computes RES = f2K (RAND), the cipher key CK = f3K (RAND) and the integrity key IK = f4K (RAND). Next the USIM calculates the GSM response parameters SRES and KC, using the conversion functions defined in TS 33.102 [13].
Input:
‑ RAND.
Output:
‑ SRES; KC.
7.1.1.3 VGCS/VBS security context
USIM operation in a VGCS/VBS security context is supported if both Service n°57 and Service n°64 are "available" (VGCS security context) or if both Service n°58 and Service n°65 are "available" (VBS security context).
The USIM computes the Short Term Key (VSTK) associated with a particular VGCS/VBS Group Identifier (Group_Id). For this computation, the USIM uses the Voice Group (for VGCS) or Broadcast Group (for VBS) Key (V_Ki) identified by their respective Group_Id and Master Group Key Identifier (VK_Id). The USIM retrieves the Group_Id and the service flag (VGCS or VBS) from the received Voice Service Identifier (Vservice_Id).
NOTE: The Group_Id has a variable length according to TS 43.068 [46].
The USIM shall first search if the Group_Id corresponds to a stored VGCS Group Identifier in EFVGCS or a stored VBS Group Identifier in EFVBS.
Then, the USIM shall retrieve the V_Ki corresponding to the given Group_Id and VK_Id.
Then the USIM uses V_Ki and VSTK_RAND as input parameters for the A8_V key derivation function (as defined in TS 43.020 [44]) in order to compute and returns VSTK.
Input:
‑ Vservice_Id, VK_Id, VSTK_RAND
Output:
‑ VSTK.
7.1.1.4 GBA security context (Bootstrapping Mode)
USIM operations in GBA security context are supported if service n°68 is "available".
The USIM receives the RAND and AUTN*. The USIM first computes the anonymity key AK = f5K (RAND) and retrieves the sequence number SQN = (SQN AK) AK.
The USIM calculates IK = f4K (RAND) and MAC (by performing the MAC modification function described in TS 33.220 [42]). Then the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with the MAC previously produced. If they are different, the USIM abandons the function.
Then the USIM performs the checking of AUTN* as in UMTS security context. If the USIM detects the sequence numbers to be invalid, this is considered as a synchronisation failure and the USIM abandons the function. In this case the command response is AUTS, which is computed as in UMTS security context.
If the sequence number is considered in the correct range, the USIM computes RES = f2K (RAND) and the cipher key CK = f3K (RAND).
The USIM then derives and stores GBA_U bootstrapped key material from CK, IK values. The USIM shall also stores RAND in the RAND field of EFGBABP
The USIM stores GBA_U bootstrapped key material from only one bootstrapping procedure. The previous bootstrapped key material, if present, shall be replaced by the new one. This key material is linked with the data contained in EFGBABP : RAND, which is updated by the USIM and B-TID, which shall be further updated by the ME.
NOTE: According to TS 33.220 [42], NAF-specific keys that may be stored on the USIM are not affected by this bootstrapping operation.
RES is included in the command response after flipping the least significant bit.
Input:
‑ RAND, AUTN*
Output:
– RES
or
– AUTS
7.1.1.5 GBA security context (NAF Derivation Mode)
USIM operations in GBA security context are supported if service n°68 is "available".
The USIM receives the NAF_ID and IMPI.
The USIM performs Ks_ext_NAF and Ks_int_NAF derivation as defined in TS 33.220 [42] using the key material from the previous GBA_U bootstrapping procedure.
If no key material is available this is considered as a GBA Bootstrapping failure and the USIM abandons the function. The status word ‘6985’ (Conditions of use not satisfied) is returned.
Otherwise, the USIM stores Ks_int_NAF and associated B-TID together with NAF_ID. The Ks_int_NAF keys related to other NAF_Ids, which are already stored in the USIM, shall not be affected. The USIM updates EFGBANL as follows:
– If a record with the given NAF_ID already exists, the USIM updates the B-TID field of this record with the B-TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF derivation procedure.
– If a record with the given NAF_ID does not exist, the USIM uses an empty record to store the NAF_ID and the B-TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF Derivation procedure.
NOTE: According to TS 33.220 [42], the USIM can contain several Ks_int_NAF together with the associated B-TID and NAF_ID, but there is at most one pair of Ks_int_NAF and associated B-TID stored per NAF_ID.
– In case no empty record is available the USIM shall overwrite an existing record to store the NAF_ID and the B-TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF Derivation procedure. To determine the record to overwrite, the USIM shall construct a list of record numbers by storing in the list first position the record number of the last used (i.e. involved in an Authentication command) or derived Ks_int_NAF and by shifting down the remaining list elements. The last record number in this list corresponds to the record to overwrite when the USIM runs out of free records. If an existing record corresponding to a Ks_int_NAF key in use is overwritten, the application Ks_int_NAF shall not be affected (e.g. in case a Ks_int_NAF was put into use as an MBMS MUK key, the MUK key shall continue to be available for the MBMS application).
Then, the USIM returns Ks_ext_NAF.
Input:
‑ NAF_ID, IMPI
Output:
– Ks_ext_NAF
7.1.1.6 MBMS security context (MSK Update Mode)
USIM operations in MBMS security context are supported if service n°69 is "available".
The USIM receives the MIKEY packet containing an MSK update message. First, the USIM uses the MUK ID to identify the Ks_int_NAF corresponding with a previous bootstrapping procedure.
The USIM shall check if a new NAF derivation procedure involving the received Idi in the MIKEY message has been performed or if it is the first time that this Idi is used. If this check cannot be performed because the corresponding Ks_int_NAF key was overwritten, the USIM abandons the function and returns the status word ‘6985’ (Conditions of use not satisfied). In case of a new NAF derivation procedure or a new Idi, the USIM shall store the last bootstrapped Ks_int_NAF as the last generated MUK and update EFMUK as follows:
– If a record with the received Idi (included in the MUK ID: see TS 33.246 [43]) value is already present, then the MUK ID is stored in the corresponding field of this record, and the associated Time Stamp Counter (TS) field is reset. Additionally, the USIM internally stores the last successfully used MUK (i.e. MUK that was used during the last successful MSK update procedure), along with its MUK ID for further use (e.g. to detect Key freshness failure).
– If a record with the received Idi does not exist, the USIM uses an empty record to include the MUK ID, and reset the associated TS field.
– In case there is no empty record available in EFMUK the USIM abandons the function and the status word ‘9867’ (Authentication error, no available memory space in EFMUK) is returned.
NOTE: In case no empty record in EFMUK is available the ME should run a MUK Deletion Mode procedure to free entries in EFMUK before running an MSK Update Mode procedure that involves a new MUK key.
NOTE: In case the ME receives the status word ‘6985’, the ME should derive the required Ks_int_NAF key. In case the corresponding bootstrapping key Ks is still available, the ME should invoke the Authenticate command in "GBA – NAF derivation Mode" before invoking again the AUTHENTICATE command in "MBMS – MSK Update Mode". In case the corresponding bootstrapping key has been updated, the ME should put the new B-TID into use.
If the received MUK ID does not correspond to the last generated MUK (i.e. last bootstrapped MUK) then the USIM proceeds as follows:
– If the received MUK ID corresponds to the last successfully used MUK then the USIM uses this MUK to verify the integrity of the message. If the verification is unsuccessful, the USIM abandons the function and returns the status word ‘9862’ (Authentication error, incorrect MAC). If the verification is successful, the USIM abandons the function and returns the status word ‘9865’ (Key Freshness Failure), indicating to the ME that the received MIKEY message is protected using the last successfully used MUK that does not correspond to the last generated MUK (the new B-TID shall be put into use: see TS 33.246 [43]). In this case, the USIM shall not return a MIKEY verification message.
– Otherwise, this is considered as a bootstrapping failure (incorrect MUK) and the USIM abandons the function. The status word ‘6A88’ (Referenced data not found) is returned.
Otherwise, if the received MUK ID corresponds to the last generated MUK, the USIM uses the MUK value for MSK validation and derivation functions as described in TS 33.246 [43]. If the validation is unsuccessful, the status word ‘9862’ (Authentication error, incorrect MAC) is returned and the USIM abandons the function.
After a successful MSK Update procedure the USIM stores the received credentials (e.g. MSK and/or Key Validity data) and updates EFMSK as follows:
– If a record with the received Key Domain ID and Key Group part (i.e. Key Group part of the MSK ID) already exists, USIM stores the older MSK ID (if any) and its associated TS as the 2nd MSK ID and TS. The newer MSK ID is stored as the 1st MSK ID. In case the received MSK message has the same MSK ID as a stored MSK, the TS associated to this stored MSK is stored as the 1st TS. Otherwise, the 1st TS value is reset. The number of stored MSK IDs and corresponding TS shall be set to ’02’ if the USIM stores two different MSK IDs. The USIM shall not store two MSK IDs with the same Key Number part in the same record.
– If a record with the received Key Domain ID and Key Group part does not exist, the USIM uses an empty record to include those values. The received MSK ID is stored as the 1st MSK ID and the associated TS is reset. The 2nd MSK ID and the associated TS are set to ‘FF FF’. The number of stored MSK IDs and corresponding TS shall be set to ’01’. In case there is no empty record available in EFMSK the USIM abandons the function and the status word ‘9866’ (Authentication error, no available memory space) is returned.
– In the case of a BM-SC solicited pull procedure (i.e. when the Key Number part of the MSK ID is set to 0x0), EFMSK is not updated.
NOTE: In case no empty record is available the ME should run an MSK Deletion Mode procedure to free entries in EFMSK before running an MSK Update Mode procedure that contains a new MSK key.
Then, the USIM stores the Time Stamp field (retrieved from the MIKEY message) in its corresponding field under EFMUK.
The USIM stores internally the last successfully used MUK along with its MUK ID for further use. This MUK may be used beyond its GBA validity (i.e. after the derivation of a new Ks_int_NAF resulting from a new bootstrap procedure) to verify the integrity of a MIKEY message in order to detect a synchronization failure. This may occur if the last derived Ks_int_NAF did not reach the BM-SC.
The MSK is not necessarily updated in the MIKEY message, since a MSK transport message can be sent e.g. to update the Key Validity data or as part of a BM-SC solicited pull procedure. In such a case the USIM shall use the status word ‘9000’ to inform the ME that the MIKEY message validation using the last generated MUK has succeeded.
Finally, if the V-bit in the HDR field of the received MIKEY message is set then the USIM shall produce a MSK Verification Message as described in TS 33.246 [43]. In this case the command response is the MIKEY verification message.
Input:
‑ MIKEY message
Output:
– MIKEY message
or
– None
7.1.1.7 Void
7.1.1.8 MBMS security context (MTK Generation Mode)
USIM operations in MBMS security context are supported if service n°69 is "available".
The USIM receives the MIKEY message containing an MBMS MTK and a Salt key (if Salt key is available). First, the USIM retrieves the MSK with the Key Domain ID and the MSK ID given by the Extension payload of the MIKEY message (as described in TS 33.246 [43]).
If the needed MSK does not exist, this is considered as a MSK failure and the USIM abandons the function. The status word ‘6A88’ (Referenced data not found) is returned.
If the key validity data of the MSK indicates an invalidated MSK (i.e. SEQl is greater than SEQu) then the USIM returns the status word ‘6985’ (Conditions of use not satisfied) and abandons the function. SEQl and SEQu are defined in TS 33.246 [43].
Otherwise, the USIM performs the MBMS Generation and Validation Function (MGV-F) as described in TS 33.246 [43] using MSK.
If the USIM detects that the given MTK ID is invalid, this is considered as a SEQp freshness failure and the USIM abandons the function. The status word ‘9865’ (Key freshness failure) is returned.
If the integrity validation of the MIKEY message is unsuccessful, the USIM abandons the function and returns the status word ‘9862’ (Authentication error, incorrect MAC).
After successful MGV_F procedure the USIM stores the Time Stamp field (retrieved from the MIKEY message) as the Time Stamp Counter (TS) associated with the involved MSK under EFMSK
The USIM also stores MTK ID (retrieved from the MIKEY message) as the SEQl associated with MSK.
Then, the USIM returns MTK and Salt key (if Salt key is available).
Input:
‑ MIKEY message
Output:
– MTK and Salt (if available).
7.1.1.9 MBMS security context (MSK Deletion Mode)
USIM operations in MBMS security context are supported if service n°69 is "available".
The USIM receives the Key Domain ID and the Key Group part of the MSK ID. The USIM shall identify in the EFMSK the record containing MSK IDs having this Key Domain ID and Key Group part.
If no record is identified, the USIM abandons the function and returns the status word ‘6A88’ (Referenced data not found).
If a record is found, the USIM shall delete all corresponding MSKs and set to ‘FF’ the bytes of this record.
Input:
‑ Key Domain ID, MSK ID Key Group part
Output:
– None.
7.1.1.10 MBMS security context (MUK Deletion Mode)
USIM operations in MBMS security context are supported if service n°69 is "available".
The USIM shall identify in EFMUK the record containing the received MUK ID.
If no record is identified, the USIM abandons the function and returns the status word ‘6A88’ (Referenced data not found).
If a record is found, the USIM shall delete the corresponding MUK and set to ‘FF’ the bytes of this record. If a corresponding Ks_int_NAF key is present (i.e. with the same NAF_ID), it shall be deleted and its corresponding record in EFGBANL shall be set to ‘FF’. In case the corresponding Ks key is present (i.e. with the same B-TID), it shall be deleted and the content of EFGBABP shall be set to ‘FF’.
Input:
MUK ID TLV
Output:
– None
7.1.1.11 Local Key Establishment security context (Key Derivation mode)
USIM operations in this security context are supported if service n°68 and service n°76 are "available".
The USIM receives the NAF_ID corresponding to the NAF Key Centre, the Terminal_ID, the Terminal_appli_ID, the UICC_appli_ID, RANDx, the Counter Limit value and the MAC as described in TS 33.110 [47].
The USIM uses the NAF_ID to identify the Ks_int_NAF associated to the NAF Key Centre. If no valid Ks_int_NAF is available, this is considered as a Key Establishment failure and the USIM abandons the function. The status word ‘6A88’ (Referenced data not found) is returned.
If the Ks_local key derivation is not authorized by the local UICC policy (e.g. Terminal_appli_ID/UICC_appli_ID association not authorized or Terminal_ID value not authorized), the USIM abandons the function. The status word ‘6985’ (Conditions of use not satisfied) is returned.
Otherwise, the USIM retrieves the appropriate Ks_int_NAF, derives Ks_local as described in TS 33.110 [47]. The USIM verifies the MAC value received from the Terminal as described in TS 33.110 [47]:
– If the verification is unsuccessful, the USIM abandons the function and returns the status word ‘9862’ (Authentication error, incorrect MAC).
– If the verification is successful, the USIM stores Ks_local and associated parameters Terminal_ID, Terminal_appli_ID, UICC_appli_ID, RANDx and the Ks_local Counter Limit. The USIM returns the Local Key Establishment Operation Response TLV (indicating a successful Key Derivation operation) and a response MAC, which is derived as described in TS 33.110 [47].
The minimum number of Local keys that can be stored by the USIM shall be defined by the service provider at the pre-issuance of the card.
In case the maximum number of Local Key was already reached or there is not enough available memory in the USIM, the USIM shall overwrite a Local Key and its associated data in order to store the new one. To determine the Ks_local to overwrite, the USIM shall construct a list of Ks_local identifiers by storing in the list first position the Ks_local identifier of the last used or derived Ks_local and by shifting down the remaining list elements. The last Ks_local identifier in this list corresponds to the Ks_local to overwrite when the USIM runs out of free memory or when the maximum number of Ks_local keys is reached. If an existing Ks_local in use is overwritten, the application using Ks_local shall not be affected.
Input:
– Local Key Establishment Mode (Key Derivation mode), Counter Limit, request MAC, Key Identifier (i.e. NAF_ID, Terminal_ID, Terminal_appli_ID, UICC_appli_ID, RANDx)
Output:
– Key Derivation operation status, response MAC.
7.1.1.12 Local Key Establishment security context (Key Availability Check mode)
USIM operations in this security context are supported if service n°68 and service n°76 are "available".
The USIM receives a Ks_local identifier. The USIM checks if a corresponding valid Ks_local is available. If a valid Ks_local key is available the Local Key Establishment Operation Response TLV (indicating a successful Key Availability Check operation) is returned. In case no valid Ks_local key is available the command fails and the status word ‘6A88’ (Referenced data not found) is returned.
Input:
Local Key Establishment Mode (Key Availability Check mode), Key identifier (i.e. NAF_ID, Terminal_ID, Terminal_appli_ID, UICC_appli_ID, RANDx).
Output:
– Key Availability Check Operation Status.
7.1.2 Command parameters and data
This command can be used with an EVEN or an ODD instruction (INS) code. The EVEN instruction code can be used when the challenge data provided by the terminal is not TLV encapsulated data and the length of the challenge data provided by the terminal is less than 256 bytes.
The ODD instruction code shall be used with the security context specified in table 2, when challenge and response data is TLV encapsulated regardless of their length. Terminals and UICCs that do not support security context requiring TLV format (e.g. MBMS), do not have to support AUTHENTICATE command with ODD instruction code.
EVEN INS code
|
Code |
Value |
|
CLA |
As specified in TS 31.101 [11] |
|
INS |
’88’ |
|
P1 |
’00’ |
|
P2 |
See table 1 below |
|
Lc |
See below |
|
Data |
See below |
|
Le |
’00’, or maximum length of data expected in response |
Parameter P2 specifies the authentication context as follows:
Table 7.1.2-1: Coding of the reference control P2
|
Coding b8-b1 |
Meaning |
|
‘1——-‘ |
Specific reference data (e.g. DF specific/application dependant key) |
|
‘—– XXX’ |
Authentication context: 000 GSM context 001 3G/EPS/5G context 010 VGCS/VBS context 100 GBA context |
All other codings are RFU.
ODD INS code
The authentication data and the authentication response data are encapsulated in BER-TLV objects structured using tag ’73’ for BER-TLV structured data and tag ’53’ otherwise.
How this command can chain successive blocks of authentication data, or authentication response data is described in TS 31 101 [11].
If P1 indicates "First block of authentication data" or "Next block of authentication data":
Input:
– Authentication data encapsulated in a BER-TLV data object.
Output:
– None.
|
Code |
Value |
|
CLA |
As specified in TS 31.101 [11] |
|
INS |
’89’ |
|
P1 |
As specified in TS 31.101 [11] |
|
P2 |
See table 2 below |
|
Lc |
Length of the subsequent data field |
|
Data |
Authentication related data |
|
Le |
Not present |
If P1 indicates "First block of authentication response data" or "Next block of authentication response data":
Input:
– None.
Output:
– Authentication response data encapsulated in a BER-TLV data object.
|
Code |
Value |
|
CLA |
As specified in TS 31.101 [11] |
|
INS |
’89’ |
|
P1 |
As specified in TS 31.101 [11] |
|
P2 |
See table 2 below |
|
Lc |
Not present |
|
Data |
Not present |
|
Le |
Length of the response data |
Parameter P1 is used to control the data exchange between the terminal and the UICC as defined in TS 31.101 [11].
Parameter P2 specifies the authentication context as follows:
Table 7.1.2-2: Coding of the reference control P2
|
Coding b8-b1 |
Meaning |
|
‘1——-‘ |
Specific reference data (e.g. DF specific/application dependant key) |
|
‘—– XXX’ |
Authentication context: 101 MBMS context 110 Local Key Establishment mode |
All other codings are RFU.
Command parameters/data:
7.1.2.1 GSM/3G/EPS/5G security context
|
Byte(s) |
Description |
Length |
|
1 |
Length of RAND (L1) |
1 |
|
2 to (L1+1) |
RAND |
L1 |
|
(L1+2) |
Length of AUTN (L2) (see note) |
1 |
|
(L1+3) to (L1+L2+2) |
AUTN (see note) |
L2 |
|
Note: Parameter present if and only if in 3G/EPS/5G security context. |
||
The coding of AUTN is described in TS 33.102 [13]. The most significant bit of RAND is coded on bit 8 of byte 2. The most significant bit of AUTN is coded on bit 8 of byte (L1+3).
Response parameters/data, case 1, 3G/EPS/5G security context, command successful:
|
Byte(s) |
Description |
Length |
|
1 |
"Successful 3G authentication" tag = ‘DB’ |
1 |
|
2 |
Length of RES (L3) |
1 |
|
3 to (L3+2) |
RES |
L3 |
|
(L3+3) |
Length of CK (L4) |
1 |
|
(L3+4) to (L3+L4+3) |
CK |
L4 |
|
(L3+L4+4) |
Length of IK (L5) |
1 |
|
(L3+L4+5) to (L3+L4+L5+4) |
IK |
L5 |
|
(L3+L4+L5+5) |
Length of KC (= 8) (see note) |
1 |
|
(L3+L4+L5+6 to (L3+L4+L5+13) |
KC (see note) |
8 |
|
Note: Parameter present if and only if Service n°27 is "available". |
||
The most significant bit of RES is coded on bit 8 of byte 3. The most significant bit of CK is coded on bit 8 of byte (L3+4). The most significant bit of IK is coded on bit 8 of byte (L3+L4+5).
Response parameters/data, case 2, 3G/EPS/5G security context, synchronisation failure:
|
Byte(s) |
Description |
Length |
|
1 |
"Synchronisation failure" tag = ‘DC’ |
1 |
|
2 |
Length of AUTS (L1) |
1 |
|
3 to (L1+2) |
AUTS |
L1 |
The coding of AUTS is described in TS 33.102 [13]. The most significant bit of AUTS is coded on bit 8 of byte 3.
Response parameters/data, case 3, GSM security context, command successful:
|
Byte(s) |
Description |
Length |
|
1 |
Length of SRES (= 4) |
1 |
|
2 to 5 |
SRES |
4 |
|
6 |
Length of KC (= 8) |
1 |
|
7 to 14 |
KC |
8 |
The most significant bit of SRES is coded on bit 8 of byte 2. The most significant bit of Kc is coded on bit 8 of byte 7.
7.1.2.2 VGCS/VBS security context
|
Byte(s) |
Description |
Length |
|
1 |
Length of Vservice_Id |
1 |
|
2 to 5 |
Vservice_Id |
4 |
|
6 |
Length of VK_Id |
1 |
|
7 |
VK_Id |
1 |
|
8 |
Length of VSTK_RAND (L1) |
1 |
|
9 to L1+8 |
VSTK_RAND |
L1 |
Vservice_Id is coded in the same way as the octets 2-5 in the Descriptive group or broadcast call reference information element as defined in TS 24.008 [9].
An Example for the coding of Vservice_Id can be found in Annex K.
The coding of VK_Id is as follows:
Coding of VK_Id
|
Coding b8-b1 |
Meaning |
|
‘00000001’ |
Corresponds to the 1st group key |
|
‘00000010’ |
Corresponds to the 2nd group key |
The coding of VSTK_RAND is described in TS 43.020 [44]. The VSTK_RAND shall be inserted left-aligned into the L1 bytes, with unused bits to the right set to zero.
Response parameters/data, VGCS/VBS security context, command successful:
|
Byte(s) |
Description |
Length |
|
1 |
"Successful VGCS/VBS operation" tag = ‘DB’ |
1 |
|
2 |
Length of VSTK (16) |
1 |
|
3 to 18 |
VSTK |
16 |
7.1.2.3 GBA security context (Bootstrapping Mode)
|
Byte(s) |
Description |
Length |
|
1 |
"GBA Security Context Bootstrapping Mode" tag = ‘DD’ |
1 |
|
2 |
Length of RAND (L1) |
1 |
|
3 to (L1+2) |
RAND |
L1 |
|
(L1+3) |
Length of AUTN (L2) |
1 |
|
(L1+4) to (L1+L2+3) |
AUTN |
L2 |
Response parameters/data, GBA security context (Bootstrapping Mode), synchronisation failure:
|
Byte(s) |
Description |
Length |
|
1 |
"Synchronisation failure" tag = ‘DC’ |
1 |
|
2 |
Length of AUTS (L1) |
1 |
|
3 to (L1+2) |
AUTS |
L1 |
AUTS coded as for UMTS Security context.
Response parameters/data, GBA security context (Bootstrapping Mode), command successful:
|
Byte(s) |
Description |
Length |
|
1 |
"Successful GBA operation" tag = ‘DB’ |
1 |
|
2 |
Length of RES (L) |
1 |
|
3 to (L+2) |
RES |
L |
RES coded as for UMTS Security context.
7.1.2.4 GBA security context (NAF Derivation Mode)
|
Byte(s) |
Description |
Length |
|
1 |
"GBA Security Context NAF Derivation Mode" tag = ‘DE’ |
1 |
|
2 |
Length of NAF_ID (L1) |
1 |
|
3 to (L1+2) |
NAF_ID |
L1 |
|
(L1+3) |
Length of IMPI (L2) |
1 |
|
(L1+4) to (L1+L2+3) |
IMPI |
L2 |
Response parameters/data, GBA security context (NAF Derivation Mode), command successful:
|
Byte(s) |
Description |
Length |
|
1 |
"Successful GBA operation" tag = ‘DB’ |
1 |
|
2 |
Length of Ks_ext_NAF (L) |
1 |
|
3 to (L+2) |
Ks_ext_NAF |
L |
Coding of Ks_ext_NAF as described in TS 33.220 [42].
7.1.2.5 MBMS security context (All Modes)
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
MBMS Data Object tag (’53’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to 1+A bytes (A ≤ 4) |
MBMS Data Object length (L1) |
As defined in TS 31.101 [11] for BER-TLV data object |
A |
|
A+2 |
MBMS Security Context Mode |
See below |
1 |
|
A+3 to (A+L1+1) |
MIKEY message or Key Domain ID || MSK ID Key Group part or MUK ID TLV |
L1-1 |
Only the MIKEY message shall be transmitted in the MBMS security context mode ’01’ or ’02’.
Only the Key Domain ID (coded on 3 bytes as described in TS 33.246 [43]) concatenated with the Key Group part of the MSK ID (coded on two bytes as described in TS 33.246 [43] where the last transmitted byte represents the least significant byte of the Key Group part) shall be transmitted in the MBMS security context mode ’03’.
Only the MUK ID TLV shall be transmitted in the MBMS security context mode ’04’. The MUK ID TLV, containing the MUK Idr and MUK Idi only, shall be encoded as described in clause 4.2.81.
Parameter MBMS Security Context Mode specifies the MBMS mode in which MBMS security procedure is performed as follows:
Coding of MBMS Security Context Mode
|
Coding |
Meaning |
|
’01’ |
MSK Update Mode |
|
’02’ |
MTK Generation Mode |
|
’03’ |
MSK Deletion Mode |
|
’04’ |
MUK Deletion Mode |
Response parameters/data, MBMS security context (MSK Update Mode), command successful:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
MBMS operation response Data Object tag (’53’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to 1+A bytes (A ≤ 4) |
MBMS operation response Data Object length (L) |
As defined in TS 31.101 [11] for BER-TLV data object |
A |
|
A+2 |
"Successful MBMS operation" tag = ‘DB’ (see note 1) |
1 |
|
|
A+3 to (A+L+1) |
MIKEY message (see note 1) |
L-1 |
|
|
NOTE 1: Parameter present if a MIKEY verification message is returned. Otherwise, the USIM returns "53 01 DB" |
|||
Response parameters/data, MBMS security context (MTK Generation Mode), command successful:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
MBMS operation response Data Object tag (’53’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to 1+A bytes (A ≤ 4) |
MBMS operation response Data Object length (L) |
As defined in TS 31.101 [11] for BER-TLV data object |
A |
|
A+2 |
"Successful MBMS operation" tag = ‘DB’ |
1 |
|
|
A+3 to (A+L+1) |
MTK || Salt (if Salt key is available) |
L-1 |
Response parameters/data, MBMS security context (MSK and MUK Deletion Mode), command successful:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
MBMS operation response Data Object tag (’53’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 |
MBMS operation response Data Object length |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
3 |
"Successful MBMS operation" tag = ‘DB’ |
1 |
The coding of parameters is described in TS 33.246 [43].
Note: The constructed TLV tag value ‘AE’ is used by OMA BCAST Smart Card Profile [49] for the encapsulation of command and response parameters/data.
7.1.2.6 Local Key Establishment security context (All Modes)
The Local Key Establishment Control TLV is included in the command data to indicate the security context mode. The Local Key Establishment Control TLV is also included in the response data to indicate the operation status.
Table 3: Coding of the Local Key Establishment Control TLV
|
Tag Value |
Length |
Value / Meaning |
|
’80’ |
Coded according to ISO/IEC 8825-1 [35] |
Local Key Establishment context: ’01’: Key Derivation mode ’02’: Key Availability Check mode Operation Status: ‘DB’: Successful Operation |
7.1.2.6.1 Local Key Establishment security context (Key Derivation mode)
Command parameters/data:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
Key Derivation Data Object tag (’73’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to A+1 bytes (A ≤ 4) |
Key Derivation Data Object length (L) |
As defined in TS 31.101 [11] for BER-TLV data object |
A |
|
A+2 to (A+L+1) |
Key Derivation Data Object |
L |
– Key Derivation Data Object content: The TLVs defined in table 4 are included in the Key Derivation Data Object.
Table 4: Coding of the Key Derivation Data Object
|
Description |
Value |
M/O |
Length (bytes) |
|
Local Key Establishment Control TLV |
Coded as defined in clause 7.1.2.6. The value field shall be set to ’01’ |
M |
B |
|
Counter Limit tag |
’81’ |
M |
1 |
|
Length |
C |
M |
Note 1 |
|
Counter Limit |
Coded as defined in TS 33.110 [47] |
M |
C |
|
Request MAC tag |
’82’ |
M |
1 |
|
Length |
D |
M |
Note 1 |
|
Request MAC |
Coded as defined in TS 33.110 [47] |
M |
D (see Note 3) |
|
Key Identifier tag |
‘A0’ |
M |
1 |
|
Length |
E (see Note 2) |
M |
Note 1 |
|
NAF_ID tag |
’83’ |
M |
1 |
|
Length |
F |
M |
Note 1 |
|
NAF_ID |
Coded as defined in TS 33.220 [42] |
M |
F |
|
Terminal_ID tag |
’84’ |
M |
1 |
|
Length |
G |
M |
Note 1 |
|
Terminal_ID |
Coded as defined in TS 33.110 [47] |
M |
G |
|
Terminal_appli_ID tag |
’85’ |
M |
1 |
|
Length |
H |
M |
Note 1 |
|
Terminal_appli_ID |
Coded as defined in TS 33.110 [47] |
M |
H |
|
UICC_appli_ID tag |
’86’ |
M |
1 |
|
Length |
I |
M |
Note 1 |
|
UICC_appli_ID |
Coded as defined in TS 33.110 [47] |
M |
I |
|
RANDx tag |
’87’ |
M |
1 |
|
Length |
J |
M |
Note 1 |
|
RANDx |
Coded as defined in TS 33.110 [47] |
M |
J (see Note 4) |
|
Note 1: The length is coded according to ISO/IEC 8825-1 [35]. Note 2: The Key Identifier TLV is a constructed TLV containing the following primitive TLVs: NAF_ID, Terminal_ID, Terminal_appli_ID, UICC_appli_ID and RANDx. E is the length of the constructed Key Identifier value. Note 3: The most significant bit of the request MAC is coded on bit 8 of the first byte following the MAC Length. Note 4: The most significant bit of the RANDx is coded on bit 8 of the first byte following the RANDx Length. |
|||
Response parameters/data, Local Key Establishment security context (Key Derivation mode), command successful:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
Key Derivation Operation Response Data Object tag (’73’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to A1+1 bytes (A1 ≤ 4) |
Key Derivation Operation Response Data Object length (L1) |
As defined in TS 31.101 [11] for BER-TLV data object |
A1 |
|
A1+2 to (A1+L1+1) |
Key Derivation Operation Response Data Object |
L1 |
Key Derivation Operation Response Data Object content: The TLVs defined in table 5 are included in the Key Derivation Operation Response Data Object.
Table 5: Coding of the Key Derivation Operation Response Data Object
|
Description |
Value |
M/O |
Length (bytes) |
|
Local Key Establishment Control TLV |
Coded as defined in clause 7.1.2.6. The value field shall be set to ‘DB’ |
M |
B |
|
Response MAC tag |
’82’ |
M |
1 |
|
Length |
C |
M |
Note 1 |
|
Response MAC |
Coded as defined in TS 33.110 [47] |
M |
C (see Note 2) |
|
Note 1: The length is coded according to ISO/IEC 8825-1 [35]. Note 2: The most significant bit of the response MAC is coded on bit 8 of the first byte following the MAC length. |
|||
7.1.2.6.2 Local Key Establishment security context (Key Availability Check mode)
Command parameters/data:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
Key Availability Check Data Object tag (’73’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to 1+A bytes (A ≤ 4) |
Key Availability Check Data Object length (L) |
As defined in TS 31.101 [11] for BER-TLV data object |
A |
|
A+2 to (A+L+1) |
Key Availability Check Data Object |
L |
– Key Availability Check Data Object content: The TLVs defined in table 6 are included in the Key Availability Check Data Object.
Table 6: Coding of the Key Availability Check Data Object
|
Description |
Value |
M/O |
Length (bytes) |
|
Local Key Establishment Control TLV |
Coded as defined in clause 7.1.2.6. The value field shall be set to ’02’ |
M |
B |
|
Key Identifier TLV |
Coded as defined in clause 7.1.2.6.1 |
M |
C |
Response parameters/data, Local Key Establishment security context (Key Availability Check mode), command successful:
|
Byte(s) |
Description |
Coding |
Length |
|
1 |
Key Availability Check Operation Response Data Object tag (’73’) |
As defined in TS 31.101 [11] for BER-TLV data object |
1 |
|
2 to 1+A1 bytes (A1 ≤ 4) |
Key Availability Check Operation Response Data Object length (L1) |
As defined in TS 31.101 [11] for BER-TLV data object |
A1 |
|
A1+2 to (A1+L1+1) |
Key Availability Check Operation Response Data Object |
L1 |
– Key Availability Check Operation Response Data Object content: The TLV defined in table 7 is included in the Key Availability Check Operation Response Data Object.
Table 7: Coding of the Key Availability Check Operation Response Data Object
|
Description |
Value |
M/O |
Length (bytes) |
|
Local Key Establishment Control TLV |
Coded as defined in clause 7.1.2.6. The value field shall be set to ‘DB’ |
M |
B |
7.2 Void
7.3 Status Conditions Returned by the USIM
Status of the card after processing of the command is coded in the status bytes SW1 and SW2. This clause specifies the coding of the status bytes in the following tables, in addition to the ones defined in TS 31.101 [11].
7.3.1 Security management
|
SW1 |
SW2 |
Error description |
|
’98’ |
’62’ |
‑ Authentication error, incorrect MAC |
|
’98’ |
’64’ |
‑ Authentication error, security context not supported |
|
’98’ |
’65’ |
‑ Key freshness failure |
|
’98’ |
’66’ |
– Authentication error, no memory space available |
|
’98’ |
’67’ |
– Authentication error, no memory space available in EFMUK |
7.3.2 Status Words of the Commands
The following table shows for each command the possible status conditions returned (marked by an asterisk *).
Commands and status words
|
Status Words |
AUTHENTICATE |
GET IDENTIYY |
|
90 00 |
* |
* |
|
91 XX |
* |
* |
|
93 00 |
||
|
98 50 |
||
|
98 62 |
* |
|
|
98 64 |
* |
|
|
98 65 |
* |
|
|
98 66 |
* |
|
|
98 67 |
* |
|
|
62 00 |
* |
* |
|
62 81 |
||
|
62 82 |
||
|
62 83 |
||
|
62 F1 |
* |
|
|
62 F3 |
* |
|
|
63 CX |
||
|
63 F1 |
* |
|
|
64 00 |
* |
* |
|
65 00 |
* |
* |
|
65 81 |
* |
* |
|
67 00 |
* |
* |
|
67 XX – (see note) |
* |
* |
|
68 00 |
* |
* |
|
68 81 |
* |
* |
|
68 82 |
* |
* |
|
69 81 |
||
|
69 82 |
* |
* |
|
69 83 |
||
|
69 84 |
* |
|
|
69 85 |
* |
* |
|
69 86 |
||
|
6A 80 |
||
|
6A 81 |
* |
* |
|
6A 82 |
||
|
6A 83 |
||
|
6A 86 |
* |
* |
|
6A 87 |
||
|
6A 88 |
* |
* |
|
6B 00 |
* |
* |
|
6E 00 |
* |
* |
|
6F 00 |
* |
* |
|
6F XX – (see note) |
* |
* |
|
NOTE: Except SW2 = ’00’. |
||
7.4 Optional commands
The following command is optional for the USIM application:
– GET CHALLENGE command as defined in TS 31.101 [11].
– GET IDENTITY command as defined in clause 7.5
Note: OMA BCAST Smart Card Profile [49] defines a command using instruction code INS ‘1B’
7.5 GET IDENTITY
7.5.1 Command description
The function can be used in the following contexts:
– a SUCI context, to retrieve the SUCI when "SUCI calculation is to be performed by the USIM".
– a SUCI NSWO context, to retrieve the SUCI when "SUCI calculation is to be performed by the USIM" and "5G NSWO support" is activated (i.e. Service nº142 is "available").
The function is related to a particular USIM and shall not be executable unless the USIM application has been selected and activated, and the current directory is the USIM ADF or any subdirectory under this ADF and a successful PIN verification procedure has been performed (see clause 5).
If GET IDENTITY command is not supported by the UICC, then the status word ‘6D00’ (Instruction code not supported or invalid) shall be returned.
7.5.1.1 SUCI context
SUCI context shall be supported if "SUCI calculation is to be performed by the USIM" (i.e. Service n°124 and Service n°125 are "available").
The command returns the SUCI which is a privacy preserving identifier containing the concealed SUPI. The function is used in 5GS in the specific cases described in 3GPP TS 33.501 [105] prior to mutual authentication between the UE and the SN.
The SUCI returned is calculated as described in 3GPP TS 33.501 [105].
For the execution of the command, the following information shall be available in the USIM:
– Home network identifier (i.e. MCC and MNC when SUPI Type is IMSI or domain name when SUPI Type is Network Specific Identifier, Global Line Identifier or Global Cable Identifier) (see NOTE).
– Routing indicator (configured in EFRouting_Indicator).
– Home network public key (see Note).
– Home network public key identifier (see Note).
– Protection scheme identifier (see Note).
– SUPI.
NOTE: Provision and storage of the information in the USIM when "SUCI calculation is to be performed by the USIM" (i.e. Service n°124 and Service n°125 are "available") is out of the scope of the specification.
The SUCI is designed for one-time use, however, the freshness and randomness of SUCI returned upon each call of the command depends on the protection scheme configured. There is the special case where the protection scheme used is null-scheme, in such case SUCI contains the non concealed SUPI.
If the home network public key is not provisioned in the USIM, the SUCI shall be calculated using the null-scheme irrespective of the protection scheme stored in the USIM.
The returned SUCI consists of the concatenation of the following information as described in 3GPP TS 23.003 [25]:
– SUPI Type
– Home network identifier (i.e. MCC and MNC when SUPI Type is IMSI or domain name when SUPI Type is Network Specific Identifier, Global Line Identifier or Global Cable Identifier).
– Routing indicator.
– Protection scheme identifier.
– Home network public key identifier.
– Scheme output, resulting from the protection scheme profile, identified by the protection scheme identifier. The protection scheme profile shall be one of those defined in Annex C of 3GPP TS 33.501 [105] or one of those specified by the Home network.
If SUCI context is supported and:
– Service n°124 is not "available" or:
– "SUCI calculation is to be performed by the ME" (i.e. Service n°124 is "available", and Service n°125 is not "available")
the status word ‘6985’ (Conditions of use not satisfied) shall be returned
Editor’s Note: It is FFS to specify the behavior in case other parameters (e.g. Home network public key identifier, some necessary data is not provisioned) are not correctly configured
7.5.1.2 SUCI 5G NSWO context
SUCI 5G NSWO context shall be supported if "SUCI calculation is to be performed by the USIM" (i.e. Service n°124 and Service n°125 are "available") and "5G NSWO support" is activated (i.e. Service nº142 is "available").
The command returns the SUCI which is a privacy preserving identifier containing the concealed SUPI. The function is used in 5GS in the specific cases of NSWO authentication described in 3GPP TS 33.501 [105] Annex S.
For the execution of the command, the following information shall be available in the USIM:
– Home network identifier (i.e. MCC and MNC when SUPI Type is IMSI) (see NOTE 1).
– Routing indicator (configured in EFRouting_Indicator).
– Home network public key (see NOTE 1).
– Home network public key identifier (see NOTE 1).
– Protection scheme identifier (see NOTE 1).
– SUPI (NOTE 2).
NOTE 1: Provision and storage of the information in the USIM when "SUCI calculation is to be performed by the USIM" (i.e. Service n°124 and Service n°125 are "available") is out of the scope of the specification.
NOTE 2: As per TS 33.501 [105] Annex C.3.1, when the SUPI is of type IMSI, the subscription identifier part of the IMSI (i.e., MSIN) that is used to construct the scheme-input shall be coded as hexadecimal digits using packed BCD coding.
The SUCI is designed for one-time use, however, the freshness and randomness of SUCI returned upon each call of the command depends on the protection scheme configured. There is the special case where the protection scheme used is null-scheme, in such case, SUCI contains the non concealed SUPI.
If the home network public key is not provisioned in the USIM, the SUCI shall be calculated using the null scheme irrespective of the protection scheme stored in the USIM.
The returned SUCI shall be in the NAI format as in TS 23.003 [25] and is computed as described in 3GPP TS 33.501 [105] Annex S.3.
If SUCI 5G NSWO context is supported and:
– Service n°124 is not "available" or
– "SUCI calculation is to be performed by the ME" (i.e. Service n°124 is "available", and Service n°125 is not "available") or
– "5G NSWO support" is not activated (i.e. Service nº142 is not "available")
the status word ‘6985’ (Conditions of use not satisfied) shall be returned.
Editor’s Note: It is FFS to specify the behavior in case other parameters (e.g. Home network public key identifier, some necessary data is not provisioned) are not correctly configured
7.5.2 Command parameters and data
|
Code |
Value |
|
CLA |
As specified in TS 31.101 [11] |
|
INS |
’78’ |
|
P1 |
’00’ |
|
P2 |
Identity context, see Table 7.5.2-1 below |
|
Lc |
Length of the subsequent data field or not present, see below |
|
Data |
See below |
|
Le |
’00’, or maximum length of data expected in response |
Parameter P2 specifies the identity context as follows:
Table 7.5.2-1: Coding of the reference control P2
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
Meaning |
|
– |
X |
X |
X |
X |
X |
X |
X |
Identity Context (See below) |
|
– |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
SUCI |
|
– |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
SUCI 5G NSWO |
All other codings are RFU.
7.5.2.1 SUCI context
Command parameters/data: None
Response parameters/data:
|
Byte(s) |
Description |
Length |
|
1 to Le |
SUCI TLV data object |
Le |
Subscription Concealed Identifier TLV data object:
|
Description |
Value |
M/O/C |
Length (bytes) |
|
SUCI TLV data object tag |
‘A1’ |
M |
1 |
|
Length |
X |
M |
Note |
|
SUCI value |
— |
M |
X |
|
NOTE: The length is coded according to ISO/IEC 8825-1 [35] |
|||
– SUCI
It contains the SUCI as defined in 3GPP TS 33.501 [105].
When SUPI Type is IMSI, the SUCI is coded as part of 5GS mobile identity information element for type of identity "SUCI" and SUPI format "IMSI" defined in 3GPP TS 24.501 [104]. The correspondence between the SUCI value and the octets of the above referenced 5GS mobile identity information element is provided below:
Byte 1 corresponds to "octet 4" and the value is ’01’:
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
||||||||||||
|
1 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
From byte 2 to 4, the Home Network Identifier (i.e. MCC and MNC) is coded and corresponds from "octet 5" to "octet 7".
Byte 5 and 6 code the Routing Indicator which correspond to "octet 8" and "octet 9".
Byte 7 codes the Protection Scheme Identifier which corresponds to "octet 10".
Byte 8 codes the Home Network Public Key Identifier which corresponds to "octet 11".
Byte 9 corresponds to "octet 12". From Byte 9 onwards, the Scheme Output is coded and the length depends on the Protection Scheme used.
When SUPI Type is Network Specific Identifier (i.e. service n°130 is "available" and EFSUPI_NAI contains a Network Specific Identifier), the SUCI is coded as part of 5GS mobile identity information element for type of identity "SUCI" and SUPI format "Network specific identifier" defined in 3GPP TS 24.501 [104]. The correspondence between the SUCI value and the octets of the above referenced 5GS mobile identity information element is provided below:
Byte 1 corresponds to "octet 4" and the value is ’11’:
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
|||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
Byte 2 corresponds to "octet 5". From byte 2 onwards, the SUCI NAI is coded as defined in 3GPP TS 24.501 [104].
When SUPI Type is Global Line Identifier (i.e. service n°130 is "available" and EFSUPI_NAI contains a Global Line Identifier), the SUCI is coded as part of 5GS mobile identity information element for type of identity "SUCI" and SUPI format "Global Line Identifier" (GLI) defined in 3GPP TS 24.501 [104]. The correspondence between the SUCI value and the octets of the above referenced 5GS mobile identity information element is provided below:
Byte 1 corresponds to "octet 4" and the value is ’31’:
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
|||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
1 |
||||||||||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
Byte 2 corresponds to "octet 5". From byte 2 onwards, the SUCI NAI is coded as defined in 3GPP TS 24.501 [104].
When SUPI Type is Global Cable Identifier (i.e. service n°130 is "available" and EFSUPI_NAI contains a Global Cable Identifier), the SUCI is coded as part of 5GS mobile identity information element for type of identity "SUCI" and SUPI format "Global Cable Identifier" (GCI) defined in 3GPP TS 24.501 [104]. The correspondence between the SUCI value and the octets of the above referenced 5GS mobile identity information element is provided below:
Byte 1 corresponds to "octet 4" and the value is ’21’:
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
|||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
1 |
||||||||||||||||||
|
0 |
||||||||||||||||||
|
0 |
||||||||||||||||||
Byte 2 corresponds to "octet 5". From byte 2 onwards, the SUCI NAI is coded as defined in 3GPP TS 24.501 [104].
7.5.2.2 SUCI 5G NSWO context
Command parameters/data: None
Response parameters/data:
|
Byte(s) |
Description |
Length |
|
1 to Le |
SUCI TLV data object |
Le |
Subscription Concealed Identifier TLV data object:
|
Description |
Value |
M/O/C |
Length (bytes) |
|
SUCI TLV data object tag |
‘A1’ |
M |
1 |
|
Length |
X |
M |
Note |
|
SUCI value |
— |
M |
X |
|
NOTE: The length is coded according to ISO/IEC 8825-1 [35] |
|||
– SUCI
It contains the SUCI in NAI format as defined in TS 33.501 [105] Annex S.
When SUPI Type is IMSI, the SUCI in NAI format is coded as part of 5GS mobile identity information element as defined in 3GPP TS 24.501 [104] Figure 9.11.3.4.4. The correspondence between the SUCI value and the octets of the above referenced 5GS mobile identity information element is provided below:
Byte 1 corresponds to "octet 4" and the value is ’01’:
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
||||||||||||
|
1 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
|
0 |
|||||||||||||||||||
Byte 2 corresponds to "octet 5". From byte 2 onwards, the SUCI NAI field contains an NAI constructed as specified in clause 28.7.3 of 3GPP TS 23.003 [25].