Message-ID: <551D3FBE.3010802@billmairsolutions.ltd.uk>
Date: Thu, 02 Apr 2015 15:10:22 +0200
From: Bill Mair <cryptsetup@billmairsolutions.ltd.uk>
MIME-Version: 1.0
References: <551CDF3E.4020407@billmairsolutions.ltd.uk>
 <20150402102027.GA18528@tansi.org>
 <551D1CF9.9020502@billmairsolutions.ltd.uk>
 <20150402120848.GC18528@tansi.org>
In-Reply-To: <20150402120848.GC18528@tansi.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dm-crypt] Proposal for support of PKCS#11 devices (SmartCards
 and Tokens)
To: dm-crypt@saout.de

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=20
> 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=20
> 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 a=
ll together. If my laptop+password are stolen then that person wouldn't h=
ave my hardware token or access to my private key, that is what I underst=
and 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=20
> tokens), and no final good solutions are in sight. Hence it is not=20
> something that has a place in cryptsetup proper, beyond what is=20
> already there. You can also always treat the passphrase as the secret=20
> and protect that with your chosen 2-factor authentication scheme.
There are quite a few very secure tokens available and arguing that broke=
n 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 environm=
ent
>> where multiple user's tokens could be granted access to a drive (lapto=
p,
>> workstation) via their key.  The system administrator would only requi=
re
>> 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=20
> happen in corporate environments, usually to fulfill some=20
> 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 li=
ne
>> processing.
> Yes, and that is the way to do it. "Do one thing and do that one well."=
=20
> 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 th=
at
>> does what I propose using libcryptsetup but I think it would be better=
 if
>> such a solution was included as build option (something like ./configu=
re
>> --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).=20
The existing functionality would remain untouched and adding functions do=
esn'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=20
> would be your task, an that is how it should be as you are the one
> that wants it.=20
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