On Sat, Aug 14, 2004 at 03:36:48PM +0200, Philipp Marek wrote: > I'd like to share some ideas about various ways to implement a tamper-proof > filesystem for linux. Do you mean a trip-wire-like protection of the file system, or are you concerned with media failure only? > I hope to get some opinions whether the statements in this mail are valid or > indeed sane :-). That's what humanity is about. > ###### > > As far as I can see, there are some ways to protect the data in a filesystem > against modifications from outside. > > Common to them is that some verification data (below written as vd) has to be > stored. > That could be the IV after block-encryption, a HMAC for unencrypted devices, > or even a error-correction code for use on buggy media (eg. floppy) (which > would allow on-the-fly error-correction). > > > The main problem to solve is that the vd must match the data. If this isn't > true the block should be rejected, and an operator probably has to be > alerted. (This is what I mean with atomicity - vd and data must match) For protection against malicios data modification, the tricky part is also to integrate every vd record (or group of vd blocks) with all other encrypted data (a modification of a vd needs to lead to a major, detectable modification of all encrypted data, or at least a specificly designed sensitive part of it). Otherwise, a commonly known problem is that someone who was able to obtain an earlier copy of the encrypted data can extract a block (or a group of blocks that share the same vd / vd's group) from the earlier copy can substitute it in the new version of the encrypted volume, thus modifying a part of the encrypted data without being detected. > I) defining a new filesystem > ---------------------------- > > > Ia) storing the vd in every data block Vulnerable as described above. Already discussed a little on this list. > II) protecting the block-device-layer, storing the vd outside the data blocks > ----------------------------------------------------------------------------- > > These things could be done as a part of device-mapper. > > > IIa) The simple way with header blocks > > For a logical block size of LB (eg. 4KB) and a vd size of VD (eg. 16B) we can > store N=LB/VD (eg. 256) vds in a logical block (the vd-lb). > So we can precede N data blocks with one lb to store the vd. > (Or perhaps N-1, and store the vd of the vd-lb there.) As mentioned earlier on the list, grouping vd's and keeping a vd of vd's is one solution of the problem mentioned above. Good luck and watch out (By the way are people here interested in TEMPEST, e.g. <http://bss.sfsu.edu/fischer/IR%20360/Readings/tempest.htm>?), -- Pav http://en.wikipedia.org/w/wiki.phtml?title=Frankfurt_School&oldid=4862683 ,., http://www.larouchepub.com/eirtoc/2004/eirtoc_3125.html ,``:'', http://www.bilderberg.org/ccf.htm {o ! o} http://en.wikipedia.org/wiki/Fabian_Society ] -+- [ http://bss.sfsu.edu/fischer/IR%20360/Readings/Readings.htm \ ! / http://www.againsttcpa.com/ http://swpat.ffii.org/ My type: Dvorak. `-'http://en.wikipedia.org/wiki/List_of_U.S._foreign_interventions_since_1945 `shell$ gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 164C028F` - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
