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
> 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.
> 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.
>> 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.
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 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.
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 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.
> 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.
> Regards,
> Arno
Regards,
Bill
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
