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

Fri Oct 30 11:35:30 PDT 2015

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 at lists.macosforge.org on behalf of
Blumenthal, Uri - 0553 - MITLL"
<smartcardservices-users-bounces at lists.macosforge.org on behalf of
uri at 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
>

-------------- 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/20151030/d0b49700/attachment.bin>