Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

pulsesecurity.co.nz

Post reply on HN
Print view View original

91–100 of 135 posts

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#91

Post by jiveturkey »

als0 wrote: post #78
chatmasta wrote: post #74

Earlier quoted context omitted.

Can you explain the difference a bit more, and why it's more than just splitting hairs? Is it because TPM is a specific standard for implementation of a secure co-processor, whereas Secure Enclave is part of a larger SoC (T2), which while it could be considered an implementation of a secure co-processor, is distinct from the TPM standard? In researching this comment I learned that the T2 chip actually runs its own op…

The TPM is an TCG standard (also ISO/IEC 11889), and specifies commands that support a lot of use cases. The Secure Enclave from Apple is something simpler and more restrictive, that is tailored only for Apple's use cases.

simpler? hardly.

high level overview: https://support.apple.com/guide/security/secure-enclave-sec5...

low level overiew: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

AFAIK, and it's hard to find the info since I don't have it handy, so I don't want to devote the searching time, but bringing it back on-topic, all disk i/o has to go through the secure enclave for encryption and decryption. i believe this is better documented on mac than iphone. the data storage is always encrypted since T2. If filevault is enabled, then the user's password gets mixed in with the T2 hardware keys. Because those keys can never leave T2, all disk i/o necessarily goes through it.

This is vastly different than how TPM operates.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#92

Post by teddyh »

SomeoneOnTheWeb wrote: post #23
alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

I used to have a custom NAS with full disk encryption, whose bootloader would spin up a tiny SSH server with very few features, mainly only access to an unlock function that would allow to transmit the encryption passphrase over the said SSH tunnel. Then the SSH connection would be closed by the server and it would startup with the decryption key. That way, it was impossible to access the data physically, but I was s…

Might I suggest that Mandos might be a slightly easier version of a solution to that problem?

(Disclosure: I am a co-author of Mandos.)

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#93

Post by patrakov »

michaelt wrote: post #45
13of40 wrote: post #26

Earlier quoted context omitted.

It's not a totally meaningless check box. If the key for decrypting the disk is in the TPM, this fixes the case where the drive gets pulled and thrown in a recycle bin, then someone recovers data from it later.

Yes, when I say "small enough you can't adopt effective organisational controls" I mean organisations that are large enough that they're discarding so many disks they might accidentally forget to wipe some, and yet small enough they don't have procedures and record-keeping that prevent such accidents. A large organisation will usually have tedious checks and record-keeping for wiping and discarding hardware, probably…

It is not about forgetting to wipe a disk. A realistic scenario is that an SSD fails in a way that it ceases to be recognized by the system. At this point, you have no way to wipe it. Still, you may be required to return it to the vendor (by the contract that gave you the discounted price in the first place) - and they can read it using their tools not available to mere mortals.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#94

Post by theLiminator »

gameoverhumans wrote: post #59
hollerith wrote: post #48

Earlier quoted context omitted.

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article. Once you have physic…

Is there a way to do 2FA yubikey style disk encryption? Ie. requires a passphrase + user's yubikey to login?

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#95

Post by arjvik »

Klasiaster wrote: post #88

Sounds like it would have also worked to replace the hard drive with an own one where the OS directly gives a root shell to read the TPM secret. The solution is to bind the TPM secret to a measured boot state, but that requires a way of precalculation of the expected measurement values. Read more about signatures for these precalcuated measurement values here: https://0pointer.net/blog/brave-new-trusted-boot-world.ht…

The point of this article is that this attack doesn't change any of the TPM measurements.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#96

Post by adrian_b »

alexeldeib wrote: post #81
adrian_b wrote: post #79

Earlier quoted context omitted.

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs. In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data. To boot the compute…

Are you still using LUKS for these? How are you invoking decryption with the pass phrase protected key?

I am not using LUKS, I am using a custom kernel module that implements a block device that presents to the kernel the decrypted SSD. The kernel module receives the key when it is loaded, then it creates the block device that is eventually mounted as the new root device.

I do not know if LUKS could be used for this, I have not examined it. IIRC, LUKS stores the actual decryption key in the encrypted disk (protected by a passphrase) or in the TPM, like most commercial products for disk encryption, which are methods that I do not approve.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#99

Post by adrian_b »

StillBored wrote: post #84
adrian_b wrote: post #79

Earlier quoted context omitted.

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs. In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data. To boot the compute…

While cool/interesting, i'm failing to understand the attack your protecting against here in the context of just prompting for an unlock PIN. Particularly if that unlock pin is for a FIDO key or whatever which can also be removed. I mean, if someone steals your backpack, or stops you at the border, breaks into your house, whatever, they are getting the boot image too, right? Furthermore, are all your machines AMD Pro…

The attacks "evil maid" described by a poster above are impossible.

Even with physical access, the computer does not have any boot loader or kernel or any other executable that could be altered.

The attack described in the thread title also does not work, because the computer cannot boot. Even after booting from their own device, attackers cannot do anything useful. Reading the encrypted SSD will not provide any information and writing it will be detected later. The SSD does not have any non-encrypted sector.

Obviously I do not keep the USB key with the computer, especially when the computer is not with me. It is never put in the computer backpack.

Of course, if someone would watch me to discover how I start the computer and then they would capture me with all my belongings and then they would do a thorough search they might find the key and they might torture me to get the passphrase.

Nevertheless, against this kind of threats, there are no computer solutions. The only thing that would work would be the use of armed guards.

On the other hand, my method is not vulnerable to trivial attacks that could be done without my knowledge, like the one described in the thread title.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#100

Post by [deleted] »

kaylynb wrote: post #66

The article title is very misleading. This isn't bypassing FDE in any way. It's just getting a root shell on a machine you have physical access to with a particular boot configuration. Clever? Yes. But no encryption is bypassed. Most systems will only be listening to PCR 7 anyway, so a similar attack could be done by loading your own custom bootloader, or possibly reading messages on the SPI bus when booting. This is…

[deleted]
Post reply on HN