Description
RAND, short for RANDom number, is a fundamental 128-bit parameter within the 3GPP security architecture, specifically for the Authentication and Key Agreement (AKA) mechanism. It is a cryptographically strong random or pseudo-random number generated by the network's authentication center, typically residing in the Home Subscriber Server (HSS) for LTE/5G or the Home Location Register/Authentication Centre (HLR/AuC) for 2G/3G. The primary role of the RAND is to serve as a random challenge in a challenge-response protocol. During an authentication procedure, the network sends the RAND to the User Equipment (UE) via the serving network (e.g., MME, SGSN).
Upon receipt, the UE passes the RAND to its Universal Subscriber Identity Module (USIM) application. The USIM, which shares a long-term secret key (K) with the HSS/AuC, uses this RAND along with the key K and other parameters as inputs to a set of cryptographic functions. These functions, standardized in 3GPP (like the MILENAGE algorithm suite), produce two crucial outputs: a Signed Response (SRES for 2G, RES for 3G/4G/5G) and a Cipher Key (CK) and Integrity Key (IK). The UE sends the computed RES back to the network. The network, having generated the same RAND and possessing the same secret key K, performs the identical computation. It then compares the RES received from the UE with the one it computed locally. A match proves that the UE possesses the correct secret key and is therefore authentic.
Beyond authentication, the RAND is equally vital for key derivation. The same computation that produces the RES also generates the ciphering key (CK) and integrity key (IK). These keys form the basis for all subsequent secure communication between the UE and the network for that session. They are used to derive the actual encryption and integrity protection keys for the Access Stratum (AS) and Non-Access Stratum (NAS). Thus, the randomness and unpredictability of the RAND are paramount. A weak or predictable RAND could compromise the entire authentication process, allowing for replay attacks or making it easier for an attacker to deduce the long-term secret key. The RAND ensures that each authentication instance is unique, providing freshness and preventing the reuse of previously exchanged authentication vectors.
Purpose & Motivation
The RAND exists to provide a robust challenge in a challenge-response authentication mechanism, which is central to securing cellular networks. Before standardized authentication protocols, simpler systems were vulnerable to replay attacks where an attacker could intercept and re-send a valid user response to gain access. The use of a random challenge for each authentication attempt directly addresses this vulnerability. By ensuring the challenge is different every time, a previously recorded response becomes useless to an attacker.
In the evolution from GSM to UMTS and beyond, the role of the RAND expanded. In GSM, the RAND was used with the COMP128 algorithm to generate the SRES and the Kc key. However, GSM authentication was one-way (network authenticates the UE) and had cryptographic weaknesses. The introduction of UMTS AKA, starting in Release 99, retained the RAND but integrated it into a more secure, mutual authentication framework. The RAND, combined with a sequence number (SQN) for freshness, became the input to stronger algorithms, producing separate keys for encryption and integrity. This solved the limitations of GSM's weaker cryptography and lack of integrity protection.
The motivation for its creation and continued use is the fundamental need for a non-repeating, unpredictable variable to seed the cryptographic functions that secure the network. It is the element that introduces entropy and session-specific variability into the key generation process. Without a fresh RAND for each authentication, the derived session keys could be predictable, leading to a catastrophic failure of confidentiality and integrity for user data and signaling. Its standardization ensures interoperability between equipment from different vendors and networks worldwide.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (30 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-2, normative work from Rel-15.
In Release 15, updates to USIM management procedures for 5GS were introduced, which include the enhancement of USIM OPL configuration to support 3-byte Tracking Area Codes when connected to an NG-RAN. Furthermore, the release allowed for the configuration of Mission Critical Services data and Access Identity 2 via the USIM, alongside clarifications regarding the presence of specific configuration files.
- USIM Service Table update for PDU session call control support TS 31.102CR0786
- Allow configuration of MCS (Access Identity 2) via USIM. TS 31.102CR0794
- Mission Critical Services configuration data update to USIM TS 31.102CR0808
- Enhance USIM OPL configuration to support 3 bytes TAC when in NG-RAN. TS 31.102CR0818
- Updates to USIM management procedures for 5GS TS 31.102CR0806
- Clarification about presence of EFIMSConfigData in ISIM and USIM TS 31.102CR0833
In Release 16, the enhancements for the USIM did not directly modify the RAND function itself but expanded the USIM's configuration and storage capabilities. New USIM-based configuration lists were introduced, such as for RLOS PLMN lists, URSP rules, Trusted non-3GPP access networks, and PS Data Off settings for home and roaming. Additionally, support was added for storing a separate KSEAF for non-3GPP access and for dedicated AIDs for USIM applications using non-IMSI based SUPI types.
- Add new general abbreviations MCC Note: CR cover sheet wrongly shows CR number as "1118". TS 21.905CR0118
- Support for USIM configuration of RLOS PLMN list TS 31.102CR0847
- URSP storage in USIM TS 31.102CR0861
- Specify storage for a potentially separate KSEAF for non-3gpp access on the USIM TS 31.102CR0864
- USIM configuration of RLOS allowed MCC list TS 31.102CR0881
- Support for Trusted non-3GPP access networks list by USIM TS 31.102CR0891
+ 5 more changes
In Release 17, the primary enhancement related to the RAND function was the support of an enhanced 5G-AKA sequence number re-synchronization procedure. This update improved the authentication and key agreement mechanism by refining the handling of synchronization failures between the USIM and the network. The change aimed to increase the robustness of the 5G security framework without altering the fundamental RAND parameter generation itself.
- Introduce a USIM file to store pre-configured CAG information list TS 31.102CR0904
- SOR-CMCI storage in USIM TS 31.102CR0917
- Addition of USIM files for the indication of whether disaster roaming is enabled in the UE, disaster roaming wait range, disaster return wait range and applicability indicator for disaster roaming PLMNs list provided by VPLMN. TS 31.102CR0938
- Adding eDRX parameters in the USIM for NG-RAN TS 31.102CR0943
- 5G NSWO (Non-Seamless WLAN Offload) configuration support in the USIM compromised proposal. TS 31.102CR0946
- Support of 'No E-UTRA Disabling In 5GS' in USIM TS 31.102CR0947
+ 3 more changes
In Release 18, the RAND function itself was not directly modified, but the security framework for storing its associated parameters was enhanced. The release mandated that extended storage for 5G security parameters, including authentication credentials, be enabled on the USIM under specific service conditions. This change ensures the USIM can reliably store and manage the necessary authentication parameters, like those used with RAND, for advanced 5G security procedures.
In Release 19, a key enhancement for the RAND function involved ensuring backward compatibility for USIMs that lack extended security parameter storage in the EF_5GAuthKeys file. This update specifically addresses the handling of authentication procedures when such legacy USIMs are in use. The change ensures that the generation and use of the RAND parameter remains secure and functional across different USIM implementations.
- Backward compatibility handling of USIM without extended security parameter storage in EF_5GAuthKeys - Rel19 TS 31.102CR1074
Explore further
Broader topics and technologies where RAND plays a role.
Defining Specifications
3GPP specifications that define or reference RAND, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 24.109 vj00 | HTTP Digest AKA & GAA Stage 3 | Rel-19 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 29.109 vj00 | GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) | Rel-19 |
| TS 31.102 vj40 | USIM Application Specification | Rel-19 |
| TS 31.103 vj00 | ISIM Application Specification | Rel-19 |
| TR 31.900 vj00 | 3GPP TS 31.900: Security Interworking Guidance | Rel-19 |
| TS 33.102 vj10 | 3G Security Architecture Specification | Rel-19 |
| TS 33.105 vj00 | 3G Security: Cryptographic Algorithm Requirements | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 35.205 vj00 | MILENAGE Algorithm Set: General Overview | Rel-19 |
| TR 35.934 vj00 | Tuak algorithm set for 3GPP auth & key gen | Rel-19 |