simtrac hw

historical

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)