There is an application note <Injecting and Updating Secure User Keys> shows how to inject keys on RA series MCU.
In my case, I have download the project for RA8M1 and using board type RA8D1, I assume the project(RA8M1) may work on RA8D1.
Main process according to <8. Example Project for RA8M1 (RSIP Compatibility Mode)> of this application note and previous generation for AES key wrap success according to section 6.1 of this note.
As this example show
In my application is fails:
I've trace this and found it fails at below point:
R_RSIP_AES128_InitialKeyWrap->HW_SCE_GenerateOemKeyIndexSub
Need to mention is that, the first time debug, I use the demo code with ra8m1_initial_aes128_key.c not modified with keys generated by myself, and it seems that the first step(R_RSIP_AES128_InitialKeyWrap) works, but fails in verify_cryptographic_operation_with_psa_api() function.
Could you check what cause:
1. Using demo key in application note success in first step(R_RSIP_AES128_InitialKeyWrap) but fail in second step(verify_cryptographic_operation_with_psa_api)?
2. Using keys that generated by me fails in R_RSIP_AES128_InitialKeyWrap?
UFPK I am using: 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
AES KEY: 000102030405060708090a0b0c0d0e0f
IV: 7BCADD2D955686B6D2433583D8EFBBA4(Random value)
Security key Management Tool operation log:
Output File: D:.....\csource.hOutput File: D:.....\csource.cUFPK: 00112233445566778899AABBCCDDEEFF00112233445566778899AABBCCDDEEFFW-UFPK: 00000000B95A9F847C4B10283E559BCF283D21FAB95A9F847C4B10283E559BCF283D21FAIV: 7BCADD2D955686B6D2433583D8EFBBA4Encrypted key: 682FEE599F5AC58805F714BC4E9F3B3254E642FC80C15B0D65CC2BECB92B3347操作成功
Thanks.
1. Sorry, I ran on EK-RA8D1, the sample passes. Also when I wrap the key a second time, it will pass also.
2. Did you select protected mode when you generate your w-ufpk? It wont work on compatibility mode.
Do you mean only DLM and protected mode works? I checked the display history, and it shows:
So maybe this is suspicious.
An application note sited we need to choose compatible mode:
I have tried using CompatibleMode and generate W-UFPK again, the first step(R_RSIP_AES128_InitialKeyWrap) now works now.
I will check if second step will work then.
The project uses compatibility mode.
I have tried with e2studio 2023-10 and it shows succeed(Default to using FSP v5.1.0). Maybe the reason fail on my side is the e2studio version, e2studio 2024-07(Default to using FSP v5.5.0)
Also, I install FSP v5.0.0 and generate code again, with e2studio 2024-07 the secure_key_inject_ra8m1 project works now.
Could you check if when moving to FSP v5.5.0, key_inject_check() will fail?
In my side, I move key_inject_check() related code to RA8D1 demo project named mbed_crypto_ek_ra8d1_ep, and when import key with psa_import_key()
It reports error code -134, #define PSA_ERROR_NOT_SUPPORTED ((psa_status_t)-134)
Could you check if there is change from FSP v5.0.0 to FSP 5.5.0 caused this issue(psa_import_key() error)?
When try to Upgrade the project secure_key_inject_ra8m1 FSP from v5.0.0(Default) to v5.5.0(latest), it is the same reault:
Any update?
The length of wrap key is used to identify the key type. It was changed internally.
You need to change 48 (12*4) to 36 (9*4)
I am planning to verify this. I will update then. Thanks.
Yes, changed from 48 to 36 could result to successfully import key.
But some other changes need to make for cipher_operation() to success with FSP v5.5.0.
cipher_operation(&operation_aes, enc_plain, BLOCK_SIZE, 16, cipher, 16,
&output_length);
cipher_operation() parameter 16(c_part_size) seems to be required for AES block encryption, 16(output_size) is strange.
In comparison, no change with FSP v5.0.0 needed to run cipher_operation success.
Could you help check if this an issue?