Windows 8/Server 2012: Passes FIPS-140-2 despite failing AES-GCM for IV != 96 bits long?

Question

Background

Microsoft certifies Windows 7/8 as well as Server 2008 R2 and 2012 to be FIPS-140-2 compliant. Actually they certify just a small crypto core, bcrypt.dll (the library, which is unrelated to bcrypt, the key derivation function). Microsoft's FIPS-140-2 architecture is detailed here. Also, their FIPS-140-2 AES certificate on NIST's listing is certificate #2216, in detail here. You can see in the listing that AES in GCM mode was tested with comments IV Lengths Tested: ( 8 , 1024 ) , 96BitIV_Supported , GMAC_Supported. I do see other vendors also having an additional flag/comment OtherIVLen_Supported in their FIPS AES certificate that MSFT's own FIPS certificate lacks.

Issue

We tested bcrypt.dll for AES in GCM mode with the test vectors found in the AES GCM paper (hosted on NIST). We found that Windows' bcrypt.dll throws an error (NT_STATUS = An invalid parameter was passed to a service or function.) when using IVs that are NOT 96 bits. So basically the test vectors 5, 11, 17 and 6, 12, 18 fail as those two groups use IVs of size 64 bits and 480 bits respectively. The results are

Question

I know that IV size != 96bits means additional processing but how can they clear certification despite failing IV sizes of 64 and 480 bits? Or is IV at 96 bits the only required IV length needed for passing?

Answer 1

The answer is, yes, you can get FIPS certification even if you don't implement every approved cryptographical primitive, or if you don't implement every possible option of those primitives.

When you undergo FIPS testing, they ask you to fill out an "information form" that asks for the details of what cryptography you claim to implement. These includes questions about which primitives you implement (e.g. whether you do GCM or not). If you do claim to support GCM, you then have to claim what portions of GCM you implement. For example, you can claim to support GCM encryption but not decryption, or support 128 bit and 256 bit keys, but not 192 bits (for example). As for the IV, you can claim support for 96 bits, or you can claim support for a range of IV sizes (anywhere between 0 and 1024 bits, multiples of 8 please).

Hence, when Microsoft applied for FIPS validation of their component, they claimed support for only 96 bit IVs.

However, that's not immediately obvious from the summary that NIST lists in the certificate listing (which is copied directly from the Information Form, and lists exactly what restrictions the certified implementation has). For this implementation, they list under GCM:

IV Lengths Tested: ( 8 , 1024 )

which would, to a naive reader, appear to state that Microsoft claimed support for IV's of length in the range 8 to 1024, and that NIST tested them, however, that's not the case. NIST has a separate flag 'OtherIVLen_Supported'; unless that is claimed, you really get support only for 96 bits. That flag is not mentioned under the Microsoft entry, hence Microsoft doesn't claim to support those IV lengths.

Exactly how NIST expects you to know this (if you're not familiar with the internals of the NIST information form), I have no idea. The OtherIVLen_Supported flag is not even mentioned in the 'Legend for Description Field' header.