just realized that all linux full-disk-encryption tutorials which suggest using GRUB and LUKS1 for /boot, then storing a binary key for rootfs on /boot so you only type a password once are effectively downgrading LUKS2 security back to LUKS1 levels.

that seems Bad. why was this ever recommended by any distros?

@domi what in the world

@domi i actually didn't read this kind of tutorial before
usually the boot part just gets left out of the equation

@domi is there even any good way to have an encrypted boot partition

@weirdtreething well GRUB2.06 onwards supports LUKS2, but only with PBKDF2. If you want argon, tough luck?

@twinspin6 i skim over them briefly every time i setup LUKS on anything that’s not alpine, because I always end up tweaking initramfs somewhat

ADHD wins again

@domi is the key just lying there unencrypted after boot?

@tastytea @domi yes

@domi actually i just realized you could use linuxboot. you wouldn't even need /boot on a different partition.

@tastytea i mean.. yes, but how else do you implement that? this is not the issue

an attacker with just the partition dump has two options: crack the LUKS2, which probably uses argon2id derivation. Likely infeasible within our lifetimes

or crack the LUKS1 key, and get the LUKS2 key for free. Feasible for short passphrases

@weirdtreething linuxboot wins again

@ellis @tastytea but that’s not a problem! you’re not supposed to have it world-readable, and if you’re root, you might as well dump /dev/kmem and extract the master key from there.

@weirdtreething @domi do you need encrypted boot if you have some way to make sure that everything you start is signed?

@twinspin6 @domi I just have unencrypted boot. My threat model is not a nation state evil maid, but someone nicking my laptop and reselling it to have money for drugs

@piggo @domi true that

@domi @tastytea oh i have seen lots of people who have world readable /boot and everything in there is world readable too.

@ellis @weirdtreething there’s currently no way to do this on the PC platform without putting endless trust in your vendor. Coreboot more or less exempt, altho that’s a niche

@weirdtreething @domi even with uefi?

@domi @weirdtreething but the part of the bootloader that decrypts boot needs still to be trusted.

@ellis @weirdtreething what’s your point, exactly? This is what I wrote.

@domi @weirdtreething
hmm but is there a way to have encrypted EFI Sy^W^W encrypted coreboot payload in the motherboard flash?

@wolf480pl @weirdtreething no. where would you keep the keys?

@ellis @domi yeah you should be able to build linuxboot and put it in a uki

@domi @ellis problem is someone can take your device and flash a backdoored coreboot build to it

@weirdtreething @ellis i’m painfully aware

if you’re worried about evil maid, paint your screwheads. Nothing beats a physical intrusion indicator

@domi @weirdtreething

@domi @weirdtreething
btw. what's the benefit of encrypted /boot ?

@wolf480pl @weirdtreething that nobody can trivially modify your kernel/initramfs, i suppose?

of course, they could still modify the GRUB decryption stub. the goalpost never stops moving

@ellis @weirdtreething
No, you don’t need encrypted boot. With encrypted boot you need to have grub signed (only grub is capable of encrypted boot, with the downsides that @domi described).

For everything else you’ll need to make a unified kernel image because it’s not possible to sign the intramfs.

@domi @ellis if you could setup bootguard yourself this would be fine. but i dont think that's possible?

@domi @weirdtreething
it stops moving when you BootGuard, but we don't want that od we :/

@wolf480pl @weirdtreething it literally doesn’t! that just shifts the goalpost onto some bloke at Intel

@domi @weirdtreething
wait what?
oh, because it's PK instead of hash?

@wolf480pl @domi bootguard is only cool when we get to control the keys on our own devices

@wolf480pl @weirdtreething no matter if it’s a hash or a key, something somewhere has to be stored unencrypted to verify that hash. you also can’t inspect that code, so you’re left trusting that Intel Corp. hasn’t given the keys to a nation state wanting to pwn your device

or, less nation-state, that your vendor didn’t have a leak two months ago

@weirdtreething @domi
in theory
if there was some way to independently check this

you could fuse into the CPU the hash of a single blob
and have that blob have just enough code to hash the next stage, send that hash to the TPM, and execute it

then you could run any firmware/OS you like on top of it, but you could also bind TPM secrets to the boot chain... including a way for the boot chain to authenticate to you before prompting you for disk password, HEADS-style.

@domi @weirdtreething
yeah you'd have to have a way to verify the bootrom...

oh, but there could be a silicon backdoor that lets the attacker skip attacker-selected jump instructions, including ones in the bootrom

so yeah, the buck never stops

@domi @wolf480pl guess i need to start making my own cpu without any backdoors

@domi @wolf480pl @weirdtreething TPM? But still kinda lolno

@wolf480pl @weirdtreething @domi I mean, that’s already kinda how it works if implemented properly?

@wolf480pl @weirdtreething say it with me

👏 TPM 👏 is 👏 NOT 👏 secure 👏

as long as it’s a separate chip that you can probe with a signal analyzer, you can pwn it. and it has been done before, and it will be done again

I accept trusted elements inside SoCs, because as long as the bootrom doesn’t have a gaping hole (greets to nvidia tegra :^) then it’s somewhat secure.

it’s a chicken and egg problem. i think the point of this thread has been reached: *you can do this all day, and you won’t find a valid strategy that doesn’t at least partially rely on obscurity. The trick is to make a choice on where you draw the line, and hope that your strats help you not get pwned

@wolf480pl @weirdtreething (aside - i don’t think that any platform with encrypted firmware actually uses TPM for the key, i’d imagine they just store it inside the bootrom)

@domi @weirdtreething @wolf480pl

But we can modify the GRUB decryption stub, said Toad

That is true, said Frog

@ellis @domi mhm, some (many?) entities have a combined /boot and EFI partition as FAT32 for example…

@tastytea @ellis irrelevant, you can’t have EFI on encrypted /boot

@domi @weirdtreething
> you can do this all day, and you won’t find a valid strategy that doesn’t at least partially rely on obscurity

oh come on, let's do it all day, it's fun!

@wolf480pl @weirdtreething but i wanted to play vidya, that’s why i’m even setting this machine up!

(but i appreciate having fun discussions nonetheless )

@domi @ellis ah, right

@tastytea @ellis (also that’s one of the main reasons why I don’t encrypt boot, I find having one part for kernels and EFI to be optimal)

@twinspin6 @domi yeah, it's just not worth it, when your threatmodel is cops raiding you house and stealing your puters

@domi i don’t understand what people want to accomplish with encrypted /boot? if you want a verified boot chain, use secure boot, you can do usually do key enrolment right from the running system iirc. (or you can run one of the globally signed linux kernels on some distros) and if you use uki, the signing should include the entire elf pe, so including the boot stub, cpio and such. (and the included kernel cli cannot be changed for ukis)

@filmroellchen @domi reminds me of how many guides advice the user to disable secure boot.

@nachtpfoetchen @domi arguably, secure boot is pretty useless unless set up very very specifically and given that you trust HSMs. which neither of those are reasonable in practice to me.

@nachtpfoetchen @domi very specifically = locked-down UEFI secure boot menu that can’t easily be circumvented (e.g. by pulling the CMOS battery), ability to sign only when booted into secure environment (i.e. previous signed kernel), removing backdoored keys/kernels and any globally signed stuff you don’t need (e.g. Windows / Microsoft’s keys, not even sure if that’s possible on most stock firmware)

@domi I feel like I need a todolist app that works with my particular type of adhd, is you app source somewhere or usable by others? I've been using todoist but its closed and also there are a number of things that piss me off

@theraspb @weirdtreething @wolf480pl not at the present, and won’t be for a while (as i’m afraid to fuck up someone’s week due to the recurring tasks not replicating properly)

it’s also written around what one of my partners told me about their todo list approach, which I then greatly extended, essentially creating an amalgamation that probably will only work for a small group of people

i may publish it at some point. more likely i’ll write down my thoughts in a blogpost sometime, i feel it may help people with a certain breed of ADHD

@domi @weirdtreething @wolf480pl please do any of these, I would appreciate it! even just for reference for my own process/app it'd be good. though obviously no pressure or obligations attached.

@domi @weirdtreething there is a patch series adding argon2 support that libreboot applies (and another patch series on grub-devel that updates libgcrypt which will also add argon2)

@filmroellchen @nachtpfoetchen @domi can the UEFI secure boot menu often be circumvented by pulling the CMOS battery? I thought everything was stored in flash using smmstore now instead of nvram.

@domi
I've set up signed EFISTUB linux images in my EFI partition with my secure boot keys replaced in my firmware. They're not encrypted, but does at least prevent one from easily tampering with them (incl. cmdline)
@weirdtreething @wolf480pl

@Xesxen @weirdtreething @wolf480pl and what stops that someone from wiping the keys and enrolling their own when you’re not looking, then signing their own payload that aims to imitate yours?

@domi
Firmware password, assuming that isn't wiped whenever you unplug your battery...
@weirdtreething @wolf480pl

@domi

The FDE guide situation bothers me as well. But it's also very complicated to come up with something that is actually better. I want to develop a reasonable FDE setup for alpine linux but at the moment the only thread model I can really cover is "untrusted storage firmware" which is only really useful if you boot your entire OS from a USB drive that is sometimes laying around in public.

@domi @weirdtreething @wolf480pl

Is it possible to derived from more than just the TPM and/or do some encrypted communication between TPM and CPU in a way that is more secure? Or is the issue with that, that it would require storing some secret on the CPU which it can't do?

@sertonix @domi @weirdtreething
If the TPM had a way to authenticate the CPU, you could do diffie-hellmann between them, and obtain a secure channel.

But how would a TPM authenticate the CPU?

@Xesxen @weirdtreething @wolf480pl firmware password can be either cleared through CMOS (rare on laptops, common-ish on desktops), or through a firmware reflash with an external flasher. Genuinely 30 minutes of work if you have another compatible motherboard (or you find a dump online)

@domi @weirdtreething @wolf480pl yeah, what's even the point from the security standpoint? it's just security by obscurity tbh

@domi @weirdtreething
unless

scanning electron microscope?

@wolf480pl @domi @weirdtreething

If the TPM is not providing the key directly (eg. through hashing with some secret) the TPM doesn't need to authenticate the CPU. The CPU could authenticate the TPM through eg. asymetric encryption which means it wouldn't need to store any secret (just a public key).

What am I missing?

@sertonix @domi @weirdtreething
the core idea behind the TPM is that the CPU sends it hashes of each stage of the boot chain, called measurements.

And the TPM only unseals the secrets if the chain of measurements satisfies certain criteria.

But how does the TPM know that it received the measurements from the real CPU, and not a MITM device sitting between the CPU and the TPM that just forwards all the hashes and then snatches the key once the CPU tries to read it from the TPM?

@sertonix @domi @weirdtreething
Moreover, the bootchain or its measurements usually aren't secret.

So an entity other than the CPU could just reset the TPM and send it the correct measurements without actually running the measured boot chain

@wolf480pl @sertonix @domi and this is why TPMs suck for security. they'd need to be integrated into the SoC to actually be secure.

@wolf480pl @domi @weirdtreething

I am less concerned about using TPMs as they are intended and more if they can be made useful in some way. Maybe a TPM doesn't have the interface to do what I think but ether way any useful method has to throw away the intended method due to these issues.

@sertonix @domi @weirdtreething
Then it becomes a smartcard that you can't unplug and keep in your pocket when walking away from your computer...

At that point I'd just get a USB smartcard (they come in the shape of yubikeys, hardware wallets for cryptocurriencies, etc)

@wolf480pl @sertonix @weirdtreething yeah, get a FIDO2 key or something similar. This doesn’t guard you from… someone else getting access to said key… but you can set a PIN on them, so it’s at least a little bit more secure

@sertonix @wolf480pl @domi Maybe check out the document describing how ChromeOS uses the TPM: https://www.chromium.org/developers/design-documents/tpm-usage/
though keep in mind that google's threat model for chromebooks does not cover an attacker being able to have physical access to the device for a long period of time

@domi @weirdtreething @sertonix
IIRC FIDO2 exposes very limited primitives...
If trying to match TPM's capabilities without the measurement/sealing part, I was thinking more like PIV or OpenPGP card.

@wolf480pl @weirdtreething @sertonix you don’t want a lot of primitives in a security device. ideally you want it to do exactly what it needs to and not more. everything you’re not using is an area that can potentially contain insecure code, or be used as a side-channel in a more advanced attack

@domi @sertonix
As long as the privitives it has are enough for the task at hand. Which @weirdtreething never described...

@wolf480pl @sertonix @weirdtreething i think the task at hand is purely hypothetical :)

@domi
which is why I'm trying to avoid going into the practical details of "everything has bugs, also don't try doing things because you will do them wrong"
@weirdtreething @sertonix

@wolf480pl @weirdtreething @sertonix i’m not trying to be a doomer in this one, multiple times in this thread I’ve described how you need to draw the line somewhere, because nothing is truly secure. That being said, it’s important that people who use security devices aren’t misled by the vendor / fellow hackers into believing that they’re getting full, total security.

lacking a safety mechanism isn’t the most unsafe - having a broken one without knowing is. it’s important to remember this :)

@weirdtreething @domi @wolf480pl

> These keys are managed locally; they are not escrowed outside of the Chrome device. [...] However, this feature also necessitates a strong method of protecting these keys from disclosure as they are stored in a persistent file on disk.

Did they just imply that keys in the Google Cloud only need weak protection?

@sertonix @weirdtreething @wolf480pl how did you read that? they literally write “a strong method of protecting these keys from disclosure”

@domi @weirdtreething @wolf480pl

I didn't copy the sentence where they talk about "offline" which makes it seem that the alternative to storing the keys on device would be to store them in the cloud. Combined with the fact that they argue that strong protection is (only?) needed cause the keys are stored on device it makes it seem like strong protection wouldn't be needed on the Google Cloud.

@weirdtreething @domi @wolf480pl @sertonix every device I have with a TPM it is in fact in the same package as the CPU, to be fair

@erincandescent @weirdtreething @wolf480pl @sertonix did you get rid of all x86 desktops? they usually have a separate chip, or at the very least it’s in the chipset

@weirdtreething @domi @sertonix @wolf480pl but even with the TPM on a separate chip, for full disk encryption that's competently implemented (not Bitlocker) you need an active MitM while the password is entered because the password should be used as input for deriving the KEK and should be transferred over a ephemeral diffie hellman secured channel

@domi @erincandescent @weirdtreething @wolf480pl @sertonix people are confusing tpm and ftpm, practically all systems now a days use ftpm, this is all done inside the CPU firmware, or chipset firmware on older intel CPUs. But that’s it

@evey @erincandescent @weirdtreething @wolf480pl @sertonix some systems have an fTPM, but it’s not as ubiquitous as you think. and depending on how you wanna look at it, it’s either better (because integrated) or worse (because it’s loading firmware which can be observed, and given enough resources, likely could be exploited)

@domi @weirdtreething @wolf480pl @sertonix maybe Intel desktop CPUs are fucked. AMD put it in the CPU package, as do Intel laptops (the fTPM runs in the AMD SEP/Intel ME)

I've seen motherboards with TPM sockets but not seen them filled

@domi @erincandescent @weirdtreething @wolf480pl @sertonix any windows 10 compatible system has fTPM, nobody is spending money in adding a dedicated tpm chip. Plus in general the threat model is fine the main problem is windows storing secrets unlocked in there and assuming chassis intrusion is enough to lock it

@sertonix @domi @weirdtreething
I'm guessing in their threat model (of using chromebooks as Google employees' workstations), they see Google Cloud's dedicated key storage service as more secure than a file on a laptop's disk

@erincandescent @domi @weirdtreething @wolf480pl @sertonix thinkpads for like a decade for some reason have included a discrete tpm 1.x chip still, and have a choice in the bios between ftpm and that lol