Proposal to add pre-boot Mutual-Multifactor (secure external key provision) full-disk-decryption

[Chris Drake]

I've written a solution for providing out-of-band LUKS key material during boot.

My question is: if I contribute this to the Qubes project (which will be a huge amount of work) - how likely will it be to gain acceptance?

My solution includes verifier impersonation resistance (NIST SP800-63-3 AAL3) and additional decryption keys - it uses mobile phones (and optional biometrics or passphrase to encrypt the keys in protected storage there) for fast and convenient (and in the case of servers - remote) unlock usage, combined with a lightweight network-aware pre-image for triggering a "wake-up" phone push event and key reception (I also support audio-QR and bluetooth for local users).

My proposal allows anyone to implement their own verification service atop my open protocol, but they can also use my (commercial) product for immediate working protection (free for individuals and non-profits etc, modest fee for others). We put some effort into independently securing the mobile component, but the true security comes from the second-device nature - any compromise of either (not both) hardware devices does thus not compromise your whole system. (PC boot integrity forms part of the verifier-impersonation resistance, for which I owned the (now expired) patent 6,006,328.)

The same solution also optionally supports (once booted) PAM and other 2FA mechanisms, quickly providing multifactor (and optional biometric) protection to system operations (sudo/su/ssh/etc) or other risky behaviour.

Chris.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Something functionally similar is already done here:
https://github.com/QubesOS/qubes-antievilmaid/pull/20

- - --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
- -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpI0ywACgkQ24/THMrX
1yzVFAgAlJFLbXbqvbuwddEUs09QGeZPXl+/7B2YfFlZv8ULiN1iwPbXRVe0n3S4
oMI5DvZLemVCu6SnIxkIPuRMpng/fBCys4THUK3GvdLE+wZYiDyvDvWFgXX9jdB0
Xio9H33bQxIkx3f6TSeN3tzQczsIQlHNpx68905pOlY5XwDIKsKQo4Okq4JjZO2Y
DkMHKEB0LbnxkuryiqiYZoYvFFX5Y10wFzsIqr7/f1OGhttdChZqdm8TId5N41gU
EjEjt95EZkfHRowDWx/VJ5aN0RzhZoH5aDCjzlgBq1j+B7qVA9HrMS5HLDkW4x81
QCJZFmZqO7UtxtcSu9p6VB475Bxu5Q==
=cCvM
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpI02QACgkQ24/THMrX
1yxk4Af/YJrE9QlEjtujtuTIuhOoPYwYSvPc/u86mlr9im5qoEaeQnANhLWcuzTa
XquuHk1qFPH922AhCt15dJdUoJ9OJC4BUi+kReWZG7laqjQdwshpjazSsxQp/xNw
eaKmKXKXg81lu6pK4g9EJVSXvv40QhuSgG5Js010Yppz17pSnS/X0S27SwpUfQyC
B7lMMZwvtHFTPoSvgbI0JUOvGbIbIcMjO6XhH3ID2wu7NgaPiohpUiJDaOsVHKPI
VgtoBuhjZcY0VRmq0VlSXJMQPQl3O5/1zJ9IvMOITiUeb+D2zK60lGqI3IYgM3K7
u+E683UUJO3egxVqmS4/wPznBSPEbQ==
=uAXm
-----END PGP SIGNATURE-----

[Chris Drake]

Thanks Marek - nice reference, plus the idea of TPM usage is a good one.

Providing a key while physically present is obviously not helpful for servers and remote access use-cases, which is my principal issue.  Storing keys on general purpose media (USB/floppy/bootdisks) doesn't exactly raise the bar that much for the evil maid IMHO.

My proposal includes making boot-time physically-supplied passwords *optional*, to facilitate full, yet still secure, remote admin and reboot - plus keeping all or part of a key (or TOTP-assisted TPM access request for one) on a users separate device (phone) adds a vast speed and simplicity improvement with additional biometric protection, plus defence against physical compromise (the "challenge" for the key is based on the integrity of the boot environment requesting it).  It also makes it possible to safely remove USB and removable media pre-boot compromises.

Thwarting an evil maid is going to be a whole lot easier when your key device (phone) is in your pocket, and key is encrypted behind biometrics, and your system pre-boot environment integrity is communicated (and required to be correct) before key provision occurs...

What's your experience with sizeable security-enforcing contributions?  Am I wasting my time to port this (a major effort) to Qubes, or would it gain enough support to stand some decent chance of inclusion?

Chris.

[Naja Melan]

> (the "challenge" for the key is based on the integrity of the boot environment requesting it). It also makes it possible to safely remove USB and removable media pre-boot compromises.

Hi Chris,

just out of curiosity, how do you verify that the challenge you get from a compromised boot environment is not being forged? TPM? You seem to say "the idea of TPM usage is a good one", which made me curious as to how you did it without TPM?

greets
Naja

[Chris Drake]

Hi Naja,

I'm using code similar to the last step in claim 3 of my (now expired) patent: https://www.google.com/patents/US6006328 - specifically, I build a digest from the in-memory environment, including processor flags, static system information, and execution timing information, then encrypt  this to the public key of the users token (in their phone) - where the digest's construction includes the executing digest and encryption code itself  (it helps to get your head around this by imagining modifying a SHA256 executable to produce a digest of the executable code of itself producing this digest).  

The users phone knows how to present this digest to the user in a way such that if it ever changes in future, the user cannot then supply the decryption key to the no-longer-trusted requesting code.  To make this easy for idiots or inattentive users, while also super-fast, I convert the digest into an index into of human-recognisable photos, which the user needs to match with a tap in order to supply the decryption key to the boot process.  If there is no matching photo, there's nothing for the user to tap on to provide that key - so we can get a full human-verified out-of-band digest integrity check in under 2 seconds, taking just one unlock (eg; fingerprint biometric), and one tap.

I do realise that, absent "secure boot" incorporating my proposal, this is an "arms race" scenario in terms of battling reverse engineering of the boot process by an evil maid intent on forging that digest, but since the digest is unknown anyplace except for the users phone, this makes an attack quite difficult to mount: they must try to reverse-engineer a digest without knowing what it is, where they only get one guess (a wrong digest immediately alarms the user), and where any adjustment to the system, code, timing, or processor flags destroys the correct digest.  It's not perfect, but it does raise that bar a long way IMHO - our evil made now also needs to be a skilled and patient reverse engineer who can somehow generate a bit-and-timing-and-CPU-and-system-side-effect perfect duplication of the entire executing boot environment, with not even one chance to get it wrong.

My TPM comment is related to a different attack vector (mobile malware, CALEA, 2FA infrastructure compromise, etc): since the key provided by the user is not the decryption key itself, but rather, the TPM index for it, this prevents anything outside the box accessing your data (e.g. that evil maid cannot just do a "dd" of your encrypted hard drive, then turn up on the user (or my, or my employees') doorstep with a gun, warrant, or malicious USB, and walk away with means to decrypt that drive.)

Chris.

Naja

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/ntlJ0GlXDDI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-devel+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/cdd5e544-02d5-423d-76fd-ccf9d1686d32%40autistici.org.
For more options, visit https://groups.google.com/d/optout.