ecdh: generation and retention of ecc privkey in kernel/hardware

ecdh: generation and retention of ecc privkey in kernel/hardware

[Tudor Ambarus]

Hi, Herbert,

I'm working with a crypto accelerator that is capable of generating and
retaining ecc private keys in hardware and further use them for ecdh.
The private keys can not be read from the device. This is good because
the less software has access to secrets, the better.

Generation and retention of ecc private keys are also helpful in a user
space to kernel ecdh offload. The privkey can be generated in kernel and 
never revealed to user space.

I propose to extend the ecc software support to allow the generation of
private keys. ECDH software implementation and drivers will permit the
users to provide NULL keys. In this case, the kernel (or the device, if
possible) will generate the ecc private key and further use it for ecdh.

What's your feeling on this?

Thanks,
ta

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

[Marcel Holtmann]

Hi Tudor,

> I'm working with a crypto accelerator that is capable of generating and
> retaining ecc private keys in hardware and further use them for ecdh.
> The private keys can not be read from the device. This is good because
> the less software has access to secrets, the better.
> 
> Generation and retention of ecc private keys are also helpful in a user
> space to kernel ecdh offload. The privkey can be generated in kernel and never revealed to user space.
> 
> I propose to extend the ecc software support to allow the generation of
> private keys. ECDH software implementation and drivers will permit the
> users to provide NULL keys. In this case, the kernel (or the device, if
> possible) will generate the ecc private key and further use it for ecdh.
> 
> What's your feeling on this?

can we represent these keys via keyctl as part of the kernel keyring? I think when it comes to asymmetric crypto and its keys, we need to have these as keys represented in kernel keyring. Recently we added keyctl features to sign, verify, encrypt and decrypt operations.

The crypto subsystem concept is broken when it comes to keys in hardware since it enforces the concept of always being able to fallback on a software implementation of the algorithm.

Regards

Marcel

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

[Stephan Müller]

Am Donnerstag, 27. April 2017, 18:55:13 CEST schrieb Marcel Holtmann:

Hi Marcel,

> Hi Tudor,
> 
> > I'm working with a crypto accelerator that is capable of generating and
> > retaining ecc private keys in hardware and further use them for ecdh.
> > The private keys can not be read from the device. This is good because
> > the less software has access to secrets, the better.
> > 
> > Generation and retention of ecc private keys are also helpful in a user
> > space to kernel ecdh offload. The privkey can be generated in kernel and
> > never revealed to user space.
> > 
> > I propose to extend the ecc software support to allow the generation of
> > private keys. ECDH software implementation and drivers will permit the
> > users to provide NULL keys. In this case, the kernel (or the device, if
> > possible) will generate the ecc private key and further use it for ecdh.
> > 
> > What's your feeling on this?
> 
> can we represent these keys via keyctl as part of the kernel keyring? I
> think when it comes to asymmetric crypto and its keys, we need to have
> these as keys represented in kernel keyring. Recently we added keyctl
> features to sign, verify, encrypt and decrypt operations.

... as well as DH operations :-)

I would think that hardware support would fit into the keys DH framework just 
like it fits seamlessly into the kernel crypto API framework.

> 
> The crypto subsystem concept is broken when it comes to keys in hardware
> since it enforces the concept of always being able to fallback on a
> software implementation of the algorithm.

I do not think this argument is correct. The kernel crypto API requires that a 
key is set with a tfm -- i.e. a tfm is a representation of the "static" parts 
of a cipher instance (key, AAD-length, others). When you have a tfm that is 
ready for a cipher operation, all required data like a key must have been set 
with it. This tfm is now used with a "request" that defines the "volatile" 
data of the cipher operation.

For kpp the kernel crypto API may add one API call to generate a tfm without 
setting a real key, similar to my KPP AF_ALG proposal I aired a couple of days 
ago. Tudor's hardware could generate the key internally, whereas other 
implementations in the kernel could use a logical equivalent as the kpp_genkey 
function in [1].

I.e. if the key is provided by the caller, it should be taken by the tfm. If 
no key is provided or a null is provided, the DH implementation should 
generate the key and retain it with the tfm. That tfm then could be linked to 
by the keys framework.

[1] https://www.spinics.net/lists/linux-crypto/msg25296.html

Ciao
Stephan

PS: Marcel, could you comment on the kpp AF_ALG proposal I sent around some 
days ago? As DH operations are at the same time crypto operations and pure key 
management operations, I am not sure whether DH hardware should be 
externalized with an AF_ALG interface or keys interface. DH is a key 
management cipher type and thus fits with the keys framework, but AF_ALG 
provides an async interface. Further, when DH hardware is used to accelerate 
things like user space TLS / IKE / SSH or whatever, is the keys interface 
complete (think of scatter-gather-list / IOVEC handling offered by AF_ALG)?

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

[Herbert Xu]

On Thu, Apr 27, 2017 at 05:17:58PM +0300, Tudor Ambarus wrote:
> Hi, Herbert,
> 
> I'm working with a crypto accelerator that is capable of generating and
> retaining ecc private keys in hardware and further use them for ecdh.
> The private keys can not be read from the device. This is good because
> the less software has access to secrets, the better.
> 
> Generation and retention of ecc private keys are also helpful in a user
> space to kernel ecdh offload. The privkey can be generated in kernel and
> never revealed to user space.
> 
> I propose to extend the ecc software support to allow the generation of
> private keys. ECDH software implementation and drivers will permit the
> users to provide NULL keys. In this case, the kernel (or the device, if
> possible) will generate the ecc private key and further use it for ecdh.
> 
> What's your feeling on this?

It sounds sane to me.

It does raise the question though whether we need the ability to set the
secret at all.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

[Tudor Ambarus]

On 23.05.2017 06:58, Herbert Xu wrote:
> On Thu, Apr 27, 2017 at 05:17:58PM +0300, Tudor Ambarus wrote:
>> Hi, Herbert,
>>
>> I'm working with a crypto accelerator that is capable of generating and
>> retaining ecc private keys in hardware and further use them for ecdh.
>> The private keys can not be read from the device. This is good because
>> the less software has access to secrets, the better.
>>
>> Generation and retention of ecc private keys are also helpful in a user
>> space to kernel ecdh offload. The privkey can be generated in kernel and
>> never revealed to user space.
>>
>> I propose to extend the ecc software support to allow the generation of
>> private keys. ECDH software implementation and drivers will permit the
>> users to provide NULL keys. In this case, the kernel (or the device, if
>> possible) will generate the ecc private key and further use it for ecdh.
>>
>> What's your feeling on this?
> 
> It sounds sane to me.
> 
> It does raise the question though whether we need the ability to set the
> secret at all.

Ephemeral-Static Mode is a must in rfc2631[1], so the ability of using
a static key pair.

Thanks,
ta

[1]https://www.ietf.org/rfc/rfc2631.txt