On Mon, May 20, 2013 at 04:56:23PM +0200, Krzysztof Rutecki wrote: > 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? No, because it does not fit the architecture and security model. LUKS is software encryption and there you allways have to trust root users, no way around that. What you want to do is something conceptionally different. And no, a crypto card is a security token, but not an HSM, unless you let it do the encryption itself and it has keyboard and display for passphrases. For most applications, cards will be far too slow, even though some with keyboard and display exists. Cards can hold keys with some (not very high) level of seurity, but that is basically it. A HSM is something far more massive. It includes phycial proection, (sensors, battery, always-on monitoring, effective self-destruct,...), secure RNGs, encryption engines, etc. Think of it as something that uses 1-3 19" HEs and costs more than a new car. Yes, I know that some people have started to call crypto-cards "HSMs", but that is just marketing nonsense and dishonest. > 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). Initially maybe. As soon as cryptsetup changes, likely not anymore. Arno > 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 -- 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
