( As Spanish authorities finally said No-no to allow re-licensing GPL'd DNIe code for inclusion in OpenSC, me an some others have started a written-from-scratch OpenSC DNIe module. We are next to start writing sm code... )
At lun, 11-10-2010 a las 09:56 +0300, Martin Paljak wrote: [....] > >> There are not many card drivers with SM support (yet) and generally SM > >> support is a somewhat moving target. Do you have practical suggestions > >> for improvement? > > From what I have seen, message padding, the construction of the > > authentication data and encoding of the SM APDU data is conform to > > ISO-7916 for all SM cards, which opensc already supports. Afaik For Spanish DNIe that is true too > What I am > > suggesting (and implemented in my SM implementation, see above) is that > > these operations could be done by an abstraction layer that sits between > > user input and the card specific configuration and implementations for > > ciphers and authentication. So the card initializes some flags for which > > parts should be included in the authentication data or the SM APDU data > > and sets call back functions for the actual encrypting/decrypting or > > authentication of buffers. I'm coding something similar for DNIe: a sort of "virtual channel" that hides SM operations to the rest of OpenSC code [...] > > So what needs to be changed? I have an implementation up and running > > which is based on OpenSC. It should be easily integrated as card driver. > > But my implementation uses also the SM abstraction I described above. > > This abstraction layer of course only implements what is needed for the > > nPA. So if integration in OpenSC is wanted, the question is whether to > > rewrite the SM layer to match the card-centric aproach which is used at > > the moment in OpenSC, whether to rewrite the SM card drivers of OpenSC > > to use the abstraction or to use the already running nPA-tool and not > > integrate it into libopensc. > > Can you prepare two patches against current trunk: the card driver and the > related secure messaging code? Yes, please :-)
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
