MACSEC nonce/key uniqueness

Question

802.1ae requires a nonce to be sent with each Ethernet frame in the MACSEC tag. The 96 bit nonce is formed by concatenating a 64 bit fixed field (based on MAC source address and port number) with a 32 bit packet number. The packet number is incremented for each frame. So the nonces for two successive frames belonging to the same secure association would look as follows:

Frame #1 {MAC SA, Port Number, PN}

Frame #2 {MAC SA, Port Number, PN+1}

Now the frames are encrypted using the AES-GCM mode. So each 128 bit plaintext block of each message is encrypted using a unique nonce. For example:

Frame #1, Block #1 is encrypted using {MAC SA, Port Number, PN}

Frame #1, Block #2 is encrypted using {MAC SA, Port Number, PN+1}

etc...

Frame #2, Block #1 is encrypted using {MAC SA, Port Number, PN+1}

Frame #2, Block #2 is encrypted using {MAC SA, Port Number, PN+2}

etc...

So it seems that the same nonce/key combination is reused for different blocks in successive ethernet frames.

But the AES-CTR mode specifically warns against using the same nonce/key combination.

What am I missing?

thank-you

Answer 1

If you look at the GCM specification, you will see on page 15 that when the IV has length exactly 96 bits, then the counter for the AES-CTR encryption is initialized at J₀ = IV || 0₃₁ || 1, i.e. the 128-bit counter is built by appending 31 bits of value 0, then one bit of value 1. The successive increments when doing the CTR encryption will alter bits in these low 32 bits. Thus, there is no overlap as long as no ethernet frame is bigger than four billion blocks, i.e. 64 gigabytes... and an ethernet frame is indeed much shorter than that.

Alternative description: if a frame uses IV x, then the counter value for that frame begins at value 2³²x+1 and will go up to 2³²x+94 (for a 1500-byte ethernet frame, a bit less than 94 blocks). Next frame will use IV x+1, for a counter which starts at 2³²(x+1)+1 = 2³²x+2³²+1, incurring no overlap.

Note: this means that it would be quite unsafe to encrypt more than 64 gigabytes as a single run with GCM. This is stated explicitly in the specification, page 8: plaintext length shall not exceed 2³⁹-256 bits. This is more than enough because, by definition, an authenticated encryption mode is meant to provide some integrity guarantees; thus, it makes sense when the data could be altered by the attacker; correspondingly, the receiver of data shall not use it until it has verified the MAC, which entails buffering the whole "packet". Who wants to buffer 64 gigabytes of data before being able to begin its processing ? When GCM is used in TLS, the buffer size will not exceed 17 kilobytes; and, in your case, the maximum size will be that of an ethernet frame, which maxes out at 9000 bytes even with jumbo frames.

Answer 2

What happens is that AES has other modes of operation:

1. AES-CTR uses the same IV
2. AES-rand ctr-mod: Randomize the IV.

GCM indeed is "randomized the IV", even for just one bit, but is doing so as @Tom Leek states above