According: ZFS encryption Will it be possible to have an encrypted root pool? Integration with TPM? Regards, Ulrich -- | Ulrich Graef, Senior System Engineer, OS Ambassador \
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.> Integration with TPM?Eventually yes. Initially via PKCS#11 and eventually using it to store the key for an encrypted bootfs. However neither of these are in scope for the first integration of the ZFS Crypto project. They haven''t been dropped they were never planned for the initial integration. TPM support in OpenSolaris is quite new (it won''t be in the 2009.06 release), we don''t yet have TPM support in GRUB and we don''t yet have SPARC TPM support either. To get an encrypted bootfs dataset we need to also modify GRUB to provide read only support for encrypted datasets. Doing this for SPARC is much harder - and might require OBP updates. -- Darren J Moffat
Vladimir ''phcoder'' Serbinenko
2009-May-05 22:14 UTC
[zfs-discuss] Fwd: ? ZFS encryption with root pool
On Tue, May 5, 2009 at 12:40 PM, Darren J Moffat <darrenm at opensolaris.org>wrote:> Vladimir ''phcoder'' Serbinenko wrote: > >> >> >> On Fri, May 1, 2009 at 10:57 AM, Darren J Moffat <darrenm at opensolaris.org<mailto: >> darrenm at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090506/6a74cea9/attachment.html>