User:Pointdexter5/sandbox
Advanced Encryption Standard-Counter Cipher Mode with Block Chaining Message Authentication Code Protocol or AES-CCMP (CCM mode Protocol) is an encryption protocol designed for Wireless LAN products that implement the standards of the IEEE 802.11i amendment (Clause 8.3.3 [1]) to the original IEEE 802.11 standard. CCMP, originally defined in IETF RFC 3610 [2] is an enhanced data cryptographic encapsulation mechanism designed for data confidentiality and based upon the Counter Mode with CBC-MAC (CCM) of the AES standard[3]. The Advanced Encryption Standard (AES) standard[3] was originally defined in US FIPS PUB 197 [4], and was created to address the vulnerabilities presented by WEP, a dated, insecure protocol.[3]
Abbreviations
[edit]The abbreviation AES-CCMP is derived from other acronyms used in the 802.11 world. The following list shows the acronyms making up AES-CCMP:
AES: Advanced Encryption Standard.
CTR: Counter Mode. One of the modes defined under AES and used for confidentiality.
CBC-MAC: Cipher Block Chaining - Message Authentication Code. Another mode defined under AES and used for message integrity.
CCM: Abbreviation for CTR/CBC-MAC, a mode of AES combining CTR and CBC-MAC to achieves both confidentiality and message integrity.
CCMP: The CCM Protocol, also referred to as the CTR/CBC-MAC Protocol. This protocol is used by the security algorithm applied in 802.11i. [5]
CCMP data block
[edit]While AES allows for varying key lengths and block lengths, CCMP uses a 128-bit key with a 128-bit block length. For every session, CCM requires a new AES Temporal Key (TK), and additionally requires a unique nonce value for every frame protected by a TK. To address this, CCMP uses a 48-bit Packet Number (PN), which is an incrementing counter to avoid packet replay. The PN is part of the nonce value, as well as the Destination Address (Address 2 in the MAC header) and the Priority field (from the MAC header). The incremental PN ensures the input to CCM varies with every packet. To avoid compromise, a PN should not be re-used with the same TK. The 128-bit CCMP data block, also referred to as the MPDU (MAC Protocol Data Unit) will look as follows: [5][6]
.JPG)
The CCMP header used in the algorithm consists of eight octets, an increase of four octets compared to WEP. The presence of the extra 4 octets is indicated by setting the Extended IV bit to “1”. The PN is split into two grouping of octets, where the least two significant octets (bytes 1 through 0) are placed at the beginning of the CCMP header. The header further consists of a Zero Reserved Octet, the Key ID Octet, which contains the Extended IV bit and the Key ID bits; and the four most significant octets of the PN (bytes 5 through 2). With the CCMP header being in the clear part of the MPDU data block, the PN is represented completely in the clear, and in little-endian order.[5][6]
The MPDU data block’s encrypted area contains the data to be transmitted and an eight-octet Message Integrity Check (MIC). The TK used for the MIC calculation is the same as the TK used for the MPDU. As part of the MIC calculation, the IV information is used, the PN, and other data from the packet header. The IV value is used as input to an AES block, after which it’s output is X-ORed with select elements (128 bits) from the packet header, which is used as input again for another AES block. This procedure is repeated over the remainder of the packet header and length of packet data until a final 128-bit CBC-MAC value is achieved. Only the upper 64 bits of this CBC-MAC value are used for the final MIC.[7]
CCMP encapsulation
[edit]The process of encrypting the data and wrapping it with headers is referred to as encapsulation. The CCMP encapsulation process provides confidentiality (CTR mode), integrity (CBC-MAC mode) and replay prevention. The confidentiality is ensured by the strength of the CTR mode, and by protecting the key. Integrity is achieved by including a MIC at the end of the encrypted ported of the MPDU, which further includes protection from replay attacks. The MIC calculation is performed using the data and portions of the MAC header, referred to as the Additional Authentication Data (AAD). By including this non-encrypted data as part of the MIC calculation, it prevents this data from being modified in transit. The AAD content is shown in image x. The 2-octed Duration field is excluded from the AAD, while specific bits in the Frame Control and Sequence control are set to 0 or 1. [5]
In generic CCM, two parameters are used as input to the algorithm. The first parameter is M, which reflects the size of the authentication field, with valid values of 4, 6, 8, 10, 12, 14 and 16 octets. The second parameter is L, indicating the size of the length field, with valid values between 2 and 8 octets (L=1 is a reserved value). Additionally, the TK and a nonce of 15-L octets are used as input. [8]
The following image shows the complete CCMP Encapsulation process:
The image can be interpreted as follows. The AAD is created from the MAC header. Additional data from the MAC header is used combined with the PN to build the nonce. The AAD, nonce, the TK and MPDU plaintext data are inputs into the CCM algorithm (using the parameters L & M). The output of the algorithm is the encrypted data and the MIC. Once the CCMP header is created based in the PN, it is placed in front of the encrypted data. To finish the packet before transmission, the MAC header is placed at the front of the data packet. [5]
CCMP decapsulation
[edit]When the data packet arrives at its destination, the MAC header is extracted as well as the PN from the CCMP header. The PN is evaluated to see if it is not a replayed packet. Once this is verified, the nonce and AAD are calculated. Since senders and receivers of data packets use key management, the TK is already known at the receiving end, so the receiver can use this TK along with the nonce and AAD as inputs to the CCM algorithm to decrypt the data. The MIC is then recalculated to be compared to the MIC sent in the data packet. If the MIC calculated does not match up with the MIC sent, the message has been modified and is to be disregarded. No derived data is to be shared, to protect the algorithm. With a 64-bit MIC value, chances of forging the MIC are 1 in 1019, which ensures integrity of the message. [5] [6] [8]
The following image shows the complete CCMP Decapsulation process:
Restrictions
[edit]The limit of data which the CCM algorithm can process with a single key cannot exceed 2^61 block cipher encryption operations. This corresponds with about 2^64 octets or around 16 million terabytes to be encrypted and authenticated. While this number suffices in most applications, senders need to ensure this limit is not exceeded, even in instances where this limit may be reached.[8]
References
[edit]- ^ IEEE 802.11i-2004: Amendment 6: Medium Access Control (MAC) Security Enhancements (pdf), IEEE Standards, 2004-07-23, p. 72, retrieved 2012-07-31
- ^ "Counter with CBC-MAC (CCM)". IETF - Network Working Group. September 2003. Retrieved 2012-08/04.
{{cite web}}: Check date values in:|accessdate=(help) - ^ a b c Cole, Terry (12 June 2007). "IEEE Std 802.11-2007" (PDF). New York, New York: The Institute of Electrical and Electronics Engineers, Inc. Retrieved 11 April 2011. Cite error: The named reference "802.11 2007" was defined multiple times with different content (see the help page).
- ^ "Federal Information Processing Standards Publication 197" (PDF). National Institute of Standards and Technology (NIST). 26 November 2011. Retrieved 2012-08-31.
- ^ a b c d e f "Encryption Protocols". etutorials. Retrieved 2012-08-04. Cite error: The named reference "etutorials" was defined multiple times with different content (see the help page).
- ^ a b c Garg, Akshay. [http http://www.freewebs.com/akshaygarg/802.11i.pdf "IEEE 802.11: Security"] (PDF). freewebs. Retrieved 2012-08-04.
{{cite web}}: Check|url=value (help) - ^ Eaton, Dennis. "Diving into the 802.11i Spec: A Tutorial". eetimes.
- ^ a b c "Counter with CBC-MAC (CCM)". IETF. Retrieved 2012-08-06.