Re: [SmartcardServices-Users] [Fed-Talk] Help tracing access to keys/certificates?
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
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@lists.macosforge.org on behalf of Blumenthal, Uri - 0553 - MITLL" <smartcardservices-users-bounces@lists.macosforge.org on behalf of uri@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
On Oct 30, 2015, at 9:05 AM, Disiena, Ridley (MSFC-IS60)[EAST] <ridley.disiena@nasa.gov> wrote:
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.
Since restarting Mail (without restarting anything in the card/keychain system) is a workaround, I think it’s reasonable to think the problem is in Mail, or in Mail’s use of keychain. However if there is some suspicion Yubikey support is an issue, then we should be reporting the PIV applet number on the Yubikey. There are several “in the wild”. I feel sure Yubikey will be responsive to bug reports with sufficient detail. Also I think 10.10 was when Apple began “officially” supporting Yubikey/PIV. Henry B (Hank) Hotz, CTO hhotz@securechannels.com (949) 679-5738
<<Apologies if you get this twice. I used the wrong return address the first time.>>
On Oct 30, 2015, at 9:05 AM, Disiena, Ridley (MSFC-IS60)[EAST] <ridley.disiena@nasa.gov> wrote:
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.
Since restarting Mail (without restarting anything in the card/keychain system) is a workaround, I think it’s reasonable to think the problem is in Mail, or in Mail’s use of keychain. However if there is some suspicion Yubikey support is an issue, then we should be reporting the PIV applet number on the Yubikey. There are several “in the wild”. I feel sure Yubikey will be responsive to bug reports with sufficient detail. Also I think 10.10 was when Apple began “officially” supporting Yubikey/PIV. Henry B (Hank) Hotz, CTO hhotz@securechannels.com (949) 679-5738 Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com
On Oct 30, 2015, at 14:57 , Henry B (Hank) Hotz, CISSP <hbhotz@oxy.edu> wrote:
On Oct 30, 2015, at 9:05 AM, Disiena, Ridley (MSFC-IS60)[EAST] <ridley.disiena@nasa.gov> wrote:
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.
Since restarting Mail (without restarting anything in the card/keychain system) is a workaround, I think it’s reasonable to think the problem is in Mail, or in Mail’s use of keychain.
Or in the Keychain API (whatever it is) itself - perhaps it enforces PIN-authentication for a “new” app, but “forgets” to do that for subsequent requests from the same app; so restarting Mail makes it a “new” app again, forces authentication again, etc.
However if there is some suspicion Yubikey support is an issue, then we should be reporting the PIV applet number on the Yubikey. There are several “in the wild”. I feel sure Yubikey will be responsive to bug reports with sufficient detail.
I’m aware of two: PIV applet 0.1.2 and 0.1.3. I’m having these issues with 0.1.3 - have not tried Mail with 0.1.2.
Also I think 10.10 was when Apple began “officially” supporting Yubikey/PIV.
??? But I use 10.10.5 anyway. -- Uri Blumenthal uri@mit.edu
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".
Pretty much. If you don't send VERIFY in the APDU immediately prior to the DSK operation, the PIV card applet should return an error (I don't have 800-73 in front of me, but you can look up the error). The tokend then handles that error. That's all integral to the PIV card data model. Non-conformance can happen at both ends, but I'm relatively certain that PIV.token and PKard.tokend are conformant (no offense to Sean or Paul :). Yubi's PIV applet is possibly suspect, not having been certified, but you know you can download NIST's PIV data model test tools, right? http://csrc.nist.gov/groups/SNS/piv/download.html I'd be more apt to believe a bug in Mail or securityd, however. -- T
On Oct 30, 2015, at 16:30 , Miller, Timothy J. <tmiller@mitre.org<mailto:tmiller@mitre.org>> wrote: ... If you don't send VERIFY in the APDU immediately prior to the DSK operation, the PIV card applet should return an error (I don't have 800-73 in front of me, but you can look up the error). The tokend then handles that error. That's all integral to the PIV card data model. OK, and that’s what NEO seems to require! Non-conformance can happen at both ends, but I'm relatively certain that PIV.token and PKard.tokend are conformant (no offense to Shawn or Paul :). Yubi's PIV applet is possibly suspect, not having been certified, OK, but if Yubi refuses to work without a PIN, and the PIN is not sent to it and the user is not prompted for for a PIN - how can Yubi be a suspect in this particular case? but you know you can download NIST's PIV data model test tools, right? http://csrc.nist.gov/groups/SNS/piv/download.html I will download it - though I suspect it requires Windows, which would make my ability to try it rather unlikely… I'd be more apt to believe a bug in Mail or securityd, however. I’m in complete agreement here. :-) -- Uri Blumenthal uri@mit.edu<mailto:uri@mit.edu>
On Oct 30, 2015, at 7:13 AM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote: 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.
I’m the one that suggested the workaround; the misattribution doesn’t bother me though. :) One thing I’ve found different with El Capitan is that it no longer seems necessary to uncheck the option to sign the email before saving the draft and restarting Mail. - David
participants (7)
-
Blumenthal, Uri - 0553 - MITLL
-
David Mueller
-
Disiena, Ridley (MSFC-IS60)[EAST]
-
Henry B (Hank) Hotz, CISSP
-
Henry Hotz
-
Miller, Timothy J.
-
Uri Blumenthal