[dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Bill Mair]

I have been looking at the format and structure of cryptsetup and the
LUKS header and was wondering if the extension I propose is a sound one
(implementation and cryptographically).

If I have understood the code correctly, the encryption key (32 bytes)
for the block data is encrypted using the password and AF split (4000
times, thus requiring 125KiB) across to 256 sectors, each of which is
512 bytes in size (a total of up to 131072 bytes or 128KiB per key).

I think that using a slot's salt (32 bytes) should be used to identify
the slot as key store for PKCS1 encrypted keys (e.g.
"LUKS_EncryptedKeyStore_PKCS11_v1").

The slot could still have the 0x00AC71F3 signature and the other header
values can remain filled with "normal" LUKS values, but a password would
never be able to deliver the correct key based on the contents of the
KeyStore data.

It is possible to encrypt 214 random bytes of data (password for Slot#1)
using RSA(2048)+PKCS1 padding into a 256 byte block using a X.509 public
key.

The encrypted password would then be saved to a keystore (e.g. Slot#2)
along with a string identifying the key used to encrypt the data,
something like the serialized Id (as used by OpenVPN) and it's length.

I would look something like this:

Slot 1 - Classic LUKS key with a 214 byte password.
Stot 2 - PKCS11 Keystore with multiple PKCS1 encrypted passwords.
Offset Type      Description
     0 uint16_t  Number of keys (n)
   ++2 KeyStruct n key structure

where KeyStruct is:

Offset Type      Description
     0 uint16_t  Key Id Length (l)
     2 char[l]   Key Identifier
   2+l byte[256] RSA+PKCS1 Encryped password

This kind of structure would potentially allow 7 truly random passwords
(214 bytes each) and a KeyStore capable of storing 350+ KeyStructs
(128KiB available per LUKS slot, Serialized IDs of 100 chars and 256
bytes RSA+PKCS11).

When the drive has to be mounted, the available keys in any available
PKCS#11 devices could be compared to those stored in the KeyStore and
used to decrypt the password. The result of the decryption would then be
passed as a "classic" password to the current function for AF merge and
hash checking.

Sadly I have zero knowledge of PKCS#11 programming, otherwise I would
probably being delivering a patch. But I would be willing to learn it
and attempt to implement the above solution if the theory that I have
based the above on proves to be solid.

Pleas let me know what you think of the above proposal.

Thanks.

Bill Mair

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Arno Wagner]

Hi Bill,

the main question is why you would want to do this. 

PKCS11 is public-key crypto. That only makes sense to use 
if you have two parties, a sender (that does not get the 
secret key) and a receiver (that does get the secret key). 
The whole point of pubic-key crypto is that the sender 
only needs authentic information that is not secret to 
send information securely to the receiver.

In disk-encryption you only have one party, and hence 
using public key crypto does not make any sense at all.

If you want to ship a LUKS container, just use PGP to
get the passphrasae to the receiver or encrypt a 
disk-image with PGP in the first place instead of with 
LUKS.

Remember that the foundation of all dependable engineering
is KISS and that applies to secure coding in spades.
Do not add functionality, unless there is a very compelling
reason to do so.

Gr"usse,
Arno 


On Thu, Apr 02, 2015 at 08:18:38 CEST, Bill Mair wrote:
> I have been looking at the format and structure of cryptsetup and the
> LUKS header and was wondering if the extension I propose is a sound one
> (implementation and cryptographically).
> 
> If I have understood the code correctly, the encryption key (32 bytes)
> for the block data is encrypted using the password and AF split (4000
> times, thus requiring 125KiB) across to 256 sectors, each of which is
> 512 bytes in size (a total of up to 131072 bytes or 128KiB per key).
> 
> I think that using a slot's salt (32 bytes) should be used to identify
> the slot as key store for PKCS1 encrypted keys (e.g.
> "LUKS_EncryptedKeyStore_PKCS11_v1").
> 
> The slot could still have the 0x00AC71F3 signature and the other header
> values can remain filled with "normal" LUKS values, but a password would
> never be able to deliver the correct key based on the contents of the
> KeyStore data.
> 
> It is possible to encrypt 214 random bytes of data (password for Slot#1)
> using RSA(2048)+PKCS1 padding into a 256 byte block using a X.509 public
> key.
> 
> The encrypted password would then be saved to a keystore (e.g. Slot#2)
> along with a string identifying the key used to encrypt the data,
> something like the serialized Id (as used by OpenVPN) and it's length.
> 
> I would look something like this:
> 
> Slot 1 - Classic LUKS key with a 214 byte password.
> Stot 2 - PKCS11 Keystore with multiple PKCS1 encrypted passwords.
> Offset Type      Description
>      0 uint16_t  Number of keys (n)
>    ++2 KeyStruct n key structure
> 
> where KeyStruct is:
> 
> Offset Type      Description
>      0 uint16_t  Key Id Length (l)
>      2 char[l]   Key Identifier
>    2+l byte[256] RSA+PKCS1 Encryped password
> 
> This kind of structure would potentially allow 7 truly random passwords
> (214 bytes each) and a KeyStore capable of storing 350+ KeyStructs
> (128KiB available per LUKS slot, Serialized IDs of 100 chars and 256
> bytes RSA+PKCS11).
> 
> When the drive has to be mounted, the available keys in any available
> PKCS#11 devices could be compared to those stored in the KeyStore and
> used to decrypt the password. The result of the decryption would then be
> passed as a "classic" password to the current function for AF merge and
> hash checking.
> 
> Sadly I have zero knowledge of PKCS#11 programming, otherwise I would
> probably being delivering a patch. But I would be willing to learn it
> and attempt to implement the above solution if the theory that I have
> based the above on proves to be solid.
> 
> Pleas let me know what you think of the above proposal.
> 
> Thanks.
> 
> Bill Mair
> _______________________________________________
> 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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Arno Wagner]

Hi Bill,

[CC'ed to the list, as other people may want to comment too
 and so it gets archived.]

On Thu, Apr 02, 2015 at 12:42:01 CEST, Bill Mair wrote:
> Hi Arno.
> 
> The main driving factor for this proposal is adding two factor
> authentication 

Cryptsetup already has 2-factor authentication in a rather
strong sense: 1. You need a passphrase 2. you need the LUKS
header. Anything beyond that is not the task of cryptsetup.
If you really want two secrets, just use a detached header
as the second one. (Actually, you can make it 3-factor by
requiring possession of the encrypted data in addition, but
that is rathr large and unwieldly, and therefore usually made 
non-secret.)

2-factor authentication is a large field with many dysfunctional
solutions (biometrics, for example, or numerous insecure hardware 
tokens), and no final good solutions are in sight. Hence it is not 
something that has a place in cryptsetup proper, beyond what is 
already there. You can also always treat the passphrase as the secret 
and protect that with your chosen 2-factor authentication scheme. 

> to the drive access not the public key cryptography,
> although that does bring additional benefits in an enterprise environment
> where multiple user's tokens could be granted access to a drive (laptop,
> workstation) via their key.  The system administrator would only require
> the user's public key to grant them access.

Ah, yes. The model where the sysadmin can grant access to data that
he has no access to himself. I have seen a lot of this stupidity 
happen in corporate environments, usually to fulfill some 
non-fulfillable regulatory or policy-requirement. This cannot work
and when you look at the details, you find that it does not work,
but the people responsible do not want to hear that. The fact of the
matter is that in most corporate IT settings, the UNIX admins can
get at anything and without leaving traces too, if they are reasonaby
competent.
 
> There are examples of using a PKCS#15 Data Object on a token being
> extracted to an external file and then being fed to cryptsetup (this
> approach requires a data object on the token per drive).  There are of
> course other examples using various methods to implement two factor
> authentication using tokens, all of which have some kind of command line
> processing.

Yes, and that is the way to do it. "Do one thing and do that one well." 
You can always tie these together using standard UNIX methods.

> Clearly it would be possible to write a "cryptsetup-pkcs11" program that
> does what I propose using libcryptsetup but I think it would be better if
> such a solution was included as build option (something like ./configure
> --enable-pkcs11) in the application's standard build.

I do not see why that would be better. I do believe it would be far
worse as it would increase complexity of cryptsetup for a negligible
gain in functionality and an actual decrease in security (due to said
complexity). 

There is also the question of who creates and maintains that code.
If you do the pkcs11 functionality on top of libcryptsetup, that 
would be your task, an that is how it should be as you are the one
that wants it. 

Regards,
Arno

> 
> Regards,
> 
>    Bill Mair
> 
> On 02/04/15 12:20, Arno Wagner wrote:
> > Hi Bill,
> >
> > the main question is why you would want to do this. 
> >
> > PKCS11 is public-key crypto. That only makes sense to use 
> > if you have two parties, a sender (that does not get the 
> > secret key) and a receiver (that does get the secret key). 
> > The whole point of pubic-key crypto is that the sender 
> > only needs authentic information that is not secret to 
> > send information securely to the receiver.
> >
> > In disk-encryption you only have one party, and hence 
> > using public key crypto does not make any sense at all.
> >
> > If you want to ship a LUKS container, just use PGP to
> > get the passphrasae to the receiver or encrypt a 
> > disk-image with PGP in the first place instead of with 
> > LUKS.
> >
> > Remember that the foundation of all dependable engineering
> > is KISS and that applies to secure coding in spades.
> > Do not add functionality, unless there is a very compelling
> > reason to do so.
> >
> > Gr"usse,
> > Arno 
> >
> >
> > On Thu, Apr 02, 2015 at 08:18:38 CEST, Bill Mair wrote:
> >> I have been looking at the format and structure of cryptsetup and the
> >> LUKS header and was wondering if the extension I propose is a sound one
> >> (implementation and cryptographically).
> >>
> >> If I have understood the code correctly, the encryption key (32 bytes)
> >> for the block data is encrypted using the password and AF split (4000
> >> times, thus requiring 125KiB) across to 256 sectors, each of which is
> >> 512 bytes in size (a total of up to 131072 bytes or 128KiB per key).
> >>
> >> I think that using a slot's salt (32 bytes) should be used to identify
> >> the slot as key store for PKCS1 encrypted keys (e.g.
> >> "LUKS_EncryptedKeyStore_PKCS11_v1").
> >>
> >> The slot could still have the 0x00AC71F3 signature and the other header
> >> values can remain filled with "normal" LUKS values, but a password would
> >> never be able to deliver the correct key based on the contents of the
> >> KeyStore data.
> >>
> >> It is possible to encrypt 214 random bytes of data (password for Slot#1)
> >> using RSA(2048)+PKCS1 padding into a 256 byte block using a X.509 public
> >> key.
> >>
> >> The encrypted password would then be saved to a keystore (e.g. Slot#2)
> >> along with a string identifying the key used to encrypt the data,
> >> something like the serialized Id (as used by OpenVPN) and it's length.
> >>
> >> I would look something like this:
> >>
> >> Slot 1 - Classic LUKS key with a 214 byte password.
> >> Stot 2 - PKCS11 Keystore with multiple PKCS1 encrypted passwords.
> >> Offset Type      Description
> >>      0 uint16_t  Number of keys (n)
> >>    ++2 KeyStruct n key structure
> >>
> >> where KeyStruct is:
> >>
> >> Offset Type      Description
> >>      0 uint16_t  Key Id Length (l)
> >>      2 char[l]   Key Identifier
> >>    2+l byte[256] RSA+PKCS1 Encryped password
> >>
> >> This kind of structure would potentially allow 7 truly random passwords
> >> (214 bytes each) and a KeyStore capable of storing 350+ KeyStructs
> >> (128KiB available per LUKS slot, Serialized IDs of 100 chars and 256
> >> bytes RSA+PKCS11).
> >>
> >> When the drive has to be mounted, the available keys in any available
> >> PKCS#11 devices could be compared to those stored in the KeyStore and
> >> used to decrypt the password. The result of the decryption would then be
> >> passed as a "classic" password to the current function for AF merge and
> >> hash checking.
> >>
> >> Sadly I have zero knowledge of PKCS#11 programming, otherwise I would
> >> probably being delivering a patch. But I would be willing to learn it
> >> and attempt to implement the above solution if the theory that I have
> >> based the above on proves to be solid.
> >>
> >> Pleas let me know what you think of the above proposal.
> >>
> >> Thanks.
> >>
> >> Bill Mair
> >> _______________________________________________
> >> 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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Nick Econopouly]

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

"2-factor authentication is a large field with many dysfunctional
solutions (biometrics, for example, or numerous insecure hardware 
tokens), and no final good solutions are in sight. Hence it is not 
something that has a place in cryptsetup proper, beyond what is 
already there. You can also always treat the passphrase as the secret 
and protect that with your chosen 2-factor authentication scheme."

I've been interested in the hardware tokens you mentioned; are the yubikey and the upcoming nitrokey insecure?
(For 2fa, I assume the gnupg features are more secure because they at least require a pin)

-nick

On April 2, 2015 8:08:48 AM EDT, Arno Wagner <arno@wagner.name> wrote:
>Hi Bill,
>
>[CC'ed to the list, as other people may want to comment too
> and so it gets archived.]
>
>On Thu, Apr 02, 2015 at 12:42:01 CEST, Bill Mair wrote:
>> Hi Arno.
>> 
>> The main driving factor for this proposal is adding two factor
>> authentication 
>
>Cryptsetup already has 2-factor authentication in a rather
>strong sense: 1. You need a passphrase 2. you need the LUKS
>header. Anything beyond that is not the task of cryptsetup.
>If you really want two secrets, just use a detached header
>as the second one. (Actually, you can make it 3-factor by
>requiring possession of the encrypted data in addition, but
>that is rathr large and unwieldly, and therefore usually made 
>non-secret.)
>
>2-factor authentication is a large field with many dysfunctional
>solutions (biometrics, for example, or numerous insecure hardware 
>tokens), and no final good solutions are in sight. Hence it is not 
>something that has a place in cryptsetup proper, beyond what is 
>already there. You can also always treat the passphrase as the secret 
>and protect that with your chosen 2-factor authentication scheme. 
>
>> to the drive access not the public key cryptography,
>> although that does bring additional benefits in an enterprise
>environment
>> where multiple user's tokens could be granted access to a drive
>(laptop,
>> workstation) via their key.  The system administrator would only
>require
>> the user's public key to grant them access.
>
>Ah, yes. The model where the sysadmin can grant access to data that
>he has no access to himself. I have seen a lot of this stupidity 
>happen in corporate environments, usually to fulfill some 
>non-fulfillable regulatory or policy-requirement. This cannot work
>and when you look at the details, you find that it does not work,
>but the people responsible do not want to hear that. The fact of the
>matter is that in most corporate IT settings, the UNIX admins can
>get at anything and without leaving traces too, if they are reasonaby
>competent.
> 
>> There are examples of using a PKCS#15 Data Object on a token being
>> extracted to an external file and then being fed to cryptsetup (this
>> approach requires a data object on the token per drive).  There are
>of
>> course other examples using various methods to implement two factor
>> authentication using tokens, all of which have some kind of command
>line
>> processing.
>
>Yes, and that is the way to do it. "Do one thing and do that one well."
>
>You can always tie these together using standard UNIX methods.
>
>> Clearly it would be possible to write a "cryptsetup-pkcs11" program
>that
>> does what I propose using libcryptsetup but I think it would be
>better if
>> such a solution was included as build option (something like
>./configure
>> --enable-pkcs11) in the application's standard build.
>
>I do not see why that would be better. I do believe it would be far
>worse as it would increase complexity of cryptsetup for a negligible
>gain in functionality and an actual decrease in security (due to said
>complexity). 
>
>There is also the question of who creates and maintains that code.
>If you do the pkcs11 functionality on top of libcryptsetup, that 
>would be your task, an that is how it should be as you are the one
>that wants it. 
>
>Regards,
>Arno
>
>> 
>> Regards,
>> 
>>    Bill Mair
>> 
>> On 02/04/15 12:20, Arno Wagner wrote:
>> > Hi Bill,
>> >
>> > the main question is why you would want to do this. 
>> >
>> > PKCS11 is public-key crypto. That only makes sense to use 
>> > if you have two parties, a sender (that does not get the 
>> > secret key) and a receiver (that does get the secret key). 
>> > The whole point of pubic-key crypto is that the sender 
>> > only needs authentic information that is not secret to 
>> > send information securely to the receiver.
>> >
>> > In disk-encryption you only have one party, and hence 
>> > using public key crypto does not make any sense at all.
>> >
>> > If you want to ship a LUKS container, just use PGP to
>> > get the passphrasae to the receiver or encrypt a 
>> > disk-image with PGP in the first place instead of with 
>> > LUKS.
>> >
>> > Remember that the foundation of all dependable engineering
>> > is KISS and that applies to secure coding in spades.
>> > Do not add functionality, unless there is a very compelling
>> > reason to do so.
>> >
>> > Gr"usse,
>> > Arno 
>> >
>> >
>> > On Thu, Apr 02, 2015 at 08:18:38 CEST, Bill Mair wrote:
>> >> I have been looking at the format and structure of cryptsetup and
>the
>> >> LUKS header and was wondering if the extension I propose is a
>sound one
>> >> (implementation and cryptographically).
>> >>
>> >> If I have understood the code correctly, the encryption key (32
>bytes)
>> >> for the block data is encrypted using the password and AF split
>(4000
>> >> times, thus requiring 125KiB) across to 256 sectors, each of which
>is
>> >> 512 bytes in size (a total of up to 131072 bytes or 128KiB per
>key).
>> >>
>> >> I think that using a slot's salt (32 bytes) should be used to
>identify
>> >> the slot as key store for PKCS1 encrypted keys (e.g.
>> >> "LUKS_EncryptedKeyStore_PKCS11_v1").
>> >>
>> >> The slot could still have the 0x00AC71F3 signature and the other
>header
>> >> values can remain filled with "normal" LUKS values, but a password
>would
>> >> never be able to deliver the correct key based on the contents of
>the
>> >> KeyStore data.
>> >>
>> >> It is possible to encrypt 214 random bytes of data (password for
>Slot#1)
>> >> using RSA(2048)+PKCS1 padding into a 256 byte block using a X.509
>public
>> >> key.
>> >>
>> >> The encrypted password would then be saved to a keystore (e.g.
>Slot#2)
>> >> along with a string identifying the key used to encrypt the data,
>> >> something like the serialized Id (as used by OpenVPN) and it's
>length.
>> >>
>> >> I would look something like this:
>> >>
>> >> Slot 1 - Classic LUKS key with a 214 byte password.
>> >> Stot 2 - PKCS11 Keystore with multiple PKCS1 encrypted passwords.
>> >> Offset Type      Description
>> >>      0 uint16_t  Number of keys (n)
>> >>    ++2 KeyStruct n key structure
>> >>
>> >> where KeyStruct is:
>> >>
>> >> Offset Type      Description
>> >>      0 uint16_t  Key Id Length (l)
>> >>      2 char[l]   Key Identifier
>> >>    2+l byte[256] RSA+PKCS1 Encryped password
>> >>
>> >> This kind of structure would potentially allow 7 truly random
>passwords
>> >> (214 bytes each) and a KeyStore capable of storing 350+ KeyStructs
>> >> (128KiB available per LUKS slot, Serialized IDs of 100 chars and
>256
>> >> bytes RSA+PKCS11).
>> >>
>> >> When the drive has to be mounted, the available keys in any
>available
>> >> PKCS#11 devices could be compared to those stored in the KeyStore
>and
>> >> used to decrypt the password. The result of the decryption would
>then be
>> >> passed as a "classic" password to the current function for AF
>merge and
>> >> hash checking.
>> >>
>> >> Sadly I have zero knowledge of PKCS#11 programming, otherwise I
>would
>> >> probably being delivering a patch. But I would be willing to learn
>it
>> >> and attempt to implement the above solution if the theory that I
>have
>> >> based the above on proves to be solid.
>> >>
>> >> Pleas let me know what you think of the above proposal.
>> >>
>> >> Thanks.
>> >>
>> >> Bill Mair
>> >> _______________________________________________
>> >> 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
>----
>A good decision is based on knowledge and not on numbers. -- Plato
>
>If it's in the news, don't worry about it.  The very definition of 
>"news" is "something that hardly ever happens." -- Bruce Schneier
>_______________________________________________
>dm-crypt mailing list
>dm-crypt@saout.de
>http://www.saout.de/mailman/listinfo/dm-crypt

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

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Bill Mair]

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

Hi Nick,

AFAIK the yubikey is only useful for authentication (it only generates passwords).

The nitrokey on the other hand seems to be a fully fledged cryptographic token that can decrypt, encrypt and generate keys and numbers on the card itself (OpenSC/PKCS11), with the addition of remote user authentication functionality (HOTP & TOTP).

Regards,

   Bill

On 02/04/15 14:38, Nick Econopouly wrote:
> "2-factor authentication is a large field with many dysfunctional
> solutions (biometrics, for example, or numerous insecure hardware
> tokens), and no final good solutions are in sight. Hence it is not
> something that has a place in cryptsetup proper, beyond what is
> already there. You can also always treat the passphrase as the secret
> and protect that with your chosen 2-factor authentication scheme."
>
> I've been interested in the hardware tokens you mentioned; are the yubikey and the upcoming nitrokey insecure?
> (For 2fa, I assume the gnupg features are more secure because they at least require a pin)
>
> -nick
>
> On April 2, 2015 8:08:48 AM EDT, Arno Wagner <arno@wagner.name> wrote:
>
>     Hi Bill,
>
>     [CC'ed to the list, as other people may want to comment too
>      and so it gets archived.]
>
>     On Thu, Apr 02, 2015 at 12:42:01 CEST, Bill Mair wrote:
>
>         Hi Arno. The main driving factor for this proposal is adding two factor authentication 
>
>
>     Cryptsetup already has 2-factor authentication in a rather
>     strong sense: 1. You need a passphrase 2. you need the LUKS
>     header. Anything beyond that is not the task of cryptsetup.
>     If you really want two secrets, just use a detached header
>     as the second one. (Actually, you can make it 3-factor by
>     requiring possession of the encrypted data in addition, but
>     that is rathr large and unwieldly, and therefore usually made 
>     non-secret.)
>
>     2-factor authentication is a large field with many
>     dysfunctional
>     solutions (biometrics, for example, or numerous insecure hardware 
>     tokens), and no final good solutions are in sight. Hence it is not 
>     something that has a place in cryptsetup proper, beyond what is 
>     already there. You can also always treat the passphrase as the secret 
>     and protect that with your chosen 2-factor authentication scheme. 
>
>         to the drive access not the public key cryptography, although that does bring additional benefits in an enterprise environment where multiple user's tokens could be granted access to a drive (laptop, workstation) via their key. The system administrator would only require the user's public key to grant them access. 
>
>
>     Ah, yes. The model where the sysadmin can grant access to data that
>     he has no access to himself. I have seen a lot of
>     this stupidity 
>     happen in corporate environments, usually to fulfill some 
>     non-fulfillable regulatory or policy-requirement. This cannot work
>     and when you look at the details, you find that it does not work,
>     but the people responsible do not want to hear that. The fact of the
>     matter is that in most corporate IT settings, the UNIX admins can
>     get at anything and without leaving traces too, if they are reasonaby
>     competent.
>      
>
>         There are examples of using a PKCS#15 Data Object on a token being extracted to an external file and then being fed to cryptsetup (this approach requires a data object on the token per drive). There are of course other examples using various methods to implement two factor authentication using tokens, all of which have some kind of command line processing. 
>
>
>     Yes, and that is the way to do it. "Do one thing and do that one well." 
>     You can always tie these together using standard UNIX methods.
>
>         Clearly it would be possible to write a "cryptsetup-pkcs11" program that does what I propose using libcryptsetup but I think it would be better if such a solution was included as build option (something like ./configure --enable-pkcs11) in the application's standard build. 
>
>
>     I do not see why that would be better. I do believe it would be far
>     worse as it would increase complexity of cryptsetup for a negligible
>     gain in functionality and an actual decrease in security (due to said
>     complexity). 
>
>     There is also the question of who creates and maintains that code.
>     If you do the pkcs11 functionality on top of libcryptsetup, that 
>     would be your task, an that is how it should be as you are the one
>     that wants it. 
>
>     Regards,
>     Arno
>
>         Regards, Bill Mair On 02/04/15 12:20, Arno Wagner wrote:
>
>             Hi Bill, the main question is why you would want to do this. PKCS11 is public-key crypto. That only makes sense to use if you have two parties, a sender (that does not get the secret key) and a receiver (that does get the secret key). The whole point of pubic-key crypto is that the sender only needs authentic information that is not secret to send information securely to the receiver. In disk-encryption you only have one party, and hence using public key crypto does not make any sense at all. If you want to ship a LUKS container, just use PGP to get the passphrasae to the receiver or encrypt a disk-image with PGP in the first place instead of with LUKS. Remember that the foundation of all dependable engineering is KISS and that applies to secure coding in spades. Do not add functionality, unless there is a very compelling reason to do so. Gr"usse, Arno On Thu, Apr 02, 2015 at 08:18:38 CEST, Bill Mair wrote:
>
>                 I have been looking at the format and structure of cryptsetup and the LUKS header and was wondering if the extension I propose is a sound one (implementation and cryptographically). If I have understood the code correctly, the encryption key (32 bytes) for the block data is encrypted using the password and AF split (4000 times, thus requiring 125KiB) across to 256 sectors, each of which is 512 bytes in size (a total of up to 131072 bytes or 128KiB per key). I think that using a slot's salt (32 bytes) should be used to identify the slot as key store for PKCS1 encrypted keys (e.g. "LUKS_EncryptedKeyStore_PKCS11_v1"). The slot could still have the 0x00AC71F3 signature and the other header values can remain filled with "normal" LUKS values, but a password would never be able to deliver the correct key based on the contents of the KeyStore data. It is possible to encrypt 214 random bytes of data (password for Slot#1) using RSA(2048)+PKCS1 padding into a 256 byte
>                 block using a X.509 public key. The encrypted password would then be saved to a keystore (e.g. Slot#2) along with a string identifying the key used to encrypt the data, something like the serialized Id (as used by OpenVPN) and it's length. I would look something like this: Slot 1 - Classic LUKS key with a 214 byte password. Stot 2 - PKCS11 Keystore with multiple PKCS1 encrypted passwords. Offset Type Description 0 uint16_t Number of keys (n) ++2 KeyStruct n key structure where KeyStruct is: Offset Type Description 0 uint16_t Key Id Length (l) 2 char[l] Key Identifier 2+l byte[256] RSA+PKCS1 Encryped password This kind of structure would potentially allow 7 truly random passwords (214 bytes each) and a KeyStore capable of storing 350+ KeyStructs (128KiB available per LUKS slot, Serialized IDs of 100 chars and 256 bytes RSA+PKCS11). When the drive has to be mounted, the available keys in any available PKCS#11 devices could be compared to those stored in the
>                 KeyStore and used to decrypt the password. The result of the decryption would then be passed as a "classic" password to the current function for AF merge and hash checking. Sadly I have zero knowledge of PKCS#11 programming, otherwise I would probably being delivering a patch. But I would be willing to learn it and attempt to implement the above solution if the theory that I have based the above on proves to be solid. Pleas let me know what you think of the above proposal. Thanks. Bill Mair
>                 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 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


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

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Bill Mair]

Hi,

On 02/04/15 14:08, Arno Wagner wrote:
> Hi Bill,
>
> [CC'ed to the list, as other people may want to comment too
>  and so it gets archived.]
mistakenly replied to you directly, sorry.
> On Thu, Apr 02, 2015 at 12:42:01 CEST, Bill Mair wrote:
>> Hi Arno.
>>
>> The main driving factor for this proposal is adding two factor
>> authentication 
> Cryptsetup already has 2-factor authentication in a rather
> strong sense: 1. You need a passphrase 2. you need the LUKS
> header. Anything beyond that is not the task of cryptsetup.
> If you really want two secrets, just use a detached header
> as the second one. (Actually, you can make it 3-factor by
> requiring possession of the encrypted data in addition, but
> that is rathr large and unwieldly, and therefore usually made 
> non-secret.)
I don't really agree that having the header (the drive) and the password is 2 factor. That would be like saying use raw dm-crypt and forget LUKS all together. If my laptop+password are stolen then that person wouldn't have my hardware token or access to my private key, that is what I understand as 2 factor authentication. Even if they had my smartcard/token they would need to know the PIN to unlock the key and that is locked up after 3 incorrect attempts.
> 2-factor authentication is a large field with many dysfunctional
> solutions (biometrics, for example, or numerous insecure hardware 
> tokens), and no final good solutions are in sight. Hence it is not 
> something that has a place in cryptsetup proper, beyond what is 
> already there. You can also always treat the passphrase as the secret 
> and protect that with your chosen 2-factor authentication scheme.
There are quite a few very secure tokens available and arguing that broken tokens or biometrics have nothing to do with the viability of using a "good" token to store the access key.
>> to the drive access not the public key cryptography,
>> although that does bring additional benefits in an enterprise environment
>> where multiple user's tokens could be granted access to a drive (laptop,
>> workstation) via their key.  The system administrator would only require
>> the user's public key to grant them access.
> Ah, yes. The model where the sysadmin can grant access to data that
> he has no access to himself. I have seen a lot of this stupidity 
> happen in corporate environments, usually to fulfill some 
> non-fulfillable regulatory or policy-requirement. This cannot work
> and when you look at the details, you find that it does not work,
> but the people responsible do not want to hear that. The fact of the
> matter is that in most corporate IT settings, the UNIX admins can
> get at anything and without leaving traces too, if they are reasonaby
> competent.
We all know that an administrator can do just about anything he wants in a system, that is an organisational (almost political! ;-) ) argument.
>> There are examples of using a PKCS#15 Data Object on a token being
>> extracted to an external file and then being fed to cryptsetup (this
>> approach requires a data object on the token per drive).  There are of
>> course other examples using various methods to implement two factor
>> authentication using tokens, all of which have some kind of command line
>> processing.
> Yes, and that is the way to do it. "Do one thing and do that one well." 
> You can always tie these together using standard UNIX methods.
The issue being that it has to be stored somewhere in user space between the steps and that there is no turnkey solution available.
>> Clearly it would be possible to write a "cryptsetup-pkcs11" program that
>> does what I propose using libcryptsetup but I think it would be better if
>> such a solution was included as build option (something like ./configure
>> --enable-pkcs11) in the application's standard build.
> I do not see why that would be better. I do believe it would be far
> worse as it would increase complexity of cryptsetup for a negligible
> gain in functionality and an actual decrease in security (due to said
> complexity). 
The existing functionality would remain untouched and adding functions doesn't always lead to degraded security.
> There is also the question of who creates and maintains that code.
> If you do the pkcs11 functionality on top of libcryptsetup, that 
> would be your task, an that is how it should be as you are the one
> that wants it. 
I fully appreciate that and before I created such a project/application I wanted to find out what the reaction would be to adding and implementing the functionality in the standard program.
> Regards,
> Arno
Regards,

    Bill

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Arno Wagner]

On Thu, Apr 02, 2015 at 14:38:28 CEST, Nick Econopouly wrote:
> "2-factor authentication is a large field with many dysfunctional
> solutions (biometrics, for example, or numerous insecure hardware 
> tokens), and no final good solutions are in sight. Hence it is not 
> something that has a place in cryptsetup proper, beyond what is 
> already there. You can also always treat the passphrase as the secret 
> and protect that with your chosen 2-factor authentication scheme."
> 
> I've been interested in the hardware tokens you mentioned; are the yubikey
> and the upcoming nitrokey insecure?
>
> (For 2fa, I assume the gnupg features are more secure because they at
> least require a pin)
> 
> -nick

The think is that in the past most chipcards were broken, some
in ridiculously simple fashions. At the same time, people do not
realize this. I have even heard some security people call a 
smartcard a "mini-HSM". The problem is that makeing a secure token
is hard and expensive. For example, it needs always-on sensors
that can wipe it in case of attacks on the hardware. 

Sure, a hardware token of any kind usually gives you a significant 
security boost as most people chose insecure passwords, but
that is basically it. If a user uses secure passwords, 2-factor
will just annoy.

Gr"usse,
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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Arno Wagner]

On Thu, Apr 02, 2015 at 15:10:22 CEST, Bill Mair wrote:
> Hi,
> 
> On 02/04/15 14:08, Arno Wagner wrote:
> > Hi Bill,
> >
> > [CC'ed to the list, as other people may want to comment too
> >  and so it gets archived.]
> mistakenly replied to you directly, sorry.
> > On Thu, Apr 02, 2015 at 12:42:01 CEST, Bill Mair wrote:
> >> Hi Arno.
> >>
> >> The main driving factor for this proposal is adding two factor
> >> authentication 
> > Cryptsetup already has 2-factor authentication in a rather
> > strong sense: 1. You need a passphrase 2. you need the LUKS
> > header. Anything beyond that is not the task of cryptsetup.
> > If you really want two secrets, just use a detached header
> > as the second one. (Actually, you can make it 3-factor by
> > requiring possession of the encrypted data in addition, but
> > that is rathr large and unwieldly, and therefore usually made 
> > non-secret.)

> I don't really agree that having the header (the drive) and the password
> is 2 factor.  That would be like saying use raw dm-crypt and forget LUKS
> all together.  

So? LUKS does not add any factor to the authentication. It
adds convenience functions, anti-forensics and some protection
for weak passwords.  

What you forget here is that 2-factor is for _authentication_,
not decryption. Authentication needs an active agent on the other 
side. You do not authenticate versus an encrypted 
container, you decrypt it. Hence the container (or the header
in case of LUKS), becomes a legitimate "somethign you have" if
you mis-model it as an authentication scenario. But sure, this is
a broken analogy, as is the idea that you can use 2-factor for
a storage BLOB in the first place. A BLOB is not a device, it
has no agency of its own, while a device you authenticate to
certainly has.

> If my laptop+password are stolen then that person wouldn't
> have my hardware token or access to my private key, that is what I
> understand as 2 factor authentication.  Even if they had my

And if the LUKS header is on your hardware token, this is exactly
what you get. Really, you analogy is flawed, this is not an 
authentication scenario.

> smartcard/token they would need to know the PIN to unlock the key and that
> is locked up after 3 incorrect attempts.


> > 2-factor authentication is a large field with many dysfunctional
> > solutions (biometrics, for example, or numerous insecure hardware 
> > tokens), and no final good solutions are in sight. Hence it is not 
> > something that has a place in cryptsetup proper, beyond what is 
> > already there. You can also always treat the passphrase as the secret 
> > and protect that with your chosen 2-factor authentication scheme.

> There are quite a few very secure tokens available and arguing that broken
> tokens or biometrics have nothing to do with the viability of using a
> "good" token to store the access key.

Most of these tokens are only secure if you believe the people
that want to sell them to you. The rest is very expensive. 

The only protection the typical token offers is that it is harder
to steal token and laptop in one go, and that many laptop thieves
are mostly interested in the hardware in the first place and will
only look at exploiting the data on it if it is easy to access.
As most people use really bad passwords, that may be the case even
on encrypted drives. The token fixes that. So does using a good 
passphrase.

> >> to the drive access not the public key cryptography,
> >> although that does bring additional benefits in an enterprise environment
> >> where multiple user's tokens could be granted access to a drive (laptop,
> >> workstation) via their key.  The system administrator would only require
> >> the user's public key to grant them access.
> > Ah, yes. The model where the sysadmin can grant access to data that
> > he has no access to himself. I have seen a lot of this stupidity 
> > happen in corporate environments, usually to fulfill some 
> > non-fulfillable regulatory or policy-requirement. This cannot work
> > and when you look at the details, you find that it does not work,
> > but the people responsible do not want to hear that. The fact of the
> > matter is that in most corporate IT settings, the UNIX admins can
> > get at anything and without leaving traces too, if they are reasonaby
> > competent.

> We all know that an administrator can do just about anything he wants in a
> system, that is an organisational (almost political!  ;-) ) argument.

> >> There are examples of using a PKCS#15 Data Object on a token being
> >> extracted to an external file and then being fed to cryptsetup (this
> >> approach requires a data object on the token per drive).  There are of
> >> course other examples using various methods to implement two factor
> >> authentication using tokens, all of which have some kind of command line
> >> processing.
> > Yes, and that is the way to do it. "Do one thing and do that one well." 
> > You can always tie these together using standard UNIX methods.

> The issue being that it has to be stored somewhere in user space between
> the steps and that there is no turnkey solution available.

Please look up the definition of FOSS some time. If you want a 
"turnkey" solution, do one yourself. However most "turnkey" solutions
for security cannot deliver what they promise these days, as the 
user and his/her understanding of the securuty mechanism is critical
for them to be secure. 

> >> Clearly it would be possible to write a "cryptsetup-pkcs11" program that
> >> does what I propose using libcryptsetup but I think it would be better if
> >> such a solution was included as build option (something like ./configure
> >> --enable-pkcs11) in the application's standard build.
> > I do not see why that would be better. I do believe it would be far
> > worse as it would increase complexity of cryptsetup for a negligible
> > gain in functionality and an actual decrease in security (due to said
> > complexity). 

> The existing functionality would remain untouched and adding functions
> doesn't always lead to degraded security.

Easy to say, exceptionally hard to do. I have seen this fail time
and again. And "doesn't always" is just not good enough. Here it clearly
does.

> > There is also the question of who creates and maintains that code.
> > If you do the pkcs11 functionality on top of libcryptsetup, that 
> > would be your task, an that is how it should be as you are the one
> > that wants it. 

> I fully appreciate that and before I created such a project/application I
> wanted to find out what the reaction would be to adding and implementing
> the functionality in the standard program.

Negative, at least from me ;-)

But there really is no need to do so. A separate executable and 
code-base is entirely fine and the best way to do this. The
libcryptsetup API has excellent stability and hence a separate
program will be simpler, easier to maintain, and in addition
you can do waht you want with it.

Also note that the mis-use you propose for the LUKS header has 
no place in the core project. I am not sure you can even do it
via libcryptsetup.

Gr"usse,
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
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards and Tokens)

[Bill Mair]

On 02/04/15 18:08, Arno Wagner wrote:
> So? LUKS does not add any factor to the authentication. It
> adds convenience functions, anti-forensics and some protection
> for weak passwords.  

And it is because of convenience that a weak password will be used more
often than not.

Protecting a strong password that is encrypted and that can be only
unlocked using a private key that is on a token which is pin protected
would be adding extra convenience too.

> What you forget here is that 2-factor is for _authentication_,
> not decryption. Authentication needs an active agent on the other 
> side. You do not authenticate versus an encrypted 
> container, you decrypt it. Hence the container (or the header
> in case of LUKS), becomes a legitimate "somethign you have" if
> you mis-model it as an authentication scenario. But sure, this is
> a broken analogy, as is the idea that you can use 2-factor for
> a storage BLOB in the first place. A BLOB is not a device, it
> has no agency of its own, while a device you authenticate to
> certainly has.

The token requests a PIN to unlock the private key and internally
decrypts the password for the blob, I would classify that as an
authentication agent. Getting the PIN wrong a few times locks up the
token making the key inaccessible.

> And if the LUKS header is on your hardware token, this is exactly
> what you get. Really, you analogy is flawed, this is not an 
> authentication scenario.

The authentication device is the PIN mechanism of the token, the LUKS
header is, as you said above a convenience mechanism, an easy way to
store the parameters for setting up the device (offsets, encryption 
algorithm, hash algorithm, etc.).

> Most of these tokens are only secure if you believe the people that
> want to sell them to you. The rest is very expensive. The only
> protection the typical token offers is that it is harder to steal
> token and laptop in one go, and that many laptop thieves are mostly
> interested in the hardware in the first place and will only look at
> exploiting the data on it if it is easy to access. As most people use
> really bad passwords, that may be the case even on encrypted drives.
> The token fixes that. So does using a good passphrase.

I don't think that carrying a FIPS-4 device around is really a viable
option either and as you stated they are extremely expensive too.

Effectively, a bad password, remains a bad password and once you have
physical access to a LUKS drive, a fairly simple brute force attack
against such a weak password would probably be easy because there is no
mechanism to invalidate the "key" encoded in the header. You actually
only need the header to assess if you have the correct password that
matches the hash code.

You could say the same about a Crytpo Token but for the fact that
extracting the private key from the token would require some very
expensive equipment and that is out of the reach of most people.

> Please look up the definition of FOSS some time. If you want a
> "turnkey" solution, do one yourself. However most "turnkey" solutions
> for security cannot deliver what they promise these days, as the user
> and his/her understanding of the securuty mechanism is critical for
> them to be secure.

I am well aware of what FOSS means.

Knowing how to enter a PIN in a crypto token doesn't require a user to
understand the mechanisms involved, they only have to protect their
token and the PIN.

>> The existing functionality would remain untouched and adding functions
>> doesn't always lead to degraded security.
> Easy to say, exceptionally hard to do. I have seen this fail time
> and again. And "doesn't always" is just not good enough. Here it clearly
> does.

I fail to see how using a cryto token would degrade the security of the
software, clearly or otherwise.

>> I fully appreciate that and before I created such a project/application I
>> wanted to find out what the reaction would be to adding and implementing
>> the functionality in the standard program.
> Negative, at least from me ;-)

Now that is a surprise! ;-)

> But there really is no need to do so. A separate executable and 
> code-base is entirely fine and the best way to do this. The
> libcryptsetup API has excellent stability and hence a separate
> program will be simpler, easier to maintain, and in addition
> you can do waht you want with it.

I think that it might be better to do it as a separate project to with
the only dependency being on libcryptsetup.

> Also note that the mis-use you propose for the LUKS header has 
> no place in the core project. I am not sure you can even do it
> via libcryptsetup.

I also think that the libcryptsetup API would only be of limited help in
managing the token information but would be used in it's standard way
once the password has been extracted.

Because the source is available and the LUKS header is well documented,
I don't think that storing information in a key slot as I originally
proposed would break anything.

> Gr"usse,
> Arno 

Regards,

    Bill