FreeCalypso > hg > fc-sim-sniff

comparison doc/Motivation @ 40:510bef2b2000

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
new README, old stuff goes to doc/Motivation
author Mychaela Falconia <falcon@freecalypso.org>
date Wed, 30 Aug 2023 05:39:53 +0000
parents README@fbbafa93b52b
children
comparison
equal deleted inserted replaced
39:a9e87abeeaa2 40:510bef2b2000
1 Q: What is the principal idea behind SIMtrace, as distinct from the specific
2 implementation realized by "standard" Osmocom SIMtrace?
3
4 A: The two principal objectives of SIMtrace are:
5
6 1) Passive sniffing of communication between a phone-type device and a SIM,
7 ideally as transparent and non-invasive as possible.
8
9 2) Card emulation: the SIMtrace apparatus presents itself to the phone (or
10 modem or other phone-type device) as a SIM, either emulating the entire
11 SIM CardOS functionality in software or communicating with a real SIM
12 located somewhere remotely, across the Internet.
13
14 Q: What are the shortcomings of the existing Osmocom SIMtrace implementation of
15 the above goals?
16
17 A: In the opinion of Mother Mychaela of FreeCalypso, the electrical aspects of
18 Osmocom SIMtrace implementation are its biggest shortcoming. The following
19 problems are most acute currently:
20
21 * Current SIMtrace v2 hardware is not 5V-tolerant: connecting this apparatus to
22 an old phone that puts out 5V (class A) on its SIM socket can damage the
23 hardware, as class A SIM voltages exceed the absolute maximum rating spec of
24 the AT91SAM3S4B microcontroller on the SIMtrace v2 board, which is connected
25 directly to the SIM bus.
26
27 * One option would be to revive the previous hardware generation as in SIMtrace
28 v1, replacing the AT91SAM3S with AT91SAM7S. However, all firmware maintained
29 by Osmocom is written for SAM3S only, thus a backport to SAM7S would involve
30 significant work. Given that the resulting solution would still be far from
31 my idea of perfection, I find it difficult to justify investing in that
32 software effort - instead I would rather work on a more philosophically-proper
33 solution.
34
35 * AT91SAMx-based SIMtrace, both v1 and v2, works (most of the time, but not 100%
36 reliably) with 1.8V phone-SIM combination (a phone that prefers class C and a
37 SIM that supports it) only by accident. The Vih spec (the minimum required
38 voltage on a signal line for it to register reliably as a 1) is 2.0 V for
39 AT91SAM7S or 2.31 V (0.7 * Vddio, Vddio = 3.3 V) for AT91SAM3S, but the actual
40 voltage on SIM interface lines in class C operation will never rise above
41 1.8 V. The electrical interface on this hw operates severely out of spec,
42 and I find it rather miraculous that it works at all. Not surprisingly,
43 reports are starting to trickle in with user experiences of it actually NOT
44 working sometimes.
45
46 * Even if the SIM interface is restricted (by the phone, by the SIM, or by
47 SIMtrace MITM function tampering with ATR or file characteristics bytes) to
48 operating in class B (3.0 V nominal) only, the existing AT91SAMx SIMtrace
49 boards are still electrically unclean. Looking at the schematics, one can see
50 that both CLK and I/O lines are pulled up (with resistors) to the SIMtrace
51 board's 3.3V rail, which is a higher voltage than what the phone will put out
52 (3.0 V or 1.8 V), and in the case of SIMtrace v1 with a 5V phone, that pull-up
53 will turn into a pull-midway-down instead.
54
55 * My philosophy is that the tracing apparatus should be making only a high-
56 impedance connection to the SIM bus and nothing more, while the SIM bus itself
57 is galvanically connected from the phone to the physical SIM without passing
58 through any switches or other potential Heisenbug-inducing artifacts.
59
60 My first thought was to gently modify the existing AT91SAMx-based SIMtrace
61 design for electrically clean multivolt operation:
62
63 * Replace the electrical switches for SIM VCC (FPF2109) and SIM RST/CLK/IO
64 (CB3Q3244) with either a relay (my initial thought, but way too power-hungry)
65 or a manually operated 5PDT slide switch;
66
67 * Insert a Nexperia 74LVC4T3144 dual-supply buffer between the SIM bus and the
68 MCU, providing a sniffing path that not only supports all 3 voltage classes,
69 but is electrically clean, making only a high-impedance connection to the SIM
70 bus as I desire;
71
72 * Connect a 74LVC1G07 open drain driver (fed with TxD from the MCU) to the SIM
73 bus I/O line, providing a signal path for card emulation mode. (In trace mode
74 the firmware would be responsible for never turning on this OD driver, keeping
75 the tracing apparatus High-Z.)
76
77 However, as I was reading AT91SAMx datasheets more carefully in preparation for
78 embarking on a project to turn the above idea into reality, I saw a big problem:
79 when the USART is put into ISO 7816-3 mode, it uses the chip's TxD pin (switched
80 to open drain operation) for both Rx and Tx, and there is no option to keep
81 separate RxD and TxD pins with an external receiving buffer and an external OD
82 driver.
83
84 It would probably be possible to build an all-voltage SIM interface with
85 AT91SAMx, perhaps by using one of those bidirectional level shifter ICs that
86 somehow automagically handle driving direction reversals. But I personally am
87 not too inclined to trust those automagical bidirectional translators, they
88 just don't align with my design philosophy - I would much much rather have
89 unidirectional buffers, one for sniffing and another for OD-driving the I/O
90 line in card emulation mode. Seeing that AT91SAMx is incompatible with such
91 electrical design, I decided to screw AT91SAMx and go for a radically different
92 approach.