4 ms·

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 primit

by bri3d 2y ago

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.

throwawaymaths 2y ago
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?
- bri3d 2y ago
  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 https://github.com/dalek-cryptography .
  - throwawaymaths 2y ago
    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

4 ms·

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 primit

by bri3d 2y ago

throwawaymaths 2y ago
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?
- bri3d 2y ago
  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 https://github.com/dalek-cryptography .
  - throwawaymaths 2y ago
    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