Hacker News Reader

Comment by greenavocado | Hacker News Reader

Congratulations on the development. Part of me is concerned that this will be used to push devices that cannot be unlocked and tinkered with by end users, reducing their technological freedom.

View on HN

The purpose of this bootloader is to avoid executing malicious code sent over the internet, such as by a MITM attack.

The author explains that it does not attempt to defend against hardware attacks or attempts to replace the bootloader:

> SentinelBoot's threat model focuses on thin client devices which do not store their own OS and over-the-air updates (e.g. how phones are updated): both of these cases involve executable code being sent over a network, usually the internet. We ignore the risk of direct hardware modification, as an attacker can just swap out the bootloader (making any potential defence implemented by SentinelBoot in vain).

That shift has already started in various areas.

You see it with phones but also with cars where OEMs require Secure Boot enabled devices when possible. This ranges from the central unit to all small ECUs.

You can kind of see it pushed for desktops as the default mode but at least there for now you usually have a way to disable it.

For embedded devices though they never really provide a way to disable it. I think you could find a compromise where you could provide a physical method to disable it. If you disable it you clear all the DRM keys and other secrets. This way you can still protect against malicious updates for most users and tinkerers can do what they want once the company stops supporting it.

This was going to happen regardless. I believe Nvidia's RISC-V coprocessor ships with hardware fuses that serve more-or-less the same purpose.

If anything, it just makes me glad that RISC-V also has specs for UEFI-like interfaces.

Many (most) devices with secure boot have hardware fuses, but the software that reads them is usually broken. Rust and an eye towards sound cryptographic primitives (especially against side channels) will definitely go a distance towards protecting against this, although logic bugs are also quite common.

This bootloader doesn’t actually seem to be a real secure / trusted boot implementation anyway, just a thing that verifies updates.

What is the story with rust and cryptographic side channels? I imagine the layers of abstraction (e.g. an iterator may have arbitrary O) would make it harder to see those?

The layers don't really matter. Any side-effect or implementation detail (especially in a language with an optimizing compiler) is not a good protection against side channel attacks.

Where Rust (and most languages with a robust type system) can help prevent side channel issues is via typing - all cryptographic operations in a given library can be implemented with (for example), a TimingSafeU32 type that only implements constant-time operations (comparison, multiplication, addition, etc). This massively reduces the opportunity for mistakes. Traits make implementing this type of system much easier and more elegant.

`rust-timing-shield` and `subtle` are both a good example here, as well as really everything in https://github.com/dalek-cryptography .

I'd be more worried about early exits from loops in an iterator, e.g. if you had a .any() derived function, or short-circuiting logic in boolean operators with a lazily evaluated second parameter. A type system won't protect you from that.

Or maybe an early return and having an expensive destructor called as it goes out of phase with RAII

I'm sure that's part of the story, but there's tons of boring old company/government equipment out there in the world that wants secure boot too.

That'll happen with permissive licenses

That's what it's for, make no mistake.

Those who sacrifice liberty for safety will receive and deserve neither.

Reminder that quote is so out of context that the actual meaning, as it was intended, is wildly different.

https://techcrunch.com/2014/02/14/how-the-world-butchered-be...

https://news.ycombinator.com/item?id=5268899

https://www.npr.org/2015/03/02/390245038/ben-franklins-famou...

I am sorry if I have caused any misunderstanding; the point I was trying to make is that, as ownership is a nebulous concept, yet one that must be protected, one with physical access to a device ought to be able to do whatever they want to it. To imply that bootloader locking is not primarily used to restrict what the owner of a device is able to do with it is disingenuous at best. I fundamentally disagree with the concept of bootloader locks in general under the idea that the evil that corporations are able to enact with them has historically far outweighed the real life security concerns that they actually protect users against. I understand this may be a controversial viewpoint but personally I feel (opinion) that the erosion of ownership is one of the most important issues we face today.

Reply on news.ycombinator.com