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
