I. Introduction:

I had the idea to build a chipcard reader after seeing sundry
ads and articles. All the card readers shown there had one thing in common : a
micro-controller (e.g. PIC) or even a small microcomputer system. The price for
such a device was (and is) of course pretty high and it would be very hard to be
able to program it because of missing information. Then I have seen many
do-it-yourself instructions that showed how to connect a chip card more or less
direct to the parallel interface of the PC. It gave me the shivers, e.g. seeing
how the cards were supplied directly by the interface. No wonder, when the power
supply crashes sometimes.

I have been trying to make the circuit so simple as possible but trying to
guarantee a secure operation within the specifications at the same time. I think
I have succeeded : everything you need is a "chipcard contact unit" (e.g. from
Conrad), an ordinary CMOS buffer IC (4049) and a PC with a printer interface.
The costs will be about 7$ / 10 Marks - provided you don't fear the
do-it-yourself construction. Of course the chipcard must be controlled by
software completely, but even for very old computers it's no problem. Under
Windows you could even realize this with DLLs.

For the reader I have
written a program. There is a Pascal-Version (which I won't write further on)
and a C++ Version. It's written for LINUX, but porting it to other systems won't
be hard (see point IV).

II. The Chipcard:

Since the first chipcard (a telecard) from Thomson Semiconductors had been
introduced in the 80's, there is a great chipcard boom. In the meantime they
find application as moneycards, medical / health cards, identification cards,
etc. and the next generation is now coming, too : without any contacts they
can transceive data via a built-in coil, which also supplies it with energy!

Smart-cards and Memory-cards:
Generally one can distinguish between
two types of chipcards : smartcards (processorcards) and memorycards.
Memorycards are the far simpler types: they consist of a memory and if necessary
a security logic. Typical application : the telecard. Smartcards are much more
complex. They are nearly complete microcomputers : CPU (or microcontroller),
ROM, RAM, EEPROM and if needed a crypto (co-) processor are integrated on the
chip. They give a maximum of security to the user. A typical application is here
the money card.
 
Synchronous and Asynchronous Chipcards:

Looking at the same thing in a technical manner, one can distinguish between
synchronous and asynchronous chipcards. One can draw clear lines to the effort
of distinction in the point above : smartcards as the GSM-card or the money card
are asynchronous chipcards and memorycards as the telecard and the KVK are
synchronous chipcards.
They are called "synchronous" because the data on the
I/O-line is transmitted synchronous to the clock on the CLK-line. Typical
frequencies range from 10 to 50 kHz. Programming such a chipcard with the PC is
in general completely uncritical (in my LINUX program there is even no timing at
all...). Asynchronous chipcards are different : here is a relatively high clock
requiered for the processor. It is not generated on the chipcard itself, because
a crystal would be too big for the thin card. The frequencies used here reach
some megahertz - typical are for example 3.57 MHz. With a divisor of 372 you get
9600 baud and it's very handy that the used protocol resembles a serial
transmission (startbits, databits, stopbits). So you can use an ordinary UART
for the communication!
 

ISO 7816-1 defines the physical characteristics of a chipcard
ISO
7816-2 defines the dimensions and location of the contacts
ISO 7816-3
defines the electronic signals and the transmission protocols

The
Pinout:
The first you will be interested in, is surely the pinout (picture 1). This one
is used by the German telecard as well as by the medical card. Apart from this
"ISO - version" there is also defined the pin-out according to AFNOR (see [5]
for more).

The Initialization (Reset and ATR):
The second you will have to know is the communication with the card: after the
reset of an ISO - card, you can read the 4 ATR - bytes (picture 2). This so-called
Answer-To-Reset contains information about the card and its protocol
(picture 3). Please be aware that you can only employ this reset on synchronous
chipcards!
 
 
The ISO-reset and the reading of the ATR:       
( Picture 2 )

           ,__________________________________________________...

   Vcc   __|   .  
.   .   .   .   .  
.   .   .   .   .   .

           .   ,___________,   .  
.   .   .   .   .   .  
.
   Rst   ______|   .   .   |__________________________________...

           .   .   ,___,   .  
,___,   ,___,   ,___,   ,___,
   Clk   __________|   |_______|   |___|  
|___|   |___|   |__...
           . t
.   .   .   .   .  
.   .   .   .   .   .  
.
   I/O   x=====x=======x=======x=======x==...
           |              
|  ^ (0)   ^ (1)   ^ (2)   ^ (3)
           | Reset         |
Read
 

         = : unknown
level (data valid)
         : unknown level (data not
valid)
         ^ : point of time to read
the bit and bit number in brackets
         t : 1 time unit (>10us)
<- not completely concurring with ISO, but it's OK.
 
         voltage levels : >0V
and <Vcc

The ATR-Byte H1:
Chipcards may use many different
protocols : for example the well-known (and unaltered) I²C-protocol, the 2-wire or the 3-wire protocol. The
cardreader can handle all three of them.
 
The first ATR - byte
(H1) shows, which protocol is employed:
 

             
H1 : Protocol Byte
                                                         
( Picture 3 )
  BIT   :   7  6  5  4  3 
2  1  0
           \__________/     
\____/
 
            protocol       
structure
              
|               
|
              
|               
|
           1000 : I²C         
00 : defined by ISO
           1001 : 3-wire      
10 : structure 1  }
           1010 : 2-wire      
01 : structure 2  } not defined by ISO
                              
11 : structure 3  }
 

"Epilogue":
Let
me say a word about the standards: apparently it's a fault to believe that you
can easily get access to standards. At least this is true for the ISO -
standard, a large number of publications is referring to - e.g. this one. People
only with a small amount of money available (students) don't need to look at
www.iso.ch.
An alternative is to examine other organizations,
e.g. ECMA. They could have the same standard - only under an other number but
for free. At this point I want to refer to the "standards-faq", which has
more information on this topic.
 
 
II.1. The Telecard / Phone Card:

The most known application is surely the telecard. It has a certain value,
which is reduced by using it, until there are no more units left on the card.

"Manual Analysis" - Description of the Numbers:
To get information
about a certain card, you need not necessarily a card reader at once. All
informations are already printed on the card except the instantaneously
remaining units. (Actually only a part of this information is stored on the chip
itself !)
 
 

The memory is split in different types:

 

64 bit EPROM	:	Informationen about the telecard
40 bit EEPROM with security logic	:	Memory for the remaining credit
24 bit EEPROM, normally set to "1"	:	No function, writable on 64 byte cards

 

This table is taken from [3]. But in my opinion it's not very likely that there
are used two different types of memory. It's more plausible that there is used
only one EEPROM with memory-areas under different security levels (a de
facto ROM and not EPROM).
 
 
The memory area $00 - $07
(read-only):

 

Byte   (high / low nibble)	Description:
0H,0L	Identification of the chip: (1,2,3)    $4F (very frequently)     }     $2F (rarely)              } 16 byte     $03 (rarely, only Uniqua) }    ---------------------------    $1B, $01 : 64 byte cards
1H	Constant value: (1,2,3,4)    $F
2H	Country: (1,3)    $F = Germany (and the Netherlands)
3H	"test code" = $5 (1,2,3,4)
3L	Card manufacturer     0 = Orga Kartensysteme (1,3)     1 = Giesecke & Devrient (G&D)     2 = Oldenbourg Datensysteme (ODS)     3 = Gemplus     4 = Solaic     5 = Orga, (Uniqua 1,3)     6 = Schlumberger (1,3)
4H	Year of fabrication     (4H) + 1990     e.g. 3 -> 1993
4L	Nominal value:     3 =  1,50 DM     4 =  6,00 DM     5 = 12,00 DM     6 = 60,00 DM (1,3)     7 = 50,00 DM
7H+7L+6H+6L+5H	"internal serial number"
5L	Month of fabrication

 

¹ : From other publications
² : Discovered with
my (ca.30) cards
³ : Information not very reliable

⁴ : Meaning unknown
 
(As you can see, there's
much not very reliable. So who can help me?)
Only information without
footnote is reliable.

 
The memory area $08 - $0C (read /
write):

That's the 5 byte memory (the so-called octal counter) where the remaining
credit is stored - unfortunately it's a bit difficult to calculate.

1. Each byte contains a number of bits, set
to "1". So a byte can have only 9 different "levels".
 e.g. 00000011 = 01001000 = 2  

2. Every memory cell from 8 to 12 is attached
a certain value:
 

Memory cell:	Value:
8	4096 = 84
9	512 = 83
10	64 = 82
11	8 = 81
12	1 = 80

 
 
When you have got the number of "1" bits, you can calculate the remaining
credit.
 
  Remaining credit = Number of bits in a memory
cell * Value of the memory cell  

Example:
 
 

Byte 8	Byte 9	Byte 10	Byte 11	Byte 12
01000000	00000000	00001101	00110110	00000000

Credit := 4096*1 + 512*0 + 64*3 + 8*4 + 1*0
Credit := 4320
 
You get a credit of 4320 units
For a German telecard you get 4320 "Pfennigs" or 43,20 marks!
 
 
Pascal code:
 
A simple function (out of my program) to calculate the credit:
 
var Buffer : array[0..15]of byte;  (* here the data
must be read in *)
 
Function AddBits(x : byte) : byte;
var i, j : byte;
begin
  j := 0;
  for i := 0 to 7 do
    if ((x shr i) and 1) = 1 then inc(j);
  AddBits := j;
end;
 
Function Credit : word;
var i, j : byte;
    h    : word;
begin
  h := 0;  j := 1;
  for i := 1 to 5 do begin
    h := ( AddBits( Buffer[13-i] ) * j ) + h;
    j := j * 8;
  end;
  Credit := h;
end;

II.2. The German Medical / Health Card (KVK):

 
The medical card is also a very
well-known application for chipcards in Germany. Its contents are prescribed by
law and it's employed to identify an insurant and to settle up medical services.
Our Austrian neighbors are now introducing a medical card till 2002, too, which
will be similar to our KVK.
 
The Chip:
Every KVK is a
synchronous 256-Byte memorycard. There can be used various protocols. For
example the IC PCB 2032 from Philips Semiconductors uses the 2-wire protocol
(ISO protocol S=10). To my information the SLE 4432 is the same chip from
Siemens. Who knows other chip types / numbers (used in any chipcards)!

 
Reset - Characteristics:
Most medical cards use the
I²C-protocol, but there are 2-wire cards as
well. If you have a 2-wire card you can read the 4 ATR - bytes and then $FF. Now
the first ATR-Byte will clearly identify this card as a 2-wire card and for
further access you will certainly use the 2-wire-routines. An I²C - card on the other hand is not reacting to an
ISO-reset. You will only read $FFs. In this case you will try to send an
I²C - START and to read data . If you do not
succeed in doing this, then something is wrong with the contact, or you have an
unknown card.
 
The Memory Structure:
The relevant data of a KVK is found from address $1E on. That's the case if
you were able to read in a $60 at this address. With the next byte you calculate
the start address of the datafields. Unfortunately I don't have safe information
about this - have a look in the source for the temporary solution, which seems
to work very fine! All further bytes must then be scanned for tags (a byte >=
$80). Each tag has a special meaning (see table). Then follows a second byte
that shows how long the data field is and after this you can read the datafield
in German ASCII till the next tag appears. The last tag is $C0 for the final
data field. The next byte shows, how many spaces ($20) follow to "fill up" the
remaining memory. The last byte (at address $FF) is set to $00.

 
 For more, have a
look into the source-code.
 Has anybody information about how the
check sum is created?
 (Somebody has told me that it is a
XOR-connection within the data fields)
 
Attention: Medical cards can easily be written to.
Don't make any frivolous tests or / and make a backup to be able to restore lost
data.
 

Switch S1 is on the "chipcard contact unit". On mine the switch is open if a
card is in the unit. (By the way, I have been leaving away the "ON / OFF Part" :
Vcc for the chipcard is directly connected to the switch S1 - of course now the
10k resistor must be exchanged with a 100 Ohm resistor)
 
A problem
could be the 5V power supply. You can take it from the computer (as I have done
it), e.g. joystick port / keyboard (but it's dangerous, because a 5V
short-circuit will mean the end for your computer). The best would be a voltage
stabilized power supply with the voltage in between 4.75V and 5.25V (see table
6) as ISO demands it, even if there are some chipcard ICs with a higher
tolerance.
 

Actually
my experience has shown that common cards (tel./KVK) use only about 5
mA.
 
If the reader shall only read
telephone cards, you can leave transistor T2 (and the two resistors and the
buffer, of course, too) in the I/O - part. You may not leave it, if you
(only) want to read I²C - cards, too : you have
to send the START / STOP signals!! For T1 and T2 you can use any ordinary NPN
small signal type, e.g. BC547, BC283 etc.

If you disconnect the reader and the power supply
is not off, then the levels on the outputs of the buffers are undefined. (perhaps
they oscillate) and if a card is inserted, it might be destroyed. If this is
the case (e.g. with a printer switch) you should solder a 10K pull-down resistor
at each input of a buffer.
 
V. Bibliography / Links:

1. PICs Kartentricks, Bassem Yahya, ELRAD 1995, Heft 2, S.29-36
2. Kartentricks, Peter Laackmann, Marcus Janke, c't 9/93, S.158