Measured boot > trust chain through signature verification:<p>With measured boot, components in the boot chain tell some trusted component (e.g. a TPM, possibly in FW) about all of their input and only if the hashes at the end match, $something is accessible (in most cases a secret key for data decryption).<p>1. More flexibility (with TPM e.g. you can "seal" a secret against different parts independently)<p>2. No need for PKI, which gets very complex once revocations are involved (have fun looking at the "Secure Boot" DBX lists and the shim SBAT mechanism)<p>3. More freedom: The system still boots if the measurements don't match, you just don't get access to secrets. You're free to seal your own secrets against your new measurements and whoever did the last sealing has no access anymore. (Unlike on PCs where the Microsoft trust is in most cases not removable).
tbh I feel bad for the kid, his thesis supervisor should have helped him more here to scope and direct the work in some sensible way. now it is bit of a mess :(<p>like just doing a review and comparison of existing boot verification mechanisms would have been already good scope for a thesis. Instead they are barely even mentioned as a side-note, which puts this in a awkward position.<p>or if crypto was focus, then putting more work on designing and implementing the crypto scheme would have been relevant. Now they got so tangled with the nitty gritty boot details that the crypto ended up also as questionable side-note.<p>or if rust was focus, then just implementing clean pure-rust bootloader could have been already enough for the thesis, avoiding the stumbling over on misguided crypto bits.<p>or many other ways this could have been more successful. overall it now feels the author ended up biting far more than what they can chew. also they should have imho spent less time coding and more time on editing the actual thesis. the text is all over the place.
I don't get the "1/10 size of U-Boot" argument. As it can only boot 3 RISC-V64 boards via TFTP, it also has less than 1/10 of the features and supported hardware of U-Boot. <a href="https://github.com/u-boot/u-boot">https://github.com/u-boot/u-boot</a>
The problem with Rust in the boot process is that it's going to become much harder to find vulnerabilities for roots/jailbreaks. Still, this is great work!
That is I've impressive final year project, nice work!<p>Vector crypto is very cutting edge too. I guess there isn't any hardware that has it yet...
This is a very specific type of bootloader for devices that get their code over the internet:<p>> 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).<p>The author readily acknowledges that it does not defend against hardware modification. The other comments here trying to vilify this project don't understand what it is supposed to do.
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.
"cryptographically secure bootloader" is a meaningless phrase.<p>They mean a boot loader that validates cryptographic public key signatures of the loaded component. That would be a secure cryptographic bootloader. AFTER they have proven that it is, in fact, secure.<p>You can't just write some code and then say it must be secure because Rust was involved.