Can AES-CMAC key come from session context or anything other than the symmetric secret OID, and size limits?

[antfarmer]

I am able to get the CMAC function to work on my PIC24 environment, but I'd like to be able to use ECDH and a KDF to generate the key in OPTIGA_KEY_ID_SESSION_BASED to avoid having to transfer the key in and out of the chip. Right now, I can only get it to work with OPTIGA_KEY_ID_SECRET_BASED.

Similar to my HMAC question, what are the size limits for CMAC when calling optiga_crypt_symmetric_encrypt vs optiga_crypt_symmetric_encrypt_start/continue/final? Is there a table of size limitations for API functions any where in the documentation? Thanks.

[ayushev]

I am able to get the CMAC function to work on my PIC24 environment, but I'd like to be able to use ECDH and a KDF to generate the key in OPTIGA_KEY_ID_SESSION_BASED to avoid having to transfer the key in and out of the chip. Right now, I can only get it to work with OPTIGA_KEY_ID_SECRET_BASED.

can you please help me understand where exactly do you struggle? Ideally with some code snippet.

Similar to my HMAC question, what are the size limits for CMAC when calling optiga_crypt_symmetric_encrypt vs optiga_crypt_symmetric_encrypt_start/continue/final? Is there a table of size limitations for API functions any where in the documentation? Thanks.

It is limited by the communication buffer (0x615 by default) per one command, but if you use start/update/finalize you can extend the maximum data size

[antfarmer]

I'd like to be able to use another OID for the key because I'd like to change the keys for the HMAC for each "session". I've heard it is good practice to change encryption and mac keys for symmetric crypto. Ideally, I'd like to use OPTIGA_KEY_ID_SESSION_BASED or even RAM to be able to use ECDH and a KDF for the keys for encryption and MAC.

[ayushev]

I think I just realised what you mean here.
For hmac you can use session OIDs (maximum of 4), but for symmetric encryption you have to use the symmetric key OID.
Also answering your another question on the maxmum data length. if used provided data is longer than the internal buffer it will be internally fragmented.

[antfarmer]

OK, that's what I gathered now. I guess this is not fitting my use case as I want to change the MAC key relatively frequently and the AES NVM won't allow for that. It would be nice in future versions of the chip if somehow the key could come from some other NVM slots and even better if there was a way to copy data from one slot to another without having to export the data to the host and back again. These issues it seems are out of the scope of the API, and actually with the chip design itself. Thanks for the help.