Confused about SRK

[dlliweihua]

Hello NXP experts,

The PKT tree generated by cst tool is as  "CA->SRK->SGK(optional)",

why the burned key into fuse OTP is not CA's public key but SRK's public key?

And in the final signed image, there is no SRK's certificate, that is to say,

the procedure of using CA's private key to sign SRK's public key is only performed

on host computer to generate SRKn_XXX_XXX_XXX_v3_XXX_crt.pem,

and the SRK's public key infos (RSA Modulus/Exponent or ECDSA X/Y)

are written into SRK record in the signed image directly.

When performing seco image verification, the CA's public key never used!

Then, what is the role of CA to the end during the whole process?

Best Regards,

liweihua

[Yuri]

@dlliweihua 
Hello,

  In general, the i.MX HAB CST approach is intended for the case, when there are following
participants:
• A Certificate Authority (CA), which is responsible for protecting the top level CA key and for
certifying lower level code signing keys.
• A Signature Authority (SA), which is responsible for performing the act of code signing.
• A Manufacturer, which is responsible for requesting digital signatures across product
software

   The CST is set of command line tools residing on a host computer which serves as both the Certificate  Authority (CA) and Signature Authority (SA) allowing manufacturers to control all aspects of the HAB  code signing process.

Regards,
Yuri.

[dlliweihua]

@Yuri 

Since CA is used to protect SRK,

SECO should use CA's public key to decrypt and get SRK's public key from SRK's certificate.

Why dose CST not write SRK's certificate into the signed image?

Why the burned key into fuse OTP is not CA's public key instead of  SRK's public key?

Regards,

liweihua

[Yuri]

@dlliweihua 
Hello,

  AHAB implementation may be considered as some kind of optimization.
Note, SRK fuses contain hash of SRK keys.  

Regards,
Yuri.

[dlliweihua]

@Yuri 

1.AHAB implementation may be considered as some kind of optimization.

Is this optimization equivalent to SRK self signature?

2.Note, SRK fuses contain hash of SRK keys.  

Yes,I have noted this point.

Thanks.

Regards,

liweihua

[Yuri · Accepted solution]

@dlliweihua 

    We do not use all trust levels (starting from CA) during
i.MX boot. Further optimization is Fast authentication.
It provides the option to use the SRK to verify the CSF data
and Image data directly, instead of using the CSF and IMG keys.
This reduces the number of key pair authentications that must
occur during boot stage.