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

Bill Mair cryptsetup at billmairsolutions.ltd.uk
Thu Apr 2 14:50:56 CEST 2015

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



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 at 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 at saout.de http://www.saout.de/mailman/listinfo/dm-crypt 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20150402/c055e447/attachment.html>

More information about the dm-crypt mailing list