SEC/CAAM blob support for non-volatile user data protection

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SEC/CAAM blob support for non-volatile user data protection

1,052 Views
bschaefer
Contributor I

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. 

0 Kudos
Reply
5 Replies

968 Views
bschaefer
Contributor I

We are based off LSDK version 20.04

0 Kudos
Reply

935 Views
yipingwang
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply

921 Views
bschaefer
Contributor I

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.

0 Kudos
Reply

887 Views
yipingwang
NXP TechSupport
NXP TechSupport

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.

0 Kudos
Reply

983 Views
yipingwang
NXP TechSupport
NXP TechSupport

Can I know which LSDK version they are using? I'm trying to contact with RD team.

0 Kudos
Reply