Subject: RE: key usage - key encipherment or data encipherment

From: Stephen Kent <[email-masked]>
Date: Fri, 13 May 2005 09:33:16 -0400

At 11:52 AM +0100 5/13/05, Stefan Santesson wrote:
>How about calling the bits "The encryption bit" and "The other
>encryption bit" :-) 
>
>Jokes aside, can anyone recall the justification for having 2 different
>bits for key and data encryption?

Despite the observation that many folks setting these bits, or 
applications using these bits, don't really know the difference, 
there is a difference. From a security perspective, it can be 
important to know whether the bits being decrypted are data to be 
handed to a user or app, or keys to be kept within the key management 
subsystem. Hence there is a legitimate, security benefit that could 
be obtained IF people set the bits properly.

I am hesitant to have us remove this potentially useful distinction 
merely because folks have not been smart enough to make good use of 
it so far.

Steve

---

From: "Bob Bell" <[email-masked]>
Date: Fri, 13 May 2005 08:41:59 -0600

Stephen - 

Just a question for clarification. Since these bits are located in the
certificate. How does that translate into knowing without knowledge based on
the actual data structure itself that the data encrypted is keying material
or data. It would seem to me that the contextual information based on the
information exchange is more the determiner of what is intended. The bits in
the certificate are to indicate if it is acceptable to use the public key
for the stated purpose. At least that is my understanding. If I am wrong,
please educate me.

Bob Bell

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Friday, May 13, 2005 07:33
> To: Stefan Santesson
> Cc: Simon McMahon; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: key usage - key encipherment or data encipherment
> 
> 
> Despite the observation that many folks setting these bits, 
> or applications using these bits, don't really know the 
> difference, there is a difference. From a security 
> perspective, it can be important to know whether the bits 
> being decrypted are data to be handed to a user or app, or 
> keys to be kept within the key management subsystem. Hence 
> there is a legitimate, security benefit that could be 
> obtained IF people set the bits properly.
> 
> I am hesitant to have us remove this potentially useful 
> distinction merely because folks have not been smart enough 
> to make good use of it so far.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 May 2005 11:20:46 -0400

>for the stated purpose. At least that is my understanding. If I am wrong,
Bob,

I can implement crypto software that never releases the bytes 
decrypted with a private key that appears in a cert which has enabled 
the "keyEncipherment" but not "dataEncipherment" key usage bits. The 
intent is that a peer should never have used the public key to 
encrypt anything but key (or key and associated control info) bits, 
given the marking. In contrast, if the bytes I receive and decrypt 
were encrypted using a public key from a cert that has enabled the 
"dataEncipherment" key usage bit but not the "keyEncipherment" bit, 
then I would expect to hand these bits to an app, and that would be 
bad if they were really key bits.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 May 2005 18:21:56 +0200

Steve,

I wished that what you say would be true, however it isn't. See below.

> I can implement crypto software that never releases the bytes decrypted 
> with a private key that appears in a cert which has enabled the 
> "keyEncipherment" but not "dataEncipherment" key usage bits. The intent 
> is that a peer should never have used the public key to encrypt anything 
> but key (or key and associated control info) bits, given the marking. In 
> contrast, if the bytes I receive and decrypt were encrypted using a 
> public key from a cert that has enabled the "dataEncipherment" key usage 
> bit but not the "keyEncipherment" bit, then I would expect to hand these 
> bits to an app, and that would be bad if they were really key bits.

At this time someone who uses a certificate that has the key usage 
keyEncipherment set cannot know whether the "keying material" can be 
released or not by the receiving application (that owns the private key).

Let us look what PKCS#11 states about the mapping of X.509 key usage
flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP:

Table 35, Mapping of X.509 key usage flags to cryptoki attributes
for private keys

Key usage flags for public keys    Corresponding cryptoki attributes
in X.509 public key certificates   for private keys

dataEncipherment                           CKA_DECRYPT
keyAgreement                               CKA_DERIVE
keyEncipherment                            CKA_UNWRAP

C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private
key or secret key object.

The CKA_UNWRAP attribute of the unwrapping key, which indicates whether
the key supports unwrapping, must be TRUE. The new key will have the
CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE
attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to
TRUE.

   It would be "nice" to be able to distinguish between C_UnwrapKey where
   the secret cannot be extractable and where it can be.

   We would then be able to distinguish between:

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

   I would thus propose to be able to support that distinction.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 13 May 2005 18:49:17 -0700

I concur with Steve's observation.  The potential utility outweighs
current deficiencies.

Mike

-----Original Message-----
From: Stephen Kent
Sent: Friday, May 13, 2005 6:33 AM
>
> . . .
>
> I am hesitant to have us remove this potentially
> useful distinction merely because folks have not
> been smart enough to make good use of it so far.
>
> Steve

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 15 May 2005 20:27:53 +1200

Denis Pinkas <[email-masked]> writes:

>Let us look what PKCS#11 states about the mapping of X.509 key usage flags to
>cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP:

Note that this usage is entirely dependent on the user.  PKCS #11 sets no
constraints based on the cert contents.  Experience has shown that the PKCS
#11 flags set by the user often bear no relation to the key flags in the cert,
with keys with signature-only certs being usable for encryption and vice
versa.  It's not small-scale stuff either, this sort of thing goes all the way
up to the European national-CA level (this isn't a purely European disease,
but smart cards seem to be a lot more widely used over there, so it's more
noticeable).

>Key usage flags for public keys    Corresponding cryptoki attributes in X.509
>public key certificates for private keys
>

Even that is merely theoretical guidance, since there's a lot of confusion
between decryption and unwrapping keys - some apps mark keys as being for
decryption and some for unwrapping.  What you do is you try a decrypt first,
and if that fails you try an unwrap with a CKO_SECRET_KEY of type
CKK_GENERIC_SECRET, which returns the entire decrypted value, making the
unwrap equivalent to a straight decrypt.

So even here where you've got provision for key-wrap vs. data-encrypt, (a)
it's frequently not mapped from the certificate to the PKCS #11 level and (b)
even if it were, it's common practice to apply both operations in a manner
that makes them equivalent, in order to handle with the way existing apps do
things.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 May 2005 17:58:00 -0400

At 6:21 PM +0200 5/13/05, Denis Pinkas wrote:
>>decrypted with a private key that appears in a cert which has 
>>enabled the "keyEncipherment" but not "dataEncipherment" key usage 
>>bits. The intent is that a peer should never have used the public 
>>key to encrypt anything but key (or key and associated control 
>>info) bits, given the marking. In contrast, if the bytes I receive 
>>and decrypt were encrypted using a public key from a cert that has 
>>enabled the "dataEncipherment" key usage bit but not the 
>>"keyEncipherment" bit, then I would expect to hand these bits to an 
>>app, and that would be bad if they were really key bits.
>

that's true.

>   I would thus propose to be able to support that distinction.

yes, this distinction would be nice, but Peter's messages suggests 
that PKCS #11 code does not really pay much attention to the key 
usage bits anyway. so, it does not seem worht pursuing.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 May 2005 10:46:17 +0200

Steve (and Burt),

I concur with you and Peter that PKCS#11 is not currently enforcing an 
appropriate key protection against key extraction, but this could be easily 
improved.

Maybe RSA Security would like to improve PKCS#11 ?

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

Denis

> yes, this distinction would be nice, but Peter's messages suggests that 
> PKCS #11 code does not really pay much attention to the key usage bits 
> anyway. so, it does not seem worht pursuing.
> 
> Steve
> 
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 17 May 2005 21:32:06 +1200

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

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.  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.  Finally, some hardware (e.g.
many smart cards) can't support this, since all the card can usefully do is
the private-key op.  As a result the unwrapped key is always extractable from
the card, 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.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 May 2005 14:26:56 +0200

Peter,

> 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

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

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

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 18 May 2005 18:12:51 +1200

Denis Pinkas <[email-masked]> writes:

>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

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.

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 May 2005 18:34:31 +0200

Peter,

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

> 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