<html><head></head><body style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Paul,</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">You don't have to convince me that this stuff is hard. :-)</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Let's see if we can shed some light on the following immediate practical questions. </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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?</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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? </div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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?</div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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?</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Thanks!</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div> <div style="display:none"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Paul Nelson</div><div><b>Sent: </b>Thursday, October 29, 2015 16:53</div><div><b>To: </b>Blumenthal, Uri - 0553 - MITLL</div><div><b>Cc: </b>Shawn A. Geddis; SmartCardServices-Users</div><div><b>Subject: </b>Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Uri,
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Paul</div>
<div class="">Thursby Software Systems, Inc.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 29, 2015, at 3:19 PM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="" style="word-wrap:break-word; font-size:14px; font-family:Calibri,sans-serif">
<span id="OLK_SRC_BODY_SECTION" class="">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" class="" type="cite" style="border-left:#b5c4df 5 solid; padding:0 0 0 5; margin:0 0 0 5">
<div class="">
<div class="" style="word-wrap:break-word">
<div class="">
<blockquote type="cite" class="">
<div class="" style="word-wrap:break-word">
<div class=""><font class="">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)?</font></div>
</div>
</blockquote>
</div>
<div class="">
<div class="" style="word-wrap:break-word">
<div class=""><br class="">
</div>
<div class="">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. </div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div>
<br></div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div class="">
<div class="" style="word-wrap:break-word">
<div class="">Shawn, could you please clarify for me what “Cached PIN” means in the context?</div>
</div>
</div>
</span>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div class="">
<div class="" style="word-wrap:break-word">
<div class="">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?</div>
</div>
</div>
</span>
<div class=""><br class="">
</div>
<div class="">Who decides how long that “for a while” lasts? </div>
<div class=""><br class="">
</div>
<div class="">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”?</div>
<div class=""><br class="">
</div>
<div class="">Thanks!</div>
<div class=""><br class="">
</div>
</div>
_______________________________________________<br class="">
SmartcardServices-Users mailing list<br class="">
<a href="mailto:SmartcardServices-Users@lists.macosforge.org" class="">SmartcardServices-Users@lists.macosforge.org</a><br class="">
https://lists.macosforge.org/mailman/listinfo/smartcardservices-users<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br><!--end of _originalContent --></div> </body></html>