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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

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

1,828 次查看
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 项奖励
回复
5 回复数

1,744 次查看
bschaefer
Contributor I

We are based off LSDK version 20.04

0 项奖励
回复

1,711 次查看
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 项奖励
回复

1,697 次查看
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 项奖励
回复

1,663 次查看
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 项奖励
回复

1,759 次查看
yipingwang
NXP TechSupport
NXP TechSupport

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

0 项奖励
回复