Skip to main content

3. MAC Algorithms

  1. Message Authentication Code (MAC) Algorithms

Section 8.2 of [RFC9052] contains a generic description of MAC algorithms. This section defines the conventions for two MAC algorithms.

3.1. Hash-Based Message Authentication Codes (HMACs)

HMAC [RFC2104] [RFC4231] was designed to deal with length extension attacks. The HMAC algorithm was also designed to allow new hash functions to be directly plugged in without changes to the hash function. The HMAC design process has been shown to be solid; although the security of hash functions such as MD5 has decreased over time, the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151].

The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define one HMAC algorithm that is truncated. There are currently no known issues with truncation; however, the security strength of the message tag is correspondingly reduced in strength. When truncating, the leftmost tag-length bits are kept and transmitted.

The algorithms defined in this document can be found in Table 3.

+=============+=======+=========+============+======================+ | Name | Value | Hash | Tag Length | Description | +=============+=======+=========+============+======================+ | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | | 256/64 | | | | truncated to 64 bits | +-------------+-------+---------+------------+----------------------+ | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | | 256/256 | | | | | +-------------+-------+---------+------------+----------------------+ | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | 384/384 | | | | | +-------------+-------+---------+------------+----------------------+ | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | 512/512 | | | | | +-------------+-------+---------+------------+----------------------+

                   Table 3: HMAC Algorithm Values

Some recipient algorithms transport the key, while others derive a key from secret data. For those algorithms that transport the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the output of the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the output of the underlying hash function.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "Symmetric".

  • If the "alg" field is present, it MUST match the HMAC algorithm being used.

  • If the "key_ops" field is present, it MUST include "MAC create" when creating an HMAC authentication tag.

  • If the "key_ops" field is present, it MUST include "MAC verify" when verifying an HMAC authentication tag.

Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

3.1.1. Security Considerations for HMAC

HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation.

3.2. AES Message Authentication Code (AES-CBC-MAC)

AES-CBC-MAC is the instantiation of the CBC-MAC construction (defined in [MAC]) using AES as the block cipher. For brevity, we also use "AES-MAC" to refer to AES-CBC-MAC. (Note that this is not the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) [RFC4493].)

AES-CBC-MAC is parameterized by the key length, the authentication tag length, and the Initialization Vector (IV) used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key and tag lengths. The algorithms defined in this document are found in Table 4.

 +=========+=======+============+============+==================+
 | Name    | Value | Key Length | Tag Length | Description      |
 +=========+=======+============+============+==================+
 | AES-MAC |   14  |    128     |     64     | AES-MAC 128-bit  |
 | 128/64  |       |            |            | key, 64-bit tag  |
 +---------+-------+------------+------------+------------------+
 | AES-MAC |   15  |    256     |     64     | AES-MAC 256-bit  |
 | 256/64  |       |            |            | key, 64-bit tag  |
 +---------+-------+------------+------------+------------------+
 | AES-MAC |   25  |    128     |    128     | AES-MAC 128-bit  |
 | 128/128 |       |            |            | key, 128-bit tag |
 +---------+-------+------------+------------+------------------+
 | AES-MAC |   26  |    256     |    128     | AES-MAC 256-bit  |
 | 256/128 |       |            |            | key, 128-bit tag |
 +---------+-------+------------+------------+------------------+

                Table 4: AES-MAC Algorithm Values

Keys may be obtained from either a key structure or a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "Symmetric".

  • If the "alg" field is present, it MUST match the AES-MAC algorithm being used.

  • If the "key_ops" field is present, it MUST include "MAC create" when creating an AES-MAC authentication tag.

  • If the "key_ops" field is present, it MUST include "MAC verify" when verifying an AES-MAC authentication tag.

3.2.1. Security Considerations for AES-CBC-MAC

A number of attacks exist against Cipher Block Chaining Message Authentication Code (CBC-MAC) that need to be considered.

  • A single key must only be used for messages of a fixed or known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for messages of different lengths. The current structure mitigates this problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.)

  • In Cipher Block Chaining (CBC) mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code.

  • If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros.

Last updated on