On Sat, May 7, 2016 at 9:32 PM, Michael Kjörling <michael@xxxxxxxxxxx> wrote: > On 7 May 2016 09:03 +0200, from johanna-a@xxxxxxxx (Johanna A): > > Maybe I'm missing something, but could you please elaborate a bit on > why the filesystem cannot act as such a provider? > PKCS#11 (also sometimes called Cryptoki) is a standard (http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm) that by it's nature doesn't lend itself to kernel implementation. I'm not aware of the current status of filesystems in userspace, but I'm thinking that for PKCS#11 a filesystem implementation would be messy at best, and maybe even unstable. The PKCS#11 URI scheme is in some ways not as absolute as filesystem paths, while in other ways, such as properties of an object, far more detailed. Also, unlocking a token by PIN would be cumbersome to implement in a filesystem. My current approach has been to modify systemd to provide the data of a PKCS#11 data object as passphrase. This works, but the systemd maintainers seem reluctant to include that functionality. Philosophically, at least UNIX-wise, this functionality would be better placed I think in cryptsetup or as a wrapper calling libcryptsetup. Making a wrapper would be easier, but including it in cryptsetup would allow for stronger implementations in the future such as a two-way procedure further protecting the key. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
