From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNXulAqtxnbS for ; Sun, 19 May 2013 21:10:45 +0200 (CEST) Received: from zimbra.kress-net.com (88-199-169-71.tktelekom.pl [88.199.169.71]) by mail.saout.de (Postfix) with ESMTP for ; Sun, 19 May 2013 21:10:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.kress-net.com (Postfix) with ESMTP id EDA551B6D21 for ; Sun, 19 May 2013 21:02:55 +0200 (CEST) Received: from zimbra.kress-net.com ([127.0.0.1]) by localhost (zimbra.kress-net.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ-iLmaAVHXq for ; Sun, 19 May 2013 21:02:54 +0200 (CEST) Received: from zimbra.kress-net.com (zimbra.kress-net.com [88.199.169.71]) by zimbra.kress-net.com (Postfix) with ESMTP id 68FFF1B6D0C for ; Sun, 19 May 2013 21:02:54 +0200 (CEST) Date: Sun, 19 May 2013 21:02:53 +0200 (CEST) From: Krzysztof Rutecki Message-ID: <28381984.12246.1368990173659.JavaMail.root@zimbra.kress-net.com> In-Reply-To: <13728200.12238.1368989649950.JavaMail.root@zimbra.kress-net.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12245_21052318.1368990173658" Subject: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de ------=_Part_12245_21052318.1368990173658 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 ------=_Part_12245_21052318.1368990173658 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Hi guys

I`m new here. The purpose of this email is PKCS#11 sup= port 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 t= oken,

retrieve upon 'luksOpen' operation based on PIN only.

<= font face=3D"times new roman, new york, times, serif">

What is working now= is:

- = encrypt a backup of the key using certificate from token upon 'luksFormat'<= /font>

- d= ecrypt key from file using privatekey from token upon 'luksOpen'

- all above e= xtansions are build in into cryptsetup command (few new switches)

- depen= dencies are minimal - only pkcs11 library file for token is required (no li= bp11 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 PK= CS#11 support in cryptsetup needed? If yes, please give me any

possible hint c= an help. Or suggestion what or how to implement to make it secure.

RegardsKrzysztof Rutecki

------=_Part_12245_21052318.1368990173658-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9m1whqgwcsC for ; Mon, 20 May 2013 04:31:10 +0200 (CEST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 20 May 2013 04:31:10 +0200 (CEST) Received: by mail-ie0-f174.google.com with SMTP id 10so12694247ied.19 for ; Sun, 19 May 2013 19:31:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <28381984.12246.1368990173659.JavaMail.root@zimbra.kress-net.com> References: <13728200.12238.1368989649950.JavaMail.root@zimbra.kress-net.com> <28381984.12246.1368990173659.JavaMail.root@zimbra.kress-net.com> From: ".. ink .." Date: Sun, 19 May 2013 22:30:47 -0400 Message-ID: Content-Type: multipart/alternative; boundary=f46d04430300fe455a04dd1d1fc4 Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Krzysztof Rutecki Cc: dm-crypt@saout.de --f46d04430300fe455a04dd1d1fc4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 19, 2013 at 3:02 PM, Krzysztof Rutecki 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? --f46d04430300fe455a04dd1d1fc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

= Hi guys

I`m new here. The=A0purpose=A0of this email is PKCS#11 support in cryptsetup = I`m working on.

In short: I need t= o encrypt disk with LUKS and store key on PKCS#11 compatible device. I now<= /font>

there is a lot = of example how to do this using gnupgp or openssl. =A0The goal is to have k= ey only on token,

retrieve upon 'luksOpen' operation based on PIN only= .

=A0

i want to add the same functionali= ty in my project hosted at: http://code.google.com/p/zulucrypt/ but i dont have the hardware to im= plement it on.

are you making a proprietary or a FOSS solution?,if FOSS,where do you h= ost your sources?

--f46d04430300fe455a04dd1d1fc4-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kC5BpbaQ0yX for ; Mon, 20 May 2013 09:22:49 +0200 (CEST) Received: from zimbra.kress-net.com (88-199-169-71.tktelekom.pl [88.199.169.71]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 20 May 2013 09:22:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.kress-net.com (Postfix) with ESMTP id 5ED0C1B69C0 for ; Mon, 20 May 2013 09:22:48 +0200 (CEST) Received: from zimbra.kress-net.com ([127.0.0.1]) by localhost (zimbra.kress-net.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdwN4E+NzUx2 for ; Mon, 20 May 2013 09:22:47 +0200 (CEST) Received: from zimbra.kress-net.com (zimbra.kress-net.com [88.199.169.71]) by zimbra.kress-net.com (Postfix) with ESMTP id 9B6641B698E for ; Mon, 20 May 2013 09:22:47 +0200 (CEST) Date: Mon, 20 May 2013 09:22:47 +0200 (CEST) From: Krzysztof Rutecki Message-ID: <2491870.12591.1369034567557.JavaMail.root@zimbra.kress-net.com> In-Reply-To: <10488515.12587.1369034490360.JavaMail.root@zimbra.kress-net.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12590_24350919.1369034567556" Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de ------=_Part_12590_24350919.1369034567556 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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? ------=_Part_12590_24350919.1369034567556 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>

Hi

Since today all modifications to cryptsetu= p are my own usage only. I will clean a code and open repo somewhere (GitHu= b probab= ly= ).

And ye= s, it will be open source. I have few crypto cards (CyrptoTech, ACS and Gem= alto) and two readers. At beginning its ok.

Soon I will get few tokens (USB de= vices, in operation it looks like reader and card all-in-one). As my modifi= cation are only extensions

I plan to release it in to versions: inte= grated 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 crypt= setup I`m working on.

In short: I need t= o encrypt disk with LUKS and store key on PKCS#11 compatible device. I now<= /font>

there is a lot = of example how to do this using gnupgp or openssl. The goal is to hav= e key only on token,
retrieve upon 'luksOpen' operation based on PIN only.

i want to add the same function= ality in my project hosted at: http://code.google.com/p/zulucrypt/ but i dont ha= ve the hardware to implement it on.

are you making a proprietary or a FOSS solution?,if FOSS,where do you h= ost your sources?

------=_Part_12590_24350919.1369034567556-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzhaGVA4YpMV for ; Mon, 20 May 2013 10:16:25 +0200 (CEST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 20 May 2013 10:16:24 +0200 (CEST) Received: by mail-ie0-f182.google.com with SMTP id a14so13204493iee.41 for ; Mon, 20 May 2013 01:16:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <10488515.12587.1369034490360.JavaMail.root@zimbra.kress-net.com> References: <10488515.12587.1369034490360.JavaMail.root@zimbra.kress-net.com> From: ".. ink .." Date: Mon, 20 May 2013 04:16:01 -0400 Message-ID: Content-Type: multipart/alternative; boundary=e89a8ffbad89a4b49304dd21f2b2 Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Krzysztof Rutecki , dm-crypt@saout.de --e89a8ffbad89a4b49304dd21f2b2 Content-Type: text/plain; charset=ISO-8859-1 > 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. --e89a8ffbad89a4b49304dd21f2b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 ser= iousness,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 d= esigned 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 pro= ject in both and i use them equally.

Those in authority will give yo= u an authoritative answer so take what i am about to say as merely toothles= s speculations.I think the answer you will get to your request to patch cry= ptsetup to add functionality you seek is "NO" and the reason give= n will be that the kind functionality you are seeking lives above cryptsetu= p 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.=

--e89a8ffbad89a4b49304dd21f2b2-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYaQUnUT5BNQ for ; Mon, 20 May 2013 10:41:57 +0200 (CEST) Received: from zimbra.kress-net.com (88-199-169-71.tktelekom.pl [88.199.169.71]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 20 May 2013 10:41:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.kress-net.com (Postfix) with ESMTP id 8015F1B6E4B for ; Mon, 20 May 2013 10:41:56 +0200 (CEST) Received: from zimbra.kress-net.com ([127.0.0.1]) by localhost (zimbra.kress-net.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INAEOWfuLsCK for ; Mon, 20 May 2013 10:41:54 +0200 (CEST) Received: from zimbra.kress-net.com (zimbra.kress-net.com [88.199.169.71]) by zimbra.kress-net.com (Postfix) with ESMTP id 84C441B6B06 for ; Mon, 20 May 2013 10:41:54 +0200 (CEST) Date: Mon, 20 May 2013 10:41:54 +0200 (CEST) From: Krzysztof Rutecki Message-ID: <32903421.12967.1369039314290.JavaMail.root@zimbra.kress-net.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12966_28585214.1369039314289" Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de ------=_Part_12966_28585214.1369039314289 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 ------=_Part_12966_28585214.1369039314289 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Hi

The reason I`m doing it is to have a solution where pa= ssphrase 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 lea= kage e.g. where drive is being replace for new one under warranty

condition? W= ith MooseFS (btw an excellent tool), LUKS, passprase on crypto card/token a= nd 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 admin= s never see key(s). Using now available

methods (gnupgp or pkcs11-data) you ca= n easlly modify scripts to dump passphrase or keyfile. I want to minimize i= t.

fork from it to my ve= rsion. Community can see what cams from and how.

<= font face=3D"times new roman, new york, times, serif">Anyway lots of job to= be done before code will be ready to place on public repo.It will be, mayb= e in next 2-3 weeks. If you are interested, good and help full source of sm= artcards is

SmartCardsFocus. Thanks guys for help with ACOS5-6= 4 cards! RSA4096 is finally working well under PKCS#11. Good job.

RegardsKrzysztof Rutecki

------=_Part_12966_28585214.1369039314289-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feKugS3Nws4b for ; Mon, 20 May 2013 11:09:13 +0200 (CEST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 20 May 2013 11:09:13 +0200 (CEST) Received: by mail-ie0-f182.google.com with SMTP id a14so13276861iee.41 for ; Mon, 20 May 2013 02:09:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <32903421.12967.1369039314290.JavaMail.root@zimbra.kress-net.com> References: <32903421.12967.1369039314290.JavaMail.root@zimbra.kress-net.com> From: ".. ink .." Date: Mon, 20 May 2013 05:08:51 -0400 Message-ID: Content-Type: multipart/alternative; boundary=e89a8ffbad89969b9304dd22af34 Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Krzysztof Rutecki , dm-crypt@saout.de --e89a8ffbad89969b9304dd22af34 Content-Type: text/plain; charset=ISO-8859-1 > 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 --e89a8ffbad89969b9304dd22af34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Imagine you hav= e servers with 24 bays and few root=A0administrators. What is a chance of d= isk 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 sam= e way or classic, just for backup) and sys admins never see key(s). Using n= ow available

methods (gnupgp= or pkcs11-data) you can easlly modify scripts to dump passphrase or keyfil= e. I want to minimize it.

=A0

I do not thin= k 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 solu= tion.As users with root privileges,they are effectively GODS and there is n= othing 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 lib= raries you can interface with, most tokens ships with libraries that talks = to the hardware too or generic ones exists.Why not use cryptsetup library a= nd the=A0 library provided by the hardware and add some logic btw them in y= our binary or library.

The library interface should be enough,have you looked at it and de= termined its not adequate? how is it not adequate if you have?

[1]http://w= iki.cryptsetup.googlecode.com/git/API/index.html
--e89a8ffbad89969b9304dd22af34-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czXO4lbIxZO1 for ; Mon, 20 May 2013 14:48:44 +0200 (CEST) Received: from v6.tansi.org (unknown [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 20 May 2013 14:48:43 +0200 (CEST) Received: from gatewagner.dyndns.org (84-72-142-22.dclient.hispeed.ch [84.72.142.22]) by v6.tansi.org (Postfix) with ESMTPA id 145BB20DC250 for ; Mon, 20 May 2013 14:48:43 +0200 (CEST) Date: Mon, 20 May 2013 14:48:42 +0200 From: Arno Wagner Message-ID: <20130520124842.GA22384@tansi.org> References: <32903421.12967.1369039314290.JavaMail.root@zimbra.kress-net.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxib1862An6p for ; Mon, 20 May 2013 16:56:28 +0200 (CEST) Received: from zimbra.kress-net.com (88-199-169-71.tktelekom.pl [88.199.169.71]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 20 May 2013 16:56:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.kress-net.com (Postfix) with ESMTP id 353881B6CD4 for ; Mon, 20 May 2013 16:56:28 +0200 (CEST) Received: from zimbra.kress-net.com ([127.0.0.1]) by localhost (zimbra.kress-net.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3Dz6xjEXr1v for ; Mon, 20 May 2013 16:56:24 +0200 (CEST) Received: from zimbra.kress-net.com (zimbra.kress-net.com [88.199.169.71]) by zimbra.kress-net.com (Postfix) with ESMTP id D8F631B6DA1 for ; Mon, 20 May 2013 16:56:23 +0200 (CEST) Date: Mon, 20 May 2013 16:56:23 +0200 (CEST) From: Krzysztof Rutecki Message-ID: <10655313.14414.1369061783311.JavaMail.root@zimbra.kress-net.com> In-Reply-To: <20130520124842.GA22384@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 n= atural. 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=20 library). Anyway, out job is quite advanced and will be finished. I will open source = it and we will see. If anybody=20 have any suggestion related with dm-crypt and crypto cards/token over PKCS1= 1 comments are welcome. Maybe something interested can be added :)=20 Or maybe all the tasks here are just wasting our time :) Regards Krzysztof Rutecki=20 ----- Oryginalna wiadomo=C5=9B=C4=87 ----- Od: "Arno Wagner" Do: dm-crypt@saout.de Wys=C5=82ane: poniedzia=C5=82ek, 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? =20 If one of the root-people is corrupt, then high. There really is not way around that except changing the crypto-architecture, see=20 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 authenticatio= n > > device. Am I thinking correctly? =20 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 minimiz= e > > 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.=20 The only solution for disk encryption I see is to use raw storage=20 and encrypt in a dedicated HSM that the admins cannot get into.=20 Something like this: ------->|filesystem front-end|---------->|HSM|--->|Raw/NFS storage| clients NFS or =20 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=20 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=20 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 i= n > with root's credentials. It is possible to hide the passphrase, but that does not help much,=20 as it is fundamentally impossible to hide the master-key from root.=20 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.=20 > If they can modify scripts,they can replace your > binary solution.As users with root privileges,they are effectively GODS a= nd > 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. =20 > You can use libraries if you worry about leakage from loose boundaries bt= w > different binaries and scripts. >=20 > cryptsetup ships with a library you can interface with[1],the two binarie= s > you have mentioned also have libraries you can interface with, most token= s > 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. =20 > The library interface should be enough,have you looked at it and determin= ed > its not adequate? how is it not adequate if you have? >=20 > [1]http://wiki.cryptsetup.googlecode.com/git/API/index.html I think you shgould try for this. Far easier than maintainoing a patch-set.=20 Arno --=20 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV41fj998SvC for ; Mon, 20 May 2013 18:13:09 +0200 (CEST) Received: from v6.tansi.org (unknown [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 20 May 2013 18:13:08 +0200 (CEST) Received: from gatewagner.dyndns.org (84-72-142-22.dclient.hispeed.ch [84.72.142.22]) by v6.tansi.org (Postfix) with ESMTPA id BA8C120DC250 for ; Mon, 20 May 2013 18:13:07 +0200 (CEST) Date: Mon, 20 May 2013 18:13:07 +0200 From: Arno Wagner Message-ID: <20130520161307.GB25429@tansi.org> References: <20130520124842.GA22384@tansi.org> <10655313.14414.1369061783311.JavaMail.root@zimbra.kress-net.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10655313.14414.1369061783311.JavaMail.root@zimbra.kress-net.com> Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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" > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSTKg0ID8i5L for ; Mon, 20 May 2013 21:03:23 +0200 (CEST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 20 May 2013 21:03:23 +0200 (CEST) Received: by mail-ea0-f171.google.com with SMTP id b15so4246396eae.16 for ; Mon, 20 May 2013 12:03:22 -0700 (PDT) Message-ID: <519A7363.2030205@gmail.com> Date: Mon, 20 May 2013 21:02:59 +0200 From: Milan Broz MIME-Version: 1.0 References: <10655313.14414.1369061783311.JavaMail.root@zimbra.kress-net.com> In-Reply-To: <10655313.14414.1369061783311.JavaMail.root@zimbra.kress-net.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] cryptsetup with native PKCS#11 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Krzysztof Rutecki Cc: dm-crypt@saout.de 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