[dm-crypt] PKCS#11 support in cryptsetup

[dm-crypt] PKCS#11 support in cryptsetup

[Johanna A]

I am aware that this has been previously discussed in the following threads:
http://www.saout.de/pipermail/dm-crypt/2013-May/003329.html
http://www.saout.de/pipermail/dm-crypt/2015-April/004667.html

I have been working on bringing PKCS#11 support to systemd's
"cryptsetup" (that uses libcryptsetup). However, maintainers of
systemd has suggested that cryptsetup may be a better place for this
functionality.

The relevant discussions on systemd are:
https://github.com/systemd/systemd/pull/2776
https://github.com/systemd/systemd/pull/3007

In a comment to the last pull request I suggest adding pkcs#11 support
in cryptsetup in a similar way as to how keyfiles are handled. In a
way keyfiles and pkcs#11 data objects are quite similar. Both are
accessiable via an URI (https://tools.ietf.org/html/rfc7512), both can
be read depending on size or until EOF.

The main problem is that pkcs#11 are accessed through a provider,
rather than a filesystem. Providers are not included in the kernel and
as such are less "accessible". I have tried to find a standard way of
enumerating providers in UNIX systems but unfortunately there seems to
be none. The closest seem to be p11-kit
(https://p11-glue.freedesktop.org/p11-kit.html).
I would suggest that the solution to this would be to accept a
provider through arguments.

What are your thoughts on this?

Re: [dm-crypt] PKCS#11 support in cryptsetup

[Michael Kjörling]

On 7 May 2016 09:03 +0200, from johanna-a@mjao.org (Johanna A):
> The main problem is that pkcs#11 are accessed through a provider,
> rather than a filesystem. Providers are not included in the kernel and
> as such are less "accessible".

Maybe I'm missing something, but could you please elaborate a bit on
why the filesystem cannot act as such a provider?

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] PKCS#11 support in cryptsetup

[Johanna A]

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

Re: [dm-crypt] PKCS#11 support in cryptsetup

[Milan Broz]

On 05/07/2016 09:03 AM, Johanna A wrote:

> In a comment to the last pull request I suggest adding pkcs#11 support
> in cryptsetup in a similar way as to how keyfiles are handled. In a
> way keyfiles and pkcs#11 data objects are quite similar. Both are
> accessiable via an URI (https://tools.ietf.org/html/rfc7512), both can
> be read depending on size or until EOF.

Hi,

in new version of LUKS we plan to add some kind of token
support (at least to store some metadata inside LUKS to identify what
token can open particular keyslots and that token will contain
data to open particular keyslot).

Anyway, PKCS#11 is one of example I would like to see to be tested
from the beginning.
What library it should use is another question.

It would be nice if you can create "feature request" issue on cryptsetup
gitlab page (https://gitlab.com/cryptsetup/cryptsetup/issues)
and link your code (and possibly previous discussion) there.

We will return to that later (in guess in 1-2 months, unfortunately...) and
I update the issue there once this happens.

Thanks,
Milan