openct changes: protocol selection / reset

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

openct changes: protocol selection / reset

Andreas Jellinghaus-2
Hi,

have we settled on what to do with openct concerning protocol
selections? I leave the decission what is best to you and
the driver authors, you know best what to do.

I wanted to add this:
 - we discussed those tpdu/apdu changes in opensc.
 - I hope you saw Haralds posting about wireless card readers?
   He plans to add an "escape" protocol for raw access to the
   reader data, as well as T=CL for contact less cards on the
   upper layer.

does the current plan work well with those changes, too?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: openct changes: protocol selection / reset

Laurent Pinchart
> have we settled on what to do with openct concerning protocol
> selections? I leave the decission what is best to you and
> the driver authors, you know best what to do.

I stated my opinion, which I'll summarize here. Please keep in mind that the
assumption driving those changes is that ISO-7816-4 stays applicable. Is that
true for RFID tokens as well ?

The OpenCT protocol should be modified to talk APDU instead of TPDU. ADPU to
TPDU conversion should be handled by the reader driver in OpenCT, with the
help of proto-t0.c and proto-t1.c.

The OpenCT PC/SC and ctapi front-ends should be modified to transform T=0
TPDUs to APDUs and feed them to OpenCT.

OpenSC should be modified to move PC/SC specific code to the PC/SC driver,
sc_transceive should only deal with APDUs. The PC/SC driver will transform
the APDUs to TPDUs.

>  - I hope you saw Haralds posting about wireless card readers?
>    He plans to add an "escape" protocol for raw access to the
>    reader data, as well as T=CL for contact less cards on the
>    upper layer.

I'm not sure to have a good enough understanding of RFID readers to comment on
that. Does ISO-7816-4 apply ? If so, the part of the RFID stack beneath the
APDU layer would have to be implemented in OpenCT, in the reader driver. If
not, we need to discuss it.

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: openct changes: protocol selection / reset

Priit Randla
Laurent Pinchart wrote:

>>have we settled on what to do with openct concerning protocol
>>selections? I leave the decission what is best to you and
>>the driver authors, you know best what to do.
>>    
>>
>
>I stated my opinion, which I'll summarize here. Please keep in mind that the
>assumption driving those changes is that ISO-7816-4 stays applicable. Is that
>true for RFID tokens as well ?
>  
>
    Same here, any idea, where to get something to read about RFID stuff?

>The OpenCT protocol should be modified to talk APDU instead of TPDU. ADPU to
>TPDU conversion should be handled by the reader driver in OpenCT, with the
>help of proto-t0.c and proto-t1.c.
>
>The OpenCT PC/SC and ctapi front-ends should be modified to transform T=0
>TPDUs to APDUs and feed them to OpenCT.
>  
>
    CTAPI seems to expect APDUs according to standard, doesn't it?No
need to convert anything then...
PC/SC we have to convert to APDU's, I agree.

Also, we have to somehow export transport protocol in use, in order to
know if we have to convert PC/SC  ?PDUs or not.
And for OpenSC to know if it needs to construct T=0 TPDU's.
Or am I mistaken?

>OpenSC should be modified to move PC/SC specific code to the PC/SC driver,
>sc_transceive should only deal with APDUs. The PC/SC driver will transform
>the APDUs to TPDUs.
>  
>
    Agreed.

Priit

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openct changes: protocol selection / reset

Andreas Jellinghaus-2
On Friday 23 September 2005 17:37, Priit Randla wrote:
>     Same here, any idea, where to get something to read about RFID stuff?

more precisely: contactless smartcards (iso 13343 or something like that).
If I remember correctly the smart card handbook by ranke/effing had
a chapter on those too, but I'm not sure.

Also I guess it is ok to CC: any question to Harald Welte, maybe he can
help.

Harald: PCSC interface needs TPDU, the others use APDU. The difference
is so far only PCSC with T=0 protocol which needs changes to the APDU
to transform it into a TPDU, as far as I understand. Do you know what the
situation with T=CL will be? Do we need to do any mangling of the APDUs
in OpenSC or can we leave that to lower levels?

Also we are discussion to change the reset and select_protocol functions,
merge them into one, as some readers need to know the desired protocol
before the reset and will automaticaly to the protocol selection.
We discussed an extra parameter of allowed protocols to the reset
function and/or a parameter with the prefered protocol(s?). What might
work best with T=CL and T=ESCAPE and your contactless reader?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: openct changes: protocol selection / reset

Harald Welte
On Fri, Sep 23, 2005 at 08:15:20PM +0200, Andreas Jellinghaus wrote:
> On Friday 23 September 2005 17:37, Priit Randla wrote:
> >     Same here, any idea, where to get something to read about RFID stuff?
>
> more precisely: contactless smartcards (iso 13343 or something like that).

it's 14443 ;)

> If I remember correctly the smart card handbook by ranke/effing had
> a chapter on those too, but I'm not sure.

there's the "RFID Handbuch", though I'm not sure whether there's an
english translation.

> Also I guess it is ok to CC: any question to Harald Welte, maybe he can
> help.

sure.

> Harald: PCSC interface needs TPDU, the others use APDU. The difference
> is so far only PCSC with T=0 protocol which needs changes to the APDU
> to transform it into a TPDU, as far as I understand. Do you know what the
> situation with T=CL will be? Do we need to do any mangling of the APDUs
> in OpenSC or can we leave that to lower levels?

Most readers implement 14443-4 (which is T=CL) in the reader firmware,
so the driver and application just talk raw APDU's.  The passive readers
(those who will use librfid that I'm working on) have a 14443-4
implementation in the host driver, but within the PC/SC ifdhandler.

So, I don't think that OpenSC (or even OpenCT) will have to do any
mangling.

Please also refer to the recently-published
http://www.pcscworkgroup.com/specifications/files/pcsc3_v2.01.4.pdf on
that subject.

> Also we are discussion to change the reset and select_protocol functions,
> merge them into one, as some readers need to know the desired protocol
> before the reset and will automaticaly to the protocol selection.
> We discussed an extra parameter of allowed protocols to the reset
> function and/or a parameter with the prefered protocol(s?). What might
> work best with T=CL and T=ESCAPE and your contactless reader?

Well, with RFID (and the PC/SC 2.x specification for ISO 14443 and ISO
15639), the application can only use PROTOCOL_RAW to transmit raw
APDU's.  The real underlying protocol is determined by the
card/transponder you use.  AFAIK they always only support one protocol,
so it's the reader and rfid protocol stack's job to figure out which one
works.

--
- Harald Welte <[hidden email]>                  http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

attachment0 (196 bytes) Download Attachment