Add support for ECC and SHA-2

[dengert]

EC keys can not decrypt. They can only sign and derive. OpenSCKeyHandle::decrypt calls sc_pkcs15_decipher his will not work with EC. Tokend may need a lot more code for ECDH. There is a CSSM_ALGCLASS_DERIVEKEY but it looks like OpenSC tokend does not support derivation. sc_pkcs15_derive

[mouse07410]

My quick test shows that it's working.

[frankmorgner]

@mouse07410 did you test signing only?

[mouse07410]

@frankmorgner yes I was able to test only signing.

I retrieved all the keys (RSA and ECC), but was not able to test ECC encryption/decryption because MS Outlook 2011 does not seem to support ECC algorithms, and Apple Mail has its own set of idiosyncrasies, such as forcing SHA1 for signatures regardless of what the certificate specifies (and it also seems to have problems with ECC).

The only app I semi-trust with ECC algorithms is Thunderbird - but it bypasses tokend for most (if not all) of its PKCS11 operations.

I am considering upgrade to MS Outlook 2016, maybe that would have better ECC support. Likewise, contemplating El Capitan...

EC keys can not decrypt. They can only sign and derive.

Strictly and theoretically - correct. In practice, EC El Gamal has been used for key transfer for quite a while. I agree that the computations are different.

OpenSCKeyHandle::decrypt calls sc_pkcs15_decipher this will not work with EC.

I don't know - as this is supposed to be done by/on the token itself.

Tokend may need a lot more code for ECDH.

That may well be so. But until there's reliable software that utilizes this capability, we can't be sure.

One test I am planning is to authenticate to a Web server protected by EC keys, using Safari and NEO with EC keys. Probably over this weekend... But don't hold me to it. :-)

[dengert]

On 11/27/2015 4:46 PM, Mouse wrote:

@frankmorgner https://github.com/frankmorgner yes I was able to test only signing.

I /retrieved/ all the keys (RSA and ECC), but was not able to test ECC encryption/decryption

ECC does not do encryption/decryption directly.

because MS Outlook 2011 does not seem to support ECC algorithms, and Apple Mail has its own set of idiosyncrasies, such as forcing SHA1 for signatures regardless of what the certificate specifies (and it also seems to have problems with ECC).

The only app I semi-trust with ECC algorithms is Thunderbird - but it bypasses tokend for most (if not all) of its PKCS11 operations.

I am considering upgrade to MS Outlook 2016, maybe that would have better ECC support. Likewise, contemplating El Capitan...

EC keys can not decrypt. They can only sign and derive.

Strictly and theoretically - correct. In practice,has been used for key transfer for quite a while. I agree that the computations are different.

EC El Gamal uses DH, which is what the derive does. Both parties derive a share secret, which can be used to derive a AES key for example.

You seam mostly interested in the PIV, which supports ECC CDH See 800-73-3 Part 3

A. 4.2.1 ECDH with the PIV KMK

"The PIV Card supports ECDH key agreement by performing the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive (see Section 5.7.1.2 of SP 800-56A [7]) using its ECC KMK private key and an ECC public key that is provided as input to the GENERAL AUTHENTICATE command. All other procedures required to complete the key agreement are performed by the cardholder’s client application and its associated cryptographic module."

The card supports the primitive as does the OpenSC implementation. Note the last line, the client application does the rest.

OpenSCKeyHandle::decrypt calls |sc_pkcs15_decipher| this will not work with EC.

I don't know - as this is supposed to be done by/on the token itself.

See above. A. 4.2.1 ECDH with the PIV KMK

Tokend may need a lot more code for ECDH.

That may well be so. But until there's reliable software that utilizes this capability, we can't be sure.

Yes we can. Don't call sc_pkcs15_decipher with a ECC key.

One test I am planning is to authenticate to a Web server protected by EC keys, using Safari and NEO with EC keys. Probably over this weekend...

See https://www.ietf.org/rfc/rfc4492.txt

         Elliptic Curve Cryptography (ECC) Cipher Suites
                for Transport Layer Security (TLS)

It can use ECDH_ECDSA for Key Exchange Algorithms.

— Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160223639.

Douglas E. Engert DEEngert@gmail.com

[mouse07410]

First, yes. I acknowledge that you are correct, and I wasn't.

You seam mostly interested in the PIV, which supports ECC CDH. See 800-73-3 Part 3

Yes. And thanks for the pointer!

The card supports the primitive as does the OpenSC implementation..... Note the last line, the client application does the rest.

I see. In your opinion, do we need more than calling sc_pkcs15_derive() if the algorithm is ECDH? Would you have a suggestion what the calling code should do? I'm a little confused about how much is supposed to be done by the application (like Safari or Mail), what should be done by the card itself, and what's left for the tokend - i.e., what functionality should be added here in decrypt() in OpenSCKeyHandle.cpp.

Don't call sc_pkcs15_decipher with a ECC key.

Yes I agree - based on what you explained, it would be a bad idea. The call should be made to sc_pkcs15_derive(), but as I said - I'm not sure what operations should surround that call. Would appreciate some help.

And it looks like with your help we can get complete ECC support in OpenSC.tokend.

[dengert]

Google for: s/mime encryption ECC

Google for: s/mime encryption NSS ECC outlook 2010

Google for: s/mime encryption safari

On 11/27/2015 9:08 PM, Mouse wrote:

First, yes. I acknowledge that you are correct, and I wasn't.

You seam mostly interested in the PIV, which supports ECC CDH. See 800-73-3 Part 3

Yes. And thanks for the pointer!

The card supports the primitive as does the OpenSC implementation.....
Note the last line, the client application does the rest.

I see. In your opinion, do we need more than calling |sc_pkcs15_derive()| if the algorithm is ECDH? Would you have a suggestion what the calling code should do? I'm a little confused about how much is supposed to be done by the application (like Safari or Mail), what should be done by the card itself, and what's left for the tokend - i.e., what functionality should be added here in |decrypt()| in |OpenSCKeyHandle.cpp|.

Don't call sc_pkcs15_decipher with a ECC key.

Yes I agree - based on what you explained, it would be a bad idea. The call should be made to |sc_pkcs15_derive()|, but as I said - I'm not sure what operations should surround that call. Would appreciate some help.

And it looks like with your help we can get complete ECC support in OpenSC.tokend.

— Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160242998.

Douglas E. Engert DEEngert@gmail.com

[mouse07410]

Doug, my apologies, but I don't see what point you're trying to make, or what info to provide:

Google for: s/mime encryption ECC

Results show that there are a few RFCs dated from 1999 to 2011, defining ECC formats in S/MIME. I find RFC 6318 particularly nice. But I don't see how it helps with the issue discussed here. If you considered that info relevant, I'd appreciate a brief explanation how.

Google for: s/mime encryption NSS ECC outlook 2010

Sorry to say, found nothing useful in the provided results. Yeah, Mozilla NSS seems to support ECC. Knew that. But NSS code is a PITA to work with - I've ported it once to Snow Leopard, considered doing it again for Yosemite, gave up. MS Outlook does not (and did not) support ECC on Mac, moving to Outlook 2016 won't help. There was a simpler way to find that out: https://technet.microsoft.com/en-us/library/jj984207(v=office.16).aspx

If there was something helpful for this work (which is making OpenSC.tokend support ECC S/MIME for those apps that both: can use S/MIME and ECC, and need tokend service) that the results of this search were supposed to provide - would you please point at it directly?

Google for: s/mime encryption safari

Not only the results appeared semi-relevant and quite outdated, but some of them (e.g., 5th from the top) mislead (give incorrect guidance). Again, what was the info here that you considered useful?

To summarize.

1. S/MIME is supported to a different extent on many platforms and by many applications. Some of them interoperate. Since this is about tokend on Mac OS X - we should constrain ourselves to that one platform (as no other platform can possibly care for a tokend app). Two apps that are proven (I have first-hand experience with that) to work with ECC crypto on Mac OS X (Firefox and Thunderbird) do not use tokend (or if they do, it's minimal, with most of the "heavy lifting" is done via PKCS11 library, in our case opensc-pkcs11.so).
2. RSA signatures work with SHA-2 (tested with SHA-256) on MS Outlook 2011. Cannot test SHA-2 on Apple Mail because Apple Mail forces SHA-1for signatures no matter what.
3. It appears that on Mac OS X ECC in S/MIME is fully and correctly supported only by Thunderbird, and that doesn't help our tokend work, for the reason mentioned above (except maybe for cross-testing if/when we find a tokend-using app that does S/MIME). I am trying to figure out experimentally/empirically how much of ECC Apple Mail actually supports - at this time and with some bug fixes to tokend, Apple Mail does sign using ECC keys/certs, but the resulting signature is bad (consistently fails to verify).
4. I think it still makes sense to fix and/or enhance the OpenSC.tokend code to make it support ECC, hoping that (a) it would be useful when an ECC-capable S/MIME-supporting app comes up on OS X, and (b) if Apple Mail can work with ECC identities, tokend would help here too.

[dengert]

On 11/28/2015 10:27 PM, Mouse wrote:

Doug, my apologies, but I don't see what point you're trying to make, or what info to provide:

Google for: s/mime encryption ECC

Results show that there are a few RFCs dated from 1999 to 2011, defining ECC formats in S/MIME. I find RFC 6318 https://tools.ietf.org/html/rfc6318 particularly nice. But I don't see how it helps with the issue discussed here. If you considered that info relevant, I'd appreciate a brief explanation how.

The point is s/mine is the standard used in all the mail programs and most of the work is done in the mail client, not in OpenSC. Only the primitive ECDH is done there. ECDH derive requires the public key from the recipiant or the public key of some ephermial key created by the mail program to be provided to the tokend, then to OpenSC via sc_pkcs15_derive.

Google for: s/mime encryption NSS ECC outlook 2010

Sorry to say, found nothing useful in the provided results. Yeah, Mozilla NSS seems to support ECC. Knew that. But NSS code is a PITA to work with - I've ported it once to Snow Leopard, considered doing it again for Yosemite, gave up. MS Outlook does not (and did not) support ECC on Mac, moving to Outlook 2016 won't help. There was a simpler way to find that out: https://technet.microsoft.com/en-us/library/jj984207(v=office.16).aspx

The above I had not seen. With the NSS, there were comments about Outlook not following the smime or ECDH standards, and the author (whose name also apppears on many NIST documents) had a circumvention for NSS to get around the Microsoft problem. Insite into the problem might help with tokend.

If there was something helpful for this work (which is making OpenSC.tokend support ECC S/MIME for those apps that both: can use S/MIME and ECC, and need tokend service) that the results of this search were supposed to provide - would you please point at it directly?

Google for: s/mime encryption safari

Not only the results appeared semi-relevant and quite outdated, but some of them (e.g., 5th from the top) mislead (give incorrect guidance). Again, what was the info here that you considered useful?

Many things returned by a search may not be revelent. Outdated maybe, but ECC has been around for years, and it is takes years to get it into applications and middleware. Searching for Safari should show what standards it and the web server you are refering to are using that could authenticate and encrypt the session. The TLS RFC would be the one. Two certificates and keys would be used, the authentication part does a signature and could use RSA or ECDSA. The encrypt part could use RSA to encrypt an AES key, or use ECDH to derived a share secret which could be a AES key. With the PIV, these two keys/certificates are the Authentication and Key Management Keys, others might use the same certificate but is not recommended as I thing there security risks in using the same key for both.

So we are back to what is the Apple API to tokend for ECDH? Does it support ECDH at all? It may not be there!

https://developer.apple.com/library/mac/documentation/Security/Conceptual/cryptoservices/CDSA/CDSA.html Says: "Important: This technology is deprecated in OS X v10.7 and is not available in iOS. You should use it only if none of the other cryptographic service APIs support what you are trying to do."

If the API that tokend is using does not support ECDH, then there is nothing we can do about it if applications have no API to call.

You will have to look closer at the CSSM CDSA to see if it does define a Derive function.

If it does not, what is the replacement for tokend?

To summarize.

1. S/MIME is supported to a different extent on many platforms and by many applications. Some of them interoperate. Since this is about tokend on Mac OS X - we should constrain ourselves to that one platform (as no other platform can possibly care for a tokend app). Two apps that are /proven/ (I have first-hand experience with that) to work with ECC crypto on Mac OS X (Firefox and Thunderbird) do not use tokend (or if they do, it's minimal, with most of the "heavy lifting" is done via PKCS11 library, in our case |opensc-pkcs11.so|).
2. It appears that on Mac OS X ECC in S/MIME is fully supported only by Thunderbird, and that doesn't help our tokend work, for the reason mentioned above (except maybe for cross-testing if/when we find a tokend-using app that does S/MIME). I am trying to figure out /experimentally/empirically/ how much of ECC Apple Mail actually supports.
3. I think it still makes sense to fix and/or enhance the OpenSC.tokend code to make it support ECC, hoping that (a) it would be useful when an ECC-capable S/MIME-supporting app comes up on OS X, and (b) if Apple Mail can work with ECC identities, tokend would help here too.

Unless you can find the API in CSSM for ECDH, rather then (3) it might be time to write the replacement for Tokend.

— Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160369651.

Douglas E. Engert DEEngert@gmail.com

[mouse07410]

With the NSS, there were comments about Outlook not following the smime or ECDH standards, and the author (whose name also apppears on many NIST documents) had a circumvention for NSS to get around the Microsoft problem. Insight into the problem might help with tokend.

I see. Perhaps you can post a pointer at the most detailed in your opinion description of the NSS fix. Though frankly I suspect it won't apply here, as it seems that Outlook on Mac does not support ECC at all, rather than having a buggy support (like on Windows where as I understand the original NSS escapade was performed).

So we are back to what is the Apple API to tokend for ECDH?

I'm afraid so. Without being able to peek into the exchange between the application and the tokend, we'd stay semi-blind. There's only so much to discern from the tokend <-> card exchanges...

Does it support ECDH at all? It may not be there!

I suspect/hope that it does. Most of the Apple software been supporting ECC for a few versions, and EC definitions are in those CSSM header files. Not a guarantee by any means, but a good sporting chance, IMHO. :-)

Unless you can find the API in CSSM for ECDH, rather then (3) it might be time to write the replacement for Tokend.

Ah, I'd love to see this tokend replaced - but who has enough time + skills + knowledge to do that monstrous job? Conceptually that would be the right thing to do because tokend and CDSA are deprecated. But re-writing so much for the new framework is definitely more than I can take on, probably true for many others as well...

ECDH derive requires the public key from the recipiant or the public key of some ephemeral key created by the mail program to be provided to the tokend, then to OpenSC via sc_pkcs15_derive.

Yes. So for S/MIME encryption we need to figure out what exactly tokend receives from the app, then "package" it appropriately for sc_pkcs15_derive, and figure how to package the card response back to the calling app.

Summary

1. This pull should be merged, because SHA-2 parts of it work, and ECC parts are necessary though insufficient on their own. So let's merge it, to at least enable SHA-2 support, and pave way for the future ECC fixes.
2. ECDSA signature requires more work, as I discovered additional issues listed in https://github.com/OpenSC/OpenSC/issues/570. Help is requested.
3. ECDH requires more work, and at the moment it is unclear how to proceed there, unless we can tap into the Mail/Safari/Chrome <-> Tokend communications.

[frankmorgner]

I don't fully disagree, we should take some time to resolve the ECC issues.

[dengert]

This is not ready. It still tries to use SC_ALGORITHM_ECDH_CDH_RAW with sc_pkcs15_decipher whihc will nogt work. The ECDSA is not getting the field_lenght correctly and the signature returned is wrong. Please see last few comments in #570 on hwo to use sc_sc_asn1_sig_value_rs_to_sequence

[mouse07410]

This is not ready.

I disagree. It certainly does not provide a complete/working ECC support. But it is a good step forward.

Let's merge this PR, because it (a) provides working functionality (SHA-2 support), and (b) paves the way for working ECC - though doesn't yet accomplish it.

It still tries to use SC_ALGORITHM_ECDH_CDH_RAW with sc_pkcs15_decipher which will not work.

Yes, we agreed on this. However, do we have the parameters to feed to sc_pkcs15_derive()? If so, could you please point me at them? Regardless, with this patch ECDH support isn't any worse than without it. :-)

The ECDSA is not getting the field_lenght correctly and the signature returned is wrong.

In my patches (the version I run) the field_length returned is perfect - check the logs in the previous posts. The signature sure is wrong, no two ways about it. But it certainly isn't any worse than before!

Please see last few comments in #570 on how to use sc_sc_asn1_sig_value_rs_to_sequence

Yes, I am going to try that next.

To summarize

This PR is not perfect, and does not address all the problems. But IMHO it adds enough useful/usable stuff (SHA-2, and beginning of recognition of ECC to branch its processing off) to deserve being merged. Plus, I'm tired of working off my own clone. And it's bloody inconvenient to keep switching between my clone and the "main" one, to test commits, etc. So let's merge incremental improvements.

[dengert]

I think we are close to getting ECDSA working. I would wait for two days so we can get it all working.

On 11/29/2015 9:13 PM, Mouse wrote:

This is not ready.

I disagree. It certainly does not provide a complete/working ECC support. But it is a good step forward.

Let me briefly review the history.

1. OpenSC.tokend plain sucked on PIV cards - did not even unlock them. The only good thing to say about it was that it could compile. OK, a patch came (in two stages, if memory serves me) that made it reliably lock & unlock PIV tokens. Did it actually work fully with those tokens? Not really, but it was a necessary step.
2. No RSA signature worked unless it was with MD5 (currently prohibited) or SHA1 hash. This patch addresses this issue 100%. However ECC keys don't exist as far as this tokend is concerned.
3. OK, this patch makes tokend recognize and accept ECC keys in addition to RSA keys. ECC keys are now recognized with 100% success. However, tokend still thinks that the only possible signatures are RSA-based.
4. OK, this patch adds recognition of ECDSA, and alongside of it - of ECDH key derivation. Tokend now produces ECDSA signatures, and starts dealing with ECDH key derivation. ECDSA signatures produced are wrong (we don't know why/how yet - possibly @dengert https://github.com/dengert is onto something wrt. ASN.1 wrapping of what |compute_signature| returns. ECDH does not call the correct method yet, and it is even unclear what the parameters for the correct one would be (whether we have them at the place & time we need them).

Based on the above - I say let's merge this PR, because it (a) provides working functionality (SHA-2 support), and (b) paves the way for working ECC - though doesn't yet accomplish it.

It still tries to use SC_ALGORITHM_ECDH_CDH_RAW with sc_pkcs15_decipher
which will not work.

Yes, we agreed on this. However, do we have the parameters to feed to |sc_pkcs15_derive()|? If so, could you please point me at them? Regardless, with this patch ECDH support isn't any worse than without it. :-)

The ECDSA is not getting the field_lenght correctly and the signature returned is wrong.

In my patches (the version I run) the field_length returned is perfect - check the logs in the previous posts. The signature sure is wrong, no two ways about it. But it certainly isn't any worse than before!

Please see last few comments in #570 on how to use sc_sc_asn1_sig_value_rs_to_sequence

Yes, I am going to try that next.

To summarize

This PR is not perfect, and does not address all the problems. But IMHO it adds enough useful/usable stuff (SHA-2, and beginning of recognition of ECC to branch its processing off) to deserve being merged. /Plus, I'm tired of working off my own clone. And it's bloody inconvenient to keep switching between my clone and the "main" one, to test commits, etc. So let's merge incremental improvements./

— Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160505923.

Douglas E. Engert DEEngert@gmail.com

[mouse07410]

I think we are close to getting ECDSA working. I would wait for two days so we can get it all working.

I think you are right. Stand by.

[mouse07410]

OK, ECDSA signatures are working now. Apple Mail happily produces them, Thunderbird and MS Outlook 2011 confirm that they are valid. Unfortunately, Outlook always asks for CSSM_ALGID_RSA regardless of whether the keys are RSA or ECC. Perhaps I can hack tokend to force ECDSA in such case based upon the type of the PRKEY. Would you agree that it's useful?

https://github.com/OpenSC/OpenSC/issues/570 contains the code changes to get ECDSA working.

ECDH next! :-)

P.S. Doug, you were right - we don't need to wait even for two days to get ECDSA. :-)

[mouse07410]

Question: to hack tokend to support MS Outlook, I may need to "forcefully" replace ALGID stored in Context. How do I do it? Reason - down the line in pkcs15-sec.c some things are decided based upon the context rather than on the key type. To limit the hack to OpenSCKeyHandle.cpp, I need to preempt that and replace CSSM_ALGID_RSA with CSSM_ALGID_ECDSA when the key is of ...PRKEY_EC type.

Guidance, please?

[frankmorgner]

Don't hack OpenSC to support Outlook. Who uses Outlook on Mac anyway?

[mouse07410]

Who uses Outlook on Mac? Two kinds of users:

• Those who need the MS Exchange-integrated Calendar capabilities, signatures with hash other than SHA-1, and the ability to select what S/SIME cents to use - typically at work.
• Those who do not want to restart their Mail client before sending the next signed message - both home and office users.

Sent from my iPad

On Nov 30, 2015, at 03:43, Frank Morgner notifications@github.com<mailto:notifications@github.com> wrote:

Don't hack OpenSC to support Outlook. Who uses Outlook on Mac anyway?

— Reply to this email directly or view it on GitHubhttps://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160556591.

[dengert]

I don't understand, where in pkcs15-sec.c does it look at the context? My C++ is not good. I have no idea, and it may not work if you change the type anyway.

On 11/29/2015 11:52 PM, Mouse wrote:

Question: to hack tokend to support MS Outlook, I may need to "forcefully" replace ALGID stored in Context. How do I do it? Reason - down the line in |pkcs15-sec.c| some things are decided based upon the context rather than on the key type. To limit the hack to |OpenSCKeyHandle.cpp|, I need to preempt that and replace |CSSM_ALGID_RSA| with |CSSM_ALGID_ECDSA| when the key is of |...PRKEY_EC| type.

Guidance, please?

— Reply to this email directly or view it on GitHub https://github.com/OpenSC/OpenSC.tokend/pull/21#issuecomment-160524114.

Douglas E. Engert DEEngert@gmail.com

[frankmorgner]

As reported in https://github.com/frankmorgner/OpenSC.tokend/pull/4#issuecomment-161514062, RSA signature do not seem to work anymore. Since I cannot reproduce/test this, I'll close this PR until someone comes up with a better PR.

[mouse07410]

I'll close this PR until someone comes up with a better PR.

In my humble opinion, a better PR was the one before refactoring - because it worked fine.