Linux kernel version: 4.19
LS1043/LS1023
Hello,
I’m looking into adding support for RFS integrity validation. This would be the last part for securing our products (SecureBoot already working).
I’ve got a POC using dm-verity. The last piece I’m stuck on is protecting the private key used to sign the root hash file.
1. What support is there in linux kernel for creating and storing the private key in a protected manner? I was looking into blob support provided by CAAM/SEC, but currently am stuck. I see the supported features in SEC Reference manual, but no drivers or examples for protecting data across power cycles using blobs.
2. When setting up secureboot and OTPMK, SRK, ITS, etc are programmed but no reset occurred yet, is SEC going to use the proper BKEK derived from SecMon master key derivation key? Or would SEC still be using non-volatile test key as input to BKEK?
3. Are there better options for protecting this private key? This key pair is used to sign a digest (private key in Linux/userspace) and subsequently validate (public key used in uboot) digest upon reset.
We are based off LSDK version 20.04
Please refer to the following update from the AE team.
1. I wonder what private key customer wants to protect by caam blob? symmetric key or asymmetric key?
2. If programmed SRK, ITS but no reset yet, SEC will use non-volatile test key. After reset, BKEK derived from SecMon master key derivation key will be used.
1. Private key of asymmetric key pair, for signing.
2. Thank you- this makes sense. We've validated MOO of SEC module after blowing fuses and reset, see MOO is Trusted Mode.
I've attempted to use a 3rd party kernel module here.
Although it was intended for i.MX, the SNVS support is just a warning about MOO of CAAM, and can be ignored. I was hoping the rest of the operations to support encap/decap would work, but unforunately I was not able to get this solution functional and got errors on attempting encapsulation.
I confirmed with Linux SDK development team.
No plan so far to integrate this feature in LSDK or Linux factory release.
Probably you could contact NXP marking team for paid service support.
Can I know which LSDK version they are using? I'm trying to contact with RD team.