47

How do I configure my system to destroy all personal data when a certain password is entered? The motivation behind this being NSA stuff.

I imagine there being three primary usage cases.

  1. At login, the entering of a predetermined password triggers destruction of user data.
  2. At system wake up. entering of a predetermined password triggers destruction of personal data.
  3. Entering any privileged command with a predetermined password triggers destruction of personal data.

I know that something like

dd if=/dev/urandom of=/dev/$HOME

Should be adequate for data destruction. I don't know how to have that triggered by a certain password, however.

Bonus points if it then permits a login while the data is being deleted.

| improve this question | |
  • 9
    if you really want to make this work then you should encrypt your hard drive. this is because with no encryption you will have to overwrite the entire hard drive, but with encryption, you only have to overwrite the LUKS header (or whatever). – strugee Jan 3 '14 at 21:06
  • 1
    There is a pam_python module, that would probably make the implementation of what you want easier: ace-host.stuart.id.au/russell/files/pam_python – replay Jan 3 '14 at 21:08
  • 7
    If it's the NSA you're worried about then dd if=/dev/urandom of=/dev/$HOME isn't going to do much good. Even assuming they're stupid enough to use the operating system instead of removing the disk and reading it directly, there are forensic recovery companies that can get data from a disk that's been overwritten and physically burned. – OrangeDog Jan 3 '14 at 23:38
  • 2
    #1. If the NSA were really after you, they already silently exfiltrated your data weeks ago. #2. Encrypting your data gives the NSA the legal right to keep your data forever, or for however long it takes to decrypt it, whichever comes first. #3. Evidence of the destruction of evidence is often enough for the court to get you on something. Those 'secure erase' programs that fill your drive with zeroes or random gibberish are evidence that you destroyed something, and that would be brought up in court. – Ryan Ries Jan 4 '14 at 16:35
  • 3
    It doesn't cover all of your 3 cases, but have a look here: kali.org/how-to/emergency-self-destruction-luks-kali – faker Jan 6 '14 at 21:39

10 Answers 10

Active Oldest Votes
28

Idea #1 - Hidden OS

As an alternative method you could make use of TrueCrypt's "Hidden Operating System". This allows you to access a fake alternative OS when a certain password is used, rather than the primary OS.

excerpt

If your system partition or system drive is encrypted using TrueCrypt, you need to enter your pre-boot authentication password in the TrueCrypt Boot Loader screen after you turn on or restart your computer. It may happen that you are forced by somebody to decrypt the operating system or to reveal the pre-boot authentication password. There are many situations where you cannot refuse to do so (for example, due to extortion). TrueCrypt allows you to create a hidden operating system whose existence should be impossible to prove (provided that certain guidelines are followed — see below). Thus, you will not have to decrypt or reveal the password for the hidden operating system.

Bruce Schneier covers the efficacy of using these (Deniable File Systems, so you might want to investigate it further before diving in.

The whole idea of Deniable Encryption is a bit of a can of worms, so caution around using it in certain situations needs to be well thought out ahead of time.

Idea #2 - Add a script to /etc/passwd

You can insert alternative scripts to a user's entry in the /etc/passwd file.

Example

# /etc/passwd
tla:TcHypr3FOlhAg:237:20:Ted L. Abel:/u/tla:/usr/local/etc/sdshell

You could setup a user's account so that it runs a script such as /usr/local/etc/sdshell which will check to see what password was provided. If it's the magical password that triggers the wipe, it could begin this process (backgrounded even) and either drop to a shell or do something else.

If the password provided is not this magical password, then continue on running a normal shell, /bin/bash, for example.

Source: 19.6.1 Integrating One-Time Passwords with Unix

| improve this answer | |
  • 2
    Idea #2 will not work. The shell will only be called once the correct password has been entered (as configured in /etc/shadow). Even if it would work, there would be no way for the script to check which password was entered at login time. – faker Jan 4 '14 at 17:13
  • @faker - this method is right out of the one-time passwords in unix, so I believe it will work. It may not integrate with the system's /etc/shadow password, directly, but is workable. – slm♦ Jan 4 '14 at 17:18
  • @slm from the page you linked to: This puts two passwords on the account: the traditional account password followed by the one-time password. You can of course in the script check for a destruction password, but only after you entered the correct account password. Essentially you then have 3 passwords. Common account password, correct 2nd step password and self destruct 2nd step password. Not very nice and pretty suspicious... – faker Jan 4 '14 at 18:06
  • @faker: slm is right -- I wouldn't be following the link step by step, but it would work. It would still just link to a different shell or script. I see no reason why it is incorrect. – Josh Jan 4 '14 at 19:56
  • @Josh it works if you consider having to remember 3 passwords to be OK. Otherwise it does not work. – faker Jan 4 '14 at 22:32
16

My approach for this would be to trigger the self destruct in a pam module. There are mechanisms to catch the password with a script, check if it's the "special" one and start the self destruct process.

Write a line in your /etc/pam.d/common-auth as first line like this:

auth    optional        pam_exec.so debug expose_authtok /etc/security/suicide.sh

(or for example in /etc/pam.d/gdm if you just want it to work with authentication via gdm) expose_authtok causes the pam_exec.so module to deliver the password via stdin to the login script called /etc/security/suicide.sh. This script would be run with root priviledges and would for example look like this:

#!/bin/bash
# read the users password from stdin (pam_exec.so gives the provided password 
# if invoked with expose_authtok)
read password

# if its an authentication and it's the user "user" and the special password
if [ "$PAM_TYPE" == "auth" ] && [ "$PAM_USER" == "user" ] && [ "$password" == "magic" ]; then
  # do whatever you want in the background and the authentication could continue
  # normally as though nothing had happened
  exit 0
else
  exit 0
fi

It would work even if you change the password of the "normal" user.

| improve this answer | |
9

Just so you know if anyone from the gov etc does grab your computer the first thing they will do is copy the drive bit for bit and work off the copy. Same thing is done anytime someone does computer forensics so if you damage while analyzing a drive you only damage the copy.

So lets say the big bad NSA takes your computer and puts your thumbs in a vice to get you to tell them the password. When you give them the wrong password then it will just del to copy and not the original. Now they know your messing with them.

So any use of a kill pass word would only be effective if you ran it before anyone got a hold of your system. So all it would do is give you a complicated way of executing something you could alias.

| improve this answer | |
6

If you really want to destroy your data. You first have to make sure that no one makes a copy of your data (i.e. the whole disk) in the beginning. But this is not possible on OS level.

The only way to make sure your data will not fall into wrong hands is use cryptography. Especially Deniable encryption would be the right thing in your case: If you type the correct password, your personal data shows up. If you type the other password some innocuous data shows up.

| improve this answer | |
  • I am most worried for the scenario someone forces me to enter a password, or grabs the computer once I enter a password. – Josh Jan 3 '14 at 22:28
  • 3
    If someone forces you to enter a password you just enter the "other" password, which unlocks the innocuous data. - Therefore you can plausible deny the existence of the real data. - If I am serious about getting your data, I will not let you touch your computer, but first make a copy of everything. – michas Jan 3 '14 at 23:53
6

If you really want to be able to destroy your data, to protect it from the NSA, you need something with explosives, and fire that will melt the metal in the disk platters, and you need to be able to trigger it remotely.

I suspect this is not practical.

| improve this answer | |
0

Well, you could have a script to trash your primary user's /home directory (as well as /var , /tmp and everyplace else you have eyes-only data) if you log in with a different username... the script would start at login and then automagically load something which deceives the onlooker by doing something putatively useful. If it trashes your system without deceiving the onlooker, they just might pull the plug and thereby prevent your best laid plan from working. That also allows you a login while this is underway... although I would put the TRASHME user on a different drive for the drive being trashed will be rather busy and therefore pokey.

| improve this answer | |
  • 1
    Not within the stated constraints. – Josh Jan 3 '14 at 22:28
0

A secure hard drive, or flash drive for that matter, is an oxymoron. The only way to secure your information is to use a virtual operating system that runs in memory and evaporates when you turn the power off, with any data that needs to be saved on external media that you can hide if you desire. There are a number of "Live" Linux distributions out there that enable you to do just that. With relatively little effort, you can remaster the CD or DVD and customize it to best suit your needs. Also, be aware that much of your behavioral information is being relayed by your browser, and for any searches that you believe are compromising, you should be using a secure browser such as Tor.

| improve this answer | |
  • Not my request. I am perfectly aware perfect security is impractical. I am not asking for a perfect solution. – Josh Jan 4 '14 at 23:16
0

If you want to keep things secure, understand that there is no such thing as perfect security and that security is no more than a trade off of acceptibles after accurate risk assessment has taken place.

For a start, why destroy anything. First look at decreasing ease of access. Create an air-gap. Buy a bcheaap box for on-line stuff and anything you want to send from your main box transport there by way of sneakernet. Use good encryption, like Scrypt. Truecrypt and others have had their venerable day.

There are many other strategies you can employ, with not enough space to go into them here, and frankly I don't have enough time to go into them. I think you have discovered a whole new learning path.

| improve this answer | |
  • Not within stated context. – Josh Jan 8 '14 at 7:22
0

As was pointed out to me, and featured on Phoronix, Kali Linux created a method of doing this as well. Looking at some of the code, there is a weakness that will still allow the patch to be defeated, but it goes a long long way to allowing an effective self destruct password. As a note, the weakness is a hardware particularity related to zeroing out data -- manufacturer tools can recover zeroed data, and overwriting key locations on a media should be done with a random number generator several times to ensure data scrambling.

Link here: http://www.kali.org/how-to/emergency-self-destruction-luks-kali/

| improve this answer | |
0

Yes, you have to destroy the surface of the drive. A thermite grenade is recommended (that is what they taught us) You can make your own with a fire starter (magnesium block) and an ignition source... the goal is to create a class D fire.... impossible to put out.

| improve this answer | |
  • I don't think OP was talking about physical destruction... – don_crissti Nov 6 '15 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.