Reply was addressed to this post:
I know what you’re referring to, and while there is merit in that, I can tell you right now, chip modification or annexation is still a fair way off. The amount of failed silicon wafers they would go through to make a chip “just for you”, you’d have to REALLY be worth going after to justify the cost…like…Dr. Evil level of worth going after…
Hardware components being added to boards is nothing new, but they’re usually regular component-sizes. But for the purposes of this, let’s assume that these “extra chips” are microscopic. Power source? Connected to what? How does it stay cool (don’t forget that chips get REALLY hot)?
Something that small would be so susceptible to electromagnetic radiation that it’s possible a thunderstorm, your air con, putting your laptop next to your microwave, or even other components already on the board with a voltage jump could fry it. And if it didn’t, it would interfere so heavily with the operation of whatever the chip was doing that you wouldn’t get reliable compute out of the thing…
What definitely does happen is obtaining schematics (a diagram of all hardware components, and how each of them is connected to each other) of the motherboard, so you can compare yourself and identify anything extra that may have been placed onto the board, or missing.
That’s how you mitigate this, for now.
So go pick it up yourself? Accept that it may arrive tampered, and inspect it yourself, or take it to someone who will inspect it for you?
There are many mitigations to all of this…
You have to find that sweet spot between what you know you can achieve yourself, and what you’re prepared to accept other doing for you.
@FranklyFlawless
What you’re referring to as ‘this post’, is in fact, ‘the original post’, or as I’ve recently taken to calling it, ‘the OP’. ‘This post’ is not a post unto itself, but rather another free component of a fully functioning Qubes OS forum thread made useful by the Discourse software, web hosting and vital system components comprising a full website as defined by ICANN. Many Qubes OS users write and modify versions of the OP every day, without realizing it. Through a peculiar turn of events, the version of the OP which is widely used today is often called “this post,” and many of its readers are not aware that it is basically the OP, developed by @JameriquayJohnsonsen. There really is a ‘this post’, and these people are reading it, but it is just a part of the broader thread they read.
‘This post’ is the quote: the reference in the thread that provides context to the other responses that you read. The post is an essential part of a thread, but useless by itself; it can only function in the context of a complete thread. ‘This post’ is normally used in combination with the OP: the whole thread is basically the OP with posts added, or OP/posts. All the so-called “this post” distributions are really distributions of OP/posts.
Couldn’t resist 
2 Likes
I don’t know if this is an attempt at Cunningham’s Law, but I guess I’ll bite anyways. Yes, the system must be booted by something that isn’t encrypted, but that doesn’t mean that you can’t protect it.
Secure Boot is pretty shit, because it locks up your system to a single OS, and it fails silently when you defeat it (since it’s just a go/no go on allowing a system to boot).
What you can do to protect your system is to make sure everything is verified. I think this can be done with grub, and the likes, but my preferred method is using a unified kernel (UKI). This means that initramfs is part of the ELF file UEFI loads when it hands over execution to the OS. When initramfs runs it can give the TPM a policy signed and encrypted by the TPM which says something like “Decrypt this key for me, but only if the hash sum for the kernel matches this hash sum, and the firmware of the motherboard matches this other hash sum”. This is called “measured boot”, and is done by locking your encryption key to specific PCR hashes.
This is still too weak if your threat model includes cold boot attacks, but you can use an external header to encrypt multiple layers without a performance penalty. I would do TPM (with passphrase for updates, let it take a couple of seconds to decrypt), FIDO2, TPM (with a passphrase for updates, same as for the first TPM, but with a separate key), and lastly a normal Passphrase.
It’s not perfectly supported in Qubes, so after every update you will have to restart your computer to get the new hashes, because data needed to precalculate the hashes can’t be read from Dom0. Everything I’ve written above can be done in Qubes 4.2, but FIDO2 support requires you to compare some pros and cons.
(This is written on a crappy phone, I expect there to be some fat fingering.)
4 Likes
Exactly, and then…
Absolutely, or I would be if I were to bother with secure boot, and first deleting the Microsoft, and any other keys, installing my own PK and all the rest needed for verification of grub or whatever is going to verify the next stage. I thought that was taken for granted… is there some other way? And after that, how to get the TPM to send me a TOTP or similar, so I know who I’m dealing with before I hand over my key?
2 Likes
That wasn’t what I meant. What I meant was how you know that your BIOS is presenting you with genuine results of any alleged Secure Boot calculations, and not simply “returning true” and lying to you.
There’s always a root of trust somewhere, and that was my point.
What would be good is if an external device was able to be plugged in at boot time that would do the verification, as opposed to the internal components that have been left unattended. That would allow you to keep it separate from the machine, which might suit more people’s threat models.
I know I’ve just described an EEPROM, but still…
Until that exists and the interactions are tamper-resistant, we’ll just have to rely on the chips on the motherboard to do the calculations for us, I guess…
https://docs.dasharo.com/projects/trenchboot-aem-v2/
https://trenchboot.org/user-docs/install_aem/
3 Likes
By either using static PCR values or by requiring the PCR value to be signed using a certain public key. Secure boot doesn’t really have anything to do with key management, although the secure boot settings are often used for disk encryption (using PCR_7).
2 Likes
TPM 2 works with AEM now, they just haven’t documented it because they haven’t done testing with it.
It seems to work fine on my Thinkpad P53. It detects initramfs tampering and all that. Just make sure that you configure additional SRTM PCRs in addition to the DRTM PCRs and you wuld be a-okay.
The thing you should be looking for right now is legacy boot support rather than TPM 1.2 support.
The tooling to make a UKI and custom key enrollment is readily available in many distros and it is not that hard to make Secure Boot with Linux not complete security theatre.
You can have just /efi and /, with /efi contain only the signed UKI and nothing else.
It is not a cut and clear case of normal Linux/KVM having a worse experience either. Qubes has plenty of quirks, like how the guest agents expects the VM filesystem layout to be a certain way and that the templates behaves in strange ways that normal installs from the ISO do not.
About 0 of them have an actual root of trust so you won’t have any real boot security anyways.
If you want boot security, the 2 laptops you should be considering atm are the Thinkpad T14 Gen 1 or the Thinkpad P53. These are the last proper enterprise laptops with legacy boot support. Both of them go EOL next year though.
Otherwise, you can get a modern laptop and try to implement UKIs + custom key enrollment.
2 Likes
Because its basically circular logic as I already said in that thread.
1 Like