Srinirajini wrote: ↑
Tue Oct 09, 2018 10:46 am
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?
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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.