Luks with yubikey + aem
969 views
Skip to first unread message
ipet...@gmail.com
Jan 6, 2016, 7:13:02 AM1/6/16
to qubes-users
Hi!
Is it possible? Are there any tutorials about it?
Thx
Marek Marczykowski-Górecki
Jan 6, 2016, 4:14:07 PM1/6/16
to ipet...@gmail.com, Rusty Bird, Joanna Rutkowska, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jan 06, 2016 at 04:13:02AM -0800, ipet...@gmail.com wrote:
> Hi!
>
> Is it possible? Are there any tutorials about it?
Currently not. But probably possible to implement. The idea is to encrypt
"something" using next OTP (from yubikey). Then after successful mount,
remove the old "something" and replace with the new value (since disk is
already mounted, it can access shared secret of yubikey, so it is
possible then), for the next boot. This idea requires to know exactly the
next OTP value, so time based OTP would be useless here. I would go with
challenge-response mode, but some details needs to be sorted out.
Regarding "something", it could be part of disk passphrase. Or even the
next OTP could be used as part of disk passphrase itself.
So the process would look like this:
1. Start (init TXT, load with measurements xen, kernel, initrd)
2. Unseal secret from TPM
3. Add a counter value(*) to it (and increment the counter)
4. Ask user for a passphrase
5. Concatenate user passphrase, unsealed secret and counter value,
calculate sha1
6. Feed result of previous step to yubikey as a challenge
7. Get a response from yubikey
8. Use response concatenated with unsealed secret as LUKS passphrase
==> LUKS mounted here, now prepare for the next startup
8. Get next counter value
9. Repeat steps 5-7 (not necessary using yubikey again, but secret key
from the disk; but using yubikey again is probably also ok)
10. Replace LUKS slot used to mount LUKS, with the newly calculated
passhprase
(*) open question: where store the counter? Does TPM provide something
like non-retractable counters? Or maybe YubiKey can be used for that (in
YubiKey OTP mode)?
This is just an idea, needs some more evaluation. For example:
1. Is it really good idea to prompt for the user passphrase without
showing user unsealed TPM secret? Theoretically user passphrase is
useless without proper unsealed TPM secret. But maybe I'm missing
something?
2. An attacker can make a copy of the whole disk, including LUKS header,
so replacing LUKS slot doesn't prevent he/she from using outdated OTP.
3. Some multi-stage attack scenario, when user passhprase is
concatenated to yubikey response, not the challenge:
1. An attacker get access to the hardware, connect fake yubikey,
which will record the challenge, boot the system to capture
the challenge; also make a backup of LUKS header before anything
2. He/she replace initramfs to replay previous challenge and capture
response together with user passphrase
3. The next time user tries to boot the system, the same challenge is
sent to yubikey to receive the response; unlock would fail because
of different PCR values (so TPM unseal would fail and one part of LUKS
passphrase will be missing); but the attacker now have a correct
response to some challenge and user passphrase
4. Attacker replaces initramfs to previous value to allow further
boots normally
Now, if the attacker can convince original initramfs to use previous
counter value (to generate the same challenge), he/she will be able to decrypt
the data. So having really non-retractable counter is critical here.
4. Maybe some other attack, similar to "3" is still possible?
5. It would be probably good idea to keep LUKS slot encrypted not only
for one next boot, but a few of them (for example 5). So if you
accidentally power on the computer but not provide a password, you will
not lock yourself out. Also a backup key is a good idea...
Related info:
YubiKey FDE implementation integration guidelines:
https://www.yubico.com/wp-content/uploads/2012/10/YubiKey-Integration-for-Full-Disk-Encryption-with-Pre-Boot-Authentication-v1.2.pdf
YubiKey integration with Qubes:
https://www.qubes-os.org/doc/yubi-key/
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWjYOWAAoJENuP0xzK19csd1gIAI/78X3kVHCefcmwtCJrb5j5
ESsu/t76OZhJfqkHb6FpLk4vWc7cneu18mcZI6pSo6Cizx3g/kbkbWrbovodfCpr
lkuXMCJEYYIuJ13DMFmtDS+W2wUecG5OvPJxAoLGvCRXYjyiNytTwzwVCO0c9Su1
+cAflFb8LPynXqoQ9gr6/j2U2pjo7xsPgSUDzZM7JS6NKlFlxhWwTRGu2QWNylDh
TtCo0E2yS5e9m1Vbhqb3ba4rD6QlhTrLsimI5PCvpRC2yEImPNl71bwNrfel685p
ePMhAnk+snSRjxso7nh9SztDiKu2r+MahCM0ggEUVkL5Zg/ZFT+2L+qPV+qjwVk=
=hwYr
-----END PGP SIGNATURE-----
Hash: SHA256
On Wed, Jan 06, 2016 at 04:13:02AM -0800, ipet...@gmail.com wrote:
> Hi!
>
> Is it possible? Are there any tutorials about it?
"something" using next OTP (from yubikey). Then after successful mount,
remove the old "something" and replace with the new value (since disk is
already mounted, it can access shared secret of yubikey, so it is
possible then), for the next boot. This idea requires to know exactly the
next OTP value, so time based OTP would be useless here. I would go with
challenge-response mode, but some details needs to be sorted out.
Regarding "something", it could be part of disk passphrase. Or even the
next OTP could be used as part of disk passphrase itself.
So the process would look like this:
1. Start (init TXT, load with measurements xen, kernel, initrd)
2. Unseal secret from TPM
3. Add a counter value(*) to it (and increment the counter)
4. Ask user for a passphrase
5. Concatenate user passphrase, unsealed secret and counter value,
calculate sha1
6. Feed result of previous step to yubikey as a challenge
7. Get a response from yubikey
8. Use response concatenated with unsealed secret as LUKS passphrase
==> LUKS mounted here, now prepare for the next startup
8. Get next counter value
9. Repeat steps 5-7 (not necessary using yubikey again, but secret key
from the disk; but using yubikey again is probably also ok)
10. Replace LUKS slot used to mount LUKS, with the newly calculated
passhprase
(*) open question: where store the counter? Does TPM provide something
like non-retractable counters? Or maybe YubiKey can be used for that (in
YubiKey OTP mode)?
This is just an idea, needs some more evaluation. For example:
1. Is it really good idea to prompt for the user passphrase without
showing user unsealed TPM secret? Theoretically user passphrase is
useless without proper unsealed TPM secret. But maybe I'm missing
something?
2. An attacker can make a copy of the whole disk, including LUKS header,
so replacing LUKS slot doesn't prevent he/she from using outdated OTP.
3. Some multi-stage attack scenario, when user passhprase is
concatenated to yubikey response, not the challenge:
1. An attacker get access to the hardware, connect fake yubikey,
which will record the challenge, boot the system to capture
the challenge; also make a backup of LUKS header before anything
2. He/she replace initramfs to replay previous challenge and capture
response together with user passphrase
3. The next time user tries to boot the system, the same challenge is
sent to yubikey to receive the response; unlock would fail because
of different PCR values (so TPM unseal would fail and one part of LUKS
passphrase will be missing); but the attacker now have a correct
response to some challenge and user passphrase
4. Attacker replaces initramfs to previous value to allow further
boots normally
Now, if the attacker can convince original initramfs to use previous
counter value (to generate the same challenge), he/she will be able to decrypt
the data. So having really non-retractable counter is critical here.
4. Maybe some other attack, similar to "3" is still possible?
5. It would be probably good idea to keep LUKS slot encrypted not only
for one next boot, but a few of them (for example 5). So if you
accidentally power on the computer but not provide a password, you will
not lock yourself out. Also a backup key is a good idea...
Related info:
YubiKey FDE implementation integration guidelines:
https://www.yubico.com/wp-content/uploads/2012/10/YubiKey-Integration-for-Full-Disk-Encryption-with-Pre-Boot-Authentication-v1.2.pdf
YubiKey integration with Qubes:
https://www.qubes-os.org/doc/yubi-key/
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWjYOWAAoJENuP0xzK19csd1gIAI/78X3kVHCefcmwtCJrb5j5
ESsu/t76OZhJfqkHb6FpLk4vWc7cneu18mcZI6pSo6Cizx3g/kbkbWrbovodfCpr
lkuXMCJEYYIuJ13DMFmtDS+W2wUecG5OvPJxAoLGvCRXYjyiNytTwzwVCO0c9Su1
+cAflFb8LPynXqoQ9gr6/j2U2pjo7xsPgSUDzZM7JS6NKlFlxhWwTRGu2QWNylDh
TtCo0E2yS5e9m1Vbhqb3ba4rD6QlhTrLsimI5PCvpRC2yEImPNl71bwNrfel685p
ePMhAnk+snSRjxso7nh9SztDiKu2r+MahCM0ggEUVkL5Zg/ZFT+2L+qPV+qjwVk=
=hwYr
-----END PGP SIGNATURE-----
Rusty Bird
Jan 7, 2016, 12:24:28 AM1/7/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki, ipet...@gmail.com, Joanna Rutkowska
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Marek,
Very interesting concept! I'm totally unfamiliar with the Yubikey
protocols, so I'll skip ahead to:
> So the process would look like this: [...] 10. Replace LUKS slot
always changing LUKS header checksum
12. Sync the resealed secrets to all AEM devices
> This is just an idea, needs some more evaluation. For example:
> [...] 4. Maybe some other attack, similar to "3" is still
But there might be a simpler way: The goal is to tie disk decryption
to a (small) second factor, and to mitigate visual surveillance, right?
- - To protect the LUKS key with "something you have" -- the AEM stick --
we could add a secret.luks.encrypted file, which holds the actual LUKS
passphrase (not usually typed in during boot, only when unsealing fails
due to upgrades), symmetrically encrypted with another passphrase.
Probably using something more modern and less bloated than GPG, like the
encryption utility from the scrypt reference implementation?
- - To protect the secret from visibility, we could plug in Matthew
Garrett's TOTP concept via a secret.totp file containing the seed. And
then add a non-default GRUB boot entry to unseal the regular static
secret.{txt,png}, in case the user doesn't have their authenticator
device with them.
Pros: Less code, easier to reason about, hide_all_usb compatible
Cons: Another (infrequent) passphrase, manual OTP comparison
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJWjfZ+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfFv0P/1nbJH4y4IgzMkxVG1RFyfI5
bHc9v83XuU3u0jzUWhesApt85bK8pKrkHt6gLsLGNNg1r2413gdRMUzPmVbx4q5p
e12frPBm8sqoTgzzqGugv/J86VwIzRXPn3gvAKRZzuqP+f5W3DSaYN5t2/GNkxi0
JzXXietJG4GxzQWaY+a+sstODWtsbz6P3qzpGsuU3Ut2cZP7S19QT0I3n87smBvg
RMhUxvezhghvLilny3h7sgIzGJ0sJz48v0RVrjGw3Og50VmSAv6LLZhJQFdzynGE
ADlYK6cHkgCFCt9lxXugUlVTvGIsFWWUhiof6mlxaTSR4nYGuoLEu7KnbBdddLiC
iImIU7rVps/SVfZyKrJBeM3gRdfWqZlr9xbkooL7VtmujRCKTgcxO95HNI2x3ddb
8vV1ylzKaCllfFnZLcaukV4AJrSaRAlLGiLWdIhfvPSPhpjn+HCxGRbX9CSBl7Ui
PBUV8bJuuOBvAcX+/zB9/ENhvLOEXtz0YG7S8k1DP6PTb1G+Z7pjJAFheqe7GHkq
gQ3ziYrq6CrpDc617rnXe7mUMYm5FWXgSz2Bh8gDPQBJ2q+PjMOA4F115IiIP+oY
9Wj8O7UcUFwj/sVVFfwtAFevB6+YoM16ij9bgc+v6CNhOTUDwiaAoSyfyYPOdbPp
2w/vIvey6VCk5psrnkNM
=eDIT
-----END PGP SIGNATURE-----
Hash: SHA512
Hi Marek,
Very interesting concept! I'm totally unfamiliar with the Yubikey
protocols, so I'll skip ahead to:
> So the process would look like this: [...] 10. Replace LUKS slot
> used to mount LUKS, with the newly calculated passhprase
11. Reseal during every boot, maybe alternating between two PCRs for the
always changing LUKS header checksum
12. Sync the resealed secrets to all AEM devices
> This is just an idea, needs some more evaluation. For example:
> possible?
>
> 5. It would be probably good idea to keep LUKS slot encrypted not
> only for one next boot, but a few of them (for example 5). So if
> you accidentally power on the computer but not provide a password,
> you will not lock yourself out. Also a backup key is a good
> idea...
Definitely lots of new angles to consider...
>
> 5. It would be probably good idea to keep LUKS slot encrypted not
> only for one next boot, but a few of them (for example 5). So if
> you accidentally power on the computer but not provide a password,
> you will not lock yourself out. Also a backup key is a good
> idea...
But there might be a simpler way: The goal is to tie disk decryption
to a (small) second factor, and to mitigate visual surveillance, right?
- - To protect the LUKS key with "something you have" -- the AEM stick --
we could add a secret.luks.encrypted file, which holds the actual LUKS
passphrase (not usually typed in during boot, only when unsealing fails
due to upgrades), symmetrically encrypted with another passphrase.
Probably using something more modern and less bloated than GPG, like the
encryption utility from the scrypt reference implementation?
- - To protect the secret from visibility, we could plug in Matthew
Garrett's TOTP concept via a secret.totp file containing the seed. And
then add a non-default GRUB boot entry to unseal the regular static
secret.{txt,png}, in case the user doesn't have their authenticator
device with them.
Pros: Less code, easier to reason about, hide_all_usb compatible
Cons: Another (infrequent) passphrase, manual OTP comparison
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJWjfZ+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfFv0P/1nbJH4y4IgzMkxVG1RFyfI5
bHc9v83XuU3u0jzUWhesApt85bK8pKrkHt6gLsLGNNg1r2413gdRMUzPmVbx4q5p
e12frPBm8sqoTgzzqGugv/J86VwIzRXPn3gvAKRZzuqP+f5W3DSaYN5t2/GNkxi0
JzXXietJG4GxzQWaY+a+sstODWtsbz6P3qzpGsuU3Ut2cZP7S19QT0I3n87smBvg
RMhUxvezhghvLilny3h7sgIzGJ0sJz48v0RVrjGw3Og50VmSAv6LLZhJQFdzynGE
ADlYK6cHkgCFCt9lxXugUlVTvGIsFWWUhiof6mlxaTSR4nYGuoLEu7KnbBdddLiC
iImIU7rVps/SVfZyKrJBeM3gRdfWqZlr9xbkooL7VtmujRCKTgcxO95HNI2x3ddb
8vV1ylzKaCllfFnZLcaukV4AJrSaRAlLGiLWdIhfvPSPhpjn+HCxGRbX9CSBl7Ui
PBUV8bJuuOBvAcX+/zB9/ENhvLOEXtz0YG7S8k1DP6PTb1G+Z7pjJAFheqe7GHkq
gQ3ziYrq6CrpDc617rnXe7mUMYm5FWXgSz2Bh8gDPQBJ2q+PjMOA4F115IiIP+oY
9Wj8O7UcUFwj/sVVFfwtAFevB6+YoM16ij9bgc+v6CNhOTUDwiaAoSyfyYPOdbPp
2w/vIvey6VCk5psrnkNM
=eDIT
-----END PGP SIGNATURE-----
Paul Harvey
Jan 7, 2016, 1:40:18 AM1/7/16
to Rusty Bird, qubes-users, Marek Marczykowski-Górecki, ipet...@gmail.com, Joanna Rutkowska
I just wanted to point you all to pre-existing work on this topic [1].
Obviously OTP modes are best and there was even an implementation [1]
(corresponding blog post at [2]). It didn't seem to gain any traction.
[3] & [4] seem to be the main yubikey-luks solutions (in Debian-land
at least) out there currently, but this approach uses a static
challenge (can be unprotected) and therefore, static luks keyslot as
the response. This is done with the yubikey in challenge-response
mode, which basically hashes some input (512bits for HMAC-SHA1)
against a write-only secret contained in the Yubikey.
Some existing discussion of figuring out how to do better Yubikey OTP
with LUKS is at [5].
There is a lot of discussion about atomicity of LUKS headers during
keyslot updates etc. in terms of reliability and failure-modes. I
would short-circuit all that discussion by just accepting that users
of such a system should be keeping backups of their LUKS headers, and
ensure they keep at least one such backup that has a known good static
"disaster recovery" keyslot preserved somewhere at all times.
And of course, with all encryption or just hard disks generally - just
be prepared to lose all of your data at any time :)
[1] https://github.com/flowolf/initramfs_ykfde/blob/master/init
[2] https://blog.flo.cx/2012/09/cryptsetup-and-the-yubikey/
[3] https://github.com/cornelinux/yubikey-luks
[4] https://github.com/tfheen/ykfde
[5] https://github.com/cornelinux/yubikey-luks/issues/1
> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@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-users/568DF67E.4040408%40openmailbox.org.
> For more options, visit https://groups.google.com/d/optout.
Obviously OTP modes are best and there was even an implementation [1]
(corresponding blog post at [2]). It didn't seem to gain any traction.
[3] & [4] seem to be the main yubikey-luks solutions (in Debian-land
at least) out there currently, but this approach uses a static
challenge (can be unprotected) and therefore, static luks keyslot as
the response. This is done with the yubikey in challenge-response
mode, which basically hashes some input (512bits for HMAC-SHA1)
against a write-only secret contained in the Yubikey.
Some existing discussion of figuring out how to do better Yubikey OTP
with LUKS is at [5].
There is a lot of discussion about atomicity of LUKS headers during
keyslot updates etc. in terms of reliability and failure-modes. I
would short-circuit all that discussion by just accepting that users
of such a system should be keeping backups of their LUKS headers, and
ensure they keep at least one such backup that has a known good static
"disaster recovery" keyslot preserved somewhere at all times.
And of course, with all encryption or just hard disks generally - just
be prepared to lose all of your data at any time :)
[1] https://github.com/flowolf/initramfs_ykfde/blob/master/init
[2] https://blog.flo.cx/2012/09/cryptsetup-and-the-yubikey/
[3] https://github.com/cornelinux/yubikey-luks
[4] https://github.com/tfheen/ykfde
[5] https://github.com/cornelinux/yubikey-luks/issues/1
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@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-users/568DF67E.4040408%40openmailbox.org.
> For more options, visit https://groups.google.com/d/optout.
Rusty Bird
Jan 7, 2016, 8:25:22 AM1/7/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki, ipet...@gmail.com, Joanna Rutkowska
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rusty Bird:
Hash: SHA512
> - To protect the LUKS key with "something you have" -- the AEM
> stick -- we could add a secret.luks.encrypted file, which holds the
> actual LUKS passphrase (not usually typed in during boot, only when
> unsealing fails due to upgrades), symmetrically encrypted with
> another passphrase.
Ugh, this doesn't prevent a multi-stage attack:
> stick -- we could add a secret.luks.encrypted file, which holds the
> actual LUKS passphrase (not usually typed in during boot, only when
> unsealing fails due to upgrades), symmetrically encrypted with
> another passphrase.
1. the attacker visually captures the disk passphrase during a
successful boot
2. later, they take a copy of the encrypted disk and infect the system
3. later, the user attaches the AEM stick and boots; the infected
system copies secret.luks.encrypted.sealed somewhere -- cue scary
music as STATEFULNESS reveals itself from the shadows yet again; now
the user notices the failed unseal
4. the attacker quickly gets to the infected notebook; then reverts it
to the original state, and unseals + decrypts the LUKS passphrase
Portable Qubes installations limit the attacker to copying only a
couple of megabytes of the encrypted disk data during (3), instead of
taking a complete copy during (2); they also make the infection harder.
Or secret.luks.encrypted.sealed could be on a second-stage AEM stick,
which the user should connect *after* verifying the OTP... :\
> - To protect the secret from visibility, we could plug in Matthew
> Garrett's TOTP concept via a secret.totp file containing the seed.
> And then add a non-default GRUB boot entry to unseal the regular
> static secret.{txt,png}, in case the user doesn't have their
> authenticator device with them.
of verifier (not prover) mode, simultaneously displaying OTPs for a
couple of preceding and following 30-second time steps. Is there
anything like that for Android?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJWjmc2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfDhoP/2sUo7zH0jm1Q2NB2Z6KbQnm
FVKsT3AE5vt4WJhyalmW798cxMA/EGQZ1vlGYYbDwsWLC2V1kpAaEhaGM81ErTq9
QKwFMKo7h+uzVBC8NOBB9/xO40zVyhRghommer/rb4+ilRjBDfDCOuPaghzhPIIb
wHBxsqjgLBP3QuVxQwG9THKqLpYhAauxqMcEvPy31YUAWQ6xa5jSOGtY0xjI24gu
EUhxcIXEl4uCovcq0noPpkYvRaPtq+bd7ZGZB26MoI/x/rTa23YT0XbyPudMCs7v
lRlYGIUKbAKut5dkpTNhpGKgJ1Xwux+Eyi3SdlWhmS+zonJPBCmv7bACXjRZHF2w
58QnRFrJCsIqdGk7j+GhCOR8Gb+JP+c6FSMNZjvxzH7SlqrQvZOl5LUJyRzpCjlL
55wzRKAkvQcxEoNOAkhMrjbcvNBl4hvLpVGI+LZBvW8dnGU4YBtaWxYkGCLaAb0h
g9wqax2B8C+sMY1mmoJIqZM7Jupd5C4NUCWsRNQm95UwpszO2yDvg7ODem+VbE/Q
7EE8Zfpk3ZomAZzkE8sAJRQ4H+7RsVJ3o0sUO7R5dLq9vENgVYkjBUCHq/uyZ+gx
hWAdmtS6CFpUuDlu3Bk3NBJ9JB+7/ApCWRx5mwilN2bOE8IOJXAIbwQdebdW76jx
cC4Krjfj3NPxV2NOwTRg
=XKDd
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jan 17, 2016, 10:51:28 AM1/17/16
to Rusty Bird, qubes...@googlegroups.com, ipet...@gmail.com, Joanna Rutkowska
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jan 07, 2016 at 01:25:10PM +0000, Rusty Bird wrote:
> Rusty Bird:
> > - To protect the LUKS key with "something you have" -- the AEM
> > stick -- we could add a secret.luks.encrypted file, which holds the
> > actual LUKS passphrase (not usually typed in during boot, only when
> > unsealing fails due to upgrades), symmetrically encrypted with
> > another passphrase.
>
> Ugh, this doesn't prevent a multi-stage attack:
>
> 1. the attacker visually captures the disk passphrase during a
> successful boot
> 2. later, they take a copy of the encrypted disk and infect the system
> 3. later, the user attaches the AEM stick and boots; the infected
> system copies secret.luks.encrypted.sealed somewhere -- cue scary
> music as STATEFULNESS reveals itself from the shadows yet again; now
> the user notices the failed unseal
And this is great thing about YubiKey - you can't easily copy it.
Otherwise yes, AEM stick could be "something you have" factor (not sure
if exactly the way you've proposed, but something like this).
> 4. the attacker quickly gets to the infected notebook; then reverts it
> to the original state, and unseals + decrypts the LUKS passphrase
>
> Portable Qubes installations limit the attacker to copying only a
> couple of megabytes of the encrypted disk data during (3), instead of
> taking a complete copy during (2); they also make the infection harder.
>
> Or secret.luks.encrypted.sealed could be on a second-stage AEM stick,
> which the user should connect *after* verifying the OTP... :\
>
> > - To protect the secret from visibility, we could plug in Matthew
> > Garrett's TOTP concept via a secret.totp file containing the seed.
> > And then add a non-default GRUB boot entry to unseal the regular
> > static secret.{txt,png}, in case the user doesn't have their
> > authenticator device with them.
>
> The mobile device's TOTP generator would have to be working in a sort
> of verifier (not prover) mode, simultaneously displaying OTPs for a
> couple of preceding and following 30-second time steps. Is there
> anything like that for Android?
I don't think so...
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWm7h3AAoJENuP0xzK19csdugH/RV7m3yDqt2nopo1Q5F9X/mJ
5JO/IGGCAYjFm+vZChxP0NvU5pfGe1RJEu3UnuG/lQTGppMkT527EzUlzRAQTG23
z1ioPwu+Y4+iTwdsE1FpeEPsqnZw/yHeBYo0Mo2XcuTuqobe2kEn9ufanovjmFdN
jbqfTk8UfVdAe7jX7jiEeoU2Oae/btqO0gS8j7W7ktXOSfePeZpXo91eeoAP8bqb
gR/oXrAtVECEz8QSqwIS4FEUN9Ns8IrcQtRfND/AuApE2JQ2Fs52IHBhMnhBYmCA
qJtwFGqraarEOuGno8bHpHQ5n0eTP36GQRguAGzLOgwHH/lCAcJZhdTT3sEJaSQ=
=Lm3q
-----END PGP SIGNATURE-----
Hash: SHA256
On Thu, Jan 07, 2016 at 01:25:10PM +0000, Rusty Bird wrote:
> Rusty Bird:
> > - To protect the LUKS key with "something you have" -- the AEM
> > stick -- we could add a secret.luks.encrypted file, which holds the
> > actual LUKS passphrase (not usually typed in during boot, only when
> > unsealing fails due to upgrades), symmetrically encrypted with
> > another passphrase.
>
> Ugh, this doesn't prevent a multi-stage attack:
>
> 1. the attacker visually captures the disk passphrase during a
> successful boot
> 2. later, they take a copy of the encrypted disk and infect the system
> 3. later, the user attaches the AEM stick and boots; the infected
> system copies secret.luks.encrypted.sealed somewhere -- cue scary
> music as STATEFULNESS reveals itself from the shadows yet again; now
> the user notices the failed unseal
Otherwise yes, AEM stick could be "something you have" factor (not sure
if exactly the way you've proposed, but something like this).
> 4. the attacker quickly gets to the infected notebook; then reverts it
> to the original state, and unseals + decrypts the LUKS passphrase
>
> Portable Qubes installations limit the attacker to copying only a
> couple of megabytes of the encrypted disk data during (3), instead of
> taking a complete copy during (2); they also make the infection harder.
>
> Or secret.luks.encrypted.sealed could be on a second-stage AEM stick,
> which the user should connect *after* verifying the OTP... :\
>
> > - To protect the secret from visibility, we could plug in Matthew
> > Garrett's TOTP concept via a secret.totp file containing the seed.
> > And then add a non-default GRUB boot entry to unseal the regular
> > static secret.{txt,png}, in case the user doesn't have their
> > authenticator device with them.
>
> The mobile device's TOTP generator would have to be working in a sort
> of verifier (not prover) mode, simultaneously displaying OTPs for a
> couple of preceding and following 30-second time steps. Is there
> anything like that for Android?
- --
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-----
Version: GnuPG v2
5JO/IGGCAYjFm+vZChxP0NvU5pfGe1RJEu3UnuG/lQTGppMkT527EzUlzRAQTG23
z1ioPwu+Y4+iTwdsE1FpeEPsqnZw/yHeBYo0Mo2XcuTuqobe2kEn9ufanovjmFdN
jbqfTk8UfVdAe7jX7jiEeoU2Oae/btqO0gS8j7W7ktXOSfePeZpXo91eeoAP8bqb
gR/oXrAtVECEz8QSqwIS4FEUN9Ns8IrcQtRfND/AuApE2JQ2Fs52IHBhMnhBYmCA
qJtwFGqraarEOuGno8bHpHQ5n0eTP36GQRguAGzLOgwHH/lCAcJZhdTT3sEJaSQ=
=Lm3q
-----END PGP SIGNATURE-----
Achim Patzner
Jan 17, 2016, 12:41:23 PM1/17/16
to qubes-users
Am 06.01.2016 um 22:13 schrieb Marek Marczykowski-Górecki <marm...@invisiblethingslab.com>:
> Currently not. But probably possible to implement. The idea is to encrypt
> "something" using next OTP (from yubikey). Then after successful mount,
> remove the old "something" and replace with the new value (since disk is
> already mounted, it can access shared secret of yubikey, so it is
> possible then), for the next boot.
Wouldn’t a device like the USB Armory a better choice for this kind of tool?
> Currently not. But probably possible to implement. The idea is to encrypt
> "something" using next OTP (from yubikey). Then after successful mount,
> remove the old "something" and replace with the new value (since disk is
> already mounted, it can access shared secret of yubikey, so it is
> possible then), for the next boot.
Achim
Marek Marczykowski-Górecki
Jan 17, 2016, 6:45:31 PM1/17/16
to Achim Patzner, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
resistance (I mean crush and water) - yubikey is pretty good at it - I'm
wearing it in my pocket and no problem yet (while a lot of USB sticks
were broken this way...).
But other than that - yes, much more flexible. For example can be used as
"remote attestation" device in pretty standard way. And even using a LED
for confirmation that laptop is good, so user may enter the passphrase.
So, yes - pretty good idea.
- --
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-----
Version: GnuPG v2
X76PWO8XPWhPGvtSScgF4lbwYhz15iIFARUGf4NW7l48W/m72bjxgtQsg3bMpuPE
1RApGjJoe360qmDigwMrK4wYnQm7lPdP4st2mBbaQsD2/s37ZZXKXLajA0YKdxMH
tF8Y/chsrlnOsMotNf1YTB6OfWcgu8AuAZmyp6H99XMaNwGgrjQDL+0aQjG3Ba2E
o7+f9xAlgzmnCFRtBmk8tvk7ebo12kBNDH7gx0O2xnfNg7ohNfXWgp0sznPLPUPz
UCkPcI17F8000wJDuM0NnkBWglVrRqf4EK7MJld5vQGbaBJTn8kIklv3ptVs+Pg=
=WChp
-----END PGP SIGNATURE-----
Tim W
Jan 18, 2016, 9:00:34 AM1/18/16
to qubes-users
Iam likley missing something but, would it be possible to use the one challenge/response setup with the aem if you used detached luks header and put it on the aem stick and remove.its prc from the chain?
My vision of.the process is it would first boot from aem entering srk passphrase. If ok, reveal tpm stored key. Then proceed to yubikey c/r auth which after decrypt enters new challenge and key in luks slot and updated luks header.
My vision of.the process is it would first boot from aem entering srk passphrase. If ok, reveal tpm stored key. Then proceed to yubikey c/r auth which after decrypt enters new challenge and key in luks slot and updated luks header.
Achim Patzner
Jan 18, 2016, 4:37:33 PM1/18/16
to qubes-users
Am 18.01.2016 um 00:45 schrieb Marek Marczykowski-Górecki <marm...@invisiblethingslab.com>:
>> Wouldn’t a device like the USB Armory seem to be a better choice for this kind of tool?
I’m carrying an USB armory around; it is my container for keys and my transparent VPN device on Windows and Mac OS (offering an IP address and a default route to the system it is connecting via DHCP and using its Internet connection sharing to get to the outside). It is storing the checksums of all relevant files on my work machine.
> But other than that - yes, much more flexible. For example can be used as
> "remote attestation" device in pretty standard way. And even using a LED
> for confirmation that laptop is good, so user may enter the passphrase.
One reason we considered Lenovo P70 is the fact that one of the USB ports is a separate board connected to the rest with an internal cable; we’re considering rerouting this to a USB Armory inside the machine and routing IO lines to the unused USB socket. An off the shelf “USB key” providing an innocent light show will be less suspicious.
Achim
>> Wouldn’t a device like the USB Armory seem to be a better choice for this kind of tool?
>
> Much more expensive ($130 vs $40). And not sure about physical
> resistance (I mean crush and water) - yubikey is pretty good at it - I'm
> wearing it in my pocket and no problem yet (while a lot of USB sticks
> were broken this way…).
> Much more expensive ($130 vs $40). And not sure about physical
> resistance (I mean crush and water) - yubikey is pretty good at it - I'm
> wearing it in my pocket and no problem yet (while a lot of USB sticks
I’m carrying an USB armory around; it is my container for keys and my transparent VPN device on Windows and Mac OS (offering an IP address and a default route to the system it is connecting via DHCP and using its Internet connection sharing to get to the outside). It is storing the checksums of all relevant files on my work machine.
> But other than that - yes, much more flexible. For example can be used as
> "remote attestation" device in pretty standard way. And even using a LED
> for confirmation that laptop is good, so user may enter the passphrase.
Achim
Joe
Aug 28, 2018, 1:41:50 PM8/28/18
to qubes-users
I want to use AEM, but I am currently using yubikey Chal/Resp for LUKS at boot time (https://github.com/the2nd/ykluks).
I am sure installing AEM would conflict in some way.
I would like AEM and ykluks to work simultaneously if possible... or if AEM can use the yubikey instead of a USB drive, and still be used as 2nd factor to decrypt the multiple LUKS devices.
Reply all
Reply to author
Forward
0 new messages