WiMAX: Technology for Broadband Wireless Access

2017-07-07 02:10:07

15.3 Data Encryption

Encryption ea:l be applied to the MAC PDU payload. The generic MAC header is never encrypted. All MAC management messages are sent in the clear to facilitate registration, ranging and normal operation of the MAC Layer ^[2]. Op.ly the secondary management connnections and the transport connections are encrypted.

The PKM protocol uses X.509 digital certificates, the RSA public key encryption algoorithm and strong encryption algorithms to perform key exchanges between the SS and the BS. After the use of PKM as a public key cryptography to establish a shared secret (the AK) between the SS and the BS, this shared secret is used to secure further PKM exchanges of TEKs (Traffic Encryption Keys). The AK is used for the generation of a Key Encryption Key (KEK) and message authentication keys as now described. The main operation is that the SS asks the BS for encryption keys (see Figure 15.7). The use of the shared secret, AK, for a two-tiered mechanism for key distribution (described in the following section) permits TEKs to be refreshed without incurring the overhead of computation intensive operations.

Figure 15.7: The SS asks the BS for encryption keys TEK0 and TEK1

15.3.1 Generation of Encryption Keys

At each instant, the BS maintains two sets of active generations of keying material per SA (or, equivalently, per SAID). A set of keying material includes a TEK and its corresponding initialisation vectors (depending of the encryption algorithm). As for the AK. one set corresponds to the older generation of keying material while the second set corresponds to the newer generation of keying material. The BS distributes both generations of active keying material to a client SS. This is done after the SS has requested a TEK with a Key Request message. The Key Reply message contains two TEK parameter attributes, each containing the keying material for one of the SAID's two active sets of keying material.

The BS uses the two active TEKs differently, depending on whether the TEK is used for downlink or uplink traffic. For each of its SAIDs, the BS uses the two active TEKs according to the following rules (illustrated in Figure 15.8):

The BS uses the older of the two active TEKs for encrypting downlink traffic.

The BS decrypts the uplink traffic using either the older or newer TEK. depending on which of the two keys the SS uses at the time.

Figure 15.9 illustrates the BS management of an SA TEK, where the shaded portion of a TEK's lifetime indicates the time period during which that TEK is used to encrypt MAC PDU payloads. As for AKs, TEKs have a limited lifetime and must be periodically refreshed. At expiration of the older TEK, the BS uses the newer TEK for encryption. It is the responsibility of the SS to update its keys in a timely fashion. The BS uses a KEK when encrypting the TEK in the Key Reply (PKM-RSP) MAC management message. The TEK is encrypted with one of the following algorithms, using the KEK: 3-DES, RSA or AES. The TEK encryption algorithm is indicated by the TEK encryption algorithm identifier in the cryptographic suite of the SA.

Figure 15.9: Traffic Encryption Keys (TEKs) management

A random or pseudo-random number generator is used by the BS to generate KEKs and TEKs. The standard ^[1] states that recommended practices for generating random numbers for use within cryptographic systems are provided in IETF RFC 1750 ^[53]. As a remark. it should be pointed out that IETF RFC 1750 has been replaced (by the IETF) by IETF RFC 4086 ^[54]. For the 3-DES KEK, the 802.16 standard defines the following method ^[1]:

K_PAD_ = 0 × 53 repeated 64 times, i.e. a 512-bit string,

KEK = Truncate (SHA(K_PAD_KEK | AK),128),

here

Truncate (x,n) denotes the result of truncating x to its leftmost n bits, SHA(x|y) denotes the result of applying the SHA-1 function (^[49]) to the concatenated bit strings x and y.

The keying material of 3-DES consists of two distinct DES keys. The 64 most significant bits of the KEK are used in the encrypt operation. The 64 least significant bits are used in the decrypt operation.

The HMAC authentication keys are derived as follows:

HMAC_KEY_D = SHA(H_PAD_D|AK),

HMAC_KEY_U = SHA(H_PAD_U|AK),

HMAC_KEY_S = SHA(H_PAD_D|Operator Shared Secret),

where

H_PAD_D = 0x3A repeated 64 times and H_PAD_U = 0x5C repeated 64 times.

The exchange of AK and the exchange of Traffic Encryption Keys (TEKs) takes place for each SA.

The Operator Shared Secret is a Mesh mode key known by all Mesh mode nodes.

15.3.2 Generation of Encryption Keys in the 802.16e Amendment

As for PKMv1, the PKMv2 protocol uses the TEK and KEK for the encryption of data flows. The KEK is used to encrypt the TEK, GKEK and all other keys sent by the BS to the SS in a unicast message.

15.3.2.1 TEK and KEK

The procedure is the same as for PKMv1 (see the previous section).

15.3.2.2 Multicast Encryption

There is one GKEK per Group Security Association. This GKEK is used to encrypt the GTEKs sent in multicast messages by the BS to the MSs in the same multicast group. It is used to encrypt multicast data packets and it is shared by all the MSs in the multicast group. The GKEK is randomly generated by the BS and encrypted using the same algorithms applied for TEK encryption.

15.3.2.3 Multicast and Broadcast Service Traffic Key

Like the other traffic keys, the MTK is used to encrypt the MBS traffic data. The MGTEK is the GTEK for the MBS. The key generation process in PKMv1 and PKMv2 is summarised in Figure 15.10.

Figure 15.10: Illustration of the key generation process in PKMv1 and PKMv2. (Figure by M. Boutin, M. Jubin and L. Nuaymi.)

15.3.3 Traffic Encryption Keys and Handover

In this section, 802.16e security is considered. The exchange of the SAs and TEK (Traffic Encryption Key) parameters associated with an MS is based on a three-way handshake. This procedure is launched once an authentication event occurs or in the case of a handover:

During initial network entry or reauthorisation (handover) the BS sends PKMv2 SA-TEK-Challenge.

The MS sends PKMv2 SA-TEK-Request upon receipt of the PKMv2 SA-TEK-Challenge message.

To complete the transfer, the BS sends PKMv2-SA-TEK-Response back to the MS.

In the case of a handover, the process can be optimised and the first step may be avoided. Additionally, for each active SA in a previous serving BS, the corresponding TEK, GTEK and GKEK parameters are also included in the new SA. This can be done using the SA-TEK-Update method, which gives the matching between the new SA and the old SA.

15.3.4 Traffic Encryption Algorithms

The MAC PDU payload is encrypted using the active TEK (or GTEK or MTK). The data encryption algorithm is indicated by the data encryption algorithm identifier in the cryptographic suite of an SA. The EC (Encryption Control) bit in the generic MAC header indicates whether the MAC PDU payload is encrypted or not. The generic MAC header is not encrypted. Basic and primary MAC management messages are also not encrypted. However, some of the MAC management messages are authenticated, as described in Section 15.4.

The 802.16-2004 standard included two well-known data encryption algorithms for the encryption of the MAC PDU payloads: DES-CBC and AES-CCM.

15.3.4.1 DES-CBC

The Data Encryption Standard (DES) algorithm (^[42]) is included in its Cipher Block Chaining (CBC) mode, shown in Figure 15.11. The DES algorithm provides a 56-bit key encryption and is mandatory in 802.16 equipment (according to 802.16-2004).

Figure 15.11: DES algorithm in its CBC mode

The CBC IV (Initialisation Vector) of CBC-DES is calculated as follows:

In the downlink, the CBC is initialised with the exclusive-or (XOR) of the IV parameter included in the TEK keying information and the content of the PHY synchronisation field (8 bits, right justified) of the latest DL-MAP. The Encryption Key Sequence (EKS), which is a 2-bit field in the generic MAC header (see Chapter 8), is the index of the TEK and IV used to encrypt the payload.

In the uplink, the CBC is initialised with the XOR of the IV parameter included in the TEK keying information and the content of the PHY synchronisation field of the DL-MAP which is in effect when the UL-MAP for the uplink transmission is created/received.

15.3.4.2 AES-CCM

The Advanced Encryption Standard (AES) is included in its counter with CBC-MAC (CCM) mode ^[55]. The AES algorithm is a 128-bit key encryption. The AES is more secure than the DES (and the 3-DES also). However, the AES is more complex and a little slower than the DES.

Figure 15.12 shows the AES-CCM generated payload (and then the transported payload). The plaintext PDU is encrypted and authenticated using the active TEK, according to the AES-CCM specification. Before the encrypted data, a 4-byte PN (Packet Number) field is added. This field is linked to the SA and incremented for each PDU transmitted. This is a parade against the replay attack. The replay attack is when some valid packets are replayed by an attacker in order to cause some damage by reproducing an action. Any PN that is received more than once is discarded as a replay attempt. The ciphertext Message Authentication Code, also known as MAC (not to be confused with the Medium Access Layer; see the following section for the Message Authentication Code), is transmitted such that byte index 0 (as enumerated in the AES specification) is transmitted first and byte index 7 is transmitted last (i.e. LSB first). The PN is not encrypted but is included in the message integrity check (Message Authentication Code) calculation.

Figure 15.12: Encrypted payload format in the AES-CCM mode. (Based on Reference ^[2].)

15.3.5 Traffic Encryption Algorithms Added in the 802.16e Amendment

The 802.16e amendment added the following encryption algorithms:

AES in Counter (CTR) mode ^[56] for MBS;

AES in CBC mode;

AES KeyWrap with a 128-bit key. The AES key wrap encryption algorithm accepts both a ciphertext and an integrity check value. The decryption algorithm returns a plaintext key and the integrity check value.

One or more of the 802.16 defined encryption algorithms can be mandatory in WiMAX profiles.

^[53]IETF RFC 1750, Randomness Recommendations for Security, D. Eastlake et al., December 1994.

^[54]IETF RFC 4086, Randomness Requirements for Security, D. Eastlake et al., June 2005.

^[55]IETF RFC 3610, Counter with CBC-MAC (CCM), D. Whiting et al., September 2003.

^[56]IETF RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode with IPsec Encapsulating Security Payload (ESP), R. Housley et al., January 2004.