El mar, 26-10-2010 a las 11:58 +0200, Peter Stuge escribió:
> Juan Antonio Martinez wrote:
> > An ideal solution for me (and for the other people that is working
> > with SM cards) would be adding a new card operation
> > "card_transmit_apdu()", that defaults in iso7816.c to
> > sc_transmit_apdu(),
On Tuesday, October 26 at 11:58AM, Peter Stuge wrote:
> Juan Antonio Martinez wrote:
> > An ideal solution for me (and for the other people that is working
> > with SM cards) would be adding a new card operation
> > "card_transmit_apdu()", that defaults in iso7816.c to
> > sc_transmit_apdu(), but c
Juan Antonio Martinez wrote:
> An ideal solution for me (and for the other people that is working
> with SM cards) would be adding a new card operation
> "card_transmit_apdu()", that defaults in iso7816.c to
> sc_transmit_apdu(), but can be overriden when needed.
I don't think this would be ideal,
Juan Antonio Martinez wrote:
> Working in new code for DNIe card, I've found a problem:
> sc_transmit_apdu() must be overriden to allow secure messaging
> routine perform apdu wrapping when SM is on
>
> I've coded a kind of "virtual channel" that hides SM issues from
> my code. Every sc_transmit_ap
On Tuesday, October 26 at 11:05AM, Juan Antonio Martinez wrote:
> Working in new code for DNIe card, I've found a problem:
> sc_transmit_apdu() must be overriden to allow secure messaging
> routine perform apdu wrapping when SM is on
>
> I've coded a kind of "virtual channel" that hides SM issues
Working in new code for DNIe card, I've found a problem:
sc_transmit_apdu() must be overriden to allow secure messaging
routine perform apdu wrapping when SM is on
I've coded a kind of "virtual channel" that hides SM issues from
my code. Every sc_transmit_apdu() call is translated into
dnie_trans
