Re: Improving PKCS#11

["Simon McMahon" <Simon_McMahon@xxxxxxxxxxxxxxxxx>]

Denis,

This discussion belongs on the PKCS11 list.

> C_UnwrapKeyCkaExtractableFalse

This adds nothing that isn't already in PKCS11 since the app still has to choose to call this function. Having spent many years in that working group I also know that adding top level functions is usually a last resort for any new feature.

The intent appears to be to map certificate key-usage attributes, for the public key, into PKCS11 key attributes of the private key and make the PKCS11 library do it. Regardless of whether it is appropriate to do that, this is just a new C_Unwrap mechanism and they can be defined in the 'vendor defined' space so this problem already has a solution - or at least a way to do it. If no-one has written such a mechanism then they probably already solved this problem another way. If they have then that mechanism can be promoted to one of the standard mechanisms.

Simon.


Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180


>>> Denis Pinkas <Denis.Pinkas@xxxxxxxx> 05/17/05 10:26pm >>>

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





***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************