Requirements The main requirement is to convince our security auditors that all the data on our systems is encrypted. The systems are moved between multiple trusted locations and the principle need is to ensure that, if lost or stolen while on the move, no data can be accessed. The systems are not required to operate except in a trusted location.
Storing the data on encrypted zfs filesystems seems like it should be sufficient for this. But the counter argument is that you cannot _guarentee_ that no data will be accidentally copied onto un-encrypted parts of the system, say as part of the print spooling of a data report (by the system) or by a user for some other reason. The auditors don't want to rely on processes being followed by people to ensure security (and I agree with them). They like a nice straight-forward story - "the whole system is encrypted". So, answering your question, I don't want the OS encrypted, I want all writable media encrypted. In terms of the two factors, I think I should: 1) need a physical thing (e.g. a usb stick with a particular file on it) and, 2) know a password/passphrase, in order to be able to boot the system. (The usb stick can be removed once authentication is completed.) Although the mobility of the usage sounds rather more "laptop" than "data centre", the systems are used for collecting and storing terabytes of data (at rates up to 10 Gb/s), so the scale quickly becomes more like data centre. And back to the earlier point, the data storage can be on zfs encrypted fs's, it's just a case of closing the last loophole. Additionally, some of the data reports generated can be quite small (easily fit on the system disk) and still require protection in the event of lost disks. In a lights out situation, presuming the trusted location, the usb stick could be left in the machine and passphrases supplied at boot time. It might also be possible to arrange a passphrase server with ssh/asymmetric encryption to supply the passphrase during boot, using the booting system's public key and including replay prevention. This approach might address the high availability (HA) scenario, but I'm afraid I don't have any experience of HA systems. I appreciate that this type of two factor booting will require some management overhead, usb sticks will need labels and tracking, and keys and passphrases will need storing/backing up. These will add cost but, "security costs". I hope this gives you a better idea of what I need. Regards, Rob PSs Writable media and the OS - Booting and operating from a read-only DVD and using memory backed caching for everything, sounds good in theory. However, this would be a total pain whenever you need to make a permanent change to a system setting, as you then need to burn another DVD and reboot the system. Unless you were going into mass production with 10s of identical systems, I don't think this would be a usable solution. Limiting authentication attempts - It might be a good thing to obliterate, after say 20 attempts, the on-system data which is used to release the key, forcing the need to access a backup of that data. I think this would slow down a good-guesses/dictionary style attack by a person at the keyboard but may not be effective against a determined attacker who makes images of the disk before starting... I'm sure you know more about this than I do. -----Original Message----- From: Darren J Moffat [mailto:darr...@opensolaris.org] Sent: 26 April 2011 09:47 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed On 24/04/2011 18:49, Rob O'Leary wrote: > Reading this reminded me that the feature I'm really waiting for is > two-factor boot time authentication from encrpyted zfs boot... Can you explain more about your requirements and use case ? Is this "laptop" or "data centre" ? or some thing else ? What "two factors" do you want ? How will this work in a lights out and/or high availability deployment ? Why do you want the operating system itself encrypted rather than just the data stored on the system ? ie What is threat you are trying to protect against ? > Is this likely to be seen in the near-ish future? I need to know more about what you mean before I can determine that. -- Darren J Moffat _______________________________________________ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
