A wireless system uses the radio channel, which is an open channel. Hence, security procedures must be included in order to protect the traffic confidentiality and integrity and to prevent different network security attacks such as theft of service. The IEEE 802.16 MAC layer contains a security sublayer (see the protocol layers in Chapter 3). This sublayer and its main procedures are described in this chapter.
The Privacy Key Management (PKM) protocol, later known as PKMvl, is included in the 802.16-2004 standard security sublayer in order to provide secure distribution of keying data from the BS to the SS. In addition, PKM is used to apply conditional access to network services, making it the authentication protocol, protecting them from theft of service (or service hijacking) and providing a secure key exchange. Many ciphering (data encryption) algorithms are included in the 802.16 standard security sublayer for encrypting packet data across the 802.16 network.
The Security sublayer has been redefined in the IEEE 802.16e amendment mainly due to the fact that 802.16-2004 had some security holes (e.g. no authentication of the BS) and that the security requirements for mobile services are not the same as for fixed services. The Security sublayer has two main component protocols as follows:
A data encapsulation protocol for securing packet data across the fixed BWA network. This protocol defines a set of supported cryptographic suites, i.e. pairings of data encryption and authentication algorithms, and the rules for applying those algorithms to a MAC PDU payload.
A key management protocol (PKM) providing the secure distribution of keying data from the BS to the SS. Through this key management protocol, the SSs and BSs synchronise keying data. In addition, the BS uses the protocol to enforce conditional access to network services. The 802.16e amendment defined PKMv2 with enhanced features.
The Security sublayer of WiMAX as it has been redefined in the IEEE 802.16e is shown in Figure 15.1. The elements of this figure will be described in this chapter, where an SS is sometimes denoted MS (as elsewhere in this book).
Many encryption algorithms are included in the 802.16 standard Security sublayer. They can be used for securing ciphering key exchange and for the encryption of transport data. Some of these algorithms are optional for some applications.
The encryption algorithms included in 802.16 are:
RSA (Rivest Shamir Adleman) [41]. RSA is a public-key asymmetric encryption algorithm used to encrypt the Authorisation Reply message using the SS public key. The Authorisation Reply message includes the Authorisation Key (AK). RSA may also be used for the encryption of traffic encryption keys when these are transmitted from the BS to the SS.
DES (Data Encryption Standard) [42]. The DES and 3-DES are shared(secret)-key encryption algorithms. The DES algorithm may be used for traffic data encryption. It is mandatory for 802.16 equipment. The 3-DES algorithm can be used for the encryption of the traffic encryption keys.
AES (Advanced Encryption Standard) [43]. The AES algorithm is a shared(secret)-key encryption algorithm. The AES algorithm may be used for traffic data encryption and can also be used for the encryption of the traffic encryption keys. Its implementation is optional.
Cryptographic algorithms are also included in 802.16:
HMAC (Hashed Message Authentication Code) [44],[45] and CMAC (Cipher-based Message Authentication Code) [46]. HMAC and CMAC are used for message authentication and integrity control.
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first published in 1988 as part of the X.500 directory recommendations, defines a standard certificate format [47] used in IETF RFC 3280 [48], itself used in the 802.16 standard (citing RFC 2459 of the IETF).
The 802.16 standard states that 802.16-compliant SSs must use X.509 Version 3 certificate formats providing a public key infrastructure used for secure authentication. Each SS carries a unique X.509 digital certificate issued by the SS manufacturer, known as the SS X.509 certificate. More exactly, this certificate is issued (and signed) by a Certification Authority (CA) and installed by the manufacturer. This digital certificate contains the SS RSA public key and the SS MAC address.
Each SS has a manufacturer-issued X.509 manufacturer CA certificate issued by the manufacturer or by an external authority. The manufacturer's public key is then placed in this X.509 manufacturer CA certificate, which in turn is signed by a higher-level CA. This higher-level CA does not seem to be clearly defined in the present version of the standard. There are then two types of X.509 certificates: SS X.509 certificates and the X.509 manufacturer CA certificate. In the 802.16-2004 standard, there is an X.509 certificate for the BS.
The main fields of the X.509 certificate are the following:
The X.509 certificate version is always set to v3 when used in the 802.16 standard.
The certificate serial number is a unique integer the issuing CA assigns to the certificate.
The signature algorithm is an object identifier and optional parameters defining the algorithm used to sign the certificate.
The signature value is the digital signature computed on the ASN.1 DER encoded tbsCertificate (‘to be signed Certificate’). The standard states that the RSA signature algorithm with SHA-1 (Secure Hash Algorithm), [49] is employed for both defined certificate types.
The certificate issuer is the Distinguished Name (DN) of the CA that issued the certificate.
The certificate validity is when the certificate becomes active and when it expires.
The certificate subject is the DN identifying the entity whose public key is certified in the subject public key information field. The country name, organisation name and manufacturing location are attributes of the certificate subject. Another attribute is the company name for the CA or, for the SS, its 48-bit universal MAC address (see Chapter 8) and its serial number. This MAC address is used to identify the SS to the various provisioning servers during initialisation.
The Certificate Subject Public Key Info Field contains the public key material (public key and parameters) and the identifier of the algorithm with which the key is used. This is the main content of the X.509 certificate.
Optional fields allow reuse of issuer names over time.
The certificate extensions are extension data.
The BS uses the X.509 certificate public key of an SS in order to verify the authenticity of this certificate and then authenticates the SS. This is done using the PKM protocol (see Section 15.2 below). This security information also authenticates the responses received by the SS.
802.16 standard security uses many encryption keys. The encryption keys defined in 802.16-2004 are listed in Table 15.1 where the notation and the number of bits in each key are given. A nonexhaustive list of the keys used in the PKMv2 protocol, taking into account the 802.16e amendment, is proposed in Table 15.2.
Encryption key |
Notation |
Number of bits |
Description |
---|---|---|---|
Authorisation Key |
AK |
160 |
Authentication of an SS by its BS. Shared secret used to secure further transactions and generating encryption keys.Lifetime between 1 and 70 days |
Key Encryption Key |
KEK |
128 |
3-DES key used for the encryption of the TEK |
Traffic Encryption Key |
TEK |
128 |
Data encryption key. Lifetime between 30 min and 7 days |
HMAC Key for the Downlink |
HMAC_KEY_D |
160 |
Used for authenticating messages in the downlink direction |
HMAC Key for the Uplink |
HMAC_KEY_U |
160 |
Used for authenticating messages in the uplink direction |
HMAC Key in the Mesh mode |
HMAC_KEY_S |
Used for authenticating messages in the Mesh mode |
Name |
Signification |
PKM version |
Notes |
---|---|---|---|
PMK |
Pairwise Master Key |
2 |
Obtained from EAP authentication |
PAK |
Primary Authorisation Key |
2 |
Obtained from RSA-based authorisation |
AK |
Authorisation Key |
1 and 2 |
Alithcntication between an SS and a BS. In the case of PKMv2, derived from PMK or PAK |
KEK |
Key Encryption Key |
1 and 2 |
Used for encryption of TEK |
TEK |
Traffic Encryption Key |
1 and 2 |
Used for data encryption |
GKEK |
Group Key Encryption Key |
2 |
Used for encryption of GTEK |
GTEK |
Group Traffic Encryption Key |
2 |
Used for multicast data packets encryption |
MAK |
MBS Authorisation Key |
2 |
Authentication for MBS |
MGTEK |
MBS Group Traffic Encryption Key |
2 |
Used to generate MTK with the MAK |
MTK |
MBS Traffic Key |
2 |
Protects MBS Traffic. Derived from MAK and MGTEK |
H/CMAC/KEY_D |
1 and 2 |
Assures message integrity for the downlink |
|
H/CMAC_KEY_U |
1 and 2 |
Assures message integrity for the uplink |
The standard defines a Security Association (SA) as a set of security information a BS and one or more of its client SSs (or MSs) share in order to support secure communications. An SA's shared information includes the Cryptographic Suite employed within the SA. A Cryptographic Suite is the SA's set of methods for data encryption, data authentication and TEK exchange. The exact content of the SA is dependent on the SA's Cryptographic Suite: encyption keys, keys lifetime, etc. The Security Association Identifier (SAID) is a 16-bit identifier shared between the BS and the SS that uniquely identifies an SA. There are three types of security associations: the SA for unicast connections, the Group Security Association (GSA) for multicast groups and the MBS Group Security Association (MBSGSA) for MBS services.
The SAs are managed by the BS. When an authentication event takes place the BS gives the SS a list of Security Associations associated with its connections. Generally, an SS has a Security Association (‘primary’ association) for its secondary management connection and two more for the downlink and the uplink links. After that, the BS may indicate one or more new SAs to the SS.
Static SAs are provisioned within the BS. Dynamic SAs are created and deleted as required in response to the initiation and termination of specific service flows.
[2]IEEE 802.16e, IEEE Standard for Local and Metropolitan Area Networks, Air Interface for Fixed Broadband Wireless Access Systems, Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, February 2006 (Approved: 7 December 2005).
[41]PKCS #1 v2.0, RSA Cryptography Standard, RSA Laboratories, October 1998.
[42]National Technical Information Service (NTIS), FIPS 46–3, Data Encryption Standard (DES), October 1999; http://www.ntis.gov/.
[43]National Technical Information Service (NTIS), FIPS 197, Advanced Encryption Standard (AES), November 2001.
[44]National Technical Information Service (NTIS), FIPS 198, The Keyed-Hash Message Authentication Code (HMAC), March 2002.
[45]IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication, H. Krawczyk, M. Bellare and R. Canetti, February 1997.
[46]IETF RFC 4493, The AES-CMAC Algorithm, J.H. Song et al., June 2006.
[47]ITU-T Recommendation X.509 (1997 E), Information technology - open systems interconnection - the directory: authentication framework, June 1997.
[48]IETF RFC 3280, Internet X.S09 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (eds R. Housley et al.,) April 2002.
[49]National Technical Information Service (NTIS), FIPS 180–1, Secure Hash Standard (SHA-1), April 1995.