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

Nick Econopouly nickeconopouly at gmail.com
Thu Apr 2 14:38:28 CEST 2015


"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
>> 
>
>-- 
>Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>arno at 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 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/c1f19db7/attachment-0001.html>


More information about the dm-crypt mailing list