Proposal for support of PKCS#11 devices (SmartCards and Tokens)

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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Hi Arno.

The main driving factor for this proposal is adding two factor authentication

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.

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.

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.

Regards,

Bill Mair

Quoted 95 lines · 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

Quoted 66 lines · 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
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Hi Bill,

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

Quoted 4 lines · Bill Mair

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.

Quoted 2 lines

to the drive access not the public key cryptography, although that does bring additional benefits in an enterprise

environment

Quoted 1 line

where multiple user's tokens could be granted access to a drive

(laptop,

Quoted 1 line

workstation) via their key. The system administrator would only

require

Quoted 1 line

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.

Quoted 3 lines

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

Quoted 2 lines

course other examples using various methods to implement two factor authentication using tokens, all of which have some kind of command

line

Quoted 1 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.

Quoted 1 line

Clearly it would be possible to write a "cryptsetup-pkcs11" program

that

Quoted 1 line

does what I propose using libcryptsetup but I think it would be

better if

Quoted 1 line

such a solution was included as build option (something like

./configure

Quoted 1 line

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

Quoted 36 lines

Regards,

Bill Mair

Quoted 30 lines · 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

Quoted 1 line · Bill Mair

I have been looking at the format and structure of cryptsetup and

the

Quoted 1 line

Quoted 1 line

Quoted 1 line

LUKS header and was wondering if the extension I propose is a

sound one

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

(implementation and cryptographically).

If I have understood the code correctly, the encryption key (32

bytes)

Quoted 1 line

Quoted 1 line

Quoted 1 line

for the block data is encrypted using the password and AF split

(4000

Quoted 1 line

Quoted 1 line

Quoted 1 line

times, thus requiring 125KiB) across to 256 sectors, each of which

is

Quoted 1 line

Quoted 1 line

Quoted 1 line

512 bytes in size (a total of up to 131072 bytes or 128KiB per

key).

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think that using a slot's salt (32 bytes) should be used to

identify

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

values can remain filled with "normal" LUKS values, but a password

would

Quoted 1 line

Quoted 1 line

Quoted 1 line

never be able to deliver the correct key based on the contents of

the

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

KeyStore data.

It is possible to encrypt 214 random bytes of data (password for

Slot#1)

Quoted 1 line

Quoted 1 line

Quoted 1 line

using RSA(2048)+PKCS1 padding into a 256 byte block using a X.509

public

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

key.

The encrypted password would then be saved to a keystore (e.g.

Slot#2)

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

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

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

(214 bytes each) and a KeyStore capable of storing 350+ KeyStructs (128KiB available per LUKS slot, Serialized IDs of 100 chars and

256

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

bytes RSA+PKCS11).

When the drive has to be mounted, the available keys in any

available

Quoted 1 line

Quoted 1 line

Quoted 1 line

PKCS#11 devices could be compared to those stored in the KeyStore

and

Quoted 1 line

Quoted 1 line

Quoted 1 line

used to decrypt the password. The result of the decryption would

then be

Quoted 1 line

Quoted 1 line

Quoted 1 line

passed as a "classic" password to the current function for AF

merge and

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

hash checking.

Sadly I have zero knowledge of PKCS#11 programming, otherwise I

would

Quoted 1 line

Quoted 1 line

Quoted 1 line

probably being delivering a patch. But I would be willing to learn

it

Quoted 1 line

Quoted 1 line

Quoted 1 line

and attempt to implement the above solution if the theory that I

have

Quoted 12 lines

Quoted 11 lines

Quoted 11 lines

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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Signature · 13 lines

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
[email protected]
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

"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 <[email protected]> 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

"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

Hi Bill,

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

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 4 lines

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

Hi,

Quoted 4 lines · Arno Wagner

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.

Quoted 5 lines · Bill Mair

Quoted 4 lines

Hi Arno.

The main driving factor for this proposal is adding two factor authentication

Quoted 8 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 9 lines

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

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.

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.

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.

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.

Quoted 2 lines

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.

Quoted 3 lines

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