CKM_AES_GCM

GCM is the Galois/Counter Mode of operation of the AES algorithm for symmetric key encryption.

Usage Notes

Initialization Vector

If the HSM is in FIPS mode (HSM policy 12: Allow non-FIPS algorithms set to OFF), the initialization vector (IV) is generated in the HSM and returned to the PKCS#11 function call. The buffer must be large enough to store the GMAC tag plus the generated IV (which has a length of 16 bytes). When both encrypting/decrypting on a Luna HSM, do not provide the tag bits themselves, just the AAD and IV (for decryption only).

Using the GCM method, encrypted data is the same size as the clear data. The IV generated by the HSM is concatenated at the end -- to determine the IV, find the last 16 bytes of the encrypted data.

If the HSM is not in FIPS mode, you must specify an IV. Random IV is supported and recommended for GCM and GMAC. If you are not using random IV, then the most efficient IV value length is 12 bytes; any other size reduces performance and requires more work (per NIST SP-800-38D).

Prior to HSM firmware version 7.9.3, the internal IV is a randomly generated 16-byte IV.

From firmware version 7.9.3, IV behavior is as follows:

If ivLen != ivBits/8 then:

- ivLen must be > ivBits/8 ... that is, user IV must be >= ivBits/8

- the HSM will generate a random ivBits of data and replace last ivBits if user IV

IVLen IvBits Behavior
0 0, or 128 Generate 128 bit IV
0 96 Generate 96 bit IV
Any Any + something Error: IvLen must be > ivBits/8
16 96 Copy 32 bits | generate 96 bits = 128 bit IV
12 96 Copy 96 bits for IV (Non FIPS)
16 128 16 128 Copy 128 bits for IV (Non FIPS)

Performance

For authentication, it is possible to use CKM_AES_GCM mechanism, when passing no data to encrypt (for strict compliance with NIST specification), and performance in that mode is better than in previous Luna releases.

The correlation is not exact but, as a general rule for a given mechanism, invocation by PKCS#11 API always provides the best performance, JSP performance is close but lower due to Java architecture, and JCPROV performance is somewhat lower still than PKCS#11 and JSP performance levels.

JCPROV

AES-GMAC and AES-GCM are supported in JCPROV. Use CK_AES_GCM_PARAMS.java to define the GMAC operation. Implementation is the same as for PKCS#11.

Java Provider (JSP)

Both GMC and GMAC are supported. "GmacAesDemo.java" provides a sample for using GMAC with Java.

Java Parameter Specification class LunaGmacParameterSpec.java defines default values recommended by the NIST specification.

JSP change from firmware version 7.9.3

FW 7.9.3 introduced changes to how AES GCM multipart encryption works.

Previous behavior

AES GCM multipart behavior prior to firmware 7.9.3:

>C_EncryptUpdate does not return any encrypted data, it just accumulates all data

>C_EncryptFinal returns the whole ciphertext along with tag bits and IV (if any) generated by firmware.

>In FIPS 140 configuration, IV generated by the HSM is always 16 bytes.

New behavior

AES GCM multipart behavior with firmware 7.9.3 and newer:

>C_EncryptUpdate returns encrypted data up to n block size and only accumulates data < 16 bytes (block size). As soon as at least one block size is encrypted, C_EncryptUpdate immediately sends the data back.

>C_EncryptFinal returns any accumulated ciphertext, tag bits and IV (if any) generated by firmware.

>In FIPS 140 configuration, IV generated by firmware is variable from 12 bytes to 16 bytes based in ulIvBits parameter in GCM Params.

Advice

This AES GCM change could affect your Java application.

For AES GCM Cipher instance,

>Cipher.update(data); now returns an encrypted chunk rather than null as was done previously. If no data is accumulated and 'data' is less than 16 bytes (block size), this call returns null but as soon as at least one block size data is accumulated, this call returns that chunk of ciphertext.

>Cipher.doFinal(); only returns any accumulated ciphertext and tag bits as opposed to returning the whole ciphertext previously.

Accumulating Data

Our GMAC and GCM are single part operations, so even if they are called using multi-part API, we accumulate the data (up to a maximum) and return data only on the “final” operation. That is the meaning of "Accumulating" in the table, below.

Messages submitted to AES GCM decryption using Luna HSM Firmware 7.9.3 or newer, can be a maximum of 512MB minus 32 bytes in size. This also applies to messages presented as input to AES GCM encryption; attempting to encrypt a larger message is not permitted.

NOTE    The FIPS 140 configuration setting requires that a large encrypted message, which is automatically divided into 64KB chunks for decryption, does not expose any of the pieces in plaintext before reassembly as the complete decrypted version. When FIPS 140 configuration is enabled, any object or message larger than 64KB is processed in a way that keeps all packets securely encrypted until the final one is received. This decreases potential attack options, but can increase decryption time for larger messages. Existing commands and calls are unchanged from the user perspective - the HSM determines what is needed, based on the FIPS 140 setting and the size of your message. Applies to Luna HSM Firmware 7.9.3 and newer and Luna HSM Client 10.9.3 and newer.

Firmware 7.7.2 and Newer Summary

FIPS approved? Yes
Supported functions Encrypt | Decrypt | Wrap | Unwrap
Functions restricted from FIPS use None
Minimum key length (bits) 128
Minimum key length for FIPS use (bits) 128
Minimum legacy key length for FIPS use (bits) N/A
Maximum key length (bits) 256
Block size 16
Digest size 0
Key types AES
Algorithms AES
Modes GCM
Flags Extractable | Accumulating

Firmware 7.7.1 and Older Summary

FIPS approved? Yes
Supported functions Encrypt | Decrypt
Functions restricted from FIPS use None
Minimum key length (bits) 128
Minimum key length for FIPS use (bits) 128
Minimum legacy key length for FIPS use (bits) N/A
Maximum key length (bits) 256
Block size 16
Digest size 0
Key types AES
Algorithms AES
Modes GCM
Flags Extractable | Accumulating