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 <bj...@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+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel