Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan,

quoted

quoted

Thanks for the reminder. I have looked at that but I am unsure about
whether this one covers asym crypto appropriately, too.

The issue is that some hardware may only offer accelerators without a full
blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do
you propose to cover raw primitives with keyctl?

where is such a hardware?

Strangely, I see such support all the time in embedded devices where 
asymmetric acceleration is really necessary.

and where are the support patches to integrate them with KPP in the kernel. Maybe we should first have these before exposing anything to userspace.

I said this in another thread before, we have Bluetooth Security Manager which uses ECDH. It has been re-written to use KPP and once we have that fully supporting hardware based ECC key generation and ECDH operation, I would be a lot more confident that we understand how asymmetric crypto accelerators actually do their job. Especially in the embedded world.

quoted

And what is the usage of it? Look at what we are
using asymmetric crypto for at the moment. It is either for sign and verify
with secure boot etc. Or it is for key exchange purposes.

I understand that this is the core purpose of asymmetric ciphers. Yet, 
asymmetric ciphers are complex and we as kernel developers do not know (or 
shall not mandate?) where the complexity shall be implemented. By forcing all 
into the keyctl, we would insist that the entire complexity of the full-blown 
asym cipher is in the kernel without an option that user space may implement 
it.

What we are currently seemingly discuss is the choice of

- keyctl: having all complexity of the entire asym logic including its key 
handling in the kernel with the benefit of the kernel protection of the 
private key

Which we already have anyway since the kernel supports Secure Boot.

- algif_akcipher (maybe with a link to keyctl): only exporting the cipher 
support and allow user space to decide where the complexity lies

Just to give you an example: A full blown RSA operation (excluding the hashing 
part for signatures) consists of padding and the asymmetric operation. For the 
asymmetric operation, we have sign/verify and encrypt/decrypt (keywrap). There 
are a gazillion padding types out there:

- PKCS1

- OAEP

- SP800-56B: RSAEP, RSADP, RSASVE, RSA-OAEP, RSA-KEM-KWS

And there may be others.

When we talk about encryption/decryption we have to consider the KDFs 
(SP800-108, RFC5689, SP800-56A).

When we consider the KDFs, we have to think of the KDF data styles (ASN.1, 
concatenation)

With keyctl to me it seems that we need to integrate all that logic into the 
kernel. As all of that is just processing logic, securing it in the kernel may 
not be the right way as this code does not need the elevated privileges in the 
kernel for that.

The keyring subsystem has extensive user permissions available. Actually that is even more of a reason to not expose anything with private keys via AF_ALG. If I can use AF_ALG to access (meaning use a private key) that I am not suppose to use, then we have a real security nightmare on our hands. The keyring subsystem has permission that can be restricted on a per-thread level.

On a side note, have a look at ELL and how it uses Mat’s crypto tree. For fun look at iwd and how it does WPA-Enterprise with mostly only kernel primitives.

Yet, some hardware may provide some/all of this logic. And we want to make 
that available to user space.

I don’t get the raw access to RSA for example. Nobody uses it in raw mode. There is always some sort of padding involved and needed. Otherwise RSA would be pretty insecure.

It is also funny how RSA centric this is. There is more than RSA since especially ECDH and its friends are getting more and more traction in the IoT spaces. Secure key exchange without the usage of certificates is actually a valid use case as well.

quoted

The asymmetric crypto is a means to an end. If it is not for certification
verification, then it for is creating a symmetric key to be used with a
symmetric cipher. We have the the asymmetric_keys subsystem for
representing the nature of this crypto. Also the list of asymmetric ciphers
is a lot smaller than the symmetric ones.

What raw primitives? When we are using for example ECDH for Bluetooth where
you need to create a pairwise symmetric key, then what you really want from
the cryptographic primitives is this:

1) Create public/private key pair

See above, it is my opinion that with asym ciphers, there is a lot of 
complexity and lots of options. I do not think that the kernel API should be a 
limiting factor here, because the kernel simply does not implement a specific 
cipher type.

What has cipher type to do with this? This confuses me. If the kernel supports any KPP backed algorithm, it should be able to generate key pairs for it. The complexity if the private key is in hardware is not what I care about. Frankly if the public is not leaving the kernel space, that is a huge bonus in my mind. The constant copying and with that securing of keys is always an attack vector.

quoted

2) Give public key to applications and store the private key safely
3) Retrieve public key from remote side and challenge

This assumes that always the Linux kernel is the manager of keys (or the 
gatekeeper to the key store). Are we sure that this is always the case?

Why would it not be? How can you do a better job in userspace? And if you have hardware backend for storage, then it can be easily abstracted with the keyring subsystem. See TPM for example.

Regards

Marcel