Re: [Opensc-devel] CardOS 5.3 driver

[Jakub J. <jj...@re...>]

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 <jj...@re...
> <mailto:jj...@re...>> 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