MACsec Engine and Key Hierarchy
Overview
MACsec (Media Access Control Security, IEEE 802.1AE) provides confidentiality, integrity, and replay protection at Layer 2. Unlike IPsec, which operates at the network layer, MACsec protects Ethernet frames directly, enabling:
- deterministic latency
- line‑rate encryption
- per‑port or per‑link security
- hardware‑enforced replay protection
MACsec requires a dedicated hardware engine because:
- AES‑GCM must run at line‑rate (1G/2.5G/10G/25G/100G+)
- replay protection must be implemented in hardware
- secure association switching must be deterministic
- the CPU cannot process packets at these speeds
- the HSM cannot operate in the data path
This page explains how the MACsec engine works and how its key hierarchy interacts with the HSM.
MACsec in the System Architecture
MACsec lives in the data path, between the MAC and the PHY. It receives keys from the HSM but performs all encryption/decryption internally.
The HSM never sees packets. The MACsec engine never sees raw keys outside its secure registers.
Key Hierarchy in MACsec
MACsec uses a layered key hierarchy to separate long‑term identity from short‑term traffic keys.
CAK — Connectivity Association Key
- Long‑term key shared between peers
- Used by MKA to derive other keys
- Stored and protected by the HSM
- Never used directly for encryption
CKN — Connectivity Association Key Name
- Identifier for the CAK
- Not secret
- Used to select the correct CAK
SAK — Secure Association Key
- Short‑term traffic key
- Used by the MACsec engine for AES‑GCM
- Derived from CAK via MKA
- Injected into the MACsec engine by the HSM
- Rotated periodically
KEK — Key Encryption Key
- Used to wrap/unwrap SAKs during MKA exchanges
- Derived from CAK
- Protects SAK distribution
ICV — Integrity Check Value
- Output of AES‑GCM
- Ensures integrity and authenticity of each frame
The HSM manages CAK/KEK and derives SAKs. The MACsec engine uses SAKs to encrypt/decrypt frames.
MKA — MACsec Key Agreement
MKA (IEEE 802.1X‑2010) is the protocol responsible for:
- authenticating peers
- distributing CAK/CKN
- deriving KEK and SAK
- performing periodic rekeying
- managing Secure Channels (SC) and Secure Associations (SA)
MKA runs on the CPU, but all key material is handled by the HSM.
The CPU never sees plaintext keys.
Secure Channels and Secure Associations
MACsec organizes encryption using two concepts:
Secure Channel (SC)
- Identified by the transmitter’s MAC address
- Represents a unidirectional flow
- Each peer has one transmit SC and one receive SC
Secure Association (SA)
- A specific key instance within an SC
- Identified by an Association Number (AN)
- Multiple SAs allow seamless rekeying
SA Switching
When a new SAK is installed:
- A new SA is created
- The MACsec engine switches to the new SA
- The old SA is retired after all frames are drained
This ensures zero packet loss during rekeying.
AES‑GCM Pipeline
MACsec uses AES‑GCM for authenticated encryption. To achieve line‑rate performance, the MACsec engine implements a pipelined AES‑GCM datapath.
Key properties:
- deterministic latency
- multi‑block parallelism
- support for jumbo frames
- integrated PN (Packet Number) handling
- hardware ICV generation and verification
The HSM cannot perform this function — it is too slow and not in the data path.
Interaction Between HSM and MACsec Engine
HSM Responsibilities
- Store CAK securely
- Derive KEK and SAK
- Enforce key usage policies
- Wrap/unwrap keys for MKA
- Provide secure key injection
MACsec Engine Responsibilities
- Encrypt/decrypt frames
- Maintain PN counters
- Enforce replay protection
- Switch SAs deterministically
- Protect keys inside hardware registers
Key Injection Flow
Keys never appear in CPU memory.
Replay Protection
MACsec uses a Packet Number (PN) per SA. The MACsec engine maintains:
- a monotonically increasing PN
- a replay window
- hardware checks for out‑of‑window frames
Replay protection must be in hardware because:
- packets arrive at line‑rate
- the CPU cannot inspect every frame
- PN must be checked before decryption
Threats and Mitigations
| Threat | Mitigation |
|---|---|
| Key extraction | HSM isolation, wrapped keys, secure injection |
| Replay attacks | PN + replay window in hardware |
| Forged frames | AES‑GCM ICV verification |
| Side‑channel attacks | Balanced logic, masking |
| Fault injection | Tamper sensors, redundant counters |
| Compromised CPU | HSM enforces key usage policies |
