On Tue, May 5, 2009 at 12:40 PM, Darren J Moffat <darr...@opensolaris.org>wrote:
> Vladimir 'phcoder' Serbinenko wrote: > >> >> >> On Fri, May 1, 2009 at 10:57 AM, Darren J Moffat >> <darr...@opensolaris.org<mailto: >> darr...@opensolaris.org>> wrote: >> >> Ulrich Graef wrote: >> >> According: ZFS encryption >> >> Will it be possible to have an encrypted root pool? >> >> >> We don't encrypt pools, we encrypt datasets. This is the same as >> what is done for compression. >> >> It will be possible in the initial integration to have encrypted >> datasets in the root pool. However the bootfs dataset can not be >> encrypted nor can /var or /usr if you have split those off into >> separate datasets. >> >> bootfs encryption should be quite possible. Especially that now we have >> initial zfs support patch for grub2 by me and a luks patch by Michael Gorven >> > > Can you send me a pointer to this please. Is there a reason why you think > this is more possible with grub2 than with the 0.97 grub that OpenSolaris > currently uses ? > http://lists.gnu.org/archive/html/grub-devel/2009-04/msg00512.html Any developement of grub-0.97 was halted and our efforts concentrate on grub2. Grub2 has much more flexible design. The points that help in zfs developement on it are the following: - real memory allocation. No need to implement a stack or use fixed addresses - possibility of opening multiple devices at the same time - scripting support allows booting from compilcated scenarios. - we already have the cryptography support with Michael Gorven's patch. - everything else I forgot right now because I don't use or code for grub1. While I can't stop you from coding on grub-legacy this would be a waste of resources and struggle against grub-legacy limitations which will be depreceated anyway soon > > > Integration with TPM? >> >> It's both useless and dangerous. What would you use it for? If it's for >> storing the key then It would be like giving a key to someone else and >> hoping that he is trustworthy enough. The moment when a crypto geek will >> find a way to retrieve the key from the tpm (if tpm reach popularity it will >> just be a question of time) your encryption is useless. As a matter of fact >> from this point of view tpm is mere an obfuscation. On the other hand tpm is >> usefull to coerce the user into using a particular software or complying >> with restrictions decided by a big company. All of this was discussed here: >> http://lists.gnu.org/archive/html/grub-devel/2009-02/threads.html#00232 >> > > You are making assumptions about how ZFS crypto would use the TPM and I > haven't design this as yet. However one thing I know for sure is that it > would not be just a key in the TPM there would be "something" the user would > still have to enter by other means. > If you enter a passphrase anyway then the only possible scenario where a data can't be accessed because of TPM is when you put your disks in another machine, TPM chip doesn't give the authentication key TPM chip fails. I don't see why someone who knows a passphrase wouldn't be allowed to change a motherboard. It looks more like a way for a mobo manufacturer to make you stay with him. As for the second it only could theoretically prevent crafted copy from accessing encrypted data it does not prevent you from entering passphrase into crafted copy. So an attacker would just put a version which simulates the password prompt sends it over network and then restores original copy and reboots. As you see circumventing the tpm "protection" only took one additional step (restoring original version). As for the third one I think anyone would be unpleased if his redundant zpool has suddenly became inaccessible just because a chip failed. Using TPM makes any redundancy irrelevant > > -- > Darren J Moffat > -- Regards Vladimir 'phcoder' Serbinenko -- Regards Vladimir 'phcoder' Serbinenko
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
