Security
This document describes the authentication, ciphering, and identity management mechanisms implemented by OmniMSC, including GSM and UMTS authentication, air-interface encryption, TMSI allocation, and identity request procedures. For configuration of cipher algorithms and security parameters, see Configuration Reference. For the MAP operations that support authentication, see MAP Operations. For TMSI allocation in MSC pool deployments with NRI encoding, see MSC Pool and NRI.
Authentication Overview
OmniMSC supports both GSM (2G) and UMTS (3G) authentication as defined in 3GPP TS 33.102 and TS 24.008 Section 4.3. Authentication is performed during location updates and, optionally, during call setup and SMS transactions.
The MSC does not store long-term subscriber credentials (Ki). Authentication vectors are obtained from the HLR/AuC via MAP SendAuthenticationInfo (see MAP Operations). The MSC sends the IMSI to the HLR, which returns a set of authentication vectors. The MSC then challenges the UE and verifies its response. The subscriber's current authentication state and remaining tuple count are visible in the control panel — see Control Panel Guide.
UMTS AKA (Authentication and Key Agreement)
UMTS Authentication and Key Agreement provides mutual authentication -- the network authenticates the subscriber and the subscriber authenticates the network. This is the preferred authentication method for USIM-equipped terminals.
The HLR returns quintuplets, each containing five values:
| Field | Size | Description |
|---|---|---|
| RAND | 128 bits | Random challenge generated by AuC |
| XRES | 32-128 bits | Expected response, used by MSC to verify UE |
| CK | 128 bits | Cipher key for air-interface encryption |
| IK | 128 bits | Integrity key for air-interface integrity protection |
| AUTN | 128 bits | Authentication token, used by UE to verify network |
The MSC sends RAND and AUTN to the UE. The USIM verifies AUTN to authenticate the network, then computes RES, CK, and IK. The MSC compares the returned RES against XRES to authenticate the subscriber.
SQN Resynchronisation
AUTN contains a sequence number (SQN) that the USIM checks to prevent replay attacks. If the USIM determines that SQN is out of range (e.g., after a long period of inactivity or database restoration), it returns an Authentication Failure with cause "SQN failure" and includes an AUTS (resynchronisation token) of 112 bits. The MSC forwards AUTS to the HLR in a new MAP SendAuthenticationInfo request, allowing the AuC to resynchronise its SQN counter and return fresh vectors.
GSM AKA
GSM authentication uses triplets for 2G-only subscribers (SIM without USIM application). Each triplet contains:
| Field | Size | Description |
|---|---|---|
| RAND | 128 bits | Random challenge |
| SRES | 32 bits | Signed response, computed by SIM using A3(Ki, RAND) |
| Kc | 64 bits | Cipher key, computed by SIM using A8(Ki, RAND) |
GSM authentication is one-way: the network authenticates the subscriber, but the subscriber does not authenticate the network. The MSC sends RAND, the SIM computes SRES and Kc, and the MSC verifies SRES against the expected value from the triplet.
Auth FSM States
The authentication procedure is managed by a finite state machine within the VLR. The FSM tracks the progress of each authentication attempt.
In the wait_auth_tuples state, the MSC has sent MAP SendAuthenticationInfo and is awaiting vectors from the HLR. In wait_ms_response, the MSC has sent Authentication Request to the UE and is awaiting the response. The wait_auth_resync state handles the AUTS resynchronisation procedure when the UE reports a sequence number mismatch.
Ciphering
After successful authentication, the MSC initiates air-interface ciphering to protect signaling and user traffic on the radio path.
GERAN (2G/3G via BSC)
For the A-interface, the MSC sends a BSSMAP Cipher Mode Command to the BSC, carrying the cipher key (Kc) and the selected A5 algorithm. The BSC activates ciphering on the radio channel and returns Cipher Mode Complete.
| Algorithm | Security | Description |
|---|---|---|
| A5/1 | Moderate | Original GSM cipher, widely deployed |
| A5/3 | Strong | KASUMI-based cipher, recommended for all deployments |
UTRAN (3G via RNC)
For the Iu-CS interface, the MSC sends a RANAP Security Mode Command to the RNC, carrying CK, IK, and the selected UEA (encryption) and UIA (integrity) algorithms. The RNC activates ciphering and integrity protection and returns Security Mode Complete.
Allowed A5 Configuration
The operator configures the set of permitted A5 algorithms. The MSC selects the strongest algorithm supported by both the network configuration and the mobile station's reported capabilities.
The permitted algorithms are specified as a list: allowed_a5: [:a5_1, :a5_3]. The MSC intersects this list with the MS classmark capabilities and selects the highest-strength match. If no common algorithm exists and A5/0 is not permitted, the MSC rejects the connection.
TMSI Allocation
The MSC allocates a Temporary Mobile Subscriber Identity (TMSI) to each subscriber after a successful Location Update. The TMSI replaces the IMSI for subsequent paging and identification, reducing exposure of the permanent identity on the air interface.
Allocation and Confirmation
After completing authentication, ciphering, and the HLR UpdateLocation exchange, the MSC generates a new TMSI and sends it to the mobile station in the Location Update Accept message. The MS stores the TMSI and responds with TMSI Reallocation Complete.
If the TMSI Reallocation Complete is not received within the reallocation timer, the MSC confirms the new TMSI rather than rolling back. This design choice prevents a scenario where the MS has successfully stored the new TMSI but the confirmation was lost on the air interface -- rolling back would leave the MSC and MS with mismatched TMSIs, breaking subsequent paging.
TMSI in MSC Pool
When operating in an MSC pool (3GPP TS 23.236), the TMSI carries NRI (Network Resource Identifier) bits that allow the BSC to route returning subscribers to the correct MSC in the pool. The NRI is embedded in a configurable bit range within the TMSI. When a BSC receives a service request or paging response containing a TMSI, it extracts the NRI and routes the signaling to the MSC that owns that NRI range.
For MSC pool configuration and NRI assignment, see MSC Pool & NRI.
Identity Request
When the MSC cannot resolve a subscriber's identity -- for example, when a TMSI is presented that is not found in the local VLR (after MSC restart, pool re-routing, or VLR overflow) -- the MSC sends an Identity Request to the mobile station requesting the IMSI.
The MS responds with an Identity Response containing its IMSI. The MSC then proceeds with authentication using the IMSI. This procedure is defined in 3GPP TS 24.008 Section 4.3.3.
Identity Request is also used to obtain the IMEI (International Mobile Equipment Identity) when equipment checking is required.
3GPP Specification References
| Specification | Title | Relevance |
|---|---|---|
| TS 33.102 | 3G Security; Security Architecture | UMTS AKA, quintuplets, SQN resynchronisation, key hierarchy |
| TS 24.008 | Mobile Radio Interface Layer 3 | Authentication Request/Response (Sec 4.3), Identity Request (Sec 4.3.3), TMSI Reallocation (Sec 4.3.1) |
| TS 43.020 | Security Related Network Functions | GSM A3/A8, A5 cipher algorithms |
| TS 48.008 | MSC-BSS Interface (BSSMAP) | Cipher Mode Command/Complete |
| TS 25.413 | UTRAN Iu Interface (RANAP) | Security Mode Command/Complete |
| TS 23.236 | Intra-Domain Connection of RAN Nodes to Multiple CN Nodes | NRI allocation, TMSI structure for MSC pool |
| TS 29.002 | MAP Specification | MAP SendAuthenticationInfo |