Hi guys
Nice to see anybody involved. Under all of yours thoughts I have to say yes, yes, yes. Root sys admin
is the person we have to trust most. But still...
The idea behind it is to make using of crypto cards (HSM) easier and more natural. We where thinking
that token/card will be required only during disk initialization but still, we can clone master key
of mounted disk. So no future security enhance can be added to LUKS?
And last thing - we extend cryptsetup as it is more easy. We still have the same tool (under different
name: cryptsetup-pkcs11) and yes, we study library as well (cryptsetup.c is an interface between cli and
library).
Anyway, out job is quite advanced and will be finished. I will open source it and we will see. If anybody
have any suggestion related with dm-crypt and crypto cards/token over PKCS11 comments are welcome. Maybe
something interested can be added :)
Or maybe all the tasks here are just wasting our time :)
Regards
Krzysztof Rutecki
----- Oryginalna wiadomość -----
Od: "Arno Wagner" <arno@xxxxxxxxxxx>
Do: dm-crypt@xxxxxxxx
Wysłane: poniedziałek, 20 maj 2013 14:48:42
Temat: Re: cryptsetup with native PKCS#11 support
On Mon, May 20, 2013 at 05:08:51AM -0400, .. ink .. wrote:
> > Imagine you have servers with 24 bays and few root administrators. What
> > is a chance of disk leakage e.g. where drive is being replace for new
> > one under warranty condition?
If one of the root-people is corrupt, then high. There really is
not way around that except changing the crypto-architecture, see
below.
> > With MooseFS (btw an excellent tool),
> > LUKS, passprase on crypto card/token and cryptsetup supporting pkcs11
> > you can format disk using token as storage and two-factor authentication
> > device. Am I thinking correctly?
Almost. The problem is that with LUKS the key has to go into the
kernel. Hence it is exposed to root users.
> > For backup you can add second key
> > (the same way or classic, just for backup) and sys admins never see
> > key(s). Using now available methods (gnupgp or pkcs11-data) you can
> > easlly modify scripts to dump passphrase or keyfile. I want to minimize
> > it.
You cannot really. A competent administrator with root is somebody
that is trusted, i.e. that can break your security. I do understand
the desire though, a lot of our customers have the problem that
they fear attacks by system administrators too.
The only solution for disk encryption I see is to use raw storage
and encrypt in a dedicated HSM that the admins cannot get into.
Something like this:
------->|filesystem front-end|---------->|HSM|--->|Raw/NFS storage|
clients NFS or
network block dev.
That is 2 systems and one HSM, and a HSM that can encrypt
disk traffic in real-time will be something like 50'000 EUR/USD
and up. It will protect your data against the administrators
though, unless they steal the HSM. But that would be obvious.
So the security comes from the fact that the HSM cannot be cloned.
Of course, that is not strictly true for most HSMs either, as
there are operational requirements in case one fails. What I
have seen (and think is a good solution) is that the HSM is
initialized with a set of chip-cards and an k-out-of-n
scheme. For example, there are 5 chipcards, and 3 are needed
to initialize a new HSM (i.e. also to clone the existing one).
Then 3 people have to collude to attack this. (It is not
n-of-n, as chipcards can get lost, be defective, etc...).
So, while I applaud your initiative, you cannot allow
root-users on the system the encrytption is done. This
is not a LUKS limitation, it is more fundamental. In
my example above, it would be perfectly fine for the
HSM to use LUKS internally.
> I do not think its possible to hide anything from a user who has logged in
> with root's credentials.
It is possible to hide the passphrase, but that does not help much,
as it is fundamentally impossible to hide the master-key from root.
Also refer to FAQ item 6.10 in
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
where it is described how to get the master key from a mapped
container.
> If they can modify scripts,they can replace your
> binary solution.As users with root privileges,they are effectively GODS and
> there is nothing technically you can do to stop them,the best you can do is
> have some policies and making sure and hope they adhere to them.
Indeed.
> You can use libraries if you worry about leakage from loose boundaries btw
> different binaries and scripts.
>
> cryptsetup ships with a library you can interface with[1],the two binaries
> you have mentioned also have libraries you can interface with, most tokens
> ships with libraries that talks to the hardware too or generic ones
> exists.Why not use cryptsetup library and the library provided by the
> hardware and add some logic btw them in your binary or library.
I think doing a crypto-token interface on top of the libraries would
be a good idea. That way it is only loosely coupled. The library
should have a pretty stable interface and is reasonably easy to
use from my limited experience with implementing the key-slot
checker tool.
> The library interface should be enough,have you looked at it and determined
> its not adequate? how is it not adequate if you have?
>
> [1]http://wiki.cryptsetup.googlecode.com/git/API/index.html
I think you shgould try for this. Far easier than maintainoing
a patch-set.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult. --Tony Hoare
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
