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

[Arno Wagner <arno@wagner.name>]

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