<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><span id="OLK_SRC_BODY_SECTION" class=""><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" class="" type="cite"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 class=""><br class=""></div><span id="OLK_SRC_BODY_SECTION" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></body></html>