search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 47 forks source link

Integrate 2FA/YubiKey into LUKS #2712

Open rugk opened 7 years ago

rugk commented 7 years ago

Community Dev: none (help wanted) PoC: https://github.com/raffaeleflorio/luks-2fa-dracut Discussion: https://groups.google.com/d/topic/qubes-users/hB0XaquzBAg/discussion

It would be nice if you could integrate the 2FA/YubiKey into luks.

See these instructions and this site e.g.

andrewdavidwong commented 7 years ago

Related: https://github.com/QubesOS/qubes-issues/issues/1979

Joeviocoe commented 7 years ago

Qubes doesn't just run on Laptops. Think about Desktops. They require USB Keyboards since most modern desktop systems don't have PS/2. And since they require USB Keyboards to enter the LUKS Passphrase, that means the "rd.qubes.hide_all_usb" option in the bootloader will render the whole system inaccessible. So USB security at boot time is not an option, therefore, not a tradeoff with 2FA for LUKS.

2FA means that I don't have to weaken my passphrase so its memorable. And if snooped by some Evil Maid attack methods, they'll need to pull the token from my cold dead hands too. AEM for Qubes only works with USB storage, not Yubikey Challenge/Response, and still requires a TPM which desktops don't often have.

I am hoping someone will finish this idea and make it available, especially for desktop users with yubikey. Unfortunately, I don't have much knowledge on initramfs or dracut to produce something usable myself. I have searched all over, and only find the same abandoned ideas, or directions to using Yubikey for something other than LUKS, or on a Debian based system.

Please help. Thank you.

marmarek commented 7 years ago

More discussion, including PoC: https://groups.google.com/d/msgid/qubes-users/5a377fe7-833f-4c53-ab31-66a2c0f667a0%40googlegroups.com

raffaeleflorio commented 6 years ago

Hi all, I wrote a module [0] for dracut that allow the user to unlock a LUKS volume using 2FA during boot. It doesn't use a YubiKey and it doesn't require any USB controller attached to dom0 (i.e. rd.hide.all_usb is permitted).

2FA means that I don't have to weaken my passphrase so its memorable. And if snooped by some Evil Maid attack methods, they'll need to pull the token from my cold dead hands too. AEM for Qubes only works with USB storage, not Yubikey Challenge/Response, and still requires a TPM which desktops don't often have.

@Joeviocoe This is the core idea of the module: you need both passphrase and the keyfile volume (e.g. on a SD card) to open a target LUKS volume (e.g. root volume). So, with this setup, password recorder or shoulder surfer are defeated. However you're not protected against a physical attack. Probably, with some work, it could be integrated with TPM (#1979 seems still open). Nonetheless I think that the module is also helpful in a TPMless context.

[0] = https://github.com/raffaeleflorio/luks-2fa-dracut

Joeviocoe commented 6 years ago

Very cool. Thanks. The reason I like yubikey and probably won't use an SD Card, is because the yubikey cannot be cloned by sticking it into an untrusted reader. An SD card keyfile volume can simple be imaged, so it is more like the yubikey "static password". This means it doesn't quite fit the description of the "something you have" like yubikey or other hard token. Yubikey secret is written into a write-only space and resists physical tampering. The Yubikey itself does the processing of crypto for Challenge/Response, so the key is never exposed. A luks volume on an SD card is protected at rest, but easily cloned for later offline brute force of your passphrase. I don't imagine it would be difficult to tap the SD card reader to pull the keyfile volume when inserted. Just like putting a physical keylogger. And with both the keylogger and the SD card image... game's over. I do want Evil Maid protection, but as soon as the attacker sees I am using an SD card, that would probably only add another step in the attack.

Also, I don't have an SD card reader on my desktop. But isn't there still a PCI Storage Controller that needs to be attached to dom0? Probably not as bad as USB, so I do see the value of your new module.

raffaeleflorio commented 6 years ago

Very cool. Thanks.

Thanks! I'm glad to help! :smile:

The reason I like yubikey and probably won't use an SD Card, is because the yubikey cannot be cloned by sticking it into an untrusted reader

A physical attack is so simple. Specifically I worked with dracut because of this module and it's easy to hack it (probably any initramfs). So if attacker has access to dracut the game is over. Furtermore there isn't any need to clone the SD card or, eventually, to mess up the YubiKey. In other words: an attacker doesn't need to interact directly with one of them. The additional requirement to YubiKey is that the user should protect the SD card, and it shouldn't be attached to untrusted stuff. For this reason, without AEM, the YubiKey setup security is equal to this setup.

An SD card keyfile volume can simple be imaged, so it is more like the yubikey "static password". This means it doesn't quite fit the description of the "something you have" like yubikey or other hard token.

It doesn't act like a simple static password. The user needs to provides a password to get the secret on the SD card. So an attacker needs both.

Yubikey secret is written into a write-only space and resists physical tampering.

It could be written everywhere. As I said above, YubiKey, without AEM:

A luks volume on an SD card is protected at rest, but easily cloned for later offline brute force of your passphrase

Obviously the passphrase should be strong enough to make, the simplest attack, computational infeasible.

But isn't there still a PCI Storage Controller that needs to be attached to dom0? Probably not as bad as USB

Exactly.

I think that the attack model is clear: this setup doesn't protect you from physical attacks. It protects the user from shoulder surfing or password recording and subsequent clone/steal of the main drive/computer. I think that, in emergency, it's easier to destroy an SD card than a drive inside a case. Anyway, with this module or YubiKey, another layer is needed to protect the user against EM.

Simon-Davies commented 6 years ago

Is anyone working on this?

andrewdavidwong commented 5 years ago

Is anyone working on this?

@raffaeleflorio created the PoC linked above, but it appears that he may have stopped working on this. If so, then anyone who wishes to take over is welcome to do so.

rafaelreis-r commented 4 years ago

Hey, so this truly interests me. There are solutions for Debian based and Arch linux based distros, and not for Qubes, which is a bit surprising considering the security orientation of Qubes. I acknowledge the function of the SD card based PoC, however, it becomes one more thing to carry around, specially if you already have a Yubikey for other stuff. Wish I had the skills to pick up from where the PoC left of and develop the integration. Willing to help with testing or information however I can.

Edit: Maybe this is a relevant resource: https://armadillo.tech/post/ykfde-fedora/

metzgerd commented 3 years ago

There is another option if you have a ps/2 keyboard and like to use YubiKey for LUKS. Plugin the key, enter password of the key and go for it. Tested on Qubes 4.0.3: https://github.com/the2nd/ykluks

Maybe this solution can be integration in the next qubes version.