Mainly looking for a solution in a scenario where the data (that resides on a zfs) has to be wiped out by some trigger (remote/local). Zfs is the filesystem to be used - unfortunately I'm not sure it provides the capability to delete something securely on it due to its very nature.
ZFS at that point makes no difference. It will neither help nor hinder the data destruction, you have to do it at the layer below.
And that would be an encrypted disk, where data loss can be deliberately caused by forgetting or destroying the key. For FreeBSD, I think the best solution is geli, as Crivens said. The only problem is that you would need to audit everything that happens to the key: You must make sure it is not stored or cached anywhere, because otherwise the attacker could retrieve the key from any place it is stored. The other possible solution is to use hardware, namely a self-encrypting drive. Those are sold by all major drive vendors. The problem is that integrating key management into drives is awfully hard, and operating systems tend to get all knotted up when faced with such a disk.
Crivens - Forgetting the key is not an option since the data is valuable. Looking for plausible deniability angles.[/quote]
Well, forgetting or destroying the key is the industry standard solution to this problem. What do you mean by "forgetting is not an option"? What if they key is stored on a small security device, and then you trigger physical destruction of that device, is that an option?
For plausible deniability, it gets even harder. One option I've seen discussed is implementing a harmless-looking content which is available when the correct key is not present. This gets quite close to steganography: When used normally, the device (disk + file system + security software) returns the correct content; when used incorrectly (for example when a "panic flag" has been triggered), it hides the correct content, and instead returns sensible but harmless content. For example, the file system could pretend to contain complete copies of the FreeBSD manuals and install packages, or something like that. Implementing such a system would be hard.
Phishfry ,
ucomp - from what I understand - the first 2 passes are used to ensure that the bit is flipped - what makes the third pass neccesary, if we are to assume that the 3 pass technique works to securely wipe out the data ?[/quote]
With reconstructing bits from magnetic hard disks, it comes down to statistics. Every time the head writes a sector, it takes a slightly different path, and writes them in a slightly different place. That means that on the edge of the "correct" bits you can find some magnetic material that contains older copies. So what one does is to read the whole surface of the disk, using a magnetic microscope (which is where the STM comes in), find each track, and then search for older copies along the sides. The more times the data has been overwritten, the less likely it is that there is anything left on the side, because the effective width (the convex hull around it) grows with every write.