Hi Kernel Crypto folks,
I've got a question about the Kernel Crypto API.
I'm working on adding a cryptographic backend based on the Kernel Crypto
API to Sequoia PGP [0][1]. Sequoia supports several cryptographical
backends already but using Kernel Crypto would allow us to significantly
reduce dependencies when running on Linux.
After implementing hashes, AEAD encryption and symmetric ciphers, I
noticed that the libkcapi API for asymmetric ciphers (and ECDH) is not
working. The libkcapi maintainer kindly explained [2] that the patches
that they proposed for inclusion in the kernel [3] were not merged.
I looked up the relevant thread [4], read it thoroughly and from what I
can see most of the arguments are about private keys not being
sufficiently protected and extensibility concerns with regards to keys
stored in hardware security modules (TPMs etc.).
However, these are mostly irrelevant to the Sequoia PGP use case, since
private keys in software that we read do not need additional protection
(as they are available for software anyway). We'd still like to use them
for signing, decryption, verification and encryption. As for keys stored
in HSMs we handle access to them in userland via our keystore module [5].
My question is: Would it be possible to revisit the decision to expose
operations with asymmetric keys (including ECDH) in Linux Crypto thus
allowing libkcapi to work with non-patched kernels?
I'd like to help make this happen and I think there are other projects
that are interested in a complete cryptographic suite of Kernel Crypto
functions available in user-land.
Thank you for your time!
Kind regards,
Wiktor
[0]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/1030
[1]:
https://lists.sequoia-pgp.org/hyperkitty/list/[email protected]/thread/ZU64CWYZ26OH5TH6PR3BBLDYDDZ6COLH/
[2]: https://github.com/smuellerDD/libkcapi/issues/164
[3]:
https://github.com/smuellerDD/libkcapi/blob/master/kernel-patches/4.15-rc3/asym/v10-0000-cover-letter.patch
[4]:
https://lkml.kernel.org/lkml/[email protected]/T/#m0dfdbd363d4419c7a2470ef884a33dbb250b6df1
[5]: https://gitlab.com/sequoia-pgp/sequoia-keystore
On Thu, 27 Jul 2023 at 14:59, Wiktor Kwapisiewicz <[email protected]> wrote:
>
> Hi Kernel Crypto folks,
>
> I've got a question about the Kernel Crypto API.
>
> I'm working on adding a cryptographic backend based on the Kernel Crypto
> API to Sequoia PGP [0][1]. Sequoia supports several cryptographical
> backends already but using Kernel Crypto would allow us to significantly
> reduce dependencies when running on Linux.
>
> After implementing hashes, AEAD encryption and symmetric ciphers, I
> noticed that the libkcapi API for asymmetric ciphers (and ECDH) is not
> working. The libkcapi maintainer kindly explained [2] that the patches
> that they proposed for inclusion in the kernel [3] were not merged.
>
> I looked up the relevant thread [4], read it thoroughly and from what I
> can see most of the arguments are about private keys not being
> sufficiently protected and extensibility concerns with regards to keys
> stored in hardware security modules (TPMs etc.).
>
> However, these are mostly irrelevant to the Sequoia PGP use case, since
> private keys in software that we read do not need additional protection
> (as they are available for software anyway). We'd still like to use them
> for signing, decryption, verification and encryption. As for keys stored
> in HSMs we handle access to them in userland via our keystore module [5].
>
> My question is: Would it be possible to revisit the decision to expose
> operations with asymmetric keys (including ECDH) in Linux Crypto thus
> allowing libkcapi to work with non-patched kernels?
>
> I'd like to help make this happen and I think there are other projects
> that are interested in a complete cryptographic suite of Kernel Crypto
> functions available in user-land.
>
AF_ALG was never intended to provide a general purpose crypto library
to user space, but only to expose asynchronous hardware crypto
accelerators that are DMA based and managed by the OS.
Exposing the pure-software crypto implementations via AF_ALG was a
mistake IMHO. Making system calls into a privileged environment just
to run some algorithm that could easily run unprivileged as well is a
bad idea both for performance as well as for security/robustness. (On
top of that, SIMD based implementations need to execute with
preemption disabled, increasing scheduling jitter)
Due to the kernel's rigid 'no regressions' policy, AF_ALG will retain
support for the modes and algorithms it supports today, but I don't
think we should extend this support unless we limit it to
implementations provided by hardware accelerators. If it can be done
in software, it should be done in user space, not in the kernel.
On 29.07.2023 10:40, Ard Biesheuvel wrote:
> AF_ALG was never intended to provide a general purpose crypto library
> to user space, but only to expose asynchronous hardware crypto
> accelerators that are DMA based and managed by the OS.
>
> Exposing the pure-software crypto implementations via AF_ALG was a
> mistake IMHO. Making system calls into a privileged environment just
> to run some algorithm that could easily run unprivileged as well is a
> bad idea both for performance as well as for security/robustness. (On
> top of that, SIMD based implementations need to execute with
> preemption disabled, increasing scheduling jitter)
>
> Due to the kernel's rigid 'no regressions' policy, AF_ALG will retain
> support for the modes and algorithms it supports today, but I don't
> think we should extend this support unless we limit it to
> implementations provided by hardware accelerators. If it can be done
> in software, it should be done in user space, not in the kernel.
Thank you for the detailed explanation Ard. This makes sense to me.
I did a quick lookup for hardware crypto accelerators available on the
market and, indeed, symmetric algorithms along with hashes constitute
the vast majority of what these accelerators support [0].
I've found some accelerators that support asymmetric operations but it
seems they are mostly targeted at microcontrollers and as such are
probably outside of supported area here [1][2]. (The accelerator at [0]
supports asymmetric operations but only public key ones).
[0]: https://www.rambus.com/security/crypto-accelerator-cores/
[1]:
https://www.ibm.com/docs/en/ztpf/2020?topic=cryptography-hardware-accelerators-perform-rsa-operations
[2]: https://www.nxp.com/docs/en/application-note/AN12445.pdf