October 2015 - SmartcardServices-Users

Re: [SmartcardServices-Users] [Fed-Talk] CAC-enabled login OS X10.7 & 10.8
by Shawn Geddis 02 Nov '16

02 Nov '16

Michael, All Smart Card related questions should be communicated on Apple's SmartCardServices Project Lists over at MacOSForge.org. A brief debunking of misinformation previously shared on this thread... There are three methods for associating a Smart Card to a given user account in either the local or remote DS. PubKey Hash - Default method used by OS X and requires sc_auth Attribute Matching - requires /etc/cacloginconfig.plist PKINIT - requires /etc/cacloginconfig.plist and Mac bound to a KDC All methods require that the smartcard-sniffer line be present in /etc/authorization for catching the Smart Card and gathering the PIN for the associated Challenge Response with the card for use of the Private Key on the card. Tokend modules no longer ship with OS X (as of OS X Lion), but are freely available for 10.7, 10.8 from Apple's SmartCardServices project at MacOSForge. This is why nothing happens when you insert a reader / card on a vanilla install of OS X Lion or higher. ALL other components of SmartCard Services are present and have even been updated in released versions of OS X since OS X Lion v10.7.0. Project Site: http://smartcardservices.macosforge.org/ Installers: http://smartcardservices.macosforge.org/trac/wiki/installers There are also third-party commercially supported solutions from, for example, Centrify, charismathics and Thursby. ".....Comparing against 10.4 references these seem to indicate that smart card login is already enabled, besides the name change from smartcard-sniffer to PKINITMechanism...." No, "smartcard-sniffer" is NOT a name change for PKINITMechanism. "smartcard-sniffer" performs a swap of the login window (dynamically) and captures PIN "PKINITMechanism" performs the Apple provided PKINIT services for Login Authentication. "...Unfortunately Apple dropped support and now it is a requirement in many places, all places that supply Windows-software for this but if you use OS X you have to find your own solution..." You have the SAME functionality still offered via my installers from Apple's MacOSForge Project You have multiple commercial solutions as well as noted above: Centrify, charismathics and Thursby. Please register and redirect ALL Smart Card related questions to one of the appropriate Mailing list on MacOSForge. http://lists.macosforge.org/mailman/listinfo Smart Card Users: https://lists.macosforge.org/mailman/listinfo/smartcardservices-users Smart Card Developers: https://lists.macosforge.org/mailman/listinfo/smartcardservices-dev - Shawn ______________________________________________________ Shawn Geddis geddis(a)me.com Enterprise Security Consulting Engineer, Apple geddis(a)apple.com MacOSForge: Smart Card Services Project Lead: Web: http://smartcardservices.macosforge.org/ Lists: http://lists.macosforge.org/mailman/listinfo ______________________________________________________ On Feb 19, 2013, at 1:40 PM, Michael Kluskens <mklus(a)ieee.org> wrote: > I'm well aware of the sc_auth command and on previous versions of OS X I had CAC login enabled. However, in testing an OS X Lion and an OS X Mt. Lion system, inserting the CAC card has no effect. Both systems otherwise have full CAC functionality and I used the Identity Private Key. > > I have not yet tried this on a clean system with no security configuration (disabling suid's binaries, etc.) so it is possible that both systems have been broken with regards to CAC login. > > I was hoping someone could actually confirm what setup works on OS X 10.7 & 10.8 because at present the discussed information has not worked for me. > > Looking at /etc/authorization under system.login I see: > > builtin:policy-banner > loginwindow:login > builtin:reset-password,privileged > builtin:forward-login,privileged > builtin:auto-login,privileged > builtin:authenticate,privileged > PKINITMechanism:auth,privileged > loginwindow:success > HomeDirMechanism:login,privileged > HomeDirMechanism:status > MCXMechanism:login > loginwindow:done > > and under authenticate I see: > > builtin:authenticate > builtin:reset-password,privileged > builtin:authenticate,privileged > PKINITMechanism:auth,privileged > > Comparing against 10.4 references these seem to indicate that smart card login is already enabled, besides the name change from smartcard-sniffer to PKINITMechanism. > > Michael > >> From: "Danberry, Michael J Mr ARMY GUEST USA" <michael.danberry(a)us.army.mil> >> The specific location for this information is at: http://militarycac.com/errors2.htm#OTHER_QUESTIONS. Question 2 > >> From: "Bomar, Matt W ERDC-RDE-ITL-MS Contractor" <Matthew.W.Bomar(a)erdc.dren.mil> >> >> Have you looked at the "sc_auth" command? It should allow you to associate >> a certificate with a local user account for CAC login. It's still present >> in 10.8. >> >> On 2/14/13 4:30 PM, "Michael Kluskens" <mklus(a)ieee.org> wrote: >> >>> What are the choices for CAC enabled login on OS X 10.7 & 10.8. >>> >>> I'm looking at OS X systems which may not have access to a MS Domain >>> Server, i.e. isolated network. Some would have access and some would not >>> have access all the time. >>> >>> I thought maybe some changes to /etc/authorization might reenable >>> CAC-login but I haven't started an attempt yet. >>> >>> Unfortunately Apple dropped support and now it is a requirement in many >>> places, all places that supply Windows-software for this but if you use >>> OS X you have to find your own solution.

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 31 Oct '15

31 Oct '15

Timothy, The way I understand your response, if the card is recognized as a PIV token ‎- then the "tokend framework" (whatever it is) should know to prompt for a PIN at every DSK operation, without any extra "nudging". I am also using Paul's software (PKard.tokend), because I also need CAC support in addition to other (PIV) smart cards. I am trying to understand why the tokend log‎ shows that the card is recognized as PIV, yet Apple Mail fails to sign any but the first outgoing email, and I have to resort to Ridley's work-around (hope attribution is correct) to send more than one signed email. The work-around is: uncheck "Sign", save in Drafts, restart Apple Mail, try again. This behavior suggests that somewhere in the system (tokend? Keychain API? Something else?) there's confusion about token's state - and the system "forgets" to prompt for a PIN before the next DSK operation. I'd like to find out (if possible) what component is failing, and (more importantly) what can be done (especially by me) to alleviate this problem. ‎ Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Miller, Timothy J. Sent: Friday, October 30, 2015 09:49 To: Blumenthal, Uri - 0553 - MITLL; Paul Nelson Cc: Shawn A. Geddis; SmartCardServices-Users Subject: RE: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates? ‎ > 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? All PIV DSKs require the VERIFY APDU immediately prior to the DSK key operation. Key container access rule are pretty clearly spelled out in SP 800-73-4 Part 1. See table 4b. And yes, PIV.tokend supports these cards. I have two, and they work fine. (That said I personally use Paul's software 'cause I also have a CAC and need to use the GSC-IS model for some operations, so having a tokend that implements both models is muy convienient :). See also NIST IR 7863, particularly the section on key caching. Paul's statement that PIV middleware must always collect the PIN for a DSK operation was the original intent of the spec, but has since been modified since it was found to be really inconvenient in practice. > 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? ‎ See above. If you're using the DSK conditional element, it's required to be subject to the PIN-Always rule, which is enforced by the PIV card app, so there's nothing you should need to do at personalization other than populate the PIV card application with the right key reference value. Also, while the CCC is a mandatory object, it's only there for GSC-IS interop. If you're not using the GSC-IS model, then the CCC can be empty *except* for the data model value. See SP 800-73-4 Part 1, Sec 3.1. -- T

7 8

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 30 Oct '15

30 Oct '15

Ridley, First - apologies for mis-attribution. Regarding your points on NEO: true, it doesn't seem to be fully PIV-compliant‎ - but that shouldn't matter in the context of the problem I'm having/describing, because in that aspect at least (requirement to use PIN for every DSK operation) NEO is 100% conformant, as I've learned from my own experience. So the problem is not that NEO would allow unprotected DSK operations forbidden by NIST (which BTW NEO doesn't) - the problem is that OS X or Keychain API or PKard.tokend are trying to perform an unprotected DSK operation on NEO contrary to what PIV standard says.‎ I am trying to (a) figure out why, and (b) how to remedy this. I fully concur on the other Apple Mail problems you described. Seen/had those, and a bunch more. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Disiena, Ridley (MSFC-IS60)[EAST] Sent: Friday, October 30, 2015 12:05 To: Blumenthal, Uri - 0553 - MITLL; Miller, Timothy J.; Paul Nelson Cc: Shawn A. Geddis; SmartCardServices-Users Subject: Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates? ‎ Since the Yubikey PIV applet has not been validated by NIST and no testing artifacts are available, I would not assume the applet is compliant. It could very well be to spec, just stating that without an audit trail that may be something that needs confirmed. Also, there are several generations of PIV, it is possible that it is an older PIV applet type with legacy specifications. The Yubikey page only specifies 800-73, it does not specify which generation. It does appear from the yubikey piv-tool documentation that the 9C DSK slot is set to PIN always, there should be a way to confirm that. Normally with card applets that have gone through NIST testing you can assume is working properly, not sure that is the case here. I can confirm Apple Mail with FIPS 201-2 compliant PIV card it does prompt for PIN on each DSK usage with PIV.tokend and OpenSC, I can't comment on the non-open source tokends. BTW, that workaround was not my suggestion, I have not seen the particular issue your are describing. I have seen numerous long standing issues with Apple Mail and signing and encryption. Sometimes the buttons for signing and encryption just stop functioning even though they appear, or sometimes they don't even appear, restarting the application can resolve it. Other issues are that intermittently messages are not properly shown as being an encrypted and or signed message despite being SMIME and having been decrypted; this can be hazardous since without inspecting the raw source a recipient has no idea that the message contents were encrypted and a reply will, by default, not be set to encrypt. Mail also defaults to SHA-1 for DSK signing with no option to request a higher algorithm, which is fortunate for PIV.tokend since it can't support higher than SHA-1. Even if you reply to a SHA-521 signed email, Mail only signs the reply with SHA-1, even if the tokend is capable of SHA-2 algorithms. In contrast Outlook will allow user control of the signing algorithm, although sending will fail if the algorithm is not supported by the tokend. Also, Mail incorrectly indicates opaquely signed messages are encrypted, when in fact they are only signed, they are just not in the legacy clear-text signing format. There are addition issues, those are just the top of my list. -Ridley Also, that attribution wasn't correct. On 10/30/15, 10:13 AM, "smartcardservices-users-bounces(a)lists.macosforge.org on behalf of Blumenthal, Uri - 0553 - MITLL" <smartcardservices-users-bounces(a)lists.macosforge.org on behalf of uri(a)ll.mit.edu> wrote: >Timothy, > >The way I understand your response, if the card is recognized as a PIV >token ?- then the "tokend framework" (whatever it is) should know to >prompt for a PIN at every DSK operation, without any extra "nudging". > >I am also using Paul's software (PKard.tokend), because I also need CAC >support in addition to other (PIV) smart cards. > >I am trying to understand why the tokend log? shows that the card is >recognized as PIV, yet Apple Mail fails to sign any but the first >outgoing email, and I have to resort to Ridley's work-around (hope >attribution is correct) to send more than one signed email. The >work-around is: uncheck "Sign", save in Drafts, restart Apple Mail, try >again. This behavior suggests that somewhere in the system (tokend? >Keychain API? Something else?) there's confusion about token's state - >and the system "forgets" to prompt for a PIN before the next DSK >operation. > >I'd like to find out (if possible) what component is failing, and (more >importantly) what can be done (especially by me) to alleviate this >problem. >? >Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >network. > Original Message >From: Miller, Timothy J. >Sent: Friday, October 30, 2015 09:49 >To: Blumenthal, Uri - 0553 - MITLL; Paul Nelson >Cc: Shawn A. Geddis; SmartCardServices-Users >Subject: RE: [SmartcardServices-Users] [Fed-Talk] Help tracing access to >keys/certificates? >? >> 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? > >All PIV DSKs require the VERIFY APDU immediately prior to the DSK key >operation. Key container access rule are pretty clearly spelled out in SP >800-73-4 Part 1. See table 4b. And yes, PIV.tokend supports these cards. >I have two, and they work fine. (That said I personally use Paul's >software 'cause I also have a CAC and need to use the GSC-IS model for >some operations, so having a tokend that implements both models is muy >convienient :). > >See also NIST IR 7863, particularly the section on key caching. Paul's >statement that PIV middleware must always collect the PIN for a DSK >operation was the original intent of the spec, but has since been >modified since it was found to be really inconvenient in practice. > >> 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? >? >See above. If you're using the DSK conditional element, it's required to >be subject to the PIN-Always rule, which is enforced by the PIV card app, >so there's nothing you should need to do at personalization other than >populate the PIV card application with the right key reference value. > >Also, while the CCC is a mandatory object, it's only there for GSC-IS >interop. If you're not using the GSC-IS model, then the CCC can be empty >*except* for the data model value. See SP 800-73-4 Part 1, Sec 3.1. > >-- T >

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 30 Oct '15

30 Oct '15

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(a)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(a)lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/smartcardservices-users ‎

2 1

[Fed-Talk] Help tracing access to keys/certificates?
by david.lloyd＠fsmail.net 30 Oct '15

30 Oct '15

Hi, Paul wrote: "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." In general as an application author, it is necessary to ensure that any call to a smart card can require that a PIN be re-entered. Almost any event can cause a smart card to be suddenly locked. In practise this isn't always the case with third-party apps - have you considered a mode where you report yourself as a TYPE-II reader and perform the PIN prompt from within the drier stack rather than hoping that the application can handle the GUI display? This is how Windows handles the situation - the CSP pops up PIN prompts, not the application. Regards, David

1 0

Building the piv.tokend project
by david.lloyd＠fsmail.net 30 Oct '15

30 Oct '15

Hi, I was asked for some pointers on building the PIV.tokend project… (1) Check out the code svn checkout https://svn.macosforge.org/repository/smartcardservices (2) Launch Xcode and open trunk/Tokend.xcodeproj Switch from World to PIV (3) Build the code - choose “Update to recommended settings: (4) Open the build settings for Tokend: - switch C++ Standard library to: stdc++ (GNU c++) (5) Create the SecurityPieces/Frameworks directory and link to OpenSC.tokend/build get the OpenSC.tokend source code - note the frameworks in the build directory git clone https://github.com/OpenSC/OpenSC.tokend.git mkdir /usr/local/SecurityPieces/Frameworks ln -s Frameworks to OpenSC.tokend/build (6) Build again Token.h line 189 rename one of the two hKeys to something else. (7) Linking: rename tokend.framework/toked_debug to tokend …so that the linker finds it, or figure out why this happens! (8) Copy output PIV.tokend/Contents/MacOS/PIV_debug over /Library/Secuity/tokend/Contents/MacOS/PIV Job done! Hope that helps...

1 0

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 29 Oct '15

29 Oct '15

>> 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!

2 1

Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
by Blumenthal, Uri - 0553 - MITLL 29 Oct '15

29 Oct '15

> Uri, > > BTW, this conversation should have gone through the SmartCardServices-User / > SmartCardServices-Dev Mailing Lists to enlighten everyone at once rather than > simply between the three of us. Copying there. >> 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. So, in the case of the PKard.tokend, Thursby would either need to > allow users to define a policy, obtain a policy from the card’s applet or take > a default stand (such as ‘cache PIN by default) if policy (ACLs) not > provided/found on card. I see. By any chance, do you happen to know if is this the > Again, this has been an across the board problem with lack of definition on US > Gov cards with the Gov’t expecting the middleware to “do the right thing” > which of course they change on a whim, unfortunately. :-) > BTW, I know of no other users across the whole US Federal Government / > Contractors having the issue you are describing here associated with Mail. To the best of my knowledge, most of the Feds :) use MS Outlook – either whatever version runs on Windows, or Outlook 2011 (or whatever was the previous one) on Mac. So the problem wouldn’t manifest itself – in my experience Outlook 2011 was able to sign outgoing several emails in a row, prompting me for the PIN every time, and signing smoothly without a hitch… >> On Oct 29, 2015, at 1:27 PM, Blumenthal, Uri - 0553 - MITLL <uri(a)ll.mit.edu> >> wrote: >> >>> Uri, >>> >>> https://bugreport.apple.com/ >>> >>> Send me the Radar # >> >> I submitted the problem, and got back this number: 23316478 >> Thanks for the explanation – so the problem is not between an application >> and tokend, but between Keychain API and tokend. Is there a way to look >> deeper into that exchange? Some more detailed logging? >> >> 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)? >> >>>> On Oct 29, 2015, at 11:38 AM, Blumenthal, Uri - 0553 - MITLL >>>> <uri(a)ll.mit.edu> wrote: >>>> >>>> Shawn, >>>> >>>> Wanted to make sure you see this. It looks like we have a decent idea >>>> what’s wrong with Apple Mail: somehow it does not seem to pass the PIN on >>>> subsequent request to sign outgoing emails, maybe believing that the card >>>> stays “unlocked” for a while. >>>> >>>> This would explain why the 1st outgoing digitally signed email succeeds >>>> practically always, the 2nd one - practically always fails, but if you >>>> save the draft and restart Apple Mail - it again succeeds signing it >>>> (because now Apple Mail treats the token as “fresh” and requiring >>>> initialization & unlocking). >>>> >>>> Would it be possible for you to pass this info to appropriate people at >>>> Apple who can get this issue looked into, and hopefully fixed??? >>>> >>>> Thanks! >>>> >>>> P.S. I have logs from Thursby PKard.tokend that show the difference of a >>>> successful signing (tokend gets a PIN-authenticate request, performs it, >>>> and then proceeds with the bunch of signing work), and an unsuccessful >>>> signing attempt (tokend gets a bunch of PIN-less requests, nothing else is >>>> going on). >>>> >>>> On 10/26/15, 12:30, "uri(a)ll.mit.edu" <uri(a)ll.mit.edu> wrote: >>>> >>>>> Interesting. I'm seeing something similar on Yosemite, with CACKey 0.7.5, >>>>> also with PKard-1.6.3, also with PIV.tokend from SmartCardServices 2.0.2. >>>>> Which means the problem is likely with Apple Mail rather than with tokend >>>>> itself (in this particular case). >>>>> >>>>> ‎It looks like Apple Mail "forgets" to ask user for a PIN and treats the >>>>> card as if unlocked - and all that tokend gets is a bunch of PIN-less >>>>> requests that it does not execute. After Apple Mail restarts, and with >>>>> this mail piece from the draft finally asks the user for his PIN - then >>>>> (usually) PIN is passed to the tokend and from it to the card, and email >>>>> (usually) gets signed and sent. (As we know, *each* signing request >>>>> *must* be PIN-authorized; the only way around it is if the app itself >>>>> caches the PIN and forwards it with the next requests.) >>>>> >>>>> So again, the problem appears to be between the app (Apple Mail) and the >>>>> tokend (most any, except for OpenSC.tokend that just does not work no >>>>> matter what). >>>>> >>>>> Which again underscores the need to somehow trace the communications >>>>> between Apple Mail and tokend. >>>>> >>>>> How do we get it from Apple??? >>>>> >>>>> Alternatively, what is people's experience with MS Outlook 2011 and/or >>>>> Thunderbird? >>>>> >>>>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE >>>>> network. >>>>> Original Message >>>>> From: David Mueller >>>>> Sent: Monday, October 26, 2015 11:49 >>>>> To: Fed Talk >>>>> Cc: Blumenthal, Uri - 0553 - MITLL >>>>> Subject: Re: [Fed-Talk] Help tracing access to keys/certificates? >>>>> >>>>> >>>>>> On Oct 19, 2015, at 1:22 PM, Blumenthal, Uri - 0553 - MITLL >>>>>> <uri(a)ll.mit.edu> wrote: >>>>>> >>>>>>> Was a frequent occurrence with Yosemite; haven’t spent much time with >>>>>>> El >>>>>>> Capitan yet to see if it’s still an issue. >>>>>> >>>>>> I’m still on Yosemite. >>>>>> >>>>>> You’re saying maybe El Capitan would be better in that area? >>>>> >>>>> So far I would say that it’s actually worse in El Capitan (including >>>>> 10.11.1). Rather than getting an error, the message simply fails to send >>>>> and is left in my Drafts folder. Closing and reopening Mail still seems >>>>> to resolve an issue. >>>>> >>>>> One difference I’ve noticed is that after restarting Mail, I’m prompted >>>>> for the CAC PIN to send the signed email, whereas before it would simply >>>>> close the outgoing message. So it’s almost like it’s trying to use the >>>>> CAC without the PIN. >>>>> ‎ >>>>> I’m using CACkey 0.7.5. >>>>> >>>>> - David >>> >

1 0

Re: [SmartcardServices-Users] Submitting patches for PIVToken.cpp bugs [Yubikey Neo]
by Beck, Keith M CDR NAVSEA, AEGISTECHREP 26 Oct '15

26 Oct '15

By definition, there are 7 mandatory objects to be a PIV (Card Capability Container (CCC) and Card Holder Unique Identifier (CHUID) are two of the seven). If you don't have all seven, you have the risk that the card will fail something that is expected as a core capability of all PIV cards. SP 800-73-4, page 28 has the list of mandatory, conditional, and optional card application data objects. http://csrc.nist.gov/groups/SNS/piv/standards.html Keith ---------------------------------------------------------------------- Date: Sun, 25 Oct 2015 10:42:51 +0100 From: david.lloyd(a)fsmail.net To: Uri Blumenthal <uri(a)mit.edu> Cc: Shawn Geddis <geddis(a)icloud.com>, SmartCard Services-Users <smartcardservices-users(a)lists.macosforge.org> Subject: Re: [SmartcardServices-Users] Submitting patches for PIVToken.cpp bugs [Yubikey Neo] Message-ID: <17361481.1771445766171121.JavaMail.www@wwinf3714> Content-Type: text/plain; charset=UTF-8 ... I am thinking that rather than a load of "-action setThisAndThat" options, the piv tool would be better off with an "-action initialize" option that adds all the required PIV files. Where "required" from where I am sitting is CCC and CHUID -- PIV experts can feel free to add more. ... Regards, David L P.S. Is there a good tool in OpenSC that checks to see if a card PIV is ok? i.e. something that can use for PIV card compliance unit testing? > Subject: Re: [SmartcardServices-Users] Submitting patches for PIVToken.cpp bugs [Yubikey Neo] > > It would be nice if SmartCardServices tokend could work with a card that doesn't have a CCC object in it. > > In my experience, NEO (a) does not have CCC, and (b) does not perform SELECT command properly. > > One workaround I found for another tokend to work with NEO correctly was to generate a CCC object and write it to NEO using piv-tool from OpenSC package.

1 0

Re: [SmartcardServices-Users] Submitting patches for PIVToken.cpp bugs [Yubikey Neo]
by david.lloyd＠fsmail.net 26 Oct '15

26 Oct '15

Hi, I have raised an issue against the Yubico-Piv-tool https://github.com/Yubico/yubico-piv-tool/issues/33 - looking at the posts it seems like the consensus is to "Add an initialize parameter that sets everything up". There is no need for error detection or PIV specification compliance testing at this stage, although it would obviously be a nice-to-have feature for OpenSC in future. I have also tried to raise a ticket against SmartcardServices/tokend, but it looks as though although the website is now back up, the "New Ticket" feature is still broken. My text is below - I have highlighted a list of potential issues with the patch that should be reviewed be the PIV/TokenD experts although I don't think any of them are particularly important. Title: PIVToken.cpp needs to be more flexible if the CCC is not on a PIV Card [Yubikey NEO] The Yubikey NEO PIV tool is not including the "Card Capability Container" file, which is in violation of the PIV specification. This causes the PIV.tokend tool to fail as the PIVToken::probe() function (line 265) assumes that it can access this to structure to generate the Unique name (PIV-<hexstring>) based on the card identifier. Current behaviour: the function uses GetDataCore() that throws an exception when the file is missing, causing Probe() to fail and the card is ignored. Proposed behaviour: In the case that the CCC is not available the code uses the CHUID to generate a unique name. This is actually what Windows appears to do in its PIV driver. I am able to compile and test any code changes. I also have access to the NIST PIV card set for regression (if needed). Here is my proposed patch. Note that: (1) although the CCC object is cached, it does not appear to be used anywhere else in the code. Basic functionality in Safari has been confirmed. (2) existing cards with a CCC have unchanged behaviour (beyond the extra step of checking for the CCC first). (3) an alternative is to catch the exception when the CCC is missing, rather than to probe for it (4) the patch does not parse the CHUID to extract the GUID, it uses the whole file as a hex string. This needs to be checked as the FASN would be revealed. A SHA512 may be an alternative to writing a parser. (5) If both CCC and CHUID are missing the card will not work (similar to Windows), it would be possible to hardcode a "PIV-Unknown" UID in this case. if (!identify()) doDisconnect = true; else { #ifndef _USEFALLBACKTOKENUID const size_t sz = sizeof(oidCardCapabilityContainer); if (getDataExists(oidCardCapabilityContainer, sz, sDescripCardCapabilityContainer)) { secdebug( "probe", "Look up Card Capability Container"); byte_string cccOid((const unsigned char *)oidCardCapabilityContainer, oidCardCapabilityContainer + sizeof(oidCardCapabilityContainer)); byte_string cccdata; /* Since probe is called before establish, securityd has not passed us the cache directory yet, so we don't try to cache anything right now */ const bool allowCaching = false; getDataCore(cccOid, "CCC", false, allowCaching, cccdata); PIVCCC ccc(cccdata); snprintf(tokenUid, TOKEND_MAX_UID, "PIV-%s", ccc.hexidentifier().c_str()); } else { secdebug( "probe", "Look up CHUID"); byte_string chuidOid((const unsigned char *)oidCardHolderUniqueIdentifier, oidCardHolderUniqueIdentifier + sizeof(oidCardHolderUniqueIdentifier)); byte_string chuidData; const bool allowCaching = false; getDataCore(chuidOid, "CHUID", false, allowCaching, chuidData); CssmData data; data.Data = &chuidData[0]; data.Length = MAX(chuidData.size(), TOKEND_MAX_UID/2 - 6); snprintf(tokenUid, TOKEND_MAX_UID, "PIV-%s", data.toHex().c_str()); } secdebug( "probe", "tokenUid is %s", tokenUid); #else There is a discussion of the tokens issue here: https://lists.macosforge.org/pipermail/smartcardservices-users/2015-October… I have also opened an issue against the Yubikey PIV tool here:https://github.com/Yubico/yubico-piv-tool/issues/33 The general sentiment is (1) that the Yubikey PIV tool should have an "initialize" option that installs all the mandatory files for novice users. (2) As the tokend code is only using this for a card identifier, it would be highly desirable for it to be more flexible in the case that the file is missing. Regards, David L

1 0