RE: Booting from encrypted ZFS WAS: RE: How to mount encrypted filesystem at boot? Why no pass phraserequesed
Hi Michel, I had noticed these drives in the past, but your email reminded me and I followed your link, thanks. A bit of googling showed that not everyone is having a great experience and I couldn't find the barracuda fde promised in the press release. I also need SAS because of read while writing issues and these are momentus sata disks (despite link names below). Can I mix sas and sata in the same controller? Reliable, SAS, FDE does not seem to be available... Regards, Rob http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Issues-with-ST932032 2AS-FDE-3-drives/m-p/29247#M12876 http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Recovering-Formattin g-FDE-Drives/td-p/7412 -Original Message- From: michel.bell...@malaiwah.com [mailto:michel.bell...@malaiwah.com] Sent: 27 April 2011 12:08 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted filesystem at boot? Why no pass phraserequesed Hi, I think the best solution for your OS drives is to have a look at disks that offer built-in full disk encryption (FDE) just like the ones offered by Seagate (example: http://www.google.com/url?q=http://www.seagate.com/ww/v/index.jsp%3Flocale%3 Den-US%26name%3Ddn_sec_intro_fde%26vgnextoid%3D1831bb5f5ed93110VgnVCM10f 5ee0a0aRCRDsa=Uei=8_e3TfvVIInBtgemsdjeBAved=0CAgQFjAAusg=AFQjCNGt_c3Vokq 4D6hL8k25rfUcIrB2Bw). While it does not offer the flexibility of ZFS encrypted datasets, I think it would be appropriate in your situation. I would rely on that encryption for the OS with a static passphrase asked at boot-time, but still point sensitive informations to the ZFS pool for better management of the keys, if your auditor asks them to be rolled once in a while (for data, at least). My 2 cents, Michel Envoyé de mon terminal mobile BlackBerry par le biais du réseau de Rogers Sans-fil -Original Message- From: Rob O'Leary raole...@btinternet.com Sender: zfs-crypto-discuss-boun...@opensolaris.org Date: Wed, 27 Apr 2011 11:46:02 To: Troels Nørgaard Nielsentro...@norgaard.co 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 Hi Troels, There are two things here. First, I don't want to learn another set of administration tasks (I've just had a quick look at Trusted Extensions and am shuddering at the thought) and second, the problem isn't when the system is running but when it is stopped. I believe the problem is called data at rest. Also, notice the line where I said the auditors like a simple story. They really do. I still want to be able to print and use the network without incurring lots of admin, re-programming or performance overhead. (Our applications are very network heavy.) But, when I shutdown I want the data on the disks to be un-intelligible. In terms of management/learning overhead, we are very familiar with tracking and accounting for documents and keys, so having a few extra keys and usb sticks to look after is no problem. Unfortunately, I don't know enough about grub and zfs booting. So, I shall resist the temptation of can't it just Almost. I'm sure there's a way. Chain from authentication phase and getting key to main boot...? (Sorry, I had to.) Best regards, Rob -Original Message- From: Troels Nørgaard Nielsen [mailto:tro...@norgaard.co] Sent: 27 April 2011 11:13 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 Hi Rob, Wouldn't the use of Solaris Trusted Extensions by placing all 'secure' operations inside a label that can only write to the filesystem (that is encrypted) with the same label, do for you what the auditors are seeking? The base idea of Trusted Extensions is that no data can escape it's label (guarded by syscall checks), to ensure traffic to the label, one can use IPSec with labeling, etc. I think Darren is dragging along here, because implementing zfs-crypto on rpool requires grub to be aware of zfs-crypto, which is kinda hard (e.g. grub doesn't support multiple vdev or raidz-n yet). Best regards Troels Nørgaard Nørgaard Consultancy Den 27/04/2011 kl. 09.54 skrev Rob O'Leary: 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
Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed
Hi Rob, Wouldn't the use of Solaris Trusted Extensions by placing all 'secure' operations inside a label that can only write to the filesystem (that is encrypted) with the same label, do for you what the auditors are seeking? The base idea of Trusted Extensions is that no data can escape it's label (guarded by syscall checks), to ensure traffic to the label, one can use IPSec with labeling, etc. I think Darren is dragging along here, because implementing zfs-crypto on rpool requires grub to be aware of zfs-crypto, which is kinda hard (e.g. grub doesn't support multiple vdev or raidz-n yet). Best regards Troels Nørgaard Nørgaard Consultancy Den 27/04/2011 kl. 09.54 skrev Rob O'Leary: 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 ?
Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted file system at boot? Why no pass phraserequesed
If I understood correctly: - there is no requirement for the system to boot (or be bootable) outside of your secure locations. - you are willing to accept separate tracking and tagging of removable media, e.g. for key distribution. Consider, at least for purposes of learning from the comparison: - having the machines netboot only, and provide the netboot environment only within the secure locations. - having the system disks on the removable media that is handled separately, not just the keys. Both of these share the property that the physical chassis being transported contains only encrypted disks, leaving you to make other tradeoffs with respect to risks and handling of the bootstrapping data (including keys). My primary interest in encrypted zfs boot for the OS is more around the integrity of the boot media, for devices that may be exposed to tampering of various kinds. This is a complex issue that can only be partly addressed by ZFS, even with such additional features. Do these sorts of concerns apply to your environment? If someone was to intercept one of these machines in transit, and tamper with OS and system executables in such a way as to disclose information/keys or otherwise alter their operation when next booted in the secure environment, would that be a concern? -- Dan. pgprO3IdicpgH.pgp Description: PGP signature ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
