CardOS 5.3 driver

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CardOS 5.3 driver

Jakub Jelen
Hello all,
we got several CardOS 5.3 cards that I tried to implement support for in
OpenSC. The initial detection is already merged [1].

The approach used CardOS 5.0 was not working everywhere so before
submitting the pull request with all the changes, I would like to hear
some feedback on some questionable parts and preferable verify that the
changes are not breaking anything that worked with CardOS 5.0 as
originally implemented years ago (adding szikora, who implemented
initial CardOS 5.0 support in PR#170) or if some of the concepts in new
cards work also in the old ones.

All changes are in my branch [2] are in four commits

The first two make the signatures working:
  * Separately detect 5.3 version and use p1 = 0x41 for security
environment -- will it work also in the old cards?
  * Remove SC_ALGORITHM_NEED_USAGE which prevented using
cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need
that?

The last two changes are more hackish and used to make decipher
mechanisms working (it looks like the card strips all the padding). Or
is there any possibility to disable in OpenSC RSA_X_509 raw decipher
mechanisms for this driver?

Comments, thoughts?

[1] https://github.com/OpenSC/OpenSC/commit/ac96e73
[2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53

Regards,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CardOS 5.3 driver

Douglas E Engert
In regards to RSA_X_509, it may be the algorithm flags are wrong. 

 An RSA_X_509 operation to a card can be the same operation used to sign a padded block the size of the key, or to decrypt a key size block and return the results, without removing any padding, which allows for using other other padding mechanisms. 

It could also be the senv is setting flags that tell the card to remove the padding whenit should not, or the card can not do RSA_X_509.  

It would be interesting to see an opensc-debug.log for     sc_pkcs15_decipher  
when it calls sc_get_encoding_flags in padding.c



On Fri, Mar 17, 2017 at 6:38 AM, Jakub Jelen <[hidden email]> wrote:
Hello all,
we got several CardOS 5.3 cards that I tried to implement support for in
OpenSC. The initial detection is already merged [1].

The approach used CardOS 5.0 was not working everywhere so before
submitting the pull request with all the changes, I would like to hear
some feedback on some questionable parts and preferable verify that the
changes are not breaking anything that worked with CardOS 5.0 as
originally implemented years ago (adding szikora, who implemented
initial CardOS 5.0 support in PR#170) or if some of the concepts in new
cards work also in the old ones.

All changes are in my branch [2] are in four commits

The first two make the signatures working:
  * Separately detect 5.3 version and use p1 = 0x41 for security
environment -- will it work also in the old cards?
  * Remove SC_ALGORITHM_NEED_USAGE which prevented using
cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need
that?

The last two changes are more hackish and used to make decipher
mechanisms working (it looks like the card strips all the padding). Or
is there any possibility to disable in OpenSC RSA_X_509 raw decipher
mechanisms for this driver?

Comments, thoughts?

[1] https://github.com/OpenSC/OpenSC/commit/ac96e73
[2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53

Regards,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CardOS 5.3 driver

Jakub Jelen
On 03/19/2017 10:30 PM, Douglas E Engert wrote:
> In regards to RSA_X_509, it may be the algorithm flags are wrong.
>
>  An RSA_X_509 operation to a card can be the same operation used to sign
> a padded block the size of the key, or to decrypt a key size block and
> return the results, without removing any padding, which allows for using
> other other padding mechanisms.

The cardos driver has its method to compute signature, which works with
a little bit of guesswork [1] what method will be available and in case
in the need of the others, it fixes the padding, if I read the comments
and code right. This can not be used by the decryption, because you
don't know what random bytes were added as a padding while encrypting.

> It could also be the senv is setting flags that tell the card to remove
> the padding whenit should not, or the card can not do RSA_X_509.
>
> It would be interesting to see an opensc-debug.log for
>  sc_pkcs15_decipher
> when it calls sc_get_encoding_flags in padding.c

Without the first commit in my branch it fails during setting up
security environment [2].

After adding this commit, RSA_X_509 mechanism succeeds and RSA_PKCS
fails (the logs also in the linked gist [2]). In the readme, there are
also command I used to create the encrypted data using OpenSSL (in case
there could go something wrong, though the tests were performed also
with the same testsuite I use for other cards).

Let me know if you want the whole logs.

[1]
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L888
[2]
https://gist.github.com/Jakuje/5a993d2b2d8a9cac35203599e49e6831#file-opensc-master-log

Jakub

> On Fri, Mar 17, 2017 at 6:38 AM, Jakub Jelen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello all,
>     we got several CardOS 5.3 cards that I tried to implement support for in
>     OpenSC. The initial detection is already merged [1].
>
>     The approach used CardOS 5.0 was not working everywhere so before
>     submitting the pull request with all the changes, I would like to hear
>     some feedback on some questionable parts and preferable verify that the
>     changes are not breaking anything that worked with CardOS 5.0 as
>     originally implemented years ago (adding szikora, who implemented
>     initial CardOS 5.0 support in PR#170) or if some of the concepts in new
>     cards work also in the old ones.
>
>     All changes are in my branch [2] are in four commits
>
>     The first two make the signatures working:
>       * Separately detect 5.3 version and use p1 = 0x41 for security
>     environment -- will it work also in the old cards?
>       * Remove SC_ALGORITHM_NEED_USAGE which prevented using
>     cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need
>     that?
>
>     The last two changes are more hackish and used to make decipher
>     mechanisms working (it looks like the card strips all the padding). Or
>     is there any possibility to disable in OpenSC RSA_X_509 raw decipher
>     mechanisms for this driver?
>
>     Comments, thoughts?
>
>     [1] https://github.com/OpenSC/OpenSC/commit/ac96e73
>     <https://github.com/OpenSC/OpenSC/commit/ac96e73>
>     [2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53
>     <https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53>
>
>     Regards,
>     --
>     Jakub Jelen
>     Software Engineer
>     Security Technologies
>     Red Hat
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>     <https://lists.sourceforge.net/lists/listinfo/opensc-devel>
>
>


--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CardOS 5.3 driver

Jakub Jelen
On 03/20/2017 06:08 PM, Douglas E Engert wrote:

> First of all, I can not do much until late next week.
>
> What I was pointing out is  sc_get_encoding_flags  takes the algorithm
> flags and breaks them apart into what the card is expected to do, and
> what OpenSC software will do. i.e. who adds/removes the padding. The
> card's senv routine can then tell the card what it needs to do. The
> algorithm flags should only indicate what the card (or the card driver)
> can do . I hope you would find the debugging messages useful  so you
> could set the algorithm flags to match what the card and card driver and
> its senv routine can do.
>
> There may be a difference is the term RAW. From the PKCS#11
> CKM_RSA_X_509 the input and output will both be the key size and the
> calling application will do all hashing and padding for both sign and
> decrypt, If the card(and driver) can not do this, then the CKM_RSA_X_509
> should not be registered.
>
> Actually PKCS#11 mechanisms also have a HW flag, indicating the
> mechanism is preformed in hardware, so claiming it is hardware, but
> doing parts in the driver can be misleading to an application.
>
> It sounds like the card has  SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED
> and  SC_CARD_CAP_ONLY_RAW_HASH. These do not sound like CKM_RSA_X_509
> to me but more about does the card expect the hash to be stripped or not.

Thank you for your time. I played a bit more with the flags specified in
the cardos_init() and managed to "turn off" the RSA_X_509 mechanism by
specifying SC_ALGORITHM_RSA_PAD_PKCS1 (other mechanisms stays intact).

https://github.com/Jakuje/OpenSC/commit/489508cf

This has a "side effect" of disabling the RSA_X_509 mechanisms also for
the signatures, but that should not be a big deal, because the signature
routine has also some hacks to strip padding from data for signatures in
case it fails sign data with padding.

I am not sure if this even worked in older CardOS cards. I will fill a
pull request with the changes so far and try to ping people who
contributed parts of CardOS drivers, if they can verify functionality
with their cards (or if this can be changed in older versions too).

Thanks,
Jakub

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CardOS 5.3 driver

Jakub Jelen
On 03/22/2017 03:20 PM, Douglas E Engert wrote:
> Th card driver has been there a long time, but could have only worked
> for signatures and not decrypt.  Many older cards only would only create
> signatures.

According to Frank on Github (where is the final change)[1], the
encryption works with CardOS 4.3B (as well as the RSA_X_509). We still
miss the missing part how the 5.0 version work.

> Also look at the card's set_security_env  routine at what flags it sets.
> There is an ISO document that defines flags for set security env, and if
> you have the manufactures document, you can compare what their card
> supports.

It is probably ISO 7816, but it is not public available. Also I don't
have any documentation from the manufacturer (nor I was able to find
anything online). But I guess if I had some documentation, I would have
to sign NDA and the changes would end up similarly as #283 [2].

> It may or may not support CKM_X_509. I am not at home and don't have
> access to the document to tell you its name.

If you will have a look at this when you will get home, it would great.
One of the theories worded by Robert Relyea was that this card might not
even support this mechanism, because it should be needed only for SSL 2.0

> The problem sounds similar to Nono's card, that could take any hash with
> digest header less then 36 bytes, but to support SHA256 one had to send
> a flag to tell the card the data being sent was just the 32 bytes of the
> hash, and card had to put in the SHA256 digest header before padding.
> His card, PTeid using card-gemsafeV1.c  did not support CKM_X_509, as
> the card always wanted to do the PKCS1 padding.

Anyway, not sure if it was intentional you are dropping the opensc-devel
mailing list from the CC (instead of reply-all). I don't think there is
anything non-public, so I am adding CC back.

[1] https://github.com/OpenSC/OpenSC/pull/1003
[2] https://github.com/OpenSC/OpenSC/pull/283

Thank you,
Jakub


> On Wed, Mar 22, 2017 at 4:10 AM, Jakub Jelen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 03/20/2017 06:08 PM, Douglas E Engert wrote:
>
>         First of all, I can not do much until late next week.
>
>         What I was pointing out is  sc_get_encoding_flags  takes the
>         algorithm
>         flags and breaks them apart into what the card is expected to
>         do, and
>         what OpenSC software will do. i.e. who adds/removes the padding. The
>         card's senv routine can then tell the card what it needs to do. The
>         algorithm flags should only indicate what the card (or the card
>         driver)
>         can do . I hope you would find the debugging messages useful  so you
>         could set the algorithm flags to match what the card and card
>         driver and
>         its senv routine can do.
>
>         There may be a difference is the term RAW. From the PKCS#11
>         CKM_RSA_X_509 the input and output will both be the key size and the
>         calling application will do all hashing and padding for both
>         sign and
>         decrypt, If the card(and driver) can not do this, then the
>         CKM_RSA_X_509
>         should not be registered.
>
>         Actually PKCS#11 mechanisms also have a HW flag, indicating the
>         mechanism is preformed in hardware, so claiming it is hardware, but
>         doing parts in the driver can be misleading to an application.
>
>         It sounds like the card has  SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED
>         and  SC_CARD_CAP_ONLY_RAW_HASH. These do not sound like
>         CKM_RSA_X_509
>         to me but more about does the card expect the hash to be
>         stripped or not.
>
>
>     Thank you for your time. I played a bit more with the flags
>     specified in the cardos_init() and managed to "turn off" the
>     RSA_X_509 mechanism by specifying SC_ALGORITHM_RSA_PAD_PKCS1 (other
>     mechanisms stays intact).
>
>     https://github.com/Jakuje/OpenSC/commit/489508cf
>     <https://github.com/Jakuje/OpenSC/commit/489508cf>
>
>     This has a "side effect" of disabling the RSA_X_509 mechanisms also
>     for the signatures, but that should not be a big deal, because the
>     signature routine has also some hacks to strip padding from data for
>     signatures in case it fails sign data with padding.
>
>     I am not sure if this even worked in older CardOS cards. I will fill
>     a pull request with the changes so far and try to ping people who
>     contributed parts of CardOS drivers, if they can verify
>     functionality with their cards (or if this can be changed in older
>     versions too).
>
>     Thanks,
>     Jakub
>
>


--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel