Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1308415 > unrolled thread

Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type David Howells <dhowells@redhat.com> - 2016-01-13 14:40 +0100
    Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type Tadeusz Struk <tadeusz.struk@intel.com> - 2016-01-13 15:10 +0100
      Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type David Woodhouse <dwmw2@infradead.org> - 2016-01-13 16:10 +0100
        Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type Tadeusz Struk <tadeusz.struk@intel.com> - 2016-01-13 17:20 +0100

#1308415 — Re: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type

Tadeusz Struk <tstruk@gmail.com> wrote:

> +	pkey = keyring->payload.data[asym_crypto];
> +	if (!pkey) {
> +		key_put(keyring);
> +		goto out;
> +	}
> +
> +	err = setkey(private, pkey->key, pkey->keylen);
> +	key_put(keyring);

Note that you may not assume that there's data there that you can use in this
manner.  The key might be a pointer to some hardware device such as a TPM.  I
have a TPM asymmetric subtype in progress.

I think this really needs to be driven from a keyctl() because you need to let
the asymmetric subtype decide how it wants to handle this.  I would suggest
adding KEYCTL_{ASYM_GETINFO,SIGN,VERIFY,ENCRYPT,DECRYPT} - the problem is how
to pass sufficient arguments, how to decrypt the private key and what metadata
needs to be passed vs what is inline with the data.

David

[toc] | [next] | [standalone]

#1308441

Hi David,
On 01/13/2016 05:31 AM, David Howells wrote:
>> > +	pkey = keyring->payload.data[asym_crypto];
>> > +	if (!pkey) {
>> > +		key_put(keyring);
>> > +		goto out;
>> > +	}
>> > +
>> > +	err = setkey(private, pkey->key, pkey->keylen);
>> > +	key_put(keyring);
> Note that you may not assume that there's data there that you can use in this
> manner.  The key might be a pointer to some hardware device such as a TPM.  I
> have a TPM asymmetric subtype in progress.

So is there anything in place that can be used to tell what the key actually is?
The security/integrity/digsig_asymmetric.c is using this api in a similar way, so
if it is incorrect digsig_asymmetric shouldn't work neither.

> 
> I think this really needs to be driven from a keyctl() because you need to let
> the asymmetric subtype decide how it wants to handle this.  I would suggest
> adding KEYCTL_{ASYM_GETINFO,SIGN,VERIFY,ENCRYPT,DECRYPT} - the problem is how
> to pass sufficient arguments, how to decrypt the private key and what metadata
> needs to be passed vs what is inline with the data.

I agree, ideally keyctl should do the job for all the cases and request_key()
should just return a key data.
Thanks,
-- 
TS

[toc] | [prev] | [next] | [standalone]

#1308491

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-01-13 at 06:05 -0800, Tadeusz Struk wrote:
> 
> I agree, ideally keyctl should do the job for all the cases and
> request_key() should just return a key data.

No, you can NOT RELY ON HAVING THE KEY DATA. It might be in hardware.
You might have something which will perform sign/verify/encrypt/decrypt
operations *with* the key at your request, but which can never just
*give* you the key.

Any crypto API which relies on *having* the key is fundamentally wrong.

-- 
dwmw2

[toc] | [prev] | [next] | [standalone]

#1308552

On 01/13/2016 07:06 AM, David Woodhouse wrote:
> On Wed, 2016-01-13 at 06:05 -0800, Tadeusz Struk wrote:
>>
>> I agree, ideally keyctl should do the job for all the cases and
>> request_key() should just return a key data.
> 
> No, you can NOT RELY ON HAVING THE KEY DATA. It might be in hardware.

Ok, I get it now.

> You might have something which will perform sign/verify/encrypt/decrypt
> operations *with* the key at your request, but which can never just
> *give* you the key.
> 
> Any crypto API which relies on *having* the key is fundamentally wrong.
> 

All the crypto APIs out there rely on this.

I think the coupling of an algorithm to its key is the problem here.
Usually an algorithm should be able to work with any (valid) key.

The solution to this can be implemented on the crypto API. 
If the TMP driver would register its supported algorithms on the crypto API
and in the setkey function it would check if a key is a real key or this
"something" (probably a ptr to TMP dev instance?) then in the first
case it would fallback to an implementation that takes a key data.
In the second case it can do its thing whatever it is.

This will make it transparent to the users of both the request_key()
and the crypto API.
Thanks,
-- 
TS

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web