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 from
> my code. Every sc_transmit_apdu() call is translated into 
> dnie_transmit_apdu() that depending on sm status, encodes apdu
> an then redirects to real sc_transmit_apdu()
> 
> Victor's SM trunk does something similar, but at lower level
> http://www.opensc-project.org/opensc/browser/branches/vtarasov/opensc-sm.trunk/src/libopensc/apdu.c
> ( Victor's code takes also care on apdu chainning when required, but
> that's not my case )
> 
> The problem arises when using standard iso7816 functions. For instance
> dnie_card_select_file() fully complains standard, so I'd like to use
> iso_ops->select_file().... but code at iso7816.c just call
> sc_transmit_apdu()... and SM wrapper won't be called. 
> The only (and dirty) solution is clone iso_select_file() into my code

There has been plenty of discussion about SM. I had the intentions of
integrating it on a higher level into OpenSC. Here is what Viktor wrote about
that in a previous mail:

---
...
Your approach (or similar) is declared in the future intentions of OpenSC.
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/apdu.c#L383
This approach means securization of the APDUs at the 'apdu-transmit' level and,
sure,  one day it will  be implemented in OpenSC.                        
...
What is actually implemented is the securization at the 'libopensc' level.
Here, in a difference to the previous mode, SM is activated only when
it's needed (according to the ACLs of the operation that is going to be
executed).                                                                    
This approach allows the card objects to be protected by multiple keysets.
It also allows to reduce the charge of the 'external SM securisation
entity', that have an access to the keysets and can perform securisation
of APDUs.
---

> 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.
> Most card drivers can stay unchanged (bypassing wrapper), but iso7816.c
> should be rewritten to take care on redirection
> 
> What's your opinion on this?. I can send you required patch for
> supporting card_operations->card_transmit_apdu() code

Could be a temporary solution until it gets integrated into sc_transmit_apdu.
But the problem with temporary solutions is that the often stay too long...

Greets, Frank.

Attachment: pgpKLmW3IUBuW.pgp
Description: PGP signature

_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to