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."
I've been interested in the hardware tokens you mentioned; are the yubikey and the upcoming nitrokey insecure?
(For 2fa, I assume the gnupg features are more secure because they at least require a pin)
-nick
On April 2, 2015 8:08:48 AM EDT, Arno Wagner <arno@xxxxxxxxxxx> wrote:
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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
