Re: Improving PKCS#11

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Peter,

> > If PKCS#11 gets improved, then we could distinguish between:

> >  keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
> >  keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

> I can't see that ever being added.  If you want to make it unextractable in
> the user app, 

No. The purpose is to make impossible, whatever the user application asks, 
to extract the private key in the clear.

> set the CKA_EXTRACTABLE flag in the key template to false (this
> is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE).  If the hardware makes
> it unextractable (e.g. in Fortezza cards), it'll implicitly set
> CKA_EXTRACTABLE for you.

The hardware cannot do anything since currently the setting of the flag 
CKA_EXTRACTABLE is left to the application.

> There are also practical considerations.  The reason for the common use of
> DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage,
> what'd you'd be asking there is for app developers to break compatibility with
> all existing drivers in exchange for a gain so abstruse that most of them
> won't even understand why it's there.  

I do not think so: the purpose is not to modify any existing command, but to 
add only ONE new one which might be called something like:

C_UnwrapKeyCkaExtractableFalse

where the certificate used to perform the operation would have a key usage 
like: keyEnciphermentNoExtract. This means that the "cryptographic 
material", once decrypted, cannot be extracted.

So there would be no backward compatibility problem.

> An addition, given the longevity of
> crypto hardware devices, even if vendors (for some reason) decided to do this,
> it'd take years for everything to implement it.  

Yes, this may take years, but since this is fairly simple, it might only 
take only a couple of years.  :-)

> Finally, some hardware (e.g.
> many smart cards) can't support this, since all the card can usefully do is
> the private-key op.  

This would apply to new smart cards only.

> As a result the unwrapped key is always extractable from the card, 

Yes, this is the current situation, and hence why we should change it.

Denis

> either because it doesn't do symmetric crypto at all, because it
> does it in a crippled manner that makes it useless (e.g. it zeroes all but 40
> bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or
> even if it does do symmetric crypto, it's so slow that it's unusable.  So
> CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be
> overridden by the hardware.
>
> Peter.