Hi all,
we are migrating our old firmware based on Linux Kernel 4.14 to 5.15. As it can be seen in the AN12714 rev 0 and AN12714 rev 2 notes, the way how to generate keys with/for the CAAM has changed.
The 4.14 way was something like
keyctl add caam_tk seckey "new ecb 16" @s
which generated a key in the format
:hex:85c121ef4834be7621c86fa6d3db638cee5dc4efaad8a0240f64bf8...
With 5.15 you are now using
caam-keygen create randomkey ecb -s 16
which generates two binary files: key + key.bb
As far as I tested it, you cannot load the "old" key with keyctl running on the new kernel, due to missing caam_tk drivers.
So how should this be dealt with?
Can I implement the caam_tk driver in the new firmware with kernel 5.15?
Can I convert the old key into the binary format?
Is there another way of loading the old key in the new firmware?
Any help is appreciated!
Thanks, Benjamin
Hi! Same problem here, and no, we can't regenerate it. We need a way to convert the old black blob to the new format
Or even "just read it". If somehow the old key can still be read into keyctl (the old method does not seems to work anymore) that would be more than enough.
Hi @lisandropm,
we solved this issue in another way:
1. We start the old system and mount the encrypted partition with the old key (keyctl).
2. We create a encrypted container on an unencrypted partition and copy all relevant data to the container.
3. We update the device, start it and overwrite the existing encrypted partition with a new key (caam-keygen).
4. We copy all data from the container to the new encrypted partition
This process has some drawbacks, esp. when you don't have enough space. But it seems to be a save way to transition from the old keyctl to the new caam-keygen.
Best Regards
Benjamin
Thanks! Sadly that's what we are trying to avoid, we have a HUGE space issue.
It's a known issue that they are not compatible.
Can you try to generate it in new BSP?
Best regards
Harvey