Re: Improving PKCS#11

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Peter,

See my comment at the bottom of this e-mail.

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

> Since the flags are ultimately controlled by the user app (no matter what you
> call them or where you put them), the user app is *always* going to get the
> key if it really wants it.  The only thing that'll stop it is if the hardware
> prevents this (see below).

> > > 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.

> That's merely a request from the software side.  A Fortezza card isn't going
> to give you the key, no matter what you set CKA_EXTRACTABLE to.  Conversely, a
> Cryptoflex (at least the older ones) will always give you the key because it
> only contains a private-key engine (you can't even do public-key encryption
> with it).  So if you try and set the flag in a way that isn't supported by the
> hardware, you'll get a template-inconsistent error (or you may get the object
> created but with the template modified according to the hardware capabilities,
> depending on the implementation).  Ultimately, the crypto hardware gets the
> last word, not an application-set flag.  Unlike PKIX, the PKCS #11 folks are
> somewhat reluctant to set standards requirements that violate the laws of
> physics.


> > 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.

> But again, this depends *entirely* on the calling software.  It doesn't matter
> how you dress this up, if the calling app wants the key, all it has to do is
> call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set
> CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever.  

I did not made my explanations clear enough.

A private key, when generated within the token, would be marked to be usable 
only with C_UnwrapKeyCkaExtractableFalse. So if the application attempts to 
use it with C_UnwrapKey this will fail. This would mean that the certificate 
corresponding to that private key would then be marked with 
keyEncipherment-no-extract.

Denis

> If the
> calling app wants to it can look at the cert, see that keyEncipherment is set
> to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE
> to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse.  There
> is therefore no difference between C_UnwrapKeyCkaExtractableFalse and
> C_UnwrapKey with CKA_EXTRACTABLE set to false.
>
> Peter.