OpenSC staging branch

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

OpenSC staging branch

Jean-Michel Pouré - GOOZE
Dear all,

There seems to be a lot of development in OpenSC staging branch:
https://github.com/OpenSC/OpenSC/commits/staging?page=1

What is the required way to make a commit? Fork and make a pull request?
Can you confirm we are back to GIThub normal process?

Thanks!
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Viktor Tarasov-3
Le 04/06/2012 19:22, Jean-Michel Pouré - GOOZE a écrit :
> Dear all,
>
> There seems to be a lot of development in OpenSC staging branch:
> https://github.com/OpenSC/OpenSC/commits/staging?page=1
>
> What is the required way to make a commit? Fork and make a pull request?
> Can you confirm we are back to GIThub normal process?

Currently we are gathering pending proposals in the 'staging' branch of OpenSC/OpenSC github project.
This branch is connected to CI service (https://opensc.fr/jenkins).

Currently the right the way for proposals is fork -> change -> pull-request.

For a while the review of proposals is slightly simplified.
One reason is the stagnation of proposal admission process during the preceding period --
a lot of proposals were waiting in purgatory for a long time.
Next reason is that the pull requests in github are not yet connected to CI service
and so the only way to compile/test proposal on different platforms is to be included to 'staging'.

I will try to connect the github pull requests to jenkins.
If no, probably we should return to the using of gerrit.

Kind regards,
Viktor.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Jean-Michel Pouré - GOOZE
Dear Viktor,

Nice work!

> Currently the right the way for proposals is fork -> change ->
> pull-request.
OK.

> I will try to connect the github pull requests to jenkins.
I will compile packages for staging for Debian, Ubuntu and Mac OS X.

Kind regards,
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Frank Morgner
Uh, I think I am a bit late on this discussion...

But I wanted to add a general concern that there are some conceptual
problems with the SM branch (and the recently included patches in
staging).

1. Global SM configuration is mixed with a configuration at the driver
   level. For example, look at [3]. It includes CWA, IAS/ECC data types
   which should be realized at the card driver level (or maybe some SM
   driver).
2. There are at least two methods to hook into SM, using a SM module and
   implementing SM at the driver level. This conceptually introduces
   duplication. It is sure to be followed with code duplication. Both
   should be unified: Each card driver has a SM driver, which provides
   wrapping and unwrapping SM. A SM driver can then also be a SM module
   with external key sets.
3. As stated earlier, I am advocating for an additional abstraction
   between encoding and encryption. Thus, a SM driver would only
   implement encoding, offering an other abstraction to the crypto.
   Not implementing this abstraction has led to code duplication [1].
   And reinventing the wheel will continue, when all ISO-7816-like
   cards [2, for example] (or modules) offer their own implementation
   of:
   - TLV-encoding/decoding of cryptogram (with padding content
     indicator), mac and le (depending on the APDU case)
   - ISO padding of APDU header and data
4. General problems with code quality:
   - A lot of dead code pieces ("#if 0")
   - Usage of global switches instead of switches in the card context
   - No or wrong documentation of the SM stuff
   - directory "sm" should be renamed to "sm-modules"

These issues, I think, disqualify the SM branch to be included in
OpenSC's trunk.

The biggest problem, I think is the coexistance of two independant SM
hooks. In general I dislike the concept of a SM module, because all
OpenSC initialization magic is lost, when only the APDU buffer is passed
to the module. If a module is only used for external keysets, then it
should do only encrypting/decrypting/authenticating instead of handling
the whole smart card stuff. Then, what you get is OpenSC that handles
smart card stuff, including SM encoding and a crypto layer with loadable
modules.

[1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html
[2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c
[3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Viktor Tarasov-3
Le 10/06/2012 14:21, Frank Morgner a écrit :

> Uh, I think I am a bit late on this discussion...
>
> But I wanted to add a general concern that there are some conceptual
> problems with the SM branch (and the recently included patches in
> staging).
>
> 1. Global SM configuration is mixed with a configuration at the driver
>    level. For example, look at [3]. It includes CWA, IAS/ECC data types
>    which should be realized at the card driver level (or maybe some SM
>    driver).

In [3] there is no IAS/ECC types.
There are data types related to the two more-or-less different SM implementations: GlobalPlatform and CWA.
It's not card specific.


> 2. There are at least two methods to hook into SM, using a SM module and
>    implementing SM at the driver level. This conceptually introduces
>    duplication. It is sure to be followed with code duplication. Both
>    should be unified: Each card driver has a SM driver, which provides
>    wrapping and unwrapping SM. A SM driver can then also be a SM module
>    with external key sets.

Was it a question?
Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and 'ACL' mode.

Duplication can happen due to fact that each card driver implement SM as it wants,
and can include into card specific part entire SM crypto library.

I do not contest that duplication can happen, but:
- it should not be obstacle to the implementation;
- please point out exactly, where in code you see duplication.



> 3. As stated earlier, I am advocating for an additional abstraction
>    between encoding and encryption. Thus, a SM driver would only
>    implement encoding, offering an other abstraction to the crypto.
>    Not implementing this abstraction has led to code duplication [1].
>    And reinventing the wheel will continue, when all ISO-7816-like
>    cards [2, for example] (or modules) offer their own implementation
>    of:
>    - TLV-encoding/decoding of cryptogram (with padding content
>      indicator), mac and le (depending on the APDU case)
>    - ISO padding of APDU header and data

As stated ealier, every card driver (at least at the beginning) can do roughly what it wants inside it's card specific part.
We have only started to introduce the common SM framework, and for a while,
we will not blame the card driver if it includes it's own SM related crypto procedures
(... and thus duplicates the code. Is that the code duplication that you are talking about?

> 4. General problems with code quality:
>    - A lot of dead code pieces ("#if 0")

You mean the SM part or entire code base of OpenSC.


>    - Usage of global switches instead of switches in the card context

What do you mean?


>    - No or wrong documentation of the SM stuff
>    - directory "sm" should be renamed to "sm-modules"

...

> These issues, I think, disqualify the SM branch to be included in
> OpenSC's trunk.
>
> The biggest problem, I think is the coexistance of two independant SM hooks.

You simply cannot cover all SM use cases with one low level SM wrapping method.
But understand you quite well -- you know/use only this one.


> In general I dislike the concept of a SM module, because all
> OpenSC initialization magic is lost, when only the APDU buffer is passed
> to the module. If a module is only used for external keysets, then it
> should do only encrypting/decrypting/authenticating instead of handling
> the whole smart card stuff.
External module do not handle all the smart card staff, but it has to do part of it.
Example: when importing, the RSA key has to be presented by a sequence of 5-7 APDUs, which could be different for the different cards.
So, external module has to be able to compose the plain APDUs .


> Then, what you get is OpenSC that handles
> smart card stuff, including SM encoding and a crypto layer with loadable
> modules.

Sorry, do not understood.


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Frank Morgner
On Sunday, June 10 at 03:39PM, Viktor Tarasov wrote:

> Le 10/06/2012 14:21, Frank Morgner a écrit :
> > Uh, I think I am a bit late on this discussion...
> >
> > But I wanted to add a general concern that there are some conceptual
> > problems with the SM branch (and the recently included patches in
> > staging).
> >
> > 1. Global SM configuration is mixed with a configuration at the driver
> >    level. For example, look at [3]. It includes CWA, IAS/ECC data types
> >    which should be realized at the card driver level (or maybe some SM
> >    driver).
>
> In [3] there is no IAS/ECC types.
> There are data types related to the two more-or-less different SM
> implementations: GlobalPlatform and CWA.  It's not card specific.
Well, well... I copied "CWA, IAS/ECC data types" from
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h:133.
If there are no IAS/ECC types, it shows how wrong the documentation is.
(By the way, there *is* some function called
`iasecc_sm_external_authentication`, line 342)

However, sm.h still requires you to know cwa structures and gp
structures. This is typically what you would want to abstract with a SM
layer. Look at opensc.h and cards.h, which offer a similar abstraction
to the smart card driver. If you add a smart card driver to opensc, you
only have to add sc_get_yourcard_driver to card.h and add it to
internal_card_drivers in ctx.c. Effectively, you have to add only two
lines to OpenSC's core files and your card driver is integrated. Now think
about what you would have to change when adding a new SM implementation with
your architecture.

> > 2. There are at least two methods to hook into SM, using a SM module and
> >    implementing SM at the driver level. This conceptually introduces
> >    duplication. It is sure to be followed with code duplication. Both
> >    should be unified: Each card driver has a SM driver, which provides
> >    wrapping and unwrapping SM. A SM driver can then also be a SM module
> >    with external key sets.
>
> Was it a question?
> Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and
> 'ACL' mode.
I don't understand ACL mode, because it isn't used anywhere. (This, by
the way, begs the question why it is defined...) The two hooks I see is
via module or via implementation by the card driver.  I am advocating
for merging sm_module_operations and sm_card_operations.

> Duplication can happen due to fact that each card driver implement SM
> as it wants, and can include into card specific part entire SM crypto
> library.

Code duplication is bad. It leads to error duplication and other
problems.

> I do not contest that duplication can happen, but:
> - it should not be obstacle to the implementation;
> - please point out exactly, where in code you see duplication.

- CWA implements SM according to ISO 7816 ([4], p67) and so does
  epass3000.
- About two years ago I have pointed at some places where bit padding is
  implemented multiple times (with different implementations) -- this still
  holds today.

> > 3. As stated earlier, I am advocating for an additional abstraction
> >    between encoding and encryption. Thus, a SM driver would only
> >    implement encoding, offering an other abstraction to the crypto.
> >    Not implementing this abstraction has led to code duplication [1].
> >    And reinventing the wheel will continue, when all ISO-7816-like
> >    cards [2, for example] (or modules) offer their own implementation
> >    of:
> >    - TLV-encoding/decoding of cryptogram (with padding content
> >      indicator), mac and le (depending on the APDU case)
> >    - ISO padding of APDU header and data
>
> As stated ealier, every card driver (at least at the beginning) can do
> roughly what it wants inside it's card specific part.  We have only
> started to introduce the common SM framework, and for a while, we will
> not blame the card driver if it includes it's own SM related crypto
> procedures (... and thus duplicates the code. Is that the code
> duplication that you are talking about?
Yes, a good architecture can reduce code duplication. Again, look at
OpenSC's card drivers. All can do what they want -- that's fine.
However, most drivers are reusing the iso7816 driver adding some tweaks.
For SM implementations, we should offer the same possibility.

> > 4. General problems with code quality:
> >    - A lot of dead code pieces ("#if 0")
>
> You mean the SM part or entire code base of OpenSC.

Uh, I `grep`ped for '#if 0' and saw that this seems to be a common
practice in OpenSC. However, new patches should not introduce new pieces
of dead code. But the recent integration of SM into staging has has done
just that.

> >    - Usage of global switches instead of switches in the card context
>
> What do you mean?

g_sm in epass3000

By the way, is there a possibility to comment on code? I think, github
only lets you comment on commits. I looked through the code yesterday
and found some other problems, which would have been easy to report...

> >    - No or wrong documentation of the SM stuff
> >    - directory "sm" should be renamed to "sm-modules"
>
> ...
>
> > These issues, I think, disqualify the SM branch to be included in
> > OpenSC's trunk.
> >
> > The biggest problem, I think is the coexistance of two independant SM hooks.
>
> You simply cannot cover all SM use cases with one low level SM wrapping method.
> But understand you quite well -- you know/use only this one.
I disagree. I think it is possible. Simply look at the interface to
OpenSC's card drivers.

> > In general I dislike the concept of a SM module, because all
> > OpenSC initialization magic is lost, when only the APDU buffer is passed
> > to the module. If a module is only used for external keysets, then it
> > should do only encrypting/decrypting/authenticating instead of handling
> > the whole smart card stuff.

> External module do not handle all the smart card staff, but it has to
> do part of it.  Example: when importing, the RSA key has to be
> presented by a sequence of 5-7 APDUs, which could be different for the
> different cards.  So, external module has to be able to compose the
> plain APDUs .

Partly wrong: Yes, SM has to be smart card aware (as you have pointed
out with your RSA example). But the crypto module should not need to be
smart card aware. The whole point of your sm modules (correct me if I am
wrong) are cryptographic keys, which are located somewhere else. When it
comes to your RSA example: Simply let OpenSC collect all RSA data and
then send it to you crypto module.

> > Then, what you get is OpenSC that handles
> > smart card stuff, including SM encoding and a crypto layer with loadable
> > modules.
>
> Sorry, do not understood.

Do something like:

struct sc_card_driver {
    ...
    struct sc_sm_driver *sm;
    ...
}
struct sc_sm_driver {
    ...
    struct sm_ctx *sm_ctx;
    int (*get_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
    int (*free_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
    ...
}
/** Secure messaging context */
struct sm_ctx {
    /** 1 if secure messaging is activated, 0 otherwise */
    unsigned char active;

    /** data of the specific crypto implementation */
    void *priv_data;

    /** Padding-content indicator byte (ISO 7816-4 Table 30) */
    u8 padding_indicator;
    /** Pad to this block length */
    size_t block_length;

    /** Call back function for authentication of data */
    int (*authenticate)(sc_card_t *card, const struct sm_ctx *ctx,
            const u8 *data, size_t datalen, u8 **outdata);
    /** Call back function for verifying authentication data */
    int (*verify_authentication)(sc_card_t *card, const struct sm_ctx *ctx,
            const u8 *mac, size_t maclen,
            const u8 *macdata, size_t macdatalen);

    /** Call back function for encryption of data */
    int (*encrypt)(sc_card_t *card, const struct sm_ctx *ctx,
            const u8 *data, size_t datalen, u8 **enc);
    /** Call back function for decryption of data */
    int (*decrypt)(sc_card_t *card, const struct sm_ctx *ctx,
            const u8 *enc, size_t enclen, u8 **data);

    /** Call back function for actions before encoding and encryption of \a apdu */
    int (*pre_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
            sc_apdu_t *apdu);
    /** Call back function for actions before decryption and decoding of \a sm_apdu */
    int (*post_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
            sc_apdu_t *sm_apdu);
    /** Call back function for actions after decrypting SM protected APDU */
    int (*finish)(sc_card_t *card, const struct sm_ctx *ctx,
            sc_apdu_t *apdu);

    /** Clears and frees private data */
    void (*clear_free)(const struct sm_ctx *ctx);
};

(struct sm_ctx is actually copied from my approach to SM [5])

Now, you have two points to customize SM: First you can specify get_apdu and
free_apdu (which should really be renamed in something like sm_wrap_apdu and
sm_unwrap_apdu). Second, you can change the call back functions that actually
calculate a cryptogram or a mac using external keys. The second hook does not
need to be aware to smart card stuff.

> > [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html
> > [2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c
> > [3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h

[4] ftp://ftp.cenorm.be/Public/Cwas/e-europe/esign/cwa14890-01-2004-Mar.pdf
[5] http://vsmartcard.sourceforge.net

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Viktor Tarasov-3
Le 10/06/2012 22:39, Frank Morgner a écrit :

> On Sunday, June 10 at 03:39PM, Viktor Tarasov wrote:
>> Le 10/06/2012 14:21, Frank Morgner a écrit :
>>> Uh, I think I am a bit late on this discussion...
>>>
>>> But I wanted to add a general concern that there are some conceptual
>>> problems with the SM branch (and the recently included patches in
>>> staging).
>>>
>>> 1. Global SM configuration is mixed with a configuration at the driver
>>>    level. For example, look at [3]. It includes CWA, IAS/ECC data types
>>>    which should be realized at the card driver level (or maybe some SM
>>>    driver).
>> In [3] there is no IAS/ECC types.
>> There are data types related to the two more-or-less different SM
>> implementations: GlobalPlatform and CWA.  It's not card specific.
> Well, well... I copied "CWA, IAS/ECC data types" from
> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h:133.
> If there are no IAS/ECC types, it shows how wrong the documentation is.
> (By the way, there *is* some function called
> `iasecc_sm_external_authentication`, line 342)

You are perfectly right, the documentation is not perfect -- will be working on it.
Do you see something card-specific in the data types?

The name of function can be easily changed, and will be changed.
Thanks to point it out.


> However, sm.h still requires you to know cwa structures and gp
> structures. This is typically what you would want to abstract with a SM
> layer. Look at opensc.h and cards.h, which offer a similar abstraction
> to the smart card driver. If you add a smart card driver to opensc, you
> only have to add sc_get_yourcard_driver to card.h and add it to
> internal_card_drivers in ctx.c. Effectively, you have to add only two
> lines to OpenSC's core files and your card driver is integrated. Now think
> about what you would have to change when adding a new SM implementation with
> your architecture.

The difference between libopensc and SM is that there is only one ISO specification for the cards,
and there are at least two SM specifications -- GlobalPlatform and CWA .

In sm.h the SM data types include the sub-types specific for the SM specification,
in the same manner as pkcs15-key data type includes the data types specific to the different key types -- RSA, DSA, GOST, ...


>>> 2. There are at least two methods to hook into SM, using a SM module and
>>>    implementing SM at the driver level. This conceptually introduces
>>>    duplication. It is sure to be followed with code duplication. Both
>>>    should be unified: Each card driver has a SM driver, which provides
>>>    wrapping and unwrapping SM. A SM driver can then also be a SM module
>>>    with external key sets.
>> Was it a question?
>> Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and
>> 'ACL' mode.
> I don't understand ACL mode, because it isn't used anywhere. (This, by
> the way, begs the question why it is defined...) The two hooks I see is
> via module or via implementation by the card driver.  I am advocating
> for merging sm_module_operations and sm_card_operations.

ACL mode is used when decision to-use or not-to-use SM for the next operation is derived by the ACL for this operation.
Example is the iasecc card driver.


>> Duplication can happen due to fact that each card driver implement SM
>> as it wants, and can include into card specific part entire SM crypto
>> library.
> Code duplication is bad. It leads to error duplication and other
> problems.

Once more,
the card drivers are relatively free inside their card-specific part.

My humble opinion is that during the period of implementing of the common SM framework,
we could tolerate some code duplication.


>> I do not contest that duplication can happen, but:
>> - it should not be obstacle to the implementation;
>> - please point out exactly, where in code you see duplication.
> - CWA implements SM according to ISO 7816 ([4], p67) and so does
>   epass3000.

Once more,
card driver can do what it want if this do not hurts the common part,
or until the moment when the common SM framework will be installed.



> - About two years ago I have pointed at some places where bit padding is
>   implemented multiple times (with different implementations) -- this still
>   holds today.

Sorry, I will not be looking for where two years ago you pointed these places,
please, point them here and now .

If this bit padding takes more then few lines in codes, we will certainly create some dedicated procedure.


>>> 3. As stated earlier, I am advocating for an additional abstraction
>>>    between encoding and encryption. Thus, a SM driver would only
>>>    implement encoding, offering an other abstraction to the crypto.
>>>    Not implementing this abstraction has led to code duplication [1].
>>>    And reinventing the wheel will continue, when all ISO-7816-like
>>>    cards [2, for example] (or modules) offer their own implementation
>>>    of:
>>>    - TLV-encoding/decoding of cryptogram (with padding content
>>>      indicator), mac and le (depending on the APDU case)
>>>    - ISO padding of APDU header and data
>> As stated ealier, every card driver (at least at the beginning) can do
>> roughly what it wants inside it's card specific part.  We have only
>> started to introduce the common SM framework, and for a while, we will
>> not blame the card driver if it includes it's own SM related crypto
>> procedures (... and thus duplicates the code. Is that the code
>> duplication that you are talking about?
> Yes, a good architecture can reduce code duplication. Again, look at
> OpenSC's card drivers. All can do what they want -- that's fine.
> However, most drivers are reusing the iso7816 driver adding some tweaks.
> For SM implementations, we should offer the same possibility.


Already answered: one specification for card, two specifications for SM.


>>> 4. General problems with code quality:
>>>    - A lot of dead code pieces ("#if 0")
>> You mean the SM part or entire code base of OpenSC.
> Uh, I `grep`ped for '#if 0' and saw that this seems to be a common
> practice in OpenSC. However, new patches should not introduce new pieces
> of dead code. But the recent integration of SM into staging has has done
> just that.


Agree, 'however, should not'.
Currently not all functionalities are tested/ported from the other branches.
Will clean it out.



>>>    - Usage of global switches instead of switches in the card context
>> What do you mean?
> g_sm in epass3000

Already answered,
'g_sm' is the epass2003 internal issue.
It has no relation to the common SM framework.




> By the way, is there a possibility to comment on code? I think, github
> only lets you comment on commits. I looked through the code yesterday
> and found some other problems, which would have been easy to report...

All these codes was pending long time in the dedicated branches and in the github pull requests -- you could comment them there.

Now you can do it here.



>>>    - No or wrong documentation of the SM stuff
>>>    - directory "sm" should be renamed to "sm-modules"
>> ...
>>
>>> These issues, I think, disqualify the SM branch to be included in
>>> OpenSC's trunk.
>>>
>>> The biggest problem, I think is the coexistance of two independant SM hooks.
>> You simply cannot cover all SM use cases with one low level SM wrapping method.
>> But understand you quite well -- you know/use only this one.
> I disagree. I think it is possible. Simply look at the interface to
> OpenSC's card drivers.


It's about ACL SM mode.

Two years ago I asked you:
how do you imagine to deal with more then one keysets for one card/application ?
to deal with the mixed card operations -- when not all card transactions has to be SM wrapped?

Until now I have no answer.




>>> In general I dislike the concept of a SM module, because all
>>> OpenSC initialization magic is lost, when only the APDU buffer is pasfsed
>>> to the module. If a module is only used for external keysets, then it
>>> should do only encrypting/decrypting/authenticating instead of handling
>>> the whole smart card stuff.
>> External module do not handle all the smart card staff, but it has to
>> do part of it.  Example: when importing, the RSA key has to be
>> presented by a sequence of 5-7 APDUs, which could be different for the
>> different cards.  So, external module has to be able to compose the
>> plain APDUs .
> Partly wrong: Yes, SM has to be smart card aware (as you have pointed
> out with your RSA example). But the crypto module should not need to be
> smart card aware. The whole point of your sm modules (correct me if I am
> wrong) are cryptographic keys, which are located somewhere else. When it
> comes to your RSA example: Simply let OpenSC collect all RSA data and
> then send it to you crypto module.

What 'OpenSC' are you talking about? The one that is installed on the client side?
The hole idea is that this part have never access to the plain RSA key and cannot send data to the crypto module.


>>> Then, what you get is OpenSC that handles
>>> smart card stuff, including SM encoding and a crypto layer with loadable
>>> modules.
>> Sorry, do not understood.
> Do something like:
>
> struct sc_card_driver {
>     ...
>     struct sc_sm_driver *sm;
>     ...
> }
> struct sc_sm_driver {
>     ...
>     struct sm_ctx *sm_ctx;
>     int (*get_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
>     int (*free_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
>     ...
> }
> /** Secure messaging context */
> struct sm_ctx {
>     /** 1 if secure messaging is activated, 0 otherwise */
>     unsigned char active;
>
>     /** data of the specific crypto implementation */
>     void *priv_data;
>
>     /** Padding-content indicator byte (ISO 7816-4 Table 30) */
>     u8 padding_indicator;
>     /** Pad to this block length */
>     size_t block_length;
>
>     /** Call back function for authentication of data */
>     int (*authenticate)(sc_card_t *card, const struct sm_ctx *ctx,
>             const u8 *data, size_t datalen, u8 **outdata);
>     /** Call back function for verifying authentication data */
>     int (*verify_authentication)(sc_card_t *card, const struct sm_ctx *ctx,
>             const u8 *mac, size_t maclen,
>             const u8 *macdata, size_t macdatalen);
>
>     /** Call back function for encryption of data */
>     int (*encrypt)(sc_card_t *card, const struct sm_ctx *ctx,
>             const u8 *data, size_t datalen, u8 **enc);
>     /** Call back function for decryption of data */
>     int (*decrypt)(sc_card_t *card, const struct sm_ctx *ctx,
>             const u8 *enc, size_t enclen, u8 **data);
>
>     /** Call back function for actions before encoding and encryption of \a apdu */
>     int (*pre_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
>             sc_apdu_t *apdu);
>     /** Call back function for actions before decryption and decoding of \a sm_apdu */
>     int (*post_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
>             sc_apdu_t *sm_apdu);
>     /** Call back function for actions after decrypting SM protected APDU */
>     int (*finish)(sc_card_t *card, const struct sm_ctx *ctx,
>             sc_apdu_t *apdu);
>
>     /** Clears and frees private data */
>     void (*clear_free)(const struct sm_ctx *ctx);
> };
>
> (struct sm_ctx is actually copied from my approach to SM [5])
>
> Now, you have two points to customize SM: First you can specify get_apdu and
> free_apdu (which should really be renamed in something like sm_wrap_apdu and
> sm_unwrap_apdu). Second, you can change the call back functions that actually
> calculate a cryptogram or a mac using external keys. The second hook does not
> need to be aware to smart card stuff.


I do not see radical difference between what is currently committed to 'staging' and your proposals.

We can longly argue about importance of one or other feature (post-transmit, pre-transmit, priv-data, ...) .
The only question that I would like to ask is:
I'm sure that the current SM framework can answer your needs that concerns the low level SM wrapping of APDUs.
Can you do the same in a regards to the needs of external SM module, support of the two SM specifications, more then one keysets per card/application ?



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Frank Morgner
Hi!

> > However, sm.h still requires you to know cwa structures and gp
> > structures. This is typically what you would want to abstract with a
> > SM layer. Look at opensc.h and cards.h, which offer a similar
> > abstraction to the smart card driver. If you add a smart card driver
> > to opensc, you only have to add sc_get_yourcard_driver to card.h and
> > add it to internal_card_drivers in ctx.c. Effectively, you have to
> > add only two lines to OpenSC's core files and your card driver is
> > integrated. Now think about what you would have to change when
> > adding a new SM implementation with your architecture.
>
> The difference between libopensc and SM is that there is only one ISO
> specification for the cards, and there are at least two SM
> specifications -- GlobalPlatform and CWA .
I don't get your argument. libopensc doesn't force you to base your card
driver on the iso7816 driver you are free to implement the call back
functions as you want. This is absolutely compatible with non-7816
cards -- simply change the call back functions as needed.

To be clear on the terminology: CWA'SM extends ISO 7816-4's SM. *Please*
look at both documents and search for the differences regarding SM. You
will find out that CWA is more specific in that it allows only one
specific configuration of ISO 7816. Also, it requires the usage of
Triple DES and Retail MAC. Thus, the two SM standards are ISO and GP.

Now imagine, you have a SM driver for ISO 7816. And you have built into
the ISO 7816 SM driver call back functions for doing the crypto
operations. Then CWA is perfectly compatible with the ISO 7816 driver
with call back functions for DES and Retail MAC. That's what I am
proposing.

> In sm.h the SM data types include the sub-types specific for the SM
> specification, in the same manner as pkcs15-key data type includes the
> data types specific to the different key types -- RSA, DSA, GOST, ...

If that's the case, using an abstraction layer for the crypto operations
can be useful here, too.

> >>> 2. There are at least two methods to hook into SM, using a SM module and
> >>>    implementing SM at the driver level. This conceptually introduces
> >>>    duplication. It is sure to be followed with code duplication. Both
> >>>    should be unified: Each card driver has a SM driver, which provides
> >>>    wrapping and unwrapping SM. A SM driver can then also be a SM module
> >>>    with external key sets.
> >> Was it a question?
> >> Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and
> >> 'ACL' mode.
> > I don't understand ACL mode, because it isn't used anywhere. (This, by
> > the way, begs the question why it is defined...) The two hooks I see is
> > via module or via implementation by the card driver.  I am advocating
> > for merging sm_module_operations and sm_card_operations.
>
> ACL mode is used when decision to-use or not-to-use SM for the next operation is derived by the ACL for this operation.
> Example is the iasecc card driver.
Hmm, SM_MODE_ACL isn't used anywhere...

> >> Duplication can happen due to fact that each card driver implement SM
> >> as it wants, and can include into card specific part entire SM crypto
> >> library.
> > Code duplication is bad. It leads to error duplication and other
> > problems.
>
> Once more, the card drivers are relatively free inside their
> card-specific part.
>
> My humble opinion is that during the period of implementing of the
> common SM framework, we could tolerate some code duplication.
Although every driver in every card is free to do whatever it wants, you
might want to give it some possibilities for simplifications. So let's
*design* a flexible SM framework instead of saying "you are free to do
whatever you want". CWA, epass2003, nPA, OpenPGP, DNie (afaik) are
all based on ISO 7816 SM. Abstraction layers will help to find a common
and robust code base between those cards.

> >> I do not contest that duplication can happen, but:
> >> - it should not be obstacle to the implementation;
> >> - please point out exactly, where in code you see duplication.
> > - CWA implements SM according to ISO 7816 ([4], p67) and so does
> >   epass3000.
>
> Once more,
> card driver can do what it want if this do not hurts the common part,
> or until the moment when the common SM framework will be installed.

What do you mean with "will be installed"? As I understood it, patches
that go to staging will later go to master, when they are more or less
evaluated. What changes to the SM framework are you planning to do?

> > - About two years ago I have pointed at some places where bit
> > padding is implemented multiple times (with different
> > implementations) -- this still holds today.
>
> Sorry, I will not be looking for where two years ago you pointed these
> places, please, point them here and now .

http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015129.html
The places have not changed much.

> If this bit padding takes more then few lines in codes, we will
> certainly create some dedicated procedure.

http://lmgtfy.com/?q=bit+padding

grep for 0x80

> >>> 3. As stated earlier, I am advocating for an additional abstraction
> >>>    between encoding and encryption. Thus, a SM driver would only
> >>>    implement encoding, offering an other abstraction to the crypto.
> >>>    Not implementing this abstraction has led to code duplication [1].
> >>>    And reinventing the wheel will continue, when all ISO-7816-like
> >>>    cards [2, for example] (or modules) offer their own implementation
> >>>    of:
> >>>    - TLV-encoding/decoding of cryptogram (with padding content
> >>>      indicator), mac and le (depending on the APDU case)
> >>>    - ISO padding of APDU header and data
> >> As stated ealier, every card driver (at least at the beginning) can do
> >> roughly what it wants inside it's card specific part.  We have only
> >> started to introduce the common SM framework, and for a while, we will
> >> not blame the card driver if it includes it's own SM related crypto
> >> procedures (... and thus duplicates the code. Is that the code
> >> duplication that you are talking about?
> > Yes, a good architecture can reduce code duplication. Again, look at
> > OpenSC's card drivers. All can do what they want -- that's fine.
> > However, most drivers are reusing the iso7816 driver adding some tweaks.
> > For SM implementations, we should offer the same possibility.
>
>
> Already answered: one specification for card, two specifications for SM.
I don't quite see what question you have answered. I am not saying that
we should abandon the GP SM implementation. Instead I want to keep GP
and ISO SM. But what I am saying is that it should be possible to
configure the ISO driver to be used in multiple configurations (e.g.
with different crypto functions).

> >>>    - Usage of global switches instead of switches in the card context
> >> What do you mean?
> > g_sm in epass3000
>
> Already answered,
> 'g_sm' is the epass2003 internal issue.
> It has no relation to the common SM framework.

Well, it *uses* the SM framework. So I consider it as related. That
epass2003 re-implements ISO 7816 SM shows the deficits of the current SM
framework.

g_sm, however, is only flaw that I saw at the first glance. Earlier,
someone was talking about "perfect patches". g_sm shows that the SM
patches (regarded as series of patches that introduce SM as framework
and some actual implementations) need more reviews.

> > By the way, is there a possibility to comment on code? I think,
> > github only lets you comment on commits. I looked through the code
> > yesterday and found some other problems, which would have been easy
> > to report...
>
> All these codes was pending long time in the dedicated branches and in
> the github pull requests -- you could comment them there.
>
> Now you can do it here.

Our discussion so far lets me think that it can take a long time, here.
Also, I want convenience as in "click here to report a problem". Isn't
there anyone who has hacked that before?

> >>>    - No or wrong documentation of the SM stuff
> >>>    - directory "sm" should be renamed to "sm-modules"
> >> ...
> >>
> >>> These issues, I think, disqualify the SM branch to be included in
> >>> OpenSC's trunk.
> >>>
> >>> The biggest problem, I think is the coexistance of two independant SM hooks.
> >> You simply cannot cover all SM use cases with one low level SM wrapping method.
> >> But understand you quite well -- you know/use only this one.
> > I disagree. I think it is possible. Simply look at the interface to
> > OpenSC's card drivers.
>
>
> It's about ACL SM mode.
>
> Two years ago I asked you:
> how do you imagine to deal with more then one keysets for one card/application ?
> to deal with the mixed card operations -- when not all card transactions has to be SM wrapped?
>
> Until now I have no answer.
I think you didn't ask... Anyway, the solution is easy and it is present
since more than two years in my SM implementation [5]. If sc_read_binary
(or whatever) is done on a non-protected file simply do:
    sm_ctx.active = 0;
(for struct sm_ctx see below). The idea is to let the card driver
configure the SM driver whenever needed.

> >>> In general I dislike the concept of a SM module, because all
> >>> OpenSC initialization magic is lost, when only the APDU buffer is pasfsed
> >>> to the module. If a module is only used for external keysets, then it
> >>> should do only encrypting/decrypting/authenticating instead of handling
> >>> the whole smart card stuff.
> >> External module do not handle all the smart card staff, but it has to
> >> do part of it.  Example: when importing, the RSA key has to be
> >> presented by a sequence of 5-7 APDUs, which could be different for the
> >> different cards.  So, external module has to be able to compose the
> >> plain APDUs .
> > Partly wrong: Yes, SM has to be smart card aware (as you have pointed
> > out with your RSA example). But the crypto module should not need to be
> > smart card aware. The whole point of your sm modules (correct me if I am
> > wrong) are cryptographic keys, which are located somewhere else. When it
> > comes to your RSA example: Simply let OpenSC collect all RSA data and
> > then send it to you crypto module.
>
> What 'OpenSC' are you talking about? The one that is installed on the
> client side?  The hole idea is that this part have never access to the
> plain RSA key and cannot send data to the crypto module.
Hmm, you said that the RSA key is presented in 5-7 APDUs. Whatever this
representation is or who you are representing it to (card or SM module),
just forget about APDUs for a second. Look at this representation as one
big blob, that can be sent to (or from) the SM module (or to the card
driver). In libopensc's card driver you can split up (or assemble) the
data into APDUs. Remember, I am talking of three layers of abstraction:
Card driver (APDU aware, local/client), SM driver (for encoding of SM,
APDU aware, local/client) and Crypto (*not* APDU aware, remote/module).

> >>> Then, what you get is OpenSC that handles
> >>> smart card stuff, including SM encoding and a crypto layer with loadable
> >>> modules.
> >> Sorry, do not understood.
> > Do something like:
> >
> > struct sc_card_driver {
> >     ...
> >     struct sc_sm_driver *sm;
> >     ...
> > }
> > struct sc_sm_driver {
> >     ...
> >     struct sm_ctx *sm_ctx;
> >     int (*get_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
> >     int (*free_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
> >     ...
> > }
> > /** Secure messaging context */
> > struct sm_ctx {
> >     /** 1 if secure messaging is activated, 0 otherwise */
> >     unsigned char active;
> >
> >     /** data of the specific crypto implementation */
> >     void *priv_data;
> >
> >     /** Padding-content indicator byte (ISO 7816-4 Table 30) */
> >     u8 padding_indicator;
> >     /** Pad to this block length */
> >     size_t block_length;
> >
> >     /** Call back function for authentication of data */
> >     int (*authenticate)(sc_card_t *card, const struct sm_ctx *ctx,
> >             const u8 *data, size_t datalen, u8 **outdata);
> >     /** Call back function for verifying authentication data */
> >     int (*verify_authentication)(sc_card_t *card, const struct sm_ctx *ctx,
> >             const u8 *mac, size_t maclen,
> >             const u8 *macdata, size_t macdatalen);
> >
> >     /** Call back function for encryption of data */
> >     int (*encrypt)(sc_card_t *card, const struct sm_ctx *ctx,
> >             const u8 *data, size_t datalen, u8 **enc);
> >     /** Call back function for decryption of data */
> >     int (*decrypt)(sc_card_t *card, const struct sm_ctx *ctx,
> >             const u8 *enc, size_t enclen, u8 **data);
> >
> >     /** Call back function for actions before encoding and encryption of \a apdu */
> >     int (*pre_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
> >             sc_apdu_t *apdu);
> >     /** Call back function for actions before decryption and decoding of \a sm_apdu */
> >     int (*post_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
> >             sc_apdu_t *sm_apdu);
> >     /** Call back function for actions after decrypting SM protected APDU */
> >     int (*finish)(sc_card_t *card, const struct sm_ctx *ctx,
> >             sc_apdu_t *apdu);
> >
> >     /** Clears and frees private data */
> >     void (*clear_free)(const struct sm_ctx *ctx);
> > };
> >
> > (struct sm_ctx is actually copied from my approach to SM [5])
> >
> > Now, you have two points to customize SM: First you can specify get_apdu and
> > free_apdu (which should really be renamed in something like sm_wrap_apdu and
> > sm_unwrap_apdu). Second, you can change the call back functions that actually
> > calculate a cryptogram or a mac using external keys. The second hook does not
> > need to be aware to smart card stuff.
>
>
> I do not see radical difference between what is currently committed to 'staging' and your proposals.
>
> We can longly argue about importance of one or other feature (post-transmit, pre-transmit, priv-data, ...) .
> The only question that I would like to ask is:
> I'm sure that the current SM framework can answer your needs that concerns the low level SM wrapping of APDUs.
Well, plain libopensc fitted my needs regarding SM. The current SM
framework, however, does not give me any advantages. What I want is
better integration of my cards (thats why I am bothering with the SM
framework so much), reusable code and clean interfaces. Both of the
latter points require changes to the current SM framework.

> Can you do the same in a regards to the needs of external SM module,
> support of the two SM specifications, more then one keysets per
> card/application ?

Again, this is easy to do: simply let the local card driver do all the
message parsing (because libopensc already does a lot of this magic) and
configure the external module appropriately. How you are configuring a
module is up to you.

> >>> [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html
> >>> [2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c
> >>> [3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h
> > [4] ftp://ftp.cenorm.be/Public/Cwas/e-europe/esign/cwa14890-01-2004-Mar.pdf
> > [5] http://vsmartcard.sourceforge.net

Look, I am currently integrating my iso 7816 SM driver into your framework.
I don't have much time, thats why this could take some weeks. But this
is only part of the problem. For several reasons, there are some things
I can't do:
- change CWA-cards and epass2003 to use the iso SM driver
- merge the card driver SM call back functions (`struct sm_card_operations`)
  into an SM module (`struct sm_module_operations`) or the other way
  round.
- testing with different real cards
As I understand it, you do not share my opinion on the deficits of the
current SM framework. If so, I don't see those things happen any time
soon. Is this correct?

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Peter Stuge-4
In reply to this post by Frank Morgner
Hi Frank,

Frank Morgner wrote:
> general concern that there are some conceptual problems

I'm afraid that your standards may be much too high. :\

Thanks for caring though!


//Peter

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

attachment0 (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC staging branch

Viktor Tarasov-3
In reply to this post by Frank Morgner
Hello,

Le 14/06/2012 23:55, Frank Morgner a écrit :

>>> However, sm.h still requires you to know cwa structures and gp
>>> structures. This is typically what you would want to abstract with a
>>> SM layer. Look at opensc.h and cards.h, which offer a similar
>>> abstraction to the smart card driver. If you add a smart card driver
>>> to opensc, you only have to add sc_get_yourcard_driver to card.h and
>>> add it to internal_card_drivers in ctx.c. Effectively, you have to
>>> add only two lines to OpenSC's core files and your card driver is
>>> integrated. Now think about what you would have to change when
>>> adding a new SM implementation with your architecture.
>> The difference between libopensc and SM is that there is only one ISO
>> specification for the cards, and there are at least two SM
>> specifications -- GlobalPlatform and CWA .
> I don't get your argument. libopensc doesn't force you to base your card
> driver on the iso7816 driver you are free to implement the call back
> functions as you want. This is absolutely compatible with non-7816
> cards -- simply change the call back functions as needed.
>
> To be clear on the terminology: CWA'SM extends ISO 7816-4's SM. *Please*
> look at both documents and search for the differences regarding SM. You
> will find out that CWA is more specific in that it allows only one
> specific configuration of ISO 7816. Also, it requires the usage of
> Triple DES and Retail MAC. Thus, the two SM standards are ISO and GP.


I do not separate ISO and CWA -- for me it one entity.
I'm talking about difference between GP and ISO&CWA version of SM.


> Now imagine, you have a SM driver for ISO 7816. And you have built into
> the ISO 7816 SM driver call back functions for doing the crypto
> operations. Then CWA is perfectly compatible with the ISO 7816 driver
> with call back functions for DES and Retail MAC. That's what I am
> proposing.

In the SM of actual 'staging' the essential part (in libopensc) is the SM related call back handlers for the card driver and external SM module.
And also the general and type specific SM data.
What you are proposing (afaiu) is the further stage -- optimizing and structuring of SM crypto library and APIs that have to be used by SM handlers and module .
In the current SM framework I do not see contradictions or excluded possibilities.


>> In sm.h the SM data types include the sub-types specific for the SM
>> specification, in the same manner as pkcs15-key data type includes the
>> data types specific to the different key types -- RSA, DSA, GOST, ...
> If that's the case, using an abstraction layer for the crypto operations
> can be useful here, too.

I do not understand what you are looking for:
there is the generic level of crypto data types and operations,
there is level of data and operations that is a key type specific .

The same in SM: generic SM data types that has 'parameter' member where are the SM type specific data to be placed.




>>>>> 2. There are at least two methods to hook into SM, using a SM module and
>>>>>    implementing SM at the driver level. This conceptually introduces
>>>>>    duplication. It is sure to be followed with code duplication. Both
>>>>>    should be unified: Each card driver has a SM driver, which provides
>>>>>    wrapping and unwrapping SM. A SM driver can then also be a SM module
>>>>>    with external key sets.
>>>> Was it a question?
>>>> Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and
>>>> 'ACL' mode.
>>> I don't understand ACL mode, because it isn't used anywhere. (This, by
>>> the way, begs the question why it is defined...) The two hooks I see is
>>> via module or via implementation by the card driver.  I am advocating
>>> for merging sm_module_operations and sm_card_operations.
>> ACL mode is used when decision to-use or not-to-use SM for the next operation is derived by the ACL for this operation.
>> Example is the iasecc card driver.
> Hmm, SM_MODE_ACL isn't used anywhere...
>
>>>> Duplication can happen due to fact that each card driver implement SM
>>>> as it wants, and can include into card specific part entire SM crypto
>>>> library.
>>> Code duplication is bad. It leads to error duplication and other
>>> problems.
>> Once more, the card drivers are relatively free inside their
>> card-specific part.
>>
>> My humble opinion is that during the period of implementing of the
>> common SM framework, we could tolerate some code duplication.
> Although every driver in every card is free to do whatever it wants, you
> might want to give it some possibilities for simplifications. So let's
> *design* a flexible SM framework instead of saying "you are free to do
> whatever you want". CWA, epass2003, nPA, OpenPGP, DNie (afaik) are
> all based on ISO 7816 SM. Abstraction layers will help to find a common
> and robust code base between those cards.

Agree, but
let's start from definition of (the most) generic SM types and SM related handlers .
The abstraction of SM related crypto can be the next stage.


>>>> I do not contest that duplication can happen, but:
>>>> - it should not be obstacle to the implementation;
>>>> - please point out exactly, where in code you see duplication.
>>> - CWA implements SM according to ISO 7816 ([4], p67) and so does
>>>   epass3000.
>> Once more,
>> card driver can do what it want if this do not hurts the common part,
>> or until the moment when the common SM framework will be installed.
> What do you mean with "will be installed"? As I understood it, patches
> that go to staging will later go to master, when they are more or less
> evaluated. What changes to the SM framework are you planning to do?


I mean the common SM related crypto library, that can be used by drivers or external SM module.
Afaiu, that's the main point of your intentions.



>>> - About two years ago I have pointed at some places where bit
>>> padding is implemented multiple times (with different
>>> implementations) -- this still holds today.
>> Sorry, I will not be looking for where two years ago you pointed these
>> places, please, point them here and now .
> http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015129.html
> The places have not changed much.
>
>> If this bit padding takes more then few lines in codes, we will
>> certainly create some dedicated procedure.
> http://lmgtfy.com/?q=bit+padding
>
> grep for 0x80


Greatly appreciated,
but please, make a reference to the actual code in 'staging'.


>>>>> 3. As stated earlier, I am advocating for an additional abstraction
>>>>>    between encoding and encryption. Thus, a SM driver would only
>>>>>    implement encoding, offering an other abstraction to the crypto.
>>>>>    Not implementing this abstraction has led to code duplication [1].
>>>>>    And reinventing the wheel will continue, when all ISO-7816-like
>>>>>    cards [2, for example] (or modules) offer their own implementation
>>>>>    of:
>>>>>    - TLV-encoding/decoding of cryptogram (with padding content
>>>>>      indicator), mac and le (depending on the APDU case)
>>>>>    - ISO padding of APDU header and data
>>>> As stated ealier, every card driver (at least at the beginning) can do
>>>> roughly what it wants inside it's card specific part.  We have only
>>>> started to introduce the common SM framework, and for a while, we will
>>>> not blame the card driver if it includes it's own SM related crypto
>>>> procedures (... and thus duplicates the code. Is that the code
>>>> duplication that you are talking about?
>>> Yes, a good architecture can reduce code duplication. Again, look at
>>> OpenSC's card drivers. All can do what they want -- that's fine.
>>> However, most drivers are reusing the iso7816 driver adding some tweaks.
>>> For SM implementations, we should offer the same possibility.
>>
>> Already answered: one specification for card, two specifications for SM.
> I don't quite see what question you have answered. I am not saying that
> we should abandon the GP SM implementation. Instead I want to keep GP
> and ISO SM. But what I am saying is that it should be possible to
> configure the ISO driver to be used in multiple configurations (e.g.
> with different crypto functions).

Agree, it's not the answer, sorry.

The answer is that in 'staging' actually defined are the generic SM data types and handlers.
That allows different cards to use SMs right now.
We can improve it further by introducing of the common SM crypto library and API.

What do you mean by 'configure ISO driver'?
Actually in opensc.conf there is possibility to define the card specific SM section.

I do not understand 'driver to be used with different crypto functions' .
Example of different crypto functions?



>>>>>    - Usage of global switches instead of switches in the card context
>>>> What do you mean?
>>> g_sm in epass3000
>> Already answered,
>> 'g_sm' is the epass2003 internal issue.
>> It has no relation to the common SM framework.
> Well, it *uses* the SM framework. So I consider it as related. That
> epass2003 re-implements ISO 7816 SM shows the deficits of the current SM
> framework.

It uses the SM related callbacks and implements it's own SM related cryptography.
I agree, here is the deficit of the current SM framework and it's opened for the further improvements.


> g_sm, however, is only flaw that I saw at the first glance. Earlier,
> someone was talking about "perfect patches". g_sm shows that the SM
> patches (regarded as series of patches that introduce SM as framework
> and some actual implementations) need more reviews.

Once more, 'g_sm' is the internal affair of this driver.
It's true that it could be easily replaced by using of current 'sm_mode' member of sm context.
You could make a proposal for the attention of the owner of this driver.


>>> By the way, is there a possibility to comment on code? I think,
>>> github only lets you comment on commits. I looked through the code
>>> yesterday and found some other problems, which would have been easy
>>> to report...
>> All these codes was pending long time in the dedicated branches and in
>> the github pull requests -- you could comment them there.
>>
>> Now you can do it here.
> Our discussion so far lets me think that it can take a long time, here.
> Also, I want convenience as in "click here to report a problem". Isn't
> there anyone who has hacked that before?
>
>>>>>    - No or wrong documentation of the SM stuff
>>>>>    - directory "sm" should be renamed to "sm-modules"
>>>> ...
>>>>
>>>>> These issues, I think, disqualify the SM branch to be included in
>>>>> OpenSC's trunk.
>>>>>
>>>>> The biggest problem, I think is the coexistance of two independant SM hooks.
>>>> You simply cannot cover all SM use cases with one low level SM wrapping method.
>>>> But understand you quite well -- you know/use only this one.
>>> I disagree. I think it is possible. Simply look at the interface to
>>> OpenSC's card drivers.
>>
>> It's about ACL SM mode.
>>
>> Two years ago I asked you:
>> how do you imagine to deal with more then one keysets for one card/application ?
>> to deal with the mixed card operations -- when not all card transactions has to be SM wrapped?
>>
>> Until now I have no answer.
> I think you didn't ask... Anyway, the solution is easy and it is present
> since more than two years in my SM implementation [5].

I don't think that with your SM implementation it's easy to support the SM protection of different operations/files with the different keysets.

Let's say,
the update of files/SDOs in 'protected' application is protected with one keyset and
the Q.signature or PIN unlock protected by another.
(Just to remind -- only one SM session could be opened at the time.)


> If sc_read_binary
> (or whatever) is done on a non-protected file simply do:
>     sm_ctx.active = 0;

Is that the 'configuration' that you mean?
Configuration by changing the code?


> (for struct sm_ctx see below). The idea is to let the card driver
> configure the SM driver whenever needed.


>>>>> In general I dislike the concept of a SM module, because all
>>>>> OpenSC initialization magic is lost, when only the APDU buffer is pasfsed
>>>>> to the module. If a module is only used for external keysets, then it
>>>>> should do only encrypting/decrypting/authenticating instead of handling
>>>>> the whole smart card stuff.
>>>> External module do not handle all the smart card staff, but it has to
>>>> do part of it.  Example: when importing, the RSA key has to be
>>>> presented by a sequence of 5-7 APDUs, which could be different for the
>>>> different cards.  So, external module has to be able to compose the
>>>> plain APDUs .
>>> Partly wrong: Yes, SM has to be smart card aware (as you have pointed
>>> out with your RSA example). But the crypto module should not need to be
>>> smart card aware. The whole point of your sm modules (correct me if I am
>>> wrong) are cryptographic keys, which are located somewhere else. When it
>>> comes to your RSA example: Simply let OpenSC collect all RSA data and
>>> then send it to you crypto module.
>> What 'OpenSC' are you talking about? The one that is installed on the
>> client side?  The hole idea is that this part have never access to the
>> plain RSA key and cannot send data to the crypto module.
> Hmm, you said that the RSA key is presented in 5-7 APDUs. Whatever this
> representation is or who you are representing it to (card or SM module),
> just forget about APDUs for a second. Look at this representation as one
> big blob, that can be sent to (or from) the SM module (or to the card
> driver). In libopensc's card driver you can split up (or assemble) the
> data into APDUs. Remember, I am talking of three layers of abstraction:
> Card driver (APDU aware, local/client), SM driver (for encoding of SM,
> APDU aware, local/client) and Crypto (*not* APDU aware, remote/module).


Probably here is a *certain* misunderstanding of the problematic.

The RSA key data cannot be always presented as one continuous blob of data, and cannot be split in a arbitrary fashion by libopensc.
Just to remind, in plain mode the libopensc driver receives key data as a RSA (OpenSSL or pkcs15-rsa) data.
These data, component by component, are encoded by libopensc into the sequence of APDUs -- it's not a simple split or chaining of the unique blob.

In SM mode with the distant keyset,
libopensc do not receives the RSA plain data, and so cannot compose the APDUs and call the SM wrap procedures.

It's up to external SM module to compose APDUs. These APDUs can be card specific, but also card-context specific (for ex. the # of allocated key slot is present the APDU data to be wrapped by SM).



>>>>> Then, what you get is OpenSC that handles
>>>>> smart card stuff, including SM encoding and a crypto layer with loadable
>>>>> modules.
>>>> Sorry, do not understood.
>>> Do something like:
>>>
>>> struct sc_card_driver {
>>>     ...
>>>     struct sc_sm_driver *sm;
>>>     ...
>>> }
>>> struct sc_sm_driver {
>>>     ...
>>>     struct sm_ctx *sm_ctx;
>>>     int (*get_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
>>>     int (*free_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct sc_apdu **sm_apdu);
>>>     ...
>>> }
>>> /** Secure messaging context */
>>> struct sm_ctx {
>>>     /** 1 if secure messaging is activated, 0 otherwise */
>>>     unsigned char active;
>>>
>>>     /** data of the specific crypto implementation */
>>>     void *priv_data;
>>>
>>>     /** Padding-content indicator byte (ISO 7816-4 Table 30) */
>>>     u8 padding_indicator;
>>>     /** Pad to this block length */
>>>     size_t block_length;
>>>
>>>     /** Call back function for authentication of data */
>>>     int (*authenticate)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             const u8 *data, size_t datalen, u8 **outdata);
>>>     /** Call back function for verifying authentication data */
>>>     int (*verify_authentication)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             const u8 *mac, size_t maclen,
>>>             const u8 *macdata, size_t macdatalen);
>>>
>>>     /** Call back function for encryption of data */
>>>     int (*encrypt)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             const u8 *data, size_t datalen, u8 **enc);
>>>     /** Call back function for decryption of data */
>>>     int (*decrypt)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             const u8 *enc, size_t enclen, u8 **data);
>>>
>>>     /** Call back function for actions before encoding and encryption of \a apdu */
>>>     int (*pre_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             sc_apdu_t *apdu);
>>>     /** Call back function for actions before decryption and decoding of \a sm_apdu */
>>>     int (*post_transmit)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             sc_apdu_t *sm_apdu);
>>>     /** Call back function for actions after decrypting SM protected APDU */
>>>     int (*finish)(sc_card_t *card, const struct sm_ctx *ctx,
>>>             sc_apdu_t *apdu);
>>>
>>>     /** Clears and frees private data */
>>>     void (*clear_free)(const struct sm_ctx *ctx);
>>> };
>>>
>>> (struct sm_ctx is actually copied from my approach to SM [5])
>>>
>>> Now, you have two points to customize SM: First you can specify get_apdu and
>>> free_apdu (which should really be renamed in something like sm_wrap_apdu and
>>> sm_unwrap_apdu). Second, you can change the call back functions that actually
>>> calculate a cryptogram or a mac using external keys. The second hook does not
>>> need to be aware to smart card stuff.
>>
>> I do not see radical difference between what is currently committed to 'staging' and your proposals.
>>
>> We can longly argue about importance of one or other feature (post-transmit, pre-transmit, priv-data, ...) .
>> The only question that I would like to ask is:
>> I'm sure that the current SM framework can answer your needs that concerns the low level SM wrapping of APDUs.
> Well, plain libopensc fitted my needs regarding SM. The current SM
> framework, however, does not give me any advantages. What I want is
> better integration of my cards (thats why I am bothering with the SM
> framework so much), reusable code and clean interfaces. Both of the
> latter points require changes to the current SM framework.

Advantage ?
Actually there is the *possibility* to integrate your card, as well as the other ones.
The rest is up to you. If you looking for the common SM related crypto library and API -- you can propose it.
As I've told, the current state of SM framework concerns mostly the generic SM data types and callbacks.


>> Can you do the same in a regards to the needs of external SM module,
>> support of the two SM specifications, more then one keysets per
>> card/application ?
> Again, this is easy to do: simply let the local card driver do all the
> message parsing (because libopensc already does a lot of this magic) and
> configure the external module appropriately. How you are configuring a
> module is up to you.

.....


>>>>> [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html
>>>>> [2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c
>>>>> [3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h
>>> [4] ftp://ftp.cenorm.be/Public/Cwas/e-europe/esign/cwa14890-01-2004-Mar.pdf
>>> [5] http://vsmartcard.sourceforge.net
> Look, I am currently integrating my iso 7816 SM driver into your framework.
> I don't have much time, thats why this could take some weeks. But this
> is only part of the problem. For several reasons, there are some things
> I can't do:
> - change CWA-cards and epass2003 to use the iso SM driver
> - merge the card driver SM call back functions (`struct sm_card_operations`)
>   into an SM module (`struct sm_module_operations`) or the other way
>   round.
> - testing with different real cards
> As I understand it, you do not share my opinion on the deficits of the
> current SM framework. If so, I don't see those things happen any time
> soon. Is this correct?


I do not share you opinion that current SM framework needs important changes.
I agree that it has to be completed.

I don't understand why you definitively need to merge the SM module and SM card operation.
You can extend the SM card operations and leave aside the SM module.

At the beginning you don't need to touch a lot the epass2003 driver.
It uses three SM callbacks, you can easily bypass/reuse/slightly-change them -- leave alone this card until you implement the support of your own card.

You can ask Jean-Michel for the ePass2003 token.

I can send you the IAS/ECC card, and finally, you can send me the yours.



>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel