Re: [pkcs11] General Philosophy - What starts in the HSM, stays in the HSM.

[Michael StJohns <msj@nthpermutation.com>]

Hi Oscar

On 8/6/2013 7:47 PM, Oscar K So Jr. wrote:
> Michael,
>
> Here is my thinking.....
> In addition to all of your proposed solution, would a signed 
> application with authenticated PKCS#11 API calls work ?
>
> I got this idea from the CK_JAVA_MIDP_SECURITY_DOMAIN attribute.
>
> This attribute has ONE of the following values:
> DOMAIN_UNSPECIFIED (i.e. unsigned application)
> DOMAIN_MANUFACTURER (i.e. Apple iPhone)
> DOMAIN_OPERATOR (i.e. AT&T phone company)
> DOMAIN_THIRD_PARTY (i.e. developer like you and me)
> The value refer to the signer of the certificate of the application.
> If we determine a group of PKCS#11 API calls which can only be called 
> or accessed if the application is signed by a trusted Root CA, we can 
> limit the attacker from calling these PKCS#11 API(s) even the attacker 
> knows the password of CKU_USER. The attacker's application is not 
> signed, and therefore, access denied.

I think what you're suggesting is some sort of stronger authentication 
for PKCS11 than just PINs.  I started to sketch out something like this, 
but decided it was definitely a 3.0 or later set of changes.

One of the simpler protocols is to use a challenge/signature model.   Do 
a call to C_GetAttributeValue for some global object that has a 
CKA_VALUE that changes everytime you query it.  Do a C_Login with the 
signature over that challenge as well as an identifier to indicate which 
of the identities (e.g public keys or certs) that the token has that 
should be used to verify the signature.

Other approaches may be possible as well without perturbing the current 
API too much.

> Anyway, I would be scared to learn that an attacker has already gotten 
> control of my HSM, decrypted all of my information, and backed it up 
> somewhere. Do you have such experience in the past ?

That's not actually the problem I'm trying to solve.  PKCS11 has 
reasonably good protections for what I call primary keys - keys that are 
generated on the HSM or loaded explicitly.  They can have the 
appropriate CKA_PRIVATE and CKA_SENSITIVE and CKA_EXTRACTABLE values set 
in a manner that I'm pretty sure they can't be extracted.

It's the secondary keys that are bothering me - the results of a KDF 
operation, or the results of a Key Agreement (ECDH, DH) operation, and 
to a lesser extent the keys from an wrap/unwrap operation (because I 
didn't actually have space to store them internally all the time).

Given the current interactions of key policies in PKCS11, I can't 
actually ensure that a derived key remains sensitive, private and 
non-extractable - because even if I set the derived key as such when I 
derive it the first time, if an attacker can get access to USE the 
module and the derivation key, he can re-derive that derived key but set 
the sensitive, private and extractable bits in a way he can extract the 
key data.  That applies to both the KDFs and to key agreement models.

Similar problems exist with the key wrapping model.

Mike



> I guess it has to be an HSM in the network where application would 
> call this HSM's PKCS#11 API remotely...
>
> Best,
> Oscar