Intel x86 Root of Trust: loss of trust

Posted Mar 6, 2020 23:27 UTC (Fri) by gus3 (guest, #61103)
In reply to: Intel x86 Root of Trust: loss of trust by tau
Parent article: Intel x86 Root of Trust: loss of trust

"Transparent disk encryption is nice and it's a shame that the Linux world is so distrustful of the concept."

I'm not sure what you mean by that. We have transparent volume encryption via LUKS, which serves the purpose really well, AFAICT. But I think you really meant to say "transparent file encryption," which is available in ext4, F2FS, and UBIFS.

As for a one-stop solution, I'm working on that. Please don't beg for a code release; I'm still in the research stage.

(FWIW: I worked 15 years ago for a company that had exactly what you're talking about, a real, working system, cross-platform [Linux, Solaris, AIX, and HP-UX] that even protected against UID 0 compromises. It was patented, but the patent was allowed to lapse after they were bought out. Now that ext4 has it, I'm interested in building that one-stop solution, based on the practice I learned 15 years ago, but it'll take time.)

Intel x86 Root of Trust: loss of trust

Posted Mar 6, 2020 23:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Windows uses TPM to automatically manage the disk encryption key. So it will fail decryption if your Windows kernel is tampered with or if you move the HD to a different computer.

This is genuinely a good feature that is difficult to do in Linux.

Intel x86 Root of Trust: loss of trust

Posted Mar 7, 2020 0:45 UTC (Sat) by viro (subscriber, #7872) [Link] (1 responses)

How does that work if e.g. you get a fried motherboard? Unless I'm misreading you, that would seem to imply an unrecoverable filesystem, wouldn't it?

Intel x86 Root of Trust: loss of trust

Posted Mar 7, 2020 0:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

You can store the full encryption key (256 bit) on paper, on a USB drive or in the ActiveDirectory.

But if you do neither, then you are going to lose your data.

Intel x86 Root of Trust: loss of trust

Posted Mar 8, 2020 1:25 UTC (Sun) by gus3 (guest, #61103) [Link] (4 responses)

I should have pointed out: the system I used 15 years ago was developed before TPM was even a thing. It has no reliance on hardware security devices, although it did have a plugin system to support things like RSA dongles, 2FA, or DES accelerators, so TPM interaction might have come along eventually.

Intel x86 Root of Trust: loss of trust

Posted Mar 8, 2020 7:18 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Sure, you can do encryption without hardware assist. But then you lose some important features:
1) Integrity control. An attacker can modify your kernel to log all keystrokes and you won't see any difference.
2) PINs. You will have to enter the full encryption key every time. Even with key strengthening (with PBKDF or similar algorithms) you still need to have a fairly long password.

Intel x86 Root of Trust: loss of trust

Posted Mar 8, 2020 23:24 UTC (Sun) by gus3 (guest, #61103) [Link] (2 responses)

#1 is a fair challenge. Boot integrity was outside the scope of the system we used. Like I said, it was developed before TPM. It was primarily focused on protection of run-time data. That meant user data (home directories) and files for network services (web, database, network shares...). But Linux and the *BSD systems have kernel lockdown features, to prevent rogue kernel module loading. Solaris, AIX, HP-UX have their own similar features.

Your point about PIN's was already addressed in the plugin interface we had. It wouldn't be a big deal to send an SMS to a cell phone, saying "If you're trying to log in, enter the sum of 227 and 13, followed by the word 'percent'." So then, to gain access, you'd type "240 percent" at some secondary access prompt. And if you weren't trying to log in, when you got such a message, you'd be immediately aware that someone was trying to hack your key store. It's basic 2FA.

I'm simplifying this a lot, b/c the design that went into it had a lot of engineering and UI definition. There were other administrative features, like automatically granting keys to apps (delegation) and group sharing of keys (key links). I have no hope to implement those; I'll just be happy to make the d@mn thing work someday.

Intel x86 Root of Trust: loss of trust

Posted Mar 9, 2020 0:21 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Your point about PIN's was already addressed in the plugin interface we had.
No, you're missing the point.

To be able to secure the disk contents, you need to use a full 128-bit strength key. If you limit yourself to ASCII, then you're looking at passwords that are around 17 characters. This is way too long to remember properly or enter on every boot.

PINs in TPMs allow to lock the full-strength password with a simple PIN (6 numbers are enough) and makes it impossible to brute-force it by imposing hardware-assisted delays between each try.

Intel x86 Root of Trust: loss of trust

Posted Mar 13, 2020 19:04 UTC (Fri) by ecree (guest, #95790) [Link]

> This is way too long to remember properly
Fwiw since developing https://github.com/ec429/passacaglia I've found to my surprise that 72-bit passwords (12 characters of Base64) only take about three uses to memorise and are pretty painless to enter. I haven't tried with longer ones, but given that I currently have more than one committed to memory, concatenating a pair of them for a 144-bit password doesn't seem impractical.

Intel x86 Root of Trust: loss of trust

Posted Mar 9, 2020 14:09 UTC (Mon) by jgg (subscriber, #55211) [Link]

Windows can also turn Secure Boot + TPM into a U2F token secured by a login PIN, which is fantastic.