Well, of course a Block cipher is always a Block cipher. But sometimes it might not be used as expected and this can cause some misunderstanding of how things work.
If you implement IPsec VPNs, you likely know ESP, the Encapsulating Security Payload and it’s packet format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Encapsulating Security Payload Packet Format from RFC 4303
The interesting part is the Padding. When AES is used, we have the block size of 128 bits, and the encryption always uses chunks of this size. when the payload is less than the blocksize, the data gets padded to reach the blocksize.
We can visualize this with a series of pings where the payload increases by 1 Byte with every ping:
The y-axis has the IP-packet length, the x-axis is the packet number. There are always 16 packet of the same size and then the size increases by 16 Bytes.
But if we do the same test in a wireless LAN this can not be observed. Although CCMP also uses AES as the encryption algorithm, the packet size increases by 1 Byte per packet:
Obviously, no padding is needed when AES is used on a WLAN. But why? Let’s first look at the MPDU format of a CCMP-encapsulated wireless frame, which is used if we configure the WLAN with WPA2 and AES:
The field “Data (PDU)” is defined as 1 Byte or more, and the frame doesn’t have a Padding Field as seen on the ESP packet format. The whole encryption process with AES has to be done in a completely different way than with IPsec/ESP.
The 802.11 standard has no details about the encryption process but references RFC 3610 Counter with CBC-MAC (CCM).
The most important piece of information here is the “Counter” (CTR). CCMP is a variant of the Counter Mode, that was already developed by Whitfield Diffie and Martin Hellman in 1979. Counter mode uses the Block Cipher to generate a key stream, which is then XORed with the data. Effectively, with Counter Mode, we use a block cipher like AES in a way similar to how a stream cipher works.
Paragraph 2.3 of RFC 3610 has the details:
To encrypt the message data we use Counter (CTR) mode. We first
define the key stream blocks by:
S_i := E( K, A_i ) for i=0, 1, 2, ...
...
The message is encrypted by XORing the octets of message m with the
first l(m) octets of the concatenation of S_1, S_2, S_3, ... .
In this process, we always have a key stream with sizes in increments of the block size. But with the XOR operation, we are not limited to encrypting only data of the block size.
Are there other benefits of using CCMP compared to the implementation in IPsec?
When used as a block cipher, the encryption and decryption processes are different. However, in CCMP, only the AES encryption operation is used to generate the key stream for the data’s encryption and decryption, which can reduce the complexity of the code.
This process is perfectly visualized in the Wikipedia article describing the different modes of operations:
Happy WLAN encryption!