bachelor

Cryptanalysis of Rejsekortet
Jens Christian Hillerup
Kongens Lyngby 2010

Technical University of Denmark
Informatics and Mathematical Modelling
Building 321, DK-2800 Kongens Lyngby, Denmark
Phone +45 45253351, Fax +45 45882673
reception@imm.dtu.dk
www.imm.dtu.dk

3
Abstract.
This bachelor thesis analyzes the security of the new Danish
ticketing system Rejsekortet. Until now nobody has conducted
any independent research on the security of this system, which is
somewhat surprising because the same system is already rolled
out in Sweden. Using documentation of older versions of the
system, the security has been assessed. Most promising, this
thesis contributes a precomputation attack against a DES-MAC
function implemented in Rejsekortet. This is possible because
of a data structure on the card offering controllable plaintext.
The controlled plaintext can be used as a constant value from
which a rainbow table is derived, enabling the attacker to look
up keys in manageble time and space. The worst-case consequence
of this attack is that it enables a determined attacker to
add money or tickets to not only his own but anybody’s card,
severely harming the system as a whole. Different immediately
applicable countermeasures for this attack are also presented. It
is concluded that the precomputation attack needs more study
before anything can said about its applicability to the current
version of Rejsekortet.

Summary
This bachelor’s thesis is completed in spring 2010, and deals with the new Danish
ticketing system called Rejsekortet, which is expected to be in nationwide
production in metros, busses and trains sometime in 2012. The system is designed
to completely replace paper tickets with the reasoning that it will become
easier to administer fare prices, as well as being able to make very precise models
for the traffic flow, which in turn will be able to aid in possible reorganization
of the public transit net.
Rejsekortet is designed to function offline, which entails that data such as the
card balance and active tickets are stored on the card. To prevent card-based
fraud, a series of security mechanisms has been set in place, each providing to
a layered security model. One of these mechanisms is the card itself, which
from the factory has a cryptographic mechanism securing against unauthorized
reading or writing to the card. Another mechanism is a recognized authenticity
verification algorithm (a “MAC”), put in place to ensure overall safety of the
card in case the card is compromised. The third layer is a nightly run-thorough
of the transaction database, in order to prevent cards being copied, etc.
The thesis presents an attack on one of these security measures, namely a timememory
trade-off that allows recovery of a secret key for the aforementioned
authentication algorithm that is executed during Rejsekort transactions. In
addition, the thesis presents an analysis of possible exploitation opportunities if
the key for the authenticity check becomes publicly known.

Resumé
Denne bachelorafhandling er udarbejdet i foråret 2010, og omhandler det nye
danske billeteringssystem Rejsekortet, som forventes i landsdækkende drift i
metroer, busser og tog i løbet af 2012. Systemet skal erstatte papirbilletter
med den begrundelse at det bliver lettere at administrere priser, samt at kunne
fastlægge helt klare modeller for trafik-flowet, hvilket kan hjælpe i eventuelle
omlægninger af busser og tog.
Rejsekortet er designet til at kunne fungere offline, og det medfølger at data
som saldo og aktive billetter lagres på kortet. For at undgå snyd med Rejsekortet,
er der blevet implementeret en række forskellige sikkerhedsforanstaltninger,
der hver for sig udgør en “lagkage” af forskellige sikringer, der bygger
ovenpå hinanden. En er kortet selv, der fra fabrikken har kryptografisk sikring
mod uautoriseret læsning og skrivning til kortet. En anden er en anerkendt
autenticitetstjek-algoritme (en “MAC”), der skal sikre kortet hvis den første
sikring bliver kompromitteret. Tredje lag er en natlig gennemgang af transaktionsdatabasen,
for blandt andet at sikre sig mod at kort bliver kopieret, mm.
Opgaven præsenterer et angreb på en af disse sikkerhedsforanstaltninger, navnlig
et time-memory trade-off, der tillader at finde en hemmelig nøgle til grund
for det føromtalte autenticitetstjek, der foregår i forbindelse med Rejsekorttransaktioner.
Herudover fremlægges der en analyse af mulige udnyttelsesmuligheder,
hvis nøglen til autenticitetstjekket bliver offentligt kendt.

Preface
This thesis was prepared at Informatics Mathematical Modelling, the Technical
University of Denmark in partial fulfillment of the requirements for acquiring
the bachelor’s degree in engineering. The project was started in February and
consists of 15 ECTS points. The thesis deals with the security of Rejsekortet, a
new Danish/Swedish travel card standard. The focus has been to find a vector
for a cryptographic weakness in Rejsekortet per RKF standards A, B and C,
with the aid of once-available standards documentation. Currently the system
runs in a later version to which the specifications are not available.
An obstacle in the project has been the unavailability of current documentation
of the RKF specification. It has made it more difficult to get a precise
understanding of the data recovered with card dumps.
Finally it is certified that this thesis is written by myself in full to the best of
my ability, and with citation clearly sourced where due.
Virum, June 2010
Jens Christian Hillerup

vi
Glossary
Rejsekort(et)
Danish for “travel card” or “the travel card,” a new Mifare-based ticketing
system for public transportation in Denmark.
The language if this thesis is English, but still the Danish conjugations of the
substantive “Rejsekort” are used. In Danish the definite and indefinite article is
the same, and for a neuter word like Rejsekort it is “et.” The difference is that
the definite article goes after the word instead of before like in other languages.
That entails that “Rejsekortet” is the definite version “Rejsekort.” In addition,
the plural of “Rejsekort” is “Rejsekort.”
RKF, Rejsekortsforeningen
A Swedish company responsible for development of Rejsekortet.
Rejsekort A/S
A Danish company responsible for implementing and developing the travel card
standard set by RKF, as well as rolling the solution out nationwide.

Acknowledgements
I wish to thank Christian Panton for bringing Rejsekortet to my attention as
an interesting subject for my bachelor’s thesis, and for the initial research he
conducted before this project was launched.
Moreover I’d like to thank Nikolas Bang Manscher, Julie Falck Valentin-Hjorth,
Mathias Brade, Tim Garbos, Anton Breum, Laura Jespersen-Kaae, Toke Højby
Lorentzen, Ulrik Borch, Niels Emil Hillerup and David Kofoed Wind for proofreading
in all stages of the project.
Finally I would like to thank Erik Zenner for invaluable feedback and consultancy
during the preparation of this thesis.

viii

Contents
Summary
Resumé
Preface
Acknowledgements
i
iii
v
ix
1 On Rejsekortet 1
1.1 History of the project . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Technology and card layout . . . . . . . . . . . . . . . . . . . . . 5
1.3 Grades of security . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 Security analysis and threat model 29
2.1 Threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Attack classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Analysis of the security . . . . . . . . . . . . . . . . . . . . . . . 34
3 Attacks on Rejsekortet 41
3.1 Rollback attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Attacking the MAC . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Masquerading attacks . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4 Attacks on the infrastructure . . . . . . . . . . . . . . . . . . . . 80
3.5 Vandalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4 Improvements 89
4.1 Improvements since version 1 and 2 . . . . . . . . . . . . . . . . . 90
4.2 Other immediately applicable improvements . . . . . . . . . . . . 96

x
CONTENTS
4.3 Other improvements . . . . . . . . . . . . . . . . . . . . . . . . . 98
5 Conclusion 99
A Related research 103
A.1 Mifare keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B Mail correspondence 107
B.1 Mail correspondance with Margareta Berg from Resekort Sweden 108
B.2 Mail correspondance with Gregers Mogensen from Rejsekort Danmark
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Chapter 1
On Rejsekortet
Rejsekortet (“the travel card”) is a new system for the Danish network of public
transportation. It is meant to completely replace paper tickets sometime in 2011,
and the project has been in the works since 1995 1 , and has at the time of writing
cost more than a billion Danish kroner 2 .
The card works as a check-in/check-out system in the sense that one “checks
in” while entering e.g. a bus and “checks out” leaving it. The system then
calculates the fare and draws the amount from the card. Moreover the card
supports various degrees of discount, interoperability across borders, and much
more.
The initial specifications were presented by a Swedish company called Resekortsföreningen
(RKF), in order to establish a common standard of travel cards in
Scandinavia. Different public transit organizations could then choose to implement
this new standard, and expect the cards to work seamlessly with the other
systems. Currently, Sweden is the only country to have a travel card using this
standard in production.
1 http://vtu.dk/filer/publikationer/1998/rapport-fra-arbejdsgruppen-om-kortteknologi-oghandicappede/html/dok10.html
2 http://www.business.dk/transport/barsk-kritik-af-nyt-rejsekort-system

2 On Rejsekortet
Disclaimer: This report is concerned with the Rejsekort versions A, B and
C, described in documents RKF-0020[7] (requirements specification) and RKF-
0022[6] (implementation specification), since it was impossible to obtain the
specification for the newest version of the system, see B.2.
RKF-0020 describes what is expected of the system. It outlines the basis for
interoperability, the data types and the desired level of security.
RKF-0022 describes the implementation details; this includes full descriptions
of all the relevant data types on the card, how they are placed and coded, and
also how the data is secured by means of a MAC, see 1.3.2.
Moreover there is a spreadsheet with ID RKF-0025[5] that describes bit-for-bit
where data is positioned on a Rejsekort. From that it is possible to make a
parser that can read Rejsekort, and possibly to write RKF-compliant data back
onto the card.
These documents can be found on the enclosed CD-ROM.
1.1 History of the project
The plans of establishing a travel card system in Denmark were made in 1995 as
a joint venture by the various Danish public transit companies. After a meeting
October 1st 1997 the project was officially started 3 .
Development went on rather quietly until 2000 when Resekortföreningen i Norden
was founded. This company comprised of Danish and Swedish public transport
organisations. In 2001 the system is defined, and the specifications are
written. RKF-0020, RKF-0022 and RKF-0025 are all dated in 2002, and were
once available from the website of Resekortföreningen i Norden. This company
has since been dissolved, and the specifications are no longer available.
In 2003 the Danish public limited company Rejsekortet A/S was founded, and
several public transport organisations joined in 4 . Rejsekort A/S makes a call
for providers of the system implementing the standard from RKF, and the company
East-West Denmark won. This company is owned by Thales Group and
Accenture, and Thales writes in a 2005 press release that Rejsekortet is planned
3 http://vtu.dk/filer/publikationer/1998/rapport-fra-arbejdsgruppen-om-kortteknologi-og-handicappede/
html/dok10.html
4 http://rejsekort.dk/Om+Rejsekort/Historie

1.2 Technology and card layout 3
for nationwide production in 2007 5 .
At the time of writing (May 2010) the system is in the testing phase in two
relatively small parts of Denmark, and it is planned to be rolled out in small
steps until the system is covering all of Denmark in 2012.
1.2 Technology and card layout
Travel cards have been marketed with many different technologies since the
conception of the idea in the mid-nineties. However, in recent years a de-facto
standard seems to have merged. The system is called Mifare and is marketed
by NXP Semiconductors. It is the basis of many travel cards worldwide.
The immediate advantages with a digital ticketing solution rather than paper
tickets are increased precision in usage data, ease of maintenance of travel pricing,
etc. The disadvantage is that, unless utmost care is exercised, the digitalizing
will make it possible to make data appear as if it is issued by Rejsekortet
A/S themselves. This is much more difficult with paper tickets carrying holograms,
etc. Data is data, and cannot be secured by means of holograms or other
physical measures. This chapter will describe exactly how the cards work, and
what digital security measures are taken to ensure that attackers cannot forge
tickets.
1.2.1 RFID
RFID (Radio Frequency IDentification) is a technology that allows touch-less
interaction between a powered base station and a “tag.” Tags can be active
or passive, depending on whether or not it has a battery; generally the active
tags have a longer range than the passive, with the added cost of having to
be powered at all times. Passive tags are powered by induction. The terminal
creates an electromagnetic field that the tag can use to induce a current giving
it enough power to run a small integrated circuit. This circuit can then transmit
a signal back to the terminal.
Some RFID implementations, however, implement more advanced data processing
than just replying back some constant. This is the case with the Mifare
Classic standard which Rejsekortet is built on, see 1.2.3. Mifare Classic chips
5 http://www.thalesgroup.com/Press_Releases/Security_PressRelease_13-09-2005/

4 On Rejsekortet
are even capable of running a small cryptographic cipher, plus implementing
access conditions for separate portions of the on-board storage on the card.
1.2.2 The infrastructure of Rejsekortet
Rejsekortet comprises of three basic entities, namely the cards, the terminals
and the back-office. Cards are held by the commuters using the system, and
terminals are installed on stations and in buses.
Not much is known about communication with the back-office, but it is certain
that the terminals synchronize at least their event log (storing special “Transaction
IDs” specific to the cards) with a central database, either live or on a
buffered basis. The buffered readers would be installed in buses, and only occasionally
transmit their buffer with the back-office. One could imagine a solution
where buses would synchronize at some traffic centre, such as the town hall
square for the Copenhagen buses, in order to reduce costs.
1.2.2.1 Check-in and check-out
When a user wants to travel somewhere with a Rejsekort, he/she will “check in”
on the designated terminals at the station of origin. This will create a certain
data element on the card describing the time and place of the check-in, and write
that to the card. Any intermediate stops require another check-in, in order for
the system to calculate the fare correctly—these check-ins will also be stored
on the card. If the card is checked by a ticket conductor during the trip the
scanner will parse this data structure and check for these “check-ins.”
After the trip the user checks out at the terminals on the station. The terminal
presents the fare and draws the money from the card. An important thing to
note is that the card stores this information, so in order to restrict tampering
it implements some systems preventing this abuse, see section 1.3.
1.2.2.2 The different kinds of cards
There are three different types of Rejsekort, each aimed at different kinds of
users. This gives the system an advantage over the conventional punching card
system currently in use in Denmark (“klippekort”), because it is possible to

1.2 Technology and card layout 5
make very precise profiles of each card’s usage patterns, etc. The three different
types are:
• Personalized: These cards are personal, and the name and photo of the
owner is printed on the card. This will likely be the standard card that
commuting Danes will use.
• Pseudo-anonymous, also known as “Rejsekortet Flex:” This card is
flexible in the sense that it can be used by anyone, not just the owner.
This would for example be used in companies that pay for the employees’
occasional travel, or parents who own a card that their children use.
• Anonymous: This card is likely targeted for tourists and other travellers.
It is completely anonymous and can be used by whoever possesses it. This
card is currently not marketed on the website for Rejsekortet, which only
reinforces the thesis of it being for tourists. Never the less, it can be
assumed that these cards are possible to get hold of once the system is
deployed nationwide.
Source: [8].
There are different grades of discounts available in the system. To encourage
people to use the personal version of the card, the highest level of discount
attainable is only available in the fully personalized version. Flex users get
“zero to medium” discount, and the same goes for anonymous users, [8].
1.2.2.3 Terminals
This thesis deals with three different types of terminals used in the Rejsekort
system. These are:
• Check-in terminals are used on stations when a user wants to commence
a travel.
• Top-up terminals are used for loading money from a credit card to a
Rejsekort. These are also situated on stations, and do not require the user
to hold the card in front of a reader. Instead the user is supposed to put
the card into a slot.
• Conductor terminals are used by conductors on buses or trains to check
if the users have checked-in.

6 On Rejsekortet
1.2.3 Mifare
Mifare is a family of ticketing systems made by NXP Semiconductors. The
system implemented by Rejsekortet is called Mifare Classic, and it is widely used
worldwide for physical access control and ticketing systems, e.g. the Oyster card
in the English subway and the student card at the IT University of Copenhagen
for door access. With over one billion smart cards sold Mifare is the most
widely deployed physical access control system worldwide 6 . It is used not only
for trains, metros and buses, but also for door and port access.
1.2.3.1 The hardware
Mifare hardware exists in many flavours, such as wrist bands, number signs for
the backs of race runners, wrist watches, cellphones, and of course cards. Some
of this hardware support the Mifare Classic protocol, but for this project we
are only concerned with the subset of Mifare products that is the Mifare Classic
cards.
1.2.3.2 Sectors and blocks
Mifare Classic cards come in two variants, 1K and 4K, having an EEPROM
memory of 1024 bytes or 4096 bytes, respectively. The memory is laid out as
seen on Figure 1.1.
• 1K and 4K cards have the same first 1024 bytes: 16 sectors, each consisting
of 4 blocks. One block can hold 16 bytes.
• 4K cards have 12 additional larger sectors, each consisting of 16 blocks.
The blocks are of the same size, so these larger sectors can carry 16 · 16 =
256 bytes.
The last block in a sector always holds key and access control information used
by the authentication procedure to determine exactly how data can be read or
modified. The data structure holds:
• Key A: 6 bytes. The primary key for the sector. This key can never be
read out from hardware, but grants complete access to the sector if a user
has it.
6 http://www.mifare.net/, see “The success of MIFARE”

1.2 Technology and card layout 7
Figure 1.1: The Mifare memory layout. Figure by de Koning Gans et. al, used
with permission.
• Access control: 3 bytes. These bits define the access conditions for the
sector. See 1.2.3.3 for a list of functions these bytes govern access to.
• An unused byte.
• Key B: 6 bytes. This is the secondary key. It can have access control
separate to key A,
The first block of the first sector of every Mifare card is a little special; it is
burned into the card and cannot be changed, ever. It contains the manufacturer
data of the card, including the cards unique ID. For this reason sector 0 only
has only two writable blocks instead of three, see Figure 1.1.
1.2.3.3 Challenge/response
Mifare implements a challenge/response protocol that must be satisfied before
a terminal can log in to a card. The protocol is described in [3], and can be
described in plain text as seen in Figure 1.2.
After authenticating to the sector, the card provides the following actions, for
some given block in the sector:

8 On Rejsekortet
1. Reader sends a “select” request.
2. Tag replies with its unique ID.
3. Reader sends a directed “select” request, including the tag’s unique ID.
This prevents collisions when two tags are within the reach of the reader.
4. Reader tries to authenticate to some sector.
5. Tag picks a challenge nonce and sends it to the reader.
6. Reader sends a challenge nonce, as well as a response to the tag’s challenge.
7. Tag sends a response to the reader’s challenge.
Figure 1.2: Authentication protocol of Mifare
• Read: Reads the content of the given block.
• Write: Writes some given data to the given block.
• Increment: Treats the block contents as an integer and increments it by
a given value.
• Decrement: Like “Increment,” but it decrements.
• Copy: Copies the content of a block onto another. This can be used for
backup.
The incrementation and decrementing functions make Mifare attractable to use
for ticketing systems since a purse can be implemented atomically.
Note that the access control bytes for the sector dictate whether or not these
functions can be used.
1.2.3.4 Ensuring internal card consistency
Rejsekortet implements a system that makes card transactions indivisible. This
is to ensure that a card does not get corrupted if the user removes it prematurely
during a transaction; either an entire transaction is carried out, or no transaction
is carried out.

1.2 Technology and card layout 9
The system furthermore differentiates between different kinds of sector types, by
defining different application types to them. They define how data redundancy
is managed for that specific data field and, and how the data is arranged.
Some application types are used only for one data structure on the card, e.g.
AT2. AT2 is the type used for storing tickets currently active on the card. There
are two data elements “taking turns” in containing the newest version, as well
as some number 1 ≤ n ≤ 6 of additional elements, containing a log of old tickets
on the card.
The card contains a data structure, TCAS 7 , that keeps the ID of the last transaction,
as well as the status of all the sectors. The sector status variable defines
which of the two redundancy elements is the current, depending on the application
type of the sector. This is important, because no current data is ever
supposed to be overwritten in Rejsekortet; if some value on the card is going to
have a new value, the data will be written to the unused sector first, and then
the section status will be changed so as to reflect that the current data is in the
“other part” of sector.
Ultimately, Rejsekort consistency is ensured by also having two copies of the
TCAS field. At each transaction this structure is written twice to the card,
in predetermined sectors. This makes the system very robust to connection
disturbance, because the card will always be able to use the old TCAS in case of a
communications fall-out. There are four phases of a transmission in Rejsekortet:
1. Writing the new data to the unused fields.
2. Writing the new TCAS1 to its designated sector. This value has another
sector status for the altered data field, making the just-written data current.
3. Writing the new TCAS2 which is equal to TCAS1. TCAS2, as we shall see,
is used if the next transaction falls out and TCAS1 becomes inconsistent.
From [6] we have this table over transaction breakdowns and how the system
will react (quote):
As stated, if TCAS1 is inconsistent, TCAS2 will be used. This leads to the card
being temporarily “rolled back” because the TCAS pointed to the non-recent
data elements.
7 Travel Card Application Status

10 On Rejsekortet
Time of transaction
breakdown
Writing of data
Writing of TCAS1
Writing of TCAS2
No breakdown
Consequences
The transaction is not completed.
Next transaction will use TCAS1.
The transaction not completed.
By the start of the next transaction
TCAS1 will be inconsistent, i.e.
TCAS2 is used.
The transaction is completed.
By the start of the next transaction
TCAS2 will be inconsistent, i.e.
TCAS1 is used.
The transaction is completed.
Next transaction will use TCAS1,
which is identical to TCAS2.
One application type, however, does not have redundancy. This type is only
used by the “customer profile” field, which in turn is only alterable in the topup-terminals.
These terminals require the user to put the card into a slot which
drastically reduces the risk of transmission errors, which might be the reason
for saving the redundancy space for something else.
1.2.3.5 Transaction numbers
RKF-0022 also talks about various kinds of transaction IDs. Some are internal
to the system, some are internal to the card. All in all there are four different
kinds of transaction numbers, stored in different areas of the card (parts quoted
from RKF-0022):
• Card transaction number: Identifies complete transactions. The transaction
number is local to each travel card.
• Device transaction number: Identifies transactions completed by a front
system. The transaction number is local to each front system device.
• Purse transaction number: Identifies purse transactions. The transaction
number is local to each purse object (which can be assumed to be one per
card.)
• Ticket/contract transaction number: Identifies ticket/contract transactions.
The transaction number is local to each travel card ticket and

1.3 Grades of security 11
contract object, respectively (which can also be assumed to be one per
card.)
These values are probably available to the back-office system.
known that the card transaction number is, see page 52 in [6].
At least it is
1.3 Grades of security
One argument used in the defense of Rejsekortet has been that it implements
several layers of security, and that if one of the layers are broken the other ones
will act redundantly. The layers implemented are the Mifare proprietary crypto,
DES-MAC checksums for the important blocks on the card, and finally a nightly
inspection of the database to determine if users have tried to fool the system in
some way.
1.3.1 Mifare / Crypto-1
Mifare implements a proprietary cryptosystem, Crypto-1, to protect the contents
of the card. The cipher has been proved to be rather weak, and recent
attacks allow an adversary to decrypt and dump the contents of the card in
minutes, see 1.3.1.1.
Crypto-1 is a stream cipher with a key size of 48 bits, but further description is
not in the scope of this thesis. A more detailed description of the cryptosystem
can be found in [2].
1.3.1.1 Mifare insecurities
Because of the market penetration of Mifare it is a very attractive target for
cryptographic attacks. Mifare implements a proprietary cryptosystem called
Crypto-1, which has been proven insufficient by some recent scientific papers.
The most serious attack is presented by Garcia et. al. in a paper called “Wirelessly
Pickpocketing a Mifare Classic Card”[3]. The attack is called the Nested
Authentication attack, and allows an adversary to recover encryption keys for
any sector given the key for just one. This enables an attacker to quickly recover
all keys for a card, given just one. In short, the attack works by being able to

12 On Rejsekortet
Figure 1.3: The Crypto-1 cipher internals.
control a nonce sent by the tag because it depends on the timing of the authentication.
If a reader is already authenticated with one sector, the specification
requires all communication to be encrypted. Then, when a terminal tries to
authenticate to a new sector, an attacker can make qualified guess as to the new
nonce, and from that some of the keystream information taken from the sector
that is being logged in to (even though the attacker has not logged in yet).
Research has shown that some Mifare Classic solutions actually use a default key
for one or more of the sectors on the card 8 . There are eight different default keys,
and it is relatively easy to check every sector with all of the keys. If any sector
on the card uses a default key, the attacker can use the nested authentication
attack to recover the rest of the keys.
However, if no sectors use standard keys it is possible to recover the key by
means of an attack described in a paper by Courtois, called “The Dark Side
of Security by Obscurity (. . . )”[1]. This attack works when an attacker replies
with a bad response to initial challenge, and only if the parity bits of the bad
response are set correctly. Instead of replying with four bytes signifying that
the data was wrong (even though the parity is right), it replies with four bits,
specifically the value 0x5 XOR’ed with four bits of the keystream. This opens
some opportunities for recovering more of the keystream. The attack is described
in full in [1].
9.
8 http://proidea.maszyna.pl/CONFidence09/2/CONFidence2009_pavol_luptak.pdf, slide

1.3 Grades of security 13
Common to the “Darkside” and nested authentication attacks is that they need
only a Mifare card and a NFC-compatible reader. The readers are readily available
online, currently priced at 30 e 9 .
These attacks combined can recover all sector keys and dump a card in minutes
on a laptop with a off-the-shelf NFC reader, even shorter time if the attacker
has access to a “ProxMark” reader 10 , currently costing $330. There are numerous
software projects that implement these attacks and provide read-write
functionality for Mifare cards, among others libnfc 11 , mfcuk 12 , crapto1 13 and
RFID IO tools 14 .
1.3.2 MAC
All of the security-critical sectors on Rejsekortet carry a checksum value calculated
with the CBC-MAC algorithm using DES[6], to which the key is secret.
This is to ensure that people do not modify the data in case they recovered the
Mifare keys.
The sectors carrying MACs must have the last 24 bits comprised of a “MAC
algorithm identifier,” a “MAC key identifier” as well as a 16-bit MAC (page 58,
[6] 15 ). The key identifier exists so that Rejsekort A/S can issue a new key if the
old one has been compromised (in turn enabling an attacker to calculate the
current MAC for some data stream), and likewise the algorithm can be changed
if the current algorithm is deemed too weak.
Moreover the sectors carry a field containing the ID of the key used to calculate
the hash so that RKF can issue a new key in case one is broken.
The non-critical sections have a CRC checksum instead of a MAC.
9 http://www.touchatag.com/e-store
10 http://proxmark3.com/
11 http://www.libnfc.org/
12 http://code.google.com/p/mfcuk/
13 http://code.google.com/p/crapto1/
14 http://www.rfidiot.org/
15 The specification allows MACs longer than 16 bits, but in practice only 16-bit MACs are
used[5].

14 On Rejsekortet
1.3.2.1 CBC-MAC
CBC-MAC is a block cipher mode of operation that allows the creation of Message
Authentication Codes (MACs). MACs can be compared to hash functions,
but the difference lies in the fact that there exists a secret key for MACs, preventing
those without it from calculating them.
The MAC function takes a 64-bit secret key and an input of arbitrary length and
chops it into blocks of 64 bits, padding with zeroes if the input length is not a
multiple of 16. For each block the DES cipher function is run with the supplied
key, resulting in a 64-bit value. This value is XORed to the next plaintext block,
and in turn fed into DES, see Figure 1.4. This continues until there are no more
blocks, and leads to “feedback” entire stream for changes in just one bit in one
of the plaintexts. The result of the last DES function is the 64-but MAC value.
This algorithm is described in FIPS 113 as the Data Authentication Algorithm,
but it is also known as DES-MAC.
p 1
p 2
p n
k DES k DES k DES
MAC
Figure 1.4: CBC-MAC with DES as its cipher. There can be any number of
plaintext blocks.
1.3.2.2 Added security of a MAC
Adding a MAC to the system makes it nontrivial to change the contents of a
field, if the Mifare keys would be known. Then, to change the keys one would also
have to recover the key for the DES-MAC which has a keyspace of cardinality
2 56 (even though the keys are 64 bits long—the last 8 bits are used for parity).
The MAC is likely introduced because it would be catastrophic to have the
Mifare keys for Rejsekortet leaked without any further security mechanisms.
Since all Rejsekort use the same Mifare keys, being able to add money and
tickets “just like that” would be highly undesirable.

1.4 Problem definition 15
As an addition to the MAC infrastructure RKF introduces a field describing
which key is used for the MAC, stored as an index. This means that if a key for
the DES-MAC is leaked or broken RKF would just generate a new key, seed it to
the terminals and increment the “key ID” field. Brute-forcing DES is currently
costly and time-consuming, so unless this time window can be brought down
the trouble of brute-forcing DES to recover a key is too high compared to the
temporary gain of being able to forge data; It will only last until a new key is
issued.
1.3.3 Nightly database sanity checking
Checking that all events (check-ins, check-outs, top-ups, etc) “evens out” every
night has been claimed to be the eventual fallback of the security system of
Rejsekortet. This security precaution granted makes Rejsekortet as a whole
more secure, but as opposed to the two previously described security measures
this one is reactive, whereas the others are proactive, i.e. this system reacts
to threats after a security hole has been exploited. The data sent back to the
system is likely the IDs described in 1.2.3.4. Especially the card transaction
number can be used to check if a user has rolled back to an older state of the
card, because then it would appear twice in the database.
It can be argued that this kind of security is just another system “patched” on
top of a weak base system; it does not really fix whatever flaws might exist in
Rejsekortet, but acts more as a check-up that these flaws are not exploited.
1.4 Problem definition
• Can a user cheat the ticketing system to travel for free
– Will such attacks be easily carried out
– Will such attacks be detectable
– What are the legal implications of exploiting the ticketing system
– What are the economic implications for the maintainers of the system
• Is it possible to construct a scheme of large-scale fraud
– Is this economically or technically viable
• Can the system be considered secure against electronic vandalism

16 On Rejsekortet

Chapter 2
Security analysis and threat
model
This chapter describes various attacks applicable to Rejsekortet, along with the
prerequisites to these attacks, as well as the possible countermeasures taken by
the maintainers.
Guarding against every possible flaw in a system like Rejsekortet can prove to
be very costly both in terms of money and time. Therefore we need to establish
a threat model in order to be able to determine whether the flaw is either too
insignificant or too difficult to pull off to actually take precautions against.
2.1 Threat model
As previously stated Rejsekortet is secured by means of Mifare encryption, DES-
MAC authentication and a nightly database consistency check. Rejsekort A/S
has not disclosed what is checked during the database checkups, but we can
assume that it at least checks for double transactions, maybe even keeps a
“purse” object internally in the system. It would resemble the purses on all
Rejsekort in order to ensure that the users has paid for all the tickets that are
used (checked) throughout the lifetime of the cards.

18 Security analysis and threat model
The threats that the maintainers care about the most are the ones that are
difficult to check in that database checks. If a hacker finds out a way to have
the checking terminals accept a Rejsekort but report either invalid or no data to
the back office, then the system is in trouble. This can potentially lead to the
company losing a lot of money, which is why such an attack is called damaging.
It is possible to construct a two-dimensional coordinate system ranging from
“hard” to “easy to pull off” on one axis and “little” to “much damage” on the
other, see Figure 2.1. Generally speaking the most dangerous attacks are the
ones that are both easy to pull off and very dangerous.
Very damaging
Hard to pull off
Easy to pull off
Not very damaging
Figure 2.1: A 2D coordinate system describing the parameters that are significant
to RKF, as well as a marked area describing the “significance threshold.”
Since the coordinate system cannot have any units on the axes it is difficult to
place any attacks in there. It just exemplifies that, theoretically, very damaging
attacks are not necessarily very hard to pull off.
In addition, since Rejsekortet is a system that is made in accordance with the
RKF standard, it is very likely that some security flaw that might exist in
Rejsekortet would also work in the Swedish “Resekortet” system.

2.2 Attack classes 19
2.2 Attack classes
There are four basic kinds of attacks that can be applied to Rejsekortet, each
representing four different ways of approaching defrauding of the system. They
are as follows:
• Rollback attacks in which the attacker loads back an older state of the
card. This kind of attacks need not much more than the possession of a
card reader to be carried out.
• Attacking the MAC allows forging of valid data to make the system
think it issued it itself. This leads to the attacker being able to add
money, tickets, discount rates, etc. to his/her card. A successful MAC
attack would require the recovery of the key for the DES-MAC used, which
has a complexity of 2 56 .
• Masquerading attacks in which an adversary impersonates another (legitimate)
user of the system.
• Attacks on the infrastructure. These attacks will not be described
in much detail, only possible attack vectors will be set forward. It is
impossible to know how the system works without physical access to the
innards, therefore this kinds of attacks will remain speculative until more
details about the hardware is known.
Another thing that has to be taken into consideration is vandalism. Even though
this kind of attacks does not offer anything to the attacker, it must still be taken
seriously—one cannot leave out the possibility of people deliberately trying to
disrupt the system for fun.
2.3 Analysis of the security
As written in 1.3 Rejsekortet has three lines of defense. The first one is the
use of Mifare Classic itself; the user is not supposed to be reading or writing
to his/her card at all! However, as described in 1.3.1.1 some attacks on Mifare
makes it possible to do just that, making the Rejsekort security depend solely
on the DES-MAC and database sanity checks.
This section will describe some remarks—both positive and negative—to the
security system described in the available documents.

20 Security analysis and threat model
2.3.1 Card integrity
One thing to note is that security is not only about keeping hackers from cheating,
it is also about keeping the card in a consistent state.
Securing against cards getting corrupt is done very effectively; as was required
all transactions are indivisible, and in case of disturbances in the terminal/carddialogue.
As was learned in the previous chapter, if the connection is lost at
any point, subsequent transactions will always be able to (re)establish a working
state of the card.
2.3.2 Mifare keys
As stated in the first chapter it is difficult to defend against attacks on Mifare
with attacks in the public domain that are capable of dumping a card in minutes.
However, RKF has done what it could securing the Mifare card by not using
standard keys for any of the sectors. This was determined by experiment using
the mfoc 1 program, testing all sectors on the card with the default Mifare keys.
See section A.1 for the complete output of the experiment.
2.3.3 MAC
Securing the data by means of a MAC is obviously a good idea if the maintainers
of the system want to keep control over what is written to the card.
One could ask why RKF chose to implement MACs instead of just encrypting
the contents, or using cryptographic signing. The answer to the former might
be that it would be convenient to be able to read the contents without having
to decrypt it. Digital signatures are likely not implemented because they need
to be stored in full to be checkable, which is not the case with MACs. Reducing
the length of the MAC just means it is more likely to collide.
In any case, using DES as a security mechanism in 2010 is a bad idea. However,
since the documents used date back to 2002 it is not completely sure that DES-
MAC is still the MAC cipher used. Using a reader it was possible to establish
that either the bit ordering on the cards has changed, or the system implements
a new MAC-algorithm, which can only be considered a welcome improvement.
See section 4.1.1 for more information on this update.
1 http://www.proxmark.org/forum/topic/381/mifare-classic-offline-cracker/

2.3 Analysis of the security 21
2.3.4 Database sanity checks
Other than the different IDs the system gathers, it is difficult to say what is
being sent to the back-office. It is, however, certain that rollback attacks are
detectable, by looking at page 52 in [6].
Sanity checks account for most of the security of Rejsekortet; if the MAC proves
to be secure, then there will still be rollback attacks, and if the MAC is broken
there will just be more to crosscheck. Threat assessments on a case-to-case basis
will be introduced in the next chapter.
2.3.5 Anonymous travel cards
The introduction of completely anonymous travel cards may prove to be somewhat
risky on the maintainers of the system. This means there is little to no risk
in cheating with those. They will likely be disabled after next database sanity
check, but then the attacker can just buy a new card and continue cheating.
2.3.6 Vandalism
Vandalism is largely ignored in Rejsekortet. It is possible to gain write access
to cards in their touchless nature, and this makes them easy to corrupt or wipe,
if the attacker knows the Mifare keys for the cards.
However, with NFC cards like Mifare, the distance between card and reader has
to be very short, under 10 cm. This makes it virtually impossible to “pickpocket”
or in other ways read or write a card without being noticed. It will still be
possible to set up “rogue terminals” on stations and such, to get people to
unknowingly let their cards corrupt.
Because of the proximity needed to write to the cards, the vandalism attacks described
in the next chapter can be considered speculative and not really suitable
for any real-world scenario. As such the system can be considered more or less
resistant to vandalism; the “walking through the train and wiping everything”
example is impossible, not because of a precaution taken by RKF, but because
of physical constraints. Israeli researchers have tried to extend the range of Mifare
reading; they successfully read/wrote a Mifare card at a 25 cm distance 2 .
However, 25 centimeters is still not enough to carry out most vandalism attacks.
2 http://www.eng.tau.ac.il/~yash/kw-usenix06/index.html

22 Security analysis and threat model
2.3.7 Layered approach
Rejsekortet’s security model is based on a layered approach, i.e. several different
security mechanisms on top of each other comprising the overall security of
Rejsekortet. This is a very clever choice if the system is expected to run for an
extended period; there will always be an interest in proving or disproving the
security of systems, especially those contributing to some kind of infrastructure
like the public transit system, and RKF did the right thing opting for a layered
security model.

Chapter 3
Attacks on Rejsekortet
As described in the previous chapter attacks on Rejsekortet can be divided into
four different categories of cheating the system, plus vandalism. Vandalism is
important to bring into the picture because personal gain might not be the only
motivation to perform an attack; if it is possible to make “digital graffiti,” or just
cause a general disruption of the system, some people might still be interested.
Especially if it introduces plausible deniability (“I couldn’t check-in because all
the terminals were broken”).
The other attacks can be assumed to be motivated by the outlook to free travel.
We can divide these attacks into two different kinds:
• Attacks that enable free travel for just the attacker’s card. These attacks
are the rollback and masquerading attacks. As we shall see in section 3.3,
the latter is at this point impossible due to a technical constraint.
• Attacks that are focused on the core security system. If such an attack
is carried out, the overall security of Rejsekortet is decreased. Such an
attack is described in 3.2.

24 Attacks on Rejsekortet
3.1 Rollback attacks
Rollbacks are a class of attacks that all depend on restoring an older state of the
card. This kind of attack is usually very easy to carry out and does not require
much technical know-how, only a card reader and some free software. If this
method would turn out to be effective it can only be assumed that somebody
will write some user-friendly software assisting in this attack.
3.1.1 The trivial rollback
This is the most basic of Rejsekortet attacks. It is carried out as follows:
1. Attacker recovers the Mifare keys for the card and saves the current card
state to his/her hard drive.
2. Attacker uses the public transit system as he/she pleases.
3. Attacker re-installs the saved version to the card.
The card will then be in the same state as it was when it was loaded.
The reason why this works is that the designers of the system wanted a very
rich card state, possibly because they did not want terminals to be online,
communicating with the back-office every time the card is used. To guard
against users tampering with the data on the card, they have implemented a
MAC so that changing the fields is difficult.
In this case, however, the data comes from RKF itself so the attacker can be
certain that the MAC is correct.
3.1.2 Modifying TCAS structure on the card
As part of the card’s indivisibility requirement the RKF-0022 standard implements
the TCAS field, as described in section 1.2.3.4. This field contains information
on the sectors, more specifically a value called SectorStatus. Modifying
this value leads to the system thinking the old value of the field is current.
This attack is unfortunately not possible to carry out without being able to
calculate the correct MAC for the new value of the TCAS field.

3.1 Rollback attacks 25
3.1.3 Countermeasures
Guarding proactively against this attack within the confines of the current system
1 is actually very difficult, despite the very simple nature of the attack. It
is certain that RKF knows about this flaw and does nothing about it because
it is either too expensive to change or a product of a design choice done early
in the development of the system (page 52, [6]. The problem is that the whole
travel card system is based around trusting the state of the card, and to guard
against this it would take a centralized system to verify each transaction when
it is conducted, defeating the purpose of having a “rich” card in the first place.
This problem was highlighted by Christian Panton in a January DR1 newscast 2 .
In response RKF sent out a press release stating that the system is in fact secure
because they conduct nightly checks of the transaction database 3 . This makes
the system resistant to rollbacks, because then it is possible to check that e.g.
transaction IDs appear twice, or that some user has simply traveled for more
money than had been added on top-up terminals.
It is important to note that while this probably will prevent this kind of attacks
from happening, it does not make them impossible; the travel card system has
not been fixed, but another system preventing this attack has been put in place.
3.1.4 Threat assessment
As stated these kinds of attacks are not likely to be taken very seriously. Largescale
exploitation is not likely to happen because this attack needs to be conducted
by the user of the card, and because the economic gain is negligible, as is
the economic loss to the maintainers. Moreover, the database checking system
will likely detect transaction IDs (and, in turn, the Rejsekort ID) appearing
twice, making the attack risky to try.
The legal implications of conducting this attack may very well be serious. It
can be argued that illicit use of Rejsekortet constitutes falsification of documents,
which is punishable by Danish law, with penalties up to two years of
imprisonment in non-serious cases 4 .
1 I.e. the terminals are allowed to be offline, so checking against a central server is not a
possibility.
2 http://forsinkelsen.dk/indslag-i-tv-avisen
3 http://www.rejsekort.dk/Presse/Pressemeddelelser/kundens+penge+er+altid+sikre
4 http://da.wikipedia.org/wiki/Dokumentfalsk

26 Attacks on Rejsekortet
3.2 Attacking the MAC
Rejsekortet introduces a MAC algorithm on most sectors in order to ensure no
one tampers with the contents of the card. The algorithm used is DES-MAC
in CBC mode, which takes a 64-bit key, of which 8 bits are used for parity—
consequently leaving the key complexity at 56 bits—and an input of any length.
Using the key it “hashes” the input to a 64-bit MAC, which is then further
stripped down to only consist of the first 16 bits of the 64-bit value. This new
16-bit value is used as a checksum for the given sector.
p 1
p 2
p n
k DES k DES k DES
MAC
Figure 3.1: The Rejsekort DES-MAC function. This figure is identical to Figure
1.4.
An attacker can implement a hashtable mapping the entire keyspace to the keys’
corresponding MACs for some fixed plaintext. In the trivial case this is known
as a code book. It will be costly in both CPU time and space, but if constructed
an attacker can look up a key from the table in O(1) time. A code book for the
DES-MAC on Rejsekortet would need to have 2 56 entries, each consisting of a
56-bit key and a 16-bit MAC:
2 56 · (56 + 16) bits = 576 petabytes
It is concluded that a code book spanning over the entire DES keyspace is
currently impossible to implement because of the sheer amount of space needed
to keep the table.

3.2 Attacking the MAC 27
3.2.1 Time-memory trade-offs
Time-memory trade-offs (TMTOs) are a class of precomputation attacks that
can be applyed to all one-way functions, that is functions taking any input and
producing an output that is computationally hard to source back to its preimage.
For a one-way function H and the result of the function c, the preimage is the
p that satisfies H(p) = c for some c. One-way functions are not designed to be
reversible, and as such hash functions and MACs pose as good candidates for
this kind of attack.
This thesis will decribe two time-memory trade-offs, namely Hellman tables as
described in the 1980 paper “A Cryptanalytic Time-Memory Trade-Off”[4] by
Hellman, and the 2003 paper “Making A Faster Cryptanalytic Time-Memory
Trade-Off”[9] by Oechslin.
3.2.1.1 Hellman tables
In a 1980 paper by Martin Hellman[4], a new “time-memory trade-off” is proposed.
The way it works is that it implements a reduction function R that
maps hash values back into the plaintext space. This facilitates the generation
of chains with alternating preimages and hash values. To further refine the
method, the one-way function is combined with the reduction function into a
new function f in order to get a mapping from the space of preimages to itself.
For some one-way function H, f can be described as f(p) = R(H(p)). f is also
known as the step function of the table.
The trick is then to only save the first and last values in the chain, discarding
all the intermediate steps. The table consists of some amount of chains m, all
starting with some random preimage and ending with a value equivalent derived
by performing the plaintext-to-plaintext function f over and over, always feeding
it with the output from the last iteration, see Figure 3.2.
d2654f → f 732efc → f 143679 → f 84e5dc → f f
} {{
. . . → 0006f3
}
d2654f→0006f3
Figure 3.2: A Hellman chain and how it is stored.
elements are in storage.
Only the first and last
For practicality reasons attacks employ more than just one table; having one table
cover a large keyspace will result in a very large file, which is time-consuming

28 Attacks on Rejsekortet
and cumbersome to search in. Having more than one table also makes it easier
to distribute the calculations needed to mount the attack properly.
Hellman tables are prone to a very serious flaw, however. A property of hash
functions is that they are collision resistant, however this does not hold for
reduction functions, meaning they can give the same reduction value for two
different hashes. If two hash chains in the table have the same value at any
point, the two chains will merge, see Figure 3.3. This will result in two chains
more likely than not cover much of the same area of the plaintext space.
rejsekort H f74eed6e R ewaisnshw H 491b2cb4 R irundian
movia H 93f03506 R ewaisnshw H 491b2cb4 R irundian
Figure 3.3: Two hash chains merging. For the sake of clarity the one-way
function and reduction functions have different boxes in this figure. The colliding
parts are highlighted in red.
To make up for this, Ronald Rivest proposed in 1982 that chains in Hellman
tables end in a distinguished point. There could be many definitions for the
point, but they have to have some property not happening too often, for example
the first n bits of the value of the ending point be zero, like on 3.2. This is
done to reduce the probability of chains merging; if two chains end in the same
distinguished point, they will have merged for some period of the chain length.
Either of the chains will be thrown out, and a new chain will be calculated in
its stead.
Not only can Hellman tables merge, they can also create a cycle. This happens
when a reduction function reduces a hash to a value already in the same chain.
This leads to the chain cycling and never reaching a distinguished point. To
detect this one could look at how long the chains would be on average, and
determine if the current chain is too far from this average to be realistic. The
chains tend to get so long that it would be unfeasible to keep them in memory
while they are being calculated to accurately determine if there is a cycle.
Therefore one must rely on the length of the chain to determine the likelihood
of it containing a cycle.
To search for some hash value h in a Hellman table with distinguished points,
one first reduces h with the reduction function: h′ = R(h). If h′ constitutes
a distinguished point, the table is checked for any chains ending with h′. If
such a chain exists, it is rebuilt and the preimage for h is found to be the value
immediately preceding h in the chain. If the reduced h is not a distinguished

3.2 Attacking the MAC 29
point, then the f function is run over and over again on h′ so as to build a chain
“on top of” h′. If at any point the function outputs a distinguished point, it
is checked in the same manner as before. However, if there is no match once a
distinguished point has been found, h can be guaranteed not to be in the table.
This is because the deterministic properties of the f; if some distinguished point
is reached after h, one can be sure that for past reconstructions of the chain
that, indeed, the chain would end in the same distinguished point.
rejsekort H f74eed6e R ewaisnshw H 491b2cb4 R bveiytoo
(continued)
H 3b7b7c75 R ewaisnshw H 491b2cb4 R bveiytoo
Figure 3.4: A cycle in a Hellman chain. The two hash values that produce the
same reduction are highlighted in red.
Finally, Hellman tables have the undesired property of causing false alarms.
This phenomenon is a corollary of Helman tables’ inherent misfeature of merging.
It can be explained by a chain in the table merging with the temporary
chain that is being constructed when a hash value is tried. The two chains will
have the same end value, but the stored chain will not contain the sought hash.
Therefore one cannot be sure that a preimage can be recovered before the chain
is rebuilt, unless the R(h) is a distinguished point. Applying any number of f
operations to R(h) might lead to merges with some chain in the Hellman table
before the preimage, leading to a false alarm.
3.2.1.2 Rainbow tables
In 2003 Philippe Oechslin presented a new approach for these time-memory
trade-offs that did away with some of the problems of the older algorithm [9]; he
narrowed down the undesired probabilities to the reduction function—Hellman
tables uses the same function for all reductions, and this causes collisions, resulting
in chains merging and cycling. Oechslin proposed a new kind of tables,
namely rainbow tables.
Rainbow tables work like the older TMTO in the sense that they facilitate
reverse lookups in hashes and other one-way functions, but they use different
reduction functions for every column in the table, resulting in merges only if
two plaintexts are the same and appear at the exact same element index of two
chains. For long chains the proability of this happening is minuscle.
To look up values in a rainbow table the attacker would take the reduce the

30 Attacks on Rejsekortet
hash value to which the preimage is sought, reduce it with the t − 1 th reduction
function R t−1 for chain length t, and look through all chain endings to see
if there is a match. If there is a match, the entire chain is generated from the
beginning. If there is no match, then R t−2 is applied to the hash value, and then
f t−1 . This will yield anoter value. If that value matches one of the endpoints in
the rainbow table(s), then the chain in question is rebuilt. If there is no match,
then R t−3 is applied, then f t−2 , then f t−1 , etc. If at any point f 0 is called, the
sought-after value is not in the rainbow table(s).
3.2.2 How the MAC is calculated
The following is known about the input to the DES-MAC function, quoted from
RKF-0022.
1. All bytes of a block contribute to the checksum calculation with the exception
of the checksum byte itself. Even possible padding zeroes between
the last proper data element and the checksum byte contribute to the
checksum.
2. The data to be authenticated, i.e. input to the MAC algorithm, always
include the CardSerialNumber of CMI: Manufacturer Information. As the
CardSerialNumber is unchangeable, this will prevent system objects or
application objects to be copied from one travel card to another, without
being detected. (Unquote.)
From this we can deduce the input for the DES-MAC function as being the
card’s serial number concatenated with the contents of the object to be MAC’d,
including any possibly unused bits, padded with zeroes to fit a multiple of the
DES block size.
The data is then MAC’ed as described in Section 1.3.2.1. The output from
the DES-MAC function is 64 bits, which is then reduced to using only the first
16 bits of the original MAC (quote RKF-0022: “the output is truncated to the
specified size as the most significant bits of the 64 b output of the algorithm.”).
The reduced MAC of 16 bits is then stored on the card, and may be verified in
subsequent transactions by calculating the MAC anew and comparing the result
with the stored value. If the values match, then the MAC is accepted.

3.2 Attacking the MAC 31
n bits (arbitrary length) 64 bits 16 bits
Plaintext
DES-MAC
cut
MAC
64 bits (8 used for parity)
Key
Figure 3.5: The reduction of MACs. The DES-MAC function is explained in
section 1.3.2.
3.2.3 Criteria to be met for a successful implementation
of a TMTO
To be successful with a time-memory trade-off, the attacker needs to always be
able to control the contents of a data structure in order to restore the state to
some expected content. These conditions must be met:
• There must exist a user-changeable or never-changing data field on the
card.
– If the field is user-changeable it must be so by means of the Rejsekort
terminals or in other ways unsuspicious. Moreover the fields changed
must be controllable so that the data can be restored to some previous
state from which the TMTO was prepared.
– If the field is never-changing we furthermore demand that RKF updates
the hash even though the data is unchanged.
• This field has to have a MAC.
• The DES key for the MACs of all fields should be the same throughout
the card.
The attack is weaker for the never-changing fields, because then it depends on
RKF actually updating the hash even though the data has not been changed,
instead of just letting the old MAC be, with proper reference to the old key.

32 Attacks on Rejsekortet
3.2.4 Interesting property of shortened MACs
Rejsekortet implements a MAC system that reduces the length of the original
MACs to 16 bits from the original 64 bits of the DES-MAC standard. This
increases the risk of having collisions, both key-based and plaintext-based 5 , but
it also makes the implementation more resistant against time/memory-tradeoffs.
The shortening of MACs on the card makes it nontrivial to look them up in a
rainbow table. MACs stored on Rejsekortet are usually 16 bits long[5], taken as
the first 16 bits of the original 64-bit hash[6]. This means that if the plaintext
is fixed two keys will still give different hashes, but their 16-bit reductions can
not be guaranteed different, see Figure 3.6.
k 0
FE:85:3D:20:1B:A8
DES-MAC
09:F9:11:02:9D:74:E3:5B
cut
09:F9
Collision
38:D9:3A:F7:B2:AC
DES-MAC
09:F9:D8:41:56:C5:63:56
cut
09:F9
k 0
Figure 3.6: Two different plaintexts having different 64-bit MACs, but after
being reduced colliding. The inputs to the DES-MAC function are of arbitrary
length, and is only shown here as six bytes as an example.
This entails that a code book needs only 2 16 rows, with all of them linking to
a list of key prospects that need to be cross-tested on some other data that is
MAC’ed with the same key. Note that this will in no way optimize the size
complexity of the code book, nor will the search time for a key be any better.
In fact, quite the opposite; since each reduced MAC can come from 2 40 different
keys acting on the same plaintext, more plaintext will likely be needed to weed
out the false positives.
3.2.4.1 Accommodating this limitation by introducing more tables/cards
It is, however, possible to adapt one’s attack to this kind of security. Knowing
that some sector S 0 is MAC’d with the same key k on all cards gives the attacker
the opportunity to create a table for another card. Given n MACs and n lookup
5 Two different keys for the same plaintext giving one MAC, and one key for two different
plaintexts giving one MAC, respectively.

3.2 Attacking the MAC 33
Card 1 Card 2 Card 3 Card 4
2 56 MAC batch 2 40 MAC batch 2 24 MAC batch 2 8 MAC batch 1
Figure 3.7: Description of usage of the “MAC batch” function that takes a piece
of data with a valid MAC and calculates MACs for all the key candidates from
the list it receives. The numbers on the arrows are the expected cardinality of
the keyset given to the batch function.
tables for the corresponding MACs it is possible to take the intersection the n
tables to “weed out” all the key prospects that do not appear in all the lists.
Generally, the more space and CPU time the attacker can afford, the more
effective this improvement is.
It is possible to make some statistical analysis as to how much an increase in
rainbow tables would affect calculation time, but in general one table should be
enough; starting with a keyspace of 2 56 and reducing that to about 2 56−16 =
2 40 to be brute-forced, it will take 1.2 days for a modern computer 6 for the
intersection set, see 3.2.7.1. If the intersection is ambiguous the remaining
intersection sets can be done in seconds.
We can define a function taking some list of keys and using this list to calculate
the reduced MACs for a given data element. This data element should already
have a MAC that is issued by the system. If the reduced MAC matches the
one already in the data element, it means that the current key is a candidate,
and the key is saved in a buffer of key candidates. This buffer is then given
as input to the same function acting on another card’s data. This way the key
candidates can be weeded out effectively. This model is shown on Figure 3.7.
3.2.4.2 Accomodating this limitation by obtaining more chosen plaintext
from the same card
It is also possible to obtain more chosen plaintext by simply changing the value
of some fields on the card and record the MACs of these individual samples. If
one can find a sector that can mutate to four or more different controlled states,
then it is possible to have 4 · 16 = 64 bits of independent MAC data for some
key. This is convenient, as we shall see in section 3.2.7.
6 In this case, a Lenovo laptop with an Intel Core 2 Duo processor at 2.26GHz, using one
CPU thread.

34 Attacks on Rejsekortet
3.2.5 Applying a time-memory trade-off to Rejsekortet
To construct a rainbow table one needs a one-way function f i that maps some
{0, 1} n → {0, 1} n space, in order to create the rainbow chains of which the table
consists. In this case n = 56 because we would like to search for a 56-bit key.
This f could for example be a DES-MAC function taking a key of 56 bits, plus
a reduction function reducing the 64-bit output to a 56-bit one, in order to have
the output in the same space as the input.
Since the MACs are only 16 bits long they are not usable as hash candidates,
unless we define our plaintext as being four different chosen plaintexts and our
hash as the hashes of the four plaintexts concatenated, as described in 3.2.4.2.
For a key k and the Rejsekortet DES-MAC function (with 16 bits output) H
we have
c k = H(p 1 , k)||H(p 2 , k)||H(p 3 , k)||H(p 4 , k)
. . . for four different plaintexts p 1 , p 2 , p 3 , p 4 . The four different plaintexts could
be different mutations of the same field or just chosen plaintexts from different
sources from the same card, given all these are MAC’ed with the same key. c k
now has 64 bits of entropy since we can expect the output from all of the H
operations to be 16 bits, and mutually independent, even though k is constant.
We can then discard 8 bits from c k in order to get a value in the {0, 1} 56 space.
A f i for Rejsekortet could then take the 56-bit key as input, use that for the k
values in c k , and then reduce the output to 56 bits by cutting the last 8 bits away
from the 64-bit value. Finally, to have the function differ between columns, it
could be XOR’ed with the column’s number.
Using the table counts, chain counts and chain lengths proposed in [9] we know
that for a 56-bit keyspace we need to store of 2 2 3 ·56 = 2 37.33 entries for a table
balanced equally in terms of size and lookup complexity. Each entry would
consist of 2 · 56 bits, leading to a total size for the rainbow table(s)
2 37.33 · (2 · 56) bits = 2.20 terabytes
Hard drives with two terabytes of storage cost, at the time of writing, about
1000 Danish kroner, so the space requirement is easily accommodated.

3.2 Attacking the MAC 35
3.2.6 Candidate data structures for a TMTO
Using RKF-0025[5] as a reference document for the bit layout of the card it was
established that there are two MAC’d data structures in Rejsekortet with either
fixed or chosen plaintext. One is in the card information section, and the other
in the customer profile section. These constitute good candidates because the
attacker can “mold” them to his/her will, allowing a precomputation attack,
because it is always possible to reset the state of the data structure to some
expected value.
3.2.6.1 Time/memory-tradeoff in the TCCI
The TCCI (Travel Card Card Information) is the second block on the card. It
holds the following information[5]:
• Card version.
• Card issuer.
• Expiry date.
• Which currency unit the purse holds.
• A MAC.
• Some fields with constant values, per the specification.
All of this information is not likely to change throughout the lifetime of a card
and thus makes for a good “entry point” for a time-memory trade-off. However,
as described above the attack is not without conditions and resistant to
countermeasures; in fact it is rather fragile.
A condition for the continued efficiency of the flaw is that immutable fields have
their MAC recalculated each time a new key is issued, otherwise the attacker
will gain no more MACs to work with. It can be assumed that the system does
this, because otherwise attackers would be able to calculate correct MACs for
data with an old (known) key.

36 Attacks on Rejsekortet
3.2.6.2 Time/memory-tradeoff in the TCCP
The TCCP (Travel Card Customer Profile) is another good candidate for a precomputation
attack. TCCP’s advantace over the TCCI is that its mutable fields
are user-controllable, abusing the inherent feature of MACs that the plaintext
is likely choosable. The precise contents of the section can be looked up in [5],
but listed here are the user-mutable fields:
• The passenger class
• Preferred language
• Dialogue preferences
The other fields are other fields relating to the user, such as his/her birthday, etc.
Conducting a pre-computation attack from the TCCP is likely more effective
than the one described for the TCCI, because the user has complete control
over the state of the sector. This entails that an attacker will be able to force a
recalculation of the MAC, which can then be looked up in the table.
3.2.7 A practical time-memory trade-off against Rejsekortet
As stated in 3.2.4.2 it is possible to get 64 bits of independent MAC data for
some key if some field can be controlled into four different mutations. As was
just established, the TCCP constitutes such a field. The preferred language
can be expected to have at least two different values, Danish and English, and
so does the passenger class, business class and economic class. This gives four
different states that all have different MACs for some key, see table 3.1. The
16-bit MACs can be concatenated to form a 64-bit MAC. However, the key
length for DES is 56, so the new 64-bit MAC can be shortened to 56 bits, giving
a {0, 1} 56 → {0, 1} 56 mapping.
It is now possible to construct a rainbow table mapping DES keys to this new 56-
bit MAC. As described in section 3.2.5 this rainbow table will have the expected
size of 2.2 TB if it is optimized equally for space efficiency and on-line key
recovery time efficiency. However, values can be adjusted as the attacker sees
fit. The step function f i for the ith column in the rainbow table is defined as
shown in Figure 3.8.

3.2 Attacking the MAC 37
in
f i
64b
c 1 c 2 c 3 c 4
MAC
MAC
MAC
MAC
64b
cut
cut
cut
cut
16b
concatenation
64b
cut
56b
⊕ i
out
Figure 3.8: The step function f i for the ith column of the rainbow table. The
top to the concatenation function is the MAC-function, and the cut and XOR
functions comprise the reduction function.

38 Attacks on Rejsekortet
Language Class MAC bits
Danish Economic 16 bits
Danish First 16 bits
English Economic 16 bits
English First 16 bits
64 bits
Table 3.1: The four different combinations of chosen plaintext in the TCCP
field.
Now, to recover a key k from the rainbow table, the attacker must recreate the
four combinations of chosen plaintext described in Table 3.1, note their MACs,
concatenate and short the 64-bit value to 56-bits and use that value as searching
operand in the rainbow table, as described in section 3.2.1.2.
This attack enables key recovery from the Rejsekort DES-MAC in feasible time,
in turn allowing a determined attacker to forge money or tickets onto Rejsekort.
Keep in mind that these rainbow tables will work for just one card, but also
that the DES keys are the same for all cards. If an attacker creates a rainbow
table over the DES-MAC function in his Rejsekort, he will be able to recover
the DES keys for all Rejsekort.
3.2.7.1 Estimates of the time complexity in constructing a rainbow
table
To construct a table comprising the entire DES keyspace, it would take 2 56 DES
runs to have the space exhausted. This needs to be done four times because
there are four different plaintexts that need to be concatenated to form one
56-bit value for use in the rainbow table. That is
2 56 · 4 = 2 58 calculations
Using the DES implementation available from www.darkside.com.au/bitslice/,
it was possible to get the following speed test output on a standard Lenovo laptop
from 2008:
Searched 27119864.5 keys per second
Dividing 2 58 with that number gives an expected calculation time of almost 337
years on a current laptop. However, the code could run much faster on an array

3.2 Attacking the MAC 39
of GPUs or FPGAs, or even as a distributed computing project, given it had
more than one thousand participants.
3.2.7.2 Coverage of rainbow tables
By using the same table counts, chains-in-table counts and chain lengths it is
possible to reuse the calculations done in [9] with regards to table coverage.
Oechslin constructed Hellman tables and rainbow tables of equal cardinality
and tested 500 random passwords against the tables. These were his findings.
Hellman tables Rainbow tables
predicted coverage 75.5% 77.5%
measured coverage 75.8% 78.8%
Table 3.2: Coverage statistics of Hellman tables vs. rainbow tables.
As can be seen rainbow tables have a slightly better coverage than tables using
distinguished points. However, since rainbow tables do not incur false alarms
nearly as often as Hellman tables, the cryptanalysis time for a password is
drastically reduced in the favor of rainbow tables.
3.2.7.3 Field experiments
A field study was conducted to determine if this attack is viable. At the terminal
at Høje Taastrup station it was attempted to modify the TCCP in the ways
described in Section 3.2.7. Between the transitions the card was dumped, and
the TCCP state picked out. The results can be seen on Figure 3.9.
A: A2 02 F4 05 E0 3D 03 00 20 ... 00 00 00 00 00 00 00 00 ... 40 ... 66 E0
B: A2 02 F4 05 E0 3D 03 00 10 ... 01 DD 59 41 77 36 1F 8C ... 40 ... 60 39
C: A2 02 F4 05 E0 3D 03 00 10 ... 01 DD 59 41 77 36 1F 8C ... 40 ... 60 39
D: A2 02 F4 05 E0 3D 03 00 20 ... 01 DD 59 41 77 36 1F 84 ... 40 ... 45 AB
E: A2 02 F4 05 E0 3D 03 00 20 ... 01 DD 59 41 77 36 1F 84 ... 40 ... 45 AB
Figure 3.9: Five dumps of the TCCP data structure. The last two bytes are
the 16-bit MAC values. A: The card as it was before the experiment. B: The
passenger class is set to first class. C: The language is set to English. D: The
passenger class is set to economic. E: The language is set back to Danish.
NB: Subsequent 0x00 bytes are replaced with “. . . ”

40 Attacks on Rejsekortet
It is noted that changing the passenger class has an immediate effect on the
contents of the field, whereas changing the language does not! This is in conflict
with the version of RKF-0022/0025 available. Moreover the card seems to be
“initialized” with the first change in the TCCP (much of the data structure were
zeroes before changing it), but this needs to be verified further. It can neither
be proven or disproven that it is possible to establish an older state of the card.
Changing the language actually did lead to a change in the card, albeit in
another part than expected. The TCCP is a special data structure called AT4 7
which, as opposed to other data structures on the card, does not have the
same kind of indivisibility enforcing as the other fields, and this does not need
redundancy. Maybe because this field can be restored to a default value in case
of a transmission error, maybe because the field can only be altered when the
card is in the machine, not in the hand of a user that might leave prematurely.
A: A2 02 F4 05 E0 3D 03 00 20 ... 01 DD 72 2B FC C5 37 5F 78 77 88 00 F1 D8 3F 96 43 14
B: A2 02 F4 05 E0 3D 03 00 20 ... 01 DD 72 2B FC C5 37 5F 78 77 88 00 F1 D8 3F 96 43 14
C: A2 02 F4 05 E0 3D 03 00 10 ... 01 DD 72 2B FC C5 37 5F 78 77 88 00 F1 D8 3F 96 43 14
D: A2 02 F4 05 E0 3D 03 00 10 ... 01 DD 72 2B FC C5 37 5F 78 77 88 00 F1 D8 3F 96 43 14
E: A2 02 F4 05 E0 3D 03 00 20 ... 01 DD 72 2B FC C5 37 5F 78 77 88 00 F1 D8 3F 96 43 14
Figure 3.10: The same exhibits as in Figure 3.9, but elsewhere on the card.
Byte number 9 changes with the language.
It is important to note that the MAC did not change with the language as it did
with the passenger class, despite the data having changed. This means either
that the new MAC was not calculated, or that it collides in this special case. In
any case it is interesting.
It is concluded that the attack as described will not work, partly because the
data storage model has been changed, partly because the field test did not yield
enough data for anyone to give a precise analysis of the possibilities of restoring
an older state. If it is possible to get back to an older state of the structure,
then it is still vulnerable to this attack. Also, if an attacker can find another
controllable data structure, then it can be used in conjunction with this to
mount the attack as described, but with the new data structure states instead.
3.2.8 Threat assessment
Forging attacks can be very dangerous because they can be centralized. If a
determined attacker has the hardware and know-how to construct a rainbow
7 Application Type 4

3.3 Masquerading attacks 41
table of the MAC algorithm, then by knowing all cards use the same keys for
the MAC it is possible to forge money and tickets for every Rejsekort.
If this attack proves effective there is presumably a large market if some entity
can offer Rejsekort money at half price, etc. This has the potential to have very
large economic consequences for Rejsekortet, unless the system is well-equipped
to withstand such an attack, by means of a reactive security measure like with
rollback attacks.
As with rollback attacks this attack is likely detectable to RKF, without knowing
exactly what is being sent to the back-office. One thing that complicates this,
however, is that the attacker can change any data on the card, so if some
validation is not done properly, the attacker might be able to take advantage of
this.
3.3 Masquerading attacks
Masquerading is an attack type involving the attacker digitally posing as somebody
else, often a legitimate user of the system. With the recent attacks on Mifare
cards it has become an ever-larger risk of having one’s card compromised.
The attacks can in theory be performed in seconds with the right equipment,
and the offended part will never notice.
The problem is, though, that these attacks are very hard to carry out in real
life, due to technical constraints both related to the reading and the writing of
the Mifare cards.
3.3.1 The trivial masquerading attack
This attack involves using Mifare vulnerabilities to dump a card and loading it
onto another. There is a tool for this task in libnfc, called nfc-mftool, that
allows reading and writing to Mifare cards, given the proper sector keys. These
can be recovered with the Mifare attacks described in the first chapter.
3.3.1.1 Mifare reading distance
As described in the first chapter, Mifare cards use a technique called Near
Field Communication to facilitate the contact between terminal and card. The

42 Attacks on Rejsekortet
specification of the standard is described in ISO/IEC 14443.
Using a regular reader from http://www.touchatag.com/ the maximum reading
distance was determined to be 7-8 centimetres. This experiment was conducted
by running the program nfc-list in a loop, slowly moving a Mifare
card further and further away from the reader. When the card was out of reach,
it was moved towards the reader again, to accurately determine the maximum
reading distance of Mifare cards.
3.3.1.2 Unique IDs on cards
Mifare cards are shipped from the manufacturer with the first block of the first
sector burned into the card, rendering it immutable. This field contains an
ID number unique to the card among some other manufacturer-specific data.
Rejsekortet uses this ID to distinguish different cards from one another, and
since it is immutable it is not possible to write to the card, it is not possible
to load a dumped version of another card. The ID will not be overwritten, and
consequently all the MACs will not match anymore, since part of their basis is
this ID.
3.3.1.3 Pirate cards
The possibility of someone developing a pirate card for Mifare is considerable.
There is no physical restraints in place to hinder creating a card that allows
writing to the first block of the first sector. The security of genuine Mifare
Classic cards lies in a clever design choice from NXP, that is not to allow writing
to the manufacturer block.
If a pirate card existed, it would be possible to create a one-to-one copy of a Mifare
card, which is problematic not only for Rejsekortet but for all deployments
of Mifare. NXP can be expected to take such experiments very seriously, and
will likely do everything in its power to stop the production of such cards.
3.3.1.4 Having a reader act as a card
Most NFC readers available also offer the functionality of emulating a Mifare
Classic card. This enables an attacker to check in and check out as if the reader
was an actual Mifare card. The problem arises when a conductor wants to

3.4 Attacks on the infrastructure 43
verify the card; since the attacker cannot present a real Rejsekort, this way of
circumventing the “manufacturer area” becomes largely unusable.
3.3.1.5 Threat assessment
Since this attack is not practically possible to carry out, it can be ignored—at
least until pirate cards exist in the wild without NXP interfering.
3.3.2 A vandalistic masquerading attack
Using the a NFC reader as a card opens up some possibilities of masquerading
in a vandalistic way. Suppose an attacker recovers a full dump of a Rejsekort
and uses his card reader to make the illegally copied Rejsekort “follow” him
somewhere. This makes the system think the legitimate Rejsekort is a rolledback
version of itself, and in turn disable it to the annoyance of the owner.
3.3.2.1 Threat assessment
An inherent feature of vandalism attacks is to cause as much disruption as
possible, and only targeting one user of Rejsekortet will likely be too small for
this attack to be interesting in the eyes of a vandal.
3.4 Attacks on the infrastructure
As stated in the last chapter this section will be speculative only, but it presents
some vectors that could be exploited in order to gain something from the system
normally restricted, and some conventional methods on exploitation likely not
applicable to this system.
3.4.1 Attacking the controlling and/or check-in terminals
Some attacks might apply to the terminals. If they can be compromised to
accept a card that should not be accepted, the adversary has mounted an effective
attack against the system. This section will present some techniques that

44 Attacks on Rejsekortet
might prove effective, and should be taken into consideration when securing the
terminals.
3.4.1.1 Fuzzing
Fuzzing is about sending garbage data to a system that expects some degree
of order in its data inputs. This may in some cases cause systems to crash or
otherwise work in unexpected ways. If the attacker is lucky it could for example
be possible to have the checking terminal seemingly accept a card without the
data contents actually being valid.
To be successful with a fuzzing attack the attacker must have physical access to
a checking terminal—preferably not on a station—in order to carry out preliminary
experiments. Experimenting with fuzzing has an inherent component of
“working blindly”—there is no “Fuzzing black book,” one just has to try feeding
bad data to the system. Obtaining the terminal will likely prove to be tricky,
as the transit organizations presumably don’t want their systems compromised,
and therefore show little interest in aiding this.
However, if an attacker gets hold of such a terminal, he would systematically
write either garbage or in other ways non-conforming data to the card, hoping
the terminal would act in an unexpected manner. If it does (and it is checkable)
then the attacker has conducted a successful fuzzing attack on a Rejsekort terminal.
This could for example be the checking terminals accepting a card with
badly formatted data.
Fuzzing attacks at Rejsekortet would probably need to be cleverly applied. From
the specifications the system looks rather robust against inconsistency, with the
introduction of TCAS, etc. The way to go about fuzzing would probably be to
follow the data structures as closely as possible but have pointers to some data
element point elsewhere than expected. This in turn requires the attacker to be
able to calculate the correct MAC for a given data stream.
3.4.1.2 Software-based buffer overflows
Buffer overflow exploitation is typically about exhausting the allocated memory
for some resource without the actual value ending. This can happen with strings
because if the terminating character ‘\0’ is not within the boundaries of the size
of the variable, there’s nothing to stop the variable from “growing out of its
space”. This causes it to overwrite other variables, but probably more worrying

3.5 Vandalism 45
it can overwrite the call stack, resulting in controllable CPU behavior on an
assembly level.
Buffer overflows will likely not work because the data structures on the card
have a fixed length and a special binary format. The readers will always know
exactly how much data to read and how much memory to allocate, with no need
of waiting for a terminal character. This makes buffer overflowing ill-fit as an
attack vector for Rejsekortet’s system, but is included here for completeness.
3.4.2 Attacking the top-up terminals
Depending on the underlying computer systems of the top-up terminals it might
be possible to perform a hacking attack that sends data to the back-office about
the card being topped up, enabling the user to travel for money “officially”
issued by the system, but without having the amount drawn from the given
credit card.
3.4.3 Threat assessment
All of these threats are probably too hard to pull off for the “average Joe”
wanting to travel for free. They either require special knowledge, access to
official equipment and/or quite some courage to pull off.
3.5 Vandalism
As stated in the last chapter, vandalism attacks must be taken seriously even
though they generally are not motivated by the outlook to personal gain. Some
people like to cause mischief not even demanding attribution for it.
As we shall see, in some cases vandalism introduces plausible deniability, which
raises some questions about liability in Rejsekortet system.
3.5.1 Card-based vandalism
With the recent Mifare attacks allowing card contents to be modified, cardbased
vandalism is a very real possibility. If we even take into consideration

46 Attacks on Rejsekortet
that the Mifare keys is shared across all Rejsekort, performing these attacks is
only needed once to be able to dump the card in seconds.
On Figure 3.11 the time consumption for dumping a card is shown. It will
take roughly the same time to write the same amount data to a card. The
dumping was done with a reader from http://www.touchatag.com/ and with
the open-sourced NFC library libnfc.
$ time nfc-mftool r a keys.mfd dump.mfd
Checking arguments and settings
Succesful opened MIFARE the required files
Connected to NFC reader: ACR122U102 - PN532 v1.4 (0x07)
Found MIFARE Classic 4K card with uid: [redacted]
Reading out 256 blocks |........................................|
Writing data to file: dump.mfd
Done, all bytes dumped to file!
real 0m3.871s
user 0m0.010s
sys 0m0.060s
Figure 3.11: Terminal output of a Mifare 4K card being dumped with
nfc-mftool. The card is dumped in less than four seconds.x
With a NFC reader it is possible to corrupt people’s cards without their consent.
However, since NFC communication requires very low distance from card to
reader, it might be difficult to pull off undetected. See Section 3.3.1.1 for an
experiment in the range of Mifare.
3.5.1.1 Rogue terminals
In theory it is possible to construct a terminal-resembling device, putting it
on stations, and either harvesting card dumps or wiping cards as unknowing
commuters “check-in.” However the effort needed to mount this attack will be
tremendous, especially in comparison to the gain.

3.5 Vandalism 47
3.5.2 Terminal-based vandalism
A successful terminal-based vandalism attack would depend on rendering the
terminal in a state of (seemingly-)irrecoverable non-functioning. For example, if
one could modify a card to make the terminal stuck in an infinite loop and glue
that card to the backside of the terminal, the terminal would be temporarily
disabled.
However, this is not possible; there are no pointers on the card that make it
possible to e.g. have it point to itself. The card is not possible to branch the
execution flow of the terminal in any undesirable direction.
3.5.2.1 Plausible deniability
If future research yields flaws in the terminals, it will introduce plausible deniability,
which gives statements like “I couldn’t check in my card because the
terminal was defective” some additional credibility, and pushes the liability of
the user not having checked in as required back to Rejsekort A/S.
3.5.3 Threat assessment
Vandalism can be considered relatively harmless in the case of Rejsekortet. Since
the reading distance is so low, it is not realistic to e.g. walk through a bus or
a train and wipe all cards as you pass by. Neither is terminal-based vandalism
possible currently, but depending on how easily possible future attacks are carried
out, the maintainers should be wary of this, and have a strategy against
plausible deniability.

48 Attacks on Rejsekortet

Chapter 4
Improvements
This chapter will propose some general improvements to the system that will
increase security.
The available documentation on the system describes an older version, therefore
not all of the information applies anymore. Some information is gathered in two
field tests conducted in June 2010.
4.1 Improvements since version 1 and 2
As previously stated this thesis is concerned with versions 1 and 2 of Rejsekortet.
Using a card provided by Rejsekort A/S it was possible to extract new
information without the specifications, simply by using the card as described
and dumping it whenever its state is changed.
Disclaimer: The information stated may not be precise if RKF has changed
the bit ordering of the fields, and should not be taken as fact without further
investigation.

50 Improvements
4.1.1 New MAC algorithm
It seems that the MAC algorithm has been changed from DES-MAC to something
else. The specifications define a MACAlgorithmIdentifier that, if set to 1,
represents DES-MAC as the algorithm used. This value has since been changed
to 3 which may indicate that the card uses a stronger MAC. The attack still
works in theory, but depending on the key size of the new cipher/hash algorithm
the attack slides further and further into the realm of infeasibility, because of
the sheer size of the new rainbow table, and because higher key complexities
need more chosen plaintext, which is scarce.
The system definitely still uses a MAC algorithm, that is a cryptographic block
cipher with some key size k > 56 in some MAC mode. There are two likely candidates
for the a replacement cipher-based MAC function, namely 3DES and
AES. These algorithms are “industry standard,” and another (secure) implementation
would be either expensive or time-consuming to have developed, or
both.
4.1.1.1 3DES
3DES, pronounced triple-DES, is a reinforcement maneuver applied to the DES
cryptosystem after it was proven too weak in the late nineties. Its weakness was
not the actual encryption algorithm, but the key size—a fact which is also used
in this thesis as an attack on the MAC system. The key size of DES is 64 bits,
but eight of the bits are reserved for parity (in case the transmission of the key
is disturbed).
3DES consists of three successive runs of the DES algorithm, first an encryption
run, then decryption, then encryption again—note that a decryption run can
work as encryption, also succeeding an encryption, as long as they use two different
keys. This structure needs three keys, and offers different keying options
for these with varying security[10].
• All keys K 1 , K 2 , K 3 are independent. This gives a key complexity of 3·56 =
168 bits, and is considered secure, also by current standards.
• K 3 equals K 1 . This gives an increased key complexity of 2 · 56 = 112 bits.
• K 3 = K 2 = K 1 . This is no more secure than single DES, in fact they are
equivalent because E K1 (D K1 (E K1 (m))) = E K1 (m) for encryption function
E and decryption function D.

4.1 Improvements since version 1 and 2 51
For the new implementation Rejsekort A/S would probably choose the first
keying option, if their choice fell on 3DES for the new MAC algorithm. Whatever
containers they used for keys prior to this (suggested) update, they would
need to make them bigger anyway, so not going “all the way” (in terms of key
complexity) seems very unlikely.
4.1.1.2 AES
AES is a more recent symmetric cryptosystem, based on an algorithm called
Rijndael. NIST 1 hosted a competition for the new data encryption standard
in the US. The competition was won by Rijmen and Daeman, and their cipher
Rijndael was finally FIPS approved in 2001.
The AES cipher offers three three different key sizes, namely 128, 192 and 256
bits, and depending on the key size runs in a number of iterative rounds, all
performing the same three functions designed to substitute and shuffle the cipher
state as much as possible, and finally adding a round key. This makes for a very
robust cipher
It is difficult to give estimates on which key size that would be chosen if Rejsekortet
were to use AES as the new hash function, but they would most likely
not pick 256 bits, since a new 2009 attack made it theoretically inferior in terms
of key complexity to AES-128.
A equally-weighed 2 rainbow table over the AES-MAC would use:
(2 · 128) · 2 2 3 ·128 bits = 2 93.3 bits = 1290 yottabytes
The byte scale goes: byte, kilobyte, megabyte, gigabyte, terabyte, petabyte,
exabyte, zettabyte, yottabyte. Current hard drives range of about 2TB; storing
this much data is currently impossible, let alone doing 2 93 calculations to recover
a key!
4.1.1.3 Hash-based MACs
Hash-based MACs use a cryptographic hash function instead of a cipher to
perform the hashing operation. The probable advantages of this is that hash
1 National Institute of Standards and Technology.
2 Equally in terms of space complexity and search complexity.

52 Improvements
functions tend to be very fast and very compact in software, leading to a faster
overall calculation of the MAC value.
The new MAC function may also be based on a hash function. It is at this point
impossible to look at a MAC and tell if it was a product of a cipher-based or a
hash-based MAC algorithm, so the possibility is included here for completeness.
4.1.1.4 Remarks
As previously stated the bit ordering of the fields on the card might have
changed, leading to parsing errors if parsed in accordance with the old standard
[6]. Therefore the MAC might actually not have changed at all. It was
impossible to test if the algorithm was changed because that would require creating
a rainbow table for the DES-MAC to recover the key, and in turn verifying
it against other Rejsekort.
However, we can note the following: 3DES is the fastest of these solutions,
at least when run on hardware. So if the MAC algorithm is in fact changed,
CBC-MAC with 3DES would be the most sensible choice.
4.2 Other immediately applicable improvements
Again, by comparing two historically different dumps of a card it is possible to
establish if other security enhancements have been implemented or not.
4.2.1 Sector-specific keys for the MAC
The proposed time-memory trade-off relies largely on the same key being used
across sectors. If sectors get their own keys one would need a rainbow table for
every sectors to recover the sector-specific key for his/her card. To create such
a table the attacker would also need enough controlled plaintext.
4.2.2 Adding noise bits
Many sectors have free bits that are not used. These are by definition set to
zero[6]. If these were randomized at each write and used in the MAC calculation

4.3 Other improvements 53
they would work as a salt, making known-plaintext attacks impossible because
the plaintext could never be known.
4.2.3 Using Mifare Plus instead of Mifare Classic
The Mifare system is not limited to only using Mifare Classic cards. There
exists a variety of cards, some with increased security. Mifare Plus 3 can act
as a drop-in replacement of Mifare Classic cards, but instead of encrypting the
sectors with Crypto-1 it implements AES, which is much more secure.
This improvement is considered immediately applicable because Rejsekortet at
the time of writing has only been issued to some 1,000 people 4 —rolling it out
to these 1,000 people and using it as the standard onwards would be straightforward.
4.3 Other improvements
It is possible to suggest some improvements that would be too fundamental to
fit into the current system.
4.3.1 Having a centralized system
All of the weaknesses described in this paper would be useless with a centralized
system. An important thing to note is, however, that such a system is very
expensive because every single terminal that interfaces with it needs to be online
or the system fails. This is likely the reason for it not being online in the first
place.
3 http://www.mifare.net/products/smartcardics/mifare_plus.asp
4 http://rejsekort.dk/Presse/Pressemeddelelser/rejsekort+paa+sydsjaelland+og+
lolland-falster: “I dag bruger mere end 1.000 kunder i den kollektive trafik allerede
rejsekort i området mellem Holbæk, Roskilde og Taastrup. . . ”

54 Improvements

Chapter 5
Conclusion
This thesis has been concerned with analyzing the security of the current implementation
of Rejsekortet. This has been a rather daunting task, considering
the fact that the newest specifications documentation has not been available,
leading to somewhat indefinite part conclusions throughout the report.
Various attack classes have been studied, namely rollback attacks, cryptographic
attacks on the MAC, masquerading attacks and infrastructure attacks. The
latter has been on speculations-only basis because it requires breaking the law
to get useful data. The first three, however, have been described, and it has
been established that:
1. Rollback attacks are possible, but also detectable. Since rollback attacks
are not very robust, they are not expected to induce a large economic hit
to the maintainers.
2. Attacking the MAC may be possible. It is not known if forging attacks
are detectable.
3. Masquerading attacks are not possible until a MIFARE pirate card exists
that allows mutability of the first block of the first sector.
The reason why it is not possible to give a clear answer as to the applicability

56 Conclusion
of the pre-computation attack is that from card dumps it seems that the MAC
algorithm has been changed, and that the plaintext control attempts were futile
because the card was in a default state (which was not reproducible). Moreover
it seemed that the language of the terminals was stored somewhere else on
the card, so the attack requires a new controllable data type with at least two
mutations. Conducting the experiment again will provide results usable for a
general security assessment.
Whether or not the MAC algorithm is changed is impossible to know at this
point. But two candidates for a more modern cipher for the MAC to use were
presented: AES and 3DES. They both present much higher key complexity
than DES, and are at this point considered practically impossible to traverse
key-wise.
If the attack on the MAC turns out to be possible, and the back-office detection
is insufficient in detecting e.g. attackers adding money to cards, it could
have catastrophic consequences. With good rainbow tables for Rejsekortet it is
possible to establish a parallel entity that can add money and tickets to cards,
because the key for the MAC function is the same across all cards. Being able
to recover this key in manageable time makes it possible to establish a business
selling under-priced Rejsekort credit, which is of course highly undesirable.
Vandalism has also been analyzed, with the conclusion that is poses no large
risk unless the attacker is very close. A vandalistic attacker is interested in
maximizing the impact of the attack, and corrupting just one card at a time is
simply too time-consuming. It is concluded that the system is robust against
vandalism.
Outlook – where to go from here
As stated, conducting the plaintext control experiment again would yield some
interesting data. The question boils down to this: Is the current MAC value of
the TCCP field preserved if the passenger class is switched to first class, then
back to business class again Will it be possible to find another suitable data
type in place for the dialog language
It would also be interesting to know if the MAC algorithm has been changed
since the available documentation was released. If this is the case it would
theoretically still be possible to mount the attack, but it would be practically
impossible to do in any foreseeable future because of the key complexities involved.

Appendix
A
Related research
A.1 Mifare keys
The following output from the mfoc program shows that Rejsekortet uses nondefault
keys in all its sectors. This enhances security somewhat.
$ ./mfoc -O rejsekort-test
Found MIFARE Classic 4K card with uid: [redacted]
[Key: ffffffffffff] -> [........................................]
[Key: a0a1a2a3a4a5] -> [........................................]
[Key: b0b1b2b3b4b5] -> [........................................]
[Key: 000000000000] -> [........................................]
[Key: 4d3a99c351dd] -> [........................................]
[Key: 1a982c7e459a] -> [........................................]
[Key: d3f7d3f7d3f7] -> [........................................]
[Key: aabbccddeeff] -> [........................................]
Sector 00 - UNKNOWN_KEY [A] Sector 00 - UNKNOWN_KEY [B]
Sector 01 - UNKNOWN_KEY [A] Sector 01 - UNKNOWN_KEY [B]
Sector 02 - UNKNOWN_KEY [A] Sector 02 - UNKNOWN_KEY [B]
Sector 03 - UNKNOWN_KEY [A] Sector 03 - UNKNOWN_KEY [B]

58 Related research
Sector 04 - UNKNOWN_KEY [A] Sector 04 - UNKNOWN_KEY [B]
Sector 05 - UNKNOWN_KEY [A] Sector 05 - UNKNOWN_KEY [B]
Sector 06 - UNKNOWN_KEY [A] Sector 06 - UNKNOWN_KEY [B]
Sector 07 - UNKNOWN_KEY [A] Sector 07 - UNKNOWN_KEY [B]
Sector 08 - UNKNOWN_KEY [A] Sector 08 - UNKNOWN_KEY [B]
Sector 09 - UNKNOWN_KEY [A] Sector 09 - UNKNOWN_KEY [B]
Sector 10 - UNKNOWN_KEY [A] Sector 10 - UNKNOWN_KEY [B]
Sector 11 - UNKNOWN_KEY [A] Sector 11 - UNKNOWN_KEY [B]
Sector 12 - UNKNOWN_KEY [A] Sector 12 - UNKNOWN_KEY [B]
Sector 13 - UNKNOWN_KEY [A] Sector 13 - UNKNOWN_KEY [B]
Sector 14 - UNKNOWN_KEY [A] Sector 14 - UNKNOWN_KEY [B]
Sector 15 - UNKNOWN_KEY [A] Sector 15 - UNKNOWN_KEY [B]
Sector 16 - UNKNOWN_KEY [A] Sector 16 - UNKNOWN_KEY [B]
Sector 17 - UNKNOWN_KEY [A] Sector 17 - UNKNOWN_KEY [B]
Sector 18 - UNKNOWN_KEY [A] Sector 18 - UNKNOWN_KEY [B]
Sector 19 - UNKNOWN_KEY [A] Sector 19 - UNKNOWN_KEY [B]
Sector 20 - UNKNOWN_KEY [A] Sector 20 - UNKNOWN_KEY [B]
Sector 21 - UNKNOWN_KEY [A] Sector 21 - UNKNOWN_KEY [B]
Sector 22 - UNKNOWN_KEY [A] Sector 22 - UNKNOWN_KEY [B]
Sector 23 - UNKNOWN_KEY [A] Sector 23 - UNKNOWN_KEY [B]
Sector 24 - UNKNOWN_KEY [A] Sector 24 - UNKNOWN_KEY [B]
Sector 25 - UNKNOWN_KEY [A] Sector 25 - UNKNOWN_KEY [B]
Sector 26 - UNKNOWN_KEY [A] Sector 26 - UNKNOWN_KEY [B]
Sector 27 - UNKNOWN_KEY [A] Sector 27 - UNKNOWN_KEY [B]
Sector 28 - UNKNOWN_KEY [A] Sector 28 - UNKNOWN_KEY [B]
Sector 29 - UNKNOWN_KEY [A] Sector 29 - UNKNOWN_KEY [B]
Sector 30 - UNKNOWN_KEY [A] Sector 30 - UNKNOWN_KEY [B]
Sector 31 - UNKNOWN_KEY [A] Sector 31 - UNKNOWN_KEY [B]
Sector 32 - UNKNOWN_KEY [A] Sector 32 - UNKNOWN_KEY [B]
Sector 33 - UNKNOWN_KEY [A] Sector 33 - UNKNOWN_KEY [B]
Sector 34 - UNKNOWN_KEY [A] Sector 34 - UNKNOWN_KEY [B]
Sector 35 - UNKNOWN_KEY [A] Sector 35 - UNKNOWN_KEY [B]
Sector 36 - UNKNOWN_KEY [A] Sector 36 - UNKNOWN_KEY [B]
Sector 37 - UNKNOWN_KEY [A] Sector 37 - UNKNOWN_KEY [B]
Sector 38 - UNKNOWN_KEY [A] Sector 38 - UNKNOWN_KEY [B]
Sector 39 - UNKNOWN_KEY [A] Sector 39 - UNKNOWN_KEY [B]
No sector encrypted with the default key has been found, exiting..
However, by applying the Darkside attack with mfcuk keyrecovery darkside
and supplying this new key to mfoc, all the sector keys are dumped in about
three minutes.

Appendix
B
Mail correspondence
The correspondance is ordered chronologically.
B.1 Mail correspondance with Margareta Berg
from Resekort Sweden
Date: Wed, 17 Feb 2010 16:29:49 +0100
Subject: Technical specifications of Resekortet.
From: Jens Christian Hillerup
To: margareta.berg@resekortet.se
Cc: Erik Zenner
Dear Margareta,
I’m currently working on my bachelor’s thesis on Resekortet,
concerning the security of digital ticketing for public transportation
systems. Currently I have parts of version 1 (volym A) and parts of
version 2 (volym B) -- both were once freely available online.
The documentation I already have is rather old, so I’m writing to

60 Mail correspondence
enquire about a more recent version. Do you need any information from
me in this regard
Kindest regards,
Jens Christian Hillerup
CC: Erik Zenner, my bachelor counsellor.
* * *
Date: Wed, 17 Feb 2010 14:00:50 -0800
Subject: SV: Technical specifications of Resekortet.
From: Margareta Berg
To: Jens Christian Hillerup
Dear Jens,
Due to the hack of Mifare Classic the specification is not public anymore.
Since 3 years ago we have a strictly license of agreement with the PTA’s
in Sweden and Rejsekort.
Maybe you can contact Gregers Mogensen at Rejsekort and working together
with them in that case you take your bachelor’s in Denmark.
Kindly regards
Margareta
B.2 Mail correspondance with Gregers Mogensen
from Rejsekort Danmark
Date: Tue, 23 Feb 2010 09:56:10 +0100
Subject: Ang. tekniske specifikationer på Rejsekortet
From: Jens Christian Hillerup
To: gem@rejsekort.dk
Cc: Erik Zenner
Kære Gregers Mogensen,
Jeg er ved at skrive min bacheloropgave fra Danmarks Tekniske
Universitet, hvor jeg skal forsøge at undersøge sikkerheden i

B.2 Mail correspondance with Gregers Mogensen from Rejsekort Danmark61
Rejsekort og sikkerhedsmæssige aspekter i digital billettering
generelt. Derfor er jeg interesseret i at se de tekniske
specifikationer der ligger til grund.
Jeg skrev oprindeligt til Margareta Berg, fordi det var min opfattelse
at det var en svensk gruppe, der oprindeligt lavede specifikationerne,
og fordi de havde et link på deres hjemmeside specifikt til tekniske
specifikationer, men hun ledte mig til dig. Som jeg også skrev til
hende har jeg allerede adgang til dele af version 1 og 2 af standarden
(som engang var frit tilgængelige på internettet), men det skulle
undre mig hvis de er de mest tidssvarende. Min korrespondance med
Margareta Berg er vedhæftet.
Det er vigtigt for mig at understrege, at dette ikke er et forsøg på
at "ødelægge" Rejsekortet, men snarere et godhjertet forsøg på at
belyse de problematikker der blev rejst i medierne medio januar og se
om de holder vand.
På forhånd tak,
Jens Christian Hillerup
CC: Min bachelorvejleder Erik Zenner.
* * *
From: Gregers Mogensen
To: Jens Christian Hillerup
CC: Erik Zenner
Date: Tue, 23 Feb 2010 14:22:42 +0100
Subject: SV: Ang. tekniske specifikationer på Rejsekortet
Kære Jens Christian Hillerup
Tak for din mail. Jeg vil gerne hjælpe dig, hvor det er muligt, men der er
en grund til, at vi ikke mere har specifikationerne liggende offentligt
tilgængeligt.
Jeg vil gerne tager et møde med dig og evt. din vejleder, hvor vi kan
drøfte hvad jeg i givet kan bidrage med.
De to punkter, som jeg umiddelbart vil spørge til, om du har med er:

62 Mail correspondence
* Kodningsprincipper for andre rejsekort
* De forretningsmæssige konsekvenser af begrænset sikkerhed
Vi kan holde møde her, eller jeg kan komme forbi DTU en morgen eller sen
eftermiddag, da jeg bor i Holte.
Med venlig hilsen/Regards
Gregers Mogensen
REJSEKORT A/S
Borgergade 14, 3.
DK-1300 København K
Telefon: +45 3343 2400
Direkte: +45 3343 2406
Mobil: +45 4030 7979
E-mail: gem@rejsekort.dk (Please note new e-mail address)
Web: www.rejsekort.dk
* * *
Date: Wed, 24 Feb 2010 13:26:11 +0100
Subject: Re: Ang. tekniske specifikationer på Rejsekortet
From: Jens Christian Hillerup
To: Gregers Mogensen
Cc: Erik Zenner
Kære Gregers,
Tak for din imødekommenhed. Det betyder meget for mig.
Jeg har studeret andre rejsekort, fx Oystercard, og har konkluderet at
de stort set allesammen også benytter Mifare. Det lader til at
Rejsekortet er sikrere end fx Oystercard, givet dets brug af DES-MAC,
som jeg har kunnet læse fra de tidlige implementeringsdokumenter jeg
har adgang til (RKF-0020 og RKF-0022, respektivt).
De forretningsmæssige konsekvenser er ikke noget, jeg umiddelbart
havde tænkt mig at berøre særlig dybt. Dermed ikke sagt, at det ikke
er en faktor i real-world-scenarier for implementeringen af et
sikkerhedssystem, men jeg er nu engang teknisk studerende, og det er

B.2 Mail correspondance with Gregers Mogensen from Rejsekort Danmark63
en forventning at min bacheloropgave tager sig mestendels af de
tekniske aspekter af hvad jeg nu engang har valgt som emne. De
forretningsmæssige aspekter vil naturligvis få sin plads i rapporten
-- dog ikke som en hovedprioritet, ligesom privatlivs- og sociologiske
betragtninger kommer i rapporten, men ikke er vægtede.
Jeg er helt klart åben for et møde, og det er jeg sikker på at Erik
(min vejleder) også er. Dog vil jeg gerne lidt dybere ind i systemets
fundamentale virkemåde før det giver mening at have et, hvilket også
var grunden til at jeg bad om de tekniske specifikationer i første
omgang. Efter min mening er det svært at sandsynliggøre at et system
er sikkert, hvis specifikationerne og implementeringsdetaljerne ikke
er offentligt tilgængelige.
Mvh.
Jens Christian
* * *
From: Gregers Mogensen
To: Jens Christian Hillerup
CC: Erik Zenner
Date: Wed, 24 Feb 2010 13:56:54 +0100
Subject: SV: Ang. tekniske specifikationer på Rejsekortet
Kære Jens Christian
Sig til, når du (I) er klar til et møde, og gerne et par uger før. Jeg er
på ferie i uge 11.
Ad dit udsagn:
Efter min mening er det svært at sandsynliggøre at et system
er sikkert, hvis specifikationerne og implementeringsdetaljerne ikke
er offentligt tilgængelige.
Så er jeg helt uenig. Det kan være, at det er svært for dig og andre
"uvedkommende", men de personer, der har brug for denne viden, har den
selvfølgelig, men det er i sagens natur et meget lille antal. Og de skilter
ikke med den fortrolige viden de har.
M.h.t til det forretningsmæssige aspekt, så er sikkerhed jo ikke en
absolut størrelse. Der er i alle livets forhold en implicit eller eksplicit
afvejning af, hvornår noget er sikkert nok.

64 Mail correspondence
Som ingeniør - og tidligere lektor på DTU - mener jeg, at det netop er
ingeniørens styrke at kunne vurdere teknologien i forhold til om verdenen,
og ikke bare teknologien for dens egen skyld.
Med venlig hilsen/Regards
Gregers Mogensen
REJSEKORT A/S
Borgergade 14, 3.
DK-1300 København K
Telefon: +45 3343 2400
Direkte: +45 3343 2406
Mobil: +45 4030 7979
E-mail: gem@rejsekort.dk (Please note new e-mail address)
Web: www.rejsekort.dk

Bibliography
[1] Nicolas T. Courtois. The dark side of security by obscurity and cloning mifare
classic rail and building passes anywhere, anytime. Cryptology ePrint
Archive, Report 2009/137, 2009. http://eprint.iacr.org/.
[2] Flavio D. Garcia, Gerhard Koning Gans, Ruben Muijrers, Peter Rossum,
Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs. Dismantling mifare
classic. In ESORICS ’08: Proceedings of the 13th European Symposium on
Research in Computer Security, pages 97–114, Berlin, Heidelberg, 2008.
Springer-Verlag.
[3] Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers
Schreur. Wirelessly pickpocketing a mifare classic card. In SP ’09: Proceedings
of the 2009 30th IEEE Symposium on Security and Privacy, pages
3–15, Washington, DC, USA, 2009. IEEE Computer Society.
[4] M. Hellman. A cryptanalytic time-memory trade-off. Information Theory,
IEEE Transactions on, 26(4):401 – 406, jul 1980.
[5] Resekortforeningen i Norden. Implementation specification details type 1.
Can be found on the CD enclosed with this thesis.
[6] Resekortforeningen i Norden. Rkf travel card implementation specification
type 1. Can be found on the CD enclosed with this thesis., 2001.
[7] Resekortforeningen i Norden. Rkf travel card requirements specification.
Can be found on the CD enclosed with this thesis., 2001.
[8] Gregers Mogensen. Travel card in denmark, concept and status. 2009.

66 BIBLIOGRAPHY
[9] Philippe Oechslin. Making a faster cryptanalytic time-memory trade-off.
In Advances in Cryptology - CRYPTO 2003, pages 617–630, 2003.
[10] Wikipedia. Triple des — wikipedia, the free encyclopedia, 2010. [Online;
accessed 31-May-2010].