Other Parts Discussed in Thread: CC2538
Hi!
Software Versions
CCS 7.3.0.00019
Compiler TI v16.9.6LTS
CC2538 Foundation Firmware 1.0.1.0
Background
While using the aes_ccm_example found within Foundation Firmware, I was trying to modify the example to use KEY_AREA_1 for one key and KEY_AREA_0 for another to only load the keys one time . This resulted in an AES_KEYSTORE_WRITE_ERROR return from AESLoadKey on the call to AESLoadKey with parameter KEY_AREA_1. Two things were found:
- Each call to AESLoadKey erases all previously written keys due to a clear and write of AES_KEY_STORE_SIZE
- The final status check of AES_KEY_STORE_WRITTEN_AREA only checks bit 0 - KEY_AREA_0
Details
'1.' from above is likely okay or expected, although it makes loading multiple keys using strictly the API impossible, but '2.' results in the API only functioning with a second parameter of KEY_AREA_0 conflicting with API documentation. The following status check (line 163 of aes.c) could be changed from:
// check status, if error return error code if((HWREG(AES_KEY_STORE_WRITTEN_AREA) & 0x7) != 0x1) { g_ui8CurrentAESOp = AES_NONE; return (AES_KEYSTORE_WRITE_ERROR); }
to:
// check status, if error return error code if((HWREG(AES_KEY_STORE_WRITTEN_AREA) & (0x00000001 << ui8KeyLocation)) != (0x00000001 << ui8KeyLocation)) { g_ui8CurrentAESOp = AES_NONE; return (AES_KEYSTORE_WRITE_ERROR); }
Question
Although I did a basic test of the above change, are there any other issues that could come up as a result of this change? Or (even better) is there something I am doing wrong with the existing implementation of AESLoadKey that actually does allow for other KEY_AREA_#s to be used?
Thank you for your help!
Best Regards,
Mark-