The USIM first computes the anonymity key AK = f5_K (RAND) and retrieves the sequence number SQN = (SQN ⊕ AK) ⊕ AK. Then the USIM computes XMAC = f1_K (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 SQN_MS, 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. 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: 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 = f2_K (RAND), the cipher key CK = f3_K (RAND) and the integrity key IK = f4_K (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. If Service No. 27 is "available", the USIM calculates the GSM response parameter KC, using the conversion function defined in TS 33.102.

USIM operation in an GSM security context is supported if Service No. 38 is "available". The USIM computes RES = f2_K (RAND), the cipher key CK = f3_K (RAND) and the integrity key IK = f4_K (RAND). Next the USIM calculates the GSM response parameters SRES and K_C, using the conversion functions defined in TS 33.102.

USIM operation in a VGCS/VBS security context is supported if both Service No. 57 and Service No. 64 are "available" (VGCS security context) or if both Service No. 58 and Service No. 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). 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) in order to compute and returns VSTK.

USIM operations in GBA security context are supported if service No. 68 is "available". The USIM receives the RAND and AUTN*. The USIM first computes the anonymity key AK = f5_K (RAND) and retrieves the sequence number SQN = (SQN ⊕ AK) ⊕ AK. The USIM calculates IK = f4_K (RAND) and MAC (by performing the MAC modification function described in TS 33.220). Then the USIM computes XMAC = f1_K (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 = f2_K (RAND) and the cipher key CK = f3_K (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. RES is included in the command response after flipping the least significant bit.

USIM operations in GBA security context are supported if service No. 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 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.
• 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.

USIM operations in MBMS security context are supported if service No. 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) 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.

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). 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. 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.

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. In this case the command response is the MIKEY verification message.

USIM operations in MBMS security context are supported if service No. 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). 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. Otherwise, the USIM performs the MBMS Generation and Validation Function (MGV-F) as described in TS 33.246 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).

USIM operations in MBMS security context are supported if service No. 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.

USIM operations in MBMS security context are supported if service No. 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'.

USIM operations in this security context are supported if service No. 68 and service No. 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. 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. The USIM verifies the MAC value received from the Terminal as described in TS 33.110:

• 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.

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.

USIM operations in this security context are supported if service No. 68 and service No. 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.