Re: [opensc-devel] OpenSC staging branch
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 cryptogra
Re: [opensc-devel] OpenSC staging branch
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 woul
Re: [opensc-devel] OpenSC staging branch
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.
> [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
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC staging branch
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
OpenPACEhttp://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
pgp2Rj2DuK9Gz.pgp
Description: PGP signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
Ludovic Rousseau wrote: > >> I don't know where the "Gerrit's review directory" is and could not > >> find a gerrit config file. > > > > ps www $(pidof java) > > $ pidof java > 24079 > > $ ps www $(pidof java) > PID TTY STAT TIME COMMAND > 24079 pts/2Sl+ 29:22 java -jar jenkins.war --httpPort=8889 > --httpListenAddress=127.0.0.1 --ajp13Port=-1 --prefix=/autobuild > > There is another java process Good find! > $ ps www 25775 > PID TTY STAT TIME COMMAND > 25775 ?Sl 681:58 GerritCodeReview -jar > /home/git/codereview/bin/gerrit.war daemon -d /home/git/codereview > --run-id=1338275543.25754 Then /home/git/codereview is gerrit's directory. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
2012/6/9 Peter Stuge : > Ludovic Rousseau wrote: >> I don't know where the "Gerrit's review directory" is and could not >> find a gerrit config file. > > ps www $(pidof java) $ pidof java 24079 $ ps www $(pidof java) PID TTY STAT TIME COMMAND 24079 pts/2Sl+ 29:22 java -jar jenkins.war --httpPort=8889 --httpListenAddress=127.0.0.1 --ajp13Port=-1 --prefix=/autobuild There is another java process $ ps www 25775 PID TTY STAT TIME COMMAND 25775 ?Sl 681:58 GerritCodeReview -jar /home/git/codereview/bin/gerrit.war daemon -d /home/git/codereview --run-id=1338275543.25754 -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] GetInvolved wiki page
> I was ready to do it, but as you know, > have no sufficient rights on gerrit and jenkins connected to > opensc-project.org . I suggest that we should share resources and administration. With Viktor, we volunteer to build daily packages from GIThub using our own infrastructure, using opensc.fr and the build farm. Packages are building in virtual machaines, chroots and behing vlan with very limited connection to internet. Furthermore, we are implementing regression tests and automatic testing of smartcards. This will give core developers more time to spend on project guidance and management. If you spend less time building packages, you have more time for the core issues and everyone is happy. What do you think? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
