I wonder How to prevent unauthorized access to the zImage, RFS and Finally the application binary that we target to run in CM3 for the Commercial product.
We have given a thought of many possibilities like having the fitImage that composed of many other required images example zImage, RFS, DTB, and Application elf. and verify the signature of individual images one after other by the key enclosed in the u-boot which is responsible to verify the authenticist of every other images to be loaded and placed in the respective place before they are starting for execution. Infact we have a hardware Crypto chip to keep the Public/Private Key pair that we can exercise form the uboot code to fetch the corresponding key exchange. But 1) we afraid what if the u-Boot itself can be replaced to by-pass all the certificate verification and simply load the zImage, RFS and Application by which someone can gain access to our hardware and Application infrastructure?
2) is it possible to secure load the u-boot from the start.elf to ensure that my u-boot itself has not tampered, currently during the Raspi boot sequence the start.elf can simply load any software image either it's a zImage or u-Boot, so replaying it in config.txt can easily gain access over the hardware resources.
Please help me understand any possible solution that Raspi open to secure the booting?
Not sure why you need to protect the zImage. That's the kernel, and it's GPL2 licenced, so you would need to release the source for it anyway.
Unless its simply to stop people injecting their own kernel and taking over the system?
I'd go with a crypto chip, but securing something completely is almost impossible against a very determined hacker.
Agreed. If the device is physically out of your control, then there is no way to defeat a determined hacker trying to extract your data, mainly as the system has to be able to decrypt it (unless you require a boot password, but then the user/hacker has to know that).
If you don't disable the USB slave boot mode (used for initially loading the image onto the EMMC), then you can copy the image back off the EMMC. Even if you do, then the EMMC can be unsoldered and copied.
What would you be using for your crypto key? If u-boot has any notion of the key then the above will mean that a hacker can get to it. Even if you use a crypto chip, then that is present on your board and so they can replay an attack against it by sniffing the interface. There is no "secure" storage for any form of key on a Pi.
IIRC Gordon did add a mechanism for signed boot by comparing the various boot files against a signature programmed into the OTP. The main headache of that is that being OTP you can't upgrade those signed files at all because it would change the signature.
I don't know whether that can be set up to verify the firmware and u-boot, and then let u-boot deal with checking signatures on all the other files, but that is more checking that only your code is running, not protecting it from prying eyes.
Since the start.elf is a closed source and it is the one is loading the further program if the Broadcom opens an API to register the Certificate keys using which the start.elf can verify and load the client software (either u-Boot or kernel). does that give a better protection while loading the untrusted images?
By the way answer to your question on "What would you be using for your crypto key?" we thought to have a hardware-based chip from Microchip to generate Certificate and public/private key.
But where would those keys be stored? The two storage options available are either the SD card/EMMC or OTP. If it's OTP then you get one chance. If it's SD card/EMMC then it's possible to copy it.
Even if we encrypt them before storing them on the SD card, it would be possible to work through start.elf to derive that encryption. IIRC OTP can be read by anyone.
Actually you want to verify signatures in bootcode.bin, not start*.elf.
Srinirajini wrote: By the way answer to your question on "What would you be using for your crypto key?" we thought to have a hardware-based chip from Microchip to generate Certificate and public/private key.
What are you passing through the crypto chip? Are you sure it can't be intercepted and used as a replay attack? Combine a replay attack with a bit of reverse engineering of your application and without a lot care your security is blown apart again.
I'm not an expert so I'm going to drop out of the discussion. The Pi has been designed for education rather than security.
You can put stumbling blocks in to put off the amateur hacker, but stopping the professionals when they physically have the device in their hands is very difficult unless it has some form of crypto built in to the SoC.
There are also the two differing sides to secure boot - protecting the device from running unauthorised code, and protecting the code that is running from being examined. They are two fairly different challenges.
Okay, Thank you for the In-depth view. So to ensure that my u-boot has not tampered, could I keep my u-boot code in OTP, and let the start.elf to load the u-boot from OTP?
1) what is the size of OTP, can it be programmed by the user once to flash the binary, could you please share any document/Tools about/used OTP.
2) or is there an option to make the existing eMMC to make the boot partition read-only and locked for reformat?
the document "SD3.0_Host_AHB_eMMC4.4_Usersguide_ver5.9_jan11_10.pdf" is not visible on the internet could you give a pointer to it.
No, the OTP is tiny, so only enough for a few bytes of information - probably an encryption code.
It appears that the hardware is missing some parts that are needed for truly secure and tamperproof system but maybe it can be still good enough for you?
Apologies if it is not relevant or does not meet your use-case - I've got no experience with secure boot and the like.