On Sat, May 7, 2016 at 9:32 PM, Michael Kjörling <michael at kjorling.se> wrote:
> On 7 May 2016 09:03 +0200, from johanna-a at mjao.org (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.