Hi, Because I'm also deceived by the rebelSIM, I was programming a sim sniffer using an atmega, by detecting the clock freq. manualy. Until Harald announced his SIMtrac. His solution is way easier, and more reliable. This is why I've now done a hw design for it. I don't know if it's the right mailing list, but it seemed to be the best. I'm not a electronic expert, I just follow datasheets and examples. I used the openPCD schema to do this one. There is : - the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly. thanks, tsaitgaist
I removed the PLL part and used only 6 out of 8 contacts from the SC https://file.tsaitgaist.info/www/?a=d&i=LqeRpJ14RJ On 21.11.2010 15:14, ml@mail.tsaitgaist.info wrote:
Hi,
Because I'm also deceived by the rebelSIM, I was programming a sim sniffer using an atmega, by detecting the clock freq. manualy. Until Harald announced his SIMtrac. His solution is way easier, and more reliable. This is why I've now done a hw design for it. I don't know if it's the right mailing list, but it seemed to be the best. I'm not a electronic expert, I just follow datasheets and examples. I used the openPCD schema to do this one. There is : - the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it
here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly.
thanks, tsaitgaist
Hi Tsaitgaist,
I removed the PLL part and used only 6 out of 8 contacts from the SC https://file.tsaitgaist.info/www/?a=d&i=LqeRpJ14RJ
I have no experience with ARM microcontrollers, but according to the datasheet VDDPLL powers the oscillator, you should not leave it unconnected. VDDCORE powers the internal logic and is specified as 1.65V to 1.95V. Your "PWR_FLAG" signal connects the output of the 1.8V regulator with +5V USB. This will most likely fry the chip as soon as power is applied. Have a look at §5.4 of the Atnek AT81SAN7S512 datasheet dated 2010-08-30. Please don't order PCBs until one of the more ARM savy guys has had a thorough look over your design. Chris
ml@mail.tsaitgaist.info wrote:
a hw design
Cool!
- the AT91SAM7SXXX
I'd use a more modern chip that is simpler to work with; something like NXP LPC1343 Cortex-M3 with USB or TI Stellaris LM36432 with 10/100 Ethernet. They're both single supply 3.3V chips. The NXP only needs five-size passive support components.
here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe
I get nonsense messages visiting that page. :\ "needs input" something or other. Maybe you can attach them to the wiki? Christian Vogel wrote:
according to the datasheet VDDPLL powers the oscillator, you should not leave it unconnected. VDDCORE powers the internal logic and is specified as 1.65V to 1.95V.
There might be an internal voltage regulator also for this chip, but I would really go with cm3 for a new design. //Peter
Hi Peter and others, On Sun, Nov 21, 2010 at 08:56:44PM +0100, Peter Stuge wrote:
- the AT91SAM7SXXX
I'd use a more modern chip that is simpler to work with; something like NXP LPC1343 Cortex-M3 with USB or TI Stellaris LM36432 with 10/100 Ethernet. They're both single supply 3.3V chips. The NXP only needs five-size passive support components.
no, no, no, no ;) There is working firmware (drivers, T=0 sniffing, ...) for the AT91SAM7 now, I put quite a bit of effort into making this work. Furthermore, the AT91SAM7 USART has the unique property that you can use it in T=0 mode but still operate as clock slave, i.e. run as sniffer or card mode, not behaving like a card reader. We really do not need any external logic, simply connect the SIM card to the right pins of the SAM7, load the (gpl licensed, of course) firmware that I wrote and run the equally free software 'simtrace' host program + wireshark. Porting this to a different microcontroller will again require significant development on the software side, which I don't think is what we need... -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi! On Sun, Nov 21, 2010 at 03:14:34PM +0100, ml@mail.tsaitgaist.info wrote:
His solution is way easier, and more reliable. This is why I've now done a hw design for it.
thanks a lot.
I don't know if it's the right mailing list, but it seemed to be the best.
well, I think it is low-traffic and we might just use this mailing list for the time being.
- the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it
I think we should consider the following use cases: 1) passive sniffer this is what simtrace is doing right now and what your hardware is also prepared for. 2) card simulation this is possible with the same circuit. Simply connect it _only_ to the phone and not to a smart card at all. The wiring will be the same, but the USART will be used in Rx and Tx mode. Only software/firmware changes required. 3) man in the middle in this case, we want to connect as master (reader) to the SIM card, and as slave (card-side interface) to the phone. In order to make we run USART0 as clock-slave (like in case 1 + 2 above), but we also connect a sim card socket to USART1, which we can then run in clock-master mode, i.e. like any 'regular' SAM7 based smart card reader. The easiest solution would be to add yet another sim card socket which is connected to USART1 (TXD1/SCK1). But then we have 3-4 sim card sockets in one device, which I think is clumsy. It may be possible to add some jumpers or dip switches that change the behavior, i.e. "one setting for sniffer + card simluation, another setting for man-in-the-middle"
here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly.
please take time for detailed review before doign any pcbs... thinking more before prototyping will save time and money. Another request: Pleaes make the DRxD / DTxD (Debug UART) pins available on the board, preferrably on the same type of header that we use on the OpenPCD. It will not add any cost to the design, but enable you to print debug messages to a serial port, which is very useful during firmware development. Also, the JTAG lines should be routed to a standard 20-pin ARM-JTAG connector. Both the Debug-UART and the JTAG headers can not be placed/soldered for normal boards, but people who want to do development will likely find both of them very useful. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
thanks for the feedback and recommendations I added the JTAG and debug connectors. I hope it will not use more then 2 layers in the end, so normal people can build the pcb at home. I could not login/register on the osmocom trac wiki to put the files there. Here the current version : https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps I now use this direct link (it could take some time until the DN is spread over all DNS) I did not yet add the MiM solution, because there are still have some open aspects : MiM : - should it use the clock provider by the reader - or should we provided our own clock (3.8432MHz/9600bps for simplicity) using the reader clock would provide better timing but cold be harder to do (I don't know well this chip yet) emulation : - how to know what the user wants (sniff vs emulation) if the mode is combined with the sniffer ? - the user has to tell the program - or by detecting the presence of a card (provided by the id-1 socket, but some tricks have to be used for the id-000 socket) - or by having a switch with 3 modes (sniff,emulation,MiM) (my favorite solution) I did a very simple PCB just to test the sniffer. I will take time to get a good design for the promising SIMtrac. kevin On 21.11.2010 20:53, Harald Welte wrote:
Hi!
On Sun, Nov 21, 2010 at 03:14:34PM +0100, ml@mail.tsaitgaist.info wrote:
His solution is way easier, and more reliable. This is why I've now done a hw design for it.
thanks a lot.
I don't know if it's the right mailing list, but it seemed to be the best.
well, I think it is low-traffic and we might just use this mailing list for the time being.
- the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it
I think we should consider the following use cases:
1) passive sniffer
this is what simtrace is doing right now and what your hardware is also prepared for.
2) card simulation
this is possible with the same circuit. Simply connect it _only_ to the phone and not to a smart card at all. The wiring will be the same, but the USART will be used in Rx and Tx mode. Only software/firmware changes required.
3) man in the middle
in this case, we want to connect as master (reader) to the SIM card, and as slave (card-side interface) to the phone.
In order to make we run USART0 as clock-slave (like in case 1 + 2 above), but we also connect a sim card socket to USART1, which we can then run in clock-master mode, i.e. like any 'regular' SAM7 based smart card reader.
The easiest solution would be to add yet another sim card socket which is connected to USART1 (TXD1/SCK1). But then we have 3-4 sim card sockets in one device, which I think is clumsy.
It may be possible to add some jumpers or dip switches that change the behavior, i.e. "one setting for sniffer + card simluation, another setting for man-in-the-middle"
here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly.
please take time for detailed review before doign any pcbs... thinking more before prototyping will save time and money.
Another request: Pleaes make the DRxD / DTxD (Debug UART) pins available on the board, preferrably on the same type of header that we use on the OpenPCD. It will not add any cost to the design, but enable you to print debug messages to a serial port, which is very useful during firmware development.
Also, the JTAG lines should be routed to a standard 20-pin ARM-JTAG connector.
Both the Debug-UART and the JTAG headers can not be placed/soldered for normal boards, but people who want to do development will likely find both of them very useful.
Regards, Harald
Hi! On Mon, Nov 22, 2010 at 01:39:07AM +0100, ml@mail.tsaitgaist.info wrote:
I did not yet add the MiM solution, because there are still have some open aspects : MiM : - should it use the clock provider by the reader
No, we don't want this. Real phones do things like CLOCKSTOP and we might not want to stop our actual SIM card during that time.
- or should we provided our own clock (3.8432MHz/9600bps for simplicity) using the reader clock would provide better timing but cold be harder to do (I don't know well this chip yet)
The AT91SAM7 can provide the clock on the SCLK0/SCLK1 pin of the USART, there is no need for any external circuitry.
emulation : - how to know what the user wants (sniff vs emulation) if the mode is combined with the sniffer ?
simply send a configuration message via USB from the simtrace program.
- the user has to tell the program
btw: please don't quote the full message at the bottom of your mail, thanks! -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
simply send a configuration message via USB from the simtrace program.
How about having the reader on port 0 and the sc on port 1 Then the 3 modes would be software controlled The sniffer part could be done by the MiM by just forwarding the messages. The freq could be regenerated, or forwarded using a software switch. It would not be a real sniffer, but simpler to design and implement. reset, clockstop, freq. changing, and proactive SIM could also be done by the chip. is there another SC feature that could be problematic ? apart using contact 4/8 which we ignore, and 20MHz freq. which I've never seen yet. Kevin
you have to take in consideration the "retransmission" also. the other thiing is that all cards are not 3.3v some are 1.8. that could be read in ATR. so if you want it to be compatible with any phone, you need on one side to give an ATR to the phone that tells it it could work with 3.3v and be able to read the actual sim with 1.8v... I've already done that kind of device a while ago with a FT2232 and scenix microcontroller. (http://88.191.12.21/fakesim.jpg) and I can mim, sniff, read... So i'm familiar with it. -- k2
Date: Mon, 22 Nov 2010 12:23:37 +0100 From: ml@mail.tsaitgaist.info To: laforge@gnumonks.org Subject: Re: simtrac hw CC: baseband-devel@lists.osmocom.org
simply send a configuration message via USB from the simtrace program.
How about having the reader on port 0 and the sc on port 1 Then the 3 modes would be software controlled The sniffer part could be done by the MiM by just forwarding the messages. The freq could be regenerated, or forwarded using a software switch. It would not be a real sniffer, but simpler to design and implement. reset, clockstop, freq. changing, and proactive SIM could also be done by the chip. is there another SC feature that could be problematic ? apart using contact 4/8 which we ignore, and 20MHz freq. which I've never seen yet.
Kevin
On Mon, Nov 22, 2010 at 12:23:37PM +0100, ml@mail.tsaitgaist.info wrote:
simply send a configuration message via USB from the simtrace program.
How about having the reader on port 0 and the sc on port 1 Then the 3 modes would be software controlled The sniffer part could be done by the MiM by just forwarding the messages.
A sniffer by definition is passive. Running MITM to sniff is modifying the behavior of the timing. I intentionally didn't want that. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
- the AT91SAM7SXXX
I'd use a more modern chip
no, no, no, no ;)
After seeing the schematic I tend to agree.
There is working firmware (drivers, T=0 sniffing, ...) for the AT91SAM7 now, I put quite a bit of effort into making this work. Furthermore, the AT91SAM7 USART has the unique property that you can use it in T=0 mode but still operate as clock slave, i.e. run as sniffer or card mode, not behaving like a card reader.
I think every sync serial peripheral that I've seen can operate in slave mode like that, and I agree that it's important.
We really do not need any external logic, simply connect the SIM card to the right pins of the SAM7, load the (gpl licensed, of course) firmware that I wrote and run the equally free software 'simtrace' host program + wireshark.
Porting this to a different microcontroller will again require significant development on the software side, which I don't think is what we need...
I disagree that significant effort would be required. It should be straightforward to use another controller, but since the schematic wouldn't really be much simpler there may not be much point to it. But one thing that I think matters is that it's very easy and cheap to get hold of a really simple (e.g.) LPC1343 development board in neat size that people could use instead of having to build their own hardware. I think that wall clock time would be about same for porting the software and producing a board. ml@mail.tsaitgaist.info wrote:
I could not login/register on the osmocom trac wiki to put the files there.
Hopefully someone will fix that.
Here the current version : https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps
Thanks for uploading it!
I added the JTAG and debug connectors. I hope it will not use more then 2 layers in the end, so normal people can build the pcb at home.
Since the crystal is around 18 MHz this might even work OK as a single layer board, maybe with a solid ground plane on the back for the ambitious.
- the user has to tell the program - or by detecting the presence of a card (provided by the id-1 socket, but some tricks have to be used for the id-000 socket) - or by having a switch with 3 modes (sniff,emulation,MiM) (my favorite solution)
It would be really nice to not have to deal with switches, and just let the host software tell the hardware which mode to use. A USB device control request could do the trick easily. //Peter
I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that? Scott On Mon, Nov 22, 2010 at 4:49 AM, Peter Stuge <peter@stuge.se> wrote:
Harald Welte wrote:
- the AT91SAM7SXXX
I'd use a more modern chip
no, no, no, no ;)
After seeing the schematic I tend to agree.
There is working firmware (drivers, T=0 sniffing, ...) for the AT91SAM7 now, I put quite a bit of effort into making this work. Furthermore, the AT91SAM7 USART has the unique property that you can use it in T=0 mode but still operate as clock slave, i.e. run as sniffer or card mode, not behaving like a card reader.
I think every sync serial peripheral that I've seen can operate in slave mode like that, and I agree that it's important.
We really do not need any external logic, simply connect the SIM card to the right pins of the SAM7, load the (gpl licensed, of course) firmware that I wrote and run the equally free software 'simtrace' host program + wireshark.
Porting this to a different microcontroller will again require significant development on the software side, which I don't think is what we need...
I disagree that significant effort would be required. It should be straightforward to use another controller, but since the schematic wouldn't really be much simpler there may not be much point to it.
But one thing that I think matters is that it's very easy and cheap to get hold of a really simple (e.g.) LPC1343 development board in neat size that people could use instead of having to build their own hardware. I think that wall clock time would be about same for porting the software and producing a board.
ml@mail.tsaitgaist.info wrote:
I could not login/register on the osmocom trac wiki to put the files there.
Hopefully someone will fix that.
Here the current version : https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps
Thanks for uploading it!
I added the JTAG and debug connectors. I hope it will not use more then 2 layers in the end, so normal people can build the pcb at home.
Since the crystal is around 18 MHz this might even work OK as a single layer board, maybe with a solid ground plane on the back for the ambitious.
- the user has to tell the program - or by detecting the presence of a card (provided by the id-1 socket, but some tricks have to be used for the id-000 socket) - or by having a switch with 3 modes (sniff,emulation,MiM) (my favorite solution)
It would be really nice to not have to deal with switches, and just let the host software tell the hardware which mode to use. A USB device control request could do the trick easily.
//Peter
Hi Scott, On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote:
I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that?
it will simply not work. the phone only implements the READER side interface, but not the CARD site interface. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Thanks Harald. Is there a doc somewhere to explain what that means? I'm confused, because to me "reader" and "sniffer" have sufficiently overlapping meanings. What does a SIM sniffer sniff? What benefit is there to support a MITM use case? Scott On Mon, Nov 22, 2010 at 1:29 PM, Harald Welte <laforge@gnumonks.org> wrote:
Hi Scott,
On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote:
I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that?
it will simply not work. the phone only implements the READER side interface, but not the CARD site interface.
-- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
MITM is useful to create a generic tool that is able to rewrite APDUs on-the-fly. Like a live apdu patcher. A sniffer only *listens* the sim<->reader lines, without writing anything. It's "passive" in the sense that all it does is listening. The timing is VERY important, a man in the middle will introduce latencies that can be *very* easily detected. It is essential that in a sniffer, all lines between the sim and the reader are directly, electrically connected, without any repeating hardware in the middle.
the other thing is that all cards are not 3.3v some are 1.8 In ALL situations, Vcc shall just be forwarded from the reader to the card. You can use an ADC line and a voltage divider to measure this line. This is important since a cold reset can be executed by the reader, and that will interrupt Vcc.
And I see that the 3rd edition of ISO7816-3 now mandates that: "No card shall be damaged when the interface device applies a class not supported by the card". So the voltage is not important. My opinion is that in practice, all SIMs vendors, that will want their cards to work on the largest number of phones, will support all the 3 voltage classes (5,3.3,1.8V). If not, you cannot destroy a card by applying any of these 3 supply voltages. Sebastien On Mon, Nov 22, 2010 at 1:21 PM, Scott Weisman <sweisman@pobox.com> wrote:
Thanks Harald. Is there a doc somewhere to explain what that means? I'm confused, because to me "reader" and "sniffer" have sufficiently overlapping meanings. What does a SIM sniffer sniff?
What benefit is there to support a MITM use case?
Scott
On Mon, Nov 22, 2010 at 1:29 PM, Harald Welte <laforge@gnumonks.org>wrote:
Hi Scott,
On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote:
I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that?
it will simply not work. the phone only implements the READER side interface, but not the CARD site interface.
-- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 22.11.2010 13:47, Sébastien Lorquet wrote:
MITM is useful to create a generic tool that is able to rewrite APDUs on-the-fly. Like a live apdu patcher. In this direction, we could interrupt the I/O line between reader and SC after the interesting header has been detected, and send our custom response. Thus the MitM would replaces the responses instead of patching them. This could lead having different states between SC and reader (general issue with MitM). Having to possibility to separately control the SC and reader could enable use to put them in the right state with additional APDU.
I did not mesure/test timings of SCs, so I can't tell it it's feasible, but with a fast processor (18MHz), may be ? With the interrupt solution (instead of patching and forwarding) the timing would modified only for the custom responses. This is good if the reader only does MitM detection on the average timing, but bad if it uses peaks as an alert. I don't know which is the most common (if there is)
So the voltage is not important. My opinion is that in practice, all SIMs vendors, that will want their cards to work on the largest number of phones, will support all the 3 voltage classes (5,3.3,1.8V). If not, you cannot destroy a card by applying any of these 3 supply voltages.
To be able to be compatible with all 3 classes, we could use multiple level shifter. It would make the hw more complicated and expensive, but would be the right way (if it's worse doing it)
thanls for your comments, and i'm happy to see we agree. regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. i think we don't need to worry about 5V anymore. Last time I've seen a 5V simcard is 10 years ago. Also, AFAIR those baseband processors that i've seen all are <= 3.3v, even for things as ancient as the calypso. -- Sent from a mobile device, excuse my short response
Also, we could add a SC reader mode, using the CCID USB profile. I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader)
regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort.
To be able to choose between 1.8v (class c) or 3.3v (class b), there is a manual switch. The other solution would be to use logic level shifter. here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps kevin
Also, we could add a SC reader mode, using the CCID USB profile. I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader)
regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort.
To be able to choose between 1.8v (class c) or 3.3v (class b), there is a manual switch. The other solution would be to use logic level shifter. here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps kevin
I found a listing of possible SIM sockets : http://www.mlelectronic.com/sim-card-connectors/sim-information.asp The push-push solution seems to be the best one. It also has a card presence switch, like the credit card size (id-1) generally has. This could make the software more accurate (in the mode menu for example) It's just harder to find in shops. kevin On 24.11.2010 09:17, ml@mail.tsaitgaist.info wrote:
Also, we could add a SC reader mode, using the CCID USB profile.
I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader)
regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort.
To be able to choose between 1.8v (class c) or 3.3v (class b), there is a manual switch. The other solution would be to use logic level shifter.
here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps
kevin
I continued the hardware design I added : - a switch, to choose between SIMtrace and normal SC reader. the USB CCID profile could be loaded during boot. VCC can be supplied to power the SC. - switches for the SC presence, included in the sockets - LEDs to show the current mode (green=reader,yellow=emulator,blue=sniffer,red=MitM) - transistor array to control the LEDs, SC connections, and I/O line - line names - .... as I'm not an electrician, could someone check if this could work, resistors/capacitors are missing, .... here the schema : https://gsm.tsaitgaist.info/SIMtrac/v0.4/SIMtrac.ps Kevin On 24.11.2010 09:17, ml@mail.tsaitgaist.info wrote:
To be able to choose between 1.8v (class c) or 3.3v (class b), there is a manual switch. The other solution would be to use logic level shifter.
here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps
kevin
this is quite basic smartcard terminology. a smart card reader is the master, it drives the clock, reset lines and issues commands to rhe card. the card is a slave to the clock and reset lines. on a protocol level, it only responds to commands by the reader. see iso 7816-3 for details on this. asynchronous t=0 is the predominant protocol used in sim cards. a sniffer just passively listens to the communication between card and reader. -- Sent from a mobile device, excuse my short response
Hi Peter, On Mon, Nov 22, 2010 at 03:49:09AM +0100, Peter Stuge wrote:
There is working firmware (drivers, T=0 sniffing, ...) for the AT91SAM7 now, I put quite a bit of effort into making this work. Furthermore, the AT91SAM7 USART has the unique property that you can use it in T=0 mode but still operate as clock slave, i.e. run as sniffer or card mode, not behaving like a card reader.
I think every sync serial peripheral that I've seen can operate in slave mode like that, and I agree that it's important.
Are you sure? Please note that the variant of ISO7816-3 that we primarily want is T=0 in asynchronous mode. Here we actually have I/O asynchronous to the clock (i.e. the clock is not a bit clock), but still want to derive the baud rate off an external clock (with programmable, non-power-of-two divider) Even for the SAM7 what we are doing is not documented, they only describe the T=0 USART mode with internal / master clock in their data sheet. The SAM7 USART is not used in synchronous mode. I'm not saying no other chip can do it, but I find it a very uncommon feature, as there is no regular commercial application to it. You either want a synchronous USART _or_ you want to operate in T=0 / T=1, but in the latter case: why would you ever do something else than implement an actual card reader? ;)
I disagree that significant effort would be required.
You will need to write drivers for the USB device controller (preferrably compatible to what simtrace currently understands, you will need to properly drive the USART, you will need a timer/counter block for waiting time detection and combine all that with the end-of-apdu-detection, nRST logic, PPS, etc. I would be surprised if you need less than two full days for development and debugging all of this. But for what? To what advantage? Even if the schematic lacks 3 or 4 components and is 10 EUR cheaper... who would want to invest that much time in something that is merely a tool that will never be produced in large quantities? Furthermore, a LPC1343 has only one UART, removing the man-in-the-middle option... and even card simulation will be difficult, as the UART has no T=0 mode and thus cannot generate the T=0 specific tri-stating of a single shared Rx/Tx line, and will not do the NACK that will pull the I/O line low during one of the two stop bits.
But one thing that I think matters is that it's very easy and cheap to get hold of a really simple (e.g.) LPC1343 development board in neat size that people could use instead of having to build their own hardware. I think that wall clock time would be about same for porting the software and producing a board.
I also agree. People will be either part of two groups: 1) people able to build their own hardware. They can use the SAM7-P64 or SAM7-H64 boards from Olimex (or similar boards) + the RebelSIM Scanner as mechanical adapter 2) people who are not able or interested in building stuff but who prefer to buy a product and simply use it. I don't think there is much room left for people actually building more than '1', i.e. producing the PCB, soldering it, etc. My approach is thus different: I'm discussing whether bitmanufaktur.de wants to include such a product into their (temporarily offline) webshop that also sells the openPCD, openPICC and openBeacon hardware. It looks good, but is likely to happen deep into Q1/2011, as far as I can tell (mostly due to constraints with their overloaded manufacturer). Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (8)
-
Christian Vogel -
Harald Welte -
Kevin Redon -
ml＠mail.tsaitgaist.info -
None None -
Peter Stuge -
Scott Weisman -
Sébastien Lorquet