On Thu, Apr 02, 2015 at 15:10:22 CEST, Bill Mair wrote: > 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. So? LUKS does not add any factor to the authentication. It adds convenience functions, anti-forensics and some protection for weak passwords. What you forget here is that 2-factor is for _authentication_, not decryption. Authentication needs an active agent on the other side. You do not authenticate versus an encrypted container, you decrypt it. Hence the container (or the header in case of LUKS), becomes a legitimate "somethign you have" if you mis-model it as an authentication scenario. But sure, this is a broken analogy, as is the idea that you can use 2-factor for a storage BLOB in the first place. A BLOB is not a device, it has no agency of its own, while a device you authenticate to certainly has. > 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 And if the LUKS header is on your hardware token, this is exactly what you get. Really, you analogy is flawed, this is not an authentication scenario. > 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. Most of these tokens are only secure if you believe the people that want to sell them to you. The rest is very expensive. The only protection the typical token offers is that it is harder to steal token and laptop in one go, and that many laptop thieves are mostly interested in the hardware in the first place and will only look at exploiting the data on it if it is easy to access. As most people use really bad passwords, that may be the case even on encrypted drives. The token fixes that. So does using a good passphrase. > >> 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. Please look up the definition of FOSS some time. If you want a "turnkey" solution, do one yourself. However most "turnkey" solutions for security cannot deliver what they promise these days, as the user and his/her understanding of the securuty mechanism is critical for them to be secure. > >> 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. Easy to say, exceptionally hard to do. I have seen this fail time and again. And "doesn't always" is just not good enough. Here it clearly does. > > 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. Negative, at least from me ;-) But there really is no need to do so. A separate executable and code-base is entirely fine and the best way to do this. The libcryptsetup API has excellent stability and hence a separate program will be simpler, easier to maintain, and in addition you can do waht you want with it. Also note that the mis-use you propose for the LUKS header has no place in the core project. I am not sure you can even do it via libcryptsetup. Gr"usse, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
