HRES

Hash RESponse

Security →
Introduced in Rel-15

HRES is a cryptographic response generated by a USIM during 5G AKA, derived from a secret key and a random network challenge to verify subscriber authenticity.

Category
Security
Introduced
Rel-15
Where
Security
Specifications
2 specs
HRES Description Purpose Detected Changes Specifications

Description

HRES (Hash RESponse) is a core output of the cryptographic functions executed by the Universal Subscriber Identity Module (USIM) during the 5G Authentication and Key Agreement (5G AKA) and EPS AKA procedures. It is a 128-bit value that serves as the subscriber's proof of possession of the shared secret key (K). The generation of HRES is a critical step in mutual authentication between the User Equipment (UE) and the network. The process begins when the network's Authentication Server Function (AUSF), via the serving network (e.g., AMF/SEAF), sends an authentication vector to the UE. This vector contains a random challenge (RAND) and an authentication token (AUTN).

The UE passes the RAND and AUTN to the USIM application. The USIM first verifies the AUTN to authenticate the network, ensuring it is communicating with a legitimate network that also possesses the correct secret key (K). If network authentication succeeds, the USIM proceeds to compute the response. Using the shared secret key (K) stored securely in the USIM and the received RAND, the USIM executes the Milenage or TUAK algorithm set. This algorithm generates several outputs, including the Cipher Key (CK), Integrity Key (IK), and the Response (RES). In 5G, for enhanced privacy, the RES is not sent over the air in plain form. Instead, the UE (specifically, the ME - Mobile Equipment) computes a hash of the RES to produce the HRES. The hash function used is defined in 3GPP TS 33.501, typically a keyed-hash or a cryptographic hash like SHA-256, depending on the context.

The HRES is then transmitted by the UE to the serving network (e.g., to the SEAF in the AMF). The network side, which originally generated the authentication vector in the Home Network (HN), holds the expected response (XRES). The HN also computes a hash of the XRES, called HXRES. The serving network receives the HRES from the UE and compares it to the HXRES received from the HN. If HRES equals HXRES, it proves that the USIM generated the correct RES, which in turn proves it possesses the valid secret key K. This completes the authentication of the subscriber. The derivation of HRES from RES is a privacy measure in 5G, as it prevents an eavesdropper from obtaining the plain RES, which could be used to track the subscriber across different serving networks.

Thus, HRES acts as a privacy-preserving authentication credential. Its correctness is the basis for the network to proceed with key derivation, establishing the secure ciphering and integrity protection keys (K_AMF, K_SEAF) that secure all subsequent NAS and RRC signaling, as well as user data. The entire process ensures that only a UE with a valid USIM and secret key can access the network, while also protecting the subscriber's long-term identity from exposure on the radio interface.

Purpose & Motivation

HRES exists as a fundamental component of the 3GPP security framework to perform subscriber authentication while addressing specific security and privacy threats. Its primary purpose is to allow the serving network to verify that the UE possesses the correct shared secret key (K) without needing to know the key itself, following the principle of authentication and key agreement (AKA). The problem it solves is proving subscriber identity in a cryptographically secure manner that resists replay attacks and eavesdropping.

The evolution from RES to HRES in 5G was motivated by privacy concerns identified in earlier generations (4G/LTE). In LTE AKA, the plain RES was sent from the UE to the network. While RES itself is a temporary value, its transmission in clear over the radio interface could potentially be used by a passive observer to fingerprint and track a subscriber as they move between different serving networks or even different cells. 5G introduced a stronger focus on subscriber identity privacy. By hashing the RES to create HRES, the value transmitted over the air is cryptographically transformed. This makes it computationally infeasible for an eavesdropper to link HRES values from different authentication sessions back to the same subscriber or to the plain RES, thereby mitigating tracking attacks.

Furthermore, HRES facilitates the separation of authentication responsibilities between the Home Network (HN) and the Serving Network (SN). The HN generates the expected response (XRES) and its hash (HXRES). It sends HXRES, not XRES, to the SN. The SN only needs to compare the received HRES with HXRES. This design prevents the SN from learning the plain RES/XRES, which adds an extra layer of security and privacy, limiting the amount of sensitive authentication data exposed to visited networks. HRES, therefore, is a key enabler of 5G's enhanced privacy features, solving the dual problems of secure authentication and subscriber untraceability in a standardized, interoperable way.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the HRES* function was newly introduced as a key component of the 5G AKA procedure for authentication in the serving network. Specifically, the SEAF is now defined to compute HRES* from the UE's RES* according to Annex A.5 and then compare it to the HXRES* received from the AUSF to determine authentication success from the serving network's point of view.

  • Clarifications on AccessToken_Get Response message TS 33.501CR0382
Rel-17 1 change

In Release 17, the key enhancement for the HRES function was the inclusion of a **Routing indicator** within the **Nudm_UEAuthentication_Get Response** from the UDM to the AUSF. This addition was specifically for subscribers with an **AKMA subscription**, complementing the existing AKMA indication. The change ensures the necessary routing information is available during authentication vector generation for procedures utilizing the HRES* comparison.

  • Add Routing indicator into the Nudm_UEAuthentication_Get Response TS 33.501CR1151

Explore further

Broader topics and technologies where HRES plays a role.

Defining Specifications

3GPP specifications that define or reference HRES, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 33.835 vg10 Study on authentication and key management for apps Rel-16