[ad]<\/p>\n
<\/p>\n
This article describes and partly implements a method to delete<\/em> or re-locate<\/em>, potentially sensitive and \/ or incriminating information from your UNIX flavoured machine, after the sad event of your death.<\/p>\n An older version of this article has<\/em> been published before, yet it has since disappeared from the Internet and the Google cache; hence this re-post.<\/p>\n Initially, the intent of the whole idea of Post-Mortem Data Destruction<\/em> (PMDD), or Post-Life<\/em> Data Destruction, was humorous. Thus, this document should be taken lightly. <\/p>\n Incidentally it can<\/em> be of use to interested people as this article does contain some useful tips \/ pointers if one decides to build such a system. For some of you that lack common sense: any damage you might cause to your machine after reading this document is entirely your own fault.<\/p>\n Note that this article, obviously, assumes that the machine that the data is on, is under your own control. We will continue to look at various motivations<\/em> for PMDD, below. Note that this whole theory does not<\/strong> apply when you are using remote storage systems (i.e. virtual drives) as the information is then stored on a remote location<\/em> and we cannot be sure that the remote system really<\/em> deletes your data. Their EULA might state that they do but the truly paranoid wouldn’t make the assumption that they really<\/em> delete it. I sincerely wonder why<\/em> one would actually ever use such a remote virtual drive — by definition these are un-trusted<\/em>. But I slightly digress..<\/p>\n You can have various motivations for wanting your data destroyed<\/em> after your death:<\/p>\n Motivations for moving<\/em>, i.e. sending out<\/em> certain data upon the event of your death could be:<\/p>\n After you have died, it’s too late: it will be virtually impossible to log in<\/em> to your machine and delete data<\/em>. Note that haunting<\/em> is only reserved to a few (hurt) souls and such a state can not be guaranteed. Fat chance you’re able to sit behind a terminal in the after-life, too. <\/p>\n One could opt for encryption, making it hard<\/em> for a person to recover the data — but that doesn’t really guarantee anything. In the event of your death, the partitions would be available to anyone that can get their hands on it. If the encrypted partitions are gone<\/em>, they can never…<\/p>\n Let us continue by making a technical analysis<\/em> of the problem at hand. <\/p>\n <\/p>\n You are probably aware of the way that watchdog-chips work; basically they change a byte somewhere in memory regularly, and if that byte hasn’t changed within a set period of time, the machine is possible hanging and needs a reboot.<\/p>\n We can use a similar method to check whether you are still alive: a machine regularly sends you a message (either through email, an SMS or through a carrier pigeon, whichever you prefer) and expects an answer back. <\/p>\n If the machine hasn’t received an answer within a configurable time-lapse, the machine can safely assume that you have died. <\/p>\n This obviously isn’t rocket-science — implementing such a system is pretty straight-forward.<\/p>\n Setting it up is a whole other can of worms: you have to be careful as wrong settings might<\/em> result in a false-positive. A false-positive might render your machine useless when you come back from your holiday to the Antarctic, where GSM and Internet coverage isn’t really that impressive.<\/p>\n In order for such a ‘system’ to be built, we can divide it up into three, logical, parts:<\/p>\n The Checker<\/em> is the core of the system that makes the actual assumption whether you are still alive (or not) and will initiate the data destruction process<\/em>.<\/li>\n<\/ul>\n Below, we will look at each of these three parts with a little more detail.<\/p>\n This part must implement the sending of the message. Messages can be sent over numerous transport-media, i.e. email or SMS, so you have to pick the one you prefer. You could also choose sending the AYA-message over more transport-media to be sure that you will receive and answer it in time.<\/p>\n (UNIX users could use ‘crontab’ here to send it out, for instance every day at 21:00 PM. Some checkups need to be built-in though to prevent AYA messages from being sent when the last one hasn’t been responded too, etc. But those are implementation details I will go into later on.)<\/p>\n This part must handle the incoming IAA-message. The location of the Receiver is dependant on the form of transport you have chosen; If you want the AYA-messages to be sent over email, the IAA-message will come in via email.<\/p>\n (UNIX users could use ‘procmail’ here in order to inspect the incoming message, and act upon it.)<\/p>\n This part checks regularly whether a AYA message has been sent, and if an IAA message has been received.<\/p>\n If the IAA isn’t received within a reasonable (configurable) amount of time the machine must assume you have died and optionally start emailing some data out before finally destroying it. We will go into the ‘Destruction Process’ later on.<\/p>\n UNIX users could write a simple script for this that retrieves and manipulates the state-information somewhere on the file-system.<\/p>\n All the above mentioned parts should have some redundancy built in and should properly react in error situations. It would be a pain to find out that a message could not be sent because of your ISP being down. In that situation you have never received, thus replied, the AYA message, and your machine will think you are dead… <\/p>\n If you don’t watch out, your data will be deleted and you might as well kill yourself.<\/p>\n Below I will go into various things that you need to keep in mind when implementing a Death Detection system.<\/p>\n The Sender<\/em>, the Receiver<\/em> and the Checker<\/em> all need to be fully aware of eachother: the Sender needs to know if a previous AYA has been answered. We do not want AYA’s sent out when the previous AYA hasn’t been answered yet as doing so might cause a flood of AYA’s that you have to answer to in time, to prevent your machine from destroying itself.<\/p>\n2. Motivation<\/h3>\n
\n
\n
3. Technical Description<\/h3>\n
\n
3.1 Sender<\/h4>\n
3.2 Receiver<\/h4>\n
3.3 Checker<\/h4>\n
4. Death Detection Caveats<\/h3>\n
4.1 State-Information<\/h4>\n