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
