measured boot / fTPM and OpenWrt One

[Daniel Golle]

Hi Michael,

On Fri, May 10, 2024 at 03:03:27PM -0400, Michael Richardson wrote:
> 
> Daniel Golle <daniel at makrotopia.org> wrote:
>     > On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
>     >>
>     >> {sorry for the long delay, been unwell}
>     >>
>     >> Bjørn Mork <bjorn at mork.no> wrote:
>     >> > Maybe it is possible to deploy the system with secure boot and a
>     >> > protected IDevId key by default, but allowing the user/owner to erase
>     >> > the key and disable secure boot?  This way all use cases could be
>     >> > supported, including playing with the BL2 code etc.
>     >>
>     >> It won't work that way.  If someone can easily turn off secure boot, then so can malware.
> 
>     > Malware cannot remove or add a physical jumper or press a physical button
>     > on the board (we got a jumper to write-protect the SPI-NOR flash).
> 
> Well, that's certainly true.  It is not always possible to talk to the
> outside world from inside that initial boot enclave.  That's the detail that
> we need.
> Do we even have a spare GPI(o) pin that can be used for this?
> (It can't be used for anything else)

While I see your point and believe this is generally possible, it's more
than just one bit needed here: It would mean to move the whole GPIO controller
into secure land and then make all the other bits again available to non-secure
land via SMC calls or something like that...

> 
>     > The only option of having secure boot enabled would be to allow users to
>     > permanently disable it, otherwise the resulting hardware would not be
>     > worth being called "Open", as it would, in fact, be closed.
> 
> The board could ship with it disabled, and the user could blow the fuse to
> enable it.

If the fuse was documented or the tool for doing this available without
signing an NDA with MediaTek, then yes. Both is currently not the case.

> I am not really a fan of secure boot, I prefer measured boot.
> To get that, we need to have a possible fTPM enabled, and this generally has
> to happen before u-boot.  This is annoying, I agree.
> 
> If you look at the diagram at:
>   https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/boot.html
> 
> which is *not* our CPU/SOC, but is probably consistent with things, then you
> see that to get fTPM, it happens before u-boot.

Yes, it's exactly the same on the router SoCs, or it least it *can* be
done like that (TF-A as trusted boot firmware). I've also seen U-Boot
instead of bl2 loading BL31 and OP-TEE, but that's probably considered
legacy stuff from the last decade.

> 
> Some would argue that a board that ships with a private key in storage that
> is not, at ship-time, protected, is worthless, but I disagree.  It's a
> risks/benefits tradeoff.
> (Note: I'm the lead editor for RFC9334)
> 
> I've been down this road a few times with other boards, and the supply chain is
> generally very difficult to work with on this.  This is one reason I would
> really like to make some progress here.   It helps us get in front of the
> situation,   providing a good reference on how to do this sanely.
> 
> And because I think that many of our (other) platforms will find themselves
> thinking they are forced down the secureboot path by recent UK, USA
> legislation: probably not quite literally by the legislation, but the lawyers
> and PHBs will think it.

It's a bit funny that the blame for that curse commonly goes to the
FCC and UK authorities, because the discussion started with the ETSI
Radio Emissions Directive (RED) 10 years ago...

> 
> I've removed the rest of your well-thought discussion about minimal security.
> What I care about it getting an initial credential into the device, and to be
> able to leverage that to get HTTPS for the admin interface, and for that to
> lead to APIs for managing IoT devices.
> 
>     > dealing with it kinda means living in denial and darkness. Hence,
>     > despite all the critizism, I do appreciate your work and effort to allow
>     > people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
> 
> Yes, so this one place that is very hard for people to learn about, because
> the pre-uboot steps are hidden :-(

ARM TrustedFirmware-A is easy to understand code and released under an
Open Source license, we build it from source in OpenWrt for that platform.
OP-TEE is an Open Source project as well, and so is Microsoft's fTPM.
Just got to put the pieces together, but the pink elephant are the missing
documentation and tools for the efuses to make the BootROM validate bl2
signature...

> 
>     >> I hope we can go the other way.
>     >>
>     >> I'm willing to do the legwork, and I can sign an NDA if necessary, and then
>     >> communicate what needs to be said.
> 
>     > NDA with whom? MediaTek?
> 
> Yes, probably it is required.  I'd rather not, but if necessary someone has
> to figure out how to leverage the details out.
> 
>     > When it comes to OpenWrt and the OpenWrt One: As a first step we would
>     > have to come up with the methods to run the necessary PKI infrastructure
>     > in a democratic and distributed way, without requiring any NDAs and
>     > without any single point of responsibility or potential bus-factor.
> 
> Yes.  I think that there are some reasonable options.
> I had hoped to chat about this over beer at the summit, but in the end,
> I've had to cancel my travel ;-(

I hope that discussion will happen anyway in the near future.
Sorry to hear you are not coming to the event :(

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>