[keymgr] Ability to run known-answer tests for KMAC

[vsukhoml]

Description

In order to qualify for proper key derivation, we will have to run KATs for derivation function used by key manager. This means we need a mode, where we can supply both a key and a label from the software to run tests.

These tests shall also run in the ROM before any other data from key manager is used.

[vsukhoml]

@ballifatih

[vsukhoml]

@moidx mentioned that kmac instance inside keymgr is the same as the one accessible via kmac, so that will help with respect to being able to run the KAT for kmac. If this is the case, we can probably address this requirement by running KMAC KATs before any use of keymgr's output

[ballifatih]

• Keymgr does not have its own internal KMAC, but it talks to the peripheral KMAC IP. The same KMAC IP can also be used from SW (for KMAC/SHAKE and SHA-3 functions). Therefore, we can use the same KMAC from SW to run KATs.
• The KMAC function used by Keymgr uses the parameters key_len = 256, security_str = 256, digest_len = 384. For AES/KMAC and Keymgr's internal key updates, 384-bit output is truncated to 256-bit. For OTBN, the whole 384-bit is used.
• Because of RTL secrets and the lack of interface within Keymgr, KAT cannot be run directly through Keymgr's path. However, we can show that the KMAC with these specific parameters runs correctly through SW.

Based on this information, do you think there is still concern for KAT? Otherwise, I would like to close this issue @vsukhoml .

[vsukhoml]

I think that we will need to run KAT on KMAC before using Keymgr.

384-bit output is truncated to 256-bit.

This is not the intended mechanism described in SP 800-108 Section 4.4 for KMAC KDF. Unlike truncation of SHA/HMAC which is explicitly allowed by taking leftmost bits, KMAC computation directly produce required length and its output for shorter length will differ from truncation of longer output as L is mixed in computation (which also true for other KDFs). This is to use output key length as diversification of different keys.

I'd suggest to feed key length explicitly, but this would require more changes, say to accommodate AES 128/192/256 bit keys you need to specify what kind of key is being created.