sanitizing disks: wiping swap, non-allocated space, and file-tails
to avoid leakage of sensitive information: any advice? X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to http://www.habeas.com/report/. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jul 2004 05:22:53 +0100 From: David Kreil [EMAIL PROTECTED] Hi, (1) I was wondering whether anyone knew of packages/tools to aid in sanitizing a FreeBSD system, i.e., wiping + the swap slice + non-allocated space on volumes + file-tails (the part of the last allocated block of files not used) with random patterns to avoid leakage of sensitive information (plain text keys or decrypted texts). I am aware of the security limitations of any approach that does not involve dissolving the entire disk in acid etc but would be grateful for a pointer to a tool that at least + generates reasonably random data for its writes + ideally does a reasonable effort of turning off caching whereever it could (ideally in the file system, the disk driver, and the disk itself) or alternatively at least did the overwrites in such an order that the effect of caching would be minimized. If there are no tools, would you know whether I can get FreeBSD on shutdown to stop using swap and access it as a raw disk device that I can write to, and how to hook into the shutdown process? (2) Related to this: I'm also interested in people's personal experiences in using partition or file system encryption options. For performance reasons I'd rather avoid having /tmp and swap and certain work space on an encrypted disk, hence the need for (1). If you feel that I'm asking this all in the wrong place, please let me know. With many thanks for your help, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sanitizing disks: wiping swap, non-allocated space, and file-tails
Dear cpghost, Thanks for your fast and helpful comment. The Handbook describes a basic gdbe setup but mentions that getting other volumes (like /home) onto a gdbe partition was trickier. Can you tell me which volumes you have on gdbe and what was required to get this working? I wonder, in particular, how system directories like /var would be kept on a gdbe partition. With many thanks again for your help and best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sanitizing disks: wiping swap, non-allocated space, and file-tails
Dear Jan, Thank you very much for your comments! I wonder, in particular, how system directories like /var would be kept on a gdbe partition. Much like any other, but the major issue is that, unlike /tmp/ and swap (which can be wiped clean when a machine boots with no ill effects), other partitions need to persist. That means you need to do one of two things: 1. Be available when the machine boots to enter the keys to mount the persistent partitions; or That's fine, that's what I consider a secure solution. 2. Store those keys somewhere so the machine can do it for you. If you choose (2) then you might as well not use an encrypted partition; Yes :-) So at what stage of boot-up and how do I make the volumes available, prompting for the necessary passphrase? Does not the boot process write into /var/log/* from the very beginning? With many thanks again for your help and best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to recover/reinitialize a trashed /var partition?
Hello, I am writing in the hope that someone can give me a hint of how to either recover or recreate a virgin FreeBSD /var partition in an otherwise (apparently) functioning system. Probably in the process of a drive failure in our hardware raid our /var volume got corrupted (yeah, I know this should not happen... sigh. I now also understand why it is recommended having /var on a separate partition...). I tried running fsck -y on /var after umount-ing it, which gives a segmentation fault (exit on signal 11) some way through the process after displaying ** Phase 2 - Check Pathnames ROOT INODE UNALLOCATED UNEXPECTED SOFT UPDATE INCONSISTENCY ALLOCATE? yes CG 0: BAD MAGIC FILE NUMBER UNEXPECTED SOFT UPDATE INCONSISTENCY Now I wonder - is this beyond repair? I should much like to recover /var, just to be able to have a look at the /var/logs to get an idea what went wrong when. About 3.6GB are reported to be in use by df. - If I cannot recover the /var partition, what is the canonical way of recreating it? I suppose I can run newfs on it, but how do I create the necessary subdir structure with the right file-permissions? Could /stand/sysinstall do that? With many thanks for your help in advance, Yours sincerely, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to recover/reinitialize a trashed /var partition?
Dear Brooks, Thank you very much for your fast and helpful reply. # populate /var /usr/sbin/mtree -deU -f /etc/mtree/BSD.var.dist -p /var # add sendmail bits /usr/sbin/mtree -deU -f /etc/mtree/BSD.sendmail.dist -p / # create new syslog files /usr/sbin/newsyslog -CC # add a lastlog file /usr/bin/touch /var/log/lastlog I cribbed this from /etc/rc.d/var on current. This is fantastic, thanks! With best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to recover/reinitialize a trashed /var partition?
Dear Brandon D Valentine, Thank you for your helpful comments. You may have to touch/chown/chmod a few files here and there to make sure the appropriate users have permissions to write to/from them. See /usr/src/etc/Makefile for some more information on that. Unfortunately I don't think there is a 'var' target in any of those Makefiles. Thanks for the pointer. Yes, shame there is no such target. Considering that folks generally advise putting /var on a separate partition, my kind of bad luck must be quite common. With best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde blackening feature - how are the keys destroyed?
Hello, I was wondering whether someone knowledgable about gbde internals could tell me how the keys are being destroyed on request under the blackening feature. Ideally, I'd like them to be overwritten with random data at least 20 times independently, but I suspect it may well be done in a different way. I'd be grateful for learning how the blackening works (and why!). With many thanks for your help in advance, David Kreil. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?
Hi, From what I can see so far, they are simply overwritten with zeros - is that right? If so, the blackening feature would be much weakend, as once can read up to 20 layers of data even under random data (and more under zeros). I would be most grateful for comments, or suggestions of where/how one could extend the code to do a secure wip of the key areas. Also, I know practically nothing of how I could to best get FreeBSD to physically write to disk (configurability of hardware cache etc permitting). With best regards, David. Hello, I was wondering whether someone knowledgable about gbde internals could tell me how the keys are being destroyed on request under the blackening feature. Ideally, I'd like them to be overwritten with random data at least 20 times independently, but I suspect it may well be done in a different way. I'd be grateful for learning how the blackening works (and why!). With many thanks for your help in advance, David Kreil. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde blackening feature - how can on-disk keys be destroyed thoroughly?
Dear LenZ, Who are you worried about recovering the data, under what circumstances? The value of the blackening feature should be that you can give away the drive and your password, say, under pressure by the [court|mafia|whoever], without compromising any confidential information on the drive. My best guess is that recovering anything from even _one_ data over-write is going to require that the recoverer have physical posession of the drive and very sophisticated equipment indeed. That means they have to be some branch of a govermnment. Hmm, I much doubt that. True, you need a clean room and a magnetic force microscope. Even standard data recovery firms like www.dataclinic.co.uk, however, can recover data under up to 8 overwrites. (NB: No affiliation or recommendation there.) Government agencies can go deeper (20x or possibly more but it gets increasingly more difficult). If you are going to attract attention of that caliber there are likely a lot of other easier means of finding out what you are up to. Sure, like pointing an antenna at my computer while its running ;-) I guess my main point is: If there is a blackening feature which is designed to give users peace of mind about disclosing their password under pressure, and it is known that data can be recovered underneath simple overwrites for a pack of $$ but that writing a random pattern, say 30x, makes the delete safe, I'd much argue in favour of doing the latter. As the areas are small, this should be really quick, too. The problem is getting the multiple overwrites out to the magnetic media, rather than them sitting somewhere in a cache buffer in computer or drive memory. Otherwise, a good hot fire ought to be pretty final even for the CIA. Actually, the above firm specializes in Track 0 damage, fire damage, flood damage, impact damage and overwritten data... So, if a commercial enterprise can offer this, I don't think I'm unduly concerned. Depending on the country, dissolving the magnetic layer in acid or finely grinding it off are considered final for classified materials. Now, I'm not interested in an exercise of extreme paranoia. If overwritten keys can, however, easily be recovered then I'd consider this a relative weakness compared to all the sophisticated effort that has gone into the design of gbde and its encryption algorithms. My question hence remains, can someone more knowledgable than me maybe comment on whether I have misunderstood what gbde does, or else how the strength of the blackening could please be improved (i.e., how to do a 30x random wipe bypassing cache in a hardware independent manner)? With best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?
Dear Poul-Henning, Thank you very much for your comments! From what I can see so far, they are simply overwritten with zeros - is that right? If so, the blackening feature would be much weakend, as one can read up to 20 layers of data even under random data (and more under zeros). I would be most grateful for comments, or suggestions of where/how one could extend the code to do a secure wipe of the key areas. Also, I know practically nothing of how I could to best get FreeBSD to physically write to disk (configurability of hardware cache etc permitting). On a modern disk there is no sequence of writes that will guarantee you that your data is iretriveable lost. Even if you rewrite a thousand times, you cannot guard yourself against the sector being replaced by a bad block spare after the first write. Good point. In the rare chance event that this happens, it would indeed be bad news as an attacker would then only have to scan the bad blocks for possible copies of the key. If your threat-analysis indicates this is a serious threat for you, you should arrange for simple physical destruction of your disk to be available. Most modern disks have one or more holes in the metal only covered by a metalic sticker. Pouring sulfuric acid through those openings is a good start. Hmm... to me, the main benefit of the blackening feature would seem to be the possibility of compliance with a court directive without disclosing confidential data. With multiple key holders, any particular person can maintain that they have done all they could to comply. Not only is the optics of having your disks are found in vats of sulfuric acid rather bad, it's also more unlikely that a moment of opportunity arises. A simple improvement on the present situation would already be if the keys were not overwritten with zeros but with random bits. I don't know how difficult it would be to attempt to physically write random bits multiple times but it would much strengthen the feature apart from the rare cases when the sectors of the masterkey have been remapped into bad blocks. As rightly pointed out in the manpages, the better the encryption gets, the more likely are attacks via other routes. Reading a few layers of the current masterkey location + all bad blocks with an MFM should cost no more than a few thousand $. What do you think? Is the required effort disproportional to the intended value of the blackening feature? With many thanks again for your help and best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?
Dear Poul-Henning, On a modern disk there is no sequence of writes that will guarantee you that your data is iretriveable lost. Even if you rewrite a thousand times, you cannot guard yourself against the sector being replaced by a bad block spare after the first write. Good point. In the rare chance event that this happens, it would indeed be bad news as an attacker would then only have to scan the bad blocks for possible copies of the key. He still has no way of recognizing the key though... Right, he'd have to try them all. A simple improvement on the present situation would already be if the keys were not overwritten with zeros but with random bits. I don't know how difficult it would be to attempt to physically write random bits multiple times but it would much strengthen the feature apart from the rare cases when the sectors of the masterkey have been remapped into bad blocks. Please read the paper, there is a reason why it is zero bits. Sorry, forgot. What do you think? Is the required effort disproportional to the intended value of the blackening feature? Blackening adds no significant incremental security imo, From a security point of vie, yes. From a social/civil-liberties/legal point of view, I felt it was an excellent thing to have. on the other hand it is feasible to implement it, so I've put it on the todo list. That's great, thanks a lot! With best regards, David. Dr David Philip Kreil (`-''-/).___..--''`-._ Research Fellow`6_ 6 ) `-. ( ).`-.__.`) University of Cambridge(_Y_.)' ._ ) `._ `. ``-..-' ++44 1223 764107, fax 333992 _..`--'_..-_/ /--'_.' ,' www.inference.phy.cam.ac.uk/dpk20 (il),-'' (li),' ((!.-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
