Hi,
I have a few questions concerning the secure boot on 1469x. I've been trying to get the dev kit to boot using a secure image. I haven't had any luck with getting it to accept my image that is comprised of a product header, fw image header, and binary. My setup is the following:
- Stored ed25519 public key in the OTP signature payload area
- Stored a AES256 key in the OTP QSPI FW decrypt area
- Produced a product and fw image header following the specifications in the data book. I had to do some trial and error to get some of the fields to work and for it to be recognized properly in the SmartSnippets toolbox QSPI header tool. But I clearly still have something wrong, as my image won't boot.
So for clarification I'd like to know a few things about the stored format of the OTP keys and some of the header field contents.
1) From the code snippets, it appears keys are to be stored 4 bytes at a time in little endian format. So if I have a key that starts with '0011223344556677...' then it gets stored as '3322110077665544...' Is this correct?
2) In the header fields, it appears from experimentation that most if not all multi byte fields are little endian (regardless of the lack of a LE in the description). This includes the section lengths for the security and signature length fields. Does this also apply to the nonce and signature?
3) ECC and symmetric key indexes are 0 based (first key would be index 0)?
4) The fw image header size field in the SmartSnippets toolbox help says the size includes the header. Is this correct? This would mean that for a fw hdr at 0x2000, with an ivt offset of 0x400 and a binary size of 0x4000 the size would be 0x400 + 16 (IVT) + 0x4000 (image size).
5) The fw image CRC is computed over what? In the product hdr it was just the product hdr itself. Is this computed over the IVT + image? before or after encryption?
6) Is the nonce field the first 8 bytes of the IVT?
7) Is the IVT encrypted? The document infers that it is in the diagram.
I know it's a lot of questions, but I am trying to nail down what I am missing.
谢谢，
Andy
Hi agross,
Thanks for your question. Someome from the Team will get contact with you direclty.
Regards, PM_Dialog
Ok. I found the mkimage tool and figured out some of the answers to the above questions. I still have an issue with the signature generation, but I'll get to that. Let me add the answers I found to the above questions:
1) Keys are indeed stored in little endian mode 32bits at a time. Verified this using the mkimage tool with my key pairs I had programmed to the OTP.
2) No. The nonce is just stored as a byte stream. Not sure on the signature.
3) Keys are 0 based. Found this through experimentation and also through a document on a different SoC.
4)我所知,附近16字节的早期doesn't exist at the front of the provided image when using mkimage. It does pad the image to the nearest 16 bytes. That really isn't necessary though as the AES256-ctr doesn't require padding. So the length is just the binary image + padding.
5) CRC is computed over the ecrypted image.
6） Nonce是前8个字节。用于加密的IVT是上8字节中的Nonce，下8字节中的0
7) The mkimage doesn't put the IVT in, so this really doesn't matter. The image is just the image with some padding (not sure if necessary).
I cannot reproduce the signature that the mkimage is creating for my binary image. The mkimage output does boot fine on the system once I add a product header. I am not sure what the signature is being computed over but i don't think it's just the image. I don't have a revocation block, so according to the datasheet it should just be across the image itself.
Update:
The last issue has been resolved. The signature is computed over the device administration area, the padding, and the attached image. This happens regardless of whether or not you have a zero length device administration area.