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 -- 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
