This is my first post to this list so a little introduction,
I work in security engineering for a large company that uses smart cards for authentication and encryption.
I am having trouble trying to use smart cards from an OSX client over Citrix. The same cards work from a Windows client. Hence the interest in being able to trace all APDUs in a non-OS specific format.
When I use simtrace with e.g. Gemalto Cyberflex cards, the APDU are shown as I would expect.
However, when the card type is a Gemalto Cryptoflex .NET alI see is the ATR APDU.
The Cryptoflex .NET cards are newer and supports a higher baud rate. Could this explain why the APDUs are not shown? There's a somewhat vague statement in the simatrace documentation to this effect.
On 01/10/2012 06:55 PM, jeremy brookfield wrote:
However, when the card type is a Gemalto Cryptoflex .NET alI see is the ATR APDU.
Hi,
i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below.
[1] http://lists.osmocom.org/pipermail/simtrace/2011-December/000193.html
diff --git a/firmware/src/simtrace/iso7816_uart.c b/firmware/src/simtrace/iso7816_uart.c index 17303ca..16a7db3 100644 --- a/firmware/src/simtrace/iso7816_uart.c +++ b/firmware/src/simtrace/iso7816_uart.c @@ -258,6 +258,8 @@ transition_to_tck(struct iso7816_3_handle *ih) /* If only T=0 supported, there is no TCK but we * immediately transition to APDUs */ set_atr_state(ih, ATR_S_DONE); + /* send off the USB context */ + ih->rctx_must_be_sent = 1; return ISO7816_S_WAIT_APDU; } else { set_atr_state(ih, ATR_S_WAIT_TCK);
On Jan 10, 2012, at 7:23 PM, Holger Hans Peter Freyther wrote:
i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below.
Thanks for the suggestion which I have been trying to implement - but without success.
I am experiencing the same problem as Ben reported in http://lists.osmocom.org/pipermail/simtrace/2012-January/000227.html
I can build the firmware and load it over dfu-util but the host application (a PKI debugging program that runs on OSX and Windows) is then returned an invalid APU (only the first byte is correct). I then had to use sam-ba to reload one of the pre-compiled binaries.
My machine is running ubuntu 11.10. The toolchain is arm-elf-toolchain downloaded from the brung ppa (as per the instructions on your wiki) No errors were reported in the build.
I then tried with unmodified firmware from the GIT repository. Same result.
The simtrace program comes from your ppa.
On 01/16/2012 06:05 PM, jeremy brookfield wrote:
My machine is running ubuntu 11.10. The toolchain is arm-elf-toolchain downloaded from the brung ppa (as per the instructions on your wiki) No errors were reported in the build.
I then tried with unmodified firmware from the GIT repository. Same result.
Hmm, this ubuntu-ppa builds quite an old gcc and "known-to-work" probably only applied to osmocomBB at some point. I have compiled 0.4+ with the attached diff.
For your broken firmware, do you get proper output on the serial console? does the firmware even boot? does the red LED turn on?
The simtrace program comes from your ppa.
holger
On Jan 16, 2012, at 6:33 PM, Holger Hans Peter Freyther wrote:
For your broken firmware, do you get proper output on the serial console? does the firmware even boot? does the red LED turn on?
Unfortunately I don't have a suitable cable for the serial port. I'll try to get one. The firmware does boot and the red line comes on (without blinking). On starting simtrace, I see "entering main loop" but on inserting the contact into a reader, the PC/MAC application receives "3b 04 00 00 01" instead of the correct ATR. dfu-util doesn't report any errors and I did load dfu.bin into "-a 1" (without that, the red line blinks)
Thank you very much for the built 0.4 firmware. This loads and works. It now allows me to trace both types of cards, the Cyberflex cards that worked with the original firmware and the Cryptoflex cards (which have a short 7 byte ATR) which now work,
Hi,
If you have a corrected firmware and it works with another phone/card, then I can provide some experience with a similar problem I got. Sometimes I did get random garbage instead of the correct APDU. The problem was hard to find but obvious: it was because of EMI. I used SIMtrace on a NFC capable phone and used the NFC. Because the FFC is not shielded (hard to do for such a flat cable) and the cable runs under the NFC antenna which is in the back cover of the phone, it interfered with the SIM traffic. The solution is to remove the cover, or if you still need to use the NFC to cover the NFC antenna using 1mm copper tape in the inside, so to protect the cable.
good luck, kevin
Excerpts from jeremy brookfield's message of Mon Jan 16 18:05:34 +0100 2012:
On Jan 10, 2012, at 7:23 PM, Holger Hans Peter Freyther wrote:
i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below.
Thanks for the suggestion which I have been trying to implement - but without success.
I am experiencing the same problem as Ben reported in http://lists.osmocom.org/pipermail/simtrace/2012-January/000227.html
-
Holger Hans Peter Freyther -
jeremy brookfield -
Kevin Redon