[dm-crypt] cryptsetup with native PKCS#11 support

[dm-crypt] cryptsetup with native PKCS#11 support

[Krzysztof Rutecki]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Hi guys 

I`m new here. The purpose of this email is PKCS#11 support in cryptsetup I`m working on. 


In short: I need to encrypt disk with LUKS and store key on PKCS#11 compatible device. I now 
there is a lot of example how to do this using gnupgp or openssl. The goal is to have key only on token, 
retrieve upon 'luksOpen' operation based on PIN only. 


What is working now is: 
- key generation (as pass-phrase ) using smartcard/token hardware RNG 
- encrypt a backup of the key using certificate from token upon 'luksFormat' 
- decrypt key from file using privatekey from token upon 'luksOpen' 
- all above extansions are build in into cryptsetup command (few new switches) 
- dependencies are minimal - only pkcs11 library file for token is required (no libp11 or pkcs11-helper) 


Later I will add storage of keyfile on token as data object. 


As this job is for private use only, the code is a little messy and unclean. 


So I want to open a discussion : is a native PKCS#11 support in cryptsetup needed? If yes, please give me any 
possible hint can help. Or suggestion what or how to implement to make it secure. 


Regards 
Krzysztof Rutecki 

[-- Attachment #2: Type: text/html, Size: 3092 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Sun, May 19, 2013 at 3:02 PM, Krzysztof Rutecki
<krzysztof@kress-net.com>wrote:

> Hi guys
>
> I`m new here. The purpose of this email is PKCS#11 support in cryptsetup
> I`m working on.
>
> In short: I need to encrypt disk with LUKS and store key on PKCS#11
> compatible device. I now
> there is a lot of example how to do this using gnupgp or openssl.  The
> goal is to have key only on token,
> retrieve upon 'luksOpen' operation based on PIN only.
>
>
i want to add the same functionality in my project hosted at:
http://code.google.com/p/zulucrypt/ but i dont have the hardware to
implement it on.

are you making a proprietary or a FOSS solution?,if FOSS,where do you host
your sources?

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Krzysztof Rutecki]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]



Hi 

Since today all modifications to cryptsetup are my own usage only. I will clean a code and open repo somewhere (GitHub probably ). 
And yes, it will be open source. I have few crypto cards (CyrptoTech, ACS and Gemalto) and two readers. At beginning its ok. 
Soon I will get few tokens (USB devices, in operation it looks like reader and card all-in-one). As my modification are only extensions 
I plan to release it in to versions: integrated with latest version of cryptsetup and patch only. We will see... 



What is more user friendly Google Code or GitHub? 


Regards 
Krzysztof Rutecki 






On Sun, May 19, 2013 at 3:02 PM, Krzysztof Rutecki < krzysztof@kress-net.com > wrote: 




Hi guys 

I`m new here. The purpose of this email is PKCS#11 support in cryptsetup I`m working on. 


In short: I need to encrypt disk with LUKS and store key on PKCS#11 compatible device. I now 
there is a lot of example how to do this using gnupgp or openssl. The goal is to have key only on token, 
retrieve upon 'luksOpen' operation based on PIN only. 




i want to add the same functionality in my project hosted at: http://code.google.com/p/zulucrypt/ but i dont have the hardware to implement it on. 

are you making a proprietary or a FOSS solution?,if FOSS,where do you host your sources? 




[-- Attachment #2: Type: text/html, Size: 4036 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

> What is more user friendly Google Code or GitHub?
>
>
code.google.com look more professional,serious and cleaner to me.To add to
its sense of seriousness,you get a dedicated download page where you have
more visible and official releases.

on the downside,it lacks "social integration",it seem to be designed with
only one project in mind and the project lives independent of everything
else.

github on the other hand,it seem hacky to me and a place where you throw
some random bits though people do serious work there.You can have one
account with multiple subprojects,you can have your repos and people can
collaborate with you from their repositories,you get to see who contributes
what,where,how much,you know, the whole social thing.If you are into that
kind of thing then github will be a place to be.If you plan to have
multiple subprojects,related or otherwise then github is a place to be too.

Which one you will like may come down to personal preference.I have project
in both and i use them equally.

Those in authority will give you an authoritative answer so take what i am
about to say as merely toothless speculations.I think the answer you will
get to your request to patch cryptsetup to add functionality you seek is
"NO" and the reason given will be that the kind functionality you are
seeking lives above cryptsetup and the best way to go about it is to get
the key somehow independent of cryptsetup and then just pass it to
cryptsetup.for it to unlock the volume.

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Krzysztof Rutecki]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

Hi 

The reason I`m doing it is to have a solution where passphrase never leave host or better, never leave cryptsetup tool. My company is working on NAS solutions with maximum 
security lever. 


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? 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? 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. 


Of course I`m not expecting that maintainers of official cryptsetup will integrate it. Maybe some day. Those I was thinking about GitHub. I can make a fork of official cryptsetup, then 
fork from it to my version. Community can see what cams from and how. 


Anyway lots of job to be done before code will be ready to place on public repo.It will be, maybe in next 2-3 weeks. If you are interested, good and help full source of smartcards is 
SmartCardsFocus . Thanks guys for help with ACOS5-64 cards! RSA4096 is finally working well under PKCS#11. Good job. 


Regards 
Krzysztof Rutecki 




[-- Attachment #2: Type: text/html, Size: 3193 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

> 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? 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? 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.
>
>
I do not think its possible to hide anything from a user who has logged in
with root's credentials.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.

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.


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

[-- Attachment #2: Type: text/html, Size: 2475 bytes --]

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Arno Wagner]

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@wagner.name
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

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Krzysztof Rutecki]

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@wagner.name>
Do: dm-crypt@saout.de
Wysłane: poniedziałek, 20 maj 2013 14:48:42
Temat: Re: [dm-crypt] 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@wagner.name
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@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Arno Wagner]

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@wagner.name>
> Do: dm-crypt@saout.de
> Wysłane: poniedziałek, 20 maj 2013 14:48:42
> Temat: Re: [dm-crypt] 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@wagner.name
> 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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] cryptsetup with native PKCS#11 support

[Milan Broz]

Hi,

just few notes (I think most of the arguments were already mentioned).

On 20.5.2013 16:56, Krzysztof Rutecki wrote:
> 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...

Once you run encryption on main processor, you must trust superuser.

It is nice we can limit sone attack vectors but the key will be always somewhere
in memory (in dmcrypt case it is part of config ioctl structure.)

Note, dmcrypt is not military technology with robust hw tamper resistant design,
and it has some limits.

Yes, we have kernel keyring, we can limit key transfer (and I agree that
sending key in dm-ioctl message is stupid) but the problem is still there
even if key is in some special keyring.

> 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?

I would like to have "LUKS2" where keyslots can be of different types - it can be
handle to kernel keyring, it can be handle to some token.

(IOW the key will be initialized not through dm-ioctl but through some
other interface dependent of keyslot type.)

But in the end, there will be still key somewhere in main CPU
which run encryption.

So yes, there will be some development which could help your project.

> 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).

Better do not do that. I will not accept such patches upstream, it is against
design architecture.
libcryptsetup is much more powerful than cryptsetup (see e.g. cryptsetup-reencrypt tool).
(and cryptsetup is VERY limited by backward CLI compatibility)

If there is any function missing in libcryptsetup, let me know,
I can help to provide that. And patches, as always, are welcome.

But please try to not extend cryptsetup command with upstream incompatible extensions.

Some more notes (Also see PAM PKCS11 login extensions etc)

> What is working now is:
> - key generation (as pass-phrase) using smartcard/token hardware RNG

- you can already provide pre-generated key to cryp_format API call,
what missing here?

> - encrypt a backup of the key using certificate from token upon 'luksFormat'

Do you know volume_key project? It seems to me that this is better place for
key escrow functionality. https://fedorahosted.org/volume_key/
(You can ask author, he will be for sure interested in this.)

> - decrypt key from file using privatekey from token upon 'luksOpen'

So this is the core problem, for now, I would use some wrapper or simple
tool based on libcryptsetup. Later it can be specific handler for new
LUKS2 keyslot type.

> 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 :) 

You approach is good for prototyping but for long term it would be nice to have some supportable code.
I would definitely not recommend use such modified tool in production phase.
(And if you will distrbute modified tool, you have to provide source code
in all cases, it is GPL code. If it is github or Googlecode is cosmetic detail,
it is just a tool :-)

Milan