zfs crypto discuss - Apr 2011 - How to mount encrypted file system at boot? Why no pass phrase requesed

I went to a talk last night at the London Open Solaris User Group (LOSUG) by
Darren Moffat - an Oracle engineer who had a major role in the ZFS encryption
implementation in Solaris. I was particularly interested in this,as for a long
time I''ve been concerned about security of data on my laptop.

I decided to try to secure my laptop, which is running Solaris 11 Express. I
want to set the machine up so that during the boot process I get asked to enter
the pass phrase to mount file system with my home directory on.

But I am having problems.

First I create the file system. As expected, Solaris asks for a pass phrase:

drkirkby at laptop:~# zfs create -o compression=on -o encryption=on -o
mountpoint=/export/home/davek rpool/export/home/davek
Enter passphrase for ''rpool/export/home/davek'': *******
Enter again: ******

Next I create a file on the file system and check it exists.

drkirkby at laptop:~# touch /export/home/davek/foo
drkirkby at laptop:~# ls /export/home/davek/foo
/export/home/davek/foo

Unmount the encrypted file system

drkirkby at laptop:~# zfs umount rpool/export/home/davek

Check  the file I created is no longer available

drkirkby at laptop:~# ls /export/home/davek/foo
/export/home/davek/foo: No such file or directory

Now I get a problem. I was expecting to have to enter the pass phrase again when
attempting to mount the file system, but this is not being requested. As you can
see, I can mount the file system without the pass phrase and read the data on
the file system.

drkirkby at laptop:~# zfs mount rpool/export/home/davek
drkirkby at laptop:~# ls /export/home/davek/foo
/export/home/davek/foo
drkirkby at laptop:~#

This looks wrong to me, but I''ve no idea how to solve it.

The next issue is how do I get the file system to mount when the machine is
booted? I want to supply the pass phrase by typing it in, rather than from
storing it in USB stick or other similar method.

Here''s all the properties of my file system 

drkirkby at laptop:~# zfs get all rpool/export/home/davek
NAME                     PROPERTY                        VALUE                  
SOURCE
rpool/export/home/davek  type                            filesystem             
-
rpool/export/home/davek  creation                        Thu Apr 21  9:16 2011  
-
rpool/export/home/davek  used                            32K                    
-
rpool/export/home/davek  available                       220G                   
-
rpool/export/home/davek  referenced                      32K                    
-
rpool/export/home/davek  compressratio                   1.00x                  
-
rpool/export/home/davek  mounted                         yes                    
-
rpool/export/home/davek  quota                           none                   
default
rpool/export/home/davek  reservation                     none                   
default
rpool/export/home/davek  recordsize                      128K                   
default
rpool/export/home/davek  mountpoint                      /export/home/davek     
local
rpool/export/home/davek  sharenfs                        off                    
default
rpool/export/home/davek  checksum                        sha256-mac             
local
rpool/export/home/davek  compression                     on                     
local
rpool/export/home/davek  atime                           on                     
default
rpool/export/home/davek  devices                         on                     
default
rpool/export/home/davek  exec                            on                     
default
rpool/export/home/davek  setuid                          on                     
default
rpool/export/home/davek  readonly                        off                    
default
rpool/export/home/davek  zoned                           off                    
default
rpool/export/home/davek  snapdir                         hidden                 
default
rpool/export/home/davek  aclinherit                      restricted             
default
rpool/export/home/davek  canmount                        on                     
default
rpool/export/home/davek  xattr                           on                     
default
rpool/export/home/davek  copies                          1                      
default
rpool/export/home/davek  version                         5                      
-
rpool/export/home/davek  utf8only                        off                    
-
rpool/export/home/davek  normalization                   none                   
-
rpool/export/home/davek  casesensitivity                 sensitive              
-
rpool/export/home/davek  vscan                           off                    
default
rpool/export/home/davek  nbmand                          off                    
default
rpool/export/home/davek  sharesmb                        off                    
default
rpool/export/home/davek  refquota                        none                   
default
rpool/export/home/davek  refreservation                  none                   
default
rpool/export/home/davek  primarycache                    all                    
default
rpool/export/home/davek  secondarycache                  all                    
default
rpool/export/home/davek  usedbysnapshots                 0                      
-
rpool/export/home/davek  usedbydataset                   32K                    
-
rpool/export/home/davek  usedbychildren                  0                      
-
rpool/export/home/davek  usedbyrefreservation            0                      
-
rpool/export/home/davek  logbias                         latency                
default
rpool/export/home/davek  dedup                           off                    
default
rpool/export/home/davek  mlslabel                        none                   
default
rpool/export/home/davek  sync                            standard               
default
rpool/export/home/davek  encryption                      on                     
local
rpool/export/home/davek  keysource                       passphrase,prompt      
local
rpool/export/home/davek  keystatus                       available              
-
rpool/export/home/davek  rekeydate                       Thu Apr 21  9:16 2011  
local
rpool/export/home/davek  rstchown                        on                     
default
rpool/export/home/davek  org.opensolaris.caiman:install  ready                  
inherited from rpool
rpool/export/home/davek  com.sun:auto-snapshot           true                   
inherited from rpool


Any  ideas what I need to do to get this file system to request the pass phrase
before mountin g the file system?

Dave
-- 
This message posted from opensolaris.org

On 21/04/2011 11:05, Dr. David Kirkby wrote:
> I went to a talk last night at the London Open Solaris User Group (LOSUG)
by Darren Moffat - an Oracle engineer who had a major role in the ZFS encryption
implementation in Solaris. I was particularly interested in this,as for a long
time I''ve been concerned about security of data on my laptop.
>
> I decided to try to secure my laptop, which is running Solaris 11 Express.
I want to set the machine up so that during the boot process I get asked to
enter the pass phrase to mount file system with my home directory on.
>
> But I am having problems.
>
> First I create the file system. As expected, Solaris asks for a pass
phrase:
>
> drkirkby at laptop:~# zfs create -o compression=on -o encryption=on -o
> mountpoint=/export/home/davek rpool/export/home/davek
> Enter passphrase for ''rpool/export/home/davek'': *******
> Enter again: ******
>
> Next I create a file on the file system and check it exists.
>
> drkirkby at laptop:~# touch /export/home/davek/foo
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo
>
> Unmount the encrypted file system
>
> drkirkby at laptop:~# zfs umount rpool/export/home/davek
>
> Check  the file I created is no longer available
>
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo: No such file or directory
> Now I get a problem. I was expecting to have to enter the pass
> phrase  again when attempting to mount the file system, but this is not
being
> requested. As you can see, I can mount the file system without the pass
> phrase and read the data on the file system.
I covered that in the talk last night - in fact we had about a 5 minute 
discussion about why it is this way.

If you want the key to go away you need to run:

	# zfs key -u rpool/export/home/davek
> drkirkby at laptop:~# zfs mount rpool/export/home/davek
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo
> drkirkby at laptop:~#
>
> This looks wrong to me, but I''ve no idea how to solve it.
No it is correct by design.

As I mentioned last night the reason for this is so that delegated 
administration of certain properties can work for users that don''t have
the ''key'' delegation and don''t have access to the
wrapping keys.

For example changing a mountpoint causes an umount followed by a mount. 
  There are other changes that under the covers can cause a filesystem 
to be temporarily unmounted and remounted.
> The next issue is how do I get the file system to mount when the
 > machine is booted? I want to supply the pass phrase by typing it in,
 > rather than from storing it in USB stick or other similar method.

Since this is your user home directory the ideal way would be a PAM 
module that ran during user login and requested the passphrase for the 
ZFS encrypted home dir.

There isn''t one in Solaris 11 Express (snv_151a) at this time.
> Any  ideas what I need to do to get this file system to request the
> pass phrase before mountin g the file system?
There is source for a prototype PAM module in the old opensolaris.org 
zfs-crypto repository:

http://src.opensolaris.org/source/history/zfs-crypto/phase2/usr/src/lib/pam_modules/

You would need to take a clone of that repository and check out 
changeset  6749:6dded109490e  and see if that old PAM module could be 
hacked into submission.  Note that it uses private interfaces and doing 
so is not supported by any Oracle support contract you have.

-- 
Darren J Moffat

On 21 April 2011 13:31, Darren J Moffat <darrenm at opensolaris.org>
wrote:
>> Now I get a problem. I was expecting to have to enter the pass
>> phrase ?again when attempting to mount the file system, but this is not
>> being
>> requested. As you can see, I can mount the file system without the pass
>> phrase and read the data on the file system.
>
> I covered that in the talk last night - in fact we had about a 5 minute
> discussion about why it is this way.
>
> If you want the key to go away you need to run:
>
> ? ? ? ?# zfs key -u rpool/export/home/davek
>
>> drkirkby at laptop:~# zfs mount rpool/export/home/davek
>> drkirkby at laptop:~# ls /export/home/davek/foo
>> /export/home/davek/foo
>> drkirkby at laptop:~#
>>
>> This looks wrong to me, but I''ve no idea how to solve it.
>
> No it is correct by design.
>
> As I mentioned last night the reason for this is so that delegated
> administration of certain properties can work for users that don''t
have the
> ''key'' delegation and don''t have access to the
wrapping keys.
>
> For example changing a mountpoint causes an umount followed by a mount.
> ?There are other changes that under the covers can cause a filesystem to be
> temporarily unmounted and remounted.
Thanks. You did loose me in some places - I guess that was one of them.
>> The next issue is how do I get the file system to mount when the
>
>> machine is booted? I want to supply the pass phrase by typing it in,
>> rather than from storing it in USB stick or other similar method.
>
> Since this is your user home directory the ideal way would be a PAM module
> that ran during user login and requested the passphrase for the ZFS
> encrypted home dir.
>
> There isn''t one in Solaris 11 Express (snv_151a) at this time.
>
>> Any ?ideas what I need to do to get this file system to request the
>> pass phrase before mountin g the file system?
>
> There is source for a prototype PAM module in the old opensolaris.org
> zfs-crypto repository:
>
>
http://src.opensolaris.org/source/history/zfs-crypto/phase2/usr/src/lib/pam_modules/
>
> You would need to take a clone of that repository and check out changeset
> ?6749:6dded109490e ?and see if that old PAM module could be hacked into
> submission. ?Note that it uses private interfaces and doing so is not
> supported by any Oracle support contract you have.
>
> --
> Darren J Moffat
I don''t fancy going to that length. Are there simpler options, that
don''t require hacking the system so much? I guess one way is to store
very little in one''s home directory, then store all potentially
sensitive data in another file system. I''m not overly concerned about
what might be in $HOME/.bash_history or similar.



Dave

Reading this reminded me that the feature I''m really waiting for is
two-factor boot time authentication from encrpyted zfs boot...

Is this likely to be seen in the near-ish future?

Regards
Rob

-----Original Message-----
From: zfs-crypto-discuss-bounces at opensolaris.org
[mailto:zfs-crypto-discuss-bounces at opensolaris.org]On Behalf Of Darren J
Moffat
Sent: 21 April 2011 13:32
To: Dr. David Kirkby
Cc: zfs-crypto-discuss at opensolaris.org
Subject: Re: How to mount encrypted file system at boot? Why no pass
phraserequesed


On 21/04/2011 11:05, Dr. David Kirkby wrote:
> I went to a talk last night at the London Open Solaris User Group (LOSUG)
by Darren Moffat - an Oracle engineer who had a major role in the ZFS
encryption implementation in Solaris. I was particularly interested in
this,as for a long time I''ve been concerned about security of data on
my
laptop.
>
> I decided to try to secure my laptop, which is running Solaris 11 Express.
I want to set the machine up so that during the boot process I get asked to
enter the pass phrase to mount file system with my home directory
on.
>
> But I am having problems.
>
> First I create the file system. As expected, Solaris asks for a pass
phrase:
>
> drkirkby at laptop:~# zfs create -o compression=on -o encryption=on -o
> mountpoint=/export/home/davek rpool/export/home/davek
> Enter passphrase for ''rpool/export/home/davek'': *******
> Enter again: ******
>
> Next I create a file on the file system and check it exists.
>
> drkirkby at laptop:~# touch /export/home/davek/foo
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo
>
> Unmount the encrypted file system
>
> drkirkby at laptop:~# zfs umount rpool/export/home/davek
>
> Check  the file I created is no longer available
>
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo: No such file or directory
> Now I get a problem. I was expecting to have to enter the pass
> phrase  again when attempting to mount the file system, but this is not
being
> requested. As you can see, I can mount the file system without the pass
> phrase and read the data on the file system.
I covered that in the talk last night - in fact we had about a 5 minute
discussion about why it is this way.

If you want the key to go away you need to run:

	# zfs key -u rpool/export/home/davek
> drkirkby at laptop:~# zfs mount rpool/export/home/davek
> drkirkby at laptop:~# ls /export/home/davek/foo
> /export/home/davek/foo
> drkirkby at laptop:~#
>
> This looks wrong to me, but I''ve no idea how to solve it.
No it is correct by design.

As I mentioned last night the reason for this is so that delegated
administration of certain properties can work for users that don''t have
the ''key'' delegation and don''t have access to the
wrapping keys.

For example changing a mountpoint causes an umount followed by a mount.
  There are other changes that under the covers can cause a filesystem
to be temporarily unmounted and remounted.
> The next issue is how do I get the file system to mount when the
 > machine is booted? I want to supply the pass phrase by typing it in,
 > rather than from storing it in USB stick or other similar method.

Since this is your user home directory the ideal way would be a PAM
module that ran during user login and requested the passphrase for the
ZFS encrypted home dir.

There isn''t one in Solaris 11 Express (snv_151a) at this time.
> Any  ideas what I need to do to get this file system to request the
> pass phrase before mountin g the file system?
There is source for a prototype PAM module in the old opensolaris.org
zfs-crypto repository:

http://src.opensolaris.org/source/history/zfs-crypto/phase2/usr/src/lib/pam_
modules/

You would need to take a clone of that repository and check out
changeset  6749:6dded109490e  and see if that old PAM module could be
hacked into submission.  Note that it uses private interfaces and doing
so is not supported by any Oracle support contract you have.

--
Darren J Moffat
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

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

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:darrenm at opensolaris.org]
Sent: 26 April 2011 09:47
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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

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:darrenm at opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O''Leary
> Cc: zfs-crypto-discuss at 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

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:troels at norgaard.co]
Sent: 27 April 2011 11:13
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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 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:darrenm at opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O''Leary
> Cc: zfs-crypto-discuss at 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

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%3Den-US%26name%3Ddn_sec_intro_fde%26vgnextoid%3D1831bb5f5ed93110VgnVCM100000f5ee0a0aRCRD&sa=U&ei=8_e3TfvVIInBtgemsdjeBA&ved=0CAgQFjAA&usg=AFQjCNGt_c3Vokq4D6hL8k25rfUcIrB2Bw).
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" <raoleary at btinternet.com>
Sender: zfs-crypto-discuss-bounces at opensolaris.org
Date: Wed, 27 Apr 2011 11:46:02 
To: Troels N??rgaard Nielsen<troels at norgaard.co>
Cc: <zfs-crypto-discuss at 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:troels at norgaard.co]
Sent: 27 April 2011 11:13
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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 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:darrenm at opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O''Leary
> Cc: zfs-crypto-discuss at 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

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.belleau at malaiwah.com [mailto:michel.belleau at malaiwah.com]
Sent: 27 April 2011 12:08
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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%3D1831bb5f5ed93110VgnVCM100000f
5ee0a0aRCRD&sa=U&ei=8_e3TfvVIInBtgemsdjeBA&ved=0CAgQFjAA&usg=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" <raoleary at btinternet.com>
Sender: zfs-crypto-discuss-bounces at opensolaris.org
Date: Wed, 27 Apr 2011 11:46:02
To: Troels N??rgaard Nielsen<troels at norgaard.co>
Cc: <zfs-crypto-discuss at 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:troels at norgaard.co]
Sent: 27 April 2011 11:13
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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 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:darrenm at opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O''Leary
> Cc: zfs-crypto-discuss at 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

I take it back, there do appear to be seagate savvio disks with FDE option.
I''m struggling a bit to find where to buy them... And I''m not
sure how I
would fair on the "requires TCG-compliant host or controller".

Rob

-----Original Message-----
From: michel.belleau at malaiwah.com [mailto:michel.belleau at malaiwah.com]
Sent: 27 April 2011 12:08
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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%3D1831bb5f5ed93110VgnVCM100000f
5ee0a0aRCRD&sa=U&ei=8_e3TfvVIInBtgemsdjeBA&ved=0CAgQFjAA&usg=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" <raoleary at btinternet.com>
Sender: zfs-crypto-discuss-bounces at opensolaris.org
Date: Wed, 27 Apr 2011 11:46:02
To: Troels N??rgaard Nielsen<troels at norgaard.co>
Cc: <zfs-crypto-discuss at 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:troels at norgaard.co]
Sent: 27 April 2011 11:13
To: Rob O''Leary
Cc: zfs-crypto-discuss at 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 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:darrenm at opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O''Leary
> Cc: zfs-crypto-discuss at 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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20110428/429705d7/attachment.bin>

Hi Dan,

Your first two interpretations are correct.

I like the idea of netbooting but unfortunately, although a good idea, it
doesn''t fit with the details of our use case - we temporarily take our
system to a trusted location, use it and then remove it, so we do not have a
permanent presence at the trusted locations (other than our base location).
This means that providing the netboot environment is effectively the same
problem, as anything on the same network as the data becomes subject to the
same rules regarding protection.

Putting the boot system on the key media isn''t quite the same as
transporting the key on media alone - the key media can be read-only/only
used at boot to authenticate, whereas the boot system is on writable media.
(I have already considered read-only boot images on DVD but due to the low
numbers of systems and the need to make permanent changes to the system, I
do not consider this approach operable.)

Regarding tampering and tamper detection, when the disks are transported, we
do not rely on an IT approach to these issues.

Regards,
Rob

-----Original Message-----
From: Daniel Carosone [mailto:dan at geek.com.au]
Sent: 28 April 2011 03:21
To: Rob O''Leary
Cc: Troels N?rgaard Nielsen; zfs-crypto-discuss at opensolaris.org
Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount
encryptedfile 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.

Thanks guys for the input it is really helpful and has helped validate 
the design I have.

I have plans to hopefully provide encrypted root file systems at some 
point in the future but there are other dependencies that need to be met 
else where in the system to make it possible to move that project beyond 
a proof of concept (which is where I have it now).

I can''t commit to when or if this will definitely happen for a given 
release.  I can say though it won''t be in the Solaris 11 GA (aka FCS) 
release though.

--
Darren J Moffat