A Linux/BSD-based project called Rubberhose that seems to be dead now (website available at http://web.archive.org/web/20031214064240/http://www.rubberhose.org/) implemented a plausibly deniable crypto system where essentially each key entered unlocked part of the filesystem. Against a random background, it would be impossible to tell how much space is actually used. Of course writing is only a good idea after unlocking all filesystems. In the event of torture or subpoena, one could reveal only non-incriminating or low-sensitivity data and it would be impossible for either party to prove that all data had or hadn''t been revealed. The ZFS approach of numerous filesystems seems to lend itself to similar crypto, but I lack the knowledge of ZFS and experience with cryptography to know if such a system would be feasible. Encrypting ZPLs and ZVOLs independently doesn''t look too difficult because each is its own object set. However, it appears that decrypting the DSL would reveal the entire filesystem hierarchy, so chunks of the DSL would have to be independently encrypted. Is anyone on this list familiar enough with both ZFS and cryptography to know if what I described would be feasible? Deniability would make ZFS encryption much more useful than other implementations. This message posted from opensolaris.org
I will be posting some notes on ZFS & crypto to this list some time in January. This wasn''t one of the areas I was explicitly attempting to deal with but I''ll certainly have a think about it. I also hope to be able to post a very simple prototype of some of the ZFS crypto work by end of January. Some of the features that I want to implement for encrypting ZFS file systems depend on being able to delegate the administration of file systems to other users so we need a solution for that first. Before anyone asks the one area we have no intention of attempting to implement any time soon is encrypted root file system. -- Darren J Moffat
> This wasn''t one of the areas I was explicitly attempting to > deal with but I''ll certainly have a think about it.BestCrypt (for Windows and Linux), from jetico.com, implements a plausible-deniability crypto system using hidden containers with the OP''s desired characteristics, and might be worth a look.> Before anyone asks the one area we have no intention of attempting to > implement any time soon is encrypted root file system.Is this due solely to the programming effort which would be required, or are there other reasons? This message posted from opensolaris.org
On Mon, 2005-12-19 at 15:36, Andrew wrote:> > This wasn''t one of the areas I was explicitly attempting to > > deal with but I''ll certainly have a think about it. > BestCrypt (for Windows and Linux), from jetico.com, implements a plausible-deniability crypto system using hidden containers with the OP''s desired characteristics, and might be worth a look. > > > Before anyone asks the one area we have no intention of attempting to > > implement any time soon is encrypted root file system. > Is this due solely to the programming effort which would be required, or are there other reasons?It just isn''t part of the first phase. Primarily because we can''t boot from ZFS at all yet. Also because it is partly due to the way the Solaris crypto framework operates. It is also due the the requirement that we be able to support keys in hardware keystores - which require drivers to be loaded before they can be accessed (chicken and egg problem there). Think about it this way, once you can boot from ZFS your root filesystem can be really just be the OS and things like /var/tmp and home dirs etc etc can just be additional ZFS file systems which can be encrypted - swap could even be an encrypted zvol. I''m not saying never, I''m just saying it isn''t a goal for the initial delivery of this because it adds its own complexities and it isn''t a key requirement for the customers that have requested this. -- Darren J Moffat
I think the best way to avoid the chicken and egg problem you describe is by booting from a read-only medium like a CD-ROM (it could be rw but ro would be more secure). OpenSolaris and derivative distros could ship with a boot menu option that loads the kernel, allows the user to select the root parition and slice, prompts for a password to decrypt and load the key which ideally is stored on some other medium (or the key could just be the hash of a password), then transfers control to the new root (I don''t know enough about Solaris yet to say how this would be done). I would think something like this could be done even without ZFS boot support. This message posted from opensolaris.org
On Mon, 2005-12-19 at 17:34, Jake Maciejewski wrote:> I think the best way to avoid the chicken and egg problem you describe is by booting from a read-only medium like a CD-ROM (it could be rw but ro would be more secure). OpenSolaris and derivative distros could ship with a boot menu option that loads the kernel, allows the user to select the root parition and slice, prompts for a password to decrypt and load the key which ideally is stored on some other medium (or the key could just be the hash of a password), then transfers control to the new root (I don''t know enough about Solaris yet to say how this would be done). I would think something like this could be done even without ZFS boot support.and what do you do on hardware that as no CD ? While you suggestion is okay for laptop or home systems it doesn''t scale into the data centre very well - asking for passwords on reboot goes against the A in RAS. As for the key being just the hash of the password thats a really bad idea, you really need to use something like PKCS#5 if you want to have a key derived from something the user types in frequently (ie has to remember). One of the key things for the data centre, and for some laptop/desktop deployment as well, is keys in an HSM. Thanks for thinking about this but I''m afraid while your suggestion may well work it isn''t the architecture we are looking for. It is exactly because root file system encryption is a hard boot strap problem that it is not in the first phase of ZFS crypto, because most of the problems have little to do with the changes to ZFS and more to do with key management. -- Darren J Moffat
Jake Maciejewski
2005-Dec-21 19:55 UTC
[zfs-discuss] Re: Re: Re: rubber hose crypto with ZFS?
I don''t blame you for making an encrypted root a low priority. The original purpose of this thread was to request that deniability be considered in the design of ZFS crypto, and I still think it would be a killer feature over other encrypted filesystem methods and more worthy of developer time than encrypted root. When the topic of an encyrypted root came up, I was merely suggesting the only paractical way I can think of making such a system work. It may not work for servers, but it would be convenient for less security conscious desktop/laptop/workstation users. Consider why root encryption is useful in the first place, what problem is being solved. If the issue were protecting private data, then the data is almost certainly not critical to booting the system and doesn''t really need to be on the root filesystem. I think the problem is protecting the system from various physical access attacks. If the whole system is encrypted, the attacker can''t boot from another medium or pop the hard drive into a different system and install a rootkit. An alternative would be something like tripwire installed on an encrypted filesystem to protect it from physical access, but setting something like that up could be difficult for the less security conscious desktop/laptop/workstation users I mentioned in the previous paragraph. This message posted from opensolaris.org
> Consider why root encryption is useful in the first place, what problem is being solved.Another problem which it can solve, besides those which you mention below, is concealing identification of which operating system is installed on the disk (encryption support could be added to Grub) in the event that an adversary gains physical access to the disk. While coarse knowledge of this (e.g. Solaris vs. Linux) would not be very useful, being able to read the root filesystem gives knowledge not just of the brand and model of operating system installed, but also the exact versions of all components--which in turn, matched against a public database of security vulnerabilities, gives knowledge of which network-level attacks would be successful against the system after the disk is reinstalled into its host and the host is operational on the network again. And while such knowledge would be pointless in the case of an ordinary filesystem, since an attacker with physical access to the disk could simply directly install a rootkit anyway, in the case of ZFS, gaining such knowledge could actually provide the most practical route for attack, since ZFS''s builtin tripwire-style security (see below) protects against installation of a rootkit.> I think the problem is protecting the system from various physical access attacks. If the whole system is encrypted, the attacker can''t boot from another medium or pop the hard drive into a different system and install a rootkit.This isn''t a secrecy problem, but an authentication problem. Encryption solves the problem by ensuring that modifications without knowledge of the key would produce gibberish on the disk, thus preventing installation of a rootkit. But in ZFS''s case, encryption isn''t necessary to achieve this, since ZFS already has tripwire-style security built in by virtue of its storage of the filesystem as one giant hash tree; all you have to do is keep a copy of the uberblock checksum (which is even easier, from a security management point of view, than keeping a copy of a key would be, since maintaining secrecy of the checksum is not necessary), and voila, your entire filesystem (i.e. ZFS pool) is secure--physical access to the disk would provide only read access, so installation of a rootkit would be impossible. See http://blogs.sun.com/roller/page/bonwick?entry=zfs_end_to_end_data for details. This message posted from opensolaris.org
Jake Maciejewski
2005-Dec-22 04:33 UTC
[zfs-discuss] Re: Re: Re: rubber hose crypto with ZFS?
> (encryption support could be added to Grub)What about SPARC? I thought GRUB for Solaris was an x86/amd64-only thing. Also, we''d have the same problem again, this time with GRUB not being able to be encrypted, in which case it could be hacked to steal the key.> coarse knowledge of this (e.g. Solaris vs. Linux) would not be very useful, being able to > read the root filesystem gives knowledge not just of the brand and model of operating > system installed, but also the exact versions of all components--which in turn, matched > against a public database of security vulnerabilities, gives knowledge of which > network-level attacks would be successful against the system after the disk is > reinstalled into its host and the host is operational on the network again.I think passively monitoring the network connection is enough to gain the course knowledge you describe. Actively probing with something like Nessus will find many of the remote vulnerabilites. The scan might get picked up in logs (I''m not sure about the default logging policies in Solaris), but you''d avoid the problem of downtime for examination which should also raise suspicion. Overall, though, encrypted root probably wins out in the security through obscurity department.> all you have to do is keep a copy of the uberblock checksum (which is even easier, from > a security management point of view, than keeping a copy of a key would be, since > maintaining secrecy of the checksum is not necessary), and voila, your entire > filesystem (i.e. ZFS pool) is secure--physical access to the disk would provide only read > access, so installation of a rootkit would be impossible.The uberblock checksum isn''t good enough. From time to time you''ll want to be able to write to the root filesystem, so I''d assume you''d want to know how the filesystem has changed in addition to whether or not it changed. Are these checksums accessible from userspace? This message posted from opensolaris.org
> What about SPARC? I thought GRUB for Solaris was an x86/amd64-only thing.I don''t know anything about sparc. My comments about grub would apply as well to solaris-sparc''s bootloader.> Also, we''d have the same problem again, this time with GRUB not being able to be encrypted, in which case it could be hacked to steal the key.Key management is a separate issue, independent of whether your root filesystem is encrypted. Even if you have an unencrypted root, if you have any encrypted filesystems or any other encrypted data on your computer, you have to manage the key(s) somehow. Never store your key together with your encrypted data (unless of course the key is encrypted, in which case you have a different key which you must not store along with your encrypted data, but either way, you have a key which you must deal with). Encrypting the root does not introduce any new issue here. Anyway, one simple key management solution that''s appropriate in some cases (but not all, as Darren pointed out earlier in this thread) is to use a hashed password as a key. A 22-character case-sensitive alphanumeric string suffices for a 128-bit key. I use a hashed password for the encrypted filesystem on my personal machine; I enter the (long) password once at system startup, and then rely on the OS-operated console-locking feature (with a short password) to secure the system while it''s operating.> I think passively monitoring the network connection is enough to gain the course knowledge you describe.If the operating system reveals the information (by explicit self-identification, or by network stack behavioral or timing idiosyncrasies), then yes, that''s true. But if the goal is concealment, then the existence of a particular avenue of reconnaissance is a reason to close that avenue, not an excuse to leave other avenues open as well.> The uberblock checksum isn''t good enough. From time to time you''ll want to be able to write to the root filesystem,The uberblock checksum is still good enough in this case. You simply have to get a new copy of the checksum after you write to the root.> so I''d assume you''d want to know how the filesystem has changed in addition to whether or not it changed.Version control is a separate issue. But ZFS does provide this feature; before writing to the root, simply take a snapshot. And the uberblock checksum secures all the snapshots as well.> Are these checksums accessible from userspace?I don''t think there''s currently a command line tool to access it, but it would be easy to add such a tool. zpool list ought to include the uberblock checksum as one of the output fields. Also, zfs list -o checksum foo currently just shows whether checksumming is enabled for the individual filesystem foo, but it ought to show also the current checksum itself (and in fact it should show the checksum even for an individual directory or file foo, since the entire hash tree already exists and is readily available). This message posted from opensolaris.org
On Wed, 2005-12-21 at 18:23 -0800, Andrew wrote:> Encryption solves the problem by ensuring that modifications without > knowledge of the key would produce gibberish on the disk.No! This is a common assumption, but it''s wrong in general in the presence of partially-known plaintext, and is especially wrong for stream ciphers (including RC4 as well as block ciphers in counter or OFB mode). Even CBC mode allows for a modest amount of plaintext tweaking immediately after a garbled block, and resynchronizes very quickly. The original Kerberos v4 PCBC mode was designed to propagate garbles to the end of the stream, but resynchronizes if you swap ciphertext blocks. Moreover, while humans will usually detect gibberish, in the absence of specific integrity checks, computer programs are very likely to just plow on through a garbled section, especially if the garble is short. - Bill
> No! This is a common assumption, but it''s wrong in general in the > presence of partially-known plaintext, and is especially wrong for > stream ciphers (including RC4 as well as block ciphers in counter or OFB > mode). Even CBC mode allows for a modest amount of plaintext tweaking > immediately after a garbled block, and resynchronizes very quickly.I stand corrected. For other readers of this thread, http://crypto-systems.com/modes.html explains what Bill''s talking about. The remainder of my message was correct, including my conclusions that with ZFS the best way to protect against offline installation of rootkits is to retain an independent copy of the uberblock checksum in order to authenticate the pool, and that root filesystem encryption has a valid role in concealing the identity of the operating system. This message posted from opensolaris.org
> The original purpose of this thread was to request that deniability be considered in the design of ZFS crypto, and I still think it would be a killer feature over other encrypted filesystem methodsDetails about how Jetico''s Bestcrypt, which I recommended earlier (and which I use), implements the deniability features which you''re looking for are available at http://www.jetico.com/linux/bcrypt-help/c_hiddn.htm This message posted from opensolaris.org
On Thu, Dec 22, 2005 at 10:53:27AM -0500, Bill Sommerfeld wrote:> On Wed, 2005-12-21 at 18:23 -0800, Andrew wrote: > > Encryption solves the problem by ensuring that modifications without > > knowledge of the key would produce gibberish on the disk. > > No! This is a common assumption, but it''s wrong in general in the > presence of partially-known plaintext, and is especially wrong for > stream ciphers (including RC4 as well as block ciphers in counter or OFB > mode). Even CBC mode allows for a modest amount of plaintext tweaking > immediately after a garbled block, and resynchronizes very quickly.Uh, wouldn''t the checksums detect, with extremely high probablility, any such tampering? Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
On Thu, 2005-12-22 at 18:54, Jonathan Adams wrote:> On Thu, Dec 22, 2005 at 10:53:27AM -0500, Bill Sommerfeld wrote: > > On Wed, 2005-12-21 at 18:23 -0800, Andrew wrote: > > > Encryption solves the problem by ensuring that modifications without > > > knowledge of the key would produce gibberish on the disk. > > > > No! This is a common assumption, but it''s wrong in general in the > > presence of partially-known plaintext, > Uh, wouldn''t the checksums detect, with extremely high probablility, any > such tampering?It might, but if it did, it would do so whether or not encryption was in use (recall that I was replying to a message asserting that encryption alone would let you detect malicious modifications via garbled plaintext). It would depend on the choice of checksum algorithm, its interaction with the encryption algorithm, whether the checksum was of the plaintext or the ciphertext, whether it was a keyed or unkeyed function, on whether or not you had a place to store a trusted root checksum, and probably a bunch of other factors that a real cryptographer would think of.. A simple checksum or CRC is great for detecting random single-bit errors but doesn''t stand up to malicious activity. sha256, on the other hand, should be pretty good against deliberate modification attempts if used properly .. but then again, some smart people have made mincemeat out of some of its younger siblings and I keep hearing cryptographers say we don''t know as much as we need to about designing hash functions.. When crypto''s concerned, all the details matter, and I haven''t yet seen a specific design for ZFS encryption.. - Bill (just a novice crypto plumber..)
Bill Sommerfeld wrote: ...> A simple checksum or CRC is great for detecting random single-bit errors > but doesn''t stand up to malicious activity. sha256, on the other hand, > should be pretty good against deliberate modification attempts if used > properly .. but then again, some smart people have made mincemeat out of > some of its younger siblings and I keep hearing cryptographers say we > don''t know as much as we need to about designing hash functions.. > When crypto''s concerned, all the details matter, and I haven''t yet seen > a specific design for ZFS encryption..I recall having a very interesting conversation with Radia Perlman @ SunEngCon earlier this year on that very topic. Nothing specific was mentioned, but just think of the possibilities of zfs + elliptic curve crypto :) cheers, James C. McPherson -- Solaris Datapath Engineering Data Management Group Sun Microsystems
Jake Maciejewski
2005-Dec-23 02:00 UTC
[zfs-discuss] Re: Re: Re: rubber hose crypto with ZFS?
I don''t like how bestcrypt only allows one hidden container per container, further requiring that the non-hidden container only be used read-only. Imagine if my non-hidden container had 3 albums of MP3s by a particular artist. What do I do if a new album comes out? Start a new container? Not only does it look suspicious, but it fragments my mp3 collection! This message posted from opensolaris.org
Pawel Jakub Dawidek
2005-Dec-23 02:45 UTC
[zfs-discuss] Re: Re: rubber hose crypto with ZFS?
On Wed, Dec 21, 2005 at 11:48:10AM +0000, Darren J Moffat wrote: +> On Mon, 2005-12-19 at 17:34, Jake Maciejewski wrote: +> > I think the best way to avoid the chicken and egg problem you describe is by booting from a read-only medium like a CD-ROM (it could be rw but ro would be more secure). OpenSolaris and derivative distros could ship with a boot menu option that loads the kernel, allows the user to select the root parition and slice, prompts for a password to decrypt and load the key which ideally is stored on some other medium (or the key could just be the hash of a password), then transfers control to the new root (I don''t know enough about Solaris yet to say how this would be done). I would think something like this could be done even without ZFS boot support. +> +> and what do you do on hardware that as no CD ? Look for USB port so I can plug USB Pen Drive in. +> While you suggestion is okay for laptop or home systems it doesn''t scale +> into the data centre very well - asking for passwords on reboot goes +> against the A in RAS. Actually device/filesystem level encryption is mostly dedicated for laptop users, as it only provides protection for "cold disks". Of course it can be used for servers, but it will be hard to make it serve its purpose well, ie. protecting against stealing the data/disks: - if you store the key on the server, it won''t help you, - if you keep your HSM in the same place where your server, it won''t help you, - if an attacker will be able to get more time than the time needed for removing the disk from the server, it won''t help you. In other words, if you want to protect your server''s disks from stealing you better pray for long uptimes and hire someone for giving the password on boot (or pluging in a key-holder (eg. USB Pen Drive) or keeping an eye on the servers and protecting HSM with his own chest). +> As for the key being just the hash of the password thats a really bad +> idea, you really need to use something like PKCS#5 if you want to have a +> key derived from something the user types in frequently (ie has to +> remember). Agreed. PKCS#5v2 is really useful, but even more useful is allowing to provide key from a few sources (eg. passphrase and random data from a file). +> Thanks for thinking about this but I''m afraid while your suggestion may +> well work it isn''t the architecture we are looking for. It is exactly +> because root file system encryption is a hard boot strap problem that it +> is not in the first phase of ZFS crypto, [...] I went the path Jake is proposing with my geli[1] for FreeBSD, ie. I allow to encrypt root partition, but one has to boot machine from a CD-ROM or from a USB Pen Drive where /boot/ directory (with kernel) is stored. [1] http://www.freebsd.org/cgi/man.cgi?query=geli +> [...] because most of the problems +> have little to do with the changes to ZFS and more to do with key +> management. That''s true, but you can easly end-up with "there is no ideal way". The approch I took is to allow for using PKCS#5v2-strengthened passphrases plus data from a file (which is very useful especially, because the file could be /dev/stdin). -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20051223/fe2b78bd/attachment.bin>
> I don''t like how bestcrypt only allows one hidden container per container,This suffices for the deniability which the product provides.> further requiring that the non-hidden container only be used read-only.The non-hidden container can be written to; writing to it will simply damage the hidden data if the hidden data is not unlocked first. You mentioned this yourself in your original post. It''s true that Bestcrypt doesn''t support unlocking both the non-hidden and the hidden containers simultaneously, but this isn''t necessary for its intended usage.> Imagine if my non-hidden container had 3 albums of MP3s by a particular artist. What do I do if a new album comes out? Start a new container? Not only does it look suspicious, but it fragments my mp3 collection!You''re looking for a system that allows you to have a non-hidden filesystem with real data which you actively write to, with some hidden subfilesystems mixed in. Bestcrypt''s intended usage is that you have a non-hidden filesystem with a small amount of dummy data and a large amount of free space, which you never actually mount except in the event that you''re rubber hosed, and a hidden filesystem which contains all your real data. Both your proposed system and Bestcrypt''s system provide deniability, and in both cases an adversary can''t prove that hidden data exists. And in both cases, if most of your data is hidden, then even though the adversary can''t prove that hidden data exists, your denial is very implausible. But your system provides the flexibility that the plausibility of the denial is inversely proportional to how much of the data is hidden, so if not all of the data must be hidden, your system provides more plausible deniability. So I agree, in that case your system would be better. However, that requires you to bother to pay attention to which particular data you need to be hidden, and which you don''t, and bother to segregate it correspondingly. Bestcrypt is designed for one-time setup followed by fully transparent operation. For example, on my personal system, I have a huge physical disk, the majority of the space of which is occupied by a single file which contains an encrypted virtual disk. At system startup, I enter a long password (which is for the hidden container), and then operation is fully transparent until the next system restart, at which point I have to enter the password again. The virtual disk contains all my personal data, both that whose secrecy would need to survive me being rubber hosed and that whose secrecy would not, as well as the programs which I''ve installed, which actually don''t even need to be encrypted, all so that I don''t have to bother segregating everything; the physical disk, besides containing that single file, contains essentially nothing else besides the operating system itself, and even that segregation is only because Bestcrypt doesn''t support root filesystem encryption. In the event of rubber hosing, I can reveal an alternate password which will unlock an alternate virtual disk (the non-hidden container) which contains a small amount of dummy data and a huge amount of free space. This suffices for me because my only anticipated adversaries are bored and nosy border guards who are paranoid that I''m a spy transporting stolen state secrets on my personal system during my international travels, and border guards who would be ignorant enough to have such suspicions would also be ignorant enough to be satisfied by the denial which Bestcrypt provides in this case. The threat which I face isn''t rubber hosing, but having my system confiscated. My goal is simply to maintain the necessary secrecy for my secret data while maintaining simplicity of management for all of my data; this is also my own primary argument in favor of root filesystem encryption, and why I asked about it with regards to ZFS. I want to think about security as little as possible, and have everything just be secure by default. Also, my approach is the only feasible one for mass consumption of encryption (or any kind of computer security); if everything is encrypted by default, with no manual administration needed, then Joe random user''s data on his personal machine will be encrypted. Otherwise, it will not be. Witness firewalls in consumer systems which are never turned on unless they''re turned on by default, operating system patches which are never installed unless they''re downloaded and installed automatically by default, and email encryption and authentication systems which are never used by anybody. This message posted from opensolaris.org
Jake Maciejewski
2005-Dec-23 08:05 UTC
[zfs-discuss] Re: Re: Re: rubber hose crypto with ZFS?
> ...if the hidden data is not unlocked first.I didn''t get that impression when I read the docs, but it would make sense for it to work that way.> However, that requires you to bother to pay attention to which particular data you need > to be hidden, and which you don''t, and bother to segregate it correspondingly.That''s where ZFS comes in and why I complained about Bestcrypt only having two containers per backing store. I would have my data mostly segregated anyway in a directory hierarchy, and by the design of ZFS I''d pay no penalty for making some of those subdirectories independently keyed filesystems.> In the event of rubber hosing, I can reveal an alternate password which will unlock an > alternate virtual disk (the non-hidden container) which contains a small amount of > dummy data and a huge amount of free space. This suffices for me because my only > anticipated adversaries are bored and nosy border guards...Under the system I''d like to see implemented, you''d reveal data depending on who you encounter. If you''re worried about an overbearing government and competitors out to steal trade secrets, you could trust both with your latest SchilliX ISOs and additionally give the competing company''s thugs your subversive literature and the government agents your trade secrets, in each case having an excuse for using a plausibly deniable system.> My goal is simply to maintain the necessary secrecy for my secret data while > maintaining simplicity of management for all of my data...I want to think about security > as little as possibleThe minimum additional burden over Bestcrypt is having to provide two keys instead of one. I don''t think one more key is unreasonable. This message posted from opensolaris.org
On Fri, 2005-12-23 at 01:01, James C. McPherson wrote:> SunEngCon earlier this year on that very topic. Nothing specific was > mentioned, but just think of the possibilities of zfs + elliptic curve > crypto :)Don''t hold out for ECC in Solaris or any other Sun product any time soon, there are major patent issues in there due to Certicom. Sun is working very hard on this but it is an expensive and slow process, that IMO the NSA made worse by licensing some of the Certicom patents on ECC. -- Darren J Moffat
On Fri, 2005-12-23 at 02:45, Pawel Jakub Dawidek wrote:> On Wed, Dec 21, 2005 at 11:48:10AM +0000, Darren J Moffat wrote: > +> On Mon, 2005-12-19 at 17:34, Jake Maciejewski wrote: > +> > I think the best way to avoid the chicken and egg problem you describe is by booting from a read-only medium like a CD-ROM (it could be rw but ro would be more secure). OpenSolaris and derivative distros could ship with a boot menu option that loads the kernel, allows the user to select the root parition and slice, prompts for a password to decrypt and load the key which ideally is stored on some other medium (or the key could just be the hash of a password), then transfers control to the new root (I don''t know enough about Solaris yet to say how this would be done). I would think something like this could be done even without ZFS boot support. > +> > +> and what do you do on hardware that as no CD ? > > Look for USB port so I can plug USB Pen Drive in.That assumes physical access, think data centre and think highly restricted physical access.> +> While you suggestion is okay for laptop or home systems it doesn''t scale > +> into the data centre very well - asking for passwords on reboot goes > +> against the A in RAS. > > Actually device/filesystem level encryption is mostly dedicated for > laptop users, as it only provides protection for "cold disks".I disagree and so do many of Sun''s biggest customers that are asking for this functionality. It also protects data on the SAN, consider a host that rents part of a SAN and doesn''t trust the admins with the clear text of the data. Sure you can put the crypto into the HBA if you like.> Of course it can be used for servers, but it will be hard to make it > serve its purpose well, ie. protecting against stealing the data/disks: > - if you store the key on the server, it won''t help you,That depends what your threat model is, if it is physical theft or unauthorised access to that host then yes I agree. If it is untrusted SAN then it does help.> - if you keep your HSM in the same place where your server, it won''t > help you,It does because most HSM systems loose all keys when power is removed, they also don''t let the keys leave the HSM in an unwrapped form and audit when they do. Many of the really good HSM products are very tamper evident or resistant (at least the FIPS 140-2 level 3 or higher products). Sure they aren''t perfect but nothing in this industry is.> - if an attacker will be able to get more time than the time needed for > removing the disk from the server, it won''t help you. > > In other words, if you want to protect your server''s disks from stealing > you better pray for long uptimes and hire someone for giving the > password on boot (or pluging in a key-holder (eg. USB Pen Drive) or > keeping an eye on the servers and protecting HSM with his own chest).Sure physical security always needs to be considered but that doesn''t mean this project is worth less, far from it.> +> Thanks for thinking about this but I''m afraid while your suggestion may > +> well work it isn''t the architecture we are looking for. It is exactly > +> because root file system encryption is a hard boot strap problem that it > +> is not in the first phase of ZFS crypto, [...] > > I went the path Jake is proposing with my geli[1] for FreeBSD, ie. I > allow to encrypt root partition, but one has to boot machine from a > CD-ROM or from a USB Pen Drive where /boot/ directory (with kernel) is > stored.I have thought about that. It is possible we might be able to extend the WAN Boot infrastructure we have in Solaris SPARC as well. The WAN Boot is only for Solaris SPARC since it depends on the OBP being able to do sha hashing in the OBP to verify the sha1 hmac.> [1] http://www.freebsd.org/cgi/man.cgi?query=geliThanks for the pointer. -- Darren J Moffat
Pawel Jakub Dawidek
2005-Dec-28 19:25 UTC
[zfs-discuss] Re: Re: rubber hose crypto with ZFS?
On Fri, Dec 23, 2005 at 10:33:14AM +0000, Darren J Moffat wrote: +> On Fri, 2005-12-23 at 02:45, Pawel Jakub Dawidek wrote: +> > +> While you suggestion is okay for laptop or home systems it doesn''t scale +> > +> into the data centre very well - asking for passwords on reboot goes +> > +> against the A in RAS. +> > +> > Actually device/filesystem level encryption is mostly dedicated for +> > laptop users, as it only provides protection for "cold disks". +> +> I disagree and so do many of Sun''s biggest customers that are asking +> for this functionality. +> +> It also protects data on the SAN, consider a host that rents part of a +> SAN and doesn''t trust the admins with the clear text of the data. Ok, I can buy it, but in such scenario integrity verification of such data is not less important than privacy. Avoiding replay attacks is really hard, as you cannot protect against them without another (but this time trusted) storage device. It also makes implementation much more complex. For laptop one mostly needs privacy (its often enough), as you control physical access to it (at least you can not trust your data after laptop has been stolen and returned back, which is rather rare luck:)). +> > Of course it can be used for servers, but it will be hard to make it +> > serve its purpose well, ie. protecting against stealing the data/disks: +> > - if you store the key on the server, it won''t help you, +> +> That depends what your threat model is, if it is physical theft or +> unauthorised access to that host then yes I agree. If it is untrusted +> SAN then it does help. Agreed. +> > - if you keep your HSM in the same place where your server, it won''t +> > help you, +> +> It does because most HSM systems loose all keys when power is +> removed, they also don''t let the keys leave the HSM in an unwrapped +> form and audit when they do. Many of the really good HSM products +> are very tamper evident or resistant (at least the FIPS 140-2 level 3 +> or higher products). Sure they aren''t perfect but nothing in this +> industry is. I worked on such HSMs and they didn''t loose the keys on power lost. This is not an requirement. Actually such behaviour would be very undesirable. Most often there is a battery, to keep the keys all the time in memory and to be able to protect against phisical attacks like opening the device, too low or too high temperature, etc. Only such attack (or special "panic" key) can lead to keys deletion. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20051228/d55fafd8/attachment.bin>