Secure Boot / OTP / Encrypted Boot

[james]

Very interesting design!

For embedded applications, I'm interested in what facilities the chip has for booting from encrypted code/text.

I'm assuming its a broadcom device going by a few indicators

Is there support for setting boot encryption keys in OTP (non readable) memory?
Is there a JTAG or similar port, and can it be permanently disabled via burning a fuse?

Cheers

[ShiftPlusOne]

I am guessing that's not built into the chip, but since it's linux, you can always encrypt the root fs and decrypt it using an initrd image.

[james]

Thanks ShiftPlusOne for your conjecture -- what you describe is how later stages of some chains of trust work. However without a stronger root of trust (eg hardware sealed encrypted boot loader), it only takes minutes to extract the key from the plaintext boot loader and decrypt the root fs.

So I'm still interested in the answer to the original question. For example the Tegra2 and many SoC's in STBs and smart phones support an embedded encrypted bootloader mechanism or OTP keys (which cannot be changed or easily extracted -- where easily means less than hundreds of hours or more of work).

So I'm still interested in the particular SoC being used to verify the possibilities of a secure boot chain.

[ShiftPlusOne]

Yeah, I'd be interested in the answer as well. However, I didn't mean that you'd store the key anywhere on the device. Normally you have to enter a password or have a flash drive with the key file on it inserted in order to boot(or both). I get what you're saying though, it doesn't sound like this is what you're after at all... just throwing it out there.

[james]

Gotcha. Yeah I should have been clearer. I'm after software-protection / tamper-resistance scenario (ala xbox/STB/ps etc). Rather than Privacy protection ala On-The-Fly-Encryption like Truecrypt, or something like TAILS (https://tails.boum.org/).

[Svartalf]

Quote from james on August 3, 2011, 02:57
So I'm still interested in the answer to the original question. For example the Tegra2 and many SoC's in STBs and smart phones support an embedded encrypted bootloader mechanism or OTP keys (which cannot be changed or easily extracted -- where easily means less than hundreds of hours or more of work).


Part of the nature of that strong trust chain is a bit of security by obscurity. You're going to have to be a licensee of the given tech before they hand you the means to produce a locked down bootloader.

[james]

My experience having worked on some secure boot chains commercially is that the "obscurity" portion only exists with regards to business strategy, hiding weak designs or physical security (eg. not giving away too much about the physical structure to prevent Christopher Tarnovsky style attacks).

The business strategy portion relates to hiding the technical information to delay patent infringement claims (eg. someone using ECDSA or authentication-encryption like OCB). There is a reluctance from some manufacturers to disclose their methods widely. Another reason is hide an inherent weakness so they can claim effectiveness from a business viewpoint, when infact the design offers no serious protection.

The strongest trust chains expose their logical structure transparently so they can be measured under sustained attack. When a chip vendor hides it, its usually due to hiding a weakness.

Most of those vendors in the STB space have pretty good secure boot support because of DRM, codec licensing and grey market issues.

So there is no technically good reason to rely on obscurity, but there may be some business reasons to do so.

From what I can gather this particular Broadcom SoC is booting via GPU code. I'm assuming there is a OTM, EEPROM or ROM embedded in the device. Assuming it can be written too and locked from reading and any JTAG ports can be shut down. Then it should be pretty secure.

[eben]

The device has support for secure (signed, encrypted) GPU boot code, with keys burnt into OTP at manufacture. We'll be implementing this feature in the first devices, but are unlikely to extend the chain of trust into ARM-land until a later firmware revision, when we understand customer requirements a little better.

[marked]

so you could incorporate a trusted boot with a hypervised kernel to give a contained and constrained environment that won't allow kids to build their own DDoS machine, by locking down certain aspects of networking, for example?

[eben]

Conceivably. I think there's a *lot* of work involved in doing that though, and as we're always going to support booting a bare-metal OS or non-hypervised kernel kids would always be able to get around it by using a different SD card image.

[nicodemus]

eben, can you provide help in using the secure boot feature? Can anybody provide help there?

[kirgene]

I have the same question. Will it be possible to use secure boot?
Is it even possible with this hardware?

[mimi123]

I have the same question. Will it be possible to use secure boot?
Is it even possible with this hardware?

There is Secure Boot on the VC4 part
Including encrypted suspend/resume RAM
However, I don't know if a blob verifying the Linux kernel signature is existing

[kirgene]

I have the same question. Will it be possible to use secure boot?
Is it even possible with this hardware?

There is Secure Boot on the VC4 part
Including encrypted suspend/resume RAM
However, I don't know if a blob verifying the Linux kernel signature is existing

Could you explain it in more details, please. What's VC4 part? Is there any info I can read regarding it?

[chronos00]

I have the same question. Will it be possible to use secure boot?
Is it even possible with this hardware?

There is Secure Boot on the VC4 part
Including encrypted suspend/resume RAM
However, I don't know if a blob verifying the Linux kernel signature is existing

@mimi123
I am also interested in this. Can you provide any more info?

Thank you!

[Tombosco]

Hi guys

Me as well! Is there a solution for this issue?
Secure boot with OTP register or something similar?
Specially if you use the RasPI as module with integrated eMMC and
not with the external SD-card.
Would be nice to get some hints for that one...

Thanks guys.