measured boot / fTPM and OpenWrt One

[Michael Richardson]

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)

    > 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.
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.

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.

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 :-(

    >> 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 ;-(

--
]               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    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20240510/b9621c49/attachment.sig>