Internet-Draft | ACVP MAC | August 2020 |
Fussell & Hammett | Expires 11 February 2021 | [Page] |
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 February 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
There are no acknowledgements.¶
This document defines the JSON schema for testing HMAC, CMAC, and GMAC implementations with the ACVP specification.¶
The Automated Crypto Validation Protocol (ACVP) defines a mechanism to automatically verify the cryptographic implementation of a software or hardware crypto module. The ACVP specification defines how a crypto module communicates with an ACVP server, including crypto capabilities negotiation, session management, authentication, vector processing and more. The ACVP specification does not define algorithm specific JSON constructs for performing the crypto validation. A series of ACVP sub-specifications define the constructs for testing individual crypto algorithms. Each sub-specification addresses a specific class of crypto algorithms. This sub-specification defines the JSON constructs for testing HMAC, CMAC, and GMAC implementations using ACVP.¶
No terms and definitions are listed in this document.¶
The following Message Authentication Code Algorithms MAY be advertised by the ACVP compliant cryptographic module:¶
The ACVP server performs a set of tests on the MAC algorithms in order to assess the correctness and robustness of the implementation. A typical ACVP validation session would require multiple tests to be performed for every supported cryptographic algorithm, such as CMAC-AES, CMAC-TDES, HMAC-SHA-1, HMAC-SHA2-256, etc. This section describes the design of the tests used to validate implementations of MAC algorithms.¶
There is a single test type for MACs (broken into subsections for CMACs). the single test type, algorithm functional test (AFT) can be described as follows:¶
"AFT" - Algorithm Function Test. The IUT processes all of HMAC, GMAC and the "gen" direction of CMAC by running the randomly chosen key and message data (with constraints as per the IUT's capabilities registration) through the MAC algorithm. CMAC has an additional "ver" direction present in its testing to ensure the IUT can successfully determine when a MAC does not match its originating message/key combination.¶
The tests described in this document have the intention of ensuring an implementation is conformant to [SP-800-38B] and [FIPS-198-1].¶
SP 800-38B Section 6.2 Mac Generation. ACVP server creates random sets of keys and messages for the IUT to process, then compares the IUT's result to the ACVP result.¶
SP 800-38B Section 6.3 Mac Verification. ACVP server creates random sets of keys, messages, and macs. These test vectors are then randomly altered to ensure the MAC will not match the given key and message. Using the provided test case, the IUT is expected to validate the mac against the provided key and message.¶
SP 800-38B Section 5.4 Sub-keys. While sub-keys are computed, as they are intermediate values, are not validated via current testing.¶
SP 800-38B Section 5.5 Input and Output Data. The 'mlen' is provided and not inferred.¶
SP 800-38B Appendix A. Length of MAC. The ACVP server will generate vectors as per the IUT's specified criteria. The IUT SHOULD register its entire range of supported MAC lengths, regardless of security strength. The ACVP server will test a random sampling of valid MAC lengths as per the IUT registration - this generally includes the minimum and maximum MAC length.¶
SP 800-38D Section 5.1 Block Cipher. ACVP testing SHALL make use of the AES block cipher when testing GMAC.¶
SP 800-38D Section 5.2 Two Gcm Functions. ACVP testing MAY test both the generate and verify functions of GCM (without making use of a payload) to help ensure a proper implementation. The ACVP and IUT MAY test the encrypt (generate) and decrypt (verify) utilizing a key, IV/nonce, and AAD as described in this document section.¶
SP 800-38D Section 6 Mathematical Components of GCM. GHASH and GCTR produce intermediate values and SHALL be (indirectly) evaluated for correctness via the ACVP generated GMAC test vectors.¶
SP 800-38D Section 7 GCM Specification. When the IUT registers a direction capability of "encrypt", the ACVP server MUST generate vectors for the GCM-AE function. When the IUT registers a capability of "decrypt", the ACVP server MUST generate test vectors for the GCM-AD function.¶
SP 800-38D Section 5.2.1.1 Input Data. GMAC MUST NOT make use of a plaintext.¶
SP 800-38D Section 5.2.1.2 Output Data. GMAC MUST NOT make use of a ciphertext.¶
SP 800-38D Section 7 GCM Specification. The ACVP server MUST NOT make use of a plaintext or ciphertext for the generation of test vectors for use in GMAC testing.¶
SP 800-38D Section 8 Uniqueness Requirement on IVs and Keys. Key establishment, IV construction, or number of invocations for a specific key/IV SHALL NOT be tested under the scope of the ACVP testing.¶
FIPS 198-1 Section 3 Cryptographic Keys. The ACVP server will test, depending on the nature of the IUT capabilities registration, keys that are below, at, or above the hashing algorithm block size.¶
FIPS 198-1 Section 4 HMAC Specification. Mac Generation. ACVP server creates random sets of keys and messages for the IUT to process, then compares the IUT's result to the ACVP result.¶
FIPS 198-1 Section 5 Truncation. The ACVP server is capable of generating MACs as per the capability registration of the IUT. Groups will be created containing a random sampling of valid MAC lengths from the IUT registration.¶
ACVP requires crypto modules to register their capabilities. This allows the crypto module to advertise support for specific algorithms, notifying the ACVP server which algorithms need test vectors generated for the validation process. This section describes the constructs for advertising support of MAC algorithms to the ACVP server.¶
The algorithm capabilities MUST be advertised as JSON objects within the 'algorithms' value of the ACVP registration message. The 'algorithms' value is an array, where each array element is an individual JSON object defined in this section. The 'algorithms' value is part of the 'capability_exchange' element of the ACVP JSON registration message. See the ACVP specification [ACVP] for more details on the registration message.¶
Each algorithm implementation MAY rely on other cryptographic primitives. For example, RSA Signature algorithms depend on an underlying hash function. Each of these underlying algorithm primitives must be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:¶
Prerequisites, if applicable, MUST be submitted in the registration as the prereqVals
JSON property array inside each element of the algorithms
array. Each element in the prereqVals
array MUST contain the following properties¶
JSON Property | Description | JSON Type |
---|---|---|
algorithm | a prerequisite algorithm | string |
valValue | algorithm validation number | string |
A "valValue" of "same" SHALL be used to indicate that the prerequisite is being met by a different algorithm in the capability exchange in the same registration.¶
An example description of prerequisites within a single algorithm capability exchange looks like this¶
Each MAC implementation relies on other cryptographic primitives. For example, HMAC uses an underlying SHA algorithm. Each of these underlying algorithm primitives must be validated, either separately or as part of the same submission. ACVP provides a mechanism for specifying the required prerequisites:¶
JSON Value | Description | JSON type | Valid Values |
---|---|---|---|
algorithm | a prerequisite algorithm | string | AES, SHA, TDES with associated mode such as ECB, GCM or digest size |
valValue | algorithm validation number | string | Actual number or "same" |
prereqAlgVal | prerequisite algorithm validation | object with algorithm and valValue properties | See above |
Each MAC algorithm capability advertised is a self-contained JSON object using the following values.¶
JSON Value | Description | JSON type | Valid Values |
---|---|---|---|
algorithm | The MAC algorithm to be validated | string | See Section 5 |
revision | The algorithm testing revision to use | string | "1.0" |
prereqVals | Prerequisite algorithm validations | array of prereqAlgVal objects | See Section 7.2 |
capabilities | The individual MAC capabilities | array of capability objects | See Section 8.1.1, Section 9.1.1, Section 10.1, or Section 11.1 |
Each CMAC-AES algorithm capability advertised is a self-contained JSON object using Table 3. Each capability object describes a separate permutation of direction and key length.¶
JSON Value | Description | JSON type | Valid Values |
---|---|---|---|
direction | The MAC direction(s) to test | array | "gen" and/or "ver" |
keyLen | The keyLen supported | integer | 128, 192, 256 |
msgLen | The CMAC message lengths supported in bits, values MUST be mod 8 | Domain | Min: 0, Max: 524288, Inc: 8 |
macLen | The supported mac sizes | Domain | Min: 32, Max: 128 |
'macLen' for CMAC is a Domain of values, the server MAY choose values defined by these rules:¶
The smallest CMAC length supported¶
A second CMAC length supported¶
The largest CMAC length supported¶
'msgLen' for CMAC is a Domain of values, the server MAY choose values defined by these rules:¶
The following is an example JSON object advertising support for CMAC-AES.¶
Each CMAC-TDES algorithm capability advertised is a self-contained JSON object using Table 3. Each capability object describes a separate permutation of direction and key length.¶
JSON Value | Description | JSON type | Valid Values |
---|---|---|---|
direction | The MAC direction(s) to test | array | "gen", "ver" |
keyingOption | The Keying Option used in TDES. Keying option 1 (1) is 3 distinct keys (K1, K2, K3). Keying Option 2 (2) is 2 distinct only suitable for decrypt (K1, K2, K1). Keying option 3 (No longer valid for testing, save TDES KATs) is a single key, now deprecated (K1, K1, K1). | integer | 1, 2 |
msgLen | The CMAC message lengths supported in bits, values MUST be mod 8 | Domain | Min: 0, Max: 524288, Inc: 8 |
macLen | The supported mac sizes | Domain | Min: 32, Max: 64 |
'macLen' for CMAC contains a Domain of values, the server may choose values defined by these rules:¶
The smallest CMAC length supported¶
A second CMAC length supported¶
The largest CMAC length supported¶
'msgLen' for CMAC contains a Domain of values, the server may choose values defined by these rules:¶
The following is an example JSON object advertising support for CMAC-TDES.¶
Each algorithm capability advertised is a self-contained JSON object using the following values.¶
JSON Value | Description | JSON Type | Valid Values |
---|---|---|---|
algorithm | The MAC algorithm to be validated | string | "ACVP-AES-GMAC" |
revision | The algorithm testing revision to use | string | "1.0" |
prereqVals | Prerequistie algorithm validations | array of prereqAlgVal objects | See Section 7.2 |
direction | The GMAC direction(s) to test | array | "encrypt", "decrypt" |
keyLen | The keyLen supported | array | 128, 192, 256 |
ivLen | The IV lengths supported in bits, values MUST be mod 8 | domain | Min: 8, Max: 1024, Inc: 8 |
ivGen | The IV generation method (from the perspective of the IUT) | string | "internal", "external" |
ivGenMode | The IV generation mode for use when the IUT is internally generating IVs | string | "8.2.1", "8.2.2" |
aadLen | The additional authenticated data length in bits | domain | Min: 0, Max: 65536, Inc: 8 |
tagLen | The supported mac/tag lengths | array | 32, 64, 96, 104, 112, 120, 128 |
The following is an example JSON object advertising support for AES-GMAC.¶
Each algorithm capability advertised is a self-contained JSON object using the following values.¶
JSON Value | Description | JSON type | Valid Values |
---|---|---|---|
algorithm | The MAC algorithm and mode to be validated | string | See Section 11.2 |
revision | The algorithm testing revision to use | string | "1.0" |
prereqVals | prerequistie algorithm validations | array of prereqAlgVal objects | See Section 7.2 |
keyLen | The keyLen Domain supported by the IUT in bits | domain | Min: 0, Max: 524288 |
macLen | The supported mac sizes, maximum is dependent on algorithm, see Section 11.2 | domain | Min: 32 |
'keyLen' for HMAC contains a Domain of values, the server MAY choose values defined by these rules:¶
2 values below the Hash's block length. See Section 11.2¶
The Hash's block length.¶
2 values above the Hash's block length.¶
'macLen' for HMAC contains a Domain of values, the server MAY choose values defined by these rules:¶
The following HMAC algorithms contain specific individual properties:¶
Algorithm Value | Block Length | Max MAC Length |
---|---|---|
HMAC-SHA-1 | 512 | 160 |
HMAC-SHA2-224 | 512 | 224 |
HMAC-SHA2-256 | 512 | 256 |
HMAC-SHA2-384 | 1024 | 384 |
HMAC-SHA2-512 | 1024 | 512 |
HMAC-SHA2-512/224 | 1024 | 224 |
HMAC-SHA2-512/256 | 1024 | 256 |
HMAC-SHA3-224 | 1152 | 224 |
HMAC-SHA3-256 | 1088 | 256 |
HMAC-SHA3-384 | 832 | 384 |
HMAC-SHA3-512 | 576 | 512 |
The following is an example JSON object advertising support for HMAC.¶
The ACVP server provides test vectors to the ACVP client, which are then processed and returned to the ACVP server for validation. A typical ACVP validation test session would require multiple test vector sets to be downloaded and processed by the ACVP client. Each test vector set represents an individual algorithm defined during the capability exchange. This section describes the JSON schema for a test vector set used with HMAC, CMAC, and GMAC algorithms.¶
The test vector set JSON schema is a multi-level hierarchy that contains meta data for the entire vector set as well as individual test vectors to be processed by the ACVP client. The following table describes the JSON elements at the top level of the hierarchy.¶
JSON Values | Description | JSON Type |
---|---|---|
acvVersion | Protocol version identifier | string |
vsId | Unique numeric vector set identifier | integer |
algorithm | Algorithm defined in the capability exchange | string |
mode | Mode defined in the capability exchange | string |
revision | Protocol test revision selected | string |
testGroups | Array of test groups containing test data, see Section 13 | array |
An example of this would look like this¶
The ACVP server provides test vectors to the ACVP client, which are then processed and returned to the ACVP server for validation. A typical ACVP validation session would require multiple test vector sets to be downloaded and processed by the ACVP client. Each test vector set represents an individual crypto algorithm, such as HMAC-SHA-1, HMAC-SHA2-224, CMAC-AES, etc. This section describes the JSON schema for a test vector set used with MAC crypto algorithms.¶
The test vector set JSON schema is a multi-level hierarchy that contains meta data for the entire vector set as well as individual test vectors to be processed by the ACVP client. The following table describes the JSON elements at the top level of the hierarchy.¶
JSON Value | Description | JSON type |
---|---|---|
acvVersion | Protocol version identifier | string |
vsId | Unique numeric identifier for the vector set | integer |
algorithm | The algorithm used for the test vectors | string |
revision | The algorithm testing revision to use | string |
testGroups | Array of test group JSON objects, which are defined in Section 13.1.1, Section 13.2.1, Section 13.3.1, or Section 13.4.1 depending on the algorithm | array |
The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the secure CMAC-AES JSON elements of the Test Group JSON object.¶
JSON Value | Description | JSON type |
---|---|---|
tgId | Numeric identifier for the test group, unique across the entire vector set | integer |
testType | Test category type | string |
direction | The direction of the tests - gen or ver | string |
keyLen | Length of key in bits to use | integer |
msgLen | Length of message in bits | integer |
macLen | Length of MAC in bits to generate/verify | integer |
tests | Array of individual test vector JSON objects, which are defined in Section 13.1.2 | array |
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each secure MAC test vector.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
key | Encryption key to use | hex |
msg | Value of the message | hex |
mac | MAC value, for CMAC verify | hex |
The following is an example JSON test vector object for CMAC-AES, truncated for brevity.¶
The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the secure CMAC-TDES JSON elements of the Test Group JSON object.¶
JSON Value | Description | JSON type |
---|---|---|
tgId | Numeric identifier for the test group, unique across the entire vector set | integer |
testType | Test category type | string |
direction | The direction of the tests - gen or ver | string |
keyLen | Length of key in bits to use | integer |
msgLen | Length of message in bits | integer |
macLen | Length of MAC in bits to generate/verify | integer |
tests | Array of individual test vector JSON objects, which are defined in Section 13.2.2 | array |
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each secure MAC test vector.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
key1, key2, key3 | Encryption keys to use for TDES | hex |
msg | Value of the message | hex |
mac | MAC value, for CMAC verify | hex |
The following is an example JSON test vector object for CMAC-TDES, truncated for brevity.¶
The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the secure GMAC JSON elements of the Test Group JSON object.¶
JSON Value | Description | JSON Type |
---|---|---|
tgId | Numeric identifier for the test group, unique across the entire vector set | integer |
testType | Test category type | string |
direction | The direction of the tests - encrypt or decrypt | string |
keyLen | Length of key in bits to use | integer |
ivLen | Length of IV in bits | integer |
ivGen | IV Generation (internal or external) | string |
ivGenMode | The mode an internal IV has been generated using | string |
aadLen | Length of AAD in bits | integer |
tagLen | Length of tag/MAC in bits to generate/verify | integer |
tests | Array of individual test vector JSON objects, which are defined in Section 13.3.2 | array |
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each secure MAC test vector.¶
JSON Value | Description | JSON Type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
key | Encryption key to use | hex |
iv | Value of the IV | hex |
aad | Value of the AAD | hex |
tag | MAC/tag value, for validating on a decrypt operation | hex |
The following is an example JSON test vector object for AES-GMAC, truncated for brevity¶
The testGroups element at the top level in the test vector JSON object is an array of test groups. Test vectors are grouped into similar test cases to reduce the amount of data transmitted in the vector set. For instance, all test vectors that use the same key size would be grouped together. The Test Group JSON object contains meta data that applies to all test vectors within the group. The following table describes the secure HMAC JSON elements of the Test Group JSON object.¶
JSON Value | Description | JSON type |
---|---|---|
tgId | Numeric identifier for the test group, unique across the entire vector set | integer |
testType | Test category type | string |
keyLen | Length of key in bits to use | integer |
msgLen | Length of message in bits | integer |
macLen | Length of MAC in bits to generate | integer |
tests | Array of individual test vector JSON objects, which are defined in Section 13.4.2 | array |
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each secure MAC test vector.¶
JSON Value | Description | JSON type | tcId |
---|---|---|---|
Numeric identifier for the test case, unique across the entire vector set | integer | key | The value of the key |
hex | msg | Value of the message | hex |
The following is an example JSON test vector object for HMAC, truncated for brevity.¶
After the ACVP client downloads and processes a vector set, it must send the response vectors back to the ACVP server. The following table describes the JSON object that represents a vector set response.¶
JSON Property | Description | JSON Type |
---|---|---|
acvVersion | The ACVP version used | string |
vsId | The vector set identifier | integer |
testGroups | The test group objects in the response, see Table 20 | array |
An example of this is the following¶
The 'testGroups' section is used to organize the ACVP client response in a similar manner to how it distributes vectors.¶
JSON Property | Description | JSON Type |
---|---|---|
tgId | The test group identifier | integer |
tests | The test case objects in the response, depending on the algorithm see Table 21, Table 22, Table 23 or Table 24 | array |
An example of this is the following¶
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each CMAC-AES test vector.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
mac | The value of the computed MAC output for 'gen' test type groups | hex |
testPassed | The result of CMAC verify for 'ver' test type groups | boolean |
The following is an example JSON test vector response object for CMAC-AES.¶
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each CMAC-TDES test vector.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
mac | The value of the computed MAC output for 'gen' test type groups | hex |
testPassed | The result of CMAC verify for 'ver' test type groups | boolean |
The following is an example JSON test vector response object for CMAC-TDES.¶
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each GMAC test vector.¶
JSON Value | Description | JSON Type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
tag | Value of the computed tag/MAC output, for 'encrypt' direction groups | hex |
testPassed | The result of decrypt verify, for 'decrypt' direction groups | boolean |
The following is an example JSON test vector response object for AES-GMAC.¶
Each test group contains an array of one or more test cases. Each test case is a JSON object that represents a single test vector to be processed by the ACVP client. The following table describes the JSON elements for each HMAC test vector.¶
JSON Value | Description | JSON type |
---|---|---|
tcId | Numeric identifier for the test case, unique across the entire vector set | integer |
mac | Value of the computed MAC output | hex |
The following is an example JSON test vector response object for HMAC.¶
There are no additional security considerations outside of those outlined in the ACVP document.¶
This document does not require any action by IANA.¶