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?
There are no API definition for cipher_operations. It parameter feed into psa_cipher_update where API is stated.in PSA API specs. The psa_cipher_update does allows partial data input and output maybe pended until enough number of input bytes is received. In practice, it is better to process it in fixed blocks as you mention.
The 2nd 48 should have been the size of the output buffer, i.e. 16.
cipher_operation(&operation_aes, enc_plain, sizeof(enc_plain), BLOCK_SIZE, cipher, sizeof(cipher), &output_length);