Hi List,
Here are some bare-minimum code contributions for iso7816-3 slave side protocol.
https://github.com/zwizwa/at91work/tree/apdu_phone
git@github.com:zwizwa/at91work.git branch apdu_phone
Relevant files are in:
iso7816-slave-cdc-project/ src/
I spent a bit more time on this than expected on low-level platform stuff, leaving me with no time to smooth the rough edges at the PC interface side. It's a start, though.
Features: - non-blocking iso7816-3 state machine for slave-side protocol (reusable in COS?) - low-level AT91 USART is abstracted as iso7816_port.h - line-oriented ASCII HEX protocol over CDC USB serial, easy to use in (python) scripts - transport is separate from state machine, easy to replace with other discussed mechanisms - works for me on Nexus One and BLU SAMBA JR plus
Non-features: - hardcoded ATR - hardcoded power cycle skipping to select correct operating voltage - not using SIMtrace SIM slot (see mim.py for using a PC card reader to complete MITM) - did not test with DFU but should work (I used Atmel SAM-ICE) - standalone firmware, not integrated with CCID / sniffer - git history is messy. i'd just flatten it for further work
Non-features:
- hardcoded ATR
- hardcoded power cycle skipping to select correct operating voltage
fixed: these are now implemented with commands that are encapsulated in the usual APDU traffic, to allow for different packet bearers later. currently I'm sticking with standalone ASCII HEX lines over CDC as that seems to work well.
i'll update bug fixes to the github page. there are plenty of bugs still.
if you'd like to have a look at the code, best to drop me a line to make sure you have the latest version. i'll stop spamming here for now :)
On 08/08/2013 07:46 PM, Peter Stuge wrote:
Tom Schouten wrote:
commands that are encapsulated in the usual APDU traffic
I would really like if there was less APDU crap rather than more. Sad face.
I agree. To be removed at some point.
I kept the separation between this 3-line hack and the functional code clean. It's easy to add a proper transport later.
currently I'm sticking with standalone ASCII HEX lines over CDC
What about control requests?
It makes sense to do this once the CCID device works properly.
I wonder though, control requests are PC->USB only, right? It wouldn't work well for incoming asynchronous C-APDU from the phone, as the PC needs to poll constantly in software. For the CDC serial at least it's on an IN endpoint.
//Peter
Tom Schouten wrote:
I wonder though, control requests are PC->USB only, right?
Wrong.
It wouldn't work well for incoming asynchronous C-APDU from the phone
It would work fine.
as the PC needs to poll constantly in software
All USB communication is polled.
Study chapters 5 and 8 of the USB 2.0 specification.
http://www.usb.org/developers/docs/usb_20_110512.zip
//Peter
On 08/08/2013 09:16 PM, Peter Stuge wrote:
Tom Schouten wrote:
I wonder though, control requests are PC->USB only, right?
Wrong.
It wouldn't work well for incoming asynchronous C-APDU from the phone
It would work fine.
as the PC needs to poll constantly in software
All USB communication is polled.
Study chapters 5 and 8 of the USB 2.0 specification.
Yes I understand USB is polled.
Though there's a difference between polling by the usb controller and polling at the software level, meaning having to send multiple control requests until there is data ready vs just waiting until there is data on an IN endpoint.
I don't believe a control request is meant to block for a long time. I.e. a if there is an IN stage after the SETUP stage, it's supposed to answer promptly to the control packet sent by the host.
//Peter
Tom Schouten wrote:
Yes I understand USB is polled.
Good, except..
Though there's a difference between polling by the usb controller and polling at the software level
..no, not really.
meaning having to send multiple control requests until there is data ready vs just waiting until there is data on an IN endpoint.
The difference is actually very small, but of course it is more convenient to have a dedicated endpoint. I guess the point is that there isn't one.
//Peter
-
Peter Stuge -
Tom Schouten