Cryptsetup LUKS Nuke Option
646 views
Skip to first unread message
flux
Jun 29, 2016, 10:02:22 AM6/29/16
to qubes-users
I really think this feature would fit in Qubes.
https://www.kali.org/tutorials/emergency-self-destruction-luks-kali/
TL;DR this patch uses one LUKS keyslot to add a password which wipes the LUKS header, effectively making all data in the LUKS container inaccessible until the header is restored.
Perfect for when you're being asked for a password, especially because you can pretend it was the examiners fault that the drive is "dead."
You can then (hopefully) go home and redtore the LUKS header from a separate location and go about your merry day.
Thoughts? If no one strongly disagrees I can put it in an issue.
Andrew
Jun 29, 2016, 12:47:31 PM6/29/16
to qubes...@googlegroups.com
flux:
I just don't really see the point.
If you envision the 'examiner' being a LEO, this is likely a terrible
strategy. This would almost certainly qualify as obstruction of justice
and destruction of evidence. Also, it's useless in cases where the
adversary already has a disk image.
I can't think of a scenario where:
1) You are being coerced for your password and have no legal defense
2) The LEO is dumb enough not to make a disk image (impossible these
days, except perhaps for 'routine' border searches?)
3) The consequences for destroying the evidence are less severe than the
consequences for simply refusing to comply (taking into account local
laws like RIPA, and confidence in your passphrase strength and secrecy)
On the other hand, if you're being subjected to rubber-hose
cryptanalysis by infosec amateurs, it might work to deny the adversary
information access, but you're still gonna have an awfully bad time
(i.e., die). It seems in this case something like TrueCrypt's hidden
volumes are better: you at least stand a chance of convincing the
adversary you don't have anything interesting.
I actually am really curious how you envision this feature saving the
day! :)
Andrew
If you envision the 'examiner' being a LEO, this is likely a terrible
strategy. This would almost certainly qualify as obstruction of justice
and destruction of evidence. Also, it's useless in cases where the
adversary already has a disk image.
I can't think of a scenario where:
1) You are being coerced for your password and have no legal defense
2) The LEO is dumb enough not to make a disk image (impossible these
days, except perhaps for 'routine' border searches?)
3) The consequences for destroying the evidence are less severe than the
consequences for simply refusing to comply (taking into account local
laws like RIPA, and confidence in your passphrase strength and secrecy)
On the other hand, if you're being subjected to rubber-hose
cryptanalysis by infosec amateurs, it might work to deny the adversary
information access, but you're still gonna have an awfully bad time
(i.e., die). It seems in this case something like TrueCrypt's hidden
volumes are better: you at least stand a chance of convincing the
adversary you don't have anything interesting.
I actually am really curious how you envision this feature saving the
day! :)
Andrew
Alex
Jun 29, 2016, 12:52:54 PM6/29/16
to qubes...@googlegroups.com
On 06/29/2016 06:47 PM, Andrew wrote:
> flux:
>> I really think this feature would fit in Qubes.
>> [...]
> flux:
>> I really think this feature would fit in Qubes.
>
> I just don't really see the point.
> [...]
> I just don't really see the point.
Me neither; and please remember that in software projects "all features
start at -100 points" (e.g.
https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/)
for sake of preventing feature-creep and contain maintainability burden.
Just because it's cool / it can be done it does not automatically have
to be done ;) But if you provide a valid scenario, as Andrew said, maybe
the Qubes team may implement it!
--
Alex
flux
Jun 29, 2016, 5:30:35 PM6/29/16
to qubes-users
You bring valid points, I was definitely excited to learn about the feature.
My thoughts were more along the lines of mitigative travel protection crossing borders and such. Like, you can boot to decryption but if the device is seized, no valid decryption can actually be performed. But as you say, depending on your situation that could be disadvantageous. I additionally just enjoy the idea of separating keys from locks regardless of the encrypted state of those keys.
Let me know what you think. Maybe if it doesn't go into qubes mainline it could be better served ending up as a guide somewhere, I'd be happy to do that on my own and post about it.
Thanks!
J.M. Porup
Jun 29, 2016, 6:57:35 PM6/29/16
to qubes...@googlegroups.com
On Wed, Jun 29, 2016 at 02:30:34PM -0700, flux wrote:
> My thoughts were more along the lines of mitigative travel protection crossing borders and such. Like, you can boot to decryption but if the device is seized, no valid decryption can actually be performed. But as you say, depending on your situation that could be disadvantageous. I additionally just enjoy the idea of separating keys from locks regardless of the encrypted state of those keys.
FWIW, I support this feature request as well. Search the archives for
> My thoughts were more along the lines of mitigative travel protection crossing borders and such. Like, you can boot to decryption but if the device is seized, no valid decryption can actually be performed. But as you say, depending on your situation that could be disadvantageous. I additionally just enjoy the idea of separating keys from locks regardless of the encrypted state of those keys.
previous discussion early 2015 (Caspar Bowden indicated his support for
the feature, before he passed.)
Overreliance on a boot nuke feature would, as pointed out, be unwise.
But as a journalist, I can easily imagine a scenario where I am crossing
a border, am asked/ordered to decrypt my laptop, and I prefer to nuke
the hard drive rather than comply.
Sure, border officials might image the disk first, but how many laptop
users have such a feature?
I think of it like TLS. Arguing that X.509 certificate infrastructure is
broken and not (very) trustworthy doesn't mean we should insist Qubes
return to a non-HTTPS website. It's a layer of protection, one of many.
So I support this feature request, while noting the priority is low.
jmp
Andrew
Jun 29, 2016, 8:04:45 PM6/29/16
to qubes...@googlegroups.com
J.M. Porup:
But tell me: why/when exactly would you use such a feature? Surely when
entering the US you would have to be crazy to use this unless you are
afraid your passphrase is too weak/compromised and you took no other
precautions. You could be charged with a crime simply for destroying
the data, whereas you have a 5th amendment right not to hand over the
passphrase!
You could also, before traveling, XOR your LUKS header with some known,
memorable data (perhaps the output of iterated SHA256 on a separate
passphrase). Bring along a live CD/USB and un-do it once you're past
the border.
Or change your passphrase to a very long random string you give to a
friend/family member, whom you only call and direct to read the
passphrase (which you subsequently change) after crossing the border
without interception.
Or do something similar but with a webserver or email/IRC/Slack bot:
give it your temporary password, and have it provide the password if you
request it soon after expected arrival, or shred the password if you
don't request it in time.
There are surely a million other, better ways to avoid compelled data
decryption at borders. Anyway I don't have a problem with this feature.
I just still don't understand why...
Andrew
entering the US you would have to be crazy to use this unless you are
afraid your passphrase is too weak/compromised and you took no other
precautions. You could be charged with a crime simply for destroying
the data, whereas you have a 5th amendment right not to hand over the
passphrase!
You could also, before traveling, XOR your LUKS header with some known,
memorable data (perhaps the output of iterated SHA256 on a separate
passphrase). Bring along a live CD/USB and un-do it once you're past
the border.
Or change your passphrase to a very long random string you give to a
friend/family member, whom you only call and direct to read the
passphrase (which you subsequently change) after crossing the border
without interception.
Or do something similar but with a webserver or email/IRC/Slack bot:
give it your temporary password, and have it provide the password if you
request it soon after expected arrival, or shred the password if you
don't request it in time.
There are surely a million other, better ways to avoid compelled data
decryption at borders. Anyway I don't have a problem with this feature.
I just still don't understand why...
Andrew
Andrew David Wong
Jun 30, 2016, 12:39:44 AM6/30/16
to flux, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
We've actually had a ticket for this since 2014:
https://github.com/QubesOS/qubes-issues/issues/921
While I appreciate others' skepticism about the usefulness of this
feature, I can, nonetheless, imagine it being useful in any situation
that meets the following criteria:
1. You do not want to be found to be in possession of encrypted data.
2. You do not know well in advance that your disk will be searched.
3. You have the opportunity to use the nuke option before your
adversary gains access to your disk.
4. You do not have the opportunity to safely decrypt the disk before
wiping it.
To make this more concrete, let's imagine a scenario:
You're traveling through some part of the world where you didn't
expect to be searched, but for whatever reason, you've stumbled across
some kind of checkpoint, and you realize that people's belongings,
including their electronic devices, are being searched (not
necessarily by law enforcement officers). You can tell, or reasonably
suspect, that people ahead of you in line are being forced to
unlock/decrypt their devices, but you're still far enough away to use
your laptop without (or with an acceptably low risk of) being noticed
(e.g., you're in a crowd of people waiting to be searched).
(Alternatively, perhaps you're somewhere where the use of encryption
is illegal or would arouse suspicion you'd rather avoid.) However, you
don't have control over your immediate surroundings (again, maybe
you're in a crowd), so you don't want to enter your passphrase and
decrypt your disk in order to wipe it (since a person or camera might
see which keys you type as you enter it, or at least enough of them to
make a subsequent brute force search more feasible), or since someone
might take your laptop in its decrypted state before the disk is fully
wiped (e.g., while you're waiting for it to finish). Your safest
option here would be to have a "nuke" keyslot and use it.
Whether this provides you with any plausible deniability hinges on the
technical implementation, but if I understand it correctly, the nuke
option would entirely wipe the LUKS header, leaving only encrypted
data that is indistinguishable from random bits. So, after using such
an option, you could plausibly deny that there is any encrypted data
on the disk and instead insist that it contains only random bits. But
why would it contain only random bits? Two plausible (albeit similar)
reasons:
A. You wiped the disk in preparation for travel. Some businesses, as a
matter of policy, have their employees travel with wiped laptops, then
download whatever data they need over a secure channel once their
reach their destination. (This is especially true if the business
deals with sensitive data and/or if their employees travel to places
like China.) Writing random bits to a disk is, of course, a standard
method of wiping it.
B. You've prepared the disk for an encrypted container but haven't
written it yet. (Perhaps you're traveling to the place where you will
receive the data.) Writing random bits to a disk is a standard method
of preparing it for an encrypted container, since failing to do so can
reveal the size of the encrypted container and its usage patterns.
Note: The foregoing considerations do not, by themselves, imply
anything about what the priority of this feature ought to be -- only
that it would not be universally useless.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXdKKCAAoJENtN07w5UDAwrdAQAKxZQt1Y1lEFKcHbj30/X7yT
FaIC6zy4HYujEOqhM+OIhZXRCqASB8g12kljeLRScNr52ZeuufYFpGSOpEdlt89W
CcNKVorXLqd0qLd3/gFuV7v1ZKlFEs6U0aBdIHYGgj/w1oG2THIoor8NDh59wc9U
8jkM4n3JAR2ffvqsD60wilidnA7nMz+N5V/2+fTWrUpJjElCW4zuepae6OhYf7sf
5ESqHGrN5c3l7hriJPPnkcjHjZ7xbPr6DIHW9e12iMZp3Xl7hXHSURr80qYbPXOF
SuW4h/Uho2CqjrcEXw3YydHvUmpAn6YCauLcKl1ZA+s+f1gBHB0eG143+uptTLUq
A96Q9ZIS8x9AT3vQfiwKcLb7ixbKqgPY04yU4Ia3D/A3uSmRWkE4ISmM4clsG5M5
/Fg+TONZp/SlzK2qDgsCspFChZIs7fwaZSb+QCLgxq4Ji71vt0Tb80QTuoSkzmMR
gYruvqydwD7GkNFQe1ElxznwlJMifw3B9+sFHOdFkXg1St+5ZIPaf60MefexMZay
55579NKn190AXuy2k//AF+svWMGuOhjBiT+6v++FxNhOF7XhqeEvGdXfyoxPdHL1
6IYrYZJ780VNzhOxqnDk5u9UYVvWAe7sVuFof3sN/7TsJ4PSIRfX20p/uKJ5MAVI
BWAYu62tC2UrqIjpA5BE
=Qm2g
-----END PGP SIGNATURE-----
Hash: SHA512
https://github.com/QubesOS/qubes-issues/issues/921
While I appreciate others' skepticism about the usefulness of this
feature, I can, nonetheless, imagine it being useful in any situation
that meets the following criteria:
1. You do not want to be found to be in possession of encrypted data.
2. You do not know well in advance that your disk will be searched.
3. You have the opportunity to use the nuke option before your
adversary gains access to your disk.
4. You do not have the opportunity to safely decrypt the disk before
wiping it.
To make this more concrete, let's imagine a scenario:
You're traveling through some part of the world where you didn't
expect to be searched, but for whatever reason, you've stumbled across
some kind of checkpoint, and you realize that people's belongings,
including their electronic devices, are being searched (not
necessarily by law enforcement officers). You can tell, or reasonably
suspect, that people ahead of you in line are being forced to
unlock/decrypt their devices, but you're still far enough away to use
your laptop without (or with an acceptably low risk of) being noticed
(e.g., you're in a crowd of people waiting to be searched).
(Alternatively, perhaps you're somewhere where the use of encryption
is illegal or would arouse suspicion you'd rather avoid.) However, you
don't have control over your immediate surroundings (again, maybe
you're in a crowd), so you don't want to enter your passphrase and
decrypt your disk in order to wipe it (since a person or camera might
see which keys you type as you enter it, or at least enough of them to
make a subsequent brute force search more feasible), or since someone
might take your laptop in its decrypted state before the disk is fully
wiped (e.g., while you're waiting for it to finish). Your safest
option here would be to have a "nuke" keyslot and use it.
Whether this provides you with any plausible deniability hinges on the
technical implementation, but if I understand it correctly, the nuke
option would entirely wipe the LUKS header, leaving only encrypted
data that is indistinguishable from random bits. So, after using such
an option, you could plausibly deny that there is any encrypted data
on the disk and instead insist that it contains only random bits. But
why would it contain only random bits? Two plausible (albeit similar)
reasons:
A. You wiped the disk in preparation for travel. Some businesses, as a
matter of policy, have their employees travel with wiped laptops, then
download whatever data they need over a secure channel once their
reach their destination. (This is especially true if the business
deals with sensitive data and/or if their employees travel to places
like China.) Writing random bits to a disk is, of course, a standard
method of wiping it.
B. You've prepared the disk for an encrypted container but haven't
written it yet. (Perhaps you're traveling to the place where you will
receive the data.) Writing random bits to a disk is a standard method
of preparing it for an encrypted container, since failing to do so can
reveal the size of the encrypted container and its usage patterns.
Note: The foregoing considerations do not, by themselves, imply
anything about what the priority of this feature ought to be -- only
that it would not be universally useless.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXdKKCAAoJENtN07w5UDAwrdAQAKxZQt1Y1lEFKcHbj30/X7yT
FaIC6zy4HYujEOqhM+OIhZXRCqASB8g12kljeLRScNr52ZeuufYFpGSOpEdlt89W
CcNKVorXLqd0qLd3/gFuV7v1ZKlFEs6U0aBdIHYGgj/w1oG2THIoor8NDh59wc9U
8jkM4n3JAR2ffvqsD60wilidnA7nMz+N5V/2+fTWrUpJjElCW4zuepae6OhYf7sf
5ESqHGrN5c3l7hriJPPnkcjHjZ7xbPr6DIHW9e12iMZp3Xl7hXHSURr80qYbPXOF
SuW4h/Uho2CqjrcEXw3YydHvUmpAn6YCauLcKl1ZA+s+f1gBHB0eG143+uptTLUq
A96Q9ZIS8x9AT3vQfiwKcLb7ixbKqgPY04yU4Ia3D/A3uSmRWkE4ISmM4clsG5M5
/Fg+TONZp/SlzK2qDgsCspFChZIs7fwaZSb+QCLgxq4Ji71vt0Tb80QTuoSkzmMR
gYruvqydwD7GkNFQe1ElxznwlJMifw3B9+sFHOdFkXg1St+5ZIPaf60MefexMZay
55579NKn190AXuy2k//AF+svWMGuOhjBiT+6v++FxNhOF7XhqeEvGdXfyoxPdHL1
6IYrYZJ780VNzhOxqnDk5u9UYVvWAe7sVuFof3sN/7TsJ4PSIRfX20p/uKJ5MAVI
BWAYu62tC2UrqIjpA5BE
=Qm2g
-----END PGP SIGNATURE-----
Andrew
Jun 30, 2016, 9:20:54 PM6/30/16
to qubes...@googlegroups.com
Andrew:
>
> Andrew
>
Actually, I think I get it now. Tell me if I'm wrong.
You want this to be a readily-accessible feature of Qubes. It's not
that you want to prepare to cross borders: you cross borders in the
course of your work. It's not even that you cross borders: you're
generally mobile, and you're a potential target. It makes sense to have
the ability to provide a quick failsafe if and when the need strikes.
Still, I think the better solution is to implement plausibly-deniable
per-VM encryption/hiding, as suggested when this topic came up back in
2015. Search for the qubes-users thread "Re: [qubes-users] feature
request: luksAddNuke".
Caspar actually supported this idea:
> I would really like to see this implemented
>
> --
> Caspar Bowden
> Qubes Policy Adviser"
Does this, or do these, already have a tracking ticket?
Andrew
> J.M. Porup:
>> On Wed, Jun 29, 2016 at 02:30:34PM -0700, flux wrote:
>>> My thoughts were more along the lines of mitigative travel protection crossing borders and such. Like, you can boot to decryption but if the device is seized, no valid decryption can actually be performed. But as you say, depending on your situation that could be disadvantageous. I additionally just enjoy the idea of separating keys from locks regardless of the encrypted state of those keys.
>>
>> FWIW, I support this feature request as well. Search the archives for
>> previous discussion early 2015 (Caspar Bowden indicated his support for
>> the feature, before he passed.)
>>
>> Overreliance on a boot nuke feature would, as pointed out, be unwise.
>> But as a journalist, I can easily imagine a scenario where I am crossing
>> a border, am asked/ordered to decrypt my laptop, and I prefer to nuke
>> the hard drive rather than comply.
>>
>> Sure, border officials might image the disk first, but how many laptop
>> users have such a feature?
>>
>> I think of it like TLS. Arguing that X.509 certificate infrastructure is
>> broken and not (very) trustworthy doesn't mean we should insist Qubes
>> return to a non-HTTPS website. It's a layer of protection, one of many.
>>
>> So I support this feature request, while noting the priority is low.
>>
>> jmp
>>
>
> [bullshit]
>> On Wed, Jun 29, 2016 at 02:30:34PM -0700, flux wrote:
>>> My thoughts were more along the lines of mitigative travel protection crossing borders and such. Like, you can boot to decryption but if the device is seized, no valid decryption can actually be performed. But as you say, depending on your situation that could be disadvantageous. I additionally just enjoy the idea of separating keys from locks regardless of the encrypted state of those keys.
>>
>> FWIW, I support this feature request as well. Search the archives for
>> previous discussion early 2015 (Caspar Bowden indicated his support for
>> the feature, before he passed.)
>>
>> Overreliance on a boot nuke feature would, as pointed out, be unwise.
>> But as a journalist, I can easily imagine a scenario where I am crossing
>> a border, am asked/ordered to decrypt my laptop, and I prefer to nuke
>> the hard drive rather than comply.
>>
>> Sure, border officials might image the disk first, but how many laptop
>> users have such a feature?
>>
>> I think of it like TLS. Arguing that X.509 certificate infrastructure is
>> broken and not (very) trustworthy doesn't mean we should insist Qubes
>> return to a non-HTTPS website. It's a layer of protection, one of many.
>>
>> So I support this feature request, while noting the priority is low.
>>
>> jmp
>>
>
>
> Andrew
>
Actually, I think I get it now. Tell me if I'm wrong.
You want this to be a readily-accessible feature of Qubes. It's not
that you want to prepare to cross borders: you cross borders in the
course of your work. It's not even that you cross borders: you're
generally mobile, and you're a potential target. It makes sense to have
the ability to provide a quick failsafe if and when the need strikes.
Still, I think the better solution is to implement plausibly-deniable
per-VM encryption/hiding, as suggested when this topic came up back in
2015. Search for the qubes-users thread "Re: [qubes-users] feature
request: luksAddNuke".
Caspar actually supported this idea:
> I would really like to see this implemented
>
> --
> Caspar Bowden
> Qubes Policy Adviser"
Does this, or do these, already have a tracking ticket?
Andrew
Andrew David Wong
Jul 1, 2016, 1:32:52 AM7/1/16
to Andrew, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
Not sure if you received my message (immediately prior to your last
one in this thread).
We've had a ticket open for the nuke option for quite a while now:
https://github.com/QubesOS/qubes-issues/issues/921
As for the per-VM encryption option, see here:
https://github.com/QubesOS/qubes-issues/issues/1293#issuecomment-
229028321
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
XHY6GAVRrQ8+RWu3GDdfu0hbCrzKkDXWZFSECM1v5CQm30hOFq1agaY8ANjmwvOP
gQ2x24VmtXXqLDIKnnf85h5MPYJgsYYMTESr2hq3h5l/RCgfphJsbhrZblv9YfJs
bwG5diwcwCcXFmF25QmgxfHWNmrFH/dVs8d++I9jDg/T0jCHBhzqO9g9SXtNRa2x
E6mfKWuzU58xEE0ZoRUu6+PC8fPOyt9L0vUkM+VgZsyYcsLOCzd3qkNNuF02ViaM
VsfqzALWhWgbmV3vxy5Lt+YchcO/XGcN010i9DADQEiXBh5GcJtNAazKIX4vCkhp
AIfhPGjyDYaGETj351/nAf/vUJRivPR+TJ8cvWKciJSHOjY/UImzF48SnLT3MJYl
zEj6qFsjvbmo7kjOsxDZkKcimvNjYjA9OqLEiOh/P8TDtZPqZeJOegeg97MftDml
0tOQXYk6e4CZKW09WJn3h2BMK/hbhFjZXTHXw8CLcdHfOc8cfF2RRbnSylrGJFun
WKFVZ7EavlkcapDYLdq2TLiT8g7SmLH9gpe4kYNOaGftQ5lAApGYlsS78EayL9et
Wq5c6rd52f0yGwLBu7D6TeRrwXkRjrlJc9bB7Yc3WQdMqa0TqieVoV2qPg8gjhU8
iHpwhjjU633zI6M0k8Lg
=xYUA
-----END PGP SIGNATURE-----
TheFactory
Jul 22, 2016, 11:15:29 AM7/22/16
to qubes-users
Another good use for this feature is that you can pre-program in some landmines to destroy the drive and overcome brute force. Since the LUKS password prompt on my install of 3.2 has little to no delay between password attempts one could use a mid range gpu to try millions of passwords. The drive itself can be copied dozens of times to increase the chances of getting the password.
However if
If you had a limit of 10 or 20 tries before drive wipe.
And had a dozen or more fake passwords that would induce drive wipe.
And had some sort of delay in each password attempt built in.(veracrypt takes forever to process your password input for instance)
Using tpm ontop of this would also at least frustrate their attempts at mirroring the drive.
You could be reasonably certian that even powerful attempts at getting the drive open will be hopeless. Though, you may get yourself in some physical trouble.
I have wanted features like the above ones for some time.
Andrew
Jul 22, 2016, 2:59:31 PM7/22/16
to qubes...@googlegroups.com
TheFactory:
The problem with the "landmines" idea is that it requires the computer
to react to the passphrase and begin wiping the drive. In an offline
brute-force scenario, one assumes the adversary has a disk image, and
they're surely going to remove any "landmine wipe" feature from their
version of cryptsetup.
A setup requiring a key *both* in your TPM and derived from a passphrase
would really be ideal, though, yes. A PCR-constrained TPM outer key
makes brute force impractical without physically attacking the TPM. At
the same time, you don't rely solely on your TPM's security.
Andrew
to react to the passphrase and begin wiping the drive. In an offline
brute-force scenario, one assumes the adversary has a disk image, and
they're surely going to remove any "landmine wipe" feature from their
version of cryptsetup.
A setup requiring a key *both* in your TPM and derived from a passphrase
would really be ideal, though, yes. A PCR-constrained TPM outer key
makes brute force impractical without physically attacking the TPM. At
the same time, you don't rely solely on your TPM's security.
Andrew
Andrew David Wong
Jul 22, 2016, 7:03:40 PM7/22/16
to TheFactory, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-07-22 08:15, TheFactory wrote:
> Another good use for this feature is that you can pre-program in some
> landmines to destroy the drive and overcome brute force. Since the LUKS
> password prompt on my install of 3.2 has little to no delay between
> password attempts one could use a mid range gpu to try millions of
> passwords. The drive itself can be copied dozens of times to increase the
> chances of getting the password.
>
You can configure the iteration time manually by following the instructions
> Another good use for this feature is that you can pre-program in some
> landmines to destroy the drive and overcome brute force. Since the LUKS
> password prompt on my install of 3.2 has little to no delay between
> password attempts one could use a mid range gpu to try millions of
> passwords. The drive itself can be copied dozens of times to increase the
> chances of getting the password.
>
here:
https://www.qubes-os.org/doc/encryption-config/
Remember that the actual number of iterations depends on the speed of your
hardware. The cryptsetup default is one second (1000 milliseconds).
> However if
>
> If you had a limit of 10 or 20 tries before drive wipe.
>
> And had a dozen or more fake passwords that would induce drive wipe.
>
> And had some sort of delay in each password attempt built in.(veracrypt
> takes forever to process your password input for instance)
>
> Using tpm ontop of this would also at least frustrate their attempts at
> mirroring the drive.
>
> You could be reasonably certian that even powerful attempts at getting the
> drive open will be hopeless. Though, you may get yourself in some physical
> trouble.
>
> I have wanted features like the above ones for some time.
>
wouldn't attempt to brute force your encrypted drive using your hardware and
software. They would just take a copy the ciphertext and attempt to decrypt it
with their own software on their own (much more powerful) hardware. (However,
the use of a TPM would make a difference here, for the reason Andrew points
out.)
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
BeeNmyZzTYJzrRpp/BuUzUeCRJpbiNX1qaNTgQrhCvErXcPtj0UB1pzUG4JFIU1c
DfJkHiVWpK33q95oiJg6XlitWN/3bzjBN1g6oeK9v0tcyrQtdhACcJnP5z9EttDP
43PiQ0vvGPwzGYRTmGAW0swF5jGemAYtF3oFSwuoe9brScgZ61XRep3kyBIIeZy0
cWMQEfaFVa4wn5w73t1VVnk6//FlA7SBhqW16romN1Wlq0Cu7It1kP4ShhId722n
UL015dmvxAPlKcqjSSrNoBtZqJeg+37W5ewMJUlAZb7brMiW9qQ+S72k7pN8Degf
alCOO5LFwXo6mw8a/4GNg6/zAeQ7fJm9/3Xus/HU01qqUWBXC0HkAxLFWNR9/OsY
NIQKLsiSMe+Hn1XHgBjGaOngkP4M1HrcSnrjwGu3nCn6YTe1DQMODAFrJ00x4zHc
0KZsvM7DL3hAsYbBjeUqx0WgucXQMLZiraBGvGQpw9uZcmHz0M4rVbNxN+iogX7q
JBMqV3y8JKMAijpZHYAerzMaqUTjl/JcRYSUDDTMlZxl4k20tD9tX2tWqwWXgKqw
vOkleOXKw7pDUWPtuKV8nDW3tSm6w8ZrMk5srtxv2GS6T5+QII6FPO7K+NEAgu0x
KFQ17AyCiFlZeVxYeNct
=QqBa
-----END PGP SIGNATURE-----
TheFactory
Jul 22, 2016, 7:25:53 PM7/22/16
to qubes-users
Yes mirroring it and reading it outside of the hardware would make it easy, as well as having them be able to do it while you still have the machine. But that's why you pair it with tpm. To at least try and force them to use your machine.
The recent incident with an older iphone is one example that the method I mention still works. Whatever the newer iphones use is supposed to improve on that.
Chris Laprise
Jul 22, 2016, 7:39:49 PM7/22/16
to Andrew David Wong, TheFactory, qubes-users
nuke' feature is separate and suffers from a poor understanding of the
threat model.
As you point out, the main use case is when the user wants to initiate
destruction of the encrypted volume before it falls into the wrong
hands. But there is no need to patch LUKS to accomplish this, and using
only passphrases as the trigger mechanism is probably too cumbersome in
some situations anyway.
This could be scripted with better results and flexibility for the end
user, obviating any need to meddle with LUKS code.
If there is already an issue# for a 'panic button' type of feature
request, I'd suggest linking this thread to it.
Chris
Andrew David Wong
Jul 22, 2016, 8:04:37 PM7/22/16
to Chris Laprise, TheFactory, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
that there are threat models in which the "nuke option" can make sense.
> As you point out, the main use case is when the user wants to initiate
> destruction of the encrypted volume before it falls into the wrong hands.
> But there is no need to patch LUKS to accomplish this, and using only
> passphrases as the trigger mechanism is probably too cumbersome in some
> situations anyway.
>
> This could be scripted with better results and flexibility for the end
> user, obviating any need to meddle with LUKS code.
>
good idea to discuss the details of the implementation first.
> If there is already an issue# for a 'panic button' type of feature request,
> I'd suggest linking this thread to it.
>
https://github.com/QubesOS/qubes-issues/issues/921
There is currently no separate "panic button" feature request aside from this
one. That would be a different feature, for the reasons you point out.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
h8BcgW/JXy0pFR//tgOFu7HIBgnBHUVVixsQVqrJ7egYlQQ8GMs9iwqQIawx8Qld
rCt500ObQHvBA+AqGYma/zUnNsrKOpolXf5YmAXKboIS014eC+XsJwBwqvzoC34H
W4s2hKEXldrevjWdPQlDPAmwiFBP0Oo9lWp4lb2VguyDq3VF9Hq8YJmNpitMXn9K
HRPzCMqXOfKcxLj7uTV9Fq75EiVkO10Kizm/k0cpNgQJc8Rq+/izLpy4R2Tpfst+
teuLp3MmdGEFfTvOFvIT7tvi2mdtYAC03ePAfAabaulmsDpJnNwVhjLP69wgW64W
dYMq1lUYvwut7TbaOxkfutUo95f7y2zCkwR1J6md/NL5cOLJLP5kIcYlPSU+/FvD
TAmmze4p8Z1gA7THNKa4x7ZlsCd3A3/ml4e+HqAoJMqj69L9dVeCm2S3fExAkBB+
hFNLCQXHp4L6zAuOZKFSrxEbPZyEN2jtdgJrL7ProXDpfyNpKRyLGn6K7SLD52JJ
h9isJWfbODtX7x43T1YbigH+thoY3kq9+8IyTuc2K2vDgoUr5I77dKoRxqup8Alt
aIN3+N8WJugrNjcXI7dIlsllyasBt9wUA4n7zBwaYI9Vd7QMK4uzskrtz2DJMU6g
q6eLOX8hom/gmYDrYWse
=1tA3
-----END PGP SIGNATURE-----
0'192348'019438'0194328'0914328'0931
Jul 25, 2016, 4:27:47 AM7/25/16
to qubes-users
Hallo,
perhaps a fast option will be a strong encrypted disk and the nuke feature to destroy the password or better password-expansion (a hash which is longer than the password)...
- full disk encryption
- double full disk encryption with two independent passwords and independent encryption schemes
- customization of keyword length
- customization of the cipher
- no storage of passwords only of the password-expansion (which don't shorten the password like the standard hash, which makes the original password longer, so if you steal the disk you get some extra effort to crack the code)
- customization of the wrong tries, e.g. 10 times and than the "password-hashes" get wiped out (this avoids a simple brute forward attack)
- long key setup-time (of ca. 0.5 seconds), will slow down sophisticated brute forward attacks
In the end of the day the security of the password management, the security of one or the other cipher and the effectiveness of the wiping will safe your information.
Pro: It will be very fast (approx. under 3 seconds)
Cons: Not water-proof against Quantum Computer Attacks (you will need more modern ciphers)
Kind Regards
Andrew David Wong
Jul 25, 2016, 6:23:04 AM7/25/16
to 0'192348'019438'0194328'0914328'0931, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-07-25 01:27, 0'192348'019438'0194328'0914328'0931 wrote:
> Hallo,
>
> perhaps a fast option will be a strong encrypted disk and the nuke feature
> to destroy the password
I think you mean wipe the LUKS header.
> Hallo,
>
> perhaps a fast option will be a strong encrypted disk and the nuke feature
> to destroy the password
> or better password-expansion (a hash which is longer than the password)...
>
> - full disk encryption - double full disk encryption with two independent
> passwords and independent encryption schemes - customization of keyword
> length - customization of the cipher - no storage of passwords only of the
> password-expansion (which don't shorten the password like the standard
> hash, which makes the original password longer, so if you steal the disk
> you get some extra effort to crack the code) - customization of the wrong
> tries, e.g. 10 times and than the "password-hashes" get wiped out (this
> avoids a simple brute forward attack) - long key setup-time (of ca. 0.5
> seconds), will slow down sophisticated brute forward attacks
>
> In the end of the day the security of the password management, the
> security of one or the other cipher and the effectiveness of the wiping
> will safe your information.
>
> Pro: It will be very fast (approx. under 3 seconds)
> Cons: Not water-proof against Quantum Computer Attacks (you will need more
> modern ciphers)
Effective key length will be halved, so AES-256 should be roughly as strong as
pre-quantum AES-128, but that's still pretty secure.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
Z9UkEomyvSXjeQfK583AMKPI0Jc76ZHjPBu6U84CxSe86Vw+6geTMjhhJC/Ddg1B
Q3KyyuX1LRoJzLKXu8bOsN4olEZteLScIY+9c1bqcDBxckl6+fn+R5fKCOdfnT5Z
PJPAeAUxnkvTdUETgIEhKqxY3WjpOjjcG9vKvKlN7uPuTqxB35WNDb3bGpd+jX5k
xefdm4cLnPeWu1o2r6ZEkblzMAzSHVnMHGcb72yQsLj9q+RtcEnoTLw5z2cRq0YJ
SAokOG8EcBcPx3QGhJoJPoV92GT1OMXUpj9w+fUeU3Ns5Dom6UmKW1PWYYnD7AVW
tYIUaMZUKPShQ3cXwuyEuceZaeqvSFtW8uWdOnBYMvIsWPzPT1am5KOHONQUodLO
YMBTHLs7d29cTHvZH3ZjifDb+2bqFy/3kCUSzYZZnhd0GZQhyyzP2Vbu/5wodmkc
hbhqWIF886/jHOOmY2QjvHRRDnfees6Ja8hu35zICeBSKDHIKuEwh8xNSEJHsMhh
JA23m1GtZeADbnApo8V5IIbcpQ8uXoyCGAlwsNsP86n7QEq4geryG54g3Acf97Ba
vxUQ1gj8DlhsJZb/RadB+LjZ464yfKEedp+9UNnASMPz3K5fxyke+LxO8fGpyEQv
/a+7hloOlCYrFWLrGr9e
=3HYv
-----END PGP SIGNATURE-----
J.M. Porup
Jul 26, 2016, 9:47:25 AM7/26/16
to Chris Laprise, Andrew David Wong, TheFactory, qubes-users
On Fri, Jul 22, 2016 at 07:39:40PM -0400, Chris Laprise wrote:
> But there is no need to patch LUKS to accomplish this, and using only
> passphrases as the trigger mechanism is probably too cumbersome in some
> situations anyway.
>
> This could be scripted with better results and flexibility for the end user,
> obviating any need to meddle with LUKS code.
>
> If there is already an issue# for a 'panic button' type of feature request,
> I'd suggest linking this thread to it.
This code already exists:
> But there is no need to patch LUKS to accomplish this, and using only
> passphrases as the trigger mechanism is probably too cumbersome in some
> situations anyway.
>
> This could be scripted with better results and flexibility for the end user,
> obviating any need to meddle with LUKS code.
>
> If there is already an issue# for a 'panic button' type of feature request,
> I'd suggest linking this thread to it.
https://github.com/offensive-security/cryptsetup-nuke-keys
jmp
'190284'30918432'09182'034918'02943
Jul 29, 2016, 6:04:08 AM7/29/16
to qubes-users
Hello Andrew,
imagine you have many files with CID data (customer identified data) and you must protect them after the EU data protection law.
Now you must clean all data of the customer x.
And this should be secure.
A simple trick might be to use encryption. All files get encrypted with a own key. Instead of wiping the files, you can can simple destroy the keys (in a very secure way).
This is simple and fast.
But, it will be only valid, if and olny if the encryption will hold and really is safe.
Ok, the only way to do this will be the one time pad, which is absolutely secure (as long the length is long enough to prevent the guessing).
But for practical reasons, this might be take big disk spaces.
For a compromise you can combine two ciphers, so if one will work and the other will get problems today or tomorrow, this "smart wiping" of files, will work.
And by the way, if qubes os will have it's own real non-deterministic random generator, you can use the OTP to secure the passwords itself, which have a very limited disk space, so this will be feasible.
Kind Regards
Reply all
Reply to author
Forward
0 new messages