AnsweredAssumed Answered

Managing HAB Fuses on i.MX 6 quad

Question asked by Todd Goodman on Oct 21, 2015
Latest reply on Oct 23, 2015 by bpe

Hi,

 

I'm implementing HAB (secure boot) in our i.MX 6 product and have a question about managing the HAB fuses, specifically the SRK fuses.

 

I think I may be misunderstanding something.

 

So, to start from the bottom, the OTP fuses can only be programmed to flip a bit on (1) from (0) and once that's done it cannot be changed back to a (0).

 

This is fine for single bit fields.  But when there are more than one bit in the field (e.g., the MAC address fields or the SRK hash fields) then there are lock fuses that can be used to stop any programming of those fields covered by that lock.

 

If the lock fuse is not burned then it is possible for someone to blow the unblown fuses in the field (e.g., if a MAC address has a byte with value '0x04' they could change it to a '0x05' by burning the low order bit.)

 

This is especially a problem for the SRK hashes as it would allow someone to burn bits to generate a SRK hash they can then find a private key to use that results in that hash and then they can generate signed images that would be accepted by the ROM.

 

So, the field lock for the SRK hashes must be blown to be secure.

 

However, the i.MX 6 supports four SRK hashes and has the ability to revoke up to three of the SRKs.  This is an important feature since if our private root key is compromised it's important that devices in the field be able to revoke the SRK hash associated with that key and a new one be programmed.

 

But if the SRK lock fuse is blown then the SRK hashes cannot be programmed afterwards.

 

What we'd like to do is use one key/SRK hash, release with that and if the private key is compromised, then program a new SRK hash for a newly generated private root key and revoke the old.

 

But unless I'm missing something (very possible,) all four SRK hashes must be burned at once and then the SRK lock field burned for the security reasons outlined above?

 

This means generating all four private root keys ahead of time making compromise of all of them much more likely (since it's impossible to compromise a private root key we haven't generated it must be more likely if we have to generate all four at once.)

 

Obviously, private root key management is extremely important.

 

But am I correct in the above?  Do I have to burn all four SRK hashes at once if I'm going to blow the SRK lock fuse?

 

I welcome any corrections for misunderstandings I have.

 

Thank you!

 

Todd

Outcomes