[Opendnssec-develop] hsm-toolkit questions

[Rick van Rein]

Hello Roy, John, Rickard, Jakob,

This is a reply to all that is currently in this thread.
(I sometimes wonder how people can survive without Mutt...)

On Wed, Mar 11, 2009 at 12:48:18PM +0100, Roy Arends wrote:
> 1) The object identifier
> 
> We need to identify an object. This can either be done by the LABEL or by 
> ID. Please give guidance on which to use, and what the values for this 
> identifiers need to be.

Quoting PKCS #11 v2.11 sections:

"The CKA_LABEL attribute is intended to assist users in browsing." (10.4)
"The CKA_ID field is intended to distinguish among multiple keys." (10.7)

So, you should use CKA_ID to store a hash code identifier.

Being not-for-humans, you could even consider to use a binary form of
the hash, instead of base64 or hex.  It probably makes most sense out
of what is defined in PKCS #11 as a byte array.

> I remember that 'hash of the key' was mentioned. 
> Please advice which algorithm to use. I also need to know if hsm-toolkit 
> needs to avoid identifier collisions or not.

A concern here is whether id collisions would raise security issues.
If not, you could use (a partial string of) MD4, otherwise use SHAxxx.

I could imagine attacks that would lead you to finding a key of choice
that happened to have the same ID as another one that was constructed
to fool you, but:
 1. You would probably notice ID collisions, and refuse to accept a
    newly created key with an existing ID;
 2. Even if the above attack would succeed, the private key is still
    protected by a PIN.

I see no other security problems, so the question about collision is not
a security question, IMHO.  That means that a quick/simple hash like MD4
would do; it is not secure but quicker than MD5.  Of course, practical
issues like availability of the hash routine could lead you to prefer
MD5 over MD4.  Although I see no benefit, you could even opt for using a
prefix of a hash string as ID instead of the full string.

> 2) additional functionality
> 
> The software can list, generate and destroy RSA objects from the token. Is 
> there interest in additional functionality, or do we want to keep it to 
> the bare necessities (list/generate/destroy objects)

No requests from me.

> 3) configurable defaults
> 
> Currently, all parameters need to be specified on the command line. Some 
> have static defaults. Do we want configurable defaults through a 
> configuration file, or no defaults, or the current status quo?

Bit length of keys should be configfile defaults, not static ones.
We don't want anything like "I'm stymied -- get thee a wizard".
(That's a bit of TeX folklore.)

On Wed, Mar 11, 2009 at 11:57:35AM +0000, John Dickinson wrote:

> I have a patch to add dynamic linking of the pkcs11. So that you  
> specify -P /usr/local/lib/libpkcs11.so on the command line instead of  
> at compile time. I am just cleaning it up and will submit it later  
> today.

Yes, this ought to work in general.  PKCS #11 is often loaded
dynamically, e.g. by Mozilla where you specify it in the GUI.

> Enforcer needs this as well. I was going to ask Jakob this very  
> question - Jakob, do you know the answer?

Same answer: Use CKA_ID, and you could consider binary notation.

On Wed, Mar 11, 2009 at 01:25:51PM +0100, Rickard Bondesson wrote:
> 
> My view is that ID should be used as an identifier for a key. LABEL is used as a description of the object.

Your gut feeling matches the prescriptions of the specification.

> John talked about using C_DigestKey, but that is not applicable to asymmetric keys. So you would have to extract some key material on your own and digest that.

I've missed what this is about, but C_DigestKey is intended AFAIK to
generically support algorithms like DIGEST-MD5 and CRAM-MD5, which hash
some data including a hardware-encapsulated key.  For asymmetric keys,
this is not common, as these are not usually treated as random secrets.

If your intention is to find a hash, simply extract the public key and
hash it.  It's probably best not to extract more, including no descriptive
information such as in a certificate; that would make it possible to use
the same key with different descriptive information, leading to different
identities -- you probably want to detect and reject if the same key is
used more than once.

On Wed, Mar 11, 2009 at 01:34:17PM +0100, Jakob Schlyter wrote:
> 
> I believe we decided that the LABEL should be used and that the  
> generator of the key assigns the label.

Did we?  Wow, we decided something in conflict with the standard.
Better backtrack that decision and become decent citizens again :)

If a domain is ever to be attached to a key, it could go into CKA_LABEL,
but CKA_ID definately is the place for the machine's way of locating it.

> IIRC, we said that the KASP  
> enforcer would typically generate the key and then update the label to  
> be the hash (SHA-1) of the public key.

SHA-1 is fine, but not (much) better than MD5 or even (insecure) MD4,
see above.  I'm happy with either hash algorithm, provided it doesn't
give a high collision probability like CRC-32 would.

  (Keep in mind that the number of people in a room need only be SQRT(365)
   to have a better-than-50% probability of a matching birthday.  Similarly,
   having SQRT(Reach(CRC-32)) = 2^16 keys would suffice to have a hit
   between two.  Two keys per domain, that makes only 32768 domains if
   you'd use CRC-32.)

> All others will refers to key by the label and find them by querying  
> all configured HSM for all keys.

As stated above, PKCS #11 disagrees with the label -> use CKA_ID instead.

On Wed, Mar 11, 2009 at 01:41:06PM +0100, Rickard Bondesson wrote:
> 
> Then we have to define how the public key should be hashed (in what order to hash the key material). Or perhaps there is a procedure defined by the community?

Isn't the wire format for a public key standardised?  PKCS #1
(not #11 but #1) specifies a public key syntax in appendix A.
Isn't that the most suitable format to use?

Note that in doing so, you want to select suitable encoding rules.
I believe DER-encoding is commonly used before hashing.

(Let me know if getting into ASN.1 is hard work, I may be of help.
I used to read its hexdumps -- a treat compared to PGP's base64.)


> >Then we have to define how the public key should be hashed (in what  
> >order to hash the key material). Or perhaps there is a procedure  
> >defined by the community?
> 
> no, we don't and that's a very nice property of this solution.

We should keep in mind that we do not want to be dependent on, say,
libraries on an operating system.  Those beasts update every once
in a while, and I'm not certain that XML protects us against people
adding pretty-print code to their libraries, forgetting that they
are breaking signatures.

> the one who generates the label decides how to hash - the ones using  
> it will just get the key from the keystore (e.g. using the <locator>  
> in the signconf XML blob) and query the HSMs.

XML is a bad idea as a source for hashing.  It would have to be turned
into a canonical format, which unlike ASN.1/DER isn't its default;
furthermore, there are things in XML that cannot be turned into a
canonical format, for reasons that are fundamental i.e. unresolvable.

Mixing XML and hashing is a recipe for problems.  XML is not suitable
for this, no matter what the existence of an XML Signing standard may
lead you to believe.  Stay well away from it!


Best,
 -Rick