pkinit: using RSA modulus to locate private key

[tsitkova]

On Oct 7, 2008, at 8:16 AM, Mark Phalan wrote:

> On Mon, 2008-10-06 at 15:10 -0500, Douglas E. Engert wrote:
>>
>> Tom Yu wrote:
>>> Mark Phalan <Mark.Phalan at Sun.COM> writes:
>>>
>>>> One issue I ran into when working with PKINIT on OpenSolaris was  
>>>> that
>>>> our tool for storing certs and keys in PKCS11 tokens (pkinit(1))  
>>>> doesn't
>>>> generate a CKA_ID for private keys - it leaves it blank.
>>
>> Can you change your pkinit utility?
>
> Yes, I've filed a bug against pktool(1).
> http://bugs.opensolaris.org/view_bug.do?bug_id=6744761
> I've no idea when the KMF team will fix it though.

According to PKCS11 X509 the certs and the associated key pairs must  
have the same CKA_ID.

>
>
>> But since many tokens don't store
>> the CKA_ID then what?
>
> Not sure I totally understand the question. If there is no CKA_ID set
> and the RSA modulus from a cert matches a key in the token then, with
> the proposed patch, that key can be used.
>
>>
>>>> When PKINIT
>>>> finds a suitable cert and then looks for a corresponding private  
>>>> key it
>>>> fails to locate it (unless it's the only key available). I've
>>>> implemented a fallback so that if PKINIT can't find a suitable  
>>>> key by
>>>> CKA_ID it will try to find a private key matching the RSA modulus
>>>> associated with its key.
>>
>> Assuming you are using RSA key, that might work.
>
> Currently PKINIT only looks for RSA keys.
>
>> PKCS#11 2.20 says 12.1.3:
>> "The only attributes from Table 36 for which a Cryptoki  
>> implementation
>>  is required to be able to return values are CKA_MODULUS and
>>  CKA_PRIVATE_EXPONENT"
>>
>> But there might be cards where this is not true, as the card may not
>> store this information.
>
> The proposed RSA modulus fallback is only used when a key cannot be
> found using the current methods. If the CKA_MODULUS is not stored  
> then I
> guess the fallback will also fail.
>
>>
>>>> As the CKA_ID is typically a hash of the
>>>> modulus it seemed to me to be a suitable fallback.
>>
>> I don't believe that setting CK_ID to the hash is typical.
>> OpenSC can present a PKCS#11 view of many cards, it will
>> typically use 1, 2, 3... for the CK_ID and keep the same CK_ID
>> for the cert, public key and matching private key,
>> assuming that a CK_ID is unique only across a card.
>>

CKA_ID may be generated in the numerous ways. It may be a modulus of  
RSA, a public value of DSA,  SHA1/MD5 hash of the RSA modulus or any  
other unique to the token identifier that maps the cert to the  
associated key pair.
Keeping this in mind, as a work around, it might be sufficient just to  
extract RSA pub keys both  from the cert and the priv key and compare  
their modulus, rather than cert's CKA_ID and the hash value of the  
modulus of the key pair.


>> Note that if  the MIT x509_identity with cert_id= is
>> defined in the krb5.conf or pam_krb5 it will be in effect a
>> constant,and thus each card used must use the same CKA_ID,
>> for the "authentication" cert/key.
>
> Right, I was wondering about the utility of that setting in krb5.conf.
> However if it can be easily set manually or is "well-known" (as in  
> your
> example above for OpenSC) then it makes more sense.
>
>>
>>>>
>>>> Does this sound reasonable? I can contribute a patch.
>>
>> Yes it does. I believe the Heimdal code already does something
>> like this.
>
> The patch is pretty trivial, I'll open a ticket soon.
>
> -M
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

Zhanna Tsitkova
tsitkova at mit.edu
Kerberos  Consortium