This article was used for my experiments. It is very pity, but it is no longer online. I extracted it from Google cache.
Version 2.4 August 1999
Here you can find out, what is
written in a German medical card, or how much money there is left on a telephone card!
This document and the enclosed program may be distributed freely.
However using this document or parts of it in other publications is only allowed
with the mention of this source used. The card reader and the software have
the purpose to analyze telephone and medical cards. At this point I want to
refer to the relevant, national data protection laws. This publication is only
for studying purposes. For want-to-be-hackers : no - you can't refill a telephone card!
I do not guarantee the faultlessness of the software or the hardware. I feel not
responsible for any consequences resulting from the use of this publication.
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
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!
(nearly) everything, (nearly) every chipcard is standardized. The most important
standard and with that the basis for chipcards "Integrated circuit(s) cards with
contacts" is ISO 7816. Its most important contents can be found in the three
parts ISO 7816-1 to ISO 7816-3. Besides them there are defined ISO 7816-4 to
-10, which I won't enter into.
- ISO 7816-1 defines the physical characteristics of a chipcard
7816-2 defines the dimensions and location of the contacts
defines the electronic signals and the transmission protocols
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 
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
The ISO-reset and the reading of the ATR:
( Picture 2 )
Vcc __| .
. . . . .
. . . . . .
. ,___________, .
. . . . . .
Rst ______| . . |__________________________________...
. . ,___, .
,___, ,___, ,___, ,___,
Clk __________| |_______| |___|
|___| |___| |__...
. . . . .
. . . . . .
| ^ (0) ^ (1) ^ (2) ^ (3)
| Reset |
= : unknown
level (data valid)
: unknown level (data not
^ : 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
The ATR-Byte H1:
Chipcards may use many different
protocols : for example the well-known (and unaltered) I2C-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
1000 : I2C
00 : defined by ISO
1001 : 3-wire
10 : structure 1 }
1010 : 2-wire
01 : structure 2 } not defined by ISO
11 : structure 3 }
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
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
The card contains a 16 byte "big" memory (128 bit in NMOS(?)-technology).
There are cards with 64 bytes, too - for compatibility reasons here only the
first 16 bytes are relevant. A telecard is a synchronous chipcard, so to read
it you will follow the "instructions" as shown in the diagram (picture 2).
You can read all 16 (64) Bytes at once. Be aware that the first 4 bytes of
the memory obviously are no ATR - bytes! Unfortunately I don't have the complete
information at this time. (Has anybody infos about that ?)
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 . 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
(high / low nibble)
|Identification of the chip: (1,2,3)
$4F (very frequently) }
} 16 byte
$03 (rarely, only Uniqua) }
$1B, $01 : 64 byte cards
|Constant value: (1,2,3,4)
$F = Germany (and the Netherlands)
|"test code" = $5 (1,2,3,4)|
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)
|Year of fabrication
(4H) + 1990
e.g. 3 -> 1993
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"|
|Month of fabrication|
1 : From other publications
2 : Discovered with
my (ca.30) cards
3 : Information not very reliable
4 : 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 /
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:
4096 = 84
512 = 83
64 = 82
8 = 81
1 = 80
When you have got the number of "1" bits, you can calculate the remaining
Remaining credit = Number of bits in a memory
cell * Value of the memory cell
|Byte 8||Byte 9||Byte 10||Byte 11||Byte 12|
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!
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;
j := 0;
for i := 0 to 7 do
if ((x shr i) and 1) = 1 then inc(j);
AddBits := j;
Function Credit : word;
var i, j : byte;
h : word;
h := 0; j := 1;
for i := 1 to 5 do begin
h := ( AddBits( Buffer[13-i] ) * j ) + h;
j := j * 8;
Credit := h;
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.
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
I2C-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 I2C - 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
I2C - START and to read data . If you do not
succeed in doing this, then something is wrong with the contact, or you have an
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.
|$80||Health Insurance Name|
|$81||Health Insurance Number|
|$86||Name Supplement (e.g. "van")|
|$87||Surname (U.S.: Last Name)|
|$8A||Country - Code|
|$8B||Postcode (U.S.: Zip Code)|
|$8E||Check Sum (always 1 byte)|
|$C0||final data field:
(it contains only space
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
| | 100
|\ _____ b |/
c (PIN 1)
PIN 1 |/
1K T1 |> e (PIN 5)
\ o GND
ON / OFF part
| o +5V
| | 10K
\ S1 ___ 1n
PIN 14 |/
o----| >O----o CLK
PIN 16 |/
| | 10K
|\ _____ b |/
c | |/ PIN
PIN 17 |/
1K T2 |> e I/O
\ (PIN 7)
I/O - part
+-----o IC -
as near as possible !
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)
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
|From the ISO 7816-3 standard:
|The Eurochip SLE 443x:
|PCB2032 memory card IC:
|table 6||table 7||table 8|
my experience has shown that common cards (tel./KVK) use only about 5
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 I2C - 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