05-04-2011, 09:37 AM
KEY CRYPTO GRAPHY
802.1i
Phase 1: Agreeing on the security policy
• supported authentication methods (802.1X, Pre-Shared Key (PSK)),
• Security protocols for unicast traffic (CCMP, TKIP etc.) – the pair wise cipher suite,
• Security protocols for multicast traffic (CCMP, TKIP etc.) – the group cipher suite,
• Support for pre-authentication, al- lowing users to pre-authenticate
Before switching to a new access point of the same network for a seamless handover.
Phase 2: 802.1X authentication
The second phase is 802.1X authentication based on EAP and the specific authentication method agreed earlier: EAP/TLS with client and server certificates (requiring a public key infrastructure), EAP/TTLS or PEAP for hybrid authentication (with certificates only required for servers) etc. 802.1X authentication are initiated when the access point requests client identity data, with the client’s response containing the preferred authentication method. Suitable messages are then exchanged between the client and the authentication server to generate a common master key (MK). At the end of the procedure, a Radius Accept message is send from the authentication server to the access point, containing the MK and a final EAP Success message for the client.
Phase 3: Key hierarchy and distribution
Connection security relies heavily on secret keys. In RSN, each key has a limited lifetime and overall security is ensured using a collection of various keys, organized into a hierarchy. When a security context is stab- lashed after successful authentic- tin, temporary (session) keys are created and regularly updated until the security context is closed. Key generation and exchange is the goal of the third phase.
• confirm the client’s knowledge of the PMK,
• derive a fresh PTK,
• install encryption and integrity keys,
• encrypt transport of the GTK,
• confirm cipher suite selection.
Phase 4: RSNA data confidentiality and integrity
All the keys generated previously are used in protocols supporting RSNA data confidentiality and integrity:
• Temporal Key Hash
• Counter-Mode / Cipher Block Chaining Message Authentication Code Protocol
• Wireless Robust Authenticated Protocol
An important concept must be understood before detailing these protocols: the difference between an MSDU (MAC Service Data Unit) and an MPDU (MAC Protocol Data Unit). Both refer to a single packet of data, but MSDU represents data before fragmentation, while MPDUs are the multiple data units after fragmentation. The difference is important in TKIP and CCMP encryption, since in TKIP the MIC is calculated from the MSDU, while in CCMP it is calculated from the MPDU.
The TKIP Key-Mixing Scheme is divided into two phases. Phase 1 involves static data – the secret session key TEK, the transmitter MAC address TA (included to pre- vent IV collisions) and the higher 32 bits of the IV. Phase 2 includes the output of Phase 1 and the lower 16 bits of the IV, changing all the bits of the Per Packet Key field for each new IV. The IV value always starts with 0 and is incremented by 1 for each packet sent, with any messages whose TSC is not greater than the last message being discarded. The output of Phase 2 and part of the extended IV (plus a dummy byte) are the input for RC4, generating a key stream that is XOR-end with the plaintext MPDU, the MIC calculated from the MPDU and the old ICV from WEP. MIC computation uses the Michael algorithm by Niels Ferguson. It was created for TKIP and has a target security level of 20 bits (the algorithm doesn’t use multiplication for performance reasons, as it must be supported on old wire- less hardware later to be upgraded to WPA). Due to this limitation, countermeasures are needed to avoid MIC forgery. MIC failures must be kept below two per minute, otherwise a 60 second blackout is enforced and new keys (GTK and PTK) must be established afterwards. Michael computes an 8-octet check value called the MIC and appends it to the MSDU prior to transmission. The MIC is calculated from the source address (SA), destination address (DA), plaintext MSDU and the appropriate TMK (depending on the communication side, a different key is used for transmission and reception).
CCMP is based on the AES (Advanced Encryption Standard) block cipher suite in its CCM mode of operation, with the key and blocks being 128 bits long. AES is to CCMP what RC4 is to TKIP, but unlike TKIP, which was intended to accommodate existing WEP hard- ware, CCMP isn't a compromise, but a new protocol design. CCMP uses counter mode in conjunction with a message authentication method called Cipher Block Chaining (CBC-MAC) to produce an MIC.
Some interesting features were also added, such as the use of a single key for encryption and authentication (with different initialization vectors) or covering non-encrypted data by the authentication. The CCMP protocol adds
16 bytes to the MPDU: 8 bytes for the CCMP header and 8 bytes for the MIC. The CCMP header is an unencrypted field included between the MAC header and encrypted data, including the 48-bit PN (Packet Number = Extended IV) and Group Key Key ID. The PN is incremented by one for each sub- sequent MPDU.
MIC computation uses the CBC-MAC algorithm that encrypts a starting nonce block (computed from the Priority fields, MPDU source address and incremented PN) and XORs subsequent blocks to obtain a final MIC of 64 bits (the final MIC is a 128-bit block, since the lower 64 bits are discarded). The MIC is then appended to the plaintext data for AES encryption in counter mode. The counter is constructed from a nonce similar to the MIC one, but with an extra counter field initialized to 1 and incremented for each block.
The last protocol is WRAP, also based on AES, but using the OCB (Offset Codebook Mode) authenticated encryption scheme (encryption and authentication in a single computation). OCB was the first mode selected by the IEEE 802.11i working group, but was eventually abandoned due to intellectual property issues and possible licensing fees. CCMP was then adopted as mandatory
802.1i
Phase 1: Agreeing on the security policy
• supported authentication methods (802.1X, Pre-Shared Key (PSK)),
• Security protocols for unicast traffic (CCMP, TKIP etc.) – the pair wise cipher suite,
• Security protocols for multicast traffic (CCMP, TKIP etc.) – the group cipher suite,
• Support for pre-authentication, al- lowing users to pre-authenticate
Before switching to a new access point of the same network for a seamless handover.
Phase 2: 802.1X authentication
The second phase is 802.1X authentication based on EAP and the specific authentication method agreed earlier: EAP/TLS with client and server certificates (requiring a public key infrastructure), EAP/TTLS or PEAP for hybrid authentication (with certificates only required for servers) etc. 802.1X authentication are initiated when the access point requests client identity data, with the client’s response containing the preferred authentication method. Suitable messages are then exchanged between the client and the authentication server to generate a common master key (MK). At the end of the procedure, a Radius Accept message is send from the authentication server to the access point, containing the MK and a final EAP Success message for the client.
Phase 3: Key hierarchy and distribution
Connection security relies heavily on secret keys. In RSN, each key has a limited lifetime and overall security is ensured using a collection of various keys, organized into a hierarchy. When a security context is stab- lashed after successful authentic- tin, temporary (session) keys are created and regularly updated until the security context is closed. Key generation and exchange is the goal of the third phase.
• confirm the client’s knowledge of the PMK,
• derive a fresh PTK,
• install encryption and integrity keys,
• encrypt transport of the GTK,
• confirm cipher suite selection.
Phase 4: RSNA data confidentiality and integrity
All the keys generated previously are used in protocols supporting RSNA data confidentiality and integrity:
• Temporal Key Hash
• Counter-Mode / Cipher Block Chaining Message Authentication Code Protocol
• Wireless Robust Authenticated Protocol
An important concept must be understood before detailing these protocols: the difference between an MSDU (MAC Service Data Unit) and an MPDU (MAC Protocol Data Unit). Both refer to a single packet of data, but MSDU represents data before fragmentation, while MPDUs are the multiple data units after fragmentation. The difference is important in TKIP and CCMP encryption, since in TKIP the MIC is calculated from the MSDU, while in CCMP it is calculated from the MPDU.
The TKIP Key-Mixing Scheme is divided into two phases. Phase 1 involves static data – the secret session key TEK, the transmitter MAC address TA (included to pre- vent IV collisions) and the higher 32 bits of the IV. Phase 2 includes the output of Phase 1 and the lower 16 bits of the IV, changing all the bits of the Per Packet Key field for each new IV. The IV value always starts with 0 and is incremented by 1 for each packet sent, with any messages whose TSC is not greater than the last message being discarded. The output of Phase 2 and part of the extended IV (plus a dummy byte) are the input for RC4, generating a key stream that is XOR-end with the plaintext MPDU, the MIC calculated from the MPDU and the old ICV from WEP. MIC computation uses the Michael algorithm by Niels Ferguson. It was created for TKIP and has a target security level of 20 bits (the algorithm doesn’t use multiplication for performance reasons, as it must be supported on old wire- less hardware later to be upgraded to WPA). Due to this limitation, countermeasures are needed to avoid MIC forgery. MIC failures must be kept below two per minute, otherwise a 60 second blackout is enforced and new keys (GTK and PTK) must be established afterwards. Michael computes an 8-octet check value called the MIC and appends it to the MSDU prior to transmission. The MIC is calculated from the source address (SA), destination address (DA), plaintext MSDU and the appropriate TMK (depending on the communication side, a different key is used for transmission and reception).
CCMP is based on the AES (Advanced Encryption Standard) block cipher suite in its CCM mode of operation, with the key and blocks being 128 bits long. AES is to CCMP what RC4 is to TKIP, but unlike TKIP, which was intended to accommodate existing WEP hard- ware, CCMP isn't a compromise, but a new protocol design. CCMP uses counter mode in conjunction with a message authentication method called Cipher Block Chaining (CBC-MAC) to produce an MIC.
Some interesting features were also added, such as the use of a single key for encryption and authentication (with different initialization vectors) or covering non-encrypted data by the authentication. The CCMP protocol adds
16 bytes to the MPDU: 8 bytes for the CCMP header and 8 bytes for the MIC. The CCMP header is an unencrypted field included between the MAC header and encrypted data, including the 48-bit PN (Packet Number = Extended IV) and Group Key Key ID. The PN is incremented by one for each sub- sequent MPDU.
MIC computation uses the CBC-MAC algorithm that encrypts a starting nonce block (computed from the Priority fields, MPDU source address and incremented PN) and XORs subsequent blocks to obtain a final MIC of 64 bits (the final MIC is a 128-bit block, since the lower 64 bits are discarded). The MIC is then appended to the plaintext data for AES encryption in counter mode. The counter is constructed from a nonce similar to the MIC one, but with an extra counter field initialized to 1 and incremented for each block.
The last protocol is WRAP, also based on AES, but using the OCB (Offset Codebook Mode) authenticated encryption scheme (encryption and authentication in a single computation). OCB was the first mode selected by the IEEE 802.11i working group, but was eventually abandoned due to intellectual property issues and possible licensing fees. CCMP was then adopted as mandatory
