Intel x86 Root of Trust: loss of trust

Posted Mar 8, 2020 7:18 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
In reply to: Intel x86 Root of Trust: loss of trust by gus3
Parent article: Intel x86 Root of Trust: loss of trust

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.