[SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?

Thu Oct 29 15:40:25 PDT 2015

Paul,

You don't have to convince me that this stuff is hard. :-)

Let's see if we can shed some light on the following immediate practical questions. 

1. We know that at least some cards expect PIN at any Digital Signature private key operation. I don't know whether PKard.tokend is ready to accommodate those cards - and if it is, how it determines whether ‎it needs to get the PIN again and pass it to the card, or the card considers itself still "unlocked" and doesn't need PIN again. Is it when the tokend classifies the inserted token as PIV? Maybe you could clarify this?

2. Is there a mechanism by which I (as a user, or as a person who can write data objects to the card) could tell PKard.tokend or Keychain that a given PIV token requires new PIN for every digital signature private key operation? Is there anything on the card itself that would convey this message to PKard.tolend? And why doesn't it happen automatically as soon as tokend determines that the inserted token is PIV? 

3. Assuming PKard.tokend "knows" to need to prompt for the PIN every time, how to make sure Keychain API (and whatever application that uses it) also knows it? And is this even necessary? Or does tokend framework and therefore PKard.tokend keep track of such things, and "figures" whether to prompt the user for a PIN when a digital signature operation is requested from it, without the application being aware of this PIN-prompt interaction?

4. My logs show that with CCC written to NEO, PKard.tokend recognizes this token as PIV. Yet it prompts for a PIN only at the first digital signature request - and subsequent ones do not result in a PIN prompt but rather in an error with the certificate. To actually sign the next email I have to save it in Drafts, close and restart Apple Mail - and then this email will be successfully signed (prompting me for a PIN, of course) and sent. I have to repeat the above dance for the next outgoing digitally signed email... Perhaps  you could suggest how to remedy this problem, or at least how to debug it, tracing this issue down to its actual culprit?

Thanks!

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Paul Nelson
Sent: Thursday, October 29, 2015 16:53
To: Blumenthal, Uri - 0553 - MITLL
Cc: Shawn A. Geddis; SmartCardServices-Users
Subject: Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?

Uri,
The Tokend framework provides methods for creating access control rules that get associated with objects on a smart card.  These rules do (or should) match the intent of the card specification.

For example, a CAC only requires a PIN to be sent to the card once before using any private key or reading certain data objects.  The card will keep track of its “unlocked” state until the card is powered off.  A PIV card and its specifications has different access control rules for its digital signature private key.  The card requires the pin to be sent to the card before each APDU using the digital signature private key.  It was intended by the PIV spec that the user enter their PIN each time they use the digital signature private key but the language is not specific and the NIST derived credential SP only states that a user needs to take a specific action in order for the private key to be used (that is hard to implement). However, the other private keys and data objects only require the PIN to be sent only once.  In reality, smart cards have more than one PIN (see ISO7816-4 7.5.1).  A second pin might be used to reset the user pin etc.

The challenge for Tokend developers is to try to map the Keychain CSSM objects and acls to the card specification.  Unfortunately they don’t always match up, particularly when it comes to the details of when a user must/should enter a PIN.  Saving the PIN (caching it) inside the Tokend memory can avert these issues but will break the intention of the card applet designer.

There are API for locking and unlocking a keychain but the Tokend must take care to implement what it means be locked or unlocked. Since Tokend is a private framework, you need to study the source code carefully to see how CSSM works.  This stuff is hard to figure out and you generally won’t find help from Apple.

Paul
Thursby Software Systems, Inc.

On Oct 29, 2015, at 3:19 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:

Shawn, how do I check and/or affect the policies on a given keychain wrt. enforcing PIN re-entering upon every operation (or ideally, every signing operation)?

Ultimately, this is enforced by the corresponding Tokend, but by specification should come from the applet on the card.  This has long been a problem with applets used on US Government cards not properly providing policies like this, so Apple had to take an approach of defaulting to allowing “Cached PIN” if not defined.  

Shawn, could you please clarify for me what “Cached PIN” means in the context?

Does it mean that the Keychain API assumes that once it passed the PIN to the tokend, either tokend keeps (“caches”) the PIN for a while, or the token itself stays “unlocked” for a while upon receiving the correct PIN?

Who decides how long that “for a while” lasts? 

Is there a mechanism by which tokend can inform Keychain API that the “cached for a while” is over and PIN must be re-entered? How does tokend know whether the token expects a new PIN, or is happy with being unlocked “a while ago”?

Thanks!

_______________________________________________
SmartcardServices-Users mailing list
SmartcardServices-Users at lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/smartcardservices-users

‎                 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20151029/98f4735a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20151029/98f4735a/attachment-0001.bin>