HRES

Hash RESponse

Security
Introduced in Rel-15
A cryptographic value generated by the Universal Subscriber Identity Module (USIM) during 5G Authentication and Key Agreement (AKA). The HRES is the USIM's response to a network challenge, derived from a secret key and a random number, used by the network to verify the subscriber's authenticity.

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.

Key Features

  • A 128-bit cryptographic hash of the authentication response (RES) generated by the USIM
  • Core output of the 5G AKA and EPS AKA procedures for subscriber authentication
  • Transmitted over the air instead of the plain RES to enhance subscriber privacy
  • Calculated by the Mobile Equipment (ME) using a standardized hash function (e.g., SHA-256)
  • Verified by the serving network against the HXRES received from the home network
  • Successful verification proves UE possession of the shared secret key (K) and enables subsequent key derivation

Evolution Across Releases

Rel-15 Initial

Introduced with the 5G Security Architecture (5G AKA). HRES was defined as a privacy-enhancing replacement for the plain RES used in LTE/EPC AKA. Specified the derivation of HRES in the UE as a hash of the USIM-generated RES, and the corresponding HXRES in the home network, to prevent subscriber tracking via authentication messages.

Defining Specifications

SpecificationTitle
TS 33.501 3GPP TR 33.501
TS 33.835 3GPP TR 33.835