Roots of trust are difficult
mjg59.dreamwidth.org
mjg59.dreamwidth.org
It's an open silicon root of trust. All the RTL (systemverilog code that describes the hardware), DV (design verification, which is used to demonstrate the functional correctness of the design so you are confident in building a chip with it), documentation and software is open source and available on the repo linked above.
Being able to trust your root of trust is obviously vital and current implementations are proprietary and heavy NDAs required to get any more detail. With OpenTitan you can go as deep as you want to understand what's actually going on.
[...]
> Of course, simply measuring the fact that verified boot was enabled isn't enough - what if someone replaces the CPU with one that has verified boot enabled, but trusts keys under their control? We also need to measure the keys that were used
The motivation for this stuff has always seemed pretty weird to me.
Out of the box, secure boot means your PC only boots things signed by Microsoft. Microsoft has deigned to sign a 'shim' which lets you boot Linux - so long as your kernel is signed by a vendor with Microsoft's blessing, like Canonical. Otherwise, you've got to go into the BIOS and disable Secure Boot - or enrol your own MOK, a similarly manual process, with similar security impact.
I get why this stuff is useful for big corporations making TiVo-ized products, wanting to lock out the device owners. For them, I get that this tech is great.
But if you're a human being - this seems like a whole lot of hassle to... protect against evildoers breaking into your hotel room and replacing your CPU?
Secure Boot - if done right - also prevents malware that gains root access by whatever mechanism of privilege escalation from persisting within the kernel address space.
Another, more ethically questionable requirement is RF laws. Basically some jurisdictions require as part of certification criteria that a transmission-capable device be protected against someone overriding legal limitations for frequency bands or transmission strengths. There's no way out for device manufacturers other than a complete chain of trust including a trusted way to provide a location (to prevent the user from setting a location with higher transmission limits).
You make the baseband processor physically separate from the app processor and run it off of firmware that the application processor can't reflash. All phones do this. Then it doesn't matter what boots up on the app processor, and only the baseband processor has to be certified. Nobody is trying to obey RF laws using Secure Boot on the application processor. There are other reasons for Secure Boot on the AP but this isn't one of them.
RF violations are an FCC guy with an antenna telling you to cut it out. Everything is explicitly licensed by the Feds ahead of time, copyright and computer access usually isn't.
It's a neat trick coz they can put pressure on the OEMs to introduce that friction. They can subtly reward that but fully disclaim responsibility for it when they overdo it (which at least one OEM has done).
The actual security concerns it deals with (e.g. evil maid attacks) aren't entirely imagined but they're played up.
Not really. God knows what the US CBP does to your devices if you hand them over at border control - which is why I refuse (and every other IT professional should as well) to travel to the US until that is taken back. Pry my devices from my cold dead hands.
It's rather sad that these precautions are needed, but here we are. I'm just bringing all this up to say that there are ways of travelling without having to put your devices at risk of compromise.
And there's the entire import duty/customs stuff to work out as well...
I think the risk of that with mainstream parcel carriers is pretty low. But I understand the hesitation, for sure.
> getting refused entry and being deported (and thus, losing the many thousand dollars one needs for a vacation in the US) for being "suspicious".
I have no idea what does or does not mark you as suspicious enough to be denied entry, so I can't comment on that. But if it's a vacation trip, then do you need to take electronic devices at all? Aside from a cell phone, anyway, but if you're concerned about the device being compromised, surely that cell phone doesn't have to be the one you use when you're in your home country.
Anyway, I'm not arguing with you even a little, and I hope I'm not coming off as unsympathetic. At heart, I agree with you that everything you're saying is a real problem that needs real solutions. I'm just looking at how to reduce the problem in the meantime until/unless real solutions come about.
So, AFAIK, shim/MOK, breaks all this. As a root user it then becomes possible to enroll custom keys that allow a 3rd party, or the machine owner (or exploiter) to add code to the boot path nullifying its greatest strength IMHO, which is protecting the boot chain from a root level exploit.
At that point the only protection would be a TPM + 3rd party root of trust, that notices the shim measurement of the next stage isn't one that has been reported "safe". Which doesn't exist in linux land, outside of possibly some large corps that have taken ownership of the entire thing for their own internal purposes.
For example, to install DKMS modules like nvidia drivers.
Or indeed to exercise your right to run any code you like on the system you own.
I guess from the perspective of laptop and desktop PC makers who primarily ship devices with Windows preinstalled, they just don't want to bother with separate product lines for business versus personal use.
For what it's worth, I can't speak to what is common versus not without real data, but at least from my own perspective, every non-laptop PC I have in my house is a machine I built myself from parts, and no motherboard I have ever purchased came with secure boot enabled by default.
This is separate, of course, from Microsoft's decision to make Windows 11 only run on devices with a TPM.
I'm thinking of enterprise grade networking hardware for example. Their main OS ROM is encrypted and they will refuse to decrypt if the boot process is altered.
There are no real secrets or user data being protected by the encryption. Heck, actual passwords and user configurations can be stored in clear.
It is about protecting against "after hours" production runs. If you, as a vendor, order manufacturing 1000 pieces of widgets, you want to be sure that only those delivered to you are really produced. You don't want more, and then your own product competing against you on the market.
Hence, encryption. Only your devices can run your firmware. All those extras cannot.
Enjoy all the benefits of keeping stuff to yourself I guess.
Bonus: potentially lowers the barrier to entry to electronics fabrication as more engineer hours are spent getting the fabrication equipment/processes better documented/more accessible.
No one wants that though. That'd make too much sense.
How else can the machine tell who is its rightful owner?
In that case the user isn't trusted, not because of maliciousness, but because of security mistakes, which are quite easy to make. Having attestation to prove the device is not tampered with before letting it connect to the company network is a good idea.
Individuals don't have quite as much to benefit from. I don't bother to run SEV on my personal cloud VMs. Mostly because it's more likely for there to be enough software 0-days to not offer much practical protection. If I was trying to do cryptocurrency in the cloud on top of seL4 or something equally verifiable then maybe SEV/SecureBoot would be worth it?
Foundations are best stable, as in unchanging. But few foundations can live up to that. Indeed, with our knowledge of how the very earth is dynamic, it is funny that we maintain the ideas of foundational stability on it.