Feature #15135
Emergency password for self destruction of LUKS keys
0%
Description
I would like to propose a ‘self destruct password’.
As suggested in Warnings session about persistence (https://tails.boum.org/doc/first_steps/persistence/warnings/index.en.html), `you can be forced or tricked to give out its passphrase`.
One solution for extreme cases could be a user defined password that would delete/corrupt with random bytes the persistent volume instead of opening It.
This discussion is check the viability of this feature.
Subtasks
Related issues
|
Is duplicate of Tails - |
Rejected | 2014-01-08 |
History
#1 Updated by nullhack 2017-12-30 10:32:04
I would like to propose a ‘self destruct password’.
As suggested in Warnings session about persistence (https://tails.boum.org/doc/first_steps/persistence/warnings/index.en.html), `you can be forced or tricked to give out its passphrase`.
One solution for extreme cases could be a user defined password that would delete/corrupt with random bytes the persistent volume instead of opening It.
This discussion is to check the viability of this feature.
#3 Updated by cacahuatl 2018-01-06 18:51:46
FWIW this is already a thing and is a feauture of Kali Linux but it involves patching cryptsetup:
https://www.kali.org/tutorials/emergency-self-destruction-luks-kali/
It might work in some situations, it won’t work in others (e.g. law enforcement).
#4 Updated by emmapeel 2018-01-09 14:02:06
- Category set to Persistence
- Priority changed from Normal to Low
I will bring this issue to the next contributors meeting, and I lower it’s priority because nobody has volunteered to do it.
Feel free to assign it to yourself in case you want to develop this feature.
Meanwhile it is on my plate for the discussion.
#5 Updated by Anonymous 2018-01-15 08:13:47
- Subject changed from Self destruct password to Emergency self destruction of LUKS password
#6 Updated by intrigeri 2018-01-15 09:01:45
- Subject changed from Emergency self destruction of LUKS password to Emergency password for self destruction of LUKS keys
#7 Updated by Anonymous 2018-01-18 16:46:22
- related to
Feature #6582: Emergency password for self destruction of LUKS keys added
#8 Updated by Anonymous 2018-01-18 16:46:47
- Status changed from New to Duplicate
Seems like this is actually a duplicate of Feature #6582.
#9 Updated by sajolida 2018-02-01 20:55:46
- related to deleted (
Feature #6582: Emergency password for self destruction of LUKS keys
#10 Updated by sajolida 2018-02-01 20:55:55
- is duplicate of
Feature #6582: Emergency password for self destruction of LUKS keys added
#11 Updated by Gaff 2018-06-08 04:04:35
The problem with this is that an attacker could easily copy the USB device before entering passwords. I guess as long as people understand the risks there’s no harm in trying but it’s a relatively complex topic.
Maybe more useful would be a quick-destroy option that runs from the greeter?
#12 Updated by cypherpunks 2018-06-08 06:21:23
Gaff wrote:
> The problem with this is that an attacker could easily copy the USB device before entering passwords. I guess as long as people understand the risks there’s no harm in trying but it’s a relatively complex topic.
>
> Maybe more useful would be a quick-destroy option that runs from the greeter?
Unfortunately, this feature would be rather useless in practice. USB devices do not support TRIM or SED, and due to dynamic wear leveling, bad block relocation, and overprovisioning, attempting to wipe them is a futile endeavor.