On 02/04/15 18:08, Arno Wagner wrote:
> So? LUKS does not add any factor to the authentication. It
> adds convenience functions, anti-forensics and some protection
> for weak passwords.
And it is because of convenience that a weak password will be used more
often than not.
Protecting a strong password that is encrypted and that can be only
unlocked using a private key that is on a token which is pin protected
would be adding extra convenience too.
> 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.
The token requests a PIN to unlock the private key and internally
decrypts the password for the blob, I would classify that as an
authentication agent. Getting the PIN wrong a few times locks up the
token making the key inaccessible.
> 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.
The authentication device is the PIN mechanism of the token, the LUKS
header is, as you said above a convenience mechanism, an easy way to
store the parameters for setting up the device (offsets, encryption
algorithm, hash algorithm, etc.).
> 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.
I don't think that carrying a FIPS-4 device around is really a viable
option either and as you stated they are extremely expensive too.
Effectively, a bad password, remains a bad password and once you have
physical access to a LUKS drive, a fairly simple brute force attack
against such a weak password would probably be easy because there is no
mechanism to invalidate the "key" encoded in the header. You actually
only need the header to assess if you have the correct password that
matches the hash code.
You could say the same about a Crytpo Token but for the fact that
extracting the private key from the token would require some very
expensive equipment and that is out of the reach of most people.
> 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.
I am well aware of what FOSS means.
Knowing how to enter a PIN in a crypto token doesn't require a user to
understand the mechanisms involved, they only have to protect their
token and the PIN.
>> 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.
I fail to see how using a cryto token would degrade the security of the
software, clearly or otherwise.
>> 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 ;-)
Now that is a surprise! ;-)
> 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.
I think that it might be better to do it as a separate project to with
the only dependency being on libcryptsetup.
> 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.
I also think that the libcryptsetup API would only be of limited help in
managing the token information but would be used in it's standard way
once the password has been extracted.
Because the source is available and the LUKS header is well documented,
I don't think that storing information in a key slot as I originally
proposed would break anything.
> Gr"usse,
> Arno
Regards,
Bill
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
