Challenge-response using symmetric keys – Entity Authentication

5.5.2 Challenge-response using symmetric keys

In challenge-response protocols using symmetric keys, the claimant and the verifier share a (typically high-entropy) secret K. An obvious approach to entity authentication is to send a nonce as a challenge RAND to the claimant and to expect the encrypted challenge as a response: RES = EK(RAND) (see Figure 5.6). Of course, the challenge numbers need to be fresh, as explained in Section 5.5.1.

Figure 5.6: Authentication based on symmetric encryption

As an example of a real-life authentication protocol based on symmetric keys, we take a look at the 4th generation (4G) mobile phone standard LTE [67]. In the LTE Authentication and Key Agreement (AKA) protocol, the home network and the user share a 128-bit symmetric key Ki. At the user’s site, the key is stored in a protected hardware location called the Universal Integrated Circuit Card (UICC). On this chip card, the same cryptographic algorithms are implemented as are used by the home network.

One of the basic problems in mobile phone communication is to allow roaming for the user, that is, using the service of a network different from the user’s home network. The goal of the LTE AKA protocol is mutual authentication between UICC and the home network and key agreement between UICC and the serving network without disclosing Ki to the serving network.

The basic process is shown (in simplified form) in Figure 5.7:

  1. The UICC sends the International Mobile Subscriber Identity (IMSI) to the Serving Network (SN).
  2. The SN transfers the IMSI to the user’s Home Network (HN).
  3. The HN generates a random challenge RAND. Based on the shared key Ki, it also computes the expected response XRES, an authentication token AUTN, and a local session key KASME by using a set of different encryption algorithms and key derivation functions. Ultimately, these functions are based on the AES algorithm.
  4. The HN bundles these parameters into a so-called authentication vector and sends it to the serving network. The serving network stores XRES and KASME and sends the challenge RAND along with AUTN to the UICC.
  5. The UICC verifies the correctness of the AUTN token and thereby authenticates the HN. If this is successful, it computes the response RES and sends it to the serving network. Based on Ki and RAND, it also computes KASME.
  6. The SN checks whether RES equals XRES. After successful authentication, both the UICC and the SN start to use KASME to protect the current call data on the air interface.

Figure 5.7: AKA protocol in LTE, the 4G mobile phone standard

Note that the SN never gets to see the shared secret Ki. It only acts as an intermediary in the authentication process, with the one exception of verifying that XRES = RES. It needs to know KASME, however, because it handles the actual communication with the mobile. Although the SN does not directly authenticate in this protocol, false base station attacks, as described in the Message authentication section in Chapter 2, Secure Channel and the CIA Triad, become impossible, as an attacker posing as a legitimate SN would not be able to obtain an authentication vector from the HN.

The session key KASME is used to derive confidentiality and integrity keys for the ongoing call. LTE also offers partial anonymity by creating temporary user identities, but for bootstrapping the AKA protocol, the IMSI has to be sent in cleartext at least once. In 5G networks, the user ID is always encrypted with the public key of the home network [157].