CCMP Implementation: Library Abstraction vs. Bare-Metal Simulation

The "Why" Behind this Project

In modern network security, we often rely on high-level primitives like the cryptography library's AESCCM to handle our encryption and integrity checks. While efficient, these abstractions hide the intricate dance of the IEEE 802.11i standard.

I built this project to peel back those layers. By comparing a library-based implementation with a manual, step-by-step simulation of AES-CTR and AES-CBC-MAC, I’ve documented exactly how CCMP manages temporal keys, nonces, and the critical formatting of $B_0$ and $A_i$ blocks.

High-Level vs. Bare Math

The repository contains two distinct Python implementations for the Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP):

1. High-Level (AESCCM): Utilizes standard primitives that abstract MIC calculation and encryption into a single encrypt() call.
2. Manual Simulation: A "bare-metal" approach using AES-CTR for confidentiality and AES-CBC-MAC for integrity, simulating the XOR chains and manual padding required by the standard.

Process Comparison (Sender Side)

Step	Library Implementation (AESCCM)	Manual Implementation
Nonce Construction	Implicitly handled.	Explicitly built using Source MAC, QoS, and PN.
Integrity (MIC)	Part of the encrypt() call	Calculates via a manual XOR chain in calculate_mic()
Encryption (CTR)	High-level encrypt() over AAD/Payload	Explicit encrypt_ctr() over concatenated (Plaintext + MIC)
Output	Returns Ciphertext + 64-bit MIC.	Returns Encrypted Payload + Encrypted MIC.

Core Technical Building Blocks

The manual implementation simulates the following critical CCMP functions:

• generate_ccmp_nonce: Constructs the 13-byte nonce (Source MAC + QoS + 48-bit PN).
• construct_be_block: Formats the $B_0$ block, the IV used for the CBC-MAC chain.
• calculate_mic: Manually XORs blocks ($T_i = AES(T_{i-1} \oplus P_i)$) to generate the 64-bit MIC.
• encrypt_ctr: Simulates the key-stream generation and XORing for data confidentiality.

Findings: The Abstraction Gap

Interestingly, while both implementations are functionally correct and secure, the final ciphertexts often differ slightly despite identical inputs.

Small variations in the construction of the $B_0$ block flags, length field formatting, or the specific zero-padding logic for Associated Authenticated Data (AAD) can lead to different MIC outputs. This highlights how "standard" protocols can have implementation nuances that libraries handle silently under the hood.

Error Handling & Security

The simulation includes robust mechanisms for:

• Integrity Failures: Raises IntegrityCompromisedError (mapped from InvalidTag) if the MIC check fails.
• Replay Protection: Explicit PN (Packet Number) tracking prevents the reuse of older, intercepted frames.

References

• IEEE 802.11i Standard
• K. Benton, "The Evolution of 802.11 Wireless Security," 2010.

Note: This project was developed as a deep-dive into cryptographic protocol simulation for the CyberMACS Master's program.