[kerberos-discuss] smart card token label question

[Douglas E. Engert]

Nicolas Williams wrote:
> On Mon, May 03, 2010 at 05:08:14PM -0500, Douglas E. Engert wrote:
>> Will Fiveash wrote:
>>> I'm trying to get an idea as to whether smartcards are typically
>>> deployed with a token label that is the same for all deployed smartcards
>>> or does the token label vary per smartcard?
>> I assume you are referring to the PKCS#11 CKR_TOKEN_INFO label. A card may
>> or may not have labels stored on the card. And it may or may not have a card
>> serial number. So a PKCS#11 implementation may have to try and come up with
>> a token label and/or a serial number using what ever information is available.
> 
> The pLabel field of CK_TOKEN_INFO.  This supposed to be a 32-byte
> character data field containing a label set by the SO when the token was
> initialized with C_InitToken().  It could contain anything, from a
> generic string to a username, to an employee ID, all of those, or none
> of those.

PKCS#11 2.01 says: "application-defined label, assigned during token
initialization". Since the CK_TOKEN_INFO contains both a label and a serial
number, the label may describe the application, and thus may be the same on
every smart card, where as one would expect the serial number to be unique.

> 
>> The only card and middle ware I can speak to in the PIV card with the OpenSC.
>> The PIV card has objects but NIST 800-73 does not define a label of a serial
>> number for a PIV card. The closest thing to a serial number are fields in the
>> "CHUID" object on the card that could be used to create a serial number from
>> the FASC-N or the GUID if present. The OpenSC PIV driver does this for the
>> serial number.
> 
> The serial number is not what's interesting here though.

Maybe not for PKINIT, but might be if an e-mail client is looking for a
specific card which it knows has the key pair used to verify, sign or decrypt
e-mail. It can then lookup the cert in its cert store to see what card
its looking for, and can ask the user to insert that card.

> 
>> The token label is worse. OpenSC's pkcs11-tool -L returns a combination
>> of what the the card driver has as a token label, and the label for the PIN.
>> It returns "PIV_II (PIV Card Holder PIN)".
> 
> "Label for the PIN"?  What's that?

Some cards may have multiple pins, which allow access to different objects
or applications. OpenSC can support this, and by adding the pin label to the
label which is usually used to prompt the user, the user has some clue as to
which pin to enter. (The PIV application on a card has a pin, and the card may
have a pin as well. There could also be more then one application on a card.
The OpenSC PIV driver only deals with the PIV application pin.)

> 
>> Based on observations of trying a PIV card with just a certificate and key
>> but no other objects on the card, the card would not work with the Windows 7
>> native driver. Only after a CHUID object was added to the card would it work.
>> So Microsoft may have taken the same approach of using the CHUID to get a
>> serial number.
> 
> The problem is that some tokens pretend that there are no public objects
> unless you've logged in.  So if there's several tokens in the system and
> one needs to choose between them (e.g., between an SCA6000 and one of
> several smartcards) at logon time, the questions are: how to narrow down
> the choices, and how to present the remaining choices to the user.
> 
> Also, asking that the PKINIT pre-auth plugin understand CHUID seems... a
> bit much.

I was not saying that it should. I was pointing out the lengths a PKCS#11
implementation may have to go to fill in the CK_TOKEN_INFO label and serial
number fields, and that other non PKCS#11 implementations use the same tricks.

> 
> The simplest answer is, of course, to ensure that one has just one slot :)
> But that's not as easy as it sounds.

Agreed!

> 
> Nico

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444