OpenWrt One / project update

Daniel Golle daniel at makrotopia.org
Mon Apr 29 13:05:15 PDT 2024


Hi Michael,

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

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.

Believing that secure boot could provide protection from malware also misses
an important point: Most malware nowadays doesn't even strive for
persistency but rather relies on exploitable run-time vulnerabilities.
We are in an always-online world, the classic "boot sector virus" is
an archaic thing from the 1980s.

Hence, a simple reboot would get rid of most IoT malware already today
and without secure boot, as leaving a trace on the flash would make the
infection recognizable: Cutting the power and dumping the content of the
flash is easy for malware analists. Dumping the content of the (DDR4)
RAM of a rootkit'ed system is not at all, it's nearly impossible.

The only really meaningful way to enhance system security on a technical
level is hence to reduce the attack surface and makeing sure the system
cannot be exploited at runtime. That means a whole lot of things,
ranging from human and machine review (ideally formal verification),
reproducible builds and a cryptographically trusted supply chain down to
language guarantees such as memory safety, making sure the code is easy
to understand, always keeping complexity as low as possible and much
more.

As secondary measures the principle of least privileges should be
applied, sandboxing, memory address randomization, .... even mandatory
access control systems like SELinux all have their place there.

Needless to say that there have also been vulnerabilities in the secure
enclaves as well as their secure operating systems, and that offered a
whole new dimension to nasty and persistent, and hard to detect malware.

So while I can see that having stuff like measured boot and TPM
encrypted credentials is generally nice to have, it quickly becomes
obvious that all that only works on a trusted computing environment, and
even then is only moderately meaningful if you consider the common
malware attack vectors: If an endpoint can authenticate my client using
credentials protected by a TPM or secure enclave, so can anyone else
*temporarily* in control of the client system at the same level of
privileges. And measured boot would not provide any meaningful way to
prevent that.

I think the recent increase of rather simple two-way-repeater attacks on
things like contactsless (and PIN-less) NFC payment systems as well as
car thefts aided by repeating Keyless Go demonstrates that point very
well.

Imho the whole secure boot fuzz is mostly about protecting the system
and its *remote* operators ("platform providers") from the actual users.
It's really very useful for that: SaS and other kind of intellectual
property licencing and subscriptions businesses. Things like Widevine
which is made to prevent users from source-ripping 4k HDR video content.

All that being said, I still believe it's important to have the core
components of all that stuff available as reproducible free open source
software, so people can learn how it all works and play with it
hands-on, just because it became ubiquitous in modern life and not
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.

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

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.


Cheers


Daniel

> 
> --
> Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 





More information about the openwrt-devel mailing list