Hi Stephan,

>> So if a server has public/private key pair, then the first thing that should
>> the server do is load this key pair into the kernel and retrieve a key
>> serial for it. And then use this key id to derive the session key. That
>> session key can then be used with AF_ALG and skcipher for the data
>> shoveling.
>> 
>> However that all said, the keys should never leave the kernel. Neither the
> 
> I personally do not fully agree here. For our day-to-day desktops and servers 
> I would fully and completely agree. But I see other use cases of Linux in 
> routers or other embedded systems where there may be other checks and 
> balances 
> in place where this hard demand is not warranted.

actually in embedded devices (especially the tiny IoT stuff I am looking after) 
I really want keys in a central place and do not have to copy them around all 
the time. Keeping keys secure is actually a hard job. Doing that multiple 
places in the kernel and in userspace seems not a good idea. Especially not for 
an embedded device.

The keys subsystem is great since it includes access control to your keys. If 
you have the right permissions you can get the keys back out if you want to. 
However if the key is locked down, you will not be able to read it again.

I mean the keys subsystem can operate on per user, per process and per thread 
keys and access rights. So the policy that you are after is already done nicely 
via the keys subsystem. I really don't think we are limiting anything here. We 
are actually giving users more choice for policy.

> Thus, I feel that this is a policy decision to be made in user space (see my 
> other email -- please answer on that topic there to keep a single thread).
> 
>> private key nor the session key. There is no point in sending keys through
>> userspace. We actually do not want this at all. That is especially
>> important if your actual private/public key pair is in hardware. So maybe
>> your RSA accelerator might expose secure storage for the keys. Loading them
>> over and over again from userspace makes no sense.
>> 
>> As David mentioned, we need to take a deep look at what the userspace API
>> for asymmetric cipher suites (and we also have needs for ECDH etc. and not
>> just RSA) should look like. Just exposing akcipher via AF_ALG is premature.
>> If we expose it now, it is not an API that we can take back. Having two
>> userspace APIs for the exactly the same functionality is a bad thing.
>> Especially if one is limited to software only keys.
> 
> Do not get me wrong, my patch is shall be there for all to comment. I have no 
> issues when we find a better solution. And I also do not like multiple 
> interfaces that would not be needed if we would have thought better.
>> 
>> We also need to look at the larger picture here. And that is TLS support in
>> the kernel. Potentially via AF_KCM or something similar.
> 
> With all due respect, I would object here. When we say yes to TLS (even if it 
> is parts of TLS up to the point where the KDF happens), we invite all higher 
> level crypto implementations: IKE, SNMP, SSH -- I would not want to go down 
> that path that started by simply supporting accelerated asymmetric ciphers.

Reality is that TLS in the kernel is happening. Reality is also that we do 
signing and certificate handling in the kernel. How much of the cipher 
negotiations and key derivation happens in kernel vs userspace is something to 
be still discussed. And there will be userspace involved for sure. However that 
does not mean that we keep moving keys through userspace to just load it back 
into another subsystem. That kind of API really needs to stop.

One other note I make is that we are looking at such tiny systems that 
including OpenSSL or GnuTLS is not an option at all. However we do use secure 
boot and need to be able to handle certificates and TLS.

> Look at user space crypto libs: where is the most fuzz happening? Not in the 
> cipher implementations, but in the network protocols.

Ciphers itself are easy of course. What we are saying here is that we do not 
have the cipher as the main important input on what to do. We have the key 
itself. The key decides what options for ciphers or fallback ciphers we have. 
So let me repeat this, we need to think really hard about supporting hardware 
keys. We need to see the bigger picture. Just looking at ciphers is not enough.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to