10 Jan
2012
10 Jan
'12
6:55 p.m.
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.
10 Jan
10 Jan
7:23 p.m.
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);
16 Jan
16 Jan
6:05 p.m.
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.
6:33 p.m.
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
6:52 p.m.
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,
9:01 p.m.
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
4490
days inactive
4496
days old
5 comments
3 participants
participants (3)
-
Holger Hans Peter Freyther -
jeremy brookfield -
Kevin Redon