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" <raole...@btinternet.com>
Sender: zfs-crypto-discuss-boun...@opensolaris.org
Date: Wed, 27 Apr 2011 11:46:02
To: Troels Nørgaard Nielsen<tro...@norgaard.co>
Cc: <zfs-crypto-discuss@opensolaris.org>
Subject: RE: Booting from encrypted ZFS WAS: RE: How to mount encrypted file
system at boot? Why no pass phraserequesed
Hi Troels,
There are two things here. First, I don't want to learn another set of
administration tasks (I've just had a quick look at Trusted Extensions and
am shuddering at the thought) and second, the problem isn't when the system
is running but when it is stopped. I believe the problem is called "data at
rest". Also, notice the line where I said the auditors like a simple story.
They really do.
I still want to be able to print and use the network without incurring lots
of admin, re-programming or performance overhead. (Our applications are very
network heavy.) But, when I shutdown I want the data on the disks to be
un-intelligible.
In terms of management/learning overhead, we are very familiar with tracking
and accounting for documents and keys, so having a few extra keys and usb
sticks to look after is no problem.
Unfortunately, I don't know enough about grub and zfs booting. So, I shall
resist the temptation of "can't it just...". Almost. I'm sure there's a way.
Chain from authentication phase and getting key to main boot...? (Sorry, I
had to.)
Best regards,
Rob
-----Original Message-----
From: Troels Nørgaard Nielsen [mailto:tro...@norgaard.co]
Sent: 27 April 2011 11:13
To: Rob O'Leary
Cc: zfs-crypto-discuss@opensolaris.org
Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted
file system at boot? Why no pass phraserequesed
Hi Rob,
Wouldn't the use of Solaris Trusted Extensions by placing all 'secure'
operations inside a label that can only write to the filesystem (that is
encrypted) with the same label, do for you what the auditors are seeking?
The base idea of Trusted Extensions is that no data can escape it's label
(guarded by syscall checks), to ensure traffic to the label, one can use
IPSec with labeling, etc.
I think Darren is dragging along here, because implementing zfs-crypto on
rpool requires grub to be aware of zfs-crypto, which is kinda hard (e.g.
grub doesn't support multiple vdev or raidz-n yet).
Best regards
Troels Nørgaard
Nørgaard Consultancy
Den 27/04/2011 kl. 09.54 skrev Rob O'Leary:
>
> Requirements
> The main requirement is to convince our security auditors that all the
data
> on our systems is encrypted. The systems are moved between multiple
trusted
> locations and the principle need is to ensure that, if lost or stolen
while
> on the move, no data can be accessed. The systems are not required to
> operate except in a trusted location.
>
> Storing the data on encrypted zfs filesystems seems like it should be
> sufficient for this. But the counter argument is that you cannot
_guarentee_
> that no data will be accidentally copied onto un-encrypted parts of the
> system, say as part of the print spooling of a data report (by the system)
> or by a user for some other reason. The auditors don't want to rely on
> processes being followed by people to ensure security (and I agree with
> them). They like a nice straight-forward story - "the whole system is
> encrypted".
>
> So, answering your question, I don't want the OS encrypted, I want all
> writable media encrypted.
>
> In terms of the two factors, I think I should: 1) need a physical thing
> (e.g. a usb stick with a particular file on it) and, 2) know a
> password/passphrase, in order to be able to boot the system. (The usb
stick
> can be removed once authentication is completed.)
>
> Although the mobility of the usage sounds rather more "laptop" than "data
> centre", the systems are used for collecting and storing terabytes of data
> (at rates up to 10 Gb/s), so the scale quickly becomes more like data
> centre. And back to the earlier point, the data storage can be on zfs
> encrypted fs's, it's just a case of closing the last loophole.
Additionally,
> some of the data reports generated can be quite small (easily fit on the
> system disk) and still require protection in the event of lost disks.
>
> In a lights out situation, presuming the trusted location, the usb stick
> could be left in the machine and passphrases supplied at boot time. It
might
> also be possible to arrange a passphrase server with ssh/asymmetric
> encryption to supply the passphrase during boot, using the booting
system's
> public key and including replay prevention. This approach might address
the
> high availability (HA) scenario, but I'm afraid I don't have any
experience
> of HA systems.
>
> I appreciate that this type of two factor booting will require some
> management overhead, usb sticks will need labels and tracking, and keys
and
> passphrases will need storing/backing up. These will add cost but,
"security
> costs".
>
> I hope this gives you a better idea of what I need.
>
> Regards,
> Rob
>
>
> PSs
>
> Writable media and the OS - Booting and operating from a read-only DVD and
> using memory backed caching for everything, sounds good in theory.
However,
> this would be a total pain whenever you need to make a permanent change to
a
> system setting, as you then need to burn another DVD and reboot the
system.
> Unless you were going into mass production with 10s of identical systems,
I
> don't think this would be a usable solution.
>
> Limiting authentication attempts - It might be a good thing to obliterate,
> after say 20 attempts, the on-system data which is used to release the
key,
> forcing the need to access a backup of that data. I think this would slow
> down a good-guesses/dictionary style attack by a person at the keyboard
but
> may not be effective against a determined attacker who makes images of the
> disk before starting... I'm sure you know more about this than I do.
>
> -----Original Message-----
> From: Darren J Moffat [mailto:darr...@opensolaris.org]
> Sent: 26 April 2011 09:47
> To: Rob O'Leary
> Cc: zfs-crypto-discuss@opensolaris.org
> Subject: Re: Booting from encrypted ZFS WAS: RE: How to mount encrypted
> file system at boot? Why no pass phraserequesed
>
>
> On 24/04/2011 18:49, Rob O'Leary wrote:
>> Reading this reminded me that the feature I'm really waiting for is
>> two-factor boot time authentication from encrpyted zfs boot...
>
> Can you explain more about your requirements and use case ?
>
> Is this "laptop" or "data centre" ? or some thing else ?
> What "two factors" do you want ?
> How will this work in a lights out and/or high availability deployment ?
>
> Why do you want the operating system itself encrypted rather than just
> the data stored on the system ? ie What is threat you are trying to
> protect against ?
>
>> 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@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
