On Tue, 2015-10-27 at 11:50 +0100, Stephan Mueller wrote:
quoted
expose that critically limited API to userspace. We need to expose an
API which supports hardware keys, and basically that means using the
kernel's key subsystem.
Agreed. But at the same time, that interface should be able to support the use
case where the software wants to be in control (just take OpenSSL as the
simple example where you can add an engine for the Linux kernel backed RSA
operation).
Absolutely. The interface needs to support *both*.
I've spent a lot of time chasing through userspace stacks, fixing
broken assumptions that we will *always* have the actual key material
in a file — and making libraries and applications accept PKCS#11 URIs
referring to keys in hardware as well as filenames.
I am violently opposed to exposing an API from the kernel which makes
that *same* fundamental mistake, and ties its users to using *only*
software keys.
FROM THE BEGINNING, users of this new API should be able to cope with
the fact that they might not *have* the key material, and that they
might simply be referring to a key which exists elsewhere. Such as in
the TPM, or within an SGX software enclave.
--
dwmw2