-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-06-29 07:02, flux wrote: > 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. >
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----- -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8c9670ac-b351-6be6-2774-0fb4c4b8307f%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
