The (in)security of proprietary cryptography

Transcription

The (in)security of
proprietary cryptography
Roel Verdult
c Roel Verdult, 2015
Copyright ISBN: 978-94-6259-622-1
IPA Dissertation Series: 2015-10
URL: http://roel.verdult.xyz/publications/phd_thesis-roel_verdult.pdf
Typeset using LATEX
The work in this dissertation has been carried out under the auspices
of the research school IPA (Institute for Programming research and
Algorithmics). For more information, visit
http://www.win.tue.nl/ipa/
U
x
hx,yi
X ×Z Y
y
X
p
q
f
g
Y
Z
msc Example
User
Machine 1
control
Machine 2
drill
Machine 3
test
startm1
startm2
log
continue
free
output
XY-pic is used for typesetting graphs and diagrams in schematic representations of logical composition of visual components. XY-pic allows
the style of pictures to match well with the exquisite quality of the
surrounding TEX typeset material [RM99]. For more information, visit
http://xy-pic.sourceforge.net/
The message sequence diagrams, charts and protocols in this dissertation are facilitated by the MSC macro package [MB01, BvDKM13]. It
allows LATEX users to easily include Message Sequence Charts in their
texts. For more information, visit
http://satoss.uni.lu/software/mscpackage/
The graphical art of this work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0
Unported License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/3.0/
The remaining part of this work is licensed under a Creative Commons
Attribution-NonCommercial-NoDerivs 3.0 Netherlands License.
To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-nd/3.0/nl/
Proefschrift
ter verkrijging van de graad van doctor
aan de Radboud Universiteit Nijmegen op gezag van
de rector magnificus prof. dr. Th.L.M. Engelen
volgens besluit van het college van decanen
en
ter verkrijging van de graad van doctor in de ingenieurswetenschappen
aan de KU Leuven op gezag van
de rector prof. dr. R. Torfs,
in het openbaar te verdedigen op dinsdag 21 april 2015
om 14:30 uur precies
door
Roel Verdult
geboren op 20 oktober 1982
te Zevenaar, Nederland.
Promotoren:
Prof. dr. Bart Jacobs
Prof. dr. ir. Ingrid Verbauwhede
KU Leuven, België
Copromotoren:
Dr. Lejla Batina
Dr. Claudia Diaz Martinez
KU Leuven, België
Manuscriptcommissie:
Prof. dr. Eric Verheul
Dr. Jaap-Henk Hoepman
Prof. dr. Herbert Bos
Vrije Universiteit Amsterdam, Nederland
ˇ
Prof. dr. Srdjan Capkun
ETH Zurich, Zwitserland
Prof. dr. Thorsten Holz
Ruhr-Universit¨
at Bochum, Duitsland
KU Leuven Examencommissie:
Prof. dr. Wim Dehaene
KU Leuven, België
Prof. dr. Bart Preneel
KU Leuven, België
Prof. dr. Herman Neuckermans
KU Leuven, België
Prof. dr. Gildas Avoine
Université Catholique de Louvain, België
Doctoral Thesis
to obtain the degree of doctor
from Radboud University Nijmegen on the authority of
the rector magnificus prof. dr. Th.L.M. Engelen
according to the decision of the Council of Deans
and
to obtain the degree of doctor of Engineering Science
from KU Leuven on the authority of
the rector prof. dr. R. Torfs,
to be defended in public on Tuesday, 21 April 2015
at exactly 14:30 hours
by
Roel Verdult
born in Zevenaar, Nederland
on 20 October 1982.
Supervisors:
Prof. dr. Bart Jacobs
Prof. dr. ir. Ingrid Verbauwhede
KU Leuven, Belgium
Co-supervisors:
Dr. Lejla Batina
Dr. Claudia Diaz Martinez
KU Leuven, Belgium
Doctoral Thesis Committee:
Prof. dr. Eric Verheul
Dr. Jaap-Henk Hoepman
Prof. dr. Herbert Bos
Vrije Universiteit Amsterdam, The Netherlands
ˇ
Prof. dr. Srdjan Capkun
ETH Zurich, Switzerland
Prof. dr. Thorsten Holz
Ruhr-Universit¨
at Bochum, Germany
KU Leuven Examination Board:
Prof. dr. Wim Dehaene
KU Leuven, Belgium
Prof. dr. Bart Preneel
KU Leuven, Belgium
Prof. dr. Herman Neuckermans
KU Leuven, Belgium
Prof. dr. Gildas Avoine
Université Catholique de Louvain, Belgium
A tribute to my dearest family
Irma, Twan and Sten
Acknowledgements
It has been a great honour to work with my direct colleagues at the Digital Security
group of the Radboud University, who worked with me as co-authors, but most of all,
as best friends. They inspired me to explore the path of science, which enabled me to
write this doctoral dissertation. I am extremely grateful for their guidance, didactics,
insights and support.
I would like to specially thank Flavio Garcia and Gerhard de Koning Gans, who
have been working besides me from day one. Without their feedback and continuous
support, I would not have realized my admiration for science and discovered the
contribution that I have to offer. Furthermore, I’m grateful to my first promotor
Bart Jacobs, who is an excellent example of a dedicated and outstanding scientist
that is concurrently involved in society.
My gratitude goes to all the members of the Radboud University reading committee and KU Leuven examination board, Eric Verheul, Jaap-Henk Hoepman, Wim
Dehaene, Bart Preneel, Herman Neuckermans, Gildas Avoine, Herbert Bos, Srdjan
ˇ
Capkun
and Thorsten Holz, who helped improving this doctoral dissertation a lot
by their valuable and professional comments. Additionally, I would like to thank my
friends and family, and especially my father Ad Verdult, for helping me improving
the language of this thesis.
It was pleasant to work with my second promotor Ingrid Verbauwhede and her
research group at the KU Leuven. Specifically, I would like to thank my direct
colleague from Belgium, Josep Balasch. Besides our scientific collaboration, he also
assisted me numerous times to comply with rules and administrative protocols of the
KU Leuven.
During the security research that I performed with my colleagues, several friendly
and prominent contacts were established. We collaborated extensively with governments, secret services, nation wide police forces and large corporations. However,
despite our efforts to carefully disclose sensitive information in a responsible way,
there were a few unfortunate events where we faced legal pressure that tried to reix
strain us from publishing the details of our work. During such an event we have
always been firmly supported by the legal department and executive board of the
Radboud University. My gratitude goes especially to Bas Kortmann, former rector
magnificus of the Radboud University, and Dorine Gebbink, head of legal affairs.
Although it is impossible to name every person, I would like to show my gratitude
to all the people who supported me in many ways over the last years. During this
period I have acquired a lot of knowledge, skills and experience. I’m very thankful
for that.
Finally, I would like to express my admiration, gratitude and love to my wife and
children. They have always supported me during my research and the long days that
I’ve spent writing of this thesis. I will be forever grateful for their love and care.
Roel Verdult
Oosterbeek, March 2015
Abstract
Proprietary cryptography is a term used to describe custom encryption techniques
that are kept secret by its designers to add additional security. It is questionable if
such an approach increases the cryptographic strength of the underlying mathematical
algorithms. The security of proprietary encryption techniques relies entirely on the
competence of the semi-conductor companies, which keep the technical description
strictly confidential after designing. It is difficult to give a public and independent
security assessment of the cryptography, without having access to the detailed information of the design.
Proprietary cryptography is currently deployed in many products which are used
on a daily basis by the majority of people world-wide. It is embedded in the computational core of many wireless and contactless devices used in access control systems
and vehicle immobilizers.
Contactless access control cards are used in various security systems. Examples
include the use in public transport, payment terminals, office buildings and even in
highly secure facilities such as ministries, banks, nuclear power plants and prisons.
Many of these access control cards are based on proprietary encryption techniques.
Prominent examples are the widely deployed contactless access control systems that
use the MIFARE Classic, iClass and Cryptomemory technology.
A vehicle immobilizer is an electronic device that prevents the engine of the vehicle
from starting when the corresponding transponder is not present. This transponder
is a wireless radio frequency chip which is typically embedded in the plastic casing
of the car key. When the driver tries to start the vehicle, the car authenticates the
transponder before starting the engine, thus preventing hot-wiring. According to
European Commission directive (95/56/EC) it is mandatory that all cars, sold in the
EU from 1995 onwards, are fitted with an electronic immobilizer. In practice, almost
all recently sold cars in Europe are protected by transponders that embed one of the
two proprietary encryption techniques Hitag2 or Megamos Crypto.
In this doctoral thesis well-known techniques are combined with novel methods
xi
to analyze the workings of the previously mentioned proprietary cryptosystems. The
cryptographic strength and security features of each system are comprehensively evaluated. The technical chapters describe various weaknesses and practical cryptanalytic
attacks which can be mounted by an adversary that uses only ordinary and consumer
grade hardware. This emphasizes the seriousness and relevance to the level of protection that is offered. The identified vulnerabilities are often plain design mistakes,
which makes the cryptosystems exploitable since their introduction.
The first part of this dissertation is dedicated to an introduction of the general field
of computer security and cryptography. It includes an extensive description of the
theoretical background that refers to related literature and gives a summary of wellknown cryptographic attack techniques. Additionally, a broad summary of related
scientific research on proprietary cryptography is given. Finally, the technical part of
this doctoral dissertation presents serious weaknesses in widely deployed proprietary
cryptosystems, which are still actively used by billions of consumers in their daily
lives.
Samenvatting (Dutch Summary)
De term propriëtaire cryptografie beschrijft een eigengemaakte en specifiek ontworpen
versleutelingstechniek die vaak geheim gehouden wordt met als doel hierdoor extra
veiligheid te bemachtigen. Het is maar de vraag of een dergelijke aanpak de cryptografische sterkte van de onderliggende wiskundige algoritmes ten goede komt. De
veiligheid van propriëtaire versleutelingstechnieken rust volledig op de competentie
van de semi-conductor bedrijven, die na het ontwerpen de technische omschrijvingen
strikt geheim houden. Het is moeilijk om een publieke en onafhankelijke veiligheidsbeoordeling van de cryptografie te geven, zonder dat er gedetailleerde informatie
beschikbaar is over het ontwerp.
Propriëtaire cryptografie wordt momenteel gebruikt in een groot aantal producten
die dagelijks gebruikt worden door de meerderheid van de wereldbevolking. Het is
ge¨ıntegreerd in de rekenkern van verschillende draadloze en contactloze apparaten die
toegepast worden in bijvoorbeeld toegangscontrolesystemen en startonderbrekers.
Contactloze toegangscontrolekaarten worden gebruikt in diverse beveiligingssystemen. Ze worden bijvoorbeeld gebruikt in het openbaar vervoer, betaalautomaten,
bedrijfsgebouwen en zelfs in de beter beveiligde omgevingen zoals ministeries, banken,
kernreactoren en gevangenissen. Veel van deze toegangspassen zijn gebaseerd op propriëtaire versleutelingstechnieken. Prominente voorbeelden zijn de op grote schaal
uitgerolde toegangscontrole systemen die gebruik maken van de MIFARE Classic,
iClass and Cryptomemory technologie.
Een startonderbreker is een elektronisch apparaat dat het starten van een auto
voorkomt wanneer de bijbehorende transponder niet in de buurt is. De transponder
is een draadloze radiografische chip die doorgaans verwerkt zit in het plastic omhulsel
van de autosleutel. Om autodiefstal tegen te gaan zal, wanneer de bestuurder de
auto probeert te starten, de startonderbreker eerst de autosleutel proberen te authenticeren voordat de auto daadwerkelijk wordt gestart. Volgens de Europese richtlijn
(95/56/EC) is het verplicht dat alle auto’s, die zijn verkocht na 1995, worden uitgerust
met een dergelijke startonderbreker. In praktijk zijn bijna alle recent verkochte auto’s
xiii
in Europa beschermd met transponders die gebruik maken van één van de twee propriëtaire cryptografische algoritmes Hitag2 of Megamos Crypto.
In dit proefschrift worden bestaande technieken gecombineerd met nieuwe methodes om de werking van de eerder genoemde propriëtaire cryptosystemen te analyseren.
De cryptografische sterkte en veiligheid van elk systeem is uitgebreid geëvalueerd. De
technische hoofdstukken beschrijven verschillende zwakheden en praktische cryptoanalytische aanvallen die kwaadwillenden kunnen uitvoeren met behulp van doorsnee
consumentenapparatuur. Dit benadrukt de ernst en de relevantie met betrekking tot
de mate van bescherming die wordt geboden. De ge¨ıdentificeerde kwetsbaarheden
zijn vaak simpele ontwerpfouten, waar de cryptosystemen al sinds hun introductie
vatbaar voor zijn.
Het eerste deel van dit proefschrift is gewijd aan een algemene introductie van computerbeveiliging en cryptografie. Het bevat een uitgebreide beschrijving van de theoretische achtergrond die verwijst naar verwante literatuur en geeft een overzicht van
bekende cryptografische aanvalstechnieken. Daarnaast wordt er een breed overzicht
gegeven van gerelateerde wetenschappelijke onderzoeken met betrekking tot propriëtaire cryptografie. Ten slotte presenteert het technische gedeelte van dit proefschrift ernstige zwakheden in breed ingezette propriëtaire cryptosystemen, die nog
steeds actief gebruikt worden door miljarden consumenten in hun dagelijks leven.
Contents
Acknowledgements
ix
Abstract
xi
Samenvatting (Dutch Summary)
1 Introduction
I
xiii
1
1.1
Introduction to digital security . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Inspiration and motivation . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Proprietary and secret cryptography . . . . . . . . . . . . . . . . . . .
4
1.4
Scientific and social value . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5
Responsible disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6
Scope and focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.7
Outline, contributions and results . . . . . . . . . . . . . . . . . . . . .
10
1.8
Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.8.1
Mathematical symbols . . . . . . . . . . . . . . . . . . . . . . .
14
1.8.2
Byte representation . . . . . . . . . . . . . . . . . . . . . . . .
14
Theoretical background
2 Introduction to cryptography
2.1
15
17
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.1.1
Caesar substitution . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.1.2
Scytale transposition . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2
2.3
2.4
2.5
Cryptosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.1
Cipher specification . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2.2
Cryptographic strength . . . . . . . . . . . . . . . . . . . . . .
21
2.2.3
Design methodology . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2.4
Application and deployment . . . . . . . . . . . . . . . . . . . .
23
Cryptographic algorithms . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.3.1
Symmetric and asymmetric cryptography . . . . . . . . . . . .
24
2.3.2
Stream ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.3.3
Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3.4
Hashes, MAC’s and Digital signatures . . . . . . . . . . . . . .
28
Protocols and access conditions . . . . . . . . . . . . . . . . . . . . . .
29
2.4.1
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.4.2
Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Weaknesses in symmetric cryptosystems . . . . . . . . . . . . . . . . .
32
2.5.1
Cipher design . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.5.2
Authentication protocol . . . . . . . . . . . . . . . . . . . . . .
33
2.5.3
Cipher initialization . . . . . . . . . . . . . . . . . . . . . . . .
34
2.5.4
Encryption oracle . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.5.5
Authorization model . . . . . . . . . . . . . . . . . . . . . . . .
35
2.5.6
Communication protocol . . . . . . . . . . . . . . . . . . . . . .
36
2.5.7
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
2.5.8
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3 Attack scenarios
3.1
3.2
41
Authentication and communication attacks . . . . . . . . . . . . . . .
41
3.1.1
Passive eavesdropping . . . . . . . . . . . . . . . . . . . . . . .
42
3.1.2
Relay attack . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.1.3
Replay attack . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.1.4
Reflection attack . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.1.5
Reorder and inject messages . . . . . . . . . . . . . . . . . . . .
47
3.1.6
Block the communication . . . . . . . . . . . . . . . . . . . . .
48
Cryptographic attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.2.1
Malleability attack . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.2.2
Divide-and-conquer attack . . . . . . . . . . . . . . . . . . . . .
51
3.2.3
Correlation attack . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.2.4
Guess-and-determine attack . . . . . . . . . . . . . . . . . . . .
55
3.3
3.2.5
Differential cryptanalysis . . . . . . . . . . . . . . . . . . . . .
58
3.2.6
Algebraic attacks . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.2.7
Meet-in-the-middle attack . . . . . . . . . . . . . . . . . . . . .
62
Physical attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.3.1
Non-invasive attacks . . . . . . . . . . . . . . . . . . . . . . . .
65
3.3.2
Invasive attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
3.3.3
Semi-invasive attacks . . . . . . . . . . . . . . . . . . . . . . . .
66
4 Scientific security assessments of proprietary cryptosystems
4.1
4.2
4.3
4.4
Access control systems and electronic locks . . . . . . . . . . . . . . .
69
4.1.1
Legic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.1.2
SimonsVoss G1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.1.3
SimonsVoss G2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Electronic vehicle immobilizers . . . . . . . . . . . . . . . . . . . . . .
71
4.2.1
DST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.2.2
KeeLoq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Cellular-, cordless- and sat-phones . . . . . . . . . . . . . . . . . . . .
73
4.3.1
ORYX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.2
A3, A8 and COMP128 . . . . . . . . . . . . . . . . . . . . . . .
74
4.3.3
A5/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.3.4
A5/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.3.5
A5/3 (KASUMI) . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.3.6
DSAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.3.7
DSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.8
GMR-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.9
GMR-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Various encryption techniques . . . . . . . . . . . . . . . . . . . . . . .
78
4.4.1
CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.4.2
E0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.4.3
Skipjack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.4.4
RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
4.4.5
WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5 Introduction to Radio Frequency Identification (RFID)
5.1
69
83
Technology and application . . . . . . . . . . . . . . . . . . . . . . . .
83
5.1.1
84
Signal modulation and encoding . . . . . . . . . . . . . . . . .
5.2
II
5.1.2
Communication standards . . . . . . . . . . . . . . . . . . . . .
84
5.1.3
Near Field Communication (NFC) . . . . . . . . . . . . . . . .
85
5.1.4
Contactless smart cards . . . . . . . . . . . . . . . . . . . . . .
86
5.1.5
Proprietary cryptography in RFID devices . . . . . . . . . . . .
86
Research tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.2.1
GNURadio framework . . . . . . . . . . . . . . . . . . . . . . .
88
5.2.2
Proxmark hardware device . . . . . . . . . . . . . . . . . . . .
89
Technical section
6 MIFARE Classic
91
93
6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
6.2
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.2.1
Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.2.2
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.2.3
Memory structure of the Mifare Classic . . . . . . . . . . . . .
98
Reverse-engineering MIFARE Classic . . . . . . . . . . . . . . . . . . .
98
6.3
6.4
6.5
6.3.1
Tag and reader authentication protocol . . . . . . . . . . . . . 100
6.3.2
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3.3
Filter function . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.3.4
CRYPTO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3.5
Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.4.1
Odd Inputs to the Filter Function . . . . . . . . . . . . . . . . 106
6.4.2
Parity weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.4.3
Nested authentications . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.4
Known Plaintext . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.5.1
Brute-force attack . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.5.2
Varying the reader nonce . . . . . . . . . . . . . . . . . . . . . 112
6.5.3
Varying the tag nonce . . . . . . . . . . . . . . . . . . . . . . . 116
6.5.4
Nested authentication attack . . . . . . . . . . . . . . . . . . . 118
6.6
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7 Hitag2
123
7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.2
Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.3
Hitag2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.4
7.5
7.3.1
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.3.2
Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.3.3
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.3.4
Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.3.5
Authentication protocol . . . . . . . . . . . . . . . . . . . . . . 133
7.3.6
Cipher Initialization . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.7
Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Hitag2 weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.4.1
Arbitrary length keystream oracle . . . . . . . . . . . . . . . . 135
7.4.2
Dependencies between sessions . . . . . . . . . . . . . . . . . . 136
7.4.3
Approximation of the filter function . . . . . . . . . . . . . . . 137
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.5.1
Malleability attack . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.5.2
Time/memory tradeoff attack . . . . . . . . . . . . . . . . . . . 138
7.5.3
Cryptanalytic attack . . . . . . . . . . . . . . . . . . . . . . . . 140
7.6
Starting a car . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.7
Implementation weaknesses . . . . . . . . . . . . . . . . . . . . . . . . 142
7.7.1
Weak random number generators . . . . . . . . . . . . . . . . . 142
7.7.2
Low entropy keys . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.7.3
Readable keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.7.4
Predictable transponder passwords . . . . . . . . . . . . . . . . 144
7.7.5
Identifier pickpocketing . . . . . . . . . . . . . . . . . . . . . . 144
7.8
Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.9
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8 SecureMemory, CryptoMemory and CryptoRF
149
8.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.2
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.3
The ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.3.1
8.4
Initialization and authentication . . . . . . . . . . . . . . . . . 155
Attacking SecureMemory . . . . . . . . . . . . . . . . . . . . . . . . . 158
8.5
8.6
8.4.1
Recovering the internal state . . . . . . . . . . . . . . . . . . . 159
8.4.2
Unrolling the cipher . . . . . . . . . . . . . . . . . . . . . . . . 161
8.4.3
Recovering the key . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.4.4
Complexity and time . . . . . . . . . . . . . . . . . . . . . . . . 162
Attacking CryptoMemory . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.5.1
Recovering the internal state . . . . . . . . . . . . . . . . . . . 163
8.5.2
Unrolling the cipher . . . . . . . . . . . . . . . . . . . . . . . . 165
8.5.3
Recovering the key . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.5.4
Complexity and time . . . . . . . . . . . . . . . . . . . . . . . . 166
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
9 iClass and iClass Elite
169
9.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.2
Research context and related work . . . . . . . . . . . . . . . . . . . . 170
9.3
9.4
9.5
9.6
9.7
9.2.1
Research contribution . . . . . . . . . . . . . . . . . . . . . . . 171
9.2.2
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
iClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
9.3.1
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
9.3.2
Authentication protocol . . . . . . . . . . . . . . . . . . . . . . 175
iClass standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.4.1
Black box reverse engineering . . . . . . . . . . . . . . . . . . . 176
9.4.2
The function hash0
9.4.3
Weaknesses in iClass Standard key diversification . . . . . . . . 184
9.4.4
Attacking iClass Standard key diversification . . . . . . . . . . 186
. . . . . . . . . . . . . . . . . . . . . . . . 182
The iClass cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.5.1
Firmware reverse engineering . . . . . . . . . . . . . . . . . . . 187
9.5.2
The cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Weakness in iClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.6.1
Weak keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.6.2
XOR key update weakness . . . . . . . . . . . . . . . . . . . . 191
9.6.3
Privilege escalation . . . . . . . . . . . . . . . . . . . . . . . . . 192
9.6.4
Lower card key entropy . . . . . . . . . . . . . . . . . . . . . . 192
9.6.5
Key recovery attack on iClass Standard . . . . . . . . . . . . . 192
iClass Elite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.7.1
Key diversification on iClass Elite . . . . . . . . . . . . . . . . 194
9.7.2
Weaknesses in iClass Elite key diversification . . . . . . . . . . 196
9.7.3
Key recovery attack on iClass Elite . . . . . . . . . . . . . . . . 197
9.8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
9.9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
10 Megamos Crypto
201
10.1 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
10.2 Historical claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
III
Back matter
203
Conclusion
205
Bibliography
209
Index
259
Acronyms
261
List of figures
265
List of publications
269
Curriculum vitae
273
Chapter 1
Introduction
It is hard to imagine a world without computers. Especially without small computers,
called micro-controllers, which are embedded into a variety of modern devices. Wellknown examples of such devices are electronic passports, contactless banking cards,
access control tokens, car keys, phones, televisions and even small appliances like
toasters. The general public uses such devices many times a day without considering
the potential security and privacy risks they get exposed to.
During the last decade, many of these devices started using customly designed
wireless communication interfaces. The ability to operate autonomously with remote
access to all sorts of information enables several advanced features. However, the
security and privacy risks of such systems increase with every additional feature. It is
important to mitigate the risks and protect these wireless interfaces against malicious
adversaries in the best possible way.
It is not trivial to design an algorithm (effective method expressed as a finite list
of mathematical calculations) that establishes a secure communicate channel. Many
experts, affiliated with top universities, leading industries and influential governments
proposed several cryptographic designs. Surprisingly, only very few cryptographic
algorithms proved to be secure over time. When used properly, such algorithms
offer appropriate protection against malicious adversaries. However, despite their
existence, these secure algorithms are still rarely utilized in commercial devices.
Mathematicians and experienced practitioners advocate that a cryptosystem should
undergo a long and careful peer-review process that consists of academic and public
scrutiny. Contrarily, businesses have a tendency to operate in isolation and protect
their intellectual property. Accordingly, they design confidential proprietary cryptosystems which embed secret (authentication) protocols. Unfortunately, history
shows that their proprietary designs tend to be insecure and susceptible to severe
practical attacks.
In this thesis the security strengths of various proprietary cryptosystems are independently assessed. Advanced techniques, mathematical proofs and practical examples demonstrate how minor design mistakes can drastically reduce the security
of a complete cryptosystem. Furthermore, it didactically guides and educates the
reader to be creative and to think more as an adversary when assessing novel security
designs.
This chapter introduces the motivation, objectives and outline of this dissertation.
2
Introduction
A general introduction to security in the digital world is given in Section 1.1. The
inspiration and motivation for this research is outlined in Section 1.2, followed by
careful explanation of its scientific and social value in Section 1.4. Section 1.6 gives
an overview of the research scope. Section 1.7 gives an outline of the chapters and
results that were achieved during this study. Finally, Section 1.8 introduces the
notation used throughout this dissertation.
1.1
Introduction to digital security
Privacy protection, secure data communication, remote authentication and proof of
ownership are well-known examples of digital security mechanisms. Digital security,
sometimes also referred to as information security, plays an important role in the
daily tasks of an average person. It is hardly noticeable that such security mechanisms are used when email is checked, mobile phones are activated or a digital
television is switched on. However, each of these tasks performs various mathematical computations to validate the user’s credentials and protect the confidentiality of
the transmitted data. Such mathematical computations are also called cryptographic
operations. With the use of cryptography it is possible to achieve several goals of digital security; this section introduces five of these goals: confidentiality, data integrity,
entity authentication, message authentication, availability and non-repudiation.
Confidentiality
There can be many reasons why a transmission of data should be protected
against eavesdroppers. This is extremely important for content of high value,
like privacy sensitive communication, confidential company information and
data that involves governmental secrecy. In these cases it is important to establish a confidential communication channel where only the intended genuine
sender and receiver can interpret the communication. Such a communication
channel, which is kept confidential between the legitimate parties, is called a
secure channel. The mathematical tool that is used for this is called encryption. More details about its background and specific workings are available in
Chapter 2.
Data integrity
Data integrity enables a receiving party to determine if the transmitted data was
unaltered and finished within the expected time-frame. When such an integrity
check fails, it could be just a transmission error, or the data was intentionally
altered by an adversary. Such alternation of data is referred to as message
tampering. A communication is only considered secure, when all transmitted
messages are delivered, none of the messages are tampered with, and the order
and delivery time occurred as specified. They are commonly referred to as
authentication protocols, see Section 2.4.1 for more details.
Introduction
3
Entity authentication
Entity authentication verifies the authenticity of the transmitting party (entity). There are mathematical ways to prove that the data is originating from
the genuine transmitting party. They are commonly referred to as authentication protocols, see Section 2.4.1 for more details. Such authentication protocols
enable an authenticated secret key establishment between both entities [BM03],
which is useful to set up an encrypted communication channel. Besides entity authentication, there are several more types of authentication, please refer
to [MVOV10] for more details on this topic.
Message authentication
To trust a communication channel the involved parties should provide both: entity authentication and data integrity. It proves the authenticity of the message
data and data origin. Such authenticity is established when the recipient can
verify that the sender has access to secret credentials of the genuine originator.
After verification the recipient has a certain level of confidence that the message was not illegitimately forged or tampered with. This is usually provided
by the utilization of digital signatures. More information about such signatures
is given in Section 2.3.4.
Authenticity is used for many purposes. For instance to prove the validity
of an e-passport, ensure the genuineness of a website, protect against product
counterfeiting or prevent fraud in digitalized public transport systems.
Availability
Availability is not always directly considered as a security requirement. However, recent events show that even websites of international banks and large
government institutions can become inaccessible when enough network load is
allocated to overload their servers. Therefore, the security is considered compromised when the system is made unavailable by an adversary, even when
confidentiality and integrity are still guaranteed.
Non-repudiation
Non-repudiation allows the communicating parties to commit to their actions
in such a way that it assures the origin, transport and delivery of the message.
It is primarily of interest in the context of legal or financial transactions. The
involved parties commit to their actions using cryptographic operations in such
a way that they cannot deny their involvement afterwards.
Availability and non-repudiation are indisputably important security requirements. However, they are not directly applicable to the systems addressed in this
study. Therefore, the focus is put toward the security concepts and cryptographic
properties of confidentiality, integrity and authenticity. A more general overview of
the security requirements is available in [Lan01, Sti05, MVOV10]. Additionally, a
business oriented study about the process and financial impact of computer security
is available in [LCPW01, GL02, BGL05]
4
Introduction
1.2
Inspiration and motivation
In everyday life an average person is surrounded by cryptographically enabled electronic devices which operate remotely through a contactless interface. They are utilized to improve usability, transaction speed and reliability. Well-known examples
include: using your access control card at the entrance of your office building; travelling with a contactless public transport card; authenticating to vehicle immobilizers
using your car key; or paying for lunch with your cell phone.
The general public often uses devices without giving their security much attention,
let alone questioning the actual strength of the applied security measures. They just
work great, it often feels a bit magical to open a door from a distance using (batteryless) wireless devices. Such a feeling tends to give a false sense of confidence about
the provided security. It looks very complicated, so it is probably pretty hard to
understand, let alone to attack, break and abuse.
Surprisingly, the opposite seems to be true when looking deeper into the cryptography, authentication protocols and actual implementations of widely deployed
cryptosystems. There are numerous examples where the security mechanisms of these
systems fail. Subsequently, the general public is using many devices that embed weak
security features, ranging from easy to break proprietary cryptography to unreliable
and insecure communication protocols. It is no wonder that people start to feel like
“Everything is Hackable”.
The problem is not the lack of decent and secure cryptographic algorithms and
protocols. Several secure cryptosystems were introduced over the last decades [Smi71,
DH76, RSA78, DR98]. The origin of the problem is related to the design methodology of a cryptosystem. A secret and proprietary design inherently hinders an open
discussion about the security of a system. Moreover, it counteracts independent scientific assessments and public proposals to mitigate and improve the utilized security
mechanisms.
1.3
Proprietary and secret cryptography
In 1883, more than a century ago, the Dutch linguist and cryptographer Auguste
Kerckhoffs published a set of principles in the Journal des sciences militaires that
should apply to a cryptosystem [Ker83]. The second principle, often referred to as
the Kerckhoffs’s principle, represents one of the most cited and critical ground rules
that apply to the design of a cryptosystem:
Il faut qu’il n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre
les mains de l’ennemi 1
An approximate English translation of the French text:
1 http://www.petitcolas.net/kerckhoffs/crypto_militaire_1.pdf
Introduction
5
It must not require secrecy and it can without disadvantage fall into the hands
of the enemy
Many cryptographers refer to Kerckhoffs’s principle in the literature and likewise
advocate that the security of a cryptosystem should not depend on the secrecy of the
algorithm. Instead, its security should solely rely on the secrecy of the key.
According to Kerckhoff’s principle the design of a cryptosystem should be considered known to an adversary. This does not necessarily imply that the method should
be made public. Moreover, history teaches us that the security of a cryptosystem
benefits from public scrutiny.
Over time, many proprietary cryptosystems proved to be weak and easily broken.
The proposed attack methodologies are surprisingly simple and efficient. Algorithms
and protocols are often compromised with use of only elementary cryptanalysis techniques, see Chapter 3 for more details. Note that such techniques are sometimes
known in the literature for several decades. For instance, many proprietary cryptosystems are vulnerable to algebraic attacks, which were proposed in the literature
almost a century ago in 1929 [Hil29].
Designing secure cryptographic algorithms has proven to be a difficult task
without feedback from the scientific community [Ker83, JS97, fSN97]. The workings of proprietary cryptosystems are often kept secret to provide security-throughobscurity. The industry often claims that their products provide ‘state-of-the-art’,
‘field-proven’, ‘high-level’ and ‘unbreakable’ security, but it is hard to know what
this means and how much security you actually get. There are numerous examples
in the literature [Gol97a, WSK97, KSW97, Gol97b, WSD+ 99, Ste99, BBS99, HN00,
FMS01, BGS+ 05, Bog07c, GdKGM+ 08, dKGHG08, LST+ 09, GvRVWS09, Cou09,
COQ09, GvRVWS10, NTW10, KCR+ 10, BKZ11, VK11, CMK+ 11, GdKGV11, PN12,
DHW+ 12, GdKGVM12, BGV+ 12, VGB12, VGE13, WMT+ 13, SDK+ 13, OSS+ 13,
MOPS13, BK14, GdKGV14] showing that once the secrecy of an algorithm is lost, so
is its security.
Proprietary cryptographic algorithms do not always comply with open and
community-reviewed encryption techniques. Therefore, the metrics of publicly scrutinized cryptography do not always hold for a proprietary cryptosystem with similar
specifications, like the same secret key length and operation speed. Furthermore,
the security features of a proprietary cryptosystem are undefined until they are independently and thoroughly assessed. Only if a comparable assessment and selection
process is performed to construct a proprietary cipher , it is possible to match the
strength of public schemes.
In 1997, the United States (US) Department of Defence (DoD) commissioned an
objective study to measure and specify cryptographic strength [JS97]. The report
explicitly states that if an algorithm is publicly proposed and published in the open
literature, it should benefit from a broader base of criticism. Such criticism initiates a
more severe verification of the algorithm and stimulates society to propose additional
improvements.
6
Introduction
Weaknesses make a cryptosystem vulnerable to malicious adversaries. Such weaknesses, also known as vulnerabilities, can be identified, yet they are never created. It
is sensible to filter out as many weaknesses as possible before a cryptosytem is deployed. Vulnerabilities that are identified after deployment are often hard to mitigate.
This is one of the main reasons why new cryptosystems are first publicly proposed in
the scientific literature.
An important note needs to be made on proprietary versus secret cryptography.
Cryptographic algorithms that are kept secret are not necessarily a fully customized
design like most proprietary algorithms. Such designs are often similar to widely
adopted and publicly scrutinized algorithms. For instance, by compromising on resources and encryption speed the strength of the algorithm can be increased.
Large institutions with access to substantial resources, such as government agencies and military establishments, have the capability to organize internal events to
design new proprietary and secret cryptographic algorithms. These proposals are
then subject to an internal but independent rigorous selection process, where weak
schemes are eliminated and the best and strongest cryptographic design is selected.
However, such a procedure is costly, requires many employees with a strong cryptographic background and would take many years of research. Finally, the secrecy of
an algorithm should never be utilized to cover up negligent designs.
Despite the efforts of designing a secret algorithm, it should be noted that secrecy
of an algorithm offers only marginal improvements to the security of a cryptosystem.
As Kerckhoffs pointed out, it is just a matter of time before the inner workings of the
algorithm are exposed to an adversary. Furthermore, its not a measurable security
property, since it is unknown whether the adversary has already gained knowledge
about the algorithm or not. Especially in the longer term, it is wise to assume that
such knowledge becomes public knowledge.
There are several ways to recover the mathematical operations of a cryptographic
algorithm. For instance, a practical method to discover the workings of an algorithm is the use of reverse-engineering techniques [CC90, SS02], such as decompilation [Hou73, Cif94, CG95, SSB11] and side-channel analysis [Cla04, DLMV05]. With
the assumption that an algorithm eventually gets exposed to the general public, and
is likely to be peer-reviewed by the scientific community, it might be a wise strategy
to invoke such procedures from the start.
The publicly proposed cryptosystems are carefully audited and scrutinized by
fellow academics. After identification of vulnerabilities in a design it is immediately
discouraged for further use, in theory and practice. Conversely, cryptosystems that
resist comprehensive assessments and prove secure over time [Smi71, DH76, RSA78,
DR98] are praised by the scientific, as well as the industrial security community. Such
cryptosystems are utilized worldwide in many major computer systems that require
a high level of security. Unfortunately, most small consumer devices do not embed
strong cryptography. Instead, they still use ad hoc created and poorly tested secret
and proprietary cryptosystems.
Introduction
1.4
7
Scientific and social value
A very interesting point of discussion is the scientific and social value of studies that
determine the strength of widely used proprietary cryptosystems. A separation can
be made between the short-term and the long-term contributions.
Short-term value
The direct impact is the immediate response that is given by the users and
other stake-holders. Once security issues of a system become public knowledge,
the general public demands that the involved parties take responsibility and
carry out appropriate actions to strengthen the system in such a way that it
compensates for the loss of security.
Scientists play a crucial role in objectively informing society about important
developments and serious security issues which concern the general public. Such
activity includes the verification of open academic designs as well as the assessments of proprietary industry designs.
There is a risk that adversaries take advantage of the moment that a vulnerability becomes public knowledge, while not all security weaknesses are taken
care of. However, it is important to note that unpublished vulnerabilities are
not less dangerous than published ones. Weaknesses are identified, not created.
Nevertheless, the risk of exploitation can be reduced if weaknesses are taken care
of before the adversary learns that they exist. However, it is hard to estimate
the kind of knowledge an adversary has access to.
Long-term value
Furthermore, it generally motivates the industry to migrate to well-studied and
publicly reviewed cryptographic algorithms and formally verified authentication
protocols. It has been known for many years that weak ciphers that solely depend on security by obscurity do not prevail in a hostile environment. However,
industrial parties often only acknowledge the problem when their weak cryptographic algorithm is openly proven to be insecure and vulnerable in practice.
Subsequently, this policy opens doors for third parties like criminals and government agencies to abuse its insecurity. The temptation is high for such parties
to keep the knowledge of cryptographic weaknesses hidden and keep exploiting
them in secrecy.
This study concretely addresses cryptographic security vulnerabilities which exist
in widely used weak proprietary cryptosystems. It enables architects of such systems,
academics as well as engineers, to learn from serious design and implementation mistakes. The presented security assessments of various cryptosystems educate architects
to identify security vulnerabilities and prevents similar weaknesses in future designs.
8
Introduction
1.5
Responsible disclosure
Even though the long term goal is to improve our security systems, there is an ethical consideration in the fact that publishing information regarding weaknesses in a
cryptosystem could, in the short term, make it easier for criminals to misuse the system. To deal with this problem there is the widely accepted principles of responsible
disclosure.
The National Cyber Security Centre (NCSC), part of the Dutch Ministry of Security and Justice, released formal guidelines which define responsible disclosure as:
Revealing Information and Communication Technology (ICT) vulnerabilities in
a responsible manner in joint consultation between discloser and organisation
based on a responsible disclosure policy set by organisations.
The guidelines from the NCSC encourage security researchers to disclose security vulnerabilities following this principle2 . A detailed overview of the responsible disclosure
objectives are defined in the Request for Comments (RFC) draft [CW02], which was
published in 2002 by the Internet Engineering Task Force (IETF).
Once a vulnerability has been found, stakeholders agree to allow a period of time
for the vulnerability to be fixed before publishing the details. Developers of hardware
and software often require time and resources to repair their mistakes. Computer
security scientists have the opinion that it is their social responsibility to make the
public aware of vulnerabilities with a high impact. Hiding these problems could cause
a feeling of false security. To avoid this, the involved parties join forces and agree on
a period of time for repairing the vulnerability and preventing any future damage.
Depending on the potential impact of the vulnerability, this period may vary between
a few days and several months.
The Dutch NCSC defines that if the vulnerability is to be made public, the organisation will set a date for when the vulnerability will be made public in consultation
with the discloser. A reasonably standard term that can be used for software vulnerabilities is 60 days. Remedying hardware vulnerabilities is much more difficult; for
these, a term of six months can be considered reasonable under normal circumstances.
Another authoritative organization is the Computer Emergency Response Team
(CERT), which is part of the Software Engineering Institute (SEI), based at the
Carnegie Mellon University. It is the US counterpart of the Dutch NCSC and dedicates itself to improve the security and resilience of computer systems and networks. Vulnerabilities reported to the CERT are by default disclosed to the public
45 days after the initial report, regardless of the existence or availability of patches
or workarounds from affected vendors. Extenuating circumstances, such as active
exploitation, threats of an especially serious (or trivial) nature, or situations that
require changes to an established standard may result in earlier or later disclosure.
The vulnerabilities that are identified in the Technical Section of this dissertation
2 https://www.ncsc.nl/english/current-topics/news/responsible-disclosure-guideline.html
Introduction
9
are published in line with the principles of responsible disclosure, where all affected
vendors were apprised at least a half year in advance of the publication. Together with
the affected vendors an alternate publication schedule was negotiated when required.
It is the goal of this policy to balance the need of the public to be informed of
security vulnerabilities with vendors’ need for time to respond effectively. The final
determination of a publication schedule will be based on the best interests of the
community overall.
1.6
Scope and focus
Designing a cryptosystem is a complex task. A slight variation of a secure design
could undermine its protection against various attack and exploitation techniques.
The variety of secure applications and their design specifics make it hard to compile
one general solution. Instead, there are many different kinds of cryptosystems using
various types of cryptography.
Weaknesses in a cryptosystem often depend on the specific use of certain algorithms and protocols. For instance, weaknesses of asymmetric cryptography based
systems differ radically from those used in symmetric systems. Furthermore, the
specifics and usage of symmetric algorithms like hash functions, stream and block
ciphers define another additional subset of particular vulnerabilities. The subject is
comprehensive and difficult to address entirely. Therefore, the scope of this study is
limited to a subset of cryptosystems that are widely used in proprietary cryptographic
designs.
A general categorization of cryptography is illustrated in Figure 1.1. The specific
details of the mentioned categories are later discussed in Chapter 2, which embodies
the introduction to cryptography. Within the scope of cryptography, the focus of this
study is put on proprietary synchronous stream ciphers. Such stream ciphers represent
a limited subcategory within the broader context of symmetric cryptography. For
more details about stream ciphers, please refer to Section 2.3.2.
Cryptography
Asymmetric
Symmetric
Block ciphers
Stream ciphers
Self-synchronizing
Synchronous
Figure 1.1: General categorization of cryptography and study focus
10
Introduction
Radio Frequency Identification (RFID) is a contactless technology which offers a
wireless communication interface to micro-controllers that operate with very limited
energy. The technology is deployed in many security applications such as in secure
storage, access control systems and anti-theft devices.
The majority of RFID devices use proprietary cryptosystems as a security mechanism to achieve confidentiality and integrity. The heavy dependence on proprietary
cryptography makes them ideal subjects for the scope of this study.
1.7
Outline, contributions and results
The contribution of this study is a dissertation that introduces, summarizes and
applies various cryptographic attack methodologies on proprietary ciphers. It is divided into three main parts, each containing several self-contained chapters. A quick
overview of the parts and chapters follows.
Part I – Theoretical background
The first part covers the theoretical background which introduces the techniques and
methodologies used during the study. It consists of four chapters.
Chapter 2 – Introduction to cryptography
The core aspects of cryptography are introduced in this chapter. It starts with
a few historical examples and explains the different types of cryptographic algorithms. Furthermore, it presents the different properties of the components
embedded in a cryptosystem. The chapter shows the reader the meaning of
cryptographic strength and how to identify weaknesses in a cryptosystem.
Chapter 3 – Attack scenarios
Elementary attacking techniques are introduced in the second chapter. It first
shows attacks on a protocol level, where the communication channel is compromised. Then, cryptographic weaknesses are exploited and attacked with various
cryptanalytic techniques.
There are many complex mathematical notations to represent such techniques.
However, this chapter puts forward the most commonly used cryptanalytic techniques by using comprehensible examples. Finally, it shows the possibility to
compromise a cryptosystem on a different level by directly attacking the hardware. Most attacks addressed in this chapter are mounted in practice on a real
cryptosystem in the technical section of this dissertation.
Chapter 4 – Releated attacks on proprietary cryptosystems
The academic literature includes a large quantity of cryptanalytic contributions
that assess the security of various proprietary cryptosystems. This chapter
describes several studies which are most relevant to the research presented in this
Introduction
11
dissertation. The results and conclusion of the related work strongly support
the reasons to choose publicly reviewed cryptosystems over proprietary designs.
Chapter 5 – Introduction to Radio Frequency Identification (RFID)
The fourth chapter links the theoretical study on proprietary cryptography to
practical examples of deployment in the RFID industry. To fully understand the
features and limitations of the technology, a short introduction is given to the
communication techniques and operational characteristics. Additionally, this
chapter presents a set of hardware research tools which can be used to verify
the results presented throughout this dissertation.
Part II – Technical section
The technical section is embedded in the second part of this dissertation. It contains the core contributions of the scientific study of proprietary cryptosystems. It
includes comprehensive methods to identify weaknesses, novel attack techniques, precise cryptographic strength assessments and constructive procedures to mitigate attacks. Part II consists of eight original contributions published in the literature. The
related articles are combined in five chapters which are summarized below.
Chapter 6 – MIFARE Classic
This chapter uncovers serious security weaknesses in the widely sold MIFARE
Classic RFID chip. The chip is embedded in more than a billion contactless
smart cards. It was originally designed for use in public transport systems.
However, many highly secured facilities adopted RFID tokens for their access
control system.
The chapter illustrates how the workings of the cryptosystem were revealed and
presents a mathematical representation of the used algorithms. Furthermore, it
identifies several weaknesses, proposes several attacks and demonstrates their
feasibility. The practical impact of this study is vast. After exposure, many ministries, military bases, banks, nuclear power plants and prisons quickly migrated
to more secure alternatives that use publicly reviewed cryptography.
Contribution
The work is based on two articles, Dismantling MIFARE Classic [GdKGM+ 08]
and Wirelessly Pickpocketing a MIFARE Classic Card [GvRVWS09].
The first article [GdKGM+ 08] is written together with Flavio Garcia, Gerhard
de Koning Gans, Ruben Muijrers, Peter van Rossum, Ronny Wichers Schreur
and Bart Jacobs. The contribution of the author to this article is manyfold.
Firstly, the reverse-engineering process was performed by the author in close
cooperation with Gerhard de Koning Gans. Secondly, one of the two proposed
attack ideas originates from the author. Finally, implementation of the cipher,
authentication protocol and attacks in software was largely done by the author.
12
Introduction
The second article [GvRVWS09] is written together with Flavio Garcia, Peter
van Rossum, Ronny Wichers Schreur. The author identified additional weaknesses, contributed a fully working novel attack himself and designed another
attack together with the co-authors.
The practicality of both attacks was demonstrated by a fully working implementation written by the author. Furthermore, he designed a experimental
set-up which could mount all proposed attacks and depends only on low-cost
off-the-shelf hardware.
Chapter 7 – Hitag2
Hitag2 is one of the most used RFID chips in the car immobilizer industry.
Such an immobilizer is an anti-theft device which prevents the engine of the
vehicle from starting when the corresponding chip is not present. The chip is
a passive RFID tag which is embedded in the key of the vehicle. Hitag2 uses
a proprietary cryptosystem for authentication and confidentiality. This chapter
reveals several cryptographic weaknesses and presents three practical attacks
which depend only on wireless communication.
Contribution
The chapter is based on the article Gone in 360 Seconds: Hijacking with
Hitag2 [VGB12] which is written together with Flavio D. Garcia and Josep
Balasch. The major part of this study is performed by the author. This includes the design and implementation of the weaknesses, attacks, experimental
set-up and mitigating measures. However, the scientific article was composed
in close collaboration with both co-authors.
Chapter 8 – SecureMemory, CryptoMemory and CryptoRF
This chapter assesses the security of an algorithm used in three different
chip families, namely SecureMemory, CryptoMemory and CryptoRF. They
are widely deployed and applied in many industries which include anticounterfeiting, secure storage and contactless smart cards.
The chips use a proprietary stream cipher to guarantee origin authenticity, confidentiality, and data integrity. This chapter describes the cipher in detail and
points out several weaknesses.
Contribution
This chapter represents the article Dismantling SecureMemory, CryptoMemory
and CryptoRF [GvRVWS10]. The research load was evenly shared between the
co-authors. The author contributed to several activities such as engineering,
cryptanalysis, computing mathematical complexity estimations and writing of
the article.
Chapter 9 – iClass and iClass Elite
iClass is one of the most popular contactless smart cards on the market. It is
widely used for access control, secure login and payment systems. According
Introduction
13
to the manufacturer, more than 300 million iClass cards have been sold. The
algorithms used in iClass are proprietary and little information about them is
publicly available. This chapter presents six critical weaknesses and two novel
cryptanalytic attacks, one against iClass Standard and one against the more
expensive iClass Elite variant.
Contribution
The chapter embeds three scientific articles. The first two are conference papers,
Exposing iClass Key Diversification [GdKGV11] and Dismantling iClass and
iClass Elite [GdKGVM12], the third is a more comprehensive story published
by a journal Wirelessly Lockpicking a Smart Card Reader [GdKGV14].
The contribution to each paper is shared amongst co-authors. The author contributed a large amount of work to the cryptanalysis embedded the second
paper. Furthermore, the author was closely involved in the design, development
and verification of both attacks presented in this chapter.
Chapter 10 – Megamos Crypto
The Megamos Crypto chip is another widely deployed electronic vehicle immobilizer. The original scientific article was carefully peer-reviewed and accepted
for publication. It demonstrates the lack of existing security in various car
makes. The article reveals inherent weaknesses on the basis of mathematical
calculations.
The intention was to embed the article in this chapter. However, due to a
interim injunction, ordered by the High Court of London on Tuesday the 25th
of June, 2013, the author is restrained from publishing the technical contents
of the scientific article Dismantling Megamos Crypto: Wirelessly Lockpicking a
Vehicle Immobilizer [VGE13] until further notice.
Therefore, this chapter only defines a historical claim, in the form of a cryptographic message digest, of the original scientific article. This way, with restraints
lifted in the future, the genuineness of the article in a post publication procedure
can still be validated.
Contribution
The author supplied a comprehensive contribution to this article. A major
share of the ground-work, design, implementation, experiments and writing is
performed by the author.
Part III – Back matter
The back matter material is covered in the third part. It includes an extensive bibliography which reflects all consulted sources, index of commonly used phrases, overview
of acronyms, list of figures and the author’s curriculum vitae.
14
1.8
Introduction
Notation
It is difficult to define certain cryptographic properties without a proper notation.
Part I of this dissertation contains only limited use of elementary mathematical symbols, while Part II explicitly uses a more complex mathematical notation to support
the statements that are specified in the text. Throughout this dissertation the notation that is used for mathematical symbols is specified in Section 1.8.1 and the
representation of a byte is defined in Section 1.8.2
1.8.1
Mathematical symbols
The mathematical symbols are defined as follows:
Let F2 = {0, 1} be the field of two elements (or the set of Booleans). The vector
space Fn2 represents a bitstring of length n. Given two bitstrings x and y, xy denotes
their concatenation. Sometimes, this concatenation is written explicitly with x · y to
improve readability.
Given a bitstring x ∈ (Fn2 )l , then x[i] denotes the i-th element y ∈ Fn2 of x.
Likewise, yi denotes the i-th bit of y. For example, given the bitstring x = 0x010203 ∈
(F82 )3 and y ← x[2] then the byte y = 0x03 and the bits y6 = y7 = 1.
The symbol ǫ represents the empty bitstring, 0n a bitstring of n zero-bits and
similarly, 1n denotes a bitstring of n one-bits. ⊕ denotes the bitwise exclusive-or
(XOR), ⊞ denotes addition modulo 256, x denotes the bitwise complement of x and
x ← y denotes the assignment of a value y to variable x. Sometimes, encryptions are
explicitly denoted by {−} to improve readability.
1.8.2
Byte representation
During a Radio Frequency Identification (RFID) transmission, the most significant
bit is transmitted first over the air. However, the two leading RFID standards
ISO/IEC 15693 [ISO00] and ISO/IEC 14443 [ISO01] specify that bytes should be
represented with the least significant bit on the left. This means that an ISO/IEC
compliant tool represents an over the air transmitted value of 0x0a0b0c as 0x50d030.
Unfortunately, the cryptosystems, specified in Part II, use the air transmission
order to feed input bits into the cryptographic functions. Therefore, we adopt the
air transmission convention throughout this dissertation (with the most significant
bit left, since that has nicer mathematical properties). However, we make an exception when we show a communication trace, such that we maintain representational
consistency with tools and command codes that are compliant with the ISO/IEC
specification.
Part I
Theoretical background
Chapter 2
Introduction to cryptography
There are many situations where a private communication channel is required in order to exchange confidential messages. It is not hard to imagine such a requirement
for governmental matters that concern national security. Moreover, it also applies for
business information that conceals company trade-secrets or privacy sensitive information in someone’s love-letters. The use of Cryptography can ensure that only the
intended recipient can read the message.
Cryptography can be used to transform an original piece of text (plaintext) into
a concealed piece of text (ciphertext) and vice-versa. The basic idea behind such
cryptography is that a sender conceals (encrypts) a message using a mathematical
algorithm (cipher) and a secret. A recipient that knows the cipher and secret can
reveal (decrypt) the original message. The legitimate parties, sometimes referred to as
(genuine) entities, can transform plaintext to ciphertext and ciphertext to plaintext.
However, a third party (e.g. the adversary), has no knowledge of the secret and
therefore does not have access to the plaintext.
Although this chapter tries to introduce the use of cryptography, it mostly focusses
on encryption and authentication protocols. However, the applicability of cryptographic algorithms extends far beyond this scope. A much more extensive overview
of cryptography in general is described in [Sti05] and [MVOV10].
Section 2.1 demonstrates the basic principle and usage of a cryptographic algorithm by introducing two historical ciphers. Section 2.2 gives a short introduction to
cryptosystems. It defines the specification, cryptographic strength, design methodology and utilization of a cipher. The different types of modern cryptographic algorithms are introduced in Section 2.3. Section 2.4 introduces authentication protocols
and authorization models and carefully illustrates the difference between them. Finally, the various weaknesses and vulnerabilities of a cryptosystem are presented in
Section 2.5.
2.1
History
Preliminary forms of cryptography were already used by legendary civilizations like
Ancient Greece [Rei62] and the Roman Empire [Sin66]. In fact, the word cryptography
is derived from Greek κρυπτός (‘kryptos’ means ‘hidden’) and γράφειν (‘graphein’
means ‘to write’).
18
There are many ways to implement a symmetric cipher [Sha49]. However, most
of the time it is a combination of the substitution and transposition technique. It is
easy to explain those two techniques by applying two famous ancient ciphers. These
ciphers were used to exchange secret military strategies between allied forces. The
Caesar substitution was used by the Roman Empire and the Scytale transposition was
used in Ancient Greece. In the next paragraphs, both ciphers are introduced.
2.1.1
Caesar substitution
The Caesar substitution cipher is a simple cryptographic algorithm. Many people played with it when they were kids to send
a secret message to one of their friends. The basic concept of the
algorithm is easy: every character is replaced (substituted) by a
different character that is a number of positions later in the alphabet. The alphabet is rotated, so if the end of the alphabet is
reached, the next substitution is with the first letter of the alphabet. The secret key
in this algorithm is the number of positions by which the characters are rotated.
The procedure of this cipher follows. Take all the characters from the alphabet
and put them from A to Z next to each other in one sequence. Rotate the characters
by a few positions and write the same characters set below the original sequence.
Figure 2.1 shows a graphical representation of the Caesar substitution cipher with as
secret key a rotation by three positions.
A B C D E F G H I J K L MN O P Q R S T U V W X Y Z
D E F G H I J K L MN O P Q R S T U V W X Y Z A B C
Figure 2.1: Caesar substitution using a rotation of three positions
Figure 2.2 shows an example of encryption and decryption
of the word “ATTACK”. The top (plaintext) characters are
substituted with the bottom (ciphertext) characters as specified in Figure 2.1. This example makes it rather easy to spot
one of the obvious weaknesses in this cryptosystem: it changes
the characters yet not the structure of the plaintext. An adversary can immediately deduce the length of the plaintext
and that several characters are similar.
A T T A C K
DWW D F N
Figure 2.2:
Substitution
example
In Figure 2.2 the 1st character is the same as the 4th and the 2nd is the same
as the 3rd. There are not so many (English) words of six characters that have such
a structure. Additionally, inside information about the context allows for more optimized plaintext recovery. For instance, when the message illustrated in Figure 2.2
can be correlated to battlefield terminology, the set of generic English words can be
19
reduced directly to the original plaintext. More information about the cryptographic
strength of the Caesar substitution cipher is explained in Section 2.2.2.
2.1.2
Scytale transposition
In the era of Ancient Greece, Spartan generals and Greek
leaders επηορς (‘ephors’ means ‘one who oversees’) used a
cylindrical staff as a tool to apply an elementary transposition cipher. Such a staff was called a σκυταλη (‘scytale’
meaning ‘baton’). It is assumed that generals were able to
secretly communicate with one another by using a scytale
of similar size [Rei62].
To encrypt a message, the general would wind a ribbon of papyrus vertically
around the scytale and write the text on it horizontally. After completing the message,
the ribbon was unwound and delivered. The characters on the ribbon are transposed
and would appear to be written in a jumbled form. However, the original content
of the message is revealed when the recipient rewound the ribbon on a scytale with
similar shape and dimensions. Encryption with a scytale only depends on thickness
of the scytale, which represents the characters split position. Such split position
can be seen as the secret key of a transposition cipher. Figure 2.3 shows a simple
transposition encryption performed on a famous quote from [Sun94] using a split
position of seven characters.
A L LW A R F A R E I S B A S E D O N D E C E P T I O N
A
L
L
W
A
R
F
A
R
E
I
S
B
A
S
E
D
O
N
D
E
C
E
P
T
I
O
N
A A S C L R E E L E D P W I O T A S N I R B D O F A E N
Figure 2.3: Scytale transposition using a split position of seven characters
With respect to the Caesar substitution cipher, the structure of the original plaintext is much harder to reveal from the the transposed characters. However, rearranging positions with a scytale is very limited and can be rather easily recovered
using an exhaustive search of all the possibilities.
There are several ways to attack more complex transposition ciphers. For example,
20
the original character representation and distribution are not hidden when a transposition cipher is used solely. This enables an adversary to make a statistical analysis of
the frequent of occurring syllables in the language that were used in plaintext. Such
analysis would easily reveal the secret transposition split position. An example of a
cryptographic attack that uses frequency analysis is given in Section 2.2.2.
2.2
Cryptosystems
A system that provides a usable platform with cryptographic features is often referred
to as a cryptosystem. The building blocks of such a cryptosystem are the cipher
specification, cryptographic algorithm, implementations, usage and applications of
the system. This chapter explains them in more detail.
Section 2.2.1 shows the details from a cipher specification and configuration properties it may embed. Section 2.2.2 gives a short introduction into measuring the
cryptographic strength of a cipher. The design process of a cipher is handled in
Section 2.2.3. Finally, Section 2.2.4 addresses the application and deployment of a
cryptosystem.
2.2.1
Cipher specification
The specification of a cipher defines properties about the secret key, in- and output
message lengths, operational details and computational complexity.
All cryptographic algorithms require a secret key to operate. The length of this
key, often specified by its number of bits, depends heavily on the working of a cryptographic algorithm. For example, as mentioned in Section 2.3.1, asymmetric cryptography requires much larger keys than symmetric cryptography.
The length of an in- and output message differs per algorithm. It depends on the
operation of the cipher. Block ciphers use a fixed message length of multiple digits, while hardware optimized stream ciphers often operate bit-wise. This property
does not directly influence the strength of an algorithm. However, some configurations may require specific use of the algorithm to avoid cryptographic vulnerabilities.
The environmental configuration and application of ciphers is further discussed in
Section 2.2.4.
Some cryptosystems have special requirements that vary per algorithm. They
specify operational directives for initial computations so that the output becomes
less proportional to the input, which introduces an increase of non-linearity. For
instance, the output produced during the first computational rounds of a cipher often
contains direct linear relations to the input. Therefore, the specification can define
a minimum number of initial encryption rounds to significantly decrease the linear
dependencies between the cipher internals and the computed encryption bits. The
specifics of (non-)linearity are further defined in Section 3.2.6.
21
The use of a cryptographic algorithm requires a certain amount of computation,
commonly referred to as computational complexity. This is often deterministic for
a certain length of input. Such complexity defines the minimal number of bit-wise
operations in terms of hardware gates (transistors) that are required to assemble a
chip which can perform the complete cryptographic computation. More information
about the computational complexity is described in Section 2.2.2.
2.2.2
Cryptographic strength
The strength of a cryptographic algorithm is expressed in the total amount of computations an adversary needs to perform to recover the secret key. It is often referred
to as the computational complexity of the cipher.
For a perfectly secure cipher, the computational complexity is the same as the key
space, sometimes referred to as the entropy of the key. The key space refers to the set
of all possible keys and represents the total number of combinations using all secret
key bits. The size of the key (key-size) is the amount of bits n which define the size
of the complete key space 2n .
The naive method to recover the secret key is to try simply all combinations. Such
methodology is often referred to as an exhaustive search or a brute-force attack. It
would most likely require almost 2n computations to determine the secret key. To be
precise, on average an adversary finds the secret key halfway. When lucky, the key
can be determined at an early stage, but it might just as well be one of the last tries.
Interestingly, this property already shows that the number of computations required
to determine the key is by definition lower than the actual key space.
A cipher that is perfect should be the base for a secure cryptosystem. In practice
however, most ciphers are (slightly) weaker than the full entropy of their secret key.
With clever optimizations it is often possible to find the secret key by doing far fewer
computations than the actual entropy would require. This is called the actual attack
complexity of a cipher.
To explain the attack complexity we use a substitution cipher which is similar
to the Caesar cipher introduced in Section 2.1.1. However, the algorithm does not
depend on a rotation in the second sequence of characters. This time it re-arranges
the characters completely. Figure 2.4 shows an example of a random character permutation sequence.
A B C D E F G H I J K L MN O P Q R S T U V W X Y Z
B D H Z Q X L T E A K P S V R O Y MW I G U C J F N
Figure 2.4: Modified Caesar substitution using a random permutation
This allows at most 26! permutations, where each permutation is uniquely defined
by a secret (key) value. This results in the fact that the total entropy is close to
22
26! ≈ 288.4 , which represents a key of 88 bits. Such a relatively big key space is still
considered secure. In 2014, an average consumer laptop is able to perform 240 =
1, 099, 511, 627, 776 computations within an hour1 . Although it looks impressive to
perform more than a trillion computations within one hour, with an entropy of 288.4 ,
the laptop needs to compute for 288.4−40 × 240 = 248.4 × 240 ≈ 366, 791, 447, 164, 915
hours.
However, when an adversary attacks the algorithm using the character frequency
of a language, the attack complexity drops dramatically. The letter ‘E’ occurs on
average the most often in any piece of written English text. An adversary just counts
the total number of symbols on one page and constructs a list of all characters and
their occurring frequency. It is most likely that in a sorted frequency list in descending
order, the top character represents the letter ‘E’. This means that the adversary found
an attack to drop the complexity to 25! ≈ 283.7 . Repetition of the attack with vowels
and other frequently occurring consonants, the attack complexity vastly drops to an
entropy below 240 , which is easily solved with an average laptop.
2.2.3
Design methodology
To perform encryption and decryption, the algorithm needs to be known by the sender
as well as by the recipient. When all parties are trusted entities it may seem useful to
reveal only the algorithm to those involved. However, this means the initiator needs
to design its own algorithm and supply that in secret to the other parties. This way,
the algorithm actually becomes an extension of the secret key. In the late 90’s, Bruce
Schneier already stated [Sch98a, Sch98b] that it is far from difficult to reverse-engineer
an algorithm. When the algorithm becomes public, it may get much worse, since it
was designed internally with little feedback from the large scientific and industrial
cryptographic community.
As mentioned in Section 1.2, most scientists advocate that the strength of a cryptosystem should depend on secrecy of the key and not of the algorithm [Ker83]. However, for industrial parties it seems attractive to keep the workings of their product
secret. Instead of security, the main objective shifts to protect themselves against
counterfeiting by competitors. Such designs often prove to be weak and offer a much
lower attack complexity compared to their claimed computational complexity, see
Section 2.2.2.
Many insecure proprietary algorithms were proposed in the last decades, see Section 1.2 for more details. Almost all of them have an attack complexity that is lower
than an average laptop can compute in a small amount of time. Therefore, they are
considered practically broken and insecure to use. An interesting fact is that after a
proprietary algorithm is reverse-engineered, it often takes only a few weeks before a
successful attack is mounted.
1 Results
gathered from various computational experiments
23
Since the 70’s the approach to design a strong cryptographic algorithm became
somewhat different. Experts in cryptography of the US government decided that it
would be more satisfactory if there was a world-wide call for participation to design
a new cryptographic algorithm that complies with a certain cipher specification, like
announced in [fSN97]. The challenges are organized by the National Institute of Standards and Technology (NIST), formerly called National Bureau of Standards (NBS).
They specify that proposed cryptosystems should undergo a longer period (several
years) of peer-reviews and public scrutiny. The cipher with the highest attack complexity and best performance is selected as a new public encryption standard. Prominent ciphers competitions were held for the Data Encryption Standard (DES) [FIP77]
in 1977, the Secure Hash Standard (SHS) [FIP93] in 1993, the Advanced Encryption
Standard (AES) [FIP01] in 2001, and the Secure Hash Algorithm-3 (SHA-3) [FIP14]
in 2014.
The success of this selection method can be measured by examining the number
of years that attack complexity is above the computational capabilities of high-end
computers. For example, the cryptographic attacks on DES presented in the literature [BS93, Mat94] still require a complexity of at least 239 computations, see
Section 3.2.5 for more details about the attack technique. An important remark on
those attacks should be made: they additionally need more than 70 terra bytes of
chosen plaintext-ciphertext pairs. Hence, the feasibility to mount an attack against
DES in practice is very slim.
As a result, although the DES algorithm is clearly out-dated (1977), has a only
very limited key-size (56 bits) and can easily be broken with a big cluster of computers [KPP+06], it is still considered (moderately) secure.
2.2.4
Application and deployment
A cryptographic algorithm has to be used in the correct way. In many cases it is
just a building block of a larger cryptosystem to provide an authentication method
(see Section 2.4.1) or data integrity check (see Section 2.3.4). The purpose of the
application and its working environment define how the encryption functionality of the
cipher is used. An authentication method could in theory be specified independently
of the cipher. However, in practice it is usual to design the authentication protocol in
such a way that it is optimized for the characteristics of the applied cipher. Examples
could be to adjust the size of the input and output such that it matches the cipher
specification as explained in Section 2.2.1.
The purpose of some cryptosystems is to authenticate entities rather than to
encrypt confidential data. In such a system the security depends on the combination
of cipher strength (as described in Section 2.2.2), the used authentication protocol
and the way they are implemented. A more detailed overview of various weaknesses
that could be present in a cryptosystem is described in Section 2.5.
24
2.3
Cryptographic algorithms
As illustrated in Figure 1.1, there are several categories of encryption algorithms
within cryptography. This section explains the classification and covers the most
prominent variants and utilization of modern ciphers.
The difference between symmetric and asymmetric ciphers is explained in Section 2.3.1. Symmetric cryptographic algorithms can be divided into two categories,
stream ciphers and block ciphers. Section 2.3.2 introduces stream ciphers and Section 2.3.3 block ciphers. Finally, the way a cipher can be used for other purposes than
confidentiality is covered by Section 2.3.4.
2.3.1
Symmetric and asymmetric cryptography
Cryptographic algorithms can be divided into two categories, symmetric and asymmetric. A cryptographic cipher is considered to be symmetric when it uses the same
secret key for both encryption and decryption. An asymmetric cipher, on the other
hand uses two different keys. One key is kept secret, this is called the private key.
Contrarily, the second key is revealed to allow encryption of messages which are specifically directed to the owner of the corresponding private key. This second key is often
revealed to the general public, since in most cases the recipient wants to make the
possibility of sending encrypted messages to him available to everyone. Therefore,
this key is referred to as public key. A message that is encrypted with the public key
can only be decrypted with the corresponding private key and vice-versa. This can be
very useful in situations where one party wants to establish a secure communication
with another party without being in contact on beforehand to exchanged a shared
secret key (like applied in symmetric cryptography).
The basis for asymmetric cryptography is a mathematical problem which admits
no efficient solution, like integer factorization, discrete logarithm, or elliptic curve
relationships. These problems are time-consuming to solve, but usually faster than
trying all possible keys by brute-force and therefore require keys of larger sizes. Keys
of an asymmetric cipher are at least twice as big as symmetric cipher keys with comparable security. Due to hardware limitations of small embedded systems, the lighter
requirements of symmetric cryptography are often preferred to avoid computational
expensive big number multiplication and storage of large keys in an asymmetric cryptography system.
2.3.2
Stream ciphers
A stream cipher performs an encryption which is similar to the One-time Pad (OTP)
encryption technique. It produces a large chunk of secret, random looking data and
combines it with the plaintext to produce ciphertext. Without the exact same data
chunk, the plaintext cannot be uncovered from the ciphertext. The random data
25
represents a stream of bits which is derived from the secret key and is commonly
referred to as keystream. A stream cipher contains some persistent memory, called
the internal cipher state, which is initialized by the secret key and propagates to
a successor state after each encryption step. The output of a strong stream cipher
is comparable to (and should be indistinguishable from) a contiguous bit stream
produced by a Pseudo Random Number Generator (PRNG).
To be more precise, we embed the remarks made in [Sha04] and define a stream
cipher as follows: an encryption function which operates on individual plaintext digits
(usually bits) where its internal state is initialized with the secret key prior to encryption. The keystream varies, depending on the initialized secret key and the moment
of encryption with respect to the propagation of the internal state. Encryption of
plaintext and decryption of ciphertext are both performed by the exclusive-or (XOR)
operation, which is denoted by a ⊕ symbol and represents a bit-wise addition modulo two. A useful mathematical property of this operator is that it can be inverted.
Therefore, it can be applied for encryption as well as decryption.
There are two types of stream ciphers, synchronous and self-synchronizing. In a
synchronous stream cipher, the encryption bits are computed independently from the
plaintext. Such ciphers are useful in situations when a communication channel is more
prone to error. It might happen that just one badly transmitted bit is wrongly interpreted, which however does not directly affect the other bits that were transferred in a
correct manner. Therefore, stream ciphers are very useful to encrypt streaming media
where the speed of data-traffic is more important than the completeness and integrity
of the data. Contrarily, a self-synchronizing stream cipher computes the successor of
its internal state with a function over the previous state and the ciphertext. The
internal state diverts from its original propagation path when a transmission error
occurs. This dissertation focusses itself on the most widely used and best studied of
the two, the synchronous stream ciphers. Therefore, a general reference to a stream
cipher refers to a synchronous stream cipher.
An important objective of a stream cipher is to avoid a direct relation between
the input (secret key) and output (keystream) of the cipher. Because the entropy of
a stream cipher is limited to the size of the internal state, the produced keystream
will eventually repeat itself. Note, that this is not a property of a regular One-time
Pad (OTP).
Pure One-time Pad encryption can provide perfect secrecy when the keystream is
truly random and uniquely generated for each message that is transmitted [Sha49].
In such a setting, the keystream should consist of a unique bit string that contains
uniformly distributed random bits. However, in practice it is difficult to generate truly
random data. Alternative methods, like using the complete contents of a random
book, drastically limit the number of possible keystreams. Moreover, reuse of the
same keystream is very insecure. With access to previous plaintext and ciphertext,
an adversary would be able to extract the keystream. If the same keystream is used
in a second transmission, the adversary can use the recovered keystream and reveal
26
the second plaintext. Exactly for this particular reason, the encryption technique is
called One-time Pad. The keystream that represents the secret key should only be
used once.
Keystream can be seen as an unique set of bits which
must be as long as the plaintext. However, continuing
distribution of fresh keystream for long data sequences is
undesirable. With an increase in electronic transmissions
of large transcripts in the 20th century, the need for alternative solutions grew. In response several stream cipher
encryption techniques were introduced. For instance, in
the 1930s stream ciphers were mainly used in the form of
physical rotor machines which operated mostly mechanically. A well-known example of such a rotor machine
is the Enigma, which is illustrated in Figure 2.5. A few
decades later, the introduction of large scale computer
networks increased the demand for more hard- and software oriented stream ciphers which supported automated
communication.
Figure 2.5: Enigma
machine2
One of the most popular techniques in the sixties and seventies was the non-linear
binary sequence stream cipher [Gol67, Gro71, Key76, Ple77, DH79]. It produces a
binary keystream that allows a regular One-time Pad encryption without the requirement of a very large secret key. A typical cryptosystem based on a non-linear stream
cipher is illustrated in Figure 2.6. This type of ciphers was very popular because of
their small hardware footprint. Most of the proprietary ciphers that are assessed in
Part II are a derivative of the non-linear stream cipher.
shif t register
shif t register
f (·)
f (·)
plaintext
L
ciphertext
(a) Alice (sender)
ciphertext
L
plaintext
(b) Bob (receiver)
Figure 2.6: Typical non-linear stream cipher system
The cryptographic algorithm illustrated in Figure 2.6 embeds a rotating shift register, which represents the internal state of the cipher. After the computation of a new
keystream bit, the successor function updates the internal state by a linear function
to preserve as much entropy to the cipher. Then, the output component applies a
2 http://www.securityninja.co.uk/wp-content/uploads/2010/09/4-rotor-enigma-open-copy-BW.
jpg
27
non-linear filter function f (·) to compute the next keystream bit. The keystream bits
are used by the sender (Figure 2.6a) to encrypt the plaintext bits by combining both
bit strings with the exclusive-or (XOR) operation. The resulting ciphertext is transmitted over an insecure channel. The receiver (Figure 2.6b) performs the exact same
computations and applies another XOR operation, this time on the ciphertext bits in
combination with the keystream bits. The keystream bits, already embedded in the
ciphertext, are cancelled out and the original plaintext is revealed to the receiver.
The sender and the receiver use the non-linear stream cipher to compute exactly
the same keystream. Then, the sender combines the keystream with the plaintext to
produce the ciphertext by using the XOR operation. The receiver performs the same
technique on the ciphertext together with the keystream to reconstruct and reveal
the plaintext.
In most cryptosystems it is important to link multiple encrypted messages in one
cryptographic session, this is called chaining of encryption. Stream ciphers inherently
provide this feature since their ciphertext is produced incrementally. It uses the
previous internal state and a successor function to step forward.
Besides these historical stream cipher designs there are several new proposals in the
literature [AM97, EJ03b, DC06, HJM07]. Despite their advantages in flexibility and
speed, stream ciphers are currently scarcely used in secure systems that provide strong
cryptographic security. Typical stream cipher attacks aim to separate the plaintext
from the encryption bits. For instance, a malleability attack exploits a general and
unavoidable weakness in traditional stream ciphers where the keystream is generated
independently from the plaintext. Small alterations (bitflips) to the ciphertext might
be sufficient to perform the attack without actually recovering the secret key. More
details are given in Section 3.2.1.
The security that is provided by the underlying building blocks of stream ciphers
are well-studied. However, the security implications of these separate components
may not hold when they are combined and used together in one cryptographic algorithm. Instead, the comprehensive security implications of block ciphers are better
understood [BKL+ 07, Bir04]. The next Section 2.3.3 explains block cipher designs
and their (dis)advantages in more detail.
2.3.3
Block ciphers
A block cipher operates on data blocks of a fixed size, instead of on individual bits.
The size of the blocks are predetermined and defined in the cipher specification. The
length of the input data needs to meet the exact specified length. This often requires
padding of the input to align the data with the cipher input requirements.
A useful property of block ciphers is that the encryption output of block ciphers
heavily depends on the content of the data itself. The output changes almost completely when only one bit of the input is changed. This property makes it much harder
28
to correlate between encrypted messages that contain only slight differences in the
plaintext.
A disadvantage of block ciphers is that, by default, multiple encryptions are performed independently from each other. To maintain a linked cryptographic session
an additional method should be employed. Over the years, several techniques were
proposed in the literature to chain sequential block cipher encryptions. A well-known
example is the Cipher Block Chaining (CBC) method which can be used to cryptographically link encrypted data blocks. The chaining method was proposed in 1976
and patented by IBM [EMST78]. It is used in many block cipher cryptosystems. Although CBC encryption is useful for session confidentiality, it lacks session integrity
and is proven to be vulnerable to practical attacks [DR11].
In addition, alternative techniques were proposed that additionally provide
session authenticity, confidentiality and integrity. Well-known and widely deployed alternatives are Counter with CBC-MAC (CCM), proposed and evaluated
in [WHF02, Jon03], and Galois Counter Mode (GCM), introduced in [MV04]. Both
chaining methods are currently recommended by the National Institute of Standards
and Technology (NIST) in [Dwo04, Dwo07] and are used for many secure applications.
For instance, most wireless consumer networks, secured by Wi-Fi Protected Access
II (WPA2), depend on the Counter with CBC-MAC (CCM) technique which combines the Counter (CTR) chaining mode encryption together with a CBC-MAC to
provide both confidentiality, data integrity and authenticity. The second technique,
Galois Counter Mode encryption chaining, is used in various network and infrastructural security solutions such as Internet Protocol Security (IPsec), Secure Shell (SSH)
and Transport Layer Security (TLS).
Block ciphers are computationally more expensive than stream ciphers, yet
their security properties are better understood [BKL+ 07]. Furthermore, traditional block cipher encryptions (not keystream generation) suffer less from typical stream cipher weaknesses, such as the vulnerability to malleability attacks. In
fact, an interesting development in algorithm designs is the shift to more hybrid
cipher schemes [HCJ02, WFY+ 02]. Underneath those recently proposed stream cipher designs, there is actually a block cipher component that operate in chaining
mode [McG02, Bir04].
2.3.4
Hashes, MAC’s and Digital signatures
There exist cryptographic techniques that are not solely used for confidentiality. Wellknown examples are cryptographic hash functions, message authentication codes and
digital signatures.
A cryptographic hash function generates from an arbitrary length input bit string
(message) a collision resistant, very hard to forge, yet verifiable output bit string (digest) of a fixed length. It implements a One-Way Function (OWF), which suggests
an algorithm that is easy to compute and very hard to invert. There is a broad com-
29
munity of academics that study the properties of these mathematical functions. More
detailed information about the workings of hash functions and their cryptographic
strength is available in the literature [PGV94, PS96, CDMP05, WY05, MVOV10,
Ste13].
A Message Authentication Code (MAC) is a bit string that can only be computed with knowledge of a secret key and is transmitted alongside the plaintext or
encrypted message. Both parties, sender and receiver, have knowledge of the secret
key. Therefore, it can be used to verify the data integrity and authenticity of the corresponding message. MAC algorithms are often constructed from other cryptographic
primitives, such as a Hashed Message Authentication Code (HMAC) which utilizes
a cryptographic hash function [FIP08], or a Cipher-based Message Authentication
Code (CMAC) that is based on a symmetric key block cipher [Dwo05].
Digital signature also offer verification of data integrity and authenticity of a message. However, they differ from a MAC in the sense that they depend on asymmetric
cryptography which uses public and private keys, see 2.3.1 for more detail. The public key of the sender is often embedded into a certificate (chain) which is ultimately
signed by an authority that is known and trusted by the recipient. The receiver can
establish trust in the public key of the sender by verifying the certificate and signature
from the trusted party. After the verification of trust, the recipient can use the public
key to validate the signature over the corresponding message and establish confidence
about the data integrity and authenticity of the message.
2.4
Protocols and access conditions
Cryptographic algorithms are often used for confidentiality reasons. However, the
encryption and decryption functionality can be applied in a particular manner such
that it can be used to prove authenticity of one entity to another. This process is
defined in the authentication protocol of the cryptosystem and is further explained
in Section 2.4.1. A cryptosystem can embed various security levels with different
access conditions for each entity. The access conditions specify the acquired rights
and authorization of a certain entity. A further introduction to the details of an
authorization model is given in Section 2.4.2.
2.4.1
Authentication
A symmetric cryptographic algorithm is used to identify and authenticate two parties
to each other. This operation is specified in a so-called authentication protocol. An
authentication protocol consists of a set of predefined cryptographic operations which
describe the tasks of each party in proving their legitimacy to the other party without
revealing the secret key. It typically relies on a technique that is called cryptographic
challenge-response verification. First a random number is transmitted as challenge,
followed by a response which proves knowledge of the secret key. The response is
30
derived from the output of the cryptographic computation that uses the secret key and
challenge as Initialization Vector (IV). Legitimate parties can validate the response,
yet an adversary should not be able to derive any secret from a challenge-response
pair.
It is possible to simultaneously authenticate many parties to each other. However,
the scope of this section is limited to authentication protocols which are designed to
authenticate two parties to each other using symmetric cryptography. For explanatory
reasons it is useful to make a distinction between these parties. Therefore, we define
the first (initiating) party as Alice (A) and the second (responding) party as Bob
(B). To increase readability, this section presents rather conceptual versions of the
mentioned authentication protocols.
The first scheme is a limited authentication protocol, illustrated in Figure 2.7,
which performs a single authentication that only proves the legitimacy of one party.
Then, a basic mutual authentication is introduced where both parties prove their
legitimacy concurrently to each other, see Figure 2.8. Finally, a slightly more complex,
yet much more secure version of a mutual authentication protocol is presented in
Figure 2.9.
Alice (A)
Pick challenge A
Bob (B)
challenge A
response A
Compute response A
Verify response A
Figure 2.7: Two-pass single authentication protocol
In a single authentication, sometimes referred to as unilateral authentication, only
one side proves legitimacy to the other. Figure 2.7 shows an example where Bob
authenticates himself (proves who he is) to Alice using a simplified two-pass single
authentication protocol. In this scheme Bob proves his legitimacy by answering with
a cryptographic response to the challenge from Alice. Since only the legitimacy of Bob
is verified, an adversary could easily impersonate Alice and gather valid challengeresponse pairs. Such a set-up defines a typical form of an encryption oracle and is
further explored in Section 2.5.4.
To achieve bilateral trust it is more common to use a mutual authentication protocol. In this case both parties, Alice and Bob, prove concurrently that they are genuine
to each other. This is validated with verification of the responses, they should be outputs of a cryptographic computation which uses a secret key that only Alice and
Bob know. Figure 2.8 shows a two-pass mutual authentication protocol. It extends
31
the single authentication protocol with additional response which proves that Alice is
legitimate as well.
Alice (A)
Bob (B)
Pick challenge A
Compute proof A
challenge A, proof A
Verify proof A
response A
Compute response A
Verify response A
Figure 2.8: Two-pass mutual authentication protocol
Figure 2.9 presents a simplified three-pass mutual authentication scheme. After a
successful mutual authentication, Alice and Bob can trust each other and start a communication session. As mentioned in Section 2.3.2, it is common to cryptographically
chain all further communication to the original session authentication credentials. A
session should be initialized by unique (fresh) random challenges that contains a large
enough entropy to avoid predictable values or future collisions.
A more refined, yet slightly complexer, example of the three-pass mutual authentication protocol is standardized in ISO/IEC 9798-2 [ISO99]. Various improvements to this particular authentication scheme are proposed in the literature [FDW04, DDMP04, BCM12].
To strengthen an authentication protocol, there are ways to reduce the use of
the global shared secret in a symmetric cryptosystem. One example is to introduce
diversified cryptographic keys. A diversified key is a secret per entity that is derived
from a master secret in combination with the identification information of the involved
entity. In this way a different diversified key is generated for each entity. When such
an entity key is recovered, only this particular entity secret is compromised and not
the master secret.
2.4.2
Authorization
Authorization is sometimes confused with authentication. An authorized state represents an entity with a certain set of acquired rights, which are specified in a list of
access conditions. The authentication process can be used as the underlying verification method to reach an authorized state, yet its main objective is to identify and
authenticate the entity.
32
Alice (A)
Bob (B)
Pick challenge A
challenge A
Pick challenge B
Compute response A B
challenge B, response A B
Verify response A B
Compute response B A
response B A
Verify response B A
Figure 2.9: Three-pass mutual authentication protocol
The access conditions in a cryptosystem must be defined very strictly in an authorization model. Such a model includes a detailed specification of the access conditions
which are valid after proving ownership of a specific set of credentials. After successful
verification of the credentials a state transition takes place. The entity acquires the
rights specified in the access conditions of the authorization model.
Each state transition in an authorization model must be included in the predefined list of access conditions. Unspecified events could otherwise initiate states with
undefined (and potential harmful) behaviour. Furthermore, access to certain actions
should be restricted by default and only be allowed when the corresponding credentials are authenticated. In a smaller system such rules are easy to define. However,
the complexity of these definitions grows exponentially when more features and authentication methods are added. For instance, allowing different secret keys, remote
credential alterations such as key-updates or specific authorized operations like memory locking and data manipulation.
2.5
Weaknesses in symmetric cryptosystems
This section introduces eight different types of weaknesses in cryptosystems based on
symmetric cryptography. Starting with the cryptographic topics which embed weaknesses in cipher design, authentication protocol, cipher initialization and encryption
oracle. Followed by communication oriented weaknesses which occur in the authorization model and communication protocol. Finally, a description of weaknesses in
the implementation and deployment of a cryptosystem are given.
2.5.1
33
Cipher design
A secure cipher design should offer a high degree of computational complexity which
provides the necessary cryptographic strength as specified in Section 2.2.2. Such a
design should protect against any attack that could be mounted with fewer operations
than an exhaustive search over the full key space. In practice however, this is very
hard to achieve.
Serious weaknesses that compromise the computational complexity of a stream
cipher often thrive on insecure cipher designs. Their internal state often relies on
individual linear components that are in low cohesion with respect to the other cipher
components. The components are combined together with a complex non-linear filter
function f (·) to avoid a direct relation or partial correlation between the internal
state and the produced ciphertext. However, since these components often operate
independently from each other and only have modest direct influence on the produced
encryption bit, an adversary could guess only a few components and learn the value
of the other components by statistically inverting f (·). Although the purpose of a
non-linear function is to counter inversion, it might be possible to use techniques
like guess-and-determine to eliminate incorrect candidate internal states, for more
details on this subject see Section 3.2.4. A clear example of inverting the non-linear
cipher component is shown in Chapter 6 where a cryptanalytic attack is proposed
against the MIFARE Classic encryption to invert the algorithm. The cipher uses a
non-linear filter function, which is a specific component used in many stream ciphers,
see [Gol67, Gro71, Key76, Ple77, Kuh88, And91].
Another vulnerability in stream cipher designs is persistent and overlapping cipher
bits between internal successor states. Chapter 6 shows that such a weakness can
enable a very optimized way to invert the non-linear function. More specifically, each
second successor state overlaps with 19 of the 20 related input bits to the function.
This means that only one bit needs to be guessed for each elimination iteration. This
makes the computational complexity that is required to recover the secret key in
this example negligible. The details of such guess-and-determine-attack is further
explained in Section 3.2.4.
2.5.2
Authentication protocol
There are several symmetric authentication protocols proposed in the ISO/IEC 9798
standard[ISO99]. Some proprietary cryptosystems derived their authentication protocol from one of the standarized protocols. However, a slightly modified version could
greatly reduce the security strength of the authentication protocol.
The two-pass mutual authentication protocol presented in Figure 2.8 is vulnerable
to a replay attack. In this scheme both responses are derived from challenge A, which
was merely introduced by Alice. With only one authentication attempt from Alice,
consisting of a legitimate challenge-response pair, it is possible to impersonate Alice
34
and authenticate again with Bob without any knowledge of the secret key. A complete
example of such an attack is presented in Section 3.1.2.
The three-pass mutual authentication similar to the one illustrated in Figure 2.9
is generally a secure authentication solution. However, there are specific requirements
to avoid authentication vulnerabilities. The encrypted messages should be properly
chained to each other as described in Section 2.3.2. When not properly handled it
allows an adversary to mount a blocking (Section 3.1.6), injection (Section 3.1.5),
reflection (Section 3.1.4) attack.
A well-designed three-pass mutual authentication is by definition much more secure than a single or two-pass mutual authentication. However, some issues could
still undermine the security when not properly handled. A well-known example is the
way transmission timing restrictions are defined and enforced. When these are not
properly restrained, it allows an adversary to mount a relay attack, see Section 3.1.3
for more details.
An authentication protocol with serious weaknesses is embedded in the MIFARE
Classic cryptosystem that is described in Chapter 6. According to the specification,
the authentication protocol is compliant to the ISO/IEC 9798-2 standard [ISO99].
However, the random challenges were substituted by easy-to-predict values with very
low entropy. This modification undermines the protection against the reuse of authentication attempts. Attacks that exploit such a weakness are further described in
Section 3.1.2.
It is important to carefully select the function which is responsible for computing
a diversified key, which is introduced in Secion 2.4.1. For instance an algorithm which
is invertible allows an adversary to reconstruct the master key by simply deriving it
from the diversified key. This particular problem is the case in the iClass cryptosystem
which is introduced in Chapter 9. With only a limited computational complexity the
cryptosystem allows the adversary to recover the master key from the diversified key.
2.5.3
Cipher initialization
The initialization of the internal state in a stream cipher is a crucial part in terms of
its security. It should allow session-independent initialization of all the components
using the full entropy of random challenges. When internal state bits are persistent
between sessions, it allows an adversary to link these bits between various sessions and
thereby compromise its independency. Although a cipher could be secure in terms
of component design and ciphertext production, the extra dimension of linking the
internal states of multiple sessions could completely undermine the protection of the
cipher design.
Such a serious initialization weakness is identified in Chapter 7 for the Hitag2
cipher. It shows that one third of the internal cipher state is exactly the same after
each cipher initialization. The chapter demonstrates it is not very difficult to mount
a practical attack when such s weakness is present.
35
In an unfortunate case when a full or partial internal cipher state is recovered,
it fully depends on the cipher initialization if the process can be inverted to expose
the original secret key. When non-linear steps are involved in the computation of a
successor state, it might be so that it is not trivial to undo or roll-back the initialization. For example, when each cipher state has a second state that merges to the same
successor state, there must be two predecessor candidate states for each internal cipher state. In such a situation the number of possible candidates grows with a power
of two for each previous step. In practice, most ciphers limit such non-linearity in
the computation of the successor state. This is to avoid drastic reduction of possible
cipher states after computing several successors. Sometimes a balance can be struck
between those, for instance the CryptoMemory cipher introduced in Chapter 8 uses
modular addition to achieve controlled state merging.
2.5.4
Encryption oracle
Many proprietary cryptosystems provide the encryption functionality through a black
box interface. This allows the system to keep the cryptographic algorithm secret,
yet still available to encrypt user-defined plaintext. However, a cipher that allows
invocation of its encryption functionality can be used as an encryption oracle. It
allows encryptions of arbitrary plaintexts at the adversary’s request.
Especially in the case of a stream cipher this is a serious cryptographic weakness.
The produced keystream is computed independently from the plaintext and delivered
one bit at the time. Therefore, it allows a precise and controlled invocation of its
encryption functionality.
Chapter 7 describes the Hitag2 cryptosystem where an adversary, which has access
to genuine authentication attempts, can invoke the encryption functionality at will.
It allows influence over the cipher initialization process and exposes the encryption
oracle vulnerability to invoke and observe differences in the output. The exploit of
such vulnerability is called a differential attack, see Section 3.2.5 for more details on
this subject.
2.5.5
Authorization model
To compromise the authorization model, an adversary often tries to mount a privilege
escalation attack. It exploits a weak spot in the authorization model that allows
the adversary to perform an operation with no (or insufficient) credentials. It often
involves a carefully crafted path that exists of many operations combined in such a way
that the final state is undefined by the authorization model. Some systems show an
error or throw an exception without resetting the already achieved authorization. For
example, chapter 9 shows a situation where the adversary can access the key-update
functionality on a protected area. It first performs an authentication with default
credentials on a different non-initialized area and then forces a context change to the
protected area.
36
Some authorization models define a maximum number of failed authentications
and locks down when this number is exceeded. It restricts the initiating party to try
to learn from the receiver responses to the chosen authentication attempts. Such a
mitigation requires a solid and trustworthy communication channel. The usability of
such a system is affected when the system is locked when the failed authentications
were only triggered by a set of transmission errors. It would not be difficult for an
adversary to mount a Denial-of-Service (DOS) attack, see Section 3.1.6. By remotely
initiating a sequence of incorrect authentication attempts the receiver immediately
locks down any further legitimate access.
Chapter 8 describes a system where such a security mechanism is enabled. It is
remarkably easy to bypass the mitigation in this particular example. The decrementing counter that stores the count of failed authentications is only updated after the
authentication is checked. By observing the power traces of these chips it is possible
to detect if the counter is going to be written to, before it is actually stored. This
means that when disabling the power supply just before such a write is performed, it
is still possible to initiate unlimited authentication attempts.
Weaknesses in an authorization model are often difficult to detect automatically.
There are ways to examine a design automatically by exploring the state machine
of a system [Tre08]. However, in complex cryptosystems the combinations of inputs
could lead to a state explosion which exceeds the practicality of performing such a
test. A better alternative is to formalize the complete state machine and implement
it accordingly. This way the implemented state transitions are verifiable and provably
correspond to the original formalized design.
2.5.6
Communication protocol
To use and deploy a cryptosystem, it is necessary that the means of communication
are formally specified in a communication protocol. Such a protocol defines the physical requirements of the communication channel and the message specification. The
protocol features must be adjusted to the encryption techniques of the cryptosystem.
When a communication protocol is designed without taking the cryptographic properties into account, weaknesses could arise when they are plainly used together without
any adjustment to each other.
Chapter 7 shows that the communication protocol of Hitag2 allows adversaries to
extend a very small piece of a known plaintext with an unlimited set of redundant
messages. While such a feature adds support to the reliability of the communication
channel, it undermines the security of the cryptosystem by providing a remotely
operational encryption oracle. More details about attacks with an encryption oracle
are explained in Section 2.5.4.
Another technique that improves communication integrity is to send additional
verifiable information about the actual message content, which are called integrity
checks. Well-known examples are parity bits and Cyclic Redundancy Check (CRC)
37
checksums. These integrity checks contain redundant bits which summarize the content of the message. The message is communicated together with these integrity
checks, which allows the receiving party to verify (to some extent) if the received
message was delivered in the correct manner. When an anomaly is detected, the receiving party could immediately discard the message and request a re-transmission.
Such a technique greatly improves the integrity of the communication channel.
However, it is a complex task to combine integrity checks together with an encryption layer. For instance, it is convenient to wrap the encryption completely around
the communication protocol. This inherently adds information-leaking weaknesses to
the system [Kra01]. However, an adversary may not have any knowledge about the
plaintext, the integrity checks still educate the adversary about bit-dependencies in
the plaintext message. In some systems like Global System for Mobile Communications (GSM), the content bits are almost transmitted twice within one message.
Such redundancy allows an adversary to mount a ciphertext-only attack, since the
recovered secret key is just verifiable on the message structure without requiring any
knowledge of the plaintext itself.
There are several systems where parity bits are encrypted in an insecure way.
One of the most prominent examples is the MIFARE Classic cryptosystem described
in Chapter 6. It uses a stream cipher that produces a pseudo one-time-pad, see
Section 2.3.2 for more details. The messages of the system are encrypted with unique
bits from the one-time-pad. However, the parity bits are encrypted with the same
keystream bit that was already used to encrypt the previous bit. In short, the onetime-pad is used twice, which goes directly against the basic security principles of a
one-time-pad.
Adding encryption or integrity checks at a later stage is not just adding an additional layer that wraps around an existing communication protocol. The protocol
needs to be redesigned carefully by considering all security and integrity requirements.
2.5.7
Implementation
Apart from the complex design issues, the security of a cryptosystem strongly relies
on the way it is implemented. Only when the implementation strictly follows all facets
of the design specification could the target security strength could be achieved. Besides the design specification, the implementation should implement the best-practices
in secure software and hardware development. Examples of such are, input validation, verifiable formal function annotations, thorough inspection for state transitions
with undefined behaviour, extensive adversary model with attack trees and countermeasures against invasive hardware attacks.
A cryptographic algorithm or authentication protocol often relies on a specific
input format. When the cryptosystem allows arbitrary length messages or messages
with invalid and malicious content, it could lead to a cipher weakness and trigger
unexpected and security compromizing behaviour. An interesting example that uses
38
such a weakness is described in Chapter 6, where it is shown that the internal state
of the cipher can be updated using a malicious authentication message of arbitrary
length (shorter or longer).
The design of a cryptosystem can be very strong. However, when its implementation somehow leaks secret internal information to an adversary, the security of
the complete system is considered compromised. There are various weaknesses in
a hardware implementation that could lead to such information leakage. To avoid
such vulnerabilities, shielded and tamper resistant hardware can help in reducing the
leakage of side-channel information. More extensive information about (non)invasive
attacks is presented in Section 3.3.
2.5.8
Deployment
The system integrator that parametrizes, configures and deploys a cryptosystem has
to act very carefully and focus on a secure deployment. This requires special attention for secret key-management, quality of the pseudo-random number generator,
configuration that relates to access conditions and authorization, compiling a fall-back
scenario when security is compromised.
The key-management is of essence in a cryptosystem. A secret key should be a set
of randomly distributed bits (ones and zeros). There must be absolutely no relation
between different secret keys or any of the bits within these secret keys. In some
systems (part of) the secret key is derived from another value. This must be a secure
transition and produce a practically unique derivation. If such a derivation process
can be reverted or allows an adversary to link various secret keys to each other, the
security strength is affected. Some systems even specify a set of weak keys which
should be avoided at all costs. Several examples of widely deployed systems that use
weak keys are presented in Chapter 7.
Secure cryptographic challenges that are used by a cryptosystem highly depend
on uniformly distributed random numbers. Any prediction of the challenge or part of
it could lead to serious weaknesses in the corresponding authentication protocol. This
could allow easy-to-exploit replay attacks as described in Section 3.1.2. An example
of mounting such attack is shown in Chapter 7.
An inadequately configured cryptosystem could allow an adversary to gain access
to functionality or memory that was designed and intended to be inaccessible. A clear
example of such a weakness is shown in the Hitag2 cryptosystem described in Chapter 7, where incorrectly configured write-only flags could lead to serious authorization
weakness which allows an adversary to just read out the secret key.
Furthermore, a poorly designed communication protocol that defines the messages
between a cryptographically enabled device and an external system component can
completely undermine the comprehensive security of a system. For instance, the
cryptographic strength does not matter if the result of an authentication attempt is
transmitted as a boolean value (true or false) to the external component. It allows
39
an adversary to enforce a successful authentication by simply always transmitting a
true value.
A cryptosystem is often carefully designed to operate in a very secure way. However, it could happen that one of the cryptographic components is less secure than
originally specified. It has to be an integral part of the deployment process to define a
list of actions that specify migration steps and alternate solutions for each component
of the cryptosystem.
Chapter 3
Attack scenarios
An adversary can mount a variety of attacks on a cryptosystem. This chapter introduces a few elementary versions of the most common complex digital attack scenarios. There are several attack categories where each specifies an adversary with a
set of predefined capabilities. Certain attacks require only passive observation of the
communication channel, while other scenarios require complete control of the communication channel. To clarify the different type of attacks, each section refers to
concrete examples that were encountered in the course of this study.
This chapter contains three main attack categories. Section 3.1 first explores the
attacks an adversary could mount on the authentication protocol and communication
channel. Those attacks hardly depend on the cryptographic algorithm that is used,
as they exploit insecure protocols. Next, a set of fundamental cryptographic attack
techniques are explained in Section 3.2. Those are later used to greatly reduce the
computational complexity of the ciphers explained in Part II. Finally, it briefly addresses the possibilities, impact and severity of hardware attacks. The latter shows
that even when the authentication protocol and cryptographic algorithm are secure,
a cryptosystem still might be compromised because of weaknesses in its hardware
implementation.
3.1
Authentication and communication attacks
This section addresses six attack scenarios that compromise the authentication protocol and communication channel. The first two attacks do not alter the communication
itself. The adversary just passively observes or actively forwards all original messages.
This is followed by four attacks that deliberately violate the transmission integrity by
retransmitting, reflecting, injecting or blocking messages.
To illustrate the attacks, the paragraphs include message sequence charts which
elucidate the applicability and severity of the attacks. In addition to Alice and Bob
a new communicating entity is introduced: the adversary named Eve. It is assumed
that she takes control of the communication channel that exists between Alice and
Bob. Control of this channel allows her to mount all attacks mentioned in this section. For each attach, the specific actions that Eve has to take are mentioned in the
corresponding message sequence chart.
42
3.1.1
Attack scenarios
Passive eavesdropping
One of the most simple, yet effective ways to learn information about a cryptosystem is
to observe and record the communicated messages. Such a gathering of data is called
passive eavesdropping and the data that is recorded is referred to as a trace. The
right hardware tools enable intercepting of the communicated ones and zeros. This
does not immediately imply that a cryptosystem is broken when the communication
is recorded. Contrarily, a good cryptosystem is mainly designed to defend against
such an intruder. The messages should be encrypted in such a way that there is no
way for an adversary to distinguish the trace from random noise.
Severe weaknesses in the cipher, authentication or communication protocol allow
an adversary to compromise the security of the complete cryptosystem. There are
numerous examples which show that an attack can be mounted with only passively
eavesdropped communication traces. However, this often requires very serious weaknesses in the cryptography or an extremely large set of traces. The practicality of
an attack that requires many traces drops significantly when they have to be eavesdropped from a remote cryptosystem. Nevertheless, a well-cited publication [SIR02]
showed in 2002 that it is not so difficult to recover the secret key from a wireless
network system by using only passive eavesdropping. This would take between four
and six million packets. Considering the activity of the users and the network load,
it could very well take up to a month to gather the required packets.
In practice it is very difficult to defend against a passive eavesdropper in terms of
avoiding it. In a wired system, the electrical signals and load of observers could be
monitored. However, a malicious entity that only receives wireless communication is
almost infeasible to detect. For instance, a third party (e.g. the adversary) can silently
decode the same Radio Frequency (RF) signals that are transmitted. Therefore, it is
wise to assume that in a wireless set-up the messages can be intercepted by a malicious
party at all times.
There are many secure systems that are resilient against passive eavesdroppers. In
such a system, an adversary may gather all the communicated messaged, yet gain no
advantage in learning them. To achieve this, the systems must rely on a secure combination of a strong cryptographic algorithm (Section 2.2.3), formalized and proven
authentication protocol (Section 2.4.1), a well-designed communication protocol (Section 2.5.6) and a correct and well-protected implementation (Section 2.5.7).
3.1.2
Relay attack
A relay attack is a kind of man-in-the-middle attack, where an adversary only forwards
the communicated messages both ways. The goal of such an attack is to transparently
relay the messages between an initiator and the device of a victim to unknowingly
initiate a (different) communication channel. An adversary could use a relay attack to
significantly increase the communication distance and thereby change the properties of
the original communication channel. An access control system that is designed to work
Attack scenarios
43
in proximity distance does not necessarily provide the same security properties when
it is available from a larger distance. Even when the used encryption is strong enough
to resist cryptography attacks, the lack of physical distance boundaries could still
compromise the security of the system as a whole. For instance, some access control
systems allow authentication signals to be relayed undetectably over a larger distance.
A relay attack breaks their security features without requiring any knowledge of the
used cryptography or authentication protocol. The concept of a relay attack was
introduced decades ago in [DGB88], when radio transceivers like cell phones were not
so common to use. The authors explained the concept with a practical example that
involves collaborating criminals that use a Mafia-owned restaurant. Therefore, they
introduced a fitting name and referred to such an attack with the term Mafia fraud.
The original transmission is intercepted at the side of the sender and transparently mirrored at the side of the receiver. To achieve this, two adversaries (Eve1 and
Eve2 ) are required. They both use a specific hardware set-up which enables them
to communicate with the genuine parties (Alice and Bob). Furthermore, the adversaries need on both sides a wireless transceiver which provides a fast and reliable
bidirectional communication channel with each other. The transceiver acts as a relay
station, which simply forwards the communication between Alice and Bob. Figure 3.1
shows a schematic overview of a relay attack that is mounted on the three-pass mutual
authentication protocol which was introduced in Section 2.4.1.
Alice (A)
Eve1
Bob (B)
Eve2
Pick challenge A
challenge A
Relay
challenge A
Pick challenge B
Compute response A B
Relay
Verify response A B
Compute response B A
response B A
Relay
response B A
Verify response B A
Figure 3.1: Replay attack on a three-pass mutual authentication protocol
A relay station might consist of simple consumer hardware that supports wireless
¸ A+ 04, FHMM10,
communication, like cell-phones or laptops with wifi-networks [LC
FHMM11]. However, most communication protocols require a robust hardware set-up
which achieves fast and reliable communication. Several practical implementations
are proposed in the literature that rely on optimized and dedicated embedded hard-
44
Attack scenarios
ware [KW05, Han05, KW06, HMM09, FDv11].
Figure 3.2 illustrates a practical relay attack [VdKGG12] that is performed on an
access control system that requires authentication with an Near Field Communication
(NFC) contactless smartcard. The adversary emulates such a smartcard at the access
control gate which receives the instructions that need to be relayed to the genuine
smartcard. On the other side, a second adversary impersonates with a malicious
NFC reader the access control gate and interrogates the genuine smartcard with the
relayed instructions. The relay stations in the middle transmit the signals over a
larger distance to vastly extend the original proximity communication range. More
detailed information about the mentioned technologies are available in Section 5.1.4
and Section 5.1.3.
Figure 3.2: Relay attack on an access control system that uses an NFC smart card
In an advanced relay attack the complete communication is remotely reproduced.
This includes the complete messages, header bits, similar modulation and encoding
techniques, signal strength, angle of emission and other physically detectable properties of the transmission. In theory, there is only the time that elapsed between
two transmissions that cannot be reproduced. This follows from the assumption that
information cannot travel at a speed greater than the speed of light [HK05].
In practice however, is it very hard to measure this with the required accuracy and
detect relayed transmissions. This is especially the case when a transmission between
the relay stations completes within a smaller time-frame than it takes to transmit
the original data bits. For example, when the period of the original transmission
carrier wave takes more time than needed to relay the data bits. Such a set-up could
be easily achieved by using a substantially higher transmission frequency between
the relay stations. A well-known example in the literature [FDv11] demonstrates a
practical relay attack on Passive Keyless Entry and Start (PKES) systems, which are
embedded into most modern vehicles. The study shows that it is feasible to relay
the signal within nanoseconds, while the original transmission takes at least a few
microseconds per bit that is communicated. The accuracy of the receiving hardware
in cars is unfit to detect a transmission delay of only a few nanoseconds.
Attack scenarios
45
In response to these kinds of attacks, several mitigating measures were proposed
in the literature [BC94, HK05, KAK+ 09, KA09, Rv10]. The common ground of these
publications is the extension of the authentication protocol that keeps track of the
communication timings. Such schemes are referred to as distance bounding protocols,
a term which was introduced by [BC94] in the early nineties.
3.1.3
Replay attack
One of the most basic attacks that an adversary can mount on a vulnerable cryptosystem is a replay attack. In such an attack, the adversary reuses ciphertext, recorded
from an early eavesdropped session, and replays (retransmits) it to the cryptosystem.
Protection against replay attacks is a very elementary requirement for a secure cryptosystem. The security of a system is seriously compromised when a replayed message
is not properly handled. For instance, when there is no counter-measure in the authentication protocol that protects against replay attacks, it allows (re)authentication
with the previous intercepted credentials as shown in Figure 3.3.
Alice (A)
Eve (E)
Bob (B)
Pick challenge A
Compute proof A
Eavesdrop
Verify proof A
Compute response A
response A
Eavesdrop
response A
Verify response A
Replay
Verify proof A
response A
Compute response A
Figure 3.3: Replay attack on a two-pass mutual authentication protocol
The first authentication protocol, presented in Section 2.4.1, is vulnerable to a
replay attack on Bob by an adversary that impersonates Alice and replays the same
challenge A which Alice used to authenticate before. This problem is mainly introduced by the fact that Bob does not send a challenge to Alice. Therefore, the
cryptographic session that is created after authentication is not unique. It needs to
be properly randomized by both parties every time they negotiate for a new authentication. Figure 3.3 shows a replay attack performed on the two-pass mutual authen-
46
Attack scenarios
tication protocol that was introduced in Section 2.4.1. The adversary Eve eavesdrops
the first message that was transmitted by Alice and uses it later to re-authenticate
with Bob. Notice that Eve did not learn the secret key and therefore cannot verify
the response A from Bob. However, assuming this message was valid, by using the
same challenge, Eve can perform a successful authentication with Bob at any moment
in time.
Several decades ago, various mitigation techniques were proposed in the literature
to protect against replay attacks [FNS75, Ken77, PK79, Den82, BBF83]. However,
there are numerous examples of cryptosystems introduced after this discussion that
are still vulnerable. Chapters 7, 8 and 9 show the workings of widely-used cryptosystems that contain serious weaknesses which allow an adversary to mount various
replay attacks.
3.1.4
Reflection attack
The parties in a symmetric authentication protocol prove their legitimacy to each
other sequentially. However, the proofs are computed independently from each other,
using the two-pass single authentication protocol from Figure 2.7 twice to validate
both sides. In such a protocol the challenge-response pairs from Alice to Bob are
computed in exactly in the same way as those from Bob to Alice. Because both
proofs are computed from each other independently, it allows an adversary to mount
a reflection attack as shown in Figure 3.4.
Alice (A)
Bob (B)
challenge A
response A
challenge B
response B
Alice (A)
Eve (E)
Alice (A)
challenge A
challenge A
response A
response A
Figure 3.4: Left: Using twice a two-pass single authentication protocol
Right: Reflection attack by redirecting challenge A back to Alice
In the reflection attack that is illustrated in Figure 3.4, the adversary Eve redirects
(reflects) the challenge A, which Alice picked as a challenge, back to Alice in another
communication channel. When Alice responds to the challenge in the second channel,
it is used by Eve to prove legitimacy to Alice in the first channel. Since Eve is
fully authenticated in the first communication channel, the second channel can be
disregarded. A reflection attack does not require knowledge about the secret key or
the cryptography that is used. It exploits a weakness in the authentication protocol,
as shown in Figure 3.4, which does not include countermeasures against reflection
attacks. Examples of these countermeasures are the use of cryptographically linked
Attack scenarios
47
messages as mentioned in Section 2.3.3 or the inclusion of the sender’s identity in each
communicated message.
3.1.5
Reorder and inject messages
The communication flow of the session can be compromised when it does not properly
chain the messages and lacks integrity checks that verify the complete transmission.
The adversary tries to tamper with the communication without directly attacking
the cryptography itself. This can particularly be a problem for cryptosystems that
use block ciphers, since they do not inherently keep track of the previous encryption
state, see Section 2.3.3 for more details. The technique explained in Section 2.3.4
can be used to add integrity checks within a message itself. This should keep the
adversary from forging new messages. However, it does not guarantee that a message
with correct integrity is refused when it is reused in the same cryptographic session.
Such a reuse is commonly referred to as an injection attack.
A session that contains messages which are encrypted without cryptographic
chaining allows an adversary to reorder, reuse and sometimes even combine multiple messages. Such a cryptosystem allows an adversary to inject messages into the
communication channel because it has no way to invalidate them. Figure 3.5 demonstrates an attack performed by Eve to increase the funds of Bob by simply reordering
and injecting earlier transmitted messages by Alice.
Alice (A)
Eve (E)
Bob (B)
Succesful authentication
Encrypted(increase funds)
Encrypted(with 10 units)
Eavesdrop
Encrypted(decrease funds)
Eavesdrop
Reorder and inject
Disconnect
Figure 3.5: Injection attack on a protocol without proper session integrity checks
The protocol used in Figure 3.5 to increase the funds does not use any cryptographic means to ensure the session integrity. In this example the Authentication and
Key Agreement (AKA) protocol is assumed to be secure and communication after the
secret agreement is fully encrypted. However, the communication protocol contains
48
Attack scenarios
no counter-measures against adversaries that replay encrypted messages after successful authentication. Since it lacks cryptographic chaining or other measures that
ensure session integrity, Eve is allowed to refund Bob without the necessity to break
the encryption.
The iClass access control system presented in Chapter 9 contains a comparable
integrity vulnerability. However, the integrity issues arise from unchained cryptographic messages, which are stored in memory instead of being communicated. The
weakness allows an adversary to inject and interchange memory blocks within the
smart card memory itself after a successful authentication between the genuine devices. Similarly, such an attack can be mounted without any knowledge of the secret
key. The memory is encrypted by a secure block cipher, albeit without proper cryptographic chaining. This issue, in combination with several other weaknesses, presented
in the literature [Mer10, GdKGV11, GdKGVM12, KJL+ 13], allows an adversary to
compromise the security of the system. In contrast, a well-designed cryptosystem
ensures the integrity of individual messages and the whole cryptographic session, see
Section 2.3.2 and Section 2.4.1 for more details.
3.1.6
Block the communication
As introduced in Section 1.1, availability is one of they key features of a secure cryptosystem. Solid reliability of a system preserves the continuity and usability. To subvert
such reliability an adversary may choose to block all communication. Additionally, to
alter the workings of a system an adversary might block only certain messages. The
example illustrated in Figure 3.6 shows that Eve blocks the second pair of messages,
which alters the communication flow to her advantage.
Alice (A)
Eve (E)
Bob (B)
Succesful authentication
Eavesdrop
Block
Disconnect
Figure 3.6: Blocking attack on the second part of the communication
The most simple form of a communication blocking attack is a complete Denialof-Service (DOS) attack. In such an attack all the communication is blocked and
remote access to the cryptosystem becomes completely unavailable. Unregulated and
Attack scenarios
49
professionally organized attacks on high-profile services at large institutions like electronic banking, infrastructural control centres and governmental portals have rapidly
increased over the last years [SKK+ 97, WS02, MDDR04, MSB+ 06, CKBR06].
Many DOS attacks simply try to make a service unavailable, which could be motivated by several reasons such as manifesting intentional reputation damage or to
blackmail the owner of the service. It differs from the previously described attacks
which mainly focus on security breaches to gain access to protected information.
There are, however, a few clever blocking attacks which also try to compromise the authentication or communication protocol. Although these attacks seem to be mounted
much less in the wild, a protocol that is vulnerable to it might be compromised in
many ways. For example, a transaction can be interrupted just before a crucial action
is performed or certain remote instructions are filtered out to avoid the decrement of
purchased credits like shown in Figure 3.6.
3.2
Cryptographic attacks
This section introduces seven fundamental cryptanalytic techniques which are used
in cryptographic attacks, also referred to as cryptanalysis. There are many more advanced and complex cryptographic attack methodologies and techniques proposed in
the literature [DM95, DKR97, BDL97, BS97, Wag99, KSW99, BW99, DS09, BKR11].
However, to maintain readability, only very rudimentary versions of the fundamental
techniques are introduced. The type of cryptosystem that is mainly used to demonstrate the attack techniques is a variant of the non-linear stream cipher system, introduced in Section 2.3.2.
To mount a cryptographic attack, it sometimes requires significant computational
effort to recover the secret key. The computing power that is required reflects the
attack complexity, see Section 2.2.2. It is possible to generalize the computations that
are required for a cryptographic attack in such a way that they can be (partially)
pre-computed. Such technique is commonly referred to as Time-Memory Trade-Off
(TMTO). The general idea is to split a cryptographic attack into two phases, a precomputation phase (off-line) and active attack phase (on-line). For more information
on this topic, please refer to the TMTO methods and efficient search techniques
proposed in the literature [Hel80, AH88, FN91, Bab95, BPVV98, VOW99, BS00,
Oec03, BBS06, BMS06, AJO08, HM13, vdBP13].
Most cryptographic algorithms described in Part II, i.e. the technical part of this
study, are variations of similar stream ciphers. The introduced attack techniques are
utilized in Part II to exploit various cipher weaknesses. It shows that the cryptographic strength of those cryptosystems is far from what was initially assumed.
50
Attack scenarios
3.2.1
Malleability attack
The specifics of a synchronous stream cipher that produces a non-linear binary sequence are explained in Section 2.3.2. It shows an illustration of a typical cryptosystem that uses such a cipher. The generated binary sequence serves as the keystream
and is combined with the plaintext by applying the exclusive-or (XOR) operator.
Such a cryptosystem could in principle provide a secure channel which protects the
confidentiality of the data transmission. However, without further protection, the
integrity of the data is not guaranteed. Additional countermeasures, such as a Message Authentication Code (MAC), can protect the authenticity of the data. Without
supplementary cryptographic techniques a stream cipher system is vulnerable to a
malleability attack.
During a malleability attack the ciphertext is transformed in such a way that it still
decrypts to bona fide plaintext, yet satisfies the attacker’s purpose. Note, that the goal
of a malleability attack is not to recover the secret key. In fact, it tries to undermine
the security of the cryptosystem without having any knowledge of the secret key.
Figure 3.7 demonstrates a data transmission tampering of a banking application that
is vulnerable to a malleability attack. A fairly small money transfer is altered by
a single bit-flip and suddenly represents a very large money transfer. Even if the
keystream is produced by an extremely secure stream cipher, other components of the
cryptosystem might still be vulnerable. It is the strength of the entire cryptosystem
that defines the actual security.
ciphertext = 0011 1100 0011
tampering = 1
⊕
ciphertext′ = 1011 1100 0011
Eve (adversary)
amount(100) = 0000 0110 0100
keystream = 0011 1010 0111 ⊕
ciphertext = 0011 1100 0011
ciphertext′ = 1011 1100 0011
keystream = 0011 1010 0111 ⊕
amount(2148) = 1000 0110 0100
Alice (sender)
Bob (receiver)
Figure 3.7: Malleability attack alters the value of a money transfer
Although a malleability attack appears to be powerful, it is not that straightforward to mount. The adversary needs to know exactly where and when the amount is
transmitted to be able to tamper with it. A bit-flip at an incorrect position is meaningless and will most likely result in a corrupted transmission. Knowledge about the
keystream allows an adversary to prepare more carefully crafted tampering. However,
this involves reuse of the keystream, a situation which a stream cipher should avoid
at all costs. As Section 2.3.2 states, it is important that the binary sequence is used
Attack scenarios
51
only once. To enforce this, the internal state should be initialized with a unique value
each time the stream cipher is used. For instance, such a value can be derived from
a secret key in combination with fresh random challenges. Section 2.4.1 shows the
exchange process of random challenges during the authentication phase.
A secure exchange of fresh random challenges and a protected Initialization Vector (IV) of the cipher is not a trivial task [BG07]. In fact, several proprietary stream
ciphers allow an adversary to influence the initialization of the internal state in such
a way that exactly the same keystream is produced as it was generated in a previous
session. A comprehensive, yet practical, example of a stream cipher malleability attack is given in [dKGHG08]. It shows how the cryptosystem, introduced in Chapter 6,
is exploited in such a way that the contents of a protected smartcard can be revealed
even without any knowledge of the secret key.
3.2.2
Divide-and-conquer attack
A very powerful way to reduce the complexity of a computation is to divide one big
problem into two separate small problems, often referred to as divide-and-conquer.
It is used in various fields within computer science to optimize the solving of hard
computational problems [BS76, Ben80, Dwy87, ACG89]. Its main purpose to reduce computational complexity and generic applicability makes this technique ideally
suitable to attack certain types of cryptosystems [DC94].
As mentioned in Section 2.2.2, a cryptographically secure cipher with a secret
key of significant length, for instance 80 bits, takes a lot of time and resources to
solve. Dividing the exhaustive search to find the secret key for such a cryptosystem
would not reduce the complexity itself. It only allows the adversary to parallelize two
searches, each of exactly half the complexity of the main problem 279 . However, when
the adversary finds a way to divide the big problem into two smaller problems, the
complexity is significantly reduced.
The cipher schematic, illustrated in FigCipher 1
ure 3.8, is used to demonstrate how to
mount a divide-and-conquer an attack. The
k0 k1 k2 k3 k4 k5 k6 k7
8-bit secret key k = k0 . . . k7 ∈ F82 is loaded
c
b
into the internal state during initialization.
a
d
Each encryption round the internal state rof (a, b, c, d)
tates one step to the left after producing a
keystream bit as output. The key space of
keystream
the cipher that consists of only 28 = 256
Figure 3.8: Divide-and-conquer cipher
keys and keystream repeats itself after eight
rotations. Therefore, this algorithm should be considered extremely insecure. However, its simplicity suits its purpose to demonstrate a divide-and-conquer attack.
The eight squares in Figure 3.8 represent the rotate register of the internal state.
It is loaded with the ones and zeros of the secret key during initialization. The f (·)
52
Attack scenarios
component is a non-linear function which uses 4 input bits (arrows from above) and
produces 1 output bit, which is referred to as keystream ks. The keystream bits are
defined by ksi where i represents the number of performed cipher rotations.
Consider the first three encryption rounds as illustrated in Figure 3.9. The input to
the f (·) function is different for the first three keystream bits ks0 , ks1 and ks2 . However, the secret key bits required to produce ks0 and ks2 are the same, although they
differ in order. To be precise, the first keystream bit is given by ks0 = f (k0 , k2 , k4 , k6 )
and the third keystream bit by ks2 = f (k2 , k4 , k6 , k0 ).
k0 k1 k2 k3 k4 k5 k6 k7
k1 k2 k3 k4 k5 k6 k7 k0
k2 k3 k4 k5 k6 k7 k0 k1
f (k0 , k2 , k4 , k6 )
f (k1 , k3 , k5 , k7 )
f (k2 , k4 , k6 , k0 )
ks0
ks1
ks2
Figure 3.9: Computation of the first three encryption rounds and
the derivation of ks0 , ks1 and ks2
The odd and even patterns in the keystream are properties of this particular
divide-and-conquer cipher. Only the even key bits k0 , k2 , k4 and k6 are required to
compute the even keystream bits ksx where x ∈ 2N defines the even positions, while
only the odd key bits k1 , k3 , k5 and k7 are used to compute the odd keystream bits
ksy where y ∈ 2N + 1 defines the odd positions.
Cipher 1 was designed as one big algorithm, but it can easily be divided into
smaller algorithms. Figure 3.10 demonstrates how to divide the cipher, both having
a key-size of exactly half compared to the original cipher.
k0 k1 k2 k3 k4 k5 k6 k7
b
a
c
f (a, b, c, d)
d
keystream = ks0 ks1 ks2 . . .
k0 k2 k4 k6
a
b
c
d
f (a, b, c, d)
k1 k3 k5 k7
a
b
c
d
f (a, b, c, d)
(a) Cipher for even keystream bits
(b) Cipher for odd keystream bits
Figure 3.10: Divide-and-conquer attack by dividing odd and even keystream bits
With only half of the internal cipher state, the computational complexity for
Attack scenarios
53
the odd and even cipher drops to 24 . Consequently, the total complexity for both
together is reduced to only 2 × 24 = 25 = 32, which is considerably less than the
initial computational complexity of 28 = 256. Note, that a divide-and-conquer attack
does not just halve the entropy of the key space. Such division would only yield a
8
relative small complexity reduction of 22 = 27 = 128. It is far more powerful to
separate the cipher into two smaller algorithms which rely on two independent secret
keys, where the two keys represent both halves of the original secret key.
3.2.3
Correlation attack
The cipher weakness that allows a correlation attack is a statically biased encryption
output that is highly-influenced by certain internal state bits which are used as input.
Therefore, a guess for these input bits would most likely directly influence the output
bits. With the use of statistical analysis the adversary can learn information about
these internal state bits.
The advantage of a correlation attack is that the adversary can significantly shrink
the set of likely secret key candidates. The stronger the bias, the more information is
leaked when analyzing the input and output relations. Stream ciphers in particular
are often susceptible to correlation attacks. There have been numerous proposals in
the literature to define fast and optimized stream cipher correlation attacks [MS88,
MS89, CS91, CCCS92, MDO94, And95, CGD96, Pen96, JJ00, CJS01, JJ02, Cou03b].
In the case of a stream cipher, a correlation attack technique is often applicable
on multiple sequential encryption outputs. After a successor state is reached within
a stream cipher, several previously chosen bits might overlap with the input to the
next encryption. Furthermore, the bias is verifiable on every produced output, which
allows an adversary to correlate previous and successor states. The combination of
multiple biased encryption outputs leads to more information of the complete internal
state. The set with the most probable candidates is likely to contain the internal state
that is derived from the correct secret key.
To explain the basic correlation attack [Sie84, Sie85], a vulnerable stream cipher is
introduced in Figure 3.11. Cipher 2 is a simple rotating stream cipher with an output
component that relies on the non-linear filter function f (·). To increase readability
the function definition is also given in the corresponding component of the figure.
Cipher 2
k0 k1 k2 k3 k4 k5 k6 k7 k8 k9 k10
a
b
k11 k12 k13 k14 k15
c
d
f (a, b, c, d) = ((a ∧ b ∧ c) ∨ (a ∧ b ∧ c)) ⊕ d
Figure 3.11: Stream cipher with correlation weakness, initialized by secret key k
54
Attack scenarios
The cipher illustrated in Figure 3.11 is similar to the cipher introduced in Section 3.2.2 in terms of computing its successor and the way it produces encryption
bits. However, it consists of two separate rotating registers and has a larger internal
state that is initialized by 16 secret key bits. Furthermore, it does not suffer from the
same weakness that allows separation between odd and even bits output. Instead, it
employs a non-linear filter function which generates output that is statistically biased
in correlation to the input. The function f (·) is given by Definition 3.2.1.
Definition 3.2.1. Define the statistically biased non-linear filter function f : F42 → F2
as
f (a, b, c, d) = ((a ∧ b ∧ c) ∨ (a ∧ b ∧ c)) ⊕ d
The filter function takes four input bits (a, b, c and d) and produces one output bit
by evaluating the specified non-linear equation. The boolean table which represents
the input-ouput relation of f (·) is illustrated in Figure 3.12.
abcd
0000
0001
0010
0011
f (a, b, c, d)
1
0
0
1
abcd
0100
0101
0110
0111
f (a, b, c, d)
0
1
0
1
abcd
1000
1001
1010
1011
f (a, b, c, d)
0
1
0
1
abcd
1100
1101
1110
1111
f (a, b, c, d)
0
1
1
0
Figure 3.12: Boolean input-ouput table that corresponds to Definition 3.2.1
The bias of the function is easily determined by looking at its input-output relation
showed in Figure 3.12. Although f (·) produces a balanced output, which means that
half of the produced output bits are zero and half of them are one, input bit d has
significantly more influence on the output than the input bits a, b and c. Note the
four marked rows in the input-output table illustrated in Figure 3.12 which point out
where the input bits abc are equal to each other.
In 12 out of the 16 inputs for abcd, the output bit ks is exactly the same as
the input bit d. Therefore, it is valid to conclude that on average with randomly
distributed input bits, in 43 of the cases ks = d, while only in 41 of the cases ks 6= d.
This property makes the second rotation register much more influential to the value
of the produced keystream bits.
Assume an adversary recovers the first keystream bit ks0 . She knows that ks0
was computed by the function f (·) with the arguments f (k3 , k7 , k10 , k12 ). Therefore,
she can determine with probability 34 the correct value for input d, which is for ks0
the thirteenth secret key bit k12 . Although this reduces the set of likely candidate
keys significantly, the power of a correlation attack is best demonstrated when it is
applied multiple consecutive times.
Subsequently, consider a set of 16 contiguous keystream bits ks0 ks1 . . .ks15 . The
secret key bits k3 k7 k10 k12 are used to compute ks0 . Likewise, after five rotations the
second register is completely rotated and the secret key bits k8 k1 k4 k12 are used for
Attack scenarios
55
ks5 . According to Definition 3.2.1, the fourth bit d is the most influential input bit.
For both cases, ks1 and ks5 , the fourth input bit to f (·) is the secret key bit k12 .
Let us combine the probability that 41 of the time k12 6= ks0 and that also 41 of the
time k12 6= ks5 . If ks0 = ks5 , the adversary can assume that the average probability
1
of ks0 = ks5 6= k12 significantly drops to 14 × 41 = 16
. This is because it is highly
unlikely that in both cases the (independent) input bits a, b and c are equal to each
other. A correlation attack that focusses on a combination of keystream bits provides
a much greater advantage. The probability of a correct key-bit guess can be derived
from the product of all probabilities that correspond to an independent verifiable
statistical bias in the cipher.
The correlation attack, mounted on the output ks0 and ks5 , is also valid for many
more bits from the recovered keystream set. For every pair of keystream bits which
are five positions apart (ksi = ksi+5 where i ∈ {0, . . . , 10}), the average probability
15
.
that they are exactly the same as the corresponding bit from the secret key is 16
The properties of this cipher allow an even better (but a more complex) correlation
attack. However, the purpose of the previous description is to present a simple and
explanatory example.
Chapter 8 introduces a widely deployed cipher that is vulnerable to a correlation attack. It shows how to recover the secret key using a statistical bias in the
output bits selection function that is part of the cryptographic algorithm. Although
it is slightly different from the example presented here, the attack also exploits a
correlation weakness to learn information about the internal state bits.
3.2.4
Guess-and-determine attack
Despite several well-known historical recommendations in the literature [Kuh88,
And91, Gol96], many proprietary stream ciphers do not use their complete internal state to compute a keystream bit. Such cipher design allows an adversary to
mount a guess-and-determine attack. This attack abuses the fact that only a few
internal state bits are defined as input to the filter function. Therefore, only these
bits determine the value of the computed keystream bit.
To mount such an attack, an adversary only guesses used bits, computes the output
and evaluates it against the corresponding keystream bit that was recovered from an
eavesdropped trace. The evaluation immediately leads to a contradiction for many
of the guessed candidates. After evaluation, the internal state is updated accordingly
and only additional required bits are guessed.
There are several impressive, yet slightly complex, examples in the literature [HR00, HR03, GM04, ZF06, Bog07a, Pas09, FLZ+ 10] that show the feasibility of guess-and-determine attacks on various cryptographic algorithms. To avoid
the details of complex and optimized techniques another elementary stream cipher is
introduced, see illustration in Figure 3.13.
56
Attack scenarios
Cipher 3
k0 k1 k2 k3 k4 k5 k6 k7 k8 k9 k10
b
a
k11 k12 k13 k14 k15
c
d
f (a, b, c, d) = (a ∧ b) ⊕ c ⊕ d
Figure 3.13: Non-linear stream cipher, initialized by secret key k
Cipher 3, illustrated in Figure 3.13, is a clear example of a stream cipher that
is vulnerable to a guess-and-determine attack. The output component embeds a
balanced non-linear filter function which is given by Definition 3.2.2.
Definition 3.2.2. Redefine the filter function f : F42 → F2 as
f (a, b, c, d) = (a ∧ b) ⊕ c ⊕ d
The boolean table that represents the input-ouput relation of f (·) from Definition 3.2.2 is shown in Figure 3.14. Note, that c and d have always influence on the
computed keystream bit, while the influence of a and b depend on one each other.
abcd
0000
0001
0010
0011
f (a, b, c, d)
1
0
0
1
abcd
0100
0101
0110
0111
f (a, b, c, d)
0
1
1
0
abcd
1000
1001
1010
1011
f (a, b, c, d)
1
0
0
1
abcd
1100
1101
1110
1111
f (a, b, c, d)
1
0
0
1
Figure 3.14: Boolean input-ouput table that corresponds to Definition 3.2.2
The adversary searches for a weakness in the cipher state transitions that allows
a guess-and-determine attack. She starts by examining the corresponding cipher
structure and the specified input bits which are required to compute the non-linear
function. As mentioned in Section 3.2.3, the cipher illustrated in Figure 3.11 enables
the adversary to guess only a few bits of secret key per computed output.
The cipher requires only four inputs bits at a time to compute one keystream bit.
The 16 bit long secret key initializes an internal state. Therefore, the internal state
has an entropy of 16 bits. Nevertheless, if only four bits of the internal state are
used each time to compute a keystream bit, it makes no sense to increase complexity
and guess all the bits at once. Especially, when the guessed values are not used to
compute the next output bit. The power of a guess-and-determine attack rests itself
in guessing each time only the bits that are actually used and make sure their output
do not contradict with the keystream.
An adversary can easily perform an exhaustive-search over all 16 different input
bits abcd which are shown in Figure 3.14. Next, she computes the result for each
Attack scenarios
57
f (a, b, c, d) and tests the output against one of the recovered keystream bits. This
would allow her to distinguish good and bad candidates.
Function f (·) is balanced, so it evaluates for all 16 different values of abcd to eight
times to a zero and eight times to a one. Therefore, when the keystream bit is a zero,
the eight abcd candidates, which lead to a one, are disqualified (also referred to as
eliminated).
After computing f (·) and performing one rotation on both registers, the cipher
successor state is reached. The next keystream bit is computed with four different
secret key bits. The adversary again uses the same technique and eliminates incorrect
abcd candidates for the second keystream bit. The computational complexity drops
significantly when it is possible to evaluate the input for each consecutive keystream
bit independently from the others.
Assume an adversary recovered 16 consecutive keystream bits ks0 ks1 . . .ks15 , let us examine how she can
mount a guess-and-determine attack on the cipher illustrated in Figure 3.11. To clarify the secret key bits which
are used to compute a keystream bit, the first 5 evaluations of the filter function f (·) are specified in Figure 3.15.
ks0 = f (k3 , k7 , k10 , k12 )
ks1 = f (k4 , k8 , k0 , k13 )
ks2 = f (k5 , k9 , k1 , k14 )
ks3 = f (k6 , k10 , k2 , k15 )
The four secret key bits k3 k7 k10 k12 are used to pro- ks4 = f (k7 , k0 , k3 , k11 )
duce the first keystream bit ks0 . The adversary needs
Figure 3.15: First five
to guess all 24 = 16 candidates for the 4 secret key bits
evaluations of f (·)
k3 k7 k10 k12 . After elimination, only half of the candidate
set survives the test. So, each guess of 4 bits allows the
adversary to eliminate 1 bit of entropy. This leaves the adversary after 24 computa4
tions with a smaller set of 22 = 23 possible candidates.
Evaluation of the second keystream bit ks1 requires the adversary to guess another
4 bits of the secret key, this time for k4 k8 k0 k13 . Again, only half of the candidate
set survives. These four secret key bits are completely different from those used to
compute ks0 . In fact, the adversary guessed now 8 independent secret key bits, namely
k0 k3 k4 k7 k8 k10 k12 k13 . Even so, she only has 23 × 24 = 27 candidates after guessing the
bits that compute ks1 . In contrast to the regular 28 candidates one should consider
when 8 bits are unknown. It becomes even better, after computing the keystream bit
for all 27 candidates, half of them are once again eliminated. It leaves a set of only
26 possible candidates with values that represent 8 bits of the secret.
The adversary applies the same technique on the third keystream bit ks2 . She
guesses 12 secret key bits and after 210 computations only 29 possible candidates
survive. The fourth keystream bit ks3 is computed with the secret key bits k6 k10 k2 k15 .
Note that the secret key bit k10 was already guessed to compute the first keystream bit
ks0 . It introduces two (partially) independent problems, a property which is similar
to the divide-and-conquer attack described in Section 3.2.2.
Evaluating of ks3 is rather special, this time the adversary only has to guess three
bits instead of four. After guessing the bits and before evaluating the candidate set
58
Attack scenarios
against the keystream, the size of the candidate set is 212 . Since a computation has
to be performed for each of the candidates in this set, the total attack complexity
grows to 212 computations. Nevertheless, after evaluating ks3 , the adversary guessed
15 secret key bits and compiled a set of only 211 candidates.
The last secret key bit k11 , which is still not considered, is required to compute
the fifth keystream bit ks4 . Guessing k11 only mildly increases the computational
complexity of the attack. The candidate set is first doubled (again) to 212 and after
212 computations immediately halved again to 211 candidates. Testing the candidates
requires in total two times the largest computation of 212 plus some insignificant and
negligible smaller computations which were performed on the smaller candidate sets.
This results in a total attack complexity of (2 × 212 ) + 210 + 27 + 24 = 9360 ≈ 213
instead of the supposed 216 = 65536 computations.
Although the computational complexity is reduced significantly in this example,
further (more complex) optimizations of the guess-and-determine strategy could improve this attack even more. Such techniques are not further explored in this section,
although they are further addressed in the cryptographic attacks described in Chapter 6 and Chapter 7.
3.2.5
Differential cryptanalysis
The Data Encryption Standard (DES), introduced in 1977, was considered theoretically secure for many years. This confidence lasted until 1991 when Biham and Shamir
showed in [BS91] that it is possible to cryptographically attack a cipher that is similar to DES. They used a new attack technique which they introduced as differential
cryptanalysis.
The company IBM, responsible for the initial design of DES, claimed in [Cop94]
that they were already familiar with this particular attack technique for more than
15 years. Furthermore, they explained to have used their knowledge to prevent differential cryptanalysis on DES as much as possible.
Nonetheless, two years later, Biham and Shamir published another article [BS93]
in which the authors specifically attacked the cryptographic algorithm of DES. As
mentioned in Section 2.2.3, the attack requires an enormous amount of gathered data
and is therefore considered purely theoretical. Their publications inspired many fellow
academics to further explore and optimize the differential attack technique both for
block ciphers [LMM91, CV95, AC09] and for stream ciphers [Din94, Mul04, WP07].
The applicability of differential cryptanalysis highly depends on the possibility to
gather a set of similar encryptions which differ only to a certain extent. A straightforward approach would be to find a way that directly influences and only slightly
changes the internal state of the cipher. To apply such a technique in practice, often additional components of the cryptosystems are used to intentionally create the
desired difference in the internal state. Examples of such components are the internal state initialization procedure, key diversification schemes and random number
Attack scenarios
59
generators. With control over these components an adversary can often predict and
pre-compute the desired changes.
The initialization procedure of the cipher might allow an attacker to specifically
change one internal state bit at a certain position. Such a minor change could lead
directly to a different output which indicates the changed bit is a significant input to
the filter function. Likewise, when the change does not influence the corresponding
keystream bit, it reveals that the bit is an insignificant input to filter function.
Consider the non-linear stream Cipher 4, illustrated in Figure 3.16. It uses the
non-linear filter function from Definition 3.2.2. Although the workings of the cipher
are similar to that of Cipher 3, the internal state is initialized in a different way.
Cipher 4
x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 x10
a
b
c
x11 x12 x13 x14 x15
d
f (a, b, c, d) = (a ∧ b) ⊕ c ⊕ d
Figure 3.16: Non-linear stream cipher that initializes a fresh internal state
with the key k and nonce n by xi ← ki ⊕ ni where i ∈ {0, . . . , 15}
Section 2.4.1 shows that many cryptosystems use random challenges to add freshness to the encryption. In this example the challenges consist of a 16-bit random value
which is called the nonce n. Furthermore, the bits of k are not just placed into the
internal state of the cipher like Cipher 3. Instead, they are loaded with the exclusiveor (XOR) of the secret key k and the nonce n. To be precise, the initialization is
performed by xi ← ki ⊕ ni where i ∈ {0, . . . , 15}.
Assume two additional attack vectors on the cryptosystem. The adversary has
complete control over the nonce n and secondly, she can invoke and observe plain
keystream from an authentication attempt as often as she likes. This allows her
to perform differential cryptanalysis in the following way. First, she authenticates
using a nonce n and stores the first computed keystream bit ks0 . Next, she flips the
fourth bit n3 from the nonce n which gives her an alternative nonce n′ . Then, she
re-authenticates with the nonce n′ and compares the computed bit ks′0 against the
previously stored keystream bit ks0 .
After the two authentications, the adversary did not recover the actual value of
x3 . However, she does know that the difference between the internal states of the two
authentication sessions is a negation of the bit x3 . Furthermore, the bit x3 represents
input a to the filter function, which in turn is used to compute the first keystream
bit for both authentications ks0 and ks′0 . Note, that input b, represented by x7 , was
not altered by the nonce since n7 = n′7 . The same holds for input c and d, since the
fourth bit of the nonce was changed.
60
Attack scenarios
A closer look at the input-output relation of the filter function (see Figure 3.14)
reveals that the value of input a only matters if input b is true. The first keystream bit
is computed with x3 as input a and x7 as input b. Consequently, x3 only influences
the keystream bit ks0 when x7 = 1. Therefore, if ks0 = ks′0 the adversary can
conclude that x7 = 0. Likewise, the contrapositive is valid as well, if ks0 6= ks′0 she
can conclude that x7 = 1.
In conclusion, a differential attack can be mounted on this cipher simply by flipping
the fourth bit of the nonce and uses it to re-authenticate. The observed differences
between the first computed keystream bit in both authentications reveals the value
of x7 . With the knowledge of nonce bit n7 and the determination of x7 , the secret
key bit k7 can be simply recovered by computing k7 = x7 ⊕ n7 .
This particular example shows how to recover one bit of the secret key by performing only two authentications and with negligible computational complexity. Since the
stream cipher is rotating regularly, the same technique could be applied to recover
more bits of the secret key. Likewise, flipping nonce bit n4 and observation of a
difference in ks1 reveals x8 .
The ciphers presented in Chapter 6 and Chapter 9 are to some extent vulnerable
to differential cryptanalysis. Both ciphers allow an adversary to manipulate the input
in such a way that the output leaks information about the secret key.
Differential cryptanalysis is a powerful technique to recover a secret key. Some
carelessly designed cryptosystems are vulnerable to such an extent that it is even
possible to mount a differential attack in practice. For instance, the MIFARE Classic
and iClass ciphers, presented in Chapter 6 and Chapter 9, are vulnerable to a practical
differential attack. Both ciphers allow manipulation of the input in such a way that
the computed output leaks information about the secret key.
A differential attack often requires specific input-output differences. The initialization of a cryptosystem might not always allow an adversary to enforce such
differences in the internal state. Nonetheless, there is always the possibility to gather
many traces and filter out the ones that satisfy the predetermined conditions. Moreover, according to the birthday paradox, the number of traces the adversary needs to
gather is much smaller than the number usually suggested by intuition, see [Sim64]
for more details.
3.2.6
Algebraic attacks
Several cryptographic attack methodologies aim to reduce the computational complexity of a stream cipher by attacking the non-linear function. However, some cipher
designs consist of one or more linear components. Such ciphers are vulnerable to
algebraic attacks. The literature includes several historical contributions concerning
algebraic attacks [Hil29, Hil31, Ree77, Rub79]. Throughout the last decade, several
attack generalizations and optimizations were proposed [CP02, AK03, FJ03, CM03,
Cou03a, Arm04, MPC04, Cou05, CF08]. This section, however, only defines the basic
Attack scenarios
61
principles of algebraic attacks. Note that algebraic attacks should not be confused
with linear cryptanalysis, which was introduced in [Mat94] to attack the block cipher
DES.
A property of a linear boolean function is the possibility to postpone an evaluation.
Computational problems which are formalized during a cryptographic attack can be
written as a system of boolean equations [TT80]. Instead of computing the outcome
directly, a combination of these equations can be solved by well-known techniques
such as Gaussian elimination [Hil29, Mul56, Mar57, Str69, WBD74, Rub79].
In boolean algebra, a function f is F2 -linear if it satisfies f (x ⊕ y) = f (x) ⊕ f (y) for
any pair (x, y) of elements in its domain. Moreover, a boolean linear function defines
that the input variables either always or never influence the output. Consequently,
an observation of influenced output bits, that were computed by a linear function,
leak a deterministic linear relation about the corresponding changes of the input
bits. When a sequence of influenced output bits exceeds the number of input bits,
it is just a matter of solving the system of equations without the need for expensive
computations. Contrarily, a non-linear function makes the inversion process more
difficult, since the influence of the individual input bits depends on the actual value
of these bits. In contrast to a linear function, it is much more difficult to generalize
an equation for non-linear functions which holds for every input.
Consider the cipher design with linear output as illustrated in Figure 3.17. It
consist of two very small bitwise rotating registers which both deliver one input bit
to the linear filter function f (·) in order to produce the next keystream bit.
Cipher 5
k0 k1 k2 k3 k4
a
k5 k6 k7
b
f (a, b) = (a ⊕ b)
Figure 3.17: A linear stream cipher, initialized by secret key k
The linear filter function f (·) consists of only one exclusive-or (XOR) operation
and is redefined in Definition 3.2.3. The XOR operation, denoted by the symbol ⊕,
represents a mathematical addition modulo 2.
Definition 3.2.3. Redefine the filter function f : F22 → F2 as
f (a, b) = (a ⊕ b)
The XOR operator is a bitwise linear operation and allows an adversary to compile a system of equations. Consider the following keystream bits ks0 ks1 . . .ks7 =
10110101. Figure 3.18 consists of four columns, each of which represents a write-up
62
Attack scenarios
or evaluation step. After three steps, eight equalities are formed which correspond to
the considered keystream. A combination of those equalities determines two equations
which should be satisfied when guessing the actual secret key bits.
ks0 = k2 ⊕ k5
k5 = k2 ⊕ ks0
k5 = k2 ⊕ 1
k5 = k2
ks1 = k3 ⊕ k6
k6 = k3 ⊕ ks1
k6 = k3 ⊕ 0
k6 = k3
ks2 = k4 ⊕ k7
k7 = k4 ⊕ ks2
k7 = k4 ⊕ 1
k7 = k4
ks3 = k0 ⊕ k5
k5 = k0 ⊕ ks3
k5 = k0 ⊕ 1
k5 = k0
ks4 = k1 ⊕ k6
k6 = k1 ⊕ ks4
k6 = k1 ⊕ 0
k6 = k1
ks5 = k2 ⊕ k7
k7 = k2 ⊕ ks5
k7 = k2 ⊕ 1
k7 = k2
ks6 = k3 ⊕ k5
k5 = k3 ⊕ ks6
k5 = k3 ⊕ 0
k5 = k3
ks7 = k4 ⊕ k6
k6 = k4 ⊕ ks7
k6 = k4 ⊕ 1
k6 = k4
(a)
(b)
(c)
(d)
Figure 3.18: Evaluation of ks0 ks1 . . .ks7 = 10110101 leads to the equalities of (d)
Given the equalities denoted in Figure 3.18d it is feasible to deduce two equations,
which are given below in Equation (3.1) and Equation (3.2). The equations specify
that there are two sets of secret key bits. All elements within one set carry the same
value (either zero or one). However, both sets represent the opposite value to each
other, which is confirmed by the fact that k6 is an element of the first set and its
complement k6 is an element of the second set.
k6 = k3 = k1 = k5 = k7
(3.1)
k6 = k4 = k2 = k0
(3.2)
According to Equation (3.1) and Equation (3.2) there could be only two solutions,
either k0 k1 . . .k7 = 10101000 or its bitwise complement k0 k1 . . .k7 = 01010111. The
computational complexity to evaluate the equation is negligible. However, the actual
work that is required also includes the evaluation of the keystream bits, deducing the
equalities and formulating the final equation. It is much harder to generalize such
tasks in terms of computational complexity, especially since several tricks to efficiently
optimize such effort were proposed in the literature [CKY89, Arm04, MPC04, LA+ 08].
Techniques that find their origin in the previously explained algebraic attacks are
applied in practice to the proprietary Hitag2 cipher introduced in Chapter 7. At first
it considers two linearly combined inputs as one element of the initialization. This
allows an adversary to drastically reduce the list of possible internal states by avoiding
independent evaluation of both inputs.
3.2.7
Meet-in-the-middle attack
It is not trivial to increase the computational complexity of a cryptosystem. General
reasoning could steer a designer to apply inefficient enhancements [MH81, EG85]. For
Attack scenarios
63
instance, it is misleading to think that applying a cipher twice, using a completely
different secret key, would double the total computational complexity of a cryptographic algorithm. At first sight it suggests that an adversary needs to perform an
exhaustive search twice, to independently determine the first and second secret key.
In practice however, it is unlikely that an adversary would use such a method to
attack a cryptosystem that applies multiple encryptions. This section introduces a
powerful cryptanalytic technique that attacks such a cryptosystem from two sides, the
input and the output, and tries to correlate the results in the middle. The technique
is commonly referred to as a meet-in-the-middle attack. It can be seen as a special
form a divide-and-conquer attack, since it generally tries to solve two independent
problems concurrently.
Doubling the computational complexity means that the entropy of both secret keys
are multiplied with each other, resulting in the product of both secret keys. However, a scheme where two independent ciphers are applied in a consecutive manner is
vulnerable to a meet-in-the-middle attack. Such an attack reduces the computational
complexity to the sum of both entropies instead of to the product.
A meet-in-the-middle attack requires knowledge of at least one plaintextciphertext pair. With such a pair, the adversary can attack both independent ciphers at the same time. The plaintext is used as input to the first cipher, while the
ciphertext is considered as output of the second cipher. The idea is to find a list
of candidate outputs (ciphertexts) of the first cipher and a list of candidate inputs
(plaintexts) for the second cipher. The intersection of both lists reveals a relation
between the two independent secret keys. A plaintext-ciphertext pair that consists
of a long enough bitstring singles out only one possible candidate. When multiple
candidates are found, more plaintext-ciphertext pairs can be utilized as test vectors
to recover the valid secret keys.
For instance, Figure 3.19 shows a cryptosystem that utilizes two different stream
ciphers with completely independent secret keys. The ciphers are applied consecutively after each other to encrypt the plaintext. After encryption with the first cipher,
the plaintext is transformed into an intermediate state which represents the output
of the first cipher as well as the input to the second cipher.
stream cipher 1
stream cipher 2
L
L
plaintext
intermediate state
ciphertext
Figure 3.19: cryptosystem which is vulnerable to a meet-in-the-middle attack
Assume that both stream ciphers in Figure 3.19 are not susceptible to a known
cryptographic weakness. This leaves the adversary with no other option than to
perform an exhaustive search over the complete key space of both ciphers. Instead
of trying for each first cipher key guess all possible second cipher keys, the adversary
64
Attack scenarios
performs the following attack steps.
1. She first recovers a plaintext-ciphertext pair of moderate length. It is preferably
a longer bitstring than the secret keys length of both stream ciphers together.
More bits, means more information and avoids multiple (false) candidates when
correlating the output of the first cipher with the input of the second cipher.
2. Then, she encrypts the plaintext with the first cipher using all possible secret
keys and stores the (encrypted) output in one big list. This output list represents
the intermediate state candidates.
3. Next, she decrypts the ciphertext with the second cipher using all possible secret
keys and looks if the (decrypted) input entry exists in the output list of the first
cipher.
4. Finally, the decrypted input entry that exists in the encrypted output list is the
value where both ciphers meet in the middle. The secret keys used to encrypt
and decrypt to this value are the secret keys used by the original system to
produce the plaintext-ciphertext pair.
Instead of performing a brute-force attack on the second cipher for each first
cipher secret key guess, the adversary only has to perform two independent brute-force
attacks and correlate the intermediate results. This makes the cryptographic problem
only twice as big, meaning the sum of twice the original (computational complexity)×
2, instead of the product (computational complexity)2 .
The meet-in-the-middle attack is a well-known strategy to defeat weak components
and schemes embodied in various cryptosystem. Several improvements and practical
implementations of meet-in-the-middle attacks are given in the literature [VOW96,
DST04, DSP07, DS08, AS09, DTC
¸ B09, GLRW10]. Likewise, Chapter 8 introduces
a variant of the meet-in-the-middle attack that recovers the secret key during the
cipher initialization phase. It first shows how to recover the internal state of the
CryptoMemory cipher. Then, it starts from the default initialization and guesses
the first half of the secret key while running forward and guesses the other half
running backwards. During the intersection of both internal state candidate lists, the
overlapping state represents the secret key.
Some cryptosystems explicitly define encryption schemes to mitigate meet-in-themiddle attacks. For instance, the Triple DES (3DES) specification defines the use of
multiple consecutive utilizations of the Data Encryption Standard (DES). To mitigate
a meet-in-the-middle attack, the crypto operation is performed three times instead of
two. Note, that the increase in computational complexity is limited to two times the
original 256×2 = 2112 bits, instead of the intuitively expected three times. Since the
achieved complexity is only two single DES keys, the 3DES scheme defines a way to
securely perform three times single DES using exactly two secret keys of 256 bits. It
involves a sequence of encryption, followed by a decryption and encryption again.
Attack scenarios
65
Multiple encryption schemes are useful to increase the computational complexity
of block ciphers, yet they do not provide the same security features as stream ciphers.
Combination of various stream cipher outputs means that multiple keystreams are
all combined together with the plaintext using an XOR operation. This inherently
defines a direct linear relation between the computed output bits of each utilized
stream cipher. In fact, [MM93] shows that the keystream produced by a combination
of two additive stream ciphers is as secure as the strongest of the two. Although this
feature does not increase the cryptographic strength, it could be used to spread the
potential risk of cipher weaknesses over multiple independent ciphers.
3.3
Physical attacks
The types of attacks mentioned in Section 3.1 and Section 3.2 rely on control over
the communication channel and mathematical properties of the cryptosystem. This
section addresses a third scenario where an adversary has physical access to a cryptographic hardware device. Many examples of such devices are used in everyday life.
For instance, access control cards, car keys, credit cards, mobile phones and other
electronically secured tools. These products often contain micro-controllers which
have limited protection against malicious memory access. It may implement some
countermeasures against simply reading out the secret key (e.g. using a debugger
interface). However, only the high-end (and often much more expensive) devices offer
protection against advanced physical attacks on the hardware itself.
Physical hardware attacks are categorized into three different classes. They range
from passive measurements of the characteristics of the chip to actively injecting error
states which alter the execution flow of a cryptographic computation. This section
first introduces non-invasive hardware attacks, which do not directly tamper with the
chip itself. Following are invasive hardware attacks, a technique where the components
are altered or dismantled to directly extract secret information. In some cases the chip
internals are even completely destroyed during the process. To conclude, the semiinvasive attack method is also addressed. It is similar to invasive attacks, although
this time only environmental changes are applied to the chip which subtly alter the
workings of the device.
3.3.1
Non-invasive attacks
There are many variants of non-invasive hardware attacks proposed in the literature.
The attack types that are addressed in this section are often referred to as side-channel
attacks, since they try to derive information leakage from side-effects created by the
main application. The first attack technique that is addressed is a timing attack,
followed by power analysis and finally Electromagnetic (EM) analysis.
Timing attacks [Koc96, SWT01, BB05] correlate the execution time of a crypto
algorithm with the computations that are performed. With extensive knowledge of the
66
Attack scenarios
instruction timing information of the target, the execution path may leak information
about the cryptographic computations. Using these computations a list of suitable
candidate secret keys can be estimated.
Power analysis attacks are very effective on devices that do not implement countermeasures against them. There are two main variants: Simple Power Analysis (SPA)
and Differential Power Analysis (DPA). Since its introduction in the nineties [KJJ99],
several optimizations and improvements have been proposed in the literature [Cor99,
Mes00, BCO04, GBPV10, KJJR11]. Mounting these attack techniques is quite affordable with equipment of only moderate costs. Various research institutes have
performed independent studies [MDS99, MS00, Man03, Gou02, OMHT06, MPO05]
to explore the practical resistance against power analysis on secure hardware devices
that are used by the industry. Chapter 8 describes how the observation of the power
levels could lead to the recovery of a secret key from a CryptoMemory chip.
Electromagnetic (EM) analysis is based on the information leaked through observ¨
ing electromagnetic emission. Studies in the literature [QS01, GMO01, DMOPV07]
show that it is practical to learn secret information from a cryptosystem through
EM attacks. The technique is very powerful since it can be applied from a distance
without changing the original working environment.
Academics recently showed that it is even practical to extract secret information
from a laptop, just by listening to the sound it makes during cryptographic computations [GST13].
3.3.2
Invasive attacks
Invasive hardware attacks start with the decapsulation of the Integrated Circuit (IC).
By removing the packaging the internals of the chip are exposed. Decapsulation of
an IC can be achieved by etching, drilling, laser cutting and by use of more advanced
tools like a Focused Ion Beam (FIB). The technique has almost unlimited capabilities
to extract information from chips and understand their functionality. However, it is
time-consuming, depends on expensive equipment and requires a very knowledgeable
adversary.
After the decapsulation process invasive attacks can be mounted on the surface of
the chip. With electrical probing it is possible to reveal the inner circuit of a silicon
chip [Wie90, BFSB06]. More advanced techniques like micro-probing [AK96, Wei00]
allow needles to be attached on exactly those wires that exchange sensitive data.
Observing the communication on those wires allows an adversary to learn information
like hidden proprietary commands and secret cryptographic keys.
3.3.3
Semi-invasive attacks
The category with semi-invasive attacks is introduced [Sko05] to bridge the gap between non-invasive and invasive attacks. It still requires decapsulation of the chip,
Attack scenarios
67
similar to invasive attacks, yet it applies only non-invasive techniques with less expensive equipment. Furthermore, these attacks can be performed in a reasonably short
time and are easily repeatable since the chip is not irreversibly altered in the process.
For instance, an optical microscope with a Charge-Coupled Device (CCD) camera
can make an image of a chip circuit layout. There are several studies that show it
is not hard to reconstruct the workings of a chip just by observing pictures of its
internal components [BFL+ 93, WCAA00, NESP08, PN12].
Semi-invasive attack techniques adjust a combination of various environmental
configurations and observe if the workings of the chip are influenced. The literature [SSAQ02, SA03, BBD06, HSH+ 08, HSH+ 09, Sko09, MSSS11] demonstrates practical attack results by exposing a decapsulated chip to variations in temperature, UV
light, X-rays and other sources of ionizing radiation, lasers and electromagnetic fields.
Chapter 4
Scientific security assessments of
proprietary cryptosystems
Besides the security assessments of proprietary cryptosystems presented in Part II,
there are several examples in the academic literature which expose the insecurity of
widely used proprietary cryptosystems. The majority of the evaluated systems are
attacked to such an extent that they become practically exploitable. This chapter
presents the most prominent scientific security assessments which are relevant to this
dissertation. The assessments are categorized in four types of systems.
First, the use of access control systems is addressed in Section 4.1. Next, attacks
on vehicle immobilizer systems are presented in Section 4.2. Then, various kinds of
proprietary communication encryption used in the telephone industry is described in
Section 4.3. Finally, in Section 4.4 various other widely used proprietary encryption
techniques are addressed.
4.1
Access control systems and electronic locks
Purely mechanical keys and locks are replaced by Radio Frequency (RF) enabled
devices for securing access to buildings, rooms, cars, and other property. While
mechanical keys and locks are still widely used, they suffer from several disadvantages.
For instance, when a mechanical key is lost, stolen or copied, all affected door locks
have to be replaced to preserve a certain level of security.
Electronic access control systems can cope much better with such events. In case
of loss or theft, administrators can simply lock out the affected electronic keys in a
database. Furthermore, the use of cryptography can mitigate the problem of copied
keys. However, in practice, the major system integrators and suppliers of electronic
locks have been using weak and proprietary cryptography in their systems as will be
shown next.
There are three well-known examples in the literature. Section 4.1.1 addresses the
weaknesses access control systems which use Legic Prime cards. Attacks on two widely
deployed versions of SimonsVoss electronic lock systems are presented in Section 4.1.2
and Section 4.1.3.
70
4.1.1
Scientific security assessments of proprietary cryptosystems
Legic
LEGIC Identsystems is a major supplier of access control systems that uses
RFID technology for identification. In
2006, the manufacturer claims that it
sold more than 70 million access control
tokens, which are used in at least 50, 000
installations world-wide [LEG06]. The
Figure 4.1: Legic obfuscation [PN12]
Legic Prime system uses a proprietary
RFID card to secure building access and micropayment applications [LEG03]. It is
widely deployed throughout Europe and used in critical infrastructure such as military
installations, governmental departments, power plants, hospitals and airports.
Despite its use in high-security installations, the literature [PN12] shows that access cards can be instantly cloned from a distance. The security only relies on a
secret algorithm that combines the output of a custom CRC with the user’s credentials by applying the XOR operation. There is no secret key involved in this
transformation, only a secret algorithm. The authors of [PN12] reverse-engineered
the secret algorithm by using a method called chip-slicing. This is a technique that
sequentially removes the layers of a silicon chip, photographs the internal structure
and reconstructs the operations that are performed. The method is further explained
in [BFL+ 93, NESP08].
4.1.2
SimonsVoss G1
The scientific article [WMT+ 13] assesses
the security features of electronic locks
which are based on the SimonsVoss Digital Locking System 3060 Generation 1
(G1). The system is a relatively old design which was introduced in 1997. Since Figure 4.2: Weak PRNG implementation
allowing only 231 − 1 states [WMT+ 13]
the successor of this electronic lock (G2)
was introduced in 2007, it is discouraged to use the first generation (G1). However,
it is still an actively used and widely deployed system and replacement parts are still
being sold for legacy installations.
In [WMT+ 13], the radio protocol and cryptographic primitives of the system are
reverse-engineered. They discovered some implementation flaws which allow two ways
to extract the system-wide master secret. Either the adversary mounts a bruteforce attack on gathered authentication attempts or performs a Differential Power
Analysis (DPA) attack [KJJ99] on an electronic key.
In addition to this, the authors of [WMT+ 13] discovered several weaknesses in
the Pseudo Random Number Generator (PRNG) implementation, which allows a
71
perpetrator to open a door without the necessity of recovering the secret key. Finally,
they suggest some countermeasures to mitigate their attacks.
4.1.3
SimonsVoss G2
The literature [SDK+ 13, OSS+ 13] also
contains an analysis of the newer,
widespread SimonsVoss Digital Locking
System 3060 Generation 2 (G2). With
respect to Simonsvoss G1, introduced in
Section 4.1.2, the new system also relies
on an undisclosed, proprietary protocol
to mutually authenticate transponders
and locks.
Figure 4.3: Obscurity function [SDK+ 13]
The authors of [SDK+ 13, OSS+ 13] explain that their analysis reveals several security vulnerabilities that enable practical key-recovery attacks. They present two
different approaches to gain unauthorized access to installations. Firstly, an attacker
with physical access to a door lock can extract a master key by dumping the firmware
of the chip within a time-frame of only 30 minutes.
A second cryptanalytic attack exploits an implementation flaw in the protocol and
depends only on wireless communication with the electronic door lock. The system
uses a modified DES algorithm and a challenge-response authentication protocol that
re-uses internal bits of the previous session as challenge for the next session. This
allows an adversary to derive the transponder key from a few consecutive authentication attempts gathered wirelessly. By being only a few seconds in vicinity distance
of a door lock, an adversary can recover all the transponder credentials within only a
few seconds of computation.
4.2
Electronic vehicle immobilizers
Electronic vehicle immobilizers have been very effective at reducing car theft. Such
an immobilizer is an electronic device that prevents the engine of a vehicle from
starting when the corresponding transponder is not present. This transponder is a
low-frequency Radio Frequency Identification (RFID) chip which is typically embedded in the vehicle’s key. When the driver starts the vehicle, the car authenticates the
transponder before starting the engine, thus preventing hot-wiring. In newer vehicles
the mechanical ignition key has often been removed and replaced by a start button.
In such vehicles the immobilizer transponder is the only anti-theft mechanism that
prevents a hijacker from driving away with the car.
In Section 4.2.1 an immobilizer cryptosystem is reverse-engineered and shown to
be insecure because it utilizes an extremely weak secret key. Section 4.2.2 shows
72
several attacks on a cryptographic algorithm that is used in immobilizers and Remote
Keyless Entry (RKE) systems.
4.2.1
DST
The security algorithms of the vehicle immobilizer cryptosystem known as a Digital Signature
Transponder (DST) are reversed-engineered and
attacked in [BGS+ 05]. The authors used the
transponder as an encryption oracle to perform
a black-box analysis and find the cryptographic
relation between the input and the output. Their
methodology is thoroughly explained in the paper and encourages other researches to explore
similar research.
Digital S ignature T rans ponder (3)
400 clocks
10 rounds
Challenge/R esponse R egister
R outing
Network
f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f21
f20
R outing
Network
E ncryption K ey R egister
400 / 3 clocks
Digital S ignature DS T 40 Algorithm implementation
Dr. Ulrich K ais er
T exas Ins truments Deuts chland G mbH
Figure 4.4: DST cipher [BGS+ 05]
The DST cryptosystem uses a fairly small secret key of only 40 bits. They show that it is straightforward to recover the proprietary
algorithms used in this cryptosystem. With knowledge of these proprietary computations an adversary could simply find the secret key by performing an exhaustive-search
over the complete key space. With the storage capabilities of current hard drives, it is
possible to pre-compute all possible encryptions (cipertexts) given a few chosen plaintexts. After pre-computing and sorting these ciphertexts, an adversary can quickly
lookup the corresponding secret-key given a plaintext-cipertext pair.
4.2.2
KeeLoq
The proprietary KeeLoq cipher is used in Remote Keyless Entry (RKE) systems and remotely
operated locks for garage doors. It attracted
the attention of cryptographers when the cipher
was published1 in 2006. The first proposed attack [Bog07b] used a combination of correlation
and linear attacks to recover the secret key with
a computational complexity of 252 encryptions.
The attack was later optimized in [Bog07c,
Bog07a] to a complexity of 250.6 encryptions. An
algebraic slide attack was proposed in [CBW08].
Although the computational complexity of this
attack is only 227 , it requires a special case of an
encrypted slid-pair sample. Since there is no easy
1 http://en.wikipedia.org/wiki/KeeLoq
Figure 4.5: KeeLoq
encryption [CBW08]
73
way to identify such a pair, the attack is simply repeated 232 times for each 216 pairs,
which increases the total attack complexity to at least 248 .
In [IKD+ 08] a new method is proposed that uses a meet-in-the-middle attack to reduce complexity to only 244.5 encryptions. Finally, in [EKM+ 08, PEK+ 09, KKMP09]
several hardware attacks were proposed that show it is practical to recover a device specific key as well as the secret master key which allows an adversary to clone
credentials from gathering only a few wireless traces.
4.3
Cellular-, cordless- and sat-phones
In the last decades several types of wireless phones were introduced. These communication devices have changed the way we interact with each other. Instead of using
only wired landlines, the general public migrated to cellular- and cordless-phones.
Additionally, the financial barrier to use satellite-phones is lowered by the increase
of satellite providers. Compared to wired connections, it is much easier to eavesdrop
a wireless device. It is challenging to achieve the same protection that secures the
confidentiality of a telephone conversation.
Since the 90’s most wireless communication is digitalized. One of the advantages
of digitalization is the ability to transparently encrypt the communication channel.
This could in principle protect the confidentiality of all telephone conversations. However, this section shows that several widely deployed proprietary cryptosystems used
in cellular phones (Sections 4.3.2–Section 4.3.5), cordless phones (Section 4.3.6 and
Section 4.3.7) and satellite phones (Section 4.3.8 and Section 4.3.9) fail to provide
secure and adequate ways of encryption.
4.3.1
ORYX
The Telecommunications Industry As#
5%
&
sociation (TIA) is the North American
+
equivalent to European Telecommunica+-./("012.3(14"$
!
#
5%
&
tions Standards Institute (ETSI). It de#
+-./("012.3(14")
! '
!
signs specifications and digital cellular
,
5%
&
standards which are comparable to those
#
+-./("012.3(14"*
used in GSM communication. One of the
selected encryption algorithms to proFigure 4.6: ORYX cipher [WSD+ 99]
tect wireless data services is the stream
cipher ORYX. The implementation of the proprietary cipher is controversial. A
few years after its introduction in 1995 it was first publicly reviewed in the literature [WSD+ 99]. Although the initial security of the cipher should provide a computational complexity of 296 bits, the article shows that the actual attack complexity is
only 216 . The authors of [WSD+ 99] used a divide-and-conquer attack, as described in
Section 3.2.2, to drastically reduce the computational complexity of the cipher. After
"
$&
"
$%
)
(
*
74
publication the cipher was considered completely broken and shown to be insecure.
The TIA updated their specification accordingly and removed ORYX from the list of
proposed cryptographic primitives.
4.3.2
A3, A8 and COMP128
0
15
...
...
31
....
...
7
..
.
Level 0
23
..
3
..
...
11
..
19
...
Level 1
27
Level 2
...
...
...
...
...
...
The Global System for Mobile Communications
(GSM) specification that was published by the
European Telecommunications Standards Institute (ETSI) allows Telecom operators to use their
own proprietary algorithms for network authentication. As an example, the specification mentions an authentication method based on the socalled COMP128 implementation. COMP128 is
an example instantiation of the two proprietary
algorithms A3 and A8.
...
Level 4
The first algorithm A3 is used to authenticate the mobile station to the network, while the Figure 4.7: COMP128 [RRST02]
second one, A8 is used to generate the session
key. The session key is input to one of three additional proprietary A5 ciphers which
are addressed later in Section 4.3.3, Section 4.3.4 and Section 4.3.5. Although the
COMP128 implementation was just a reference example, it has been literally copied
and deployed by different service providers in several types of Subscriber Identity
Module (SIM) cards. After public exposure of the proprietary algorithms in 19982,
the cryptographic security was thoroughly assessed in the literature.
The first cryptanalytic attack was published in [WGB98]. The attack was later
extended and generalized in [HP00]. An effective hardware attack was later proposed
in [RRST02], where the authors retrieve the 128-bit key by using as few as 8 chosen
plaintexts. This article inspired many attack optimizations [GMO01, Nov03, Cla07,
ZYSQ13] on similar algorithms.
4.3.3
A5/1
The first generations of GSM transmissions use the secret and proprietary A5
stream cipher design. This algorithm
uses a 64-bit secret key and has two main
variants. The A5 ciphers are responsible
for encryption of the data transmitted
between the mobile device and the Base
Transceiver Station (BTS).
2 http://www.scard.org/gsm/a3a8.txt
R1
0
18
C1
R2
0
21
C2
R3
0
22
C3
Clocking Unit
Figure 4.8: A5/1 cipher [BB06]
Output
stream
75
The original GSM cipher (which was export-restricted) embeds the stronger A5/1
version and is used mainly in Europe while the less secure A5/2 version is used in
other countries. The approximate design of A5/1 became publicly known3 in 1994.
Furthermore, it was concurrently published in the literature at the CHINACRYPT
conference in China [XHW94]. Historical records show that there were some serious
cryptographic weaknesses found in 1994 [She94a, She94b]. However, for several years
no cryptographic attacks on A5/1 were published in the literature. Finally, in 1997
the first article [Gol97a] showed that the required computational complexity to mount
an attack only required solving 241 linear equations.
In the years after that many followed [BS99, BD00, BS00, PS00, BSW01, BBK03,
EJ03a, GKVW05, MJB05, BB06, GNR08, BBK08, KPPM12, PPPM13]. The first
papers purely exploit cryptographic weaknesses in A5/1 and optimize the previously
proposed attacks. The latter publications propose combinations of cryptanalytic and
hardware attacks to demonstrate that the theoretical attacks are practically applicable. The specific internal structure of the GSM communication protocol allows the
most powerful cryptographic attack, a ciphertext only attack. An adversary that
eavesdrops a communication and gathers a sequence of consecutive encrypted frames,
can recover the secret key with moderate computational power.
4.3.4
A5/2
The A5/2 cipher is a weaker version of
the A5/1 encryption algorithm. The
main reason is that the designers moved
part of the algorithm to an additional
register. Thereby they increased the
complexity of the algorithm, although
they drastically decreased the computational complexity to attack the cipher. As mentioned in Section 4.3.3, the
stronger GSM cipher A5/1 was exportFigure 4.9: A5/2 cipher [BBK03]
restricted. It could not be used in countries that were not a member of the Organization for Economic Co-operation and
Development (OECD). There are several theories, yet the actual reason why the
non-OECD countries should use weaker encryption was never officially explained to
the general public.
Majority
Function
1
R1
0
R2
0
18
Majority
Function
1
21
Majority
Function
1
R3
0
Output
stream
22
Clocking Unit
R4
0
16
The cipher A5/2 was published in 1999 after it was reverse-engineered from a
mobile cell phone4 . Several cryptographic weaknesses were identified in the literature [BBK03, BER07, BBK08] shortly after its publication. The cryptographic
strength is considered extremely low, the cipher allows key recovery from only a
few consecutive ciphertext frames and negligible computational complexity.
3 http://cryptome.org/jya/crack-a5.htm
4 http://cryptome.org/gsm-a512.htm
76
4.3.5
A5/3 (KASUMI)
KASUMI is a proprietary block cipher that was designed
to form the basis of the 3rd Generation Partnership
Project (3GPP) confidentiality and integrity algorithms.
The parties collaborate in 3GPP to standardize the next
generation of cellular telephony, commonly referred to as
3G. In contrast with A5/1 and A5/2 this encryption algorithm is proprietary, yet it is not secret. The full cipher description is available in one of the 3G standardization documents [ETS12], which was published by the European Telecommunications Standards Institute (ETSI)
and is freely available on their website.
KL1 KO1 , KI1
F L1
F O1
KO2 , KI2 KL2
F O2
F L2
KL3 KO3 , KI3
F L3
F O3
KO4 , KI4 KL4
F O4
F L4
KL5 KO5 , KI5
F L5
F O5
KO6 , KI6 KL6
F O6
F L6
L
L
L
L
L
L
KOi,1
F Ii,1
L
L
F Ii,2
L
L
F Ii,3
L
KIi,1
S9
L
KOi,2
S7
L
KIi,2
L
KOi,3
S9
L
KIi,3
KIi,j,2
KIi,j,1
L
S7
L
L
F O function
F I function
KL7 KO7 , KI7
F L7
F O7
KO8 , KI8 KL8
F O8
F L8
L
T
L
L
KASUMI
KLi,1
≪
T
L
KLi,2 S
≪
bitwise
S AND
bitwise OR
≪
rotate left by one bit
F L function
Figure 4.10:
The customly designed block cipher KASUMI is based
KASUMI [DKS10]
on the publicly proposed block cipher MISTY, which was
introduced in the literature [Mat97] in 1997. The 3G session key, which encrypts the
communication, is regularly refreshed and temporarily stored in untrusted memory
of the phone. It can be argued that the initialization of the MISTY cipher in a
3G context is unnecessarily thorough. Therefore, the designers of KASUMI decided
to make MISTY faster and more hardware-friendly by simplifying its key schedule
and modifying some of its components. It is important to note that if KASUMI is
used in another context, where the cipher initialization is trusted to be secure, the
changes can have serious impact on its security strength. Such utilization is possibly
vulnerable to related key attacks [BE02, BDK05, DKS10] and higher order differential
attacks [SAHK07, Sai11, JLR+ 13].
4.3.6
DSAA
Digital Enhanced Cordless Telecommunications
(DECT) is a standard for connecting cordless telephones to a local Base Transceiver Station (BTS)
over a maximum range of few hundred meters. Cordless phones using the DECT are among the most
widely deployed wireless telephone security technologies. Furthermore, several other applications
with even greater security requirements depend on
its technology. For instance machine automation,
building access control, alarm systems, and wireless credit card terminals. To date over 800 million DECT devices have been sold in more than 100
countries [WTHH11].
A21
128
AC
RS
s
t
0xA. . . A
DSAA
s′
128
UAK
64
A11
RSAuth
s
t
DSAA
s′
A12
RAND F
s
t
64
128
KS
64
32
DSAA
s′
64
RES1
DCK
Figure 4.11: DSAA
init [MOTW09]
To achieve confidentiality and authenticity, two proprietary cryptographic algorithms are used. The DECT Standard Cipher (DSC) encrypts the communication
77
and protects the confidentiality of the conversation. The details of this cipher are
addressed in Section 4.3.7. The second algorithm, DECT Standard Authentication
Algorithm (DSAA), authenticates a DECT phone and is designed to protect against
an adversary that tries to piggyback on someone else’s telephone connection. The authentication algorithm was first published in [LST+ 09]. Until then the DSAA was only
available under a Non-Disclosure Agreement (NDA) with the European Telecommunications Standards Institute (ETSI), which thwarted an objective security assessment
through academic scrutiny.
The article [LST+ 09] gives a very detailed security analysis of the DSAA. It includes some very effective attacks on the building blocks used for DSAA. Furthermore,
it points out a commonly made implementation mistake that can practically lead to a
total break of DECT security. The authors show an attack which allows an adversary
to impersonate a BTS and perform a relay attack as described in Section 3.1.3. The
attacks were later optimized in [MOTW09] and generalized in [Tew12].
4.3.7
DSC
The encryption algorithm DECT Standard
Cipher (DSC) is responsible for the confidentiality and protects the data transmitted by a cordless DECT device. Similar to
DSAA, the DSC algorithm was not available to the general public. The inner workings of the algorithm were published one year
later than DSAA by (partially) the same auFigure 4.12: DSC cipher [Tew12]
thors [NTW10]. The article proposes a correlation attack on the cipher which allows the decryption of an intercepted call. It
only relies on passive eavesdropping, so a victim is not able to detect the presence of
an adversary. The attack was later improved in [WTHH11] by reducing the amount
of required keystream and increasing the attack speed with special-purpose hardware.
4.3.8
GMR-1
Satellite phones use the communications satellites that are positioned in a Geostationary
Earth Orbit (GEO). They are commonly referred to as a GEO Mobile Radio Interface
(GMR).
Although satellite phones are in
use for several years, the first scientific article that independently assessed the security of
sat-phone encryption was published only recently [DHW+ 12].
Figure 4.13: GMR-1
cipher [DHW+ 12]
78
According to [DHW+ 12], there are at least 100 000 sat-phone subscribers worldwide. Protecting the confidentiality is an important feature for telephones to ensure
the privacy of a conversation. This is particularly true for satellite phones, since they
are used for sensitive matters like intercontinental operations and disaster response.
There are two providers of sat-phones, each using their own proprietary encryption
technique to protect the communication channel. The first is referred to as GMR-1,
which is discussed in this section, while the second GMR-2 is discussed in Section 4.3.9.
The proprietary cryptosystem GMR-1 uses a stream cipher that is a modified
version of the A5/2 cipher used in GSM. The article [DHW+ 12] proposes an attack
that is similar to those introduced for A5/2 presented in [PFS00, BBK08]. It enables a
ciphertext-only attack, which allows an adversary to passively eavesdrop and decrypt
a GMR-1 conversation.
4.3.9
GMR-2
The proprietary cryptosystem GMR2 is addressed in the same article
which exposed and identified weaknesses in the GMR-1 encryption algorithm [DHW+ 12]. The article proposes
a known plaintext attack against the
GMR-2 cipher by using a Time-Memory
Trade-Off (TMTO). The method allows
Figure 4.14: GMR-2 cipher [DHW+ 12]
pre-computation of certain steps so that
it reduces the on-line attack complexity when it is later mounted by an adversary.
The attack on GMR-2 is less practical than the one proposed for GMR-1, since
it requires approximately 50 to 65 bytes of known plaintext. However, knowledge of
these bytes allows an adversary to practically recover the secret key of a conversation
with only moderate computational complexity.
4.4
Various encryption techniques
The previous sections addressed proprietary ciphers which were used by three specific
fields of industry. This section assesses three encryption techniques which are only
used by a specific application and two general ciphers which are not designed for a
single purpose or particular industry.
Section 4.4.1 addresses the security of the proprietary cipher used to encrypt information stored on a Digital Versatile Disc (DVD). Next, Section 4.4.2 shows the
cryptographic assessment of the proprietary encryption technique used in the communication between two Bluetooth devices. Then, the ciphers addressed in Section 4.4.3
and Section 4.4.4 demonstrate that proprietary ciphers are not necessarily insecure
79
by definition. Both ciphers, developed by experts, are still considered moderately secure and, if used correctly, not practically broken. However, in contrast, Section 4.4.5
shows that incorrect usage of a cipher can completely undermine the security of a
cryptosystem [BGW01].
4.4.1
CSS
Content Scramble System (CSS) is a proprietary
Bytes of
Ciphertext
cryptosystem used to encrypt information stored
on a Digital Versatile Disc (DVD). A DVD is
the widely adopted successor of high capacity
Compact Disc (CD) storage system. It is a Digital Rights Management (DRM) system which is
designed to prevent unauthorized duplication.
!""#$%&'$(&)*'+,-.$
+
Lk
Lk
+
Table
lookup
Table
lookup
Lk
Lk
+
Lk
+
+
Table
lookup
Table
lookup
Table
lookup
4
Table
lookup
Table
lookup
Lk
Lk
Lk
3
Table
lookup
Table
lookup
+
+
2
1
0
Table
lookup
Lk
Lk
+
+
+
Bytes of
1
2
3
4
5
The working of the CSS cryptosystem Plaintext
was
first published in [Ste99]. The same article idenFigure 4.15: CCS
tifies serious weaknesses in the system and shows
decryption
[Kes00]
that the 40-bit secret key can be recovered with
25
a computational complexity of only 2 operations. A more detailed overview of the weaknesses and attacks are presented in the
slides [Kes00] of a lecture about CSS.
4.4.2
E0
Bluetooth is a wireless communication standard
designed in 1999 by the Bluetooth Special Interest Group (SIG). The specification defines the
use of a proprietary stream cipher algorithm E0
to encrypt communication between Bluetooth devices. The first attack on the E0 stream cipher
was published in the literature shortly after its
introduction [HN00]. The attack is based on a
general correlation attack technique as described
in Section 3.2.3.
x1t
LFSR1
x2t
LFSR2
zt
⊕
x3t
LFSR3
c0t
x4t
LFSR4
ct+1
z −1
T1
⊕
T2
⊕
z −1
ct
+
+
yt
.
2
st+1
Figure 4.16: E0 cipher [DCJP01]
The article drew the attention of the cryptographic community which generated many improvements and theoretical attacks over the last decade [DCJP01, FL01, Flu02,
GBM02, Kra02, AK03, Cou03a, LV04a, LV04b, LMV05, LW05, SW06, LV08,
PDMS09]. Finally, a recently published article [ZXF13] identifies serious weaknesses
in the cipher which can be exploited in a practical attack that recovers the complete
128-bit secret key.
80
4.4.3
Skipjack
Skipjack is a proprietary block cipher that depends on
an 80-bit secret key. It was designed by the National
Security Agency (NSA) of the United States (US). Its
design was classified, implemented and distributed only
in a closed hardware device, called the Clipper chip. The
NSA started to promote the use of the chip to the industry in 1993. For instance, Telecom providers could use
the encryption to protect the confidentiality of telephone
conversations. To be able to use the chip, every secret
key had to be shared with the US government. This
raised a lot of opposition by the general public.
The Electronic Frontier Foundation (EFF) and Electronic Privacy Information Center (EPIC) defended the
public’s privacy rights by opposing the use of the Clipper
chip. It would subject citizens to increased and possibly
illegal government surveillance. Furthermore, since the
design was classified, the actual strength of the Clipper
chip’s encryption could not be evaluated. In spite of the
NSA’s effort, the Clipper chip was not embraced by consumers or manufacturers. Encouragement for its usage
eventually ceased completely around 1996.
G
1
G
Rule A
2
G
3
G
4
G
5
G
6
G
Rule A
7
G
8
G
1
RuleB
10
G
11
G
12
G
13
G
14
RuleB
G
15
G
16
G
Figure 4.17: Skipjack
cipher [BBS99]
The design of Skipjack was declassified in 1998 and
published by the US government. Publication of the design finally allowed public
scrutiny of its security strength. Shortly after publication several minor weaknesses
were identified and attacks on reduced variants of the cipher were proposed [BBD+ 99,
BBS99, KRW99, Gra02]. However, an attack on the full cipher which allows recovery
of the complete 80-bit secret key was not identified. In 2002, a cryptographic attack
on the full cipher was proposed in [Pha02]. Interestingly, several years later the same
author described a much weaker attack on Skipjack in [KP09] and completely ignored
the previous publication [Pha02].
Although the secret key distribution and the secretly designed Clipper chip was
controversial, the design of the proprietary cipher Skipjack does not seem to be very
insecure. It is carefully designed and uses better-evaluated cipher components compared to most proprietary algorithms. Judging by the publications in the literature
there are no practical attacks available.
However, many cryptographers quickly lost interest after the initial cryptanalytic
assessment. The deployment of the Clipper chip had failed and with its declassification
it became clear that the algorithm would actually never be deployed. Furthermore,
there were alternative block ciphers proposed in the literature [DR98] with better
security properties, such as the use of a 128-bit secret key.
4.4.4
81
RC4
Rivest Cipher 4 (RC4) is one of the most
widely deployed proprietary stream ciphers. The algorithm was designed in
1987 and commercially sold to the industry. It was originally considered a
trade-secret and only available under a
Non-Disclosure Agreement (NDA). RC4
was named after its creator Ron Rivest,
a cryptographer who also took part in
designing the well-known Rivest, Shamir
and Adleman (RSA) algorithm [RSA78].
"
*
'
!
$
#)*+,#)"+
*
"
$%& $%- $%%
#
#)*+
(
#)"+
#)*+,#)"+
Figure 4.18: RC4 cipher5
RC4 is preferred by many developers of software oriented cryptosystems, since its
design is byte-oriented and does not use hardware friendly bit-wise operators. The
software representation is very small and fits in just a few lines of code, while the
internal state is much larger (256 bytes) compared to other stream ciphers. Although
the design is already more than 20 years old, it is still used in many versions of popular
communication protocols such as Transport Layer Security (TLS), Secure Shell (SSH)
or to encrypt network traffic in Virtual Private Network (VPN), Wired Equivalent
Privacy (WEP) and Wi-Fi Protected Access (WPA).
In 1994 source code appeared on the internet which implemented the RC4 algorithm, it was anonymously posted on a mailing-list6 and public newsgroup7 . There
were several weaknesses identified in the cipher [Roo95, Gol97b, MT99, KWH99,
FMS01, MS02, Mir02, PP04, BGN05, Man05b, VV07, PM07, MK08, Kle08, BC08,
SVV11a, SVV11b, MPG11, ABP+ 13, GMPS14]. However, if used in a correct manner with a long randomly initialized internal state it is much more secure than most
proprietary algorithms.
The RC4 cipher usage specification is not very strict. It allows secret keys with
various lengths of 40 up to 2048 bits. Furthermore, it does not specify precisely how to
initialize the secret key together with a random challenge or Initialization Vector (IV).
Without clear directions how to use RC4 as a cryptographic building block, it can
be difficult to incorporate the cipher into a larger cryptosystem without introducing
other vulnerabilities.
Section 4.4.5 demonstrates weaknesses in a proprietary cryptosystem which incorporates RC4 in an insecure manner. It affects a widely deployed wireless network
standard which was originally designed to protect the privacy of the transmitted
messages.
5 http://en.wikipedia.org/wiki/RC4
6 http://cypherpunks.venona.com/date/1994/09/msg00304.html
7 https://groups.google.com/d/msg/sci.crypt/TPS_Ix7aTJ4/oPwa0skAoxAJ
82
4.4.5
WEP
Wired Equivalent Privacy (WEP) is a
protocol for encrypting wireless network
communication. It was officially introduced as part of the IEEE 802.11 network standard [C+ 07] in 1999. All packets in a WEP network are encrypted
with the proprietary stream cipher RC4,
see Section 4.4.4. The WEP protocol
was quickly adopted by the industry and
embedded in millions of devices [Mil01].
!N
!PB$BQFBRQ$B>P
NHS$>A&T!NU
#HH%
60K
762L
JJ
9H@&#$AHQV
0B?DHA&
$HO$
8"7&9H@
7FQBP$HO$
JJ
060,M)
!P$HCAB$@&0DHSW&NQFXH&T!0NU
!"##$%"
>63:.7&!?#@'()&78-409:;41628&A;2-B&=643.4C
Figure 4.19: WEP encryption
protocol [C+ 07]
Shortly after the introduction of the WEP protocol, several serious weaknesses
were identified in the loading and scheduling of the secret key. First the attack
methodology was published in the literature [FMS01], swiftly followed by an experiment that demonstrated the feasibility of the proposed attack [SIR02]. It requires
negligible computational power and depends on cipher text only, which can easily be
intercept by an adversary without being detected [BGW01]. Initially, the amount of
network traffic that should be intercepted was substantial. However, the fact that a
complete 104-bit key could be recovered with a passive attack, clearly demonstrated
that WEP could not provide adequate security. In response, the IEEE in collaboration with the Wi-Fi Alliance announced in 2003 [WIF03] that Wired Equivalent Privacy (WEP) had been deprecated and superseded by Wi-Fi Protected Access (WPA).
Although WEP was superseded by WPA, the network protocol was still the default protocol in most wireless consumer networks. The industry did not understand
the seriousness and practical impact of the in their view “sophisticat attacks” [Mil01].
In the years after more optimized and practical attacks were proposed in the literature [CWHWW03, HA03, SIR04, Man05a, BHL06, C+ 06, TWP07, TB09]. An attack
that was recently published in the litereature [SSVV13] shows that the full attack only
requires 5 seconds on an off-the-shelf Personal Computer (PC).
Chapter 5
Introduction to Radio Frequency
Identification (RFID)
Radio Frequency Identification (RFID) is a digital identification technology that uses the modulation of Radio
Frequency (RF) waves as communication channel. RFID
devices transmit small amounts of data wirelessly over a
short distance. The technique is introduced as successor of the legacy identification systems such as bar codes,
entrance tickets and personal passes. Figure 5.1 shows
a contactless smartcard that embeds an RFID chip and
Figure 5.1: RFID chip1
antenna. It uses Radio Frequency (RF) waves to communicate messages. Initially these messages consisted of just a Unique Identifier (UID)
which were just used to identify one side to another. In later developments more
messages and features were added.
An RFID system consists of two communicating components, an interrogator and
a responder. The interrogator is referred to as reader. It is in charge of the “conversation” and asks the “questions”. The responder is referred to as tag or transponder,
as it simply “answers” within a predefined time-frame to the interrogator’s questions.
The chapter is divided into two main sections. First, Section 5.1 presents the
technology details and their application in security products, followed by an overview
of RFID research tools in Section 5.2.
5.1
Technology and application
There is a huge variety of tags on the market. They differ in size, casing, memory,
computing power and the various security features they provide. Despite the difference
in appearance and functionality, there are two main categories of RFID tags: passive
and active ones. The passive tags operate without a battery and completely rely
on power drained from the electro-magnetic field which is generated by the reader.
Passive tags are often much cheaper to deploy. However, they have only limited
computational capabilities and a small communication distance. Active tags possess
1 http://rfid-handbook.de/downloads/images/hf-kommunikationsprinzip.png
84
Introduction to Radio Frequency Identification (RFID)
a small battery as a power supply. They are slightly more expensive, yet do not suffer
from the constraints caused by limited power.
The cryptosystems that are addressed in Part II of this dissertation are found
in passive RFID tags. Therefore, the scope of this section is limited to related
techniques. A summary of RFID signal processing is given in Section 5.1.1. The
communication protocols of RFID tags are specified in several standards published
by the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC). An overview of the standards involved is presented
in Section 5.1.2. The successor technique, which is heavily dependent on RFID communication techniques and protocols is the Near Field Communication (NFC) technology. Some cryptosystems that are assessed in Part II use NFC-compatible tags.
The technical relation and security implication are addressed in Section 5.1.3.
5.1.1
Signal modulation and encoding
The carrier that provides power to a tag is also used for communication. At the
physical layer of the communication, the sender has to transform the information to an
analog signal. This analog signal is captured at the receiver side and transformed back
to the original digital message that was sent. The main steps of this transformation
consist of encoding and modulation. It is important that these steps can be reversed
by first demodulating and then decoding the signal.
The reader-to-tag communication is in most cases achieved by interrupting the
carrier wave for a couple of microseconds. Because the field is dropped for only a
very short period, a simple capacitor in the tag can overcome the interruption of
power. The tag-to-reader communication is different, since the tag cannot interrupt
the carrier wave that is generated by the reader. Instead, it modulates the signal by
putting some resistance on the (sub)carrier wave of the reader.
There are many radio frequency signal modulation and encoding schemes. RFID
systems often use one of the following modulation techniques: Amplitude-Shift Keying
(ASK), Frequency-Shift Keying (FSK), On-Off Keying (OOK), Phase-shift keying
(PSK). Additionally, transmission and framing of the actual bits is done by one of
the following encoding schemes: Bi-Phase (BP), Binary Pulse Length Modulation
(BPLM), Non-Return-to-Zero (NRZ) and Quad Pulse Length Modulation (QPLM).
More details about the workings of these techniques are available in the doctoral
dissertation of de Koning Gans [dKG13].
5.1.2
Communication standards
There are many standards for RFID technology and a wide variety of different frequencies are available for RFID applications. The most-often used frequencies are in
the Low Frequency (LF) band at 125-134 kHz and in the High Frequency (HF) band
at 13.56 MHz. RFID communication schemes often focus on the three lowest layers of
85
the Open Systems Interconnection (OSI) model, namely the network layer, data link
layer and the physical layer. These layers facilitate the communication up to the bit
level of messages that are sent over the air. The most relevant ISO/IEC documents
that fall within the scope of this study are the low frequency standards [ISO94, ISO96],
the high frequency standards for proximity [ISO01] and vicinity [ISO00].
5.1.3
Near Field Communication (NFC)
The abbreviation RFID is not often used as terminology for consumer products, but
the more catchy term Near Field Communication (NFC) is. The NFC Forum2 , a
consortium of more than 170 multinationals, designs and standardizes RFID-based
technology under the comprehensive term NFC. To summarize the relation between
NFC and RFID technology, the next paragraphs present the main objectives, capabilities and technical aspects of NFC technology.
Near Field Communication (NFC) technology is an extension of several RFID
communication standards [ISO01, ISO00, JIC05]. It combines the high frequency
(13.56 MHz) proximity standards and reformulates them with some additional features into two new communication standards [ISO04, ISO05]. The two main new
features added in these standards are peer-to-peer connections between two active
NFC devices, also referred to as NFC Interface and Protocol (NFCIP), and the emulation of a passive proximity RFID tag. The initial goal behind NFC technology
is to establish more complex wireless channels that operate at a proximity distance.
This makes NFC much more ambitious than RFID systems. The latter is limited
to plain identification, tracking of unique card numbers or storing small monetary
values in the memory of an RFID tag. Because NFC is backwards compatible with
RFID systems, several deployed devices could be accessed by an NFC-enabled device.
These include electronic passports and identity cards based on the International Civil
Aviation Organization (ICAO) standard [ICA03], most contactless public transport
tickets and access control tags that operate at 13.56 MHz.
While RFID standards merely focused on the specification of the modulation,
encoding, and start and stop conditions of the communication, NFC extends its
specification by adding application formats [NFC11, NFC06, NFC10, NFC13] and
integration of (multiple) secure elements [ETS11, ETS08, ISO11, ISO07]. Secure elements are comparable with regular smart cards and are available in many forms, e.g.
contactless smart card, Universal Integrated Circuit Card (UICC), MicroSD card with
RF interface or an internal embedded chip which is integrated into an NFC controller
chip. The latter one is used in the popular Google Nexus phones together with an
UICC that contains the SIM and is supplied by the user’s telephone company.
Many security aspects of NFC depend on the security of the underlying RFID
technology. If the lowest level of communication is proven to be insecure, all technology that depends on its security is considered compromised. Additionally, various
2 http://www.nfc-forum.org
86
othe NFC security issues are identified in the literature [Mul09, VK11, RLS11]; they
target specific NFC standards and NFC-enabled devices.
5.1.4
Contactless smart cards
The usage of RFID tags increased considerably in the last decade. The industry
promoted the technology for various applications, including solutions for security
issues such as counterfeiting, impersonation and vehicle theft. RFID technology is
now widely adopted and used for several security applications.
A well-known example is the usage of RFID technology in several billion actively
used contactless smart cards [Jue06]. Over the last few years, more and more systems adopted contactless smart cards as a replacement for bar codes, magnetic stripe
cards and paper tickets for a wide variety of applications. Contactless smart cards
consist of a small piece of memory that can be accessed wirelessly, although unlike
historical RFID tags, they also have some computing capabilities. Most of these cards
implement some sort of simple symmetric-key cryptography, making them suitable for
applications that require access control to the smart card’s memory.
A number of large-scale applications make use of contactless smart cards. For example, they are used for payment in several public transport systems like the Oyster
card3 in London and the OV chipkaart4 in The Netherlands, among others. Many
countries have already incorporated a contactless smart card in their electronic passports [HHJ+ 06]. Many office buildings and even secured facilities such as airports
and military bases use contactless smart cards for access control.
5.1.5
Proprietary cryptography in RFID devices
Since the first generation of widely deployed RFID tags in the 90s, it has been a tradition for the industry to design proprietary RFID products. Such a proprietary design
often contains customly defined modulation/encoding schemes, packets, checksums,
instruction sets and in some cases even custom made cryptographic algorithms and
authentication protocols.
There is not much wrong with designing a custom way of RFID communication.
It allows the industry to optimize products and boost their performance for specific
applications. However, this argument certainly does not hold for the proprietary
cryptosystems. Designing secure algorithms is proven to be a difficult task without
feedback from the scientific community [Ker83, JS97, fSN97].
The semiconductor industry advocates that proprietary cryptography prevents
counterfeiting [CS05, GB06, GS07]. Unfortunately, it usually leads to a vendor lockin situation [And03, LS04]. It is conceivable that a customer is unaware that the
additional proprietary cryptography hardly increases the security strength. In fact, it
3 http://oyster.tfl.gov.uk
4 http://www.ov-chipkaart.nl
87
mostly just constrains their possibility to migrate to compatible products from other
suppliers in the future.
Almost all major semiconductor companies that produce RFID devices are inclined to create ad hoc RFID designs that use proprietary protocols and custommade cryptographic algorithms [PHI98, MC01, ST02, EM02, TI04, IC04, AT06,
INF07, HID08, AT09, NXP10]. Such designs are often kept secret to provide
security-through-obscurity. As mentioned in Section 1.2, several manufacturers claim
their products provide ‘state-of-the-art’ [IC04], ‘field-proven’ [PHI98, HID08], ‘highlevel’ [ST02, MC01, EM02, KM05, AT06] or ‘unbreakable’5 security. However, it is
hard to know what this means and how much security you actually get. As long as
RFID products do not comply with open and community-reviewed encryption standards, the security properties of such tags cannot be objectively assessed.
5.2
Research tools
There is cheap and off-the-shelf hardware available to communicate with RFID tags,
contactless smart cards and NFC enabled devices. The design and usage of such
hardware is often undocumented and uses a proprietary (and often secret) instruction
set. Moreover, this hardware is typically limited to support only one vendor-specific
RFID tag and does not allow a user to control the raw modulated and encoded
signals. This can be convenient for an engineer who does not want to spend time on
such elementary building blocks of RFID technology. However, for a researcher who
wants to have full control over the modulation depth, encoding variation, protocol
timing, parity bits and checksums, this is not very useful.
There are several open-design hardware projects that aim to overcome this limitation by introducing a tool that allows more access to raw Radio Frequency (RF)
signals [Blo04, RCT05, Ver08a, Ver08b, dKG08, KSB08, dKGV09, KSP10, FAH+ 10,
GdKGV12, VdKGG12]. However, most of these tools are created in an ad hoc manner and are limited to the investigation of specific technology or demonstrate only a
particular functionality. For instance, they are used for quick prototyping and initial testing of the protocols proposed in [VDWKP09, FGMR10, dKGG10, GvR10,
GFMR11, ABV12].
This section limits its attention to two generic hardware tools which proved themselves as best practices in scientific research, the GNURadio6 and the Proxmark7.
Both tools allow full access to raw RF signals and have support for various modulation and encoding techniques. Moreover, these tools are supported by a very active
development community and are used by many research institutes, industries and
individuals. More functional details are presented for the GNURadio in Section 5.2.1
and the Proxmark in Section 5.2.2.
5 http://www.nxp.com/products/automotive/car_access_immobilizers/immobilizer/
6 http://gnuradio.org
7 http://www.proxmark.org
88
5.2.1
GNURadio framework
A GNURadio device is a generic Software Defined Radio (SDR) that supports Radio Frequency (RF) signals on many frequencies, ranging from 0Hz to 6GHz. The
GNURadio framework is fully open-source and named after the recursive acronym
GNU’s Not Unix (GNU), to specify it is Unix compatible, yet it contains only free
software. The device comes with a large Field Programmable Gate Array (FPGA)
that allows the user to virtually build a hardware scheme using a software-based gate
configuration. The GNURadio software framework is not specifically made for RFID
communication schemes. However, it supports almost all relevant modulation and
encoding schemes.
The most often used GNURadio device is the Universal Software Radio Peripheral
(USRP), which is made by the company Ettus Research8. The USRP connects to a
host computer through a high-speed Universal Serial Bus (USB) or Gigabit Ethernet
link, which the host-based software uses to control the USRP hardware. It is possible
to integrate the general functionality of a host computer within the FPGA, which
allows the USRP to operate in a standalone fashion.
The USRP motherboard provides the following features: custom clock frequency,
FPGA, Analog-to-Digital Converter (ADC), Digital-to-Analog Converter (DAC),
USB interface, and variable power regulation. These are the basic components that are
required for baseband processing of signals. A modular front-end, called a daughterboard, is used for analog operations such as up/down-scaling, filtering, and other
signal conditioning. For compatibility with the RFID frequency, two extra hardware
modules (LFRX and LFTX daughter-boards) are required.
The default operation of the FPGA is to perform several Digital Signal Processing
(DSP) operations, which translate real signals in the analog domain to lower-rate,
complex, baseband signals in the digital domain. In most use-cases, these complex
samples are transferred to the host that performs decoding operations. The code
for the FPGA is open-source and can be optimized to allow high-speed, low-latency
operations to occur in the FPGA.
There is no predefined frequency, fixed power regulation and specified clock; all
components are configurable. Such flexibility comes with a price tag. The tool is
quite expensive, it currently costs around USD 2000.
The working environment is extremely powerful, which can be a bit confusing for
an inexperienced user. The main reason is that there are many configuration options
which relate to various well-known communication protocols (e.g. GSM, Dect and
Bluetooth).
There are a few examples in the literature [CCC+ 09, CSY+ 10, CGE12, CG12] of
RFID security research that is performed with a GNURadio USRP device. However,
the more ground-breaking security research that experimented with the GNURadio,
used the tool to evaluate various other radio frequency enabled devices. Well-known
8 http://www.ettus.com/
89
examples are the studies on pacemakers [HHBR+ 08], DECT cordless phones [LST+ 09]
and wireless monitor systems embedded into modern vehicles [IRMTT+ 10].
5.2.2
Proxmark hardware device
The Proxmark tool is similar to a USRP device, yet it is more optimized for (and
limited to) the 125-134 kHz and 13.56 MHz frequency bands, which are used in almost
all low and high frequency RFID tags. Because the Proxmark is made specifically to
support RFID technology, it already supports many RFID communication techniques.
This includes a wide range of modulation and encoding schemes, communication
protocols and most standarized contactless smart card instruction sets.
The Proxmark hardware has been developed by Jonathan Westhues9 . The early
versions of this device were able to clone unsecured tags [GR05, HJSW06], although
they were not as powerful as the third version, which is currently the most recent
version of the Proxmark. For instance, the initial ‘prox card cloner’ could only handle
one type of modulation and was merely designed to clone UID-only tags.
The latest hardware design and firmware is in the public domain since May 2007
under the General Public License (GPL). The device costs around USD 150 and since
the schematics are online, it can be ordered through any local printed circuit board
(PCB) supplier. Alternatively, a completely assembled Proxmark device is available
from two commercial suppliers: Rysc Corp.10 and GeZhi Electronic Corp. Ltd.11 .
The Proxmark community12 provides all the information that is required to assemble,
compile, flash, use and develop new features for the Proxmark.
The Proxmark supports both low (125-134 kHz) and high frequency (13.56 MHz)
signal processing. This is achieved by two parallel antenna circuits that can be used
independently. Both circuits are connected to a 4-pin Hirose connector to connect an
external loop antenna. When the Proxmark is in reader mode it drives the antenna
coils with the appropriate frequency. This is unnecessary when the Proxmark works in
eavesdropping mode or in tag emulation mode because then the electromagnetic field
is generated by the reader. The signal from the antenna is filtered and routed through
the FPGA after it has been digitized by an 8-bit Analog-to-Digital Converter (ADC).
The FPGA relays the necessary information to perform the decoding of the signal to
the micro-controller. This prevents the micro-controller from being overloaded with
signal data. An FPGA has a great advantage over a normal micro-controller in the
sense that it emulates hardware. A hardware description can be compiled and flashed
into an FPGA. Basic arithmetic operations can be performed in parallel and faster
than in a micro-controller. An FPGA is slightly slower than an Application-Specific
Integrated Circuit (ASIC) implementation, however, pure hardware lacks flexibility.
9 http://cq.cx/proxmark3.pl
10 http://www.proxmark3.com
11 http://www.xfpga.com
90
There are several schematics of hardware improvements contributed to the Proxmark project. However, most of them focus on usability like an external battery,
LCD screen or additional input buttons. The third hardware revision of the Proxmark, published in may 2007 by Jonathan Westhues13 , is still the most used and best
supported hardware version.
Since the focus of the Proxmark is merely on RFID technology, it supports a wide
range of techniques that are used in this field. Most RFID communication schemes
are working out-of-the-box using a command line interface. The Proxmark can work
standalone which offers the functionality to perform a sequence of operations very
quickly after each other. This is required for time-dependent operations like anticollision procedures and distance bounding protocols [FGMR10, GFMR11, HK05,
Han05]. The development of the Proxmark software is completely driven by opensource contributors who share their code freely in the public domain.
The user interface is controlled by predefined commands through a command line
interface. These commands can be used to configure the hardware, run a specific test
or to analyze the captured communication data. Almost all types of RFID tags that
are used worldwide are supported. Some RFID tag-specific communication protocols
are only partially implemented. However, the open source nature of the Proxmark
enables a user to rapidly implement, prototype and contribute new features.
The Proxmark device is currently the most-often used tool for RFID security
research. There are many examples in the literature [dKGHG08, GdKGM+ 08,
GvRVWS09, GvRVWS10, GdKGV11, Hen11, HHJK12, GdKGVM12, VGB12, PN12,
VGE13, LXZ13, DvE14] that have prototyped, analyzed and verified their findings
with the Proxmark tool. Besides security research, the Proxmark lends itself very
well for experimenting, rapid prototyping, validation and certification of new communication techniques like the various anti-collision algorithms that were proposed in
the academic community [FGMR10, GFMR11].
Despite the broad support of communication techniques, several custom and unsupported communication schemes were encountered in the course of this study. Several improvements and features were introduced to support additional techniques.
Implementation details are available in the literature [VdKGG12] and the source code
is embedded into the public repository14 .
The Proxmark is used to experiment and verify the theoretical findings during the
study and is presented in Part II (the technical section). The Proxmark proved itself
to be versatile, reliable, fast and easy to extend. During the course of our research
we extended the code base of the Proxmark device.
13 http://cq.cx/dl/proxmark3-may23-2007.zip
14 https://github.com/Proxmark
Part II
Technical section
Chapter 6
MIFARE Classic
The Mifare Classic is the most widely used contactless smartcard on the market. We
reverse engineered the security mechanisms of this chip: the authentication protocol,
the stream cipher CRYPTO1, and the initialization mechanism [GdKGM+ 08]. We
show several security vulnerabilities in these mechanisms and exploit these vulnerabilities with two attacks; both are capable of retrieving the secret key from a genuine
reader.
The most serious attack described in [GdKGM+ 08] retrieves a secret key in under
a second. In order to clone a card, these attacks require that the adversary either has
access to an eavesdropped communication session or executes a message-by-message
man-in-the-middle attack between the victim and a legitimate reader. Although this
is already disastrous from a cryptographic point of view, system integrators maintain
that these attacks cannot be performed without being detected.
This chapter proposes four attacks that can be executed by an adversary having
only wireless access to just a card (and not to a legitimate reader). The most serious
of them recovers a secret key in less than a second on ordinary hardware. Besides
the cryptographic weaknesses, we exploit other weaknesses in the protocol stack.
A vulnerability in the computation of parity bits allows an adversary to establish a
side channel. Another vulnerability regarding nested authentications provides enough
plaintext for a speedy known-plaintext attack.
6.1
Introduction
With more than one billion cards sold, the Mifare Classic covers more than 70% of the
contactless smartcard market1 . Such cards contain a slightly more powerful IC than
classical RFID chips (developed for identification only), equipping them with modest
computational power and making them suitable for applications beyond identification,
such as access control and ticketing systems.
The Mifare Classic is widely used in public transport payment systems such as the
Oyster card2 in London, the Charlie Card in Boston3 , the SmartRider in Australia4 ,
1 http://www.nxp.com
2 http://oyster.tfl.gov.uk
3 http://www.mbta.com/fares_and_passes/charlie
4 http://www.transperth.wa.gov.au
94
MIFARE Classic
EasyCard in Taiwan5 , and the OV-chipkaart6 in The Netherlands. It is also widely
used for access control in office and governmental buildings and entrance to military
bases.
According to [PHI98] the Mifare Classic complies with Parts 1 to 3 of the ISO
standard 14443-A [ISO01], specifying the physical characteristics, the radio frequency
interface, and the anti-collision protocol. The Mifare Classic does not implement
Part 4 of the standard, describing the transmission protocol, but instead uses its own
secure communication layer. In this layer, the Mifare Classic uses the proprietary
stream cipher CRYPTO1 to provide data confidentiality and mutual authentication
between card and reader.
Our contribution. In this chapter, we show serious vulnerabilities of the Mifare
Classic that enable an attacker to retrieve all cryptographic keys of a card, just by
wirelessly communicating with it. Thus, the potential impact is much larger than
that of the problems previously reported in [WSvRG+ 08, NESP08, Noh08, CNO08,
dKGHG08], where the attacker either needs to have access to a legitimate reader or
an eavesdropped communication session. The attacks described in this chapter are
fast enough to allow an attacker to wirelessly ‘pickpocket’ a victim’s Mifare Classic
card, i.e., to clone it immediately.
Vulnerabilities
The vulnerabilities we discovered concern the handling of parity bits and nested authentications.
• The Mifare Classic sends a parity bit for each byte that is transmitted. Violating
the standard, the Mifare Classic mixes the data link layer and secure communication layer: parity bits are computed over the plaintext instead of over the
bits that are actually sent, i.e., the ciphertext. This is, in fact, authenticatethen-encrypt which is generically insecure [Kra01].
Furthermore, parity bits are encrypted with the same bit of keystream that
encrypts the first bit of the next byte of plaintext. During the authentication
protocol, if the reader sends wrong parity bits, the card stops communicating.
However, if the reader sends correct parity bits, but wrong authentication data,
the card responds with an (encrypted) error code. This breaks the confidentiality of the cipher, enabling an attacker to establish a side channel.
• The memory of the Mifare Classic is divided into sectors, each of them having
its own 48-bit secret key. To perform an operation on a specific sector, the
reader must first authenticate using the corresponding key. When an attacker
has already authenticated for one sector (knowing the key for that sector) and
5 http://www.easycard.com.tw
6 http://www.ov-chipkaart.nl
MIFARE Classic
95
subsequently attempts to authenticate for another sector (without knowing the
key for this sector), that attempt leaks 32 bits of information about the secret
key of that sector.
Attacks
We describe four attacks exploiting these vulnerabilities to recover the cryptographic
keys from a Mifare Classic card having only contactless communication with it (and
not with a legitimate reader). These attacks make different trade-offs between online
communication time (the time an attacker needs to communicate with a card), offline
computation time (the time it takes to compute the cryptographic key using the data
gathered from the card), precomputation time (one-time generation time of static
tables), disk space usage (of the static tables) and special assumptions (whether the
attacker has already one sector key or not).
• The first attack exploits the weakness of the parity bits to mount an offline
brute-force attack on the 48-bit key space. The attacker only needs to try to
authenticate approximately 1500 times (which takes under a second).
• The second attack also exploits the weakness of the parity bits but this time
the attacker mounts an adaptive chosen ciphertext attack. The attacker needs
approximately 28 500 authentication attempts. In this attack, she needs to
make sure that the challenge nonce of the card is constant, which is why this
takes approximately fifteen minutes. During these authentication attempts,
the attacker adaptively chooses her challenge to the card, ultimately obtaining
a challenge that guarantees that there are only 436 possibilities for the oddnumbered bits of the internal state of the cipher. This reduces the offline search
space to approximately 33 bits. On a standard desktop computer, with a single
core running at 2 GHz, this search takes about one minute.
• In the third attack the attacker keeps her own challenge constant, but varies the
challenge of the tag, again ultimately obtaining a special internal state of the
cipher. These special states have to be precomputed and stored in a 384 GB table. This attack requires on average 212 = 4096 authentication attempts, which
could in principle be done in about two minutes. A few extra authentication
attempts allow efficient lookup in the table.
• The fourth attack assumes that the attacker has already recovered at least
one sector key. When the attacker first authenticates for this sector and then
for another sector, the authentication protocol is slightly different, viz., the
challenge nonce of the tag is not sent in the clear, but encrypted with the key of
the new sector. Because the random number generator has only a 16-bit state,
because parity bits leak three bits of information, and because the tag’s random
number generator runs in sync with the communication timing, this allows an
96
MIFARE Classic
attacker to guess the plaintext tag nonce and hence 32 bits of keystream. Due
to weaknesses decribed in Section 6.3, we can use these 32 bits of keystream to
compute approximately 216 candidate keys. These can then be checked offline
using another authentication attempt. Since this attack only requires three
authentication attempts, the online time is negligible. The offline search takes
under a second on ordinary hardware.
Related work
De Koning Gans et al. [dKGHG08] have proposed an attack on a Mifare Classic tag
that exploits the malleability of the CRYPTO1 stream cipher to read partial information from a tag, without even knowing the encryption algorithm. By slicing a Mifare
Classic chip and taking pictures with a microscope, the cipher was reverse engineered
by Nohl et al. [NESP08]. Courtois et al. claim in [CNO08] that the CRYPTO1 cipher
is susceptible to algebraic attacks and Nohl shows a statistical weakness of the cipher
in [Noh08].
Impact
The implications of the attacks described in this chapter are vast.
Many ticketing and payment systems using the Mifare Classic sequentially authenticate for several sectors verifying the data in the card. In the case of invalid
data, the protocol aborts. With previous attacks, this means that an attacker has to
either eavesdrop a full trace or walk from the reader to the card holder several times,
executing a message-by-message man-in-the-middle attack. In practice, both options
are hard to accomplish without being detected. Furthermore, there is no guarantee
that this allows an attacker to recover all useful data in the card, since some sectors
might not be read in this particular instance. Our attacks always enable an attacker
to retrieve all data from the card.
Our fourth attack, where the attacker already knows a single key, is extremely fast
(less than one second per key on ordinary hardware). The first key can be retrieved
using one of our first three attacks, but in many situations this is not even necessary.
Most deployed systems leave default keys for unused sectors or do not diversify keys
at all. Nearly all deployed systems that do diversify have at least one sector key
that is not diversified, namely for storing the diversification information. This is even
specified in NXP’s guideline for system integrators [NXP13]. This means that it is
possible for an adversary to recover all keys necessary to read and write the sixteen
sectors of a Mifare Classic 1k tag in less than sixteen seconds.
Overview
We start by gathering the relevant information that is already known about the
Mifare Classic in Section 6.2: its logical structure, the encryption algorithm, the
MIFARE Classic
97
authentication protocol and the initialization of the stream cipher, how to undo the
initialization of the stream cipher, and information about how the tag generates its
random numbers. The complete process of reverse-engineering the Mifare classic
security mechanisms is addressed in Section 6.3. In Section 6.4, we continue with
a precise description of the discovered weaknesses in the handling of the parity bits
and nested authentications. In Section 6.5, we show how these weaknesses can be
exploited to recover a sector key by communication with just a card. Section 6.6
gives some concluding remarks.
6.2
6.2.1
Background
Hardware setup
For this experiment we designed and built a custom device for tag emulation and
eavesdropping. This device, called Ghost, is able to communicate with a contactless
smart card reader, emulating a tag, and eavesdrop communication between a genuine
tag and reader. The Ghost is completely programmable and is able to send arbitrary
messages. We can also set the uid of the Ghost which is not possible with manufacturer tags. The hardware cost of the Ghost is approximately 40 USD. We also used
a Proxmark7, a generic device for communication with RFID tags and readers, and
programmed it to handle the ISO14443-A standard. As it provides similar functionality to the Ghost, we do not make a distinction between these devices in the remainder
of the chapter.
On the reader side we used an OpenPCD reader8 and an Omnikey reader9 . These
readers contain a MIFARE Classic chip implementing the CRYPTO1 cipher and are
fully programmable.
6.2.2
Communication
The physical layer and data link layer of the Mifare family of cards are described in
the ISO standard 14443-A. We have used the Proxmark10 for communication; this
device implements, among others, these two layers of this standard and can emulate
both a card and a reader.
Using information from [dKGHG08] about the command codes of the Mifare Classic and through reverse-engineering the cryptographic aspects of the Mifare Classic,
we implemented the functionality of a Mifare Classic reader on the Proxmark. Note
that we can observe a tag’s communication at the data link level, implying that we
can observe the parity bits as well. Furthermore, we have the freedom to send arbitrary parity bits, which is not possible using stock commercial Mifare Classic readers.
7 http://cq.cx/proxmark3.pl,http://www.proxmark.org
8 http://www.openpcd.org
9 http://omnikey.aaitg.com
10 http://www.proxmark.org/
98
MIFARE Classic
However, many newer NFC readers can be used to communicate with a Mifare Classic
card as well and are capable of sending and receiving arbitrary parity bits.11 We have
also executed the attacks described in this chapter using an inexpensive (USD 30)
stock commercial NFC reader. However, these readers are typically connected to a
host PC using USB and it is harder to obtain accurate communication timing.
6.2.3
Memory structure of the Mifare Classic
The Mifare Classic tag is a memory chip with secure wireless communication capabilities. The memory of the tag is divided into sectors, each of which is further divided
into blocks of sixteen bytes each. The last block of each sector is the sector trailer; it
stores two secret keys and the access conditions for that sector.
Figure 6.1: Memory layout of the Mifare Classic
To perform an operation on a specific block, the reader must first authenticate for
the sector containing that block. The access conditions determine which of the two
keys must be used. See Figure 6.1 for an overview of the memory of a Mifare Classic
tag.
6.3
Reverse-engineering MIFARE Classic
This section describes the reverse engineering of the MIFARE Classic Classic chip.
We do so by recording and studying traces from communication between tags and
readers. We recover the encryption algorithm and the authentication protocol.
When the tag enters the electromagnetic field of the reader and powers up, it
immediately starts the anti-collision protocol by sending its uid. The reader then
selects this tag as specified in ISO14443-A [ISO01].
According to the manufacturer’s documentation, the reader then sends an authentication request for a specific block. Next, the tag picks a challenge nonce nT
11 http://www.libnfc.org/
MIFARE Classic
99
and sends it to the reader in the clear. Then the reader sends its own challenge
nonce nR together with the answer aR to the challenge of the tag. The tag finishes
authentication by replying aT to the challenge of the reader. Starting with nR , all
communication is encrypted. This means that nR , aR , and aT are XOR-ed with the
keystream ks1 , ks2 , ks3 . Figure 6.2 shows an example.
Step
01
02
03
04
05
06
07
08
09
10
Sender
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
Hex
26
04
93
c2
93
08
60
42
7d
8b
00
20
a8
70
b6
30
97
db
d4
2d
c2
dd
76
c0
9b
10
f4 b3
a8 2d f4 b3 ba a3
4a
a4
83 67 eb 5d 83
08
Abstract
req type A
answer req
select
uid,bcc
select(uid)
Mifare 1k
auth(block 30)
nT
nR ⊕ ks1 , aR ⊕ ks2
aT ⊕ ks3
Figure 6.2: Authentication trace of the messages communicated between a
genuine Mifare Classic card and an RFID reader
We started experimenting with the Ghost and an OpenPCD reader which we
control. The pseudo-random generator in the tag is fully deterministic. Therefore
the nonce it generates only depends on the time between power up and the start
of communication [NP07]. Since we control the reader, we control this timing and
therefore can get the same tag nonce every time. With the Ghost operating as a
tag, we can choose custom challenge nonces and uids. Furthermore, by fixing nT
(and uid) and repeatedly authenticating, we found out that the reader produces the
same sequence of nonces every time it is restarted. Unlike in the tag, the state of
the pseudo-random generator in the reader does not update every clock tick but with
every invocation.
The pseudo-random generator in the tag used to generate nT is a 16-bit LFSR
with generating polynomial x16 + x14 + x13 + x11 + 1. Since nonces are 32 bits long
and the LFSR has a 16 bit state, the first half of nT determines the second half. This
means that given a 32 bit value, we can tell if it is a proper tag nonce, i.e., if it could
be generated by this LFSR. To be precise, a 32 bit value n0 n1 . . . n31 is a proper tag
nonce if and only if nk ⊕ nk+2 ⊕ nk+3 ⊕ nk+5 ⊕ nk+16 = 0 for all k ∈ {0, 1, . . . , 15}.
Every clock tick the LFSR shifts to the left and the feedback bit is computed using
L16 .
Definition 6.3.1. The feedback function L16 : F16
2 → F2 of the pseudo-random generator is defined by
L16 (x0 x1 . . . x15 ) := x0 ⊕ x2 ⊕ x3 ⊕ x5 .
Let us define the function suc that computes the next 32-bit LFSR sequence of
the 16-bit LFSR. This function is used later on in Section 6.3.1 in the authentication
protocol.
100
MIFARE Classic
32
Definition 6.3.2. The successor function suc : F32
2 → F2 is defined by
suc(x0 x1 . . . x31 ) := x1 x2 . . . x31 L16 (x16 x17 . . . x31 ) .
Because the period of the pseudo-random generator is only 65 535 and because
it shifts every 9.44 µs, it cycles in 618 ms. Under similar physical conditions (i.e.,
do not move the tag or the reader), the challenge nonce that the tag generates only
depends on the time between the moment the reader switches on the electromagnetic
field and the moment it sends the authentication request. In practice, this means
that an attacker who has physical control of the tag, can get the tag to send the same
nonce every time. To do so, the attacker just has to drop the field (for approximately
30 µs) to discharge all capacitors in the tag, switch the field back on, and wait for a
constant amount of time before authenticating.
Alternatively, by waiting exactly the right amount of time before authenticating
again, the attacker can control the challenge nonce that the tag will send. This works
whenever the tag does not leave the electromagnetic field in the mean time. On
average, this takes 618 ms/2 = 309 ms.
The Ghost can send arbitrary values as nonces and is not restricted to sending
proper tag nonces. Experimenting with authentication sessions with various uids and
tag nonces, we noticed that if nT ⊕ uid remains constant, then the ciphertext of the
encrypted reader nonce also remains constant. The answers aT and aR , however,
have different ciphertexts in the two sessions. For example, in Figure 6.2 the uid is
0xc2a82df4 and nT is 0x4297c0a4, therefore nT ⊕ uid is 0x803fed50. If we instead
take uid to be 0x1dfbe033 and nT to be 0x9dc40d63, then nT ⊕ uid still equals
0x803fed50. In both cases, the encrypted reader nonce nR ⊕ ks1 is 0x7ddb9b83.
However, in Figure 6.2, aR ⊕ ks2 is 0x67eb5d83 and aT ⊕ ks3 is 0x8bd41008, while
with the modified uid and nT they are, respectively, 0x4295c446 and 0xeb3ef7da.
This suggests that the keystream in both runs is the same and it also suggests
that aT and aR depend on nT . By XOR-ing both answers aR ⊕ ks2 and a′R ⊕ ks2
together we get aR ⊕ a′R . We noticed that aR ⊕ a′R is a proper tag nonce. Because
the set of proper tag nonces is a linear subspace of F32
2 , where F2 is the field of two
elements, the XOR of proper tag nonces is also a proper tag nonce. This suggests
that aR and a′R are also proper tag nonces.
Given a 32-bit nonce nT generated by the LFSR, one can compute the successor
suc(nT ) consisting of the next 32 generated bits. At this stage we could verify that
aR ⊕ a′R = suc2 (nT ⊕ n′T ) = suc2 (nT ) ⊕ suc2 (n′T ) which suggests that aR = suc2 (nT )
and a′R = suc2 (n′T ). Similarly for the answer from the tag we could verify that
aT = suc3 (nT ) and a′T = suc3 (n′T ).
6.3.1
Tag and reader authentication protocol
Summarizing, the authentication protocol can be described as follows; see Figure 6.3.
After the nonce nT is sent by the tag, both tag and reader initialize the cipher with the
MIFARE Classic
101
shared key K, the uid, and the nonce nT . The reader then picks its challenge nonce
nR and sends it encrypted with the first part of the keystream ks1 . Then it updates
the cipher state with nR . The reader authenticates by sending suc2 (nT ) encrypted,
i.e., suc2 (nT ) ⊕ ks2 . At this point the tag is able to update the cipher state in the
same way and verify the authenticity of the reader. The remainder of the keystream
ks3 , ks4 . . . is now determined and from now on all communication is encrypted, i.e.,
XOR-ed with the keystream. The tag finishes the authentication protocol by sending
suc3 (nT ) ⊕ ks3 . Now the reader is able to verify the authenticity of the tag.
Tag
0
1
2
3
picks nT
4
5
6
7
ks1 ← cipher(K, uid, nT )
8
9
ks2 , . . . ← cipher(nR )
Reader
anti-c(uid)
−−−−−−−−−−−−−−−−−−−−→
auth(block)
←
−−−−−−−−−−−−−−−−−−−−
nT
−−−−−−−−−−−−−−−−−−−−→
nR ⊕ ks1 , suc2 (nT ) ⊕ ks2
←
−−−−−−−−−−−−−−−−−−−−
ks1 ← cipher(K, uid, nT )
picks nR
ks2 , . . . ← cipher(nR )
suc3 (nT ) ⊕ ks3
−−−−−−−−−−−−−−−−−−−−→
Figure 6.3: Mutual authentication protocol between tag and reader
6.3.2
Initialization
The LFSR is initialized during the authentication
protocol. As before, we experimented running several authentication sessions with varying parameters. As we mention in Section 6.3.1, if nT ⊕ uid
remains constant, then the encrypted reader nonce
also remains constant. This suggests that nT ⊕ uid
is first fed into the LFSR. Moreover, experiments
showed that, if special care is taken with the feedFigure 6.4: Initialization
back bits, it is possible to modify nT ⊕ uid and
Diagram.
the secret key K in such a way that the ciphertext after authentication also remains constant. Concretely, we verified that if
nT ⊕ uid ⊕ K ⊕ ‘feedback bits’ remains constant, then the keystream generated after
authentication is constant as well. Here the ‘feedback bits’ are computed according
to the feedback polynomial of the LFSR. This suggests that the secret key K is the
initial state of the LFSR.
Proceeding to the next step in the authentication protocol, the reader nonce nR is
fed into the LFSR as well. Note that earlier bits of nR already affect the encryption
of the later bits of nR . At this point, the initialization is complete and the input bit
of the LFSR is no longer used. Figure 6.4 shows the initialization diagram for both
reader and tag. The only difference between both sides is that the reader generates
102
MIFARE Classic
nR and then computes and sends nR ⊕ ks1 , while the tag receives nR ⊕ ks1 and then
computes nR .
Note that we can, by selecting an appropriate key K, uid, and tag nonce nT ,
completely control the state of the LFSR just before feeding in the reader nonce. In
practice, if we want to observe the behavior of the LFSR starting in state α, we often
set the key to 0, let the Ghost select a uid of 0 and compute which nT we should let
the Ghost send to reach the state α. Now, because nT is only 32 bits long and α is
48 bits long, this does not seem to allow us to control the leftmost 16 bits of α: they
will always be 0. In practice, however, many readers accept and process tag nonces
of arbitrary length. So by sending an appropriate 48-bit tag nonce nT , we can fully
control the state of the LFSR just before the reader nonce. This will be very useful
in the next section, where we describe how we recovered the filter function f .
6.3.3
Filter function
The first time the filter function f is used, is when the first bit of the reader nonce,
nR,0 , is transmitted. At this point, we fully control the state α of the LFSR by setting
the uid, the key, and the tag nonce. As before, we use the Ghost to send a uid of 0,
use the key 0 on the reader, and use 48-bit tag nonces to set the LFSR state. So, for
values α of our choice, we can observe nR,0 ⊕ f (α), since that is what is being sent by
the reader. Since we power up the reader every time, the generated reader nonce is
the same every time. Therefore, even though we do not know nR,0 , it is a constant.
The first task is now to determine which bits of the LFSR are inputs to the filter
function f . For this, we pick a random state α and observe nR,0 ⊕ f (α). We then vary
a single bit in α, say the ith, giving state α′ , and observe nR,0 ⊕f (α′ ). If f (α) 6= f (α′ ),
then the ith bit must be input to f . If f (α) = f (α′ ), then we can draw no conclusion
about the ith bit, but if this happens for many choices of α, it is likely that the ith
bit is not an input to f .
Sender
Reader
Ghost
Reader
Ghost
Reader
Ghost
Reader
Ghost
Reader
Hex
Hex
26
26
04 00
04 00
93 20
93 20
00 00 00 00 00
00 00 00 00 00
93 70 00 00 00 00 00 9c d9
93 70 00 00 00 00 00 9c d9
08 b6 dd
08 b6 dd
60 00 f5 7b
60 00 F5 7B
6d c4 13 ab d0 f3
6d c4 13 ab d0 73
df 19 d5 7a e5 81 ce cb
5e ef 51 1e 5e fb a6 21
req type A
answer req
select
uid,bcc
select(uid)
Mifare 1k
auth(block 0)
nT
nR ⊕ ks1 , suc2 (nT ) ⊕ ks2
Figure 6.5: Nearly equal LFSR states
Figure 6.5 shows an example. The key in the reader (for block 0) is set to 0 and
the Ghost sends a uid of 0. On the left hand side, the Ghost sends the tag nonce
MIFARE Classic
103
0x6dc413abd0f3 and on the right hand side it sends the tag nonce 0x6dc413abd073.
This leads, respectively, to LFSR states of 0xb05d53bfdb10 and 0xb05d53bfdb11.
These differ only in the rightmost bit, i.e., bit 47. On the left hand side, the first
bit of the encrypted reader nonce is 1 and on the right hand side it is 0 (recall the
byte-swapping convention used in traces). Hence, bit 47 must be an input to the filter
function f .
This way, we were able to see that the bits 9, 11, . . . , 45, 47 are input to the filter
function f . We guessed that there are 5 “first layer circuits” each taking four inputs,
respectively, 9, 11, 13, 15 for the left-most circuit up to 41, 43, 45, 47 for the rightmost circuit. The five results from these circuit are then, we guessed, input into a
“second layer circuit”, producing a keystream bit. (See Figure 6.7 for the structure
of CRYPTO1). Note, that all these circuits implement balanced functions.
LFSR \ XX
0xb05d53bfdbXX
0xfbb57bbc7fXX
0xe2fd86e299XX
55
0
1
1
54
0
1
1
51
0
1
1
50
0
1
1
45
1
0
1
44
1
0
1
41
0
1
1
40
1
0
1
15
1
0
1
14
1
0
1
11
0
1
1
10
1
0
1
05
0
1
1
04
0
1
1
01
1
0
1
00
1
0
1
Figure 6.6: First bit of encrypted reader nonce
To verify our guess and to determine f , we again take a random state α of the
LFSR. We then vary 4 (guessed) inputs to a first layer circuit in all 16 ways possible,
giving states α0 , α1 , . . . α15 and observe r0 ⊕ f (α0 ), . . . , r0 ⊕ f (α15 ). If our guess was
correct, we expect these to be 16 zeros, 16 ones, or 8 zeros and 8 ones: either the 16
non-varying inputs are such that the 4 varying inputs do not influence the keystream
bit (in which case we get all zeros or all ones), or we get a “balanced” result as in
the Hitag2. In the first two cases, we try again; in the latter case, we have found
the component (up to a NOT, but that is irrelevant). Figure 6.6 shows examples of
LFSRs that vary the inputs to a first layer circuit.
It turned out that our guess was correct; there are two different circuits used in the
first layer. Two circuits in the first layer compute fa (x3 , x2 , x1 , x0 ) represented by the
boolean table 0x26c7 and the other three compute fb (x3 , x2 , x1 , x0 ) represented by
the boolean table 0x0dd3. I.e., from left to right the bits of 0x26c7 are the values of
fa (1, 1, 1, 1), fa (1, 1, 1, 0), . . . , fa (0, 0, 0, 0) and similarly for fb (and fc below). These
five output bits are input into the circuit in the second layer. By trying 32 states that
produce all 32 possible outputs for the first layer, we build a table for the circuits in
the second layer. It computes fc (x4 , x3 , x2 , x1 , x0 ) represented by the boolean table
0x4457c3b3. In this way we recovered the filter function f depicted in Figure 6.7.
6.3.4
CRYPTO1
After authentication, the communication between tag and reader is encrypted with
the CRYPTO1 stream cipher. This cipher consists of a 48-bit linear feedback shift
register (LFSR) with generating polynomial x48 + x43 + x39 + x38 + x36 + x34 + x33 +
104
MIFARE Classic
x31 + x29 + x24 + x23 + x21 + x19 + x13 + x9 + x7 + x6 + x5 + 1 and a non-linear
filter function f [NESP08]. Each clock tick, twenty bits of the LFSR are put through
the filter function, generating one bit of keystream. Then the LFSR shifts one bit
to the left, using the generating polynomial to generate a new bit on the right. See
Figure 6.7 for a schematic representation.
⊕
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
fa = 0x26c7
fb = 0x0dd3
fb = 0x0dd3
fa = 0x26c7
fb = 0x0dd3
fc = 0x4457c3b3
keystream
input
Figure 6.7: Structure of the CRYPTO1 stream cipher
Definition 6.3.3. The feedback function L : F48
L(x0 x1 . . . x47 ) :=x0 ⊕ x5 ⊕ x9 ⊕ x10 ⊕ x12 ⊕ x14 ⊕ x15 ⊕ x17 ⊕ x19 ⊕
x24 ⊕ x25 ⊕ x27 ⊕ x29 ⊕ x35 ⊕ x39 ⊕ x41 ⊕ x42 ⊕ x43 .
The specifics of the filter function are taken from [GdKGM+ 08].
Definition 6.3.4. The filter function f : F48
f (x0 x1 . . . x47 ) := fc (fa (x9 , x11 , x13 , x15 ), fb (x17 , x19 , x21 , x23 ),
fb (x25 , x27 , x29 , x31 ), fa (x33 , x35 , x37 , x39 ), fb (x41 , x43 , x45 , x47 )).
Here fa , fb : F42 → F2 and fc : F52 → F2 are defined by
fa (y0 , y1 , y2 , y3 ) := ((y0 ∨ y1 ) ⊕ (y0 ∧ y3 )) ⊕ (y2 ∧ ((y0 ⊕ y1 ) ∨ y3 ))
fb (y0 , y1 , y2 , y3 ) := ((y0 ∧ y1 ) ∨ y2 ) ⊕ ((y0 ⊕ y1 ) ∧ (y2 ∨ y3 ))
fc (y0 , y1 , y2 , y3 , y4 ) := (y0 ∨ ((y1 ∨ y4 ) ∧ (y3 ⊕ y4 )))
⊕ ((y0 ⊕ (y1 ∧ y3 )) ∧ ((y2 ⊕ y3 ) ∨ (y1 ∧ y4 ))).
Because f (x0 x1 . . . x47 ) only depends on x9 , x11 , . . . , x47 , we shall overload notation
and see f as a function F20
2 → F2 , writing f (x0 x1 . . . x47 ) as f (x9 , x11 , . . . , x47 ).
Note that fa and fb here are negated when compared to [GdKGM+ 08] and fc is
changed accordingly. The expressions for fa , fb , and fc given here have the minimal
number of logical operators in {∧, ∨, ⊕, ¬}; in practice, this allows for a fast bitsliced
implementation of f [Bih97].
For future reference, note that each of the building blocks of f (and hence f itself)
have the property that it is balanced.
MIFARE Classic
105
Property 6.3.1. Let Y0 , Y1 , . . . , Y4 be independent uniformly distributed variables
over F2 . Then
P [fa (Y0 , Y1 , Y2 , Y3 ) = 0] = 1/2
P [fb (Y0 , Y1 , Y2 , Y3 ) = 0] = 1/2
P [fc (Y0 , Y1 , Y2 , Y3 , Y4 ) = 0] = 1/2.
Proof. By inspection.
The following precisely defines the initialization of the cipher and the generation
of the LFSR-stream a0 a1 . . . and the keystream b0 b1 . . . .
Definition 6.3.5. Given a key k = k0 k1 . . . k47 ∈ F48
2 , a tag nonce nT = nT,0
32
,
a
uid
u
=
u
u
.
.
.
u
∈
F
,
and a reader nonce nR =
nT,1 . . . nT,31 ∈ F32
0 1
31
2
2
32
nR,0 nR,1 . . . nR,31 ∈ F2 , the internal state of the cipher at time i is αi :=
ai ai+1 . . . ai+47 ∈ F48
2 . Here the ai ∈ F2 are given by
ai := ki
∀i ∈ [0, 47]
a48+i := L(ai , . . . , a47+i ) ⊕ nT,i ⊕ ui
∀i ∈ [0, 31]
a80+i := L(a32+i , . . . , a79+i ) ⊕ nR,i
∀i ∈ [0, 31]
a112+i := L(a64+i , . . . , a111+i )
∀i ∈ N.
Furthermore, we define the keystream bit bi ∈ F2 at time i by
bi := f (ai a1+i . . . a47+i )
∀i ∈ N.
We denote encryptions by {−} and define {nR,i }, {aR,i } ∈ F2 by
{nR,i } := nR,i ⊕ b32+i
∀i ∈ [0, 31]
{aR,i } := aR,i ⊕ b64+i
∀i ∈ [0, 31].
Note that the ai , αi , bi , {nR,i }, and {aR,i } are formally functions of k, nT , u, and
nR . Instead of making this explicit by writing, e.g., ai (k, nT , u, nR ), we just write ai
where k, nT , u, and nR are clear from the context.
6.3.5
Rollback
For our attacks it is important to realize that to recover the key, it is sufficient to
learn the internal state of the cipher αi at any point i in time. Since an attacker
knows u, nT , and {nR }, the LFSR can then be rolled back to time zero [Rue86]. This
is explained in detail in Section 6.2 of [GdKGM+ 08]; below we show their method
translated into our notation.
106
MIFARE Classic
Definition 6.3.6. The rollback function R : F48
R(x1 x2 . . . x48 ) :=x5 ⊕ x9 ⊕ x10 ⊕ x12 ⊕ x14 ⊕ x15 ⊕ x17 ⊕ x19 ⊕ x24 ⊕
x25 ⊕ x27 ⊕ x29 ⊕ x35 ⊕ x39 ⊕ x41 ⊕ x42 ⊕ x43 ⊕ x48 .
If one first shifts the LFSR left using L to generate a new bit on the right, then
R recovers the bit that dropped out on the left, i.e.,
R(x1 x2 . . . x47 L(x0 x1 . . . x47 )) = x0 .
(6.1)
Theorem 6.3.1. In the situation from Definition 6.3.5, we have
a64+i = R(a65+i . . . a112+i )
∀i ∈ N
a32+i = R(a33+i . . . a80+i ) ⊕ {nR,i } ⊕
f (0 a33+i . . . a79+i )
∀i ∈ [0, 31]
ai = R(a1+i . . . a48+i ) ⊕ nT,i ⊕ ui
∀i ∈ [0, 31].
Proof. Straightforward, using Definition 6.3.5 and Equation (6.1). For the second
equation, note that f does not depend on its leftmost input. Therefore
f (0 a33+i . . . a79+i ) = f (a32+i . . . a79+i ) = b32+i
and hence {nR,i } ⊕ f (0 a33+i . . . a79+i ) = nR,i .
Consequently, if an attacker somehow recovers the internal state of the LFSR
αi = ai ai+1 . . . ai+47 at some time i, then she can repeatedly apply Theorem 6.3.1 to
recover α0 = a0 a1 . . . a47 , which is the sector key.
6.4
Weaknesses
This section describes weaknesses in the design of the Mifare Classic. We first show
that the filter function f is invertible in less than one second on ordinary hardware
without the need for any precomputed tables. Next, we treat weaknesses in the way
the Mifare Classic handles parity bits and then the ones concerning nested authentications. Finally, we show how to extract pure keystream from a reader without requiring
any access to a genuine card. These weaknesses will be exploited in Section 6.5.
6.4.1
Odd Inputs to the Filter Function
The inputs to the filter function f are only on odd-numbered places. The fact that
they are so evenly placed can be exploited. Given a part of keystream, we can generate
those relevant bits of the LFSR state that give the even bits of the keystream and those
MIFARE Classic
107
relevant bits of the LFSR state that give the odd bits of the keystream separately.
By splitting the feedback into two parts as well, we can combine those even and odd
parts efficiently and recover exactly those states of the LFSR that produce a given
keystream. This may be understood as “inverting” the filter function f .
Let b0 b1 . . . bn−1 be n consecutive bits of keystream. For simplicity of the presentation we assume that n is even; in practice n is either 32 or 64. Our goal is to recover
all states of the LFSR that produce this keystream. To be precise, we will search for
all sequences r¯ = r0 r1 . . . r46+n of bits such that
rk ⊕ rk+5 ⊕ rk+9 ⊕ rk+10 ⊕ rk+12 ⊕ rk+14 ⊕ rk+15 ⊕ rk+17
⊕ rk+19 ⊕ rk+24 ⊕ rk+25 ⊕ rk+27 ⊕ rk+29 ⊕ rk+35 ⊕ rk+39 ⊕ rk+41
⊕ rk+42 ⊕ rk+43 ⊕ rk+48 = 0, for all k ∈ {0, . . . , n − 2}, (6.2)
and such that
f (rk . . . rk+47 ) = bk , for all k ∈ {0, . . . , n − 1}.
(6.3)
Condition (6.2) says that r¯ is generated by the LFSR, i.e., that r0 r1 . . . r47 , r1 r2 . . .
r48 , . . . are successive states of the LFSR; Condition (6.3) says that it generates the
required keystream. Since f only depends on 20 bits of the LFSR, we will overload
notation and write f (rk+9 , rk+11 , . . . , rk+45 , rk+47 ) for f (rk . . . rk+47 ). Note that when
n is larger than 48, there is typically only one sequence satisfying (6.2) and (6.3),
otherwise there are on average 248−n such sequences.
During our attack we build two tables of approximately 219 elements. These tables
contain respectively the even numbered bits and the odd numbered bits of the LFSR
sequences that produce the evenly and oddly numbered bits of the required keystream.
We proceed as follows. Looking at the first bit of the keystream, b0 , we generate
all sequences of 20 bits s0 s1 . . . s19 such that f (s0 , s1 , . . . , s19 ) = b0 . The structure of
f guarantees that there are exactly 219 of these sequences. Note that the sequences
r¯ of the LFSR that we are looking for must have one of these sequences as its bits
r9 , r11 , . . . , r47 .
For each of the entries in the table, we now do the following. We view the entry as
the bits 9, 11, . . . , 47 of the LFSR. We now shift the LFSR two positions to the left.
The feedback bit, which we call s20 , that is shifted in second could be either 0 or 1;
not knowing the even numbered bits of the LFSR nor the low numbered odd ones, we
have no information about the feedback. We can check, however, which of the two
possibilities for s20 matches with the keystream, i.e., which satisfy f (s1 , s2 , . . . , s20 ) =
b2 . If only a single value of s20 matches, we extend the entry in our table by s20 .
If both match, we duplicate the entry, extending it once with 0 and once with 1. If
neither matches, we delete the entry. On average, 1/4 of the time we duplicate an
entry, 1/4 of the time we delete an entry, and 1/2 of the time we only extend the
entry. Therefore, the table stays approximately of size 219 .
We repeat this procedure for the bits b4 , b6 , . . . , bn−1 of the keystream. This way
we obtain a table of approximately 219 entries s0 s1 . . . s19+n/2 with the property that
108
MIFARE Classic
f (si , si+1 , . . . , si+19 ) = b2i for all i ∈ {0, 1, . . . , n/2}. Consequently, the sequences r¯
of the LFSR that we are looking for must have one of the entries of this table as its
bits r9 , r11 , . . . , r47+n .
Similarly, we obtain a table of approximately 219 entries t0 t1 . . . t19+n/2 with the
property that f (ti , ti+1 , . . . , ti+19 ) = b2i+1 for all i ∈ {0, 1, . . . , n/2}.
Note that after only 4 extensions of each table, when all entries have length 24,
one could try every entry s0 s1 . . . s23 in the first table with every entry t0 t1 . . . t23 in
the second table to see if s0 t0 s1 . . . t23 generates the correct keystream. Note that this
already reduces the search complexity from 248 in the brute force case to (219 )2 = 238 .
To further reduce the search complexity, we now look at the feedback of the
LFSR. Consider an entry s¯ = s0 s1 . . . s19+n/2 of the first table and an entry
t¯ = t0 t1 . . . t19+n/2 of the second table. In order to verify that r¯ = s0 t0 s1 . . . t19+n/2 is
indeed generated by the LFSR, it is necessary (and sufficient) that every 49 consecutive bits satisfy the LFSR relation (6.2), i.e., the 49th must be the feedback generated
by the previous 48 bits.
0
1
si
ti
2
3
4
5
6
7
8
9
10
si+1 ti+1 si+2 ti+2 si+3 ti+3 si+4 ti+4 si+5
45
46
47
⊕
ti+22 si+23 ti+23
Figure 6.8: Subsequences s¯ and t¯.
So, for every subsequence si si+1 . . . si+24 of 25 consecutive bits of s¯ we compute its
s
contribution b1,¯
= sk ⊕ si+5 ⊕ si+6 ⊕ si+7 ⊕ si+12 ⊕ si+21 ⊕ si+24 of the LFSR relation
i
¯
and for every subsequence ti ti+1 . . . ti+23 of 24 consecutive bits of t¯ we compute bi2,t =
ti+2 ⊕ ti+4 ⊕ ti+7 ⊕ ti+8 ⊕ ti+9 ⊕ ti+12 ⊕ ti+13 ⊕ ti+14 ⊕ ti+17 ⊕ ti+19 ⊕ ti+20 ⊕ ti+21 .
(see Figure 6.8). If s0 t0 s1 . . . tn/2 is indeed generated by the LFSR, then
¯
s
b1,¯
= bi2,t for all i ∈ {0, . . . , n/2 − 5}.
i
(6.4)
Symmetrically, for every subsequence of 24 consecutive bits of s¯ and corresponding 25
s
consecutive bits of t¯, we compute ˜b1,¯
= si+2 ⊕si+4 ⊕si+7 ⊕si+8 ⊕si+9 ⊕si+12 ⊕si+13 ⊕
i
¯
si+14 ⊕si+17 ⊕si+19 ⊕si+20 ⊕si+21 and ˜bi2,t = ti ⊕ti+5 ⊕ti+6 ⊕ti+7 ⊕ti+12 ⊕ti+21 ⊕ti+24 .
Also here, if s0 t0 s1 . . . tn/2 is indeed generated by the LFSR, then
˜b1,¯s = ˜b2,t¯ for all i ∈ {0, . . . , n/2 − 5}.
i
(6.5)
One readily sees that together, conditions (6.4) and (6.5) are equivalent to equation (6.2).
To efficiently determine the LFSR state sequences that we are looking for, we sort
1,¯
s
s
˜1,¯s
˜1,¯s
the first table by the newly computed bits b1,¯
0 . . . bn/2−5 b0 . . . bn/2−5 , and the second
2,t¯
2,t¯
2,t¯
2,t¯
˜
˜
table by b0 . . . bn/2−5 b0 . . . bn/2−5 .
Since s0 t0 s1 . . . tn/2 is generated by the LFSR if and only b1,¯s˜b1,¯s = b2,t¯˜b2,t¯ and
since by construction it generates the required keystream, we do not even have to
MIFARE Classic
109
search anymore. The complexity now reduces to n loops over two tables of size
approximately 219 and two sortings of these two tables. For completeness sake, note
that from our tables we retrieve r9 r10 . . . r46+n . So to obtain the state of the LFSR
at the start of the keystream, we have to roll back the state r9 r10 . . . r58 9 steps.
In a variant of this method, applicable if we have sufficiently many bits of keystream available (64 will do), we only generate one of the two tables. For each of the
approximately 219 entries of the table, the LFSR relation can then be used to express
the ‘missing’ bits as linear combinations (over F2 ) of the bits of the entry. We can
then check if it produces the required keystream.
This construction has been implemented in two ways. First of all as C code
that recovers states from keystreams. Secondly also as a logical theory that has
been verified in the theorem prover PVS [ORSVH95]. The latter involves a logical
formalization of many aspects of the MIFARE Classic Classic [JWS11].
6.4.2
Parity weaknesses
The ISO standard 14443-A [ISO01] specifies that every byte sent is followed by a
parity bit. The Mifare Classic computes parity bits over the plaintext instead of over
the ciphertext. Additionally, the bit of keystream used to encrypt the parity bits is
reused to encrypt the next bit of plaintext.
This already breaks the confidentiality of the encryption scheme. In this chapter
we shall only be concerned with the four parity bits of nT , nR , and aR . The ISO
standard specifies odd parity, hence the “⊕1” in the definition below.
Definition 6.4.1. In the situation from Definition 6.3.5, we define the parity bits
pj ∈ F2 by
pj := nT,8j ⊕ nT,8j+1 ⊕ · · · ⊕ nT,8j+7 ⊕ 1
∀j ∈ [0, 3]
pj+4 := nR,8j ⊕ nR,8j+1 ⊕ · · · ⊕ nR,8j+7 ⊕ 1
∀j ∈ [0, 3]
pj+8 := aR,8j ⊕ aR,8j+1 ⊕ · · · ⊕ aR,8j+7 ⊕ 1
∀j ∈ [0, 3]
and the encryptions {pj } of these by
{pj } := pj ⊕ b8+8j
∀j ∈ [0, 11].
There is a further weakness concerning the parity bits. During the authentication
protocol, when the reader sends {nR } and {aR }, the tag checks the parity bits before
the answer of the reader. If at least one of the eight parity bits is wrong, the tag
does not respond. If all eight parity bits are correct, but the answer aR is wrong,
the tag responds with the 4-bit error code 0x5 signifying failed authentication, called
‘transmission error’ in [dKGHG08]. If all eight parity bits are correct and the answer
aR is also correct, the tag responds, of course, with its answer aT . Furthermore, in
110
MIFARE Classic
case the reader sends the correct parity, but the wrong answer, the 4-bit error code
0x5 is sent encrypted. This happens even though the reader has not authenticated
itself and hence cannot be assumed to be able to decrypt.
Figure 6.9 shows an authentication trace where the attacker sends incorrect authentication data but correct parity bits. The exclamation marks represent parity
bits that deviate from what is specified in the standard. The final message of this
trace is the encrypted error message 0x5.
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
26
02 00
93 20
c1 08 41 6a e2
93 70 c1 08 41 6a e2 e4 7c
18 37 cd
60 00 f5 7b
ab cd 19 49
59! d5 92 0f! 15 b9 d5! 53!
a
req type A
answer req
select
uid, bcc
select(uid)
Mifare Classic 4k
auth(block 0)
nT
{nR }{aR }
{5}
Figure 6.9: Trace of a failed authentication attempt
6.4.3
Nested authentications
Once an attacker knows a single sector key of a Mifare Classic, there is a vulnerability
that allows an adversary to recover more keys. When a reader is already communicating (encrypted) with a tag, a subsequent authentication command for a new sector
also has to be sent encrypted. After this authentication command, the internal state
of the cipher is set to the key for the new sector and the authentication protocol from
Section 6.3.1 starts again. This time, however, the challenge of the tag is also sent
encrypted. Because there are only 216 possible nonces, an attacker can simply try to
guess a nonce to recover 32 bits of keystream.
Also here, the information that leaks through the parity bits can be used to speed
up the attack. Although there are 216 tag nonces, we show below that the parity bits
sent with the encrypted tag nonce leak three bits of information, so that there are
only 213 tag nonces possible.
Definition 6.4.2. In the situation from Definition 6.3.5, we define {nT,i } ∈ F2 by
{nT,i } := nT,i ⊕ bi
∀i ∈ [0, 31].
Theorem 6.4.1. For every j ∈ {0, 1, 2} we have
nT,8j ⊕ nT,8j+1 ⊕ · · · ⊕ nT,8j+7 ⊕ nT,8j+8 = {pj } ⊕ {nT,8j+8 } ⊕ 1
MIFARE Classic
111
Proof. We compute as follows.
nT,8j ⊕ nT,8j+1 ⊕ · · · ⊕ nT,8j+7 ⊕ nT,8j+8
= pj ⊕ 1 ⊕ nT,8j+8
(by Dfn. 6.4.1)
= pj ⊕ b8+8j ⊕ nT,8j+8 ⊕ b8+8j ⊕ 1
= {pj } ⊕ {nT,8j+8 } ⊕ 1
(by Dfns. 6.4.1 and 6.4.2)
Since the attacker can observe {pj } and {nT,8j+8 }, this theorem gives an attacker
three bits of information about nT .
In practice, timing information between the first and second authentication attempt leaks so much additional information that the attacker can accurately predict
what the challenge nonce will be.
It turns out that the distance between the tag nonces used in consecutive authentication attempts strongly depends on the time between those attempts. Here distance
is defined as follows.
Definition 6.4.3. Let nT and n′T be two tag nonces. We define the distance between
nT and n′T as
d(nT , n′T ) := min suci (nT ) = n′T .
i∈N
6.4.4
Known Plaintext
From the description of the authentication protocol it is easy to see that parts of the
keystream can be recovered. Having seen nT and suc2 (nT ) ⊕ ks2 , one can recover
ks2 (i.e., 32 bits of keystream) by computing suc2 (nT ) and XOR-ing.
Moreover, experiments show that if the tag does not send anything, then most
readers will time out and send a halt command. Since communication is encrypted it actually sends halt ⊕ ks3 . Knowing the byte code of the halt command
(0x500057cd [ISO01]) we recover ks3 .
Some readers do not send a halt command but instead continue as if authentication
succeeded. This typically means that it sends an encrypted read command. As the
byte code of the read command is also known [dKGHG08], this also enables us to
recover ks3 by guessing the block number.
It is important to note that one can obtain such an authentication session (or
rather, a partial authentication session, as the Ghost never authenticates itself) from
a reader (and hence ks2 , ks3 ) without knowing the secret key and, in fact, without
using a tag.
If an attacker does have access to both a tag and a reader and can eavesdrop a
successful (complete) authentication session, then both ks2 and ks3 can be recovered
from the answers suc2 (nT ) ⊕ ks2 and suc3 (nT ) ⊕ ks3 of the tag and the reader. This
works even if the reader does not send halt or read after timeout.
112
6.5
MIFARE Classic
Attacks
This section shows how the weaknesses described in the previous section can be exploited.
6.5.1
Brute-force attack
The attacker plays the role of a reader and tries to authenticate for a sector of her
choice. She answers the challenge of the tag with eight random bytes (and eight
random parity bits) for {nR } and {aR }. With probability 1/256, the 8 parity bits are
correct and the tag responds with the encrypted 4-bit error code. A success leaks 12
bits of entropy (out of 48).
Repeating the above procedure sufficiently at least four times (in practice six is
enough) uniquely determines the key. Since the key length is only 48 bits, the attacker
can now brute force the key: she can just check which of the 248 keys produces all six
times the correct parity bits and received response. In practice, gathering those six
authentication sessions with correct parity bits only takes on average 6·256 = 1536 authentication attempts which can be done in less than one second. The time it takes to
perform the offline brute-force attack of course is strongly dependent on the resources
the attacker has at her disposal. We give an estimate based on the performance of
COPACOBANA [KPP+06]; this is a code-cracker built from off-the-shelf hardware
costing approximately USD 10 000. Based on the fact that COPACOBANA finds a
56-bit DES key in on average 6.4 days, pessimistically assuming that one can fit the
same number of CRYPTO1 checks on an FPGA as DES-decryptions, and realizing
that the search space is a factor of 256 smaller, we estimate that this takes on average
6.4 days/256 = 36 min.
In Sections 6.5.2 and 6.5.3 the same idea is exploited in a different way, trading
online communication for computation time.
6.5.2
Varying the reader nonce
This section shows how an attacker can mount a chosen ciphertext attack by adaptively varying the encryption of nR . We assume that the attacker can control the
power up timing of the tag, thereby causing the tag to produce the same nT every
time.
We first give the idea of the attack. The attacker runs authentication sessions
until she guesses the correct parity bits. The internal state of the stream cipher just
after feeding in nR is α64 . She then runs another authentication session, keeping the
first 31 bits of {nR } (and the three parity bits) the same, flipping the last bit of {nR }
(and randomly picking the rest until the parity is ok). Now the state of the stream
cipher just after feeding in the reader nonce is α64 ⊕ 1, i.e., α64 with the last bit
flipped. Since the parity of the last byte of nR changed (since the attacker flipped
MIFARE Classic
113
just the last bit), and since its parity in the first run is encrypted with f (α64 ) and
in the second run with f (α64 ⊕ 1), she can deduce whether or not the last bit of nR
influences the encryption of the next bit, i.e., whether or not f (α64 ) = f (α64 ⊕ 1).
Approx. 9.4% of the possible α64 ’s has f (α64 ) 6= f (α64 ) ⊕ 1 and they can easily be
generated since only the twenty bits that are input to f are relevant. By repeating
this, the attacker eventually (on average after 10.6 tries) finds an instance in which
α64 is in those 9.4% and then she only has to search, offline, 9.4% of all possible
states.
We now make this idea precise and at the same time generalize it to the last bit of
each of the four bytes in the reader nonce. The following definition says that a reader
nonce has property Fj (for j ∈ {0, 1, 2, 3}) if flipping the last bit of the (j + 1)th byte
of the reader nonce changes the encryption of the next bit.
Definition 6.5.1. Let j ∈ {0, 1, 2, 3} and let nR and n′R be reader nonces with the
property that n′R,8j+7 = nR,8j+7 and n′R,i = nR,i for all i < 8j + 7 (and no restrictions
on nR,i and n′R,i for i > 8j + 7). We say that nR has property Fj if b8j+40 6= b′8j+40 .
Formally this is not just a property of nR , but also of k, nT , and u. Now k and u
of course do not vary, so we ignore that here. Furthermore, when deciding whether or
not nR has property Fj in Protocol 6.5.1 below, the attacker also keeps nT constant.
The attacker does change the reader nonce. We use a′i to refer to the bits of the
LFSR-stream where the reader nonce n′R is used and similarly for α′i , b′i , etc. I.e., a′i
denotes ai (k, nT , u, n′R ).
Note that α8j+40 (resp. α′8j+40 ) is the internal state of the cipher just after feeding in the (j + 1)th byte of nR (resp. n′R ) and b8j+40 = f (α8j+40 ) (resp. b′8j+40 =
f (α′8j+40 )), so that Fj does not depend on nR,i and n′R,i for i > 8j + 7. Also observe
that α′8j+40 = a8j+40 . . . a8j+86 a′8j+87 , i.e., α8j+40 and α′8j+40 only differ in the last
position.
The crucial idea is that an attacker can decide whether or not nR has property
Fj , only knowing {nR }. (In practice, the attacker of course chooses {nR }.)
Protocol 6.5.1. Given {nR }, an attacker can decide as follows whether or not nR has
property Fj . She first chooses {aR } arbitrary. She then starts, consecutively, several
authentication sessions with the tag. After the tags sends its challenge nT , the attacker
answers {nR }, {aR }. Inside this answer, the attacker also has to send the (encryptions
of) the parity bits: {p4 }, . . . , {p11 }. For these, she tries all 256 possibilities. After on
average 128 authentication sessions, and after at most 256, with different choices for
the {pi }, the parity bits are correct and the attacker recognizes this because the tag
responds with an error code.
Now the attacker defines {n′R,8j+7 } := {nR,8j+7 }, i.e., she changes the last bit
of the jth byte of {nR }. The earlier bits of {n′R } she chooses the same as those of
{nR }; the later bits of {n′R } and {a′R } the attacker chooses arbitrarily. Again, the
attacker repeatedly tries to authenticate to find the correct parity bits {p′i } to send.
114
MIFARE Classic
Note that necessarily {p′i } = {pi } for i ∈ {4, . . . , j + 3}, so this takes on average 27−j
authentication attempts and at most 28−j .
Now nR has property Fj if and only if {pj+4 } 6= {p′j+4 }.
Proof. Because the attacker modified the ciphertext of the last bit of the jth byte
of nR , the last bit of the plaintext of this byte also changes: n′R,8j+7 = {n′R,8j+7 } ⊕
b′8j+39 = {n′R,8j+7 } ⊕ b′8j+39 = {nR,8j+7 } ⊕ b8j+39 = nR,8j+7 ⊕ b8j+39 ⊕ b8j+39 =
nR,8j+7 . Hence, the parity of this byte changes: p′j+4 = n′R,8j ⊕ · · · ⊕ n′R,8j+6 ⊕
n′R,8j+7 ⊕ 1 = nR,8j ⊕ . . . nR,8j+6 ⊕ nR,8j+7 ⊕ 1 = pj+4 .
Now {pj+4 } ⊕ {p′j+4 } = pj+4 ⊕ b8j+40 ⊕ p′j+4 ⊕ b′8j+40 = pj+4 ⊕ b8j+40 ⊕ pj+4 ⊕
= b8j+40 ⊕ b′8j+40 . Hence {pj+4 } = {p′j+4 } if and only if b8j+40 = b′8j+40 , i.e.,
{pj+4 } 6= {p′j+4 } if and only if nR has property Fj .
b′8j+40
The theorem below shows that the probability that nR has the property Fj is
approximately 9.4%.
Lemma 6.5.2. Let Y0 , . . . , Y4 be independent uniformly distributed random variables
over F2 . Then
P [fb (Y0 , Y1 , Y2 , Y3 ) 6= fb (Y0 , Y1 , Y2 , Y3 )] =
P [fc (Y0 , Y1 , Y2 , Y3 , Y4 ) 6= fc (Y0 , Y1 , Y2 , Y3 , Y4 )] =
1
4
3
8.
Theorem 6.5.3. Let Y0 , Y1 , . . . , Y18 , Y19 be independent uniformly distributed random
variables over F2 . Then
P [f (Y0 , Y1 , . . . , Y18 , Y19 ) 6= f (Y0 , Y1 , . . . , Y18 , Y19 )] =
3
32 .
Proof. Write Z0 := fa (Y0 , . . . , Y3 ), Z1 := fb (Y4 , . . . , Y7 ), Z2 := fb (Y8 , . . . , Y11 ),
Z3 := fa (Y12 , . . . , Y15 ), and Z4 := fb (Y16 , . . . , Y19 ). Furthermore, write Z4′ :=
fb (Y16 , . . . , Y18 , Y19 ). Note that Z0 , . . . , Z4 are independent and, by Theorem 6.3.1,
uniformly distributed over F2 . Then
P [f (Y0 , Y1 , . . . , Y18 , Y19 ) 6= f (Y0 , Y1 , . . . , Y18 , Y19 )]
= P [fc (Z0 , . . . , Z4 ) 6= fc (Z0 , . . . , Z3 , Z4′ )]
= P [fc (Z0 , . . . , Z4 ) 6= fc (Z0 , . . . , Z4′ )|Z4 6= Z4′ ]
· P [Z4 6= Z4′ ]
= P [fc (Z0 , . . . , Z3 , 0) 6= fc (Z0 , . . . , Z3 , 1)]
· P [fa (Y16 , . . . , Y18 , 0) 6= fa (Y16 , . . . , Y18 , 1)]
=
=
3 1
8 · 4
3
32 .
(by Lemma 6.5.2)
Alternatively, one can also obtain this result by simply checking all 220 possibilities.
MIFARE Classic
115
We now describe how an attacker can find an {nR } such that nR has all four
properties Fj . Recall that these properties also depend on nT and it is possible that
for a fixed nT no nR has all four properties. In that case, as is explained in the
protocol below, the attacker makes the tag generate a different nT and starts the
search again.
Protocol 6.5.4. An attacker can find {nR } such that nR has properties F0 , F1 , F2 , F3
in a backtracking fashion. She first loops over all possibilities for the first byte of {nR }
(taking the other bytes of {nR } arbitrary). Using Protocol 6.5.1, the attacker decides
if nR has property F0 (which only depends on the first byte). If it has, she continues
with the second byte of {nR }, looping over all possibilities for the second byte of {nR }
while keeping the first byte fixed, trying to find {nR } such that nR also has property
F1 . She repeats this for the third and fourth byte of {nR }. If at some stage no possible
byte has property Fj , the search backtracks to the previous stage. It fails at the first
stage, the attacker has to try a different tag nonce.
By simulating this protocol (for a random key and random uid, and a random tag
nonce in every outer loop of the search), we can estimate the number of authentication
attempts needed to find a reader nonce having all four properties Fj .
Observation 6.5.5. The expected number of authentication attempts needed to find
an nR which has all four properties Fj is approximately 28 500.
Table 6.1: Odd bits of α64 ending in 0 when nR has all properties Fj
0x000041414110
0x001541414140
0x010141414110
0x014141414140
0x040040414110
0x040140414140
0x041440414110
0x041540414140
0x044440414110
0x140141414140
0x144441414110
0x150441414140
0x155141414110
0x410041414140
0x410441414110
0x411441414140
0x414141414110
0x414441414140
0x441441414110
0x445141414140
0x510110414110
0x510441414140
0x511510414110
0x514141414140
0x515141414110
0x000041414140
0x004141414110
0x010141414140
0x014441414110
0x040040414140
0x040141414110
0x041440414140
0x041541414110
0x044440414140
0x140441414110
0x144441414140
0x151441414110
0x155141414140
0x410110414110
0x410441414140
0x411510414110
0x414141414140
0x415141414110
0x441441414140
0x510010414110
0x510110414140
0x511410414110
0x511510414140
0x514410414110
0x515141414140
0x000141414110
0x004141414140
0x010441414110
0x014441414140
0x040041414110
0x040141414140
0x041441414110
0x041541414140
0x044441414110
0x140441414140
0x145141414110
0x151441414140
0x410010414110
0x410110414140
0x411410414110
0x411510414140
0x414410414110
0x415141414140
0x441541414110
0x510010414140
0x510111414110
0x511410414140
0x511511414110
0x514410414140
0x000141414140
0x004441414110
0x010441414140
0x015141414110
0x040041414140
0x040441414110
0x041441414140
0x044141414110
0x044441414140
0x141441414110
0x145141414140
0x151541414110
0x410010414140
0x410111414110
0x411410414140
0x411511414110
0x414410414140
0x440041414110
0x441541414140
0x510011414110
0x510111414140
0x511411414110
0x511511414140
0x514411414110
0x000441414110
0x004441414140
0x011441414110
0x015141414140
0x040110414110
0x040441414140
0x041510414110
0x044141414140
0x045141414110
0x141441414140
0x150041414110
0x151541414140
0x410011414110
0x410111414140
0x411411414110
0x411511414140
0x414411414110
0x440041414140
0x444141414110
0x510011414140
0x510140414110
0x511411414140
0x511540414110
0x514411414140
0x000441414140
0x005141414110
0x011441414140
0x040010414110
0x040110414140
0x041410414110
0x041510414140
0x044410414110
0x045141414140
0x141541414110
0x150041414140
0x154141414110
0x410011414140
0x410140414110
0x411411414140
0x411540414110
0x414411414140
0x440141414110
0x444141414140
0x510040414110
0x510140414140
0x511440414110
0x511540414140
0x514440414110
0x001441414110
0x005141414140
0x011541414110
0x040010414140
0x040111414110
0x041410414140
0x041511414110
0x044410414140
0x140041414110
0x141541414140
0x150141414110
0x154141414140
0x410040414110
0x410140414140
0x411440414110
0x411540414140
0x414440414110
0x440141414140
0x444441414110
0x510040414140
0x510141414110
0x511440414140
0x511541414110
0x514440414140
0x001441414140
0x010041414110
0x011541414140
0x040011414110
0x040111414140
0x041411414110
0x041511414140
0x044411414110
0x140041414140
0x144141414110
0x150141414140
0x154441414110
0x410040414140
0x410141414110
0x411440414140
0x411541414110
0x414440414140
0x440441414110
0x444441414140
0x510041414110
0x510141414140
0x511441414110
0x511541414140
0x514441414110
0x001541414110
0x010041414140
0x014141414110
0x040011414140
0x040140414110
0x041411414140
0x041540414110
0x044411414140
0x140141414110
0x144141414140
0x150441414110
0x154441414140
0x410041414110
0x410141414140
0x411441414110
0x411541414140
0x414441414110
0x440441414140
0x445141414110
0x510041414140
0x510441414110
0x511441414140
0x514141414110
0x514441414140
Once the attacker has found an nR having all four properties Fj , the number of
possibilities for the internal state of the cipher after feeding in this particular nR is
seriously restricted. The following theorem states how many possibilities there still
are.
Theorem 6.5.6. Suppose that nR has properties F0 , F1 , F2 , and F3 . Then there are
only 436 possibilities for the odd-numbered bits of α64 . Table 6.1 lists (in hexadecimal,
116
MIFARE Classic
Table 6.2: Excerpt from table T0xa04 of internal cipher states α32 at index 0xa04
0x0000004d4d1f
0x00000a137cd9
0x0000129d78db
0x00001b1c2ff7
0x000023a92baa
0x0000012d7b8b
0x00000aed7467
0x000012f4cde6
0x00001c259261
0x000026bc6e18
0x000001513ca3
0x00000b92342b
0x000015382c19
0x00001c46edf7
0x0000278a7954
0x0000049e0e78
0x00000c6db6a0
0x000016a7a95c
0x00001c5a3fde
...
0x000004cafec1
0x00000cbd2daa
0x0000172bebc6
0x00001c97ee44
0x000006f945be
0x00000cda7817
0x0000173f2299
0x00001f19da5e
0x000007089ea5
0x00000d0cbd27
0x00001821aa0a
0x00001fef9ec2
0x0000072b67df
0x00000e98af03
0x000018769666
0x000022ce6797
0x000008e79d8e
0x00001089393d
0x00001a6d513e
0x000023a396ce
with zeros on the places of the even-numbered bits) the 218 of those possibilities that
have the last bit a111 equal to 0; the other 218 are the same except that they have a111
equal to 1.
Proof. By explicit computation. For each of the 224 elements y0 y1 . . . y23 of F24
2 , one
checks if
f (y4 , y5 , . . . , y23 ) 6= f (y4 , y5 , . . . , y23 ),
f (y0 , y1 , . . . , y19 ) 6= f (y0 , y1 , . . . , y19 ),
and there exist y−8 , y−7 , . . . , y−1 ∈ F2 such that
f (y−4 , y−3 , . . . , y15 ) 6= f (y−4 , f−3 , . . . , y15 )
and
f (y−8 , y−7 , . . . , y11 ) 6= f (y−8 , f−7 , . . . , y11 ).
Consequently, when the attacker has found a reader nonce nR that has properties
F0 , F1 , F2 , and F3 , there are only 436 · 224 ≈ 232.8 ≈ 7.3 · 109 possibilities for
the internal state α64 of the cipher just after shifting in the reader nonce. Using
Theorem 6.3.1, these can be used to compute 7.3 · 109 candidate keys. The attacker
can then check these candidate keys by trying to decrypt the received 4-bit error
messages.
6.5.3
Varying the tag nonce
In the previous approach, the attacker kept nT constant and tried to find a special
{nR } such that she gained knowledge about the internal cipher state. Now the attacker does the opposite: she keeps {nR } (and {aR } and the {pi } as well) constant,
but varies nT instead. As before, the attacker waits for the tag to respond; when this
happens, she gains knowledge about the internal state of the cipher.
Protocol 6.5.7. The attacker repeatedly tries to authenticate to the tag, every time
with a different tag nonce nT and sending all zeros as its response (including the
encrypted parity bits), i.e., {nR } = 0, {aR } = 0, {p4 } = · · · = {p11 } = 0. She waits
for an nT such that the tag actually responds (i.e., the parity bits are the correct parity
bits) and where the encrypted error code is 0x5 (i.e., b96 = b97 = b98 = b99 = 0).
MIFARE Classic
117
Note that twelve bits have to be ‘correct’ (the eight parity bits and the four
keystream bits), so this will take on average 212 = 4096 authentication attempts.
The following defines a large table that needs to be precomputed.
Definition 6.5.2.
T := {α32 ∈ F48
2 | {nR } = {aR } = 0 ⇒
{p4 } = · · · = {p11 } = b96 = · · · = b99 = 0}.
So the attacker knows that after the tag sends the challenge nT found in Protocol 6.5.7, the current state of the cipher, α32 , appears in T . Now T can be precomputed; one would expect it to contain 248 /212 = 236 elements; in fact, it contains
0.82% fewer elements due to a small bias in the cipher. In principle, the attacker
could now use Theorem 6.3.1 to roll back each of the LFSRs in the table to find candidate keys and check each of these keys against a few other attempted authentication
sessions.
In practice, searching through T takes about one day, which is undesirable. The
attacker can shrink the search space by splitting T as follows.
Protocol 6.5.8. After finding nT in Protocol 6.5.7, the attacker again repeatedly tries
to authenticate to the tag, every time with the tag nonce nT she just found. Instead
of zeros, she now sends ones for the response and this time she tries all possibilities
for the encrypted parity bits until the tag responds with an encrypted error code. I.e.,
{nR } = 0xffffffff and {aR } = 0xffffffff and successively tries all possibilities
for {p4 }, . . . , {p11 } until one is correct.
This time, because eight bits have to be ‘correct’, on average 128 authentication
attempts are needed.
The table T can be split into 212 = 4096 parts indexed by the eight encrypted
parity bits and four keystream bits that encrypt the error code.
Definition 6.5.3. For every γ = γ0 . . . γ11 ∈ F12
2 we define
Tγ := {α32 ∈ T | {nR } = {aR } = 0xffffffff ⇒
{p4 } = γ0 ∧ · · · ∧ {p11 } = γ7 ∧ b96 = γ8 ∧ · · · ∧ b99 = γ11 }.
So instead of storing T as one big table, during precomputation the attacker
creates the 4096 tables Tγ . Taking γ := {p4 } . . . {p11 }b96 . . . b99 at the end of Protocol 6.5.8, the attacker knows that α32 must be an element of Tγ . Now Tγ contains
only approximately 224 entries, so this can easily be read from disk to generate 224
candidate keys and check them against a few other authentication sessions. Table 6.2
shows, as an example, the first part of Tγ for γ = 0xa04 = 1010 0000 0100.
118
MIFARE Classic
6.5.4
Nested authentication attack
We now assume that the attacker already knows at least one sector key; let us call
this sector the exploit sector.
The time between two consecutive authentication attempts might vary from card
to card, although it is quite constant for a specific card. Therefore, an attacker can
first estimate this time by authenticating two times for the exploit sector. In this way
the attacker can estimate the distance δ between the first and the second tag nonce.
As explained in Section 6.4.3, the attacker can now authenticate for the exploit
sector and subsequently for another sector. In the authentication for the exploit
sector the tag nonce n0T is sent in the clear; during the second authentication the
tag nonce nT is sent encrypted as {nT }. By computing suci (n0T ) for i close to δ,
the adversary has a small number of guesses for nT . The adversary can further
narrow the possibilities for nT using the three bits of information from the parity
bits (Theorem 6.4.1). In this way the adversary can accurately guess nT and hence
recover the first 32 bits of keystream, b0 b1 . . . b31 .
We shall show how a variant of the attack of Section 6.3 of [GdKGM+ 08] can
be used to recover approximately 216 possible candidate keys. By performing this
procedure two or three times, the attacker can recover the key for the second sector
as well by taking the intersection of the two or three sets of candidate keys.
The crucial ingredient in the attack is the fact that the inputs to the filter function
are only on odd-numbered places of the LFSR. This makes it possible to compute
separately all possibilities for the odd-numbered bits of the LFSR-stream and the
even-numbered bits of the LFSR-stream that are compatible with the keystream.
Definition 6.5.4. We define the odd tables TiO by
T0O := {x9 x11 . . . x45 x47 ∈ F20
2 | f (x9 x11 . . . x45 x47 ) = b0 }
and for i ∈ {1, . . . , 15}
TiO := {x9 x11 . . . x45+2i x47+2i ∈ F220+i |
O
x9 . . . x45+2i ∈ Ti−1
∧ f (x9+2i x11+2i . . . x45+2i x47+2i ) = b2i }.
Symmetrically, we define the even tables TiE by
T0E := {x10 x12 . . . x46 x48 ∈ F20
2 | f (x10 x12 . . . x46 x48 ) = b1 }
and for i ∈ {1, . . . , 15}
TiE := {x10 x12 . . . x46+2i x48+2i ∈ F20+i
|
2
E
x10 . . . x46+2i ∈ Ti−1
∧ f (x10+2i x12+2i . . . x46+2i x48+2i ) = b2i+1 }.
O
E
We write T O := T15
and T E := T15
.
MIFARE Classic
119
Because of the structure of the filter function f , T0O and T0E are exactly of size 219
(Theorem 6.3.1). The other tables are approximately of this size as well. An entry
O
x9 x11 . . . x45+2i of Ti−1
leads to four different possibilities in TiO : it can appear in
O
Ti extended with 0 and with 1; it can appear extended only with 0; it can appear
extended only with 1; or it cannot appear at all. Overall, these possibilities are equally
O
likely, and hence TiO has, on average, the same size as Ti−1
(and similarly for T E ).
The feedback function L can also be split into an even and an odd part.
Definition 6.5.5. We define the odd part of the feedback function, LO : F24
2 → F2 ,
by
LO (x1 x3 . . . x47 ) :=x5 ⊕ x9 ⊕ x15 ⊕ x17 ⊕ x19 ⊕ x25 ⊕
x27 ⊕ x29 ⊕ x35 ⊕ x39 ⊕ x41 ⊕ x43
E
and the even part of the feedback function, LE : F24
2 → F2 , by L (x0 x2 . . . x46 ) :=
x0 ⊕ x10 ⊕ x12 ⊕ x14 ⊕ x24 ⊕ x42 .
Note that LE and LO combine to give L, in the sense that
L(x0 x1 x2 . . . x47 ) = LE (x0 x2 . . . x46 ) ⊕ LO (x1 x2 . . . x47 ).
(6.6)
As the a9 a10 . . . a77 a78 are being shifted through the LFSR, the uid u and the tag
nonce nT are shifted in as well. In the following definition we compute the 22 bits
of feedback from the LFSR from time 9 to time 31, taking care of the shifting in of
u ⊕ nT , and also splitting the contribution from the odd- and even-numbered bits of
the LFSR. At this point, the situation in [GdKGM+ 08] is slightly simpler. There, the
attacker tries to find the state of the LFSR after initialization, so nothing is being
shifted in.
Definition 6.5.6.
ψ O (x9 x11 . . . x77 ) := (LE (x9+2i x11+2i . . . x55+2i ) ⊕ nT,9+2i ⊕ u9+2i ,
LO (x11+2i x13+2i . . . x57+2i ) ⊕ nT,10+2i ⊕ u10+2i )i∈{0,...,10}
and
ψ E (x10 x12 . . . x78 ) := (LO (x10+2i x12+2i . . . x56+2i ) ⊕ x57+2i ,
LE (x10+2i x12+2i . . . x56+2i ) ⊕ x58+2i )i∈[0,10] .
Definition 6.5.7. We define the combined table T C as follows.
T C := {x9 x10 x11 . . . x78 |x9 x11 . . . x77 ∈ T O ∧ x10 x12 . . . x78 ∈ T E ∧
ψ O (x9 x11 . . . x77 ) = ψ E (x10 x12 . . . x78 )}.
Note that T C can easily be computed by first sorting T O by ψ O and T E by ψ E .
The crucial point is the following theorem; it shows that the actual LFSR-stream
of the tag under attack is in the table T C .
120
MIFARE Classic
Theorem 6.5.9. a9 a10 a11 . . . a78 ∈ T C .
Proof. By definition of T O and T E , a9 a11 . . . a77 ∈ T O and a10 a12 . . . a78 ∈ T E . We
only have to check that the sequence a9 a10 a11 . . . a78 satisfies the constraint defining
T C . For this, we have
ψ O (a9 a11 . . . a77 ) ⊕ ψ E (a10 a12 . . . a78 )
= (LE (x9+2i x11+2i . . . x55+2i ) ⊕ nT,9+2i ⊕ u9+2i ⊕
LO (x10+2i x12+2i . . . x56+2i ) ⊕ x57+2i ,
LO (x11+2i x13+2i . . . x57+2i ) ⊕ nT,10+2i ⊕ u10+2i ⊕
LE (x10+2i x12+2i . . . x56+2i ) ⊕ x58+2i )i∈{0,...,10}
(by Dfn. 6.5.6)
= (L(x9+2i x10+2i . . . x56+2i ) ⊕ nT,9+2i ⊕ u9+2i ⊕ x57+2i ,
L(x10+2i x11+2i . . . x57+2i ) ⊕ nT,10+2i ⊕ u10+2i ⊕ x58+2i )i∈{0,...,10}
(by Eqn. (6.6))
= (0, 0)i∈{0,...,10} ,
(by Dfn. 6.3.5)
as required.
Taking the first 48 bits of every entry of T C , the attacker can apply Theorem 6.3.1
nine times for every entry, obtaining one candidate key for every entry of T C . Because
we have used 32 bits of keystream and the key is 48 bits, on average there will be 216
candidate keys. Doing this procedure once more gives another set of approximately
216 candidate keys; the actual key must be in the intersection. In practice, most of
the time the intersection only contains a single key; occasionally it contains two keys
and then a third run of this whole procedure can be used to determine the key (or
both candidate keys can just be tested online, of course).
6.6
Conclusions
We have found serious ‘textbook’ vulnerabilities in the Mifare Classic tag. In particular, the Mifare Classic mixes two layers of the protocol stack and reuses a one-time
pad for the encryption of the parity bits. It also sends encrypted error messages
before a successful authentication. These weaknesses allow an adversary to recover
a secret key within seconds. Moreover, tag nonces are predictable which, besides
allowing replays, provides known plaintext for our nested authentication attack. We
have executed these attacks in practice and retrieved all secret keys from a number
of cards, including cards used in large access control and public transport ticketing
systems.
MIFARE Classic
121
To slightly hamper an adversary, system integrators could consider the following
countermeasures:
• diversify all keys in the card;
• cryptographically bind the memory contents of the card to the UID, for instance
by including a MAC;
• perform regular integrity checks in the back office.
For the time being, the second countermeasure prevents an attacker from cloning a
card onto a blank one. However, this does not stop an attacker from emulating that
card with an emulator like the Proxmark.
Early on we have notified the manufacturer NXP of these vulnerabilities. Since the
protocol is implemented in hardware, we do not foresee any definitive countermeasure
to these attacks that does not require replacing the entire infrastructure. However,
NXP has developed and deployed a backwards compatible successor to the Mifare
Classic, the Mifare Plus. We are collaborating with NXP, providing feedback to help
them improving the security of their new prototypes, given the limitations of the
backwards compatibility mode.
6.7
Acknowledgements
We are grateful to our faculty’s computer department (C&CZ) for providing us with
computing power and to Ben Polman in particular for his assistance.
Chapter 7
Hitag2
An electronic vehicle immobilizer is an anti-theft device that prevents the engine of
the vehicle from starting unless the corresponding transponder is present. Such a
transponder is a passive RFID tag which is embedded in the car key and wirelessly
authenticates to the vehicle. It prevents a perpetrator from hot-wiring the vehicle or
starting the car by forcing the mechanical lock. Having such an immobilizer is required by law in several countries. Hitag2 , introduced in 1996, is currently the most
widely used transponder in the car immobilizer industry. It is used by at least 34 car
makes and fitted in more than 200 different car models. Hitag2 uses a proprietary
stream cipher with 48-bit keys for authentication and confidentiality. This chapter
reveals several weaknesses in the design of the cipher and presents three practical attacks that recover the secret key using only wireless communication. The most serious
attack recovers the secret key from a car in less than six minutes using ordinary hardware. This attack allows an adversary to bypass the cryptographic authentication,
leaving only the mechanical key as safeguard. This is even more sensitive on vehicles
where the physical key has been replaced by a keyless entry system based on Hitag2 .
During our experiments we managed to recover the secret key and start the engine
of many vehicles from various makes using our transponder emulating device. These
experiments also revealed several implementation weaknesses in the immobilizer units.
7.1
Introduction
In the past, most cars relied only on mechanical keys to prevent a hijacker from stealing the vehicle. Since the ’90s most car manufacturers incorporated an electronic car
immobilizer as an extra security mechanism in their vehicles. From 1995 it is mandatory that all cars sold in the EU are fitted with such an immobilizer device, according
to European directive 95/56/EC. Similar regulations apply to other countries like
Australia, New Zealand (AS/NZS 4601:1999) and Canada (CAN/ULC S338-98). An
electronic car immobilizer consists of two main components: a small transponder chip
which is embedded in (the plastic part of) the car key, see Figure 7.1; and a reader
which is located somewhere in the dashboard of the vehicle and has an antenna coil
around the ignition, see Figure 7.2.
The transponder is a passive RFID tag that operates at a Low Frequency (LF) of
125 kHz. It is powered up when it comes in proximity range of the electronic field
124
Hitag2
Figure 7.1: Car keys with a Hitag2 transponder/chip
of the reader. When the transponder is absent, the immobilizer unit prevents the
vehicle from starting the engine.
A distinction needs to be made with remotely operated central locking system,
which opens the doors, is battery powered, operates at a Ultra-High Frequency (UHF)
of 433 MHz, and only activates when the user pushes a button on the remote key.
More recent car keys are often deployed with a hybrid chip that supports the battery
powered ultra-high frequency as well as the passive low frequency communication
interface.
With the Hitag2 family of transponders, its
manufacturer NXP Semiconductors (formerly
Philips Semiconductors) leads the immobilizer
market [Noh10]. Table 7.1 shows a list containing
some of the vehicles that are deployed with a
Hitag2 transponder.
Even though NXP boosts
“Unbreakable security levels using mutual authentication, challenge-response and encrypted data
communication”1 , it uses a shared key of only 48
bits.
Since 1988, the automotive industry has moved
towards the so-called keyless ignition or keyless entry in their high-end vehicles [HTTN88]. In such a
vehicle the mechanical key is no longer present and
it has been replaced by a start button like the one
shown in Figure 7.3. The only anti-theft mechanism
left in these vehicles is the immobilizer. Startlingly,
many keyless ignition or entry vehicles sold nowadays
are still based on the Hitag2 cipher. In some keyless
entry cars Hitag2 is also used as a backup mechanism
for opening the doors, e.g., when the battery of the
remote is depleted.
Figure 7.2: Immobilizer unit
around the ignition barrel
Figure 7.3: Keyless hybrid
transponder and engine
start/stop button
1 http://www.nxp.com/products/automotive/car_access_immobilizers/immobilizer/
Hitag2
125
Table 7.1: Vehicles using Hitag2 [Key12] – boldface indicates vehicles we tested
Make
Acura
Alfa Romeo
Audi
Bentley
BMW
Buick
Cadillac
Chevrolet
Chrysler
Citroen
Dacia
Daewoo
Dodge
Fiat
GMC
Honda
Hummer
Isuzu
Iveco
Jeep
Kia
Lancia
Mini
Mitsubishi
Nissan
Opel
Peugeot
Pontiac
Porsche
Renault
Saturn
Suzuki
Volkswagen
Models
CSX, MDX, RDX, TL, TSX
156, 159, 166, Brera, Giulietta, Mito, Spider
A8
Continental
Serie 1, 5, 6, 7, all bikes
Enclave, Lucerne
BLS, DTS, Escalade, SRX, STS, XLR
Avanlache, Caprice, Captiva, Cobalt, Equinox, Express, HHR
Impala, Malibu, Montecarlo, Silverado, Suburban, Tahoe
Trailblazer, Uplander
300C, Aspen, Grand Voyager, Pacifica, Pt Cruiser, Sebring
Town Country, Voyager
Berlingo, C-Crosser, C2, C3, C4, C4 Picasso, C5, C6, C8
Nemo, Saxo, Xsara, Xsara Picasso
Duster, Logan, Sandero
Captiva, Windstorm
Avenger, Caliber, Caravan, Charger, Dakota, Durango
Grand Caravan, Journey, Magnum, Nitro, Ram
500, Bravo, Croma, Daily, Doblo, Fiorino, Grande Punto
Panda, Phedra, Ulysse, Scudo
Acadia, Denali, Envoy, Savana, Siera, Terrain, Volt, Yukon
Accord, Civic, CR-V, Element, Fit, Insight, Stream,
Jazz, Odyssey, Pilot, Ridgeline, most bikes
H2, H3
Grandeur, I30, Matrix, Santafe, Sonata, Terracan, Tiburon
Tucoson, Tuscanti
D-Max
35C11, Eurostar, New Daily, S-2000
Commander, Compass, Grand Cherokee, Liberty, Patriot
Wrangler
Carens, Carnival, Ceed, Cerato, Magentis, Mentor, Optima
Picanto, Rio, Sephia, Sorento, Spectra, Sportage
Delta, Musa, Phedra
Cooper
380, Colt, Eclipse, Endeavor, Galant, Grandis, L200
Lancer, Magna, Outlander, Outlander, Pajero, Raider
Almera, Juke, Micra, Pathfinder, Primera, Qashqai, Interstar
Note, Xterra
Agila, Antara, Astra, Corsa, Movano, Signum, Vectra
Vivaro, Zafira
106, 206, 207, 307, 406, 407, 607, 807, 1007, 3008, 5008
Beeper, Partner, Boxer, RCZ
G5, G6, Pursuit, Solstice, Torrent
Cayenne
Clio, Duster, Kangoo, Laguna II, Logan, Master
Megane, Modus, Sandero, Trafic, Twingo
Aura, Outlook, Sky, Vue
Alto, Grand Vitara, Splash, Swift, Vitara, XL-7
Touareg, Phaeton
126
Hitag2
Related work
A similar immobilizer transponder is produced by Texas Instruments under the name
Digital Signature Transponder (DST). It is protected by a different proprietary cryptographic algorithm that uses a secret key of only 40 bits. The workings of these
algorithms are reversed engineered by Bono et al. in [BGS+ 05]. Francillon et al.
demonstrated in [FDv11] that is possible to relay in real-time the (encrypted) communication of several keyless entry systems. The chapter shows that in some cases
such a communication can be intercepted over a distance of at least 100 meters.
The history of the NXP Hitag2 family of transponders overlaps with that of other
security products designed and deployed in the late nineties, see Chapter 4. Originally, information on Hitag2 transponders was limited to data sheets with high level
descriptions of the chip’s functionality [NXP10], while details on the proprietary cryptographic algorithms were kept secret by the manufacturer. This phase, in which
security was strongly based on obscurity, lasted until in 2007 when the Hitag2 inner
workings were reverse engineered [Wie07]. Similarly to its predecessor Crypto1 (used
in MIFARE Classic), the Hitag2 cipher consists of a 48-bit Linear Feedback Shift
Register (LFSR) and a non-linear filter function used to output keystream.
The publication of the Hitag2 cipher attracted the interest of the scientific community. Courtois et al. [COQ09] were the first to study the vulnerabilities of the
Hitag2 stream cipher to algebraic attacks by transforming the cipher state into a
system of equations and using SAT solvers to perform key recovery attacks. Their
most practical attack requires two days computation and a total of four eavesdropped
authentication attempts to extract the secret key. A more efficient attack, requiring
16 chosen initialization vectors (IV) and six hours of computations, was also proposed.
However, and as noted by the authors themselves, chosen-IV attacks are prevented by
the Hitag2 authentication protocol (see Sect. 7.3.5), thus making this attack infeasible
in practice.
In [SNC09], Soos et al. introduced a series of optimizations on SAT solvers that
made it possible to reduce the attack time of Courtois et al. to less than 7 hours.
ˇ
More recently, Stembera
and Novotný [vN11] implemented a brute-force attack that
could be carried out in less than two hours by using the COPACOBANA2 highperformance cluster of FPGAs. Note however, that such attack would require about
4 years if carried out on a standard Personal Computer (PC).
Finally, Sun et al. [SHXZ11] tested the security of the Hitag2 cipher against cube
attacks. Although according to their results the key can be recovered in less than a
minute, this attack requires chosen initialization vectors and thus should be regarded
as strictly theoretical.
2 http://www.copacobana.org
Hitag2
127
Our contribution
In this chapter, we show a number of vulnerabilities in the Hitag2 transponders
that enable an adversary to retrieve the secret key. We propose three attacks that
extract the secret key under different scenarios. We have implemented and successfully
executed these attacks in practice on more than 20 vehicles of various make and model.
On all these vehicles we were able to use an emulating device to bypass the immobilizer
and start the vehicle.
Concretely, we found the following vulnerabilities in Hitag2 .
• The transponder lacks a pseudo-random number generator, which makes the
authentication procedure vulnerable to replay attacks. Moreover, the transponder provides known data when a read command is issued on the block where the
transponder’s identity is stored, allowing to recover keystream. Redundancy in
the commands allow an adversary to expand this keystream to arbitrary lengths.
This means that the transponder provides an arbitrary length keystream oracle.
• With probability 1/4 the output bit of the cipher is determined by only 34 bits of
the internal state. As a consequence, (on average) one out of four authentication
attempts leaks one bit of information about the secret key.
• The 48-bit internal state of the cipher is only randomized by a nonce of 32
bits. This means that 16 bits of information on the secret key are persistent
throughout different sessions.
We exploit these vulnerabilities in the following three practical attacks.
• The first attack exploits the malleability of the cipher and the fact that the
transponder does not have a pseudo-random number generator. It uses a keystream shifting attack following the lines of [dKGHG08]. This allows an adversary to first get an authentication attempt from the reader which can later be
replayed to the transponder. Exploiting the malleability of the cipher, this can
be used to read known plaintext (the identity of the transponder) and recover
keystream. In a new session the adversary can use this keystream to read any
other memory block (with exception of the secret key when configured correctly)
within milliseconds. When the key is not read protected, this attack can also
be used to read the secret key. This was in fact the case for most vehicles we
tested from a French car make.
• The second attack is slower but more general in the sense that the same attack strategy can be applied to other LFSR based ciphers. The attack uses a
time/memory tradeoff as proposed in [Hel80, Bab95, BPVV98, BS00, Oec03,
BMS06]. Exploiting the linear properties of the LFSR, we are able to efficiently
generate the lookup table, reducing the complexity from 248 to 237 encryptions.
128
Hitag2
This attack recovers the secret key regardless of the read protection configuration of the transponder. It requires 30 seconds of communication with the
transponder and another 30 seconds to perform 2000 table lookups.
• The third attack is also the most powerful, as it only requires a few authentication attempts from the car immobilizer to recover the secret key (assuming that
the adversary knows a valid transponder id). This cryptanalytic attack exploits
dependencies among different sessions and a low degree determination of the
filter function used in the cipher. In order to execute this attack, an adversary
first gathers 136 partial authentication attempts from the car. This can be
done within one minute. Then, the adversary needs to perform 235 operations
to recover the secret key. This takes less than five minutes on an laptop with a
dual core running at 2.4 GHz.
Furthermore, besides looking into the security aspects of Hitag2 we also study how
it is deployed and integrated in car immobilizer systems by different manufacturers.
Our study reveals that in many vehicles the transponder is misconfigured by having
readable or default keys, and predictable passwords, whereas the immobilizer unit
employs weak pseudo-random number generators. All cars we tested use identifier
white-listing as an additional security mechanism. This means that in order to use
our third attack to hijack a car, an adversary first needs to eavesdrop, guess or
wirelessly pickpocket a legitimate transponder id, see Section 7.7.5.
Following the principle of responsible disclosure, we have contacted the manufacturer NXP and informed them of our findings six months ahead of publication.
We have also provided our assistance in compiling a document to inform their customers about these vulnerabilities. The communication with NXP has been friendly
and constructive. NXP encourages the automotive industry for years to migrate to
more secure products that incorporate strong and community-reviewed ciphers like
AES [DR02]. It is surprising that the automotive industry is reluctant to migrate to
secure products given the cost difference of a better chip (≤ USD 1) in relation to
the prices of high-end car models (≥ USD 50 000).
7.2
Hardware setup
Before diving into details about Hitag2 , this section introduces the experimental
platform we have developed in order to carry out attacks in real-life deployments of car
immobilizer systems. In particular, we have built a portable and highly flexible setup
allowing us to i) eavesdrop communications between Hitag2 readers and transponders,
ii) emulate a Hitag2 reader, and iii) emulate a Hitag2 transponder. Figure 7.4 depicts
our setup in the setting of eavesdropping communications between a reader and a
transponder.
Hitag2
129
The central element of our experimental platform is the Proxmark board3 , originally developed by Jonathan Westhues4 , and designed
to work with RFID transponders ranging from
low frequency (125 kHz) to high frequency
(13.56 MHz).
The Proxmark board cost around 200 United
States Dollar (USD) and comes equipped with a
FPGA and an ARM microcontroller. Low-level
RF operations such as modulation/demodulation
are carried out by the FPGA, whereas high-level
operations such as encoding/decoding of frames
are performed in the microcontroller.
Hitag2 tags are low frequency transponders used in proximity area RFID applications [NXP10]. Communication from reader
to transponder is encoded using Binary Pulse
Figure 7.4: Experimental setup
Length Modulation (BPLM), whereas from
for eavesdropping
transponder to reader it can be encoded using
either Manchester or Biphase coding. In order to
eavesdrop, generate, and read communications from reader to transponder, we added
support for encoding/decoding BPLM signals, see Figure 7.5.
Figure 7.5: Reader modulation of a read command
For the transponder side, we have also added the functionalities to support the
Manchester coding scheme as shown in Figure 7.6.
Figure 7.6: Communication from transponder to reader
4 http://cq.cx/proxmark3.pl
130
7.3
Hitag2
Hitag2
This section describes Hitag2 in detail. Most of this information is in the public
domain. We first describe the Hitag2 functionality, memory structure, and communication protocols, this comes mostly from the product data sheet [NXP10]. Then
we describe the cipher and the authentication protocol which was previously reverse
engineered in [Wie07]. In Section 7.3.7 we show that it is possible to run the cipher
backwards which we use in our attacks.
7.3.1
Functionality
Access to the Hitag2 memory contents is determined by pre-configured security policies. Hitag2 transponders offer up to three different modes of operation:
1. In public mode the contents of the user data pages are simply broadcast by the
transponder once it is powered up.
2. In password mode reader and transponder authenticate each other by interchanging their passwords. Communication is carried out in the clear, therefore
this authentication procedure is vulnerable to replay attacks.
3. In crypto mode the reader and the transponder perform a mutual authentication
by means of a 48-bit shared key. Communication between reader and transponder is encrypted using a proprietary stream cipher. This mode is used in car
immobilizer systems and will be the focus of this study.
7.3.2
Memory
Hitag2 transponders have a total of 256 bits of non-volatile memory (EEPROM)
organized in 8 blocks of 4 bytes each. Table 7.2 illustrates the memory contents of
a transponder configured in crypto mode. Block 0 stores the read-only transponder
identifier; the secret key is stored in blocks 1 and 2; the password and configuration
bits in block 3; blocks 4 till 7 store user defined memory. Access to any of the
memory blocks in crypto mode is only granted to a reader after a successful mutual
authentication.
7.3.3
Communication
The communication protocol between the reader and transponder is based on the
master-slave principle. The reader sends a command to the transponder, which
then responds after a predefined period of time. There are five different commands:
authenticate, read, read, write and halt. As shown in Table 7.3, the authenticate
command has a fixed length of 5 bits, whereas the others have a length of at least
10 bits. Optionally, these 10 bits can be extended with a redundancy message of size
Hitag2
131
Table 7.2: Hitag2 memory map in crypto mode [NXP10]
Block
0
1
2
3
4−7
Contents
transponder identifier id
secret key low k0 . . . k31
secret key high k32 . . . k47 | reserved
configuration | password
user defined memory
multiple of 5 bits. A redundancy message is composed of the bit-complement of the
last five bits of the command. According to the datasheet [NXP10] this feature is
introduced to “achieve a higher confidence level”.
In crypto mode the transponder starts in a halted state and is activated by the
authenticate command. After a successful authentication, the transponder enters the
active state in which it only accepts active commands which are encrypted. Every
encrypted bit that is transferred consists of a plaintext bit XOR’ed with one bit of the
keystream. The active commands have a 3-bit argument n which represents the offset
(block number) in memory. From this point we address Hitag2 active commands by
referring to commands and explicitly mention authentication otherwise.
Table 7.3: Hitag2 commands using block number n
Command
authenticate
read
read
write
halt
Bits
11000
11n0 n1 n2 00n0 n1 n2 . . .
01n0 n1 n2 10n0 n1 n2 . . .
10n0 n1 n2 01n0 n1 n2 . . .
00n0 n1 n2 11n0 n1 n2 . . .
State
halted
active
active
active
active
Next we define the function cmd which constructs a bit string that represents a
command c on block n with r redundancy messages.
Definition 7.3.1. Let c be the first 2-bit command as defined in Table 7.3, n be a
3-bit memory block number and r be the number of redundancy messages. Then, the
(10+5r)
function cmd : F22 × F32 × N → F2
is defined by
cmd(c, n, 0) = cncn
cmd(c, n, r)cn, r + 1 is odd;
cmd(c, n, r + 1) =
cmd(c, n, r)cn, otherwise.
For example, the command to read block 0 with two redundancy messages results in
the following bit string.
cmd(11, 0, 2) = 11000 00111 11000 00111
132
Hitag2
The encrypted messages between reader and transponder are transmitted without
any parity bits. The transponder response always starts with a prefix of five ones,
see Figure 7.7. In the remainder of this chapter we will omit this prefix. A typical
forward and backwards communication takes about 12 ms.
{11000001111100000111 }
−−−−−−−−−−−−−−−−−−→
11111{id0 . . . id31 }
←−−−−−−−−−−−−−−−−−−
Figure 7.7: Message flow for reading memory block 0
7.3.4
Cipher
In crypto mode, the communication between transponder and reader (after a sucessful
authentication) is encrypted with the Hitag2 stream cipher. This cipher has been
reverse engineered in [Wie07]. The cipher consists of a 48-bit linear feedback shift
register (LFSR) and a non-linear filter function f . Each clock tick, twenty bits of the
LFSR are put through the filter function, generating one bit of keystream. Then the
LFSR shifts one bit to the left, using the generating polynomial to generate a new
bit on the right. See Figure 7.8 for a schematic representation.
Definition 7.3.2. The feedback function L : F48
2 → F2 is defined by L(x0 . . . x47 ) :=
x0 ⊕ x2 ⊕ x3 ⊕ x6 ⊕ x7 ⊕ x8 ⊕ x16 ⊕ x22 ⊕ x23 ⊕ x26 ⊕ x30 ⊕ x41 ⊕ x42 ⊕ x43 ⊕ x46 ⊕ x47 .
The filter function f consists of three different circuits fa , fb and fc which output one
bit each. The circuits fa and fb are employed more than once, using a total of twenty
input bits from the LFSR. Their resulting bits are used as input for fc . The circuits
are represented by three boolean tables that contain the resulting bit for each input.
Definition 7.3.3 (Filter function). The filter function f : F48
f (x0 . . . x47 ) = fc (fa (x2 x3 x5 x6 ), fb (x8 x12 x14 x15 ),
fb (x17 x21 x23 x26 ), fb (x28 x29 x31 x33 ),
fa (x34 x43 x44 x46 )),
where fa , fb : F42 → F2 and fc : F52 → F2 are
fa (i) = (0xA63C)i
fb (i) = (0xA770)i
fc (i) = (0xD949CBB0)i .
For future reference, note that each of the building blocks of f (and hence f itself) is
balanced.
Hitag2
0
1
2
3
133
4
5
fa = 0xA63C
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
fb = 0xA770
fb = 0xA770
fb = 0xA770
⊕
fa = 0xA63C
fc = 0xD949CBB0
keystream
Figure 7.8: Structure of the Hitag2 stream cipher, based on [Wie07]
Remark 7.1 (Cipher schematic). Figure 7.8 is different from the schematic that was
introduced by [Wie07] and later used by [GdKGM+ 08, COQ09, vN11, SHXZ11]. The
input bits of the filter function in Figure 7.8 are shifted by one with respect to those
of [Wie07]. The filter function in the old schematic represents a keystream bit at the
previous state f (xi−1 . . . xi+46 ), while the one in Figure 7.8 represents a keystream bit
of the current state f (xi . . . xi+47 ). Furthermore, we have adapted the boolean tables
to be consistent with our notation.
7.3.5
The authentication protocol used in Hitag2 in crypto mode, reversed engineered and
published online in 2007 [Wie07], is depicted in Figure 7.9. The reader starts the
communication by sending an authenticate command, to which the transponder answers by sending its identifier id. From this point on, communication is encrypted,
i.e., XOR’ed with the keystream. The reader responds with its encrypted challenge
nR and the answer aR = 0xFFFFFFFF also encrypted to prove knowledge of the key;
the transponder finishes with its encrypted answer aT (corresponding to block 3 in
Table 7.2) to the challenge of the reader.
−−−−−authenticate
−−−−−−−−−−−−−→
←−−−−−−−−id
−−−−−−−−−−
{nR }{aR }
−−−−−−−−−−−−−−−−−−→
{aT }
←−−−−−−−−−−−−−−−−−−
Figure 7.9: Hitag2 authentication protocol
During the authentication protocol, the internal state of the stream cipher is
initialized. The initial state consists of the 32-bits identifier concatenated with the
first 16 bits of the key. Then reader nonce nR XOR’ed with the last 32 bits of the key is
shifted in. During initialization, the LFSR feedback is disabled. Since communication
is encrypted from nR onwards, the encryption of the later bits of nR are influenced
by its earlier bits. Authentication is achieved by reaching the same internal state of
the cipher after shifting in nR .
134
7.3.6
Hitag2
Cipher Initialization
The following precisely defines the initialization of the cipher and the generation of
the LFSR-stream a0 a1 . . . and the keystream b0 b1 . . . .
Definition 7.3.4. Given a key k = k0 . . . k47 ∈ F48
2 , an identifier id = id0 . . . id31 ∈
32
∈
F
,
a
reader
answer aR = aR0 . . . aR31 ∈ F32
.
.
.
n
F32
,
a
reader
nonce
n
=
n
R31
R
R0
2 ,
2
2
32
and a transponder answer aT = aT0 . . . aT31 ∈ F2 , the internal state of the cipher at
time i is αi := ai . . . a47+i ∈ F48
2 . Here the ai ∈ F2 are given by
ai := idi
∀i ∈ [0, 31]
a32+i := ki
∀i ∈ [0, 15]
a48+i := k16+i ⊕ nRi
∀i ∈ [0, 31]
a80+i := L(a32+i . . . a79+i )
∀i ∈ N .
Furthermore, we define the keystream bit bi ∈ F2 at time i by
bi := f (ai . . . a47+i )
∀i ∈ N .
Define {nR }, {aR }i , {aT }i ∈ F2 by
{nR }i := nRi ⊕ bi
∀i ∈ [0, 31]
{aR }i := aRi ⊕ b32+i
∀i ∈ [0, 31]
{aT }i := aTi ⊕ b64+i
∀i ∈ [0, 31].
Note that the ai , αi , bi , {nR }i , {aR }i , and {aT }i are formally functions of k, id,
and nR . Instead of making this explicit by writing, e.g., ai (k, id, nR ), we just write ai
where k, id, and nR are clear from the context.
7.3.7
Rollback
To recover the key it is sufficient to learn the internal state of the cipher αi at any
point i in time. Since an attacker knows id and {nR }, the LFSR can then be rolled
back to time zero [Rue86].
Definition 7.3.5. The rollback function R : F48
2 → F2 is defined by R(x1 . . . x48 ) :=
x2 ⊕ x3 ⊕ x6 ⊕ x7 ⊕ x8 ⊕ x16 ⊕ x22 ⊕ x23 ⊕ x26 ⊕ x30 ⊕ x41 ⊕ x42 ⊕ x43 ⊕ x46 ⊕ x47 ⊕ x48 .
If one first shifts the LFSR left using L to generate a new bit on the right, then
R recovers the bit that dropped out on the left, i.e.,
R(x1 . . . x47 L(x0 . . . x47 )) = x0 .
(7.1)
Hitag2
135
Theorem 7.3.1. In the situation from Definition 7.3.4, we have
a32+i = R(a33+i . . . a80+i )
∀i ∈ N
ai = idi
∀i ∈ [0, 31] .
Proof. Straightforward, using Definition 7.3.4 and Equation (7.1).
If an attacker manages to recover the internal state of the LFSR αi = ai ai+1 . . . ai+47
at some time i, then she can repeatedly apply Theorem 7.3.1 to recover a0 a1 . . . a79
and, consequently, the keystream b0 b1 b2 . . .. By having eavesdropped {nR } from the
authentication protocol, the adversary can further calculate
nRi = {nR }i ⊕ bi
∀i ∈ [0, 31] .
Finally, the adversary can compute the secret key as follows
ki = a32+i
k16+i = a48+i ⊕ nRi
7.4
∀i ∈ [0, 15]
∀i ∈ [0, 31] .
Hitag2 weaknesses
This section describes three weaknesses in the design of Hitag2 . The first one is a
protocol flaw while the last two concern the cipher’s design. These weaknesses will
later be exploited in Section 7.5.
7.4.1
Arbitrary length keystream oracle
This weakness describes that without knowledge of the secret key, but by having only
one authentication attempt, it is possible to gather an arbitrary length of keystream
bits from the transponder. Section 7.3.3 describes the reader commands that can
modify or halt a Hitag2 transponder. As mentioned in Definition 7.3.1 it is possible
to extend the length of such a command with a multiple of five bits. A 10-bit command
can have an optional number of redundancy messages r so that the total bit count
of the message is 10 + 5r bits. Due to power and memory constraints, Hitag2 seems
to be designed to communicate without a send/receive buffer. Therefore, all cipher
operations are performed directly at arrival or transmission of bits. Experiments show
that a Hitag2 transponder successfully accepts encrypted commands from the reader
which are sent with 1000 redundancy messages. The size of such a command consists
of 10 + 5 × 1000 = 5010 bits.
Since there is no challenge from the transponder it is possible to replay any valid
{nR }{aR } pair to the transponder to achieve a successful authentication. After sending aT , the internal state of the transponder is initialized and it waits for an encrypted
136
Hitag2
command from the reader as defined in Table 7.3. Without knowledge of the keystream bits b96 b97 . . . and onwards, all possible combinations need to be evaluated. A
command consist of at least 10 bits, therefore there are 210 possibilities. Each command requires a 3-bit parameter containing the block number. Both read and read
receive a 32-bit response, while the write and halt have a different response length.
Hence, when searching for 10-bit encrypted commands that get a 32-bit response there
are exactly 16 out of the 210 values that match. On average the first read command is
found after 32 attempts, the complement of this read and its parameters are a linear
difference and therefore take only 15 attempts more.
cmd(11, 0, 0) ⊕ b96 . . . b105
−−−−−−−−−−−−−−−−−−→
id ⊕ b106 . . . b137
←−−−−−−−−−−−−−−−−−−
Figure 7.10: Read id without redundancy messages
One of the 16 guesses represents the encrypted bits of the read command on the
first memory block. This block contains the id which is known plaintext since it is
transmitted in the clear during the authentication. Therefore, there is a guess such
that the communicated bits are equal to the messages in Figure 7.10.
With the correct guess, 40 keystream bits can be recovered. This keystream is then
used to encrypt a slightly modified read command on block 0 with six redundancy
messages, as explained in Section 7.3.3. The transponder responds with the next
32-bit of keystream which are used to encrypt the identifier as shown in Figure 7.11.
Hence the next 30 keystream bits were retrieved using previously recovered keystream
and by extending the read command.
cmd(11, 0, 6) ⊕ b96 . . . b135
−−−−−−−−−−−−−−−−−−→
id ⊕ b136 . . . b167
←−−−−−−−−−−−−−−−−−−
Figure 7.11: Read id using 6 redundancy messages
This operation can be repeated many times. For example, using the recovered
keystream bits b96 . . . b167 it is possible to construct a 70-bit read command with 12
redundancy messages etc. In practice it takes less than 30 seconds to recover 2048
bits of contiguous keystream.
7.4.2
Dependencies between sessions
Section 7.3.6 shows that at cipher state α79 the cipher is fully initialized and from there
on the cipher only produces keystream. This shows that the 48-bit internal state of
the cipher is randomized by a reader nonce nR of only 32 bits. Consequently, at state
Hitag2
137
α79 , only LFSR bits 16 to 47 are affected by the reader nonce. Therefore LFSR bits 0
to 15 remain constant throughout different session which gives a strong dependency
between them. These 16 session persistent bits correspond to bits k0 . . . k15 of the
secret key.
7.4.3
Approximation of the filter function
The filter function f : F48
2 → F2 consists of three building blocks fa , fb and fc arranged
in a two layer structure, see Figure 7.8. Due to this particular structure, input bits
a34 . . . a47 only affect the rightmost input bit of fc . Furthermore, simple inspection of
fc shows that in 8 out of 32 configurations of the input bits, the rightmost input bit
has no influence on the output of fc . In those cases the output of fc is determined by
its 4-leftmost input bits. Furthermore, this means that with probability 1/4 the filter
function f is determined by the 34-leftmost bits of the internal state. The following
theorem states this precisely.
Theorem 7.4.1. Let X be a uniformly distributed variable over F34
2 . Then
′
P[∀Y, Y ′ ∈ F14
2 : f (XY ) = f (XY )] = 1/4.
Definition 7.4.1. The function that checks if the rightmost input bit to fc has no
influence P : F48
P (x0 . . . x47 ) = (0x84D7)i
where
i = fa (x2 x3 x5 x6 )fb (x8 x12 x14 x15 )
fb (x17 x21 x23 x26 )fb (x28 x29 x31 x33 ).
Because P (x0 . . . x47 ) only depends on x0 . . . x33 we shall overload notation and see
14
P (·) as a function F34
2 → F2 , writing P (x0 . . . x47 ) as P (x0 . . . x33 0 ).
7.5
Attacks
This section describes three attacks against Hitag2 . The first attack is straightforward
and grants an adversary read and write access to the memory of the transponder. The
cryptanalysis described in the second attack recovers the secret key after briefly communicating with the car and the transponder. This attack uses a general technique
that can be applied to other LFSR-like stream ciphers. The third attack describes
a custom cryptanalysis of the Hitag2 cipher. It only requires a few authentication
138
Hitag2
attempts from the car and allows an adversary to recover the secret key with a computational complexity of 235 operations. The last two attacks allow a trade-off between
time/memory/data and time/traces respectively. For the sake of simplicity we describe these attacks with concrete values that are either optimal or what we consider
‘sensible’ in view of currently available hardware.
7.5.1
Malleability attack
This attack exploits the arbitrary length keystream oracle weakness described in Section 7.4.1, and the fact that during the authentication algorithm the transponder
does not provide any challenge to the reader. These well-known weaknesses allow an
adversary to first acquire keystream and then use it to read or write any block on the
card with constant communication and computational complexity. After the recovery
of the keystream bits b96 . . . b137 as shown in Figure 7.10 an adversary can dump the
complete memory of the transponder which includes its password. Recovery of the
keystream and creating a memory dump from the transponder takes in total less than
one second and requires only to be in proximity distance of the victim. This shows
a similar scenario to the attack decribed in Chapter 6 which shows how to wirelessly
pickpocket a MIFARE Classic card from the victim.
The memory blocks where the cryptographic key is stored have an extra optional
protection mechanism. There is a one time programable configuration bit which
determines whether these blocks are readable or not. If the reader tries to read a
protected block, then the transponder does not respond. In that case the adversary
can still use the attacks presented in Section 7.5.2 and Section 7.5.3. If the transponder
is not correctly configured, it enables an adversary to read all necessary data to start
the car.
7.5.2
Time/memory tradeoff attack
This attack is very general and it can be applied to any LFSR-based stream cipher
as long as enough contiguous keystream is available. This is in fact the case with
Hitag2 due to the weakness described in Section 7.4.1. It extends the methods of
similar time/memory tradeoffs articles published over the last decades [Hel80, Bab95,
BPVV98, BS00, Oec03, BMS06]. This attack requires communication with the reader
and the transponder. The next proposition introduces a small trick that makes it
possible to quickly perform n cipher steps at once. Intuitively, this proposition states
that the linear difference between a state s and its n-th successor is a combination of
the linear differences generated by each bit. This will be later used in the attack.
Proposition 7.5.1. Let s be an LFSR state and n ∈ N. Furthermore, let di =
sucn (2i ) i.e., the LFSR state that results from running the cipher n steps from the
Hitag2
139
state 2i . Then
sucn (s) =
47
M
(di · si ) .
i=0
To perform the attack the adversary A proceeds as follows:
1. Only once, A builds a table containing 237 entries. Each entry in the table is
48
of the form hks, si where s ∈ F48
2 is an LFSR state and ks ∈ F2 are 48 bits of
keystream produced by the cipher when running from s. Starting from some
state where s 6= 0, the adversary generates 48 bits of keystream and stores it.
Then it uses Proposition 7.5.1 to quickly jump n = 211 cipher states to the next
entry in the table. This reduces the computational complexity of building the
table from 248 to 48 × 237 = 242.5 cipher ticks. Moreover, in order to improve
lookup time the table is sorted on ks and divided into 224 sub-tables encoded
in the directory structure like /ks_byte1/ks_byte2/ks_byte3.bin where each
ks_byte3.bin file has only 8 KB. The total size of this table amounts 1.2 TB.
2. A emulates a transponder and runs an authentication attempt with the target
car. Following the authentication protocol, the car answers with a message
{nR }{aR }.
3. Next, the attacker wirelessly replays this message to the legitimate transponder
and uses the weakness described in Section 7.4.1 to obtain 256 bytes of keystream
ks0 . . . ks2048 . Note that this might be done while the key is in the victim’s bag
or pocket.
4. The adversary sets i = 0.
5. Then it looks up (in logarithmic time) the keystream ksi . . . ksi+47 in the table
from step 1.
6. If the keystream is not in the table then it increments i and goes back to step 5.
If there is a match, then the corresponding state is a candidate internal state.
A uses the rest of the keystream to confirm whether this is the internal state of
the cipher.
7. Finally, the adversary uses Theorem 7.3.1 to rollback the cipher state and recover the secret key.
Complexity and time. In step 1 the adversary needs to pre-compute a 1.2 TB
table which requires 242.5 cipher ticks, which is equal to 237 encryptions. During
generation, each entry is stored directly in the corresponding .bin file as mentioned
before. Each of these 8 KB files also needs to be sorted but it only takes a few minutes
to sort them all. Computing and sorting the whole table takes less than one day on a
dual core laptop running at 2.4 GHz. Steps 2-3 take about 30 seconds to gather the
256 bytes of keystream from the transponder. Steps 4-6 require (in worst case) 2000
140
Hitag2
table lookups which take less than 30 seconds on a standard laptop. This adds to a
total of one minute to execute the attack from begin to end.
7.5.3
Cryptanalytic attack
A combination of the weaknesses described in Section 7.4.2 and 7.4.3 enable an attacker to recover the secret key after gathering a few authentication attempts from
a car. In case that identifier white-listing is used as a secondary security measure,
which is in fact the case for all the cars we tested, the adversary first needs to obtain
a valid transponder id, see Section 7.7.5.
The intuition behind the attack is simple. Suppose that an adversary has a guess
for the first 34 bits of the key. One out of four traces is expected to have the property
from Theorem 7.4.1 which enables the adversary to perform a test on the first bit of
{aR }. The dependencies between sessions described in Section 7.4.2 allow the attacker
to perform this test many times decreasing drastically the amount of candidate (partial) keys. If an attacker gathers 136 traces this allows her (on average) to perform
136/4 = 34 bit tests, i.e. just as much as key bits were guessed. For the small amount
of candidate keys that pass these tests (typically 2 or 3), the adversary performs an
exhaustive search for the remaining 14 bits of the key. A precise description of this
attack follows.
1. The attacker uses a transponder emulator (like the Proxmark) to initiate 136
authentication attempts with the car using a fixed transponder id. In this way
the attacker gathers 136 traces of the form {nR }{aR }. Next the attacker starts
searching for the secret key. For this we split the key k into three parts k = k~kˆ~k
where k~ = k0 . . . k15 , kˆ = k16 . . . k33 , and ~k = k34 . . . k47 .
2. for each k~ = k0 . . . k15 ∈ F16
2 the attacker builds a table Tk
~ containing entries
~
hy ⊕ b0 . . . b17 , b32 , kyi
~ 14
for all y ∈ F18
2 such that P (ky 0 ) = 1. Note that the expected size of this table
18
16
is 2 × 1/4 = 2 which easily fits in memory.
3. For each kˆ = k16 . . . k33 ∈ F18
2 and for each trace {nR }{aR }, the attacker sets
z := kˆ ⊕ {nR }0 . . . {nR }17 . If there is an entry in Tk~ for which y ⊕ b0 . . . b17
equals z but b32 6= {aR }0 then the attacker learns that kˆ is a bad guess, so he
tries the next one. Otherwise, if b32 = {aR }0 then kˆ is still a viable guess and
therefore the adversary tries the next trace.
4. Each k~kˆ that passed the test for all traces is a partial candidate key. For each
such candidate (typically 2 or 3), the adversary performs an exhaustive search
for the remaining key bits ~k = k34 . . . k47 . For each full candidate key, the
adversary decrypts two traces and checks whether both {aR } decrypt to all
Hitag2
141
ones as specified in the authentication protocol. If a candidate passes this test
then it is the secret key. If none of them passes then the adversary goes back
~
to Step 2 and tries the next k.
Complexity and time. In step 1, the adversary needs to gather 136 partial authentication traces. This can be done within 1 minute using the Proxmark. In steps 2
and 3, the adversary needs to build 216 tables. For each of these tables the adversary
needs to compute 218 encryptions plus 218 table lookups. Step 4 has negligible complexity thus we ignore it. This adds to a total complexity of 216 × (218 + 218 ) = 235
encryptions/lookups. Note that it is straightforward to split up the search space of
k~ in as many processes as you wish. On an dual core laptop, running at 2.4 GHz,
this computation takes less than five minutes. Therefore, the whole attack can be
performed in less than 360 seconds which explains the title of the chapter.
This attack is faster than other practical attacks proposed in [COQ09, vN11]. The
following table shows a comparison between this attack and other attacks from the
literature.
Table 7.4: Comparison of attack times and requirements
Attack
[vN11]
[COQ09]
[SNC09]
[SHXZ11]
Our
1 Soos
2 Sun
7.6
Description
brute-force
sat-solver
sat-solver
cube
cryptanalytic
Practical
yes
yes
no1
no2
yes
Computation
2 102 400 min
2 880 min
386 min
1 min
5 min
Traces
2
4
N/A
500
136
Time
4 years
2 days
N/A
N/A
6 min
et al. require 50 bits of contiguous keystream.
et al. require control over the encrypted reader nonce {nR }
Starting a car
In order to elaborate on the practicality of our attacks, this section describes our
experience with one concrete vehicle. For this we have chosen a German car, mainly
because it has keyless ignition. Instead of the typical mechanical key, this car has
a hybrid remote control which contains a Hitag2 transponder. In the dashboard of
the car there is a slot to insert the remote and a button to start the engine. When
a piece of plastic of suitable size is inserted in this slot the car repeatedly attempts
to authenticate the transponder (and fails). This car uses an identifier white-list as
described in Section 7.7.5. The same section explains how to wirelessly pickpocket a
valid identifier from the victim’s remote. As soon as the car receives a valid identifier,
the dashboard lights up and the LCD screen pops-up displaying the message shown
in Figure 7.12-Left. Note also the sign on the dashboard.
142
Hitag2
Figure 7.12: Left: Authentication failure message
Right: Successful authentication using a Proxmark
At this point we used the Proxmark to quickly gather enough traces and execute
the attack from Section 7.5.3 to recover the secret key. This car is one of the few
that we tested that does not have a predictable password so we wirelessly read it
from the victim’s remote. Then we use the Proxmark to emulate the transponder.
Figure 7.12-Right shows that the car accepts the Proxmark as if it was the legitimate
transponder. The same picture shows (by looking at the tachometer) that at this
stage it is possible to start the engine.
7.7
Implementation weaknesses
To verify the practicality of our attacks, we have tested all three of them on at least
20 different car models from various makes. During our experiments we found that,
besides the weaknesses in cipher and protocol, the transponder is often misconfigured
and poorly integrated in the cars. Most of the cars we tested use a default or predictable transponder password. Some generate nonces with a very low entropy. Most
car keys have vehicle-dependent information stored in the user defined memory of
the transponder, but none of the tested cars actually check this data. Some cars use
Hitag2 for key-less ignition systems, which are more vulnerable because they lack a
physical key. This section summarizes some of the weaknesses we found during our
practical experiments. Especially, Section 7.7.4 shows the implications of the attack
described in Section 7.5.3 when the transponder uses a predictable password. Section 7.7.5 describes how to circumvent identifier white-listing. This is an additional
security mechanism which is often used in vehicle immobilizers.
7.7.1
Weak random number generators
From the cars we tested, most pseudo-random number generators (PRNG) use the
time as a seed. The time intervals do not have enough precision. Multiple authentication attempts within a time frame of one second get the same random number. Even
Hitag2
143
worse, we came across two cars which have a PRNG with dangerously low entropy.
The first one, a French car (A), produces nonces with only 8 bits of entropy, by setting
24 of the 32 bits always to zero as shown in Table 7.5.
Table 7.5: Random numbers generated by car A
Origin
CAR
TAG
CAR
TAG
CAR
TAG
CAR
TAG
Message
18
39 0F 20
0A 00 00
27 23 F8
18
39 0F 20
56 00 00
38 07 50
10
00 23 71 90 14
AF
10
00 85 CA 95 BA
C5
Description
authenticate
id
{nR }{aR }
{aT }
authenticate
id
{nR }{aR }
{aT }
Another French car (B), produced random looking nonces, but in fact, the last
nibble of each byte was determined by the last nibble of the first byte. A subset of
these nonces are shown shown in Table 7.6.
Table 7.6: Random numbers generated by car B
{nR }
20 D1
70 61
B0 A1
D0 41
25 1A
05 7A
C5 3A
E5 DA
7.7.2
0B
1B
5B
FB
3C
9C
5C
FC
08
58
98
B8
AD
8D
4D
6D
{aR }
56 36
1B 18
1E 94
01 3B
15 88
F7 4D
30 B1
D8 BD
F3
F3
62
54
5E
F7
4A
79
66
38
3A
10
19
70
D4
C3
Low entropy keys
Some cars have repetitive patterns in their keys which makes them vulnerable to
dictionary attacks. Recent models of a Korean car (C) use the key with the lowest
entropy we came across. It tries to access the transponder in password mode as well
as in crypto mode. For this it uses the default password MIKR and a key of the form
0xFFFF∗ ∗ ∗ ∗ ∗∗FF as shown in Table 7.7.
7.7.3
Readable keys
Section 7.5.1 shows how to recover the memory dump of a Hitag2 transponder. Almost
all makes protect the secret key against read operations by setting the bits of the
144
Hitag2
Table 7.7: Car C authenticates using the default password and secret key
0xFFFF814632FF
Origin
CAR
TAG
CAR
CAR
TAG
CAR
TAG
Message
18
E4 13 05
4D 49 4B
18
E4 13 05
DA 63 3D
EC 2A 4B
1A
52
1A
24 A7 19 07 12
58
Description
authenticate
id
password = MIKR
authenticate
id
{nR }{aR }
{aT }
configuration in such a way that block one and two are not readable, but there
are some exceptions. For example, experiments show that most cars from a French
manufacturer have not set this protection bit. This enables an attacker to recover the
secret key in an instant. Even more worrying, many of these cars have the optional
feature to use a remote key-less entry system which have a much wider range and are
therefore more vulnerable to wireless attacks. The combination of a transponder that
is wirelessly accessible over a distance of several meters and a unprotected readable
key is most worrying.
7.7.4
Predictable transponder passwords
The transponder password is encrypted and sent in the transponder answer aT of the
authentication protocol. This is an additional security mechanism of the Hitag2 protocol apart from the cryptographic algorithm. Besides the fact that the transponder
proves knowledge of the secret key, it sends its password encrypted. In general it
is good to have some fallback scenario and countermeasure if the used cryptosystem
gets broken. Section 7.5.3 demonstrates how to recover the secret key from a vehicle.
But to start the engine, it is necessary to know the transponder password as well.
Experiments show that at least half of the cars we tested on use default or predictable
passwords.
7.7.5
Identifier pickpocketing
The first generation of vehicle immobilizers were not able to compute any cryptographic operations. These transponders were simply transmitting a constant (unique)
identifier over the RF channel. Legitimate transponder identifiers were white-listed
by the vehicle and only those transponders in the white-list would enable the engine to start. Most immobilizer units in cars still use such white-listing mechanism,
which is actually encouraged by NXP. These cars would only attempt to authenticate transponders in their white-list. This is an extra obstacle for an attacker, namely
recovering a genuine identifier from the victim before being able to execute any at-
Hitag2
145
tack. There are (at least) two ways for an adversary to wirelessly pickpocket a Hitag2
identifier:
• One option is to use the low-frequency (LF) interface to wirelessly pickpocket
the identifier from the victim’s key. This can be done within proximity distance
and takes only a few milliseconds. According to the Hitag2 datasheet [NXP10],
the communication range of a transponder is up to one meter. However, Hitag2
transponders embedded into car keys are optimized for size and do not achieve
such a communication distance. Nevertheless, an adversary can use tuned equipment with big antennas that ignore radiation regulations (e.g., [FCC09]) in order
to reach a larger reading distance. Many examples in the literature show the
simplicity and low-cost of such a setup [SA00, KW05, KW06, Han06].
• Another option is to use the wide range Ultra-High Frequency (UHF) interface.
For this an adversary needs to eavesdrop the transmission of a hybrid Hitag2
transponder [PHI99] when the victim presses a button on the remote (e.g. to
close the doors). Most keyless entry transponders broadcast their identifier in
the clear on request (see for example [PHI99]).
With respect to the LF interface, the UHF interface has a much wider transmission
range. As shown in [FDv11] it is not hard to eavesdrop such a transmission from
a distance of 100 meters. From a security perspective, the first generation Hitag2
transponders have a physical advantage over the hybrid transponders since they only
support the LF interface.
7.8
Mitigation
This section briefly discusses a simple but effective authentication protocol for car
immobilizers and it also describes a number of mitigating measures for the attacks
proposed in Section 7.5. For more details we refer the reader to [BP08, And10].
First of all we emphasize that it is important for the automotive industry to migrate from weak proprietary ciphers to a peer-reviewed one such as AES [DR02], used
in Counter with CBC-MAC (CCM) mode. A straightforward mutual authentication
protocol is sketched in Figure 7.13. The random nonces nR , nT , secret key k and
transponder password PWDT should be at least 128 bits long. Comparable schemes
are proposed in the literature [LSS05, LSS06, WHWC07, WWW07, WKR+ 08].
There are already immobilizer transponders on the market that implement AES
like the ATA5795[AT11] from Atmel and the Hitag AES / Pro [NXP11] from NXP. It
should be noted that, although they use a peer-reviewed encryption algorithm, their
authentication protocol is still proprietary and therefore lacks public and academic
scrutiny.
In order to reduce the applicability of our cryptographic attack, the automotive
industry could consider the following measures. This attack is the most sensitive as it
146
Hitag2
−−−−−authenticate
−−−−−−−−−−−−−→
id, nT
←−−−−−−−−−−−−−−−−−−
{nR , nT }k
−−−−−−−−−−−−−−−−−−→
{nR , PWDT }k
←−−−−−−−−−−−−−−
−−−−
Figure 7.13: Immobilizer authentication protocol using AES
does not require access to the car key. These countermeasures should be interpreted as
palliating (but not a solution) before migrating to a more secure and openly designed
product.
• Extend the transponder password
The transponder password is an important part of the authentication protocol
but grievously it has only an entropy of 24 bits. Such a password is easy to find
via exhaustive search. Furthermore, as we mentioned in Section 7.7.4, manufacturers often deployed their cars with predictable transponder passwords. As
shown in Table 7.2, there are four pages of user defined memory available in a
Hitag2 transponder. These could be used to extend the transponder password
with 128 bits of random data to increase its entropy. This implies that an adversary needs to get access to the transponder’s memory before being able to
steal a car.
• Delay authentication after failure
The cryptographic car-only attack explained in Section 7.5.3 requires several authentication attempts to reduce the computational complexity. Extending the
time an adversary needs to gather these traces increases the risk of being caught.
To achieve this, the immobilizer introduces a pause before re-authenticating that
grows incrementally or exponentially with the number of sequential incorrect authentications. An interesting technique to implement such a countermeasure is
proposed in [RSH+ 12]. The robustness, availability and usability of the product is affected by this delay, but it increases the attack time considerably and
therefore reduces the risk of car theft.
Besides these measures, it is important to improve the pseudo-random number
generator in the vehicles which is used to generate reader nonces. Needless to say, the
same applies to cryptographic keys and transponder passwords. NIST has proposed
a statistical test suite which can be used to give an approximation about the quality
of a pseudo-random number generator [RSN+ 01].
7.9
Conclusions
We have found many serious vulnerabilities in the Hitag2 and its usage in the automotive industry. In particular, Hitag2 allows replaying reader data to the transponder;
Hitag2
147
provides an unlimited keystream oracle and uses only one low-entropy nonce to randomize a session. These weaknesses allow an adversary to recover the secret key within
seconds when wireless access to the car and key is available. When only communication with the car is possible, the adversary needs less than six minutes to recover the
secret key. The cars we tested use identifier white-listing. To circumvent this, the
adversary first needs to obtain a valid transponder id by other means e.g., eavesdrop
it when the victim locks the doors. This UHF transmission can be intercepted from a
distance of 100 meters [FDv11]. We have executed all our attacks (from Section 7.5)
in practice within the claimed attack times. We have experimented with more than
20 vehicles of various makes and models and found also several implementation weaknesses.
In line with the principle of responsible disclosure, we have notified the manufacturer NXP six months before disclosure. We have constructively collaborated with
NXP, discussing mitigating measures and giving them feedback to help improve the
security of their products.
7.10
Acknowledgments
The authors would like to thank Bart Jacobs for his firm support in the background.
We are also thankful to E. Barendsen, L. van den Broek, J. de Bue, Y. van Dalen, E.
Gouwens, R. Habraken, I. Haerkens, S. Hoppenbrouwers, K. Koster, S. Meeuwsen, J.
Reule, J. Reule, I. Roggema, L. Spix, C. Terheggen, M. Vaal, S. Vernooij, U. Zeitler,
B. Zwanenburg, and those who prefer to remain anonymous for (bravely) volunteering
their cars for our experiments.
Chapter 8
SecureMemory, CryptoMemory and
CryptoRF
The Atmel chip families SecureMemory, CryptoMemory, and CryptoRF use a
proprietary stream cipher to guarantee authenticity, confidentiality, and integrity.
This chapter describes the cipher in detail and points out several weaknesses. One
is the fact that the three components of the cipher operate largely independently;
another is that the intermediate output generated by two of those components
is strongly correlated with the generated keystream. For SecureMemory, a single
eavesdropped trace is enough to recover the secret key with probability 0.57 in
239 cipher ticks. This is a factor of 231.5 faster than a brute force attack. On a
single core 2 GHz laptop, this takes around 10 minutes. With more traces, the
secret key can be recovered with virtual certainty without significant additional cost
in time. For CryptoMemory and CryptoRF, if one has 2640 traces it is possible
to recover the key in 252 cipher ticks, which is 219 times faster than brute force.
On a 50 machine cluster of 2 GHz quad core machines this would take less than 2 days.
8.1
Introduction
This chapter addresses the (in)security of the cryptographic mechanisms used in the
Atmel product families SecureMemory, CryptoMemory, and CryptoRF.
These products are integrated circuits, consisting essentially of a small piece of
memory and have cryptographic capabilities to authenticate and encrypt. They have
two main application areas: in smart cards (ID and access cards, health care cards,
loyalty cards, internet kiosk, energy meters, and e-government); and embedded, to
authenticate one piece of hardware to another or for the secure storing of cryptographic data (printers and print cartridges, removable storage devices, set top boxes,
access control systems, subassembly authentication, counterfeit protection, networked
systems) [BJ04, CGY08, ZJS+ 09]. A concrete example is the widely sold NVIDIA
graphics cards, which uses CryptoMemory as secure storage to protect the HDCP
license keys1 , required to play high-definition video2 . It is also used in media players
1 http://www.expreview.com/review/2007-10-17/1192604816d5951_2.html
2 http://download.nvidia.com/downloads/pvzone/Checklist_for_Building_a_HDPC.pdf
150
SecureMemory, CryptoMemory and CryptoRF
such as Microsoft’s Zune Player[Dip09] and SanDisk’s Sansa Connect3 , for instance
to securely store the device id and device certificate.
The Atmel chips AT88SC153 and AT88SC1608, which we call here the SecureMemory family, were introduced in 1999. A newer version, the CryptoMemory family,
which includes the AT88SCxxxxC chips, with more advanced cryptographic features,
was introduced in early 2002. These two families only have contact interfaces; in
late 2003, the CryptoRF family, which is a variant of the CryptoMemory family with
the AT88SCxxxxCRF chips, was introduced also has a Radio Frequency (RF) interface [Jar04].
The technology used in the chips is covered by US Patent 7395435 B2 [BCM08].
Details on the communication protocol used between a card (or slave device) and a
reader (or master device) can be found in the documentation [AT07, AT09]; although
this does include details on how the cryptographic algorithms are called and on the
message flow between card and reader, it does not provide detailed information on
the cipher itself. As experience has shown with other chips from the same era, the
secrecy of such a proprietary cipher does not inspire confidence in its cryptographic
strength, see Chapter 4. The cipher used in CryptoMemory, however, boasts a security
stronger than DES; a security evaluation [Tec05] claims that the observed bias in the
output is “trivial enough to confirm that CryptoMemory is impermeable to shortcut
attacks”. Admittedly, sophisticated attacks were not in the scope of this evaluation.
We should note at this point that a backdoor has been found in the SecureMemory
chips AT88SC153/1608 [Fly08]: using ultra-violet light, an EEPROM fuse can be
restored to its original value and the contents of the memory can be read un-encrypted.
A relay attack has been executed against the newer chips [KCP07].
Our contribution
As part of our research we have reverse engineered the security mechanisms of the
SecureMemory and CryptoMemory families (the CryptoRF family uses exactly the
same cipher as the CryptoMemory family, so we ignore that distinction from now on).
This includes the ciphers, the authentication and encryption mechanisms, and the
password mechanisms. This was accomplished by disassembling various executable
applications from Atmel (e.g., ECEStudio), that implement the ciphers in software.
We wrote a prototype implementation and then we compared its output with the
packages we observed from the cards.
We have implemented the full functionality of these families in software and released this under GPL licence4 . Our implementation can communicate with genuine
Atmel products using commercial smartcards and readers.
3 http://www.rockbox.org/wiki/SansaConnect
4 Sample
code available at http://www.libnfc.org/documentation/examples/nfc-cryptorf
151
In this chapter, we focus exclusively on the ciphers and the authentication mechanism; that is all that is needed to recover the keys.
SecureMemory and CryptoMemory use a stream cipher. It has an internal state of
109 bits (SecureMemory) or 117 bits (CryptoMemory), organized in three shift registers with a non-linear feedback function. Every clock tick, two of the registers produce
4 bits of output; the output of the third is used to select bits from one of the two other
registers, producing 4 bits of keystream. The difference between SecureMemory and
CryptoMemory, as far as the cipher is concerned, is that in CryptoMemory the last 8
bits of the output are remembered and are fed back into the shift registers every tick.
Details are described in Section 8.3.
During initialization, 64-bit nonces from reader and card and a 64-bit shared key
are used to set the initial state of the cipher; reader and tag subsequently authenticate
by exchanging part of the following keystream. See Section 8.3.1 for details.
Next, we describe passive attacks against SecureMemory and CryptoMemory. We
assume that an attacker has managed to eavesdrop a number of authentication sessions. For SecureMemory, we use a combination of a correlation attack (see for example [Rue92]) and a meet-in-the-middle attack to recover a significant part of the
internal state of the cipher. Meet-in-the-middle attacks were also showed to be successful against other stream ciphers like A51 [BBK08] and KeeLoq [IKD+ 08]. Once
we have the internal state of the cipher, we use a meet-in-the-middle attack to recover
the shared secret key. This attack costs 239 time, taking ticks of the cipher as unit.
On a single core 2 GHz laptop, the attack takes approximately 10 minutes. Even
though this attack is rather straightforward, it serves as an intermediate, didactic
step to the more involved attack on CryptoMemory.
For CryptoMemory, the principal idea behind the attack is the same, but it is
much more complicated because of the presence of the feedback of the output into
the cipher state. We still use a correlation attack to recover a large part of the internal
state (two of the three registers). Unlike with SecureMemory, we do not recover this
with certainty, but obtain a few hundred to a few thousand candidates. Because of the
feedback, it is also not directly possible to roll back these partial states, so we have to
search for the correct remaining part of the internal state (the third register). After
this, we can again unroll and use a meet-in-the-middle attack to recover the shared
secret key. Using approximately 2640 traces, this attack has a time complexity of 252
cipher ticks; it would take less than 2 days on a 50 machine cluster of 2 GHz quad core
machines. Details on these attacks are described in Section 8.4 (for SecureMemory)
and Section 8.5 (for CryptoMemory).
We have discussed these vulnerabilities with Atmel in October 2009. To give the
manufacturer ample time to take appropriate measures, we have not disclosed them
until March 2010.
152
8.2
Background
SecureMemory and CryptoMemory are ISO/IEC 7816 smartcards that communicate
through a contact interface. CryptoRF is a ISO/IEC 14443-B smartcard that uses
a contactless interface. CryptoMemory is also available in the form of an embedded
EEPROM IC with a serial interface. The available memory ranges from 128 bytes
to 32 KB. The memory is split into multiple user zones and one system zone which
stores the configuration of the smartcard.
Figure 8.1: Logical memory structure
The system zone is divided into six sections: card identification, access control,
cryptography, secret and password. Blank cards operate with a user-defined identifier which is customized by the system integrator. To achieve key diversification,
the documentation recommends that the authentication keys should be derived from
this identifier. The access control section is used to restrict read and write operations per user zone and define the requirements of successful Authentication and
Key Agreement (AKA) and encrypted communication. To verify the legitimacy and
prevent eavesdropping of data and passwords a mutual authentication protocol with
encryption is available.
8.3
The ciphers
This section describes the stream ciphers that are used in SecureMemory and CryptoMemory. As mentioned in the introduction, the internal state of the cipher consists
of three shift registers; for CryptoMemory, an additional register remembers the last
8 bits of output.
153
⊕
0 1 2 3 4 5 6
⊞
0 1 2 3 4 5 6
⊞
0 1 2 3 4
⊕
0 1
input
(remove for SM)
⊞
⊕
keystream
Figure 8.2: The schematic of the SecureMemory and CryptoMemory cipher
Definition 8.3.1. A cipher state of SecureMemory s is an element of F109
consisting
2
of the following components:
1. the left-hand segment l = (l0 , . . . , l6 ) ∈ (F52 )7 ;
2. the middle segment m = (m0 , . . . , m6 ) ∈ (F72 )7 ;
3. the right-hand segment r = (r0 , . . . , r4 ) ∈ (F52 )5 .
The cipher state of CryptoMemory is an element of F117
2 . In addition to the three
segments above, it also has the following component:
4. the feedback segment f = (f0 , f1 ) ∈ (F42 )2 .
Every tick, a cipher state s together with an input a ∈ F82 evolves in a successor
state s′ . First, the input a (and in case of CryptoMemory also the feedback segment
f ) are XORed into s at several places, giving an intermediate state sˆ. Second, the left,
right and middle segments are shifted to the right and new 0th entries are computed
using a bitwise rotate and a modular addition. Thirdly and finally, the output segment
is shifted to the left and a new 1st entry is computed using a non-linear function of the
other segments, giving the successor state s′ . The following sequence of definitions
gives the details of this construction; see also Figure 8.2.
Definition 8.3.2. Define the bitwise left rotate operator L : Fn2 → Fn2 by
L(x0 x1 . . . xn−1 ) = (x1 . . . xn−1 x0 ).
Definition 8.3.3. Define the modified modular addition operator ⊞ : Fn2 × Fn2 → Fn2
(identifying elements of Fn2 with elements of {0, 1, . . . , 2n − 1}) by
(
x + y (mod 2n − 1) if x = y = 0 or x + y 6= 0
x⊞y=
2n − 1
otherwise,
where + (mod 2n − 1) denotes integer addition modulo 2n − 1.
154
Note that this operation is not injective when fixing one of the arguments: x ⊞ 0
and x ⊞ (2n − 1) both equal x (unless x = 0, because 0 ⊞ 0 = 0 and 0 ⊞ (2n − 1) =
2n − 1). Also observe that the result of ⊞ is never 0 unless both operands are 0.
Definition 8.3.4. Let s = (l, m, r, f ) ∈ F117
be a cipher state (for CryptoMemory;
2
for SecureMemory, ignore f ) and let a ∈ F82 be an input. We define the intermediate
state sˆ = (ˆl, m,
ˆ rˆ, fˆ) and the successor state s′ = (l′ , m′ , r′ , f ′ ) as follows. For CryptoMemory, define b := a ⊕ f0 f1 ; for SecureMemory, b := a. The intermediate state
sˆ is given by
ˆl2 := l2 ⊕ b3 b4 b5 b6 b7
m
ˆ 4 := m4 ⊕ b4 b5 b6 b7 b0 b1 b2
(8.1)
rˆ1 := r1 ⊕ b0 b1 b2 b3 b4
and all other entries are copied from l, m, r, and f . The successor state s′ is given
by
′
li+1
:= ˆli
m′i+1
′
ri+1
l0′
m′0
r0′
i ∈ {0, . . . , 5}
:= m
î
i ∈ {0, . . . , 5}
:= rî
:= ˆl3 ⊞ L(ˆl6 )
i ∈ {0, . . . , 3}
:= m
ˆ 5 ⊞ L(m
ˆ 6)
:= rˆ2 ⊞ rˆ4 .
We call the rightmost 4 bits of l0′ ⊕ l4′ the output of the left-hand segment (i.e.,
′
′
′
′
′
′
, a bitwise XOR) and denote it by outputl(l′ ).
⊕ l4,4
. . . l0,4
⊕ l4,2
l0,2
⊕ l4,1
l0,1
We call the rightmost 4 bits of r0′ ⊕ r3′ the output of the right-hand segment r′ (i.e.,
′
′
′
′
′
′
) and denote it by outputr(r′ ). The output of
⊕ r3,4
. . . r0,4
⊕ r3,2
r0,2
⊕ r3,1
r0,1
′
the cipher state s , denoted by output(s′ ) is defined by
output(s )i =
′
(
outputl(l′ )i ,
if m′0,i+3 = 0;
outputr(r′ )i ,
if m′0,i+3 = 1
i ∈ {0, . . . , 3}.
Note how the rightmost 4 bits of the middle segment acts as a selector; it selects either
a bit from the left-hand segment or a bit from the right-hand segment to be included
in the output. For CryptoMemory, we define
f0′ := fˆ1 (= f1 )
f1′ := output(s′ ).
Define the transition function suc that takes an input a and a state s and outputs the successor state s′ . We write sucn (a, s) denoting suc(a, s) when n = 1 and
sucn−1 (a, suc(a, s)) when n > 1.
155
Note that the whole feedback segment can be reconstructed from the other three
segments; f1 = output(s), but also f0 can be reconstructed: shift all segments in s
one to the left and take output. To be precise, we have
f0,i =
(
l1,i+1 ⊕ l5,i+1
if m1,i+3 = 0
r1,i+1 ⊕ r4,i+1
if m1,i+3 = 1.
(8.2)
(So the rightmost 4 bits of m1 act as a selector between the rightmost 4 bits of l1 ⊕ l5
and r1 ⊕ r4 .)
8.3.1
Initialization and authentication
The cipher is initialized during the authentication protocol. At the beginning of
this protocol, tag and reader exchange nonces as depicted in Figure 8.3. The tag
nonce is scrambled together with the first half of the reader nonce and fed into the
cipher. Subsequently, the shared key scrambled together with the second half of the
reader nonce is fed in. Then, the cipher produces keystream that will be used as
authenticator for both reader and tag. The precise definitions follow.
Let nt ∈ (F82 )8 be a tag nonce, nr ∈ (F82 )8 a reader nonce, and k ∈ (F82 )8 the
shared key between the tag and the reader.
Tag
−−−−−−−−−−−−nt
−−−−−−−−−−−→
nr, ar
←−−−−−−−−−−−−−−−−−−−−−−−
−−−−−−−−−−−−at
−−−−−−−−−−−→
Reader
Figure 8.3: Authentication protocol
The initial cipher state has all components l, m, r (for SecureMemory and CryptoMemory) and f (for CryptoMemory) equal to zero. Then the cipher is evolved
through the states s0 , s1 , . . . defined as
s0 := 0
si+1 := suc(nri , sucv (nt2i+1 , sucv (nt2i , si )))
i ∈ {0, . . . , 3}
si+5 := suc(nri+4 , suc (k2i+1 , suc (k2i , si+4 )))
i ∈ {0, . . . , 3}
v
v
where v = 1 for SecureMemory and v = 3 for CryptoMemory. The following is
an overview of the input during the initialisation phase of SecureMemory (left) and
CryptoMemory (right).
156
(s0 )
(s1 )
(s2 )
(s3 )
(s4 )
(s5 )
(s6 )
(s7 )
(s8 )
nt0
nt2
nt4
nt6
k0
k2
k4
k6
nt1
nt3
nt5
nt7
k1
k3
k5
k7
nr0
nr1
nr2
nr3
nr4
nr5
nr6
nr7
(s0 )
(s1 )
(s2 )
(s3 )
(s4 )
(s5 )
(s6 )
(s7 )
(s8 )
nt0
nt2
nt4
nt6
k0
k2
k4
k6
nt0
nt2
nt4
nt6
k0
k2
k4
k6
nt0
nt2
nt4
nt6
k0
k2
k4
k6
nt1
nt3
nt5
nt7
k1
k3
k5
k7
nt1
nt3
nt5
nt7
k1
k3
k5
k7
nt1
nt3
nt5
nt7
k1
k3
k5
k7
nr0
nr1
nr2
nr3
nr4
nr5
nr6
nr7
Starting from the state called s0 , we feed in nt0 (three times for CryptoMemory),
then nt1 (three times for CryptoMemory), then nr0 , and arrive at the state called s1 ,
etc. Note that these states are non-consecutive, e.g., s1 is not the successor of s0 ; we
have only named those states that are needed for the description.
The authentication protocols for CryptoMemory and SecureMemory are similar,
although the keystream bits used as authenticators are different in both cards. The
precise definitions follow.
SecureMemory Authentication
After initialization, the cipher produces keystream that will be used for mutual authentication of tag and reader. In SecureMemory, every second output nibble is
discarded. The keystream bits used as authenticators for the tag at ∈ (F42 )16 and for
the reader ar ∈ (F42 )16 are interleaved. We define the following relevant states:
si := suc2 (0, si−1 )
i ∈ {9, . . . , 40}.
The authenticator nibbles for the tag are
ati := output(s2i+9 )
ati+1 := output(s2i+10 )
i ∈ {0, 2, . . . , 14}
and the authenticator nibbles for the reader are
ari := output(s2i+11 )
ari+1 := output(s2i+12 )
i ∈ {0, 2, . . . , 14}.
The overview of the output during the authentication phase of SecureMemory is
as follows.
(s8 )
(s12 )
(s16 )
(s20 )
(s24 )
(s28 )
(s32 )
(s36 )
(s40 )
−
−
−
−
−
−
−
−
at0
at2
at4
at6
at8
at10
at12
at14
− at1
− at3
− at5
− at7
− at9
− at11
− at13
− at15
157
− ar0
− ar2
− ar4
− ar6
− ar8
− ar10
− ar12
− ar14
− ar1
− ar3
− ar5
− ar7
− ar9
− ar11
− ar13
− ar15
Staring from the state called s8 , one output nibble is discarded, the following is called
at0 , the next one is discarded, etc., until ar1 . The state then reached is called s12 ,
etc.
CryptoMemory Authentication
After initialization, CryptoMemory generates the reader authenticator first and then
the tag authenticator. While generating the reader authenticator ar ∈ (F42 )16 , five
keystream nibbles are discarded and then two nibbles (one byte) are used, with the
exception of the first byte where only 4 nibbles are discarded. The tag authenticator at ∈ (F42 )16 consists of the bitstring 0xff followed by the next 14 (consecutive)
keystream nibbles produced. To be precise, define the following sequence of states.
Again, note that these states are not consecutive.
s9 := suc5 (0, s8 )
s10 := suc(0, s9 )
si := suc6 (0, si−1 )
i ∈ {11, 13, . . . , 23}
si := suc(0, si−1 )
i ∈ {12, 14, . . . , 24}
si := suc(0, si−1 )
i ∈ {25, . . . , 38}.
Then the reader authenticator is defined as
ari := output(si+9 )
i ∈ {0, . . . , 15}
and the tag authenticator is defined as
at0 := 0xf
at1 := 0xf
ati := output(si+23 )
i ∈ {2, . . . , 15}.
The following shows a schematic overview of the output during the authentication
phase of CryptoMemory.
158
(s8 )
(s12 )
(s16 )
(s20 )
(s24 )
(s31 )
(s38 )
4×−
5×−
5×−
5×−
at2
at9
ar0
ar4
ar8
ar12
at3
at10
ar1
ar5
ar9
ar13
at4
at11
5×−
5×−
5×−
5×−
at5
at12
ar2
ar6
ar10
ar14
at6
at13
ar3
ar7
ar11
ar15
at7
at14
at8
at15
Starting from the state called s8 , the first 4 output nibbles generated are discarded,
the next two are called ar0 and ar1 respectively, the next 5 are discarded again, etc.
For future reference, note that an attacker who has observed an authentication trace
sees 16 consecutive keystream nibbles, viz., ar14 , ar15 , at2 , at3 , . . . , at15 .
Example 8.1. Table 8.1 shows an authentication trace using the shared key k =
0x4f794a463ff81d81; the first two bytes on every line are a command and the last
two are a CRC.
Table 8.1: Communication trace of the CryptoMemory authentication protocol
R
T
R
T
R
T
8.4
Message
1600 5007 add3
1600 ff81c91e11a6393e 00 1b66
1800 3d28a6ae3a767a25 d308e40bb3200ee0 a905
1800 00 9b85
1600 5007 add3
1600 ff4c1c06b43cbcc2 00 440b
Interpretation
Read nt
nt = ff. . . 3e
Auth nr = 3d. . . 25, ar = d3. . . e0
Ok
Read at
at = ff. . . c2
Attacking SecureMemory
We now turn our attention to attacking the ciphers. We start with an attack against
SecureMemory. We assume that an attacker has eavesdropped a single authentication
session; the attack we describe recovers the shared secret key with probability at
least 0.57. By using more authentication sessions we can arbitrarily increase this
probability.
The attack we describe takes place in two phases. First, we use a correlation attack
to recover (the left-hand and right-hand segments of) the internal state of the cipher
just after feeding in the key and just before generating the authenticators (called state
s8 in Section 8.3.1). Since the attacker knows nr and nt, he can also compute the
state just before feeding in the shared secret key (called state s4 ). Then, we use a
meet-in-the-middle attack to recover k.
The running time of the whole attack is 239 ticks of the SecureMemory cipher,
which on a single core 2 GHz laptop takes about 10 minutes.
8.4.1
159
Recovering the internal state
There are two weaknesses in the SecureMemory cipher that make it possible to recover
the internal state of the cipher. The first one is that there is a high correlation
between the output of the right-hand (or left-hand) segment and the keystream itself.
Consider a state s and its output nibble output(s). For those bits for which the middle
segment chooses the right (m0,i = 1), the output bit is equal to the corresponding
output bit of the right-hand segment (output(s)i = outputr(r)i ). Assuming a uniform
probability, this happens with probability 21 . Where the middle segment chooses the
left (m0,i = 0), the output bit is equal to the corresponding output bit of the left-hand
segment (output(s)i = outputl(l)i ), but with probability 12 this equals the output bit
of the right-hand segment (output(r)i ) anyway. So, with probability 21 + 21 · 12 = 43 ,
an output bit of the right-hand segment equals the corresponding keystream bit (and
similarly for the left-hand segment). The second weakness is that the three segments
operate independently. So, knowing (or guessing) the right-hand (or left-hand or
middle) segment of a state s, the attacker can compute the right-hand (or left-hand
or middle) segment of the successor state s′ .
Definition 8.4.1. Consider a guess r for the right-hand segment of the internal state
of the cipher at the start of the authentication phase (state s8 in Section 8.3.1) and
consider the 16 output nibbles generated by the right-hand segment that are used to
compute at and ar. We define the score of r to be the number of bits that these 16
output nibbles have in common with the actual keystream (i.e., with at and ar). A
similar definition applies for a guess l of the left-hand segment.
For a wrong guess of the right-hand segment, one would expect the score to be 64
(half of 128 bits correct); for the correct guess, one would expect the score to be 96 ( 34
of the 128 bits correct). Hence, the attacker iterates over the 225 possible right-hand
segments and computes their score. The one with the highest score is most likely to
be the correct one. As an approximation, we can assume that the score for the 225 − 1
wrong guesses is binomially distributed with parameters p = 12 and n = 128 (128 bits,
each of which has a probability of 21 of being correct) and the score for the correct
guess is binomially distributed with parameters p = 43 and n = 128. Also assuming,
again as an approximation, that all these score are independent random variables, the
following proposition applies.
Proposition 8.4.1. Let X1 , . . . , X225 −1 ∼ Binom(128, 12 ) and Y ∼ Binom(128, 34 ) be
independent random variables. Then
P[∀i.Xi < Y ] ≈ 0.57
and
P[∃i.[Y < Xi ∧ ∀j 6= i.Xj < Xi ]] ≈ 0.24.
160
Proof. Since the Xi ’s and Y are assumed to be independent, we get
P[∀i.Xi < Y ] =
=
128
X
k=0
128
X
P[∀i.Xi < k ∧ Y = k]
25
P[X1 < k]2
−1
· P[Y = k] ≈ 0.57
k=0
and
P[∃i.[Y < Xi ∧ ∀j 6= i.Xj < Xi ]]
=
128
X
P[∃i.Xi = k ∧ ∀j 6= i.Xj < k ∧ Y < k]
k=0
=
25
128 2X
−1
X
P[Xi = k ∧ ∀j 6= i.Xj < k ∧ Y < k]
k=0 i=1
=
128
X
25
(225 − 1) · P[X1 = k] · P[X2 < k]2
−2
· P[Y < k]
k=0
≈ 0.24
So, as an approximation, with probability 0.57, the correct right-hand segment has
a score that is higher than the score of all the wrong ones. With probability of only
0.24, a wrong right-hand segment has a score higher than all the others (including
the correct one). Therefore we get with probability 0.81 one right-hand segment that
scores higher than all the others. So we need, on average 1/0.81 ≈ 1.23 traces to
obtain such a single candidate. The conditional probability that this candidate is
indeed the correct right-hand segment is 0.57/0.81 ≈ 0.71. To obtain a trace in which
the highest scoring right-hand segment is indeed the correct one, we need on average
1/0.57 ≈ 1.75 traces.
From now on, assume that we have a trace for which exactly one right-hand
segment scores higher than all the others. For the attack we assume that it is the
correct right-hand segment r.
Then we try to find possible candidates for the left-hand segment. Note that
for those bits of the known keystream where the output of the right-hand segment
does not produce the correct bit, the corresponding bit from the middle segment
(the selector) must choose the left-hand segment and the corresponding bit from the
output of the left-hand segment must equal that keystream bit. For instance, when r
has a score of 96, this happens 128 − 96 = 32 times. So, the attacker iterates over all
235 possibilities for the left-hand segment, keeping only those that satisfy the above
constraint. Experiments show that this leaves only between, approximately, 10 and
200 candidates.
At this point, one could also try to recover (candidates for) the middle segment,
but as we will show in the next two sections, that is not even necessary. Later, when
we are attacking CryptoMemory in Section 8.5, we do recover the middle part as well.
8.4.2
161
Unrolling the cipher
Whenever the input b is known, given a state s′ it is possible run the cipher backwards
and recover the previous state s. We start by defining an inverse to ⊞ .
Definition 8.4.2. Define ⊟ : Fn2 × Fn2 → Fn2 by
x⊟y = x−y
(mod 2n − 1).
To reconstruct s, we first unshift the cipher, recovering the intermediate state sˆ:
′
ˆ
li := li+1
m
ˆ i :=
i ∈ {0, . . . , 5}
i ∈ {0, . . . , 5}
m′i+1
′
ri+1
rî :=
ˆl6 := L−1 (l′ ⊟ l′ )
0
4
i ∈ {0, . . . , 3}
m
ˆ 6 := L−1 (m′0 ⊟ m′6 )
rˆ4 := r0′ ⊟ r3′ .
There is, however, an issue here that needs special care: the modified modular addition
operator ⊞ is not injective when fixing one argument. When l0′ = l4′ 6= 0 there are
two possible previous left-hand segments, namely, L(l6′ ) could be equal to either 0
or to 31. Therefore, in those cases we have to consider both possible predecessors.
Similarly, splitting might happen in the middle and right-hand segments. This issue
does not significantly hamper the possibility of unrolling the cipher since it only splits
with probability 1/31 for the left-hand and right-hand segments and with probability
1/127 for the middle segment. Also, because the result of ⊞ is never 0 unless both
operands are 0, there are some states that do not have a predecessor. This happens
when l0′ = 0, but l4′ 6= 0.
Next, we simply XOR back the input to recover the previous state:
l2 := ˆ
l2 ⊕ b 3 b 4 b 5 b 6 b 7
m4 := m
ˆ 4 ⊕ b4 b5 b6 b7 b0 b1 b2
r1 := rˆ1 ⊕ b0 b1 b2 b3 b4 .
Also note that when unrolling the cipher, the three segments operate independently.
8.4.3
Recovering the key
In this section we use a meet-in-the-middle technique to recover the secret key. We
recall from Section 8.3.1 that the cipher state s4 , just before feeding in the key k,
is known to an attacker. Observe that the transition function for the right-hand
segment only uses five bits b0 . . . b4 of the input. Therefore, by guessing 20 bits of the
key, it is possible to roll the cipher 6 times (feeding in nr4 and nr5 accordingly) and
162
compute 220 possibilities for the right-hand segment of s6 . Similarly starting at the
end; we have just recovered the right-hand segment for the state at the start of the
generation of the authenticators, i.e., just after feeding in the key. By guessing the
other 20 bits of the key, it is possible to unroll the cipher 6 times (feeding in nr7 and
nr6 accordingly) and obtain another set of 220 candidates for the right-hand segment
of s6 . (Actually, rolling back there are more candidates because of the splitting; in
practice this is at most a ten fold increase.) Intersecting these sets of states, since the
right-hand segment has 25 bits of entropy and we have guessed 40 bits of the input,
we get approximately 215 candidates. In practice, because of the additional splitting
when rolling back, we get between 30 000 and 66 000 candidates for the right-hand
segment of s6 . Note that we do not just get this set of candidates, but for each
candidate we also have the leftmost five bits of every byte of the key. So, in fact, we
get between 30 000 and 66 000 candidates for the leftmost five bits of every byte of
the key.
Similarly for the left-hand segment, the transition function uses only bits b3 . . . b7 .
Just as before, but for each candidate segment l from Section 8.4.1, we guess two
times 20 bits and we meet-in-the-middle at (the left-hand segment of) s6 . In practice,
we get between 1000 and 3000 candidates. Also here, we do not just obtain this set
of candidates, but for each candidate we have the rightmost five bits of every byte of
the key. So we get between 1000 and 3000 candidates for the rightmost five bits of
every byte of the key.
We now combine the first set of left-hand candidates and the second set of righthand candidates. Of course, a left-hand candidate (40 bits of the key) can only be
combined with a right-hand candidate (also 40 bits of the key) if the bits of the
key that they share are equal. These are bits b3 and b4 of every byte; 8 · 2 = 16
bits in total. So, we get between 216 · (30 000/216) · (1000/216) ≈ 450 and 216 ·
(66 000/216) · (3000/216 ) ≈ 3000 candidate keys. Simulating the whole authentication
session, which now also involves running the middle segment, with each of these
candidate keys reveals what the actual key is.
8.4.4
Complexity and time
As a basic unit of time, we take one tick of the SecureMemory cipher. As a reference
note that an authentication attempt takes 88 ticks which means that a naive brute
force attack takes 264 · 88 = 270.5 cipher ticks.
The most time in this attack is spent in recovering the set of 10 to 200 candidates
for the left-hand segment. Here we have to loop over 235 candidates; for each of those
candidates we have to compute a maximum of 64 ticks of the cipher, two for each
of the nibbles of ar and at since SecureMemory skips every second output during
the generation of the authenticators. (Note, we only have to compute the left-hand
segment, so we count this as 13 ). So this gives a complexity of 239 ticks, comparable
to the time it takes to simulate 232.5 authentications. Note that for the right-hand
163
segment we only have to loop over 225 candidates and for the meet-in-the-middle
key-recovery we only have to build tables of size 220 , so we can ignore that. Also note
that when our authentication session does not have the desired property that a single
right-hand segment has the highest score, we only have wasted the 225 loop over the
possible right-hand segments. Since this happens only with probability 1−0.81 = 0.19
we can ignore this time. After on average 1/0.81 ≈ 1.23 traces, we do have a single
candidate for the right-hand segment and with probability 0.71 we recover the key
in 239 ticks. This yields an average complexity of 239 /0.71 = 239.5 ticks, i.e., the
complexity of simulating 233 authentications. On average, this needs 1/0.57 ≈ 1.75
authentication traces. In practice, running this attack on a single core 2 GHz laptop
takes about 10 minutes.
8.5
Attacking CryptoMemory
We now turn our attention to CryptoMemory. We describe an attack in three phases:
recovering the internal state by means of a correlation attack; unrolling the internal
state; and recovering the key by means of a meet-in-the-middle attack. There is,
however, a major complication. Because the output of the cipher is fed back into the
internal state, it is no longer possible to run the three segments independently, at least
not under all circumstances. This seriously complicates the recovery of the internal
state and also makes unrolling the cipher slightly harder. Finally, we propose a tradeoff between the number of authentication traces needed and off-line computation time,
similar to the one proposed by Biryukov et al. in [BMS06].
8.5.1
Recovering the internal state
The starting point for this attack is the same as the one described in Section 8.4.
Although the three segments cannot be run independently as for SecureMemory, because of the feedback from the keystream, it is possible to do so when the keystream
is fully known. Now most of the time, CryptoMemory discards several output nibbles
when generating keystream. When it generates the tag authenticator ar, however,
CryptoMemory does produce 16 consecutive keystream nibbles (namely the last 2 of
at and the 14 of ar that it actually generates). Note, by the way, that SecureMemory
never produces consecutive keystream nibbles, but there that is not needed for the
attack anyway. Let ks ∈ (F42 )16 be those 64 bits of keystream. Knowing that the keystream bits are equal to the output of either the left-hand or the right-hand segment,
we define the following score, similar to the one for SecureMemory, but using only
the 64 bits of ks.
Definition 8.5.1. Consider a guess r for the right-hand segment of the internal state
of the cipher just before producing the last byte of ar (the state s23 in Section 8.3.1)
and consider the 16 output nibbles generated by the right-hand segment that are used
to compute ar14 , ar15 , and at2 to at15 . We define the score of r to be the number
164
of bits that these 16 output nibbles have in common with the actual keystream ks. A
similar definition applies for a guess l of the left-hand segment.
A random segment has an expected score of 32. The correct segment, instead, has
an expected score of 48. Although not nearly as pronounced as for SecureMemory,
this correlation can be exploited to narrow our search space to segments with high
score.
The attack proceeds as follows. An attacker first eavesdrops a number Nt of
authentication traces. For each trace it will iterate over all 235 left-hand segments
and keep only those with score higher than a threshold Nl . Similarly for the righthand segment, it will iterate over all 225 right-hand segments and keep only those
with score higher that a threshold Nr . We call this segments candidate segments,
as these are our guesses for the left-hand and right-hand segments of s23 . Now, for
each (l, r) pair of candidate segments, an adversary could try all 249 middle segments,
unroll the cipher as described in Section 8.5.2 and check if it produces the correct ar
nibbles. It is, however, possible to do better than that; we now describe a directed
search through these middle segments.
Let ksl 0 = outputl(l) and ksr 0 = outputr(r) be the first nibble of output generated
by l and r, respectively. Then, since we know the keystream produced, for those bits
where ksl 0 is different from ksr 0 , we know what the selector bits are, i.e., some bits
of m0 . On average, we know two bits out of four.
More precisely, for all j ∈ {0, 1, 2, 3}
if ksl 0,j ⊕ ksr 0,j = 1, then m0,j := ksl 0,j ⊕ ks0,j .
(8.3)
Next, we compute the successor state. We have only partial information on the
middle segment, viz., only a few bits of m0 . Hence, we only get partial information
on the middle segment of the successor state, viz., a few bits of m′1 . We repeat this
procedure six times, for ksl1 and ksr 1 to ksl6 and ksr 6 , each time obtaining more
partial information about the components of the middle segment. After that there is
no extra information gain as we know a number of bits of each component and they
start falling off on the right.
So far we have consumed seven out of sixteen keystream nibbles. Next we start
searching but keep only those states that are consistent with the remaining keystream.
Precisely, we iterate over all 27 = 128 values for m5 and m6 , but consider only
those that match, respectively, the known bits of m5 and m6 . Then we compute the
successor state. At this point m5 ⊞ L(m6 ) is assigned to m0 , m6 falls out, and m5
shifts to m6 . We now check if the newly computed m0 satisfies the condition
if ksl 7,j ⊕ ksr 7,j = 1, then m0,j = ksl 7,j ⊕ ks7,j
and otherwise discard it.
Now that all bits of m6 are set, we iterate only over all 128 values of m5 . Again,
we compute the successor state and check the corresponding condition. At this point
165
m0 is shifted one position to the right and a new m0 is computed from the sum m5
and m6 , i.e., we have set all bits of m1 , m0 and m6 . We repeat this procedure four
more times, until all seven words of the middle segment are set. This gives us a
number of candidates states that depend on the overlap between ksl and ksr. These
candidate states can be unrolled as we describe in Section 8.5.2 and verified against
the ar nibbles.
8.5.2
Unrolling the cipher
Just as with SecureMemory, it is also possible to unroll the CryptoMemory cipher.
If we are at a state s′ and know the keystream f0 f1 output by the previous state s,
the procedure is merely as described in Section 8.4.2, taking care of setting the input
b to a ⊕ f0 f1 accordingly. If we do not know the keystream f0 f1 , we first have to
reconstruct it. Of course, reconstructing f1 is no problem, as f0′ = f1 . Now, first of
all, we compute sˆ as in Section 8.4.2 (if splitting happens, consider one possibility for
sˆ). Write b = b0 b1 . . . b7 = a ⊕ f0 f1 . By Equations (8.2) and (8.1), we have
(
l1,i+1 ⊕ l5,i+1 if m1,i+3 = 0
f0,i =
r1,i+1 ⊕ r4,i+1 if m1,i+3 = 1
(
ˆl1,i+1 ⊕ ˆ
l5,i+1
if m
ˆ 1,i+3 = 0
=
rˆ1,i+1 ⊕ bi+1 ⊕ rˆ4,i+1 if m
ˆ 1,i+3 = 1.
Now note that b4 = a4 ⊕ f1,0 = a4 ⊕ fˆ1,0 , so we can use the above equation to compute
f0,3 . Now b3 = a3 ⊕ f0,3 , so we can use the above equation again to compute f0,2 .
Doing this twice more, we can also compute f0,1 and f0,0 . Using Equation (8.1), we
can now compute s.
8.5.3
Recovering the key
As before, we use a meet-in-the-middle technique to recover the secret key. This
time the computational complexity of the attack is higher due to the keystream feedback loop, which makes it impossible to treat the left-hand and right-hand segments
separately.
Recall that the cipher state s4 , just before feeding in the key k, is known to an
adversary and assume the adversary also knows the state s8 , e.g., by running the
attack described in Section 8.5.1.
Then, the adversary simply guesses the first 32 bits of k and runs the cipher
forward from s4 , until half way the initialization protocol, i.e., to state s6 . This
produces a set Sf of 232 candidate states for s6 .
Similarly, it guesses the last 32 bits of k and runs the cipher backwards (unrolls)
from s8 . This produces a set Sb of candidate states (around 2 · 232 ; the additional
factor is because of the states with multiple predecessors). Since we are guessing only
166
two times 32 bits and states consist of 117 bits, there is only one element in Sf ∩ Sb ,
namely s6 . The guessed bits that lead to it constitute the actual key k.
8.5.4
Complexity and time
As a baseline let us first establish the complexity of a naive brute force attack, again
taking cipher ticks as a basic unit of time. For each of the 264 possible keys, we
need 125 cipher ticks to simulate an authentication. This adds to a complexity of 271
cipher ticks.
For the first phase of the attack, recovering the internal state, we need to iterate
over all 235 left-hand segments and for each of them we need to compute the score,
which takes 16/3 cipher ticks. This is of complexity 238 ticks and takes about half an
hour on a single core 2 GHz laptop. We also need to do the same for all 225 right-hand
segments, but this can be ignored.
The number of left-right candidates produced depends on the values of Nl and
Nr (defined in Section 8.5.1) and there is a trade-off between the number of traces
required for the attack and its computational complexity. As an example we consider
two reference configurations: C0 := (Nl = 55, Nr = 51) and C1 := (Nl = 56, Nr =
52). Take for example C0 . Our attack from Section 8.5.1 will only be able to recover
the internal state for those traces with left-hand segment score higher than 55 and
right-hand segment score higher than 51. The score of the left-hand and right-hand
segments of the correct state are binomially distributed as Binom(64, 43 ). Hence the
probability that the score of the correct left-hand segment is at least 55 is approximately 0.025 and the probability that the score of the correct right-hand segment
is at least 51 is approximately 0.239. Assuming these scores are independent, the
probability that both scores satisfy the requirement is 0.025 · 0.239 ≈ 0.0060. Experiments show that the distributions of these scores is indeed very close to binomially
distributed, but they are not totally independent. The experimentally observed probability of having both scores meet the requirement is approximately 0.00185. So the
expected number of authentication session needed is 1/0.0018 ≈ 166. The score of a
random left-hand or right-hand segment is also binomially distributed, but with distribution Binom(64, 21 ). The probability of a random segment having a score of 55 or
higher is 0.177 · 10−8 and the probability of a random segment having a score of 51 or
higher is 0.95 · 10−6. So, we expect around 0.177 · 10−8 · 235 ≈ 60.9 left-hand segments
to have a score of 55 or higher and around 0.95 · 10−6 · 225 ≈ 31.6 right-hand segments
to have a score of 51 or higher. So this gives approximately 60.9 · 31.6 ≈ 1920 leftright candidates per trace. We established the number of candidates for the middle
segment per left-right candidate empirically; we get on average 1.43 · 109 candidates
for the middle segment. For each middle segment we need to unroll the cipher at
most 64 times. This gives us a total complexity of 255 cipher ticks, comparable to
simulating 248 authentications. Assuming we dispose of a cluster of 50 2 GHz quad
core computers, all this computation would take about two weeks.
167
Considering C1 , the expected number of traces needed to find one in which the
correct segment has a score of at least 56 and the correct right-hand segment has a
score of at least 52 is 1/0.000378 ≈ 2640 traces. Here we expect only 9.5 · 7.7 ≈ 73
left-right candidates. Experiments show that the number of middle segments per
left-right candidate is approximately 2.12 · 1010 . This gives us a total complexity of
252 cipher ticks, i.e., the computational complexity of 245 authentications. With the
same computational power this would take less than 2 days of computation.
Once we have recovered the internal state, we need to do the meet-in-the-middle
approach described in Section 8.5.3 to recover the key. For each of the 232 guesses,
we need to compute 14 cipher shifts to build the set Sf . Compared to the complexity
above, this is negligible. It does require a storage space of around 16 Gb though.
Using a 2 GHz computer with enough internal memory, it takes about half an hour
to construct and sort this table. Similarly, from the other side we need another 236
cipher ticks to unroll the cipher. Since we only need the intersection of Sf and Sb ,
we do not actually store Sb , but only do a logarithmic search for each element of Sb
in the table for Sf . This whole computation takes another half hour.
8.6
Conclusion
In this chapter we have described the ciphers used in the product families SecureMemory, CryptoMemory, and CryptoRF. We have shown weaknesses of these ciphers, most
notably the fact that the three components of the cipher operate independently (knowing the keystream, in the case of CryptoMemory and CryptoRF) and that there is a
strong correlation between the intermediate output of two of those components and
the generated keystream. We have shown that an attacker can use these weaknesses
and eavesdropped sessions to recover the secret key. For SecureMemory, the attack
has a time complexity of 239 cipher ticks; in practice it takes around 10 minutes on a
single core 2 GHz laptop. For CryptoMemory and CryptoRF, the attack has a time
complexity of 252 cipher ticks; on a cluster of 50 2 GHz quad core machines, it takes
about 5 days to execute the attack. We have implemented the full functionality of
the chips in software. We have also implemented the full attacks and tested this on
genuine traces.
Chapter 9
iClass and iClass Elite
With more than 300 million cards sold, HID iClass is one of the most popular contactless smart cards on the market. It is widely used for access control, secure login and
payment systems. The card uses 64-bit keys to provide authenticity and data integrity. The cipher and key diversification algorithms used in iClass are proprietary
and little information about them is publicly available. In this chapter we have reverse engineered all security mechanisms in the card including cipher, authentication
protocol and also key diversification algorithms, which we publish in full detail. Furthermore, we have found six critical weaknesses that we exploit in two attacks, one
against iClass Standard and one against iClass Elite (a.k.a., iClass High Security). In
order to recover a secret card key, the first attack requires one authentication attempt
with a legitimate reader and 222 queries to a card. This attack has a computational
complexity of 240 MAC computations. The whole attack can be executed within
a day on a single core running at 2 GHz. Remarkably, the second attack which is
against iClass Elite is significantly faster. It directly recovers the system wide master
key from only 15 authentication attempts with a legitimate reader. The computational complexity of this attack is lower than 225 MAC computations, which means
that it can be fully executed within 5 seconds on an ordinary laptop.
9.1
Introduction
iClass is an ISO/IEC 15693 [ISO00] compatible contactless smart card manufactured
by HID Global. It was introduced in the market back in 2002 as a secure replacement of the HID Prox card which did not have any cryptographic capabilities. The
iClass cards are widely used in access control of secured buildings such as The Bank
of America Merrill Lynch, the International Airport of Mexico City and the United
States Navy base of Pearl Harbor [Cum06] among many others1 . Other applications
include secure user authentication such as in the naviGO system included in Dell’s
Latitude and Precision laptops; e-payment like in the FreedomPay and SmartCentric systems; and billing of electric vehicle charging such as in the Liberty PlugIns
system. iClass has also been incorporated into the new BlackBerry phones which
support Near Field Communication (NFC). iClass uses a proprietary cipher to provide data integrity and mutual authentication between card and reader. The cipher
1 http://hidglobal.com/mediacenter.php?cat2=2
170
uses a 64-bit diversified key which is derived from a 56-bit master key and the serial
number of the card. This key diversification algorithm is built into all iClass readers.
The technology used in the card is covered by US Patent 6058481 and EP 0890157.
The precise description of both the cipher and the key diversification algorithms are
kept secret by the manufacturer following the principles of security by obscurity. HID
distinguishes two system configurations for iClass, namely iClass Standard and iClass
Elite. The main differences between iClass Standard and iClass Elite lies in their
key management and key diversification algorithms. Remarkably, all iClass Standard
cards worldwide share the same master key used for Authentication and Key Agreement (AKA). This master key is stored unprotected in the EEPROM memory of
every iClass Standard reader. In iClass Elite, however, it is possible to let HID generate and manage a custom key for your system if you are willing to pay a higher price.
The iClass Elite Program (a.k.a., High Security) uses an additional key diversification
algorithm (on top of the iClass Standard key diversification) and a custom master key
per system which according to HID provides “the highest level of security”[HID09].
9.2
Research context and related work
Over the last few years, much attention has been paid to the (in)security of the
cryptographic mechanisms used in contactless smart cards [GdKGM+ 08, GvRVWS10,
PN12, VGB12]. Experience has shown that the secrecy of proprietary ciphers does
not contribute to their cryptographic strength, see Chapter 4. HID proposes iClass
as a migration option for systems using Mifare Classic, boosting that iClass provides
“improved security, performance and data integrity”2. The details of the security
mechanisms of iClass remained secret for almost one decade.
During the course of our research Kim, Jung, Lee, Jung and Han have published
a technical report [KJL+ 13] describing an independent reverse engineering approach
of the cipher used in iClass. Their research takes a very different, hardware oriented
approach. They recovered most of the cipher by slicing the chip and analyzing the circuits with a microscope. Our approach, however, is radically different as our reverse
engineering is based on the disassembly of the reader’s firmware and the study of
the communication behavior of tags and readers. Furthermore, the description of the
cipher by Kim et al. contains a major flaw. Concretely, their key byte selection function in the cipher is different from the one used in iClass which results in incompatible
keys. Kim et al. have proposed two key recovery attacks. The first one is theoretical,
in the sense that it assumes that an adversary has access to a MAC oracle over messages of arbitrary length. This assumption is unrealistic since neither the card nor
the reader provide access to such a powerful oracle. Their second attack requires full
control over a legitimate reader in order to issue arbitrary commands. Besides this
assumption, it requires 242 online authentication queries which, in practice, would
take more than 710 years to gather. Our attacks, however, are practical in the sense
2 http://www.hidglobal.com/products/readers/iclass/high-frequency-migration-readers
171
that they can be executed within a day and require only wireless communication with
a genuine iClass card/reader.
9.2.1
Research contribution
The contribution of this chapter consists of several parts. First it describes the reverse
engineering of the built-in key diversification algorithm of iClass Standard. The basic
diversification algorithm, which also forms the basis for iClass Elite key diversification,
consists of two parts: a cipher that is used to encrypt the identity of the card; and
a key fortification function, called hash0 in HID documentation, which is intended to
add extra protection to the master key.
We show that the key fortification function hash0 is actually not one-way nor collision resistant and therefore it adds little protection to the master key. To demonstrate
this, we give the inverse function hash0−1 that on input of a 64 bit bitstring outputs a
modest amount (on average 4) of candidate pre-images. This results in our first attack
on the iClass Standard key diversification that recovers a master key from an iClass
reader which is of comparable complexity to that of breaking single DES. It only
uses weaknesses in the key diversification algorithm. Since in the end it comes down
to breaking DES, it can be accomplished within a few days on a COPACOBANA
(a generic massively parallel FPGA-computer [KPP+ 06]). This is extremely sensitive
since there is only one master key for all iClass Standard readers and from this master
key all diversified card keys can be computed. As a faster alternative, it is possible
to emulate a predefined card identity and use it to build a pre-computed table of
ciphertexts for this particular identity using a Time-Memory Trade-Off (TMTO), see
Chapter 3.2. This allows an adversary to recover the master key even within minutes.
Furthermore, we have fully reverse engineered iClass’s proprietary cipher and authentication protocol. This task of reverse engineering is not trivial since it was first
necessary to bypass the read protection mechanisms of the microcontroller used in
the readers in order to retrieve its firmware [GdKGVM12]. This process is explained
later in Section 9.5. We also found serious vulnerabilities in the cipher that enable
an adversary to recover the secret card key by just wirelessly communicating with
the card. The potential impact of this second and improved attack against iClass
Standard is vast since when it is combined with the vulnerabilities in the key diversification algorithm, which we exploited earlier, it allows an adversary to use this secret
key to recover the master key. Additionally, we have reverse engineered the iClass
Elite key diversification algorithm which we also describe in full detail. We show that
this algorithm has even more serious vulnerabilities than the iClass Standard key diversification. In our third and last attack, an adversary is able to directly recover an
“Elite” master key by simply communicating with a legitimate iClass reader.
Concretely, we propose three key recovery attacks: one on the iClass Standard key
diversification, one against iClass Standard and one against iClass Elite. All attacks
allow an adversary to recover the master key.
172
• The first attack, against iClass Standard key diversification, exploits the fact
that the key diversification algorithm can be inverted. An adversary needs to let
the genuine reader issue a key update command. The card key will be updated
and from the eavesdropped communication the adversary learns the card key.
The adversary proceeds by inverting the key diversification which results in a
modest amount of pre-images. Now, only a brute-force attack on single DES
will reveal which master key was used.
• The second attack, against iClass Standard, exploits a total of four weaknesses
in the cipher, key diversification algorithm and card implementation. In order
to execute this attack the adversary first needs to eavesdrop one legitimate authentication session between the card and reader. Then it runs 219 key updates
and 222 authentication attempts with the card. This takes less than six hours
to accomplish (when using a Proxmark as a reader) and recovers 24 bits of the
card key. Finally, off-line, the adversary needs to search for the remaining 40
bits of the key. Having recovered the card key, the adversary gains full control
over the card. Furthermore, computing the master key from the card key is as
hard as breaking single DES and is done like in the first attack.
• The third attack, concerning iClass Elite, exploits two weaknesses in the key
diversification algorithm and recovers the master key directly. In order to run
this attack the adversary only needs to run 15 authentication attempts with a
legitimate reader. Afterwards, off-line, the adversary needs to compute only 225
DES encryptions in order to recover the master key. This attack, from beginning
to end runs within 5 seconds on ordinary hardware.
We have executed all attacks in practice and verified these claims and attack times.
These results previously appeared in abbreviated form as [GdKGV11, GdKGVM12].
9.2.2
Outline
This chapter is organized as follows. Section 9.3 starts with a description of the
iClass architecture, the functionality of the card, the cryptographic algorithms. Then,
Section 9.4 describes the reverse engineering of the key diversification scheme that is
used in iClass Standard. Here, we also give an attack against this iClass Standard
key diversification that recovers the master key from a diversified key. This attack
method forms the basis for the second attack against iClass Standard where it is used
to recover the master key in its last step. The second attack itself is described in
Section 9.6 after the reverse engineering and description of the cipher in Section 9.5.
Finally, Section 9.7 describes the key diversification in iClass Elite and presents an
attack against this scheme.
9.3
173
iClass
An HID iClass card is in fact a pre-configured and re-branded PicoPass card manufactured by Inside Secure3 . HID configures and locks the cards so that the configuration
settings can no longer be modified. This section describes in detail the functionality and security mechanisms of iClass and it also describes the reverse engineering
process.
Table 9.1: Memory layout of an iClass card
Block
0
1
2
3
4
5
6. . . 18
19. . . n
Content
Card serial number
Configuration
e-Purse
Key for application 1
Key for application 2
Application issuer area
Application 1
Application 2
Description
Identifier id
Card challenge cC
Diversified debit key k1
Diversified credit key k2
HID application
User defined memory
publicly readable
write-only after authentication
read-write after authentication
9.3.1
Functionality
iClass cards come in two versions called 2KS and 16KS with respectively 256 and
4096 bytes of memory. The memory of the card is divided into blocks of eight bytes
as shown in Table 9.1. Memory blocks 0, 1, 2 and 5 are publicly readable. They
contain the card identifier id, configuration bits, the card challenge cC and issuer
information. Block 3 and 4 contain two diversified cryptographic keys k1 and k2
which are derived from two different master keys K1 and K2. These master keys are
referred to in the documentation as debit key and credit key. The card only stores
the diversified keys k1 and k2. The remaining memory blocks are divided into two
areas, which are represented by the host software as applications. The size of these
applications is defined by the configuration block.
The first application of an iClass card is the HID application which stores the card
identifier, PIN code, password and other information used in access control systems.
Read and write access to the HID application requires a valid mutual authentication
using the cipher to prove knowledge of k1. The master key of the HID application
is a global key K1 known to all iClass Standard compatible readers. The globally
used key K1 is kept secret by HID Global and is not shared with any customer or
3 http://www.insidesecure.com/eng/Products/Secure-Solutions/PicoPass
174
industrial partner. Recovery of this key undermines the security of all systems using
iClass Standard. Two methods have been proposed [Mer10, GdKGV11] to recover
this key. To circumvent the obvious limitations of having only a global master key,
iClass Elite uses a different key diversification algorithm that allows having custom
master keys. The details regarding iClass Elite can be found in Section 9.7.1. The
second global master key K2 is used in both iClass Standard and Elite systems and it
is available to any developer who signs a non-disclosure agreement with HID global.
It is possible to extract this key from publicly available software binaries [GdKGV11].
In addition, the document [HID06] contains this master key and is available online.
This key K2 can be used by developers to protect the second application, although
in practice, K2 is hardly ever used or modified.
The card provides basic memory operations like read and write. These operations
have some non-standard behavior and therefore we describe them in detail.
• The read command takes as input an application number a and a memory block
number n and returns the memory content of this block. This command has
the side effect of selecting the corresponding key (k1 for application 1 or k2 for
application 2) in the cipher and then it feeds the content of block n into the
internal state of the cipher. Cryptographic keys are not readable. When the
block number n corresponds to the address where a cryptographic key is stored,
then read returns a bitstring of 64 ones.
• The write command takes as input a block number n, an eight-byte payload
p and a MAC of the payload MAC(k, n · p), where k is a diversified card key.
When successful, it writes p in memory and it returns a copy of p for verification
purposes. This command has the side effect of resetting the internal state of
the cipher. In addition, when the block number n corresponds to the address
where a cryptographic key k is stored, the payload is XOR-ed to the previous
value instead of overwriting it, i.e., it assigns k ← k ⊕ p.
Therefore, in order to update a key k to k ′ , the reader must issue a write command
with k ⊕ k ′ as payload. In this way the card will store k ⊕ k ⊕ k ′ = k ′ as the new
key. On the one hand, this particular key update procedure has the special feature
that in case an adversary eavesdrops a key update he is unable to learn the newly
assigned key, provided that he does not know k. On the other hand this introduces a
new weakness which we describe in Section 9.6.2.
Before being able to execute read or write commands on the protected memory
of a card, the reader needs to get access to the corresponding application by running
a successful authentication protocol described in Section 9.3.2. Cryptographic keys
k1 and k2 can be seen as part of application 1 and 2, respectively. This means that in
order to modify a key e.g., k1, the reader first needs to run a successful authentication
with k1.
175
Table 9.2: Authenticate and decrement card challenge cC using
k1 = 0xE033CA419AEE43F9
Sender
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
Reader
Tag
9.3.2
0C
47
0C
12
88
FE
05
5A
87
CF
FF
00
47
01
FF
02
FF
00
A2
02
3B
FF
73
6C
FA
FF
Hex
33
00 F7 FF 12 E0
22
FF E9 1F FF 3C
FF
00
AF
FD
D4
FF
FF
00
92
FF
6A
FF
FF FF FF FF
00 1D 49 C9 DA
FF FF FF FF FF FF
FD FF FF FF
Abstract
Read identifier
Card serial number id
Read configuration
iClass 16KS configuration
Read cC and select k1
Card challenge cC
Reader nonce nR = 0, MAC(k1, cC · nR )
Response MAC(k1, cC · nR · 032 )
Write on block 02 followed by
MAC(k1, 02 · cC − 1)
Update successful
This section describes the authentication protocol between an iClass card and reader.
This protocol is depicted in Figure 9.1 and an example trace is shown in Table 9.2.
First, during the anti-collision protocol, the reader learns the identity of the card
id. Then, the reader chooses an application and issues a read command on the card
challenge cC .
This cC is called ‘e-purse’ in the iClass documentation [IC04] and it is a special
memory block in the sense that it is intended to provide freshness. In the next step,
the reader issues an authenticate command. This command sends to the card a
reader nonce nR and a MAC of the card challenge cC concatenated with nR . This
MAC is computed using a diversified card key k. Finally, the card answers with a
MAC of cC , nR followed by 32 zero bits. For more details over the MAC function
see Section 9.5.2.
After a successful authentication on cC the reader is granted read and write access
within the selected application.
Remark 9.1. Since the card lacks a pseudo-random number generator, the reader
should decrement cC after a successful authentication in order to provide freshness
for the next authentication, see Table 9.2. This is not enforced by the card. Note that
cC is treated differently in the sense that when the tag stores cC it swaps the first and
last 32 bits (for reasons that are unknown to us). Therefore 0xFDFFFFFFFFFFFFFF is
stored by the tag as 0xFFFFFFFFFDFFFFFF as shown in Table 9.2.
176
9.4
iClass standard
In this chapter we first reverse engineer the iClass Standard key diversification. Then,
we describe its weaknesses in Section 9.4.3. Finally, we describe the first attack against
iClass Standard in Section 9.4.4.
Our first approach for reverse engineering is in line with that of [GdKGM+ 08,
LST+ 09, GvRVWS10] and consists of analyzing the update card key messages sent
by an iClass compatible reader while we apply small modifications to the key, just after the DES operation and just before it is passed to the fortification function hash0 .
We used an Omnikey reader that supports iClass. Still, we first had to bypass the encryption layer of the Omnikey Secure Mode that is used in its USB communication in
order to control the reader messages [GdKGV11]. We reverse engineered the Omnikey
Secure Mode and wrote a library that is capable of communicating in Omnikey Secure
Mode to any Omnikey reader. To eavesdrop the contactless interface we have built
a custom firmware for the Proxmark in order to intercept ISO/IEC 15693 [ISO00]
frames. We have released the library, firmware and an implementation of hash0 under the GNU General Public License and they are available at http://www.proxmark.
org.
Reader
Card
id, cC
nR , MAC(k, cC · nR)
MAC(k, cC · nR · 032)
Figure 9.1: Authentication protocol
Later in Section 9.5, we use a different approach for reverse engineering the cipher
and the key diversification for iClass Elite. In this approach we first recover the
firmware from an iClass reader. Then, by disassembling the firmware we are able to
recover the cipher and key diversification for iClass Elite. The knowledge about the
structure of hash0 which we describe in this section did help a lot in identifying the
interesting parts of the firmware for reverse engineering.
9.4.1
Black box reverse engineering
This section describes how hash0 [Cum06] (a.k.a. h0 [Cum03]) was reverse engineered.
The final description of hash0 is given in Section 9.4.2. The method used to reverse
engineer hash0 studies the input-output relations of hash0 in order to recover its
internal structure. The primary goal is to learn how a card key k is derived from a
master key K and the card identity id. The general structure of the key derivation
is known. First, the iClass reader encrypts a card identity id with the master key K,
177
using single DES. The resulting ciphertext is then input to hash0 which outputs the
diversified key k.
k = hash0(DESenc(K, id)) .
We define the function flip that takes an input c and flips a specific bit in c. By
flipping a bit we mean taking the complement of this bit. The definition flip is as
follows.
64
Definition 9.4.1. Let the function flip : F64
2 × N → F2 be defined as
flip(c, m) = c63 . . . cm+1 · cm · cm−1 . . . c0
Since we only learn the XOR difference between two hash0 outputs we define the function diff that we use to express these XOR differences. The function diff computes
the output difference of two hash0 calls and is defined as follows.
64
Definition 9.4.2. Let the function diff : F64
2 × N → F2 be defined as
diff(c, m) = hash0(c) ⊕ hash0(flip(c, m))
Now we use this definition of output difference to describe accumulative output differences of an input set C.
_
^
k ∨m =
diff(c, m),
k ∧m =
diff(c, m)
c∈C
c∈C
The results are grouped by the position of the flipped bit m. Then, the OR and AND
is computed of all the results in a group. These cumulative OR and AND values
for 64 bits that were flipped on a few thousand random 64-bit bitstrings c ∈ C are
presented in Figure 9.3 and 9.4. The output difference for flipping all possible bits is
abbreviated as follows.
k∨ =
63
^
m=0
k ∨m ,
k∧ =
63
^
k ∧m
m=0
Gathering input-output pairs
In this section we explain how we gather the input-output pairs for hash0 and calculate
the output differences. In our setup we have complete control over an iClass reader
for which we can set and update the keys that are used. Furthermore, we are able to
emulate iClass cards and learn all communication between the controlled reader and
(emulated) iClass card. First, we analyze the input-output relations of hash0 at bit
level. This requires complete control over the input c of hash0 which can be achieved
in our test setup. In this test setup we emulate a card identity id and also know,
or can even change which master key K is used. The following steps deliver XOR
differences between two hash0 evaluations that differ only one bit in the input:
178
• generate a large set of random bitstrings c ∈ F64
2 .
• for each c
– calculate id = DESdec (c, K) and
idm = DESdec (flip(c, m), K) for m = 0 . . . 63
– for each m authenticate with id, perform a key update, the reader requests
the card identity again, now use idm instead of id
Keep the master key K constant during the key updates described above. This delivers the XOR of two function evaluations of the form diff(c, m) = hash0(c) ⊕
hash0(flip(c, m)). We performed this procedure for 3000 random values c ∈ C. Experiments show that for this particular function, having more than 3000 samples does
not produce any difference on the cumulative OR and AND tables. This amount of
samples can be obtained within a couple of days.
Function input partitioning
Figure 9.3 shows the accumulated differences for the 48 rightmost output bits at
input c. The results for the remaining 16 leftmost output bits are shown in Figure 9.4.
These differences reveal that the input c of hash0 is of the form c = x · y · z[7] . . . z[0]
with x, y ∈ F82 and z[i] ∈ F62 . The eight output bytes are defined as k[0] . . . k[7] and
constitute the diversified key k. We noticed that the first 16 bits of the input exhibit
a different behavior that the rest and therefore decided to split the input into two
parts. The structure of the mask in Figure 9.3 is computed with x = y = 08 and z a
random bitstring. Whereas in Figure 9.4 we flip only bits of x and y. This leads to
the following observations:
• z[0] . . . z[3] affects k[0] . . . k[3] and z[4] . . . z[7] affects k[4] . . . k[7] .
• z[0] . . . z[3] and z[4] . . . z[7] generate a similar structure in the output but are
mutually independent. This suggests the use of a subfunction that is called
twice, once with input z[0] . . . z[3] and once with input z[4] . . . z[7] . We call this
function check.
• y7−i affects k[i] for i = 0 . . . 7. The OR-mask for y indicates a complement
operation on the output while the AND-mask in Figure 9.4 shows that k[i]0 is
exclusively affected by y for i = 0 . . . 7.
• x defines a permutation. The output is scrambled after flipping a single bit
within x. The AND-mask in Figure 9.4 shows that k[i]7 is exclusively affected
by x for i = 0 . . . 7.
• flipping bits in z never affects k[i]0 or k[i]7 . This is inferred from the occurrences
of 0x7e (01111110 in binary representation) in Figure 9.3.
y
z [7]
z [6]
z [5]
z [4]
z [3]
z [2]
z [1]
z [0]
{
{
{
{
{
{
{
{
x
179
k[0]
k[1]
k[2]
k[3]
k[4]
k[5]
k[6]
k[7]
Figure 9.2: Schematic representation of the function hash0
The above observations suggest that we can recover different parts of the function
independently. Figure 9.2 summarizes how different parts of the input affect specific
parts of the output. Note that from the last observation we know that the subfunction
check operates on z[i]0 . . . z[i]5 and affects k[i]1 . . . k[i]6 . Furthermore, it is observed that
the leftmost bit of all output bytes k[i]7 and the permutation of z[i] to k[i]1 . . . k[i]6 is
determined by x. Finally, every input bit y7−i is copied to output bit k[i]0 .
Summarizing, hash0 can be split into three different parts. The first part is the
subfunction check which applies a similar operation on z[0] . . . z[3] and z[4] . . . z[7] . In
the second part a bitwise complement operation is computed based on bits from the
input byte y. The last part applies a permutation that is defined by the input byte
x. The following sections discuss the reverse engineering of these identified parts of
hash0. Finally, the complete hash0 definition is given in Section 9.7.
Subfunction check
This section describes the reverse engineering of the subfunction check which operates
on two times four 6-bit input values z[0] . . . z[3] and z[4] . . . z[7] . In order to recover this
part of the function we keep x = y = 08 and let z vary over random bitstrings.
According to Figure 9.3 only flipping bits in z (positions 16 to 63 of input c) does
matter for check. We write modified(x) to indicate changes in x between two different
test cases. We make modifications to the input and see where it affects the output.
We start by looking at the following rules that are deduced from Figure 9.3.
modified(k[0] ) →
modified(k[4] ) →
modified(z[7] ) ∧ ¬modified(z[0] . . . z[6] )
modified(z[3] ) ∧ ¬modified(z[0] . . . z[2] )
∧¬modified(z[4] . . . z[7] )
Note that k[4]1 . . . k[4]6 = z[3] . For k[0] it is harder to find a function since flipping a
single bit in z[7] may affect multiple bits in k[0] . The relation between z[7] and k[0]
becomes more clear when we look at specific input patterns and their corresponding
output difference in Table 9.3. The stars in the input pattern for z[7] denote a bit
that can be either 0 or 1 without affecting the output difference of k[0] . Note that, of
180
z[0]
z[1]
z[2]
z[3]
z[4]
z[5]
z[6]
z[7]
















































bit
OR-mask of
AND-mask of
↓ differences in output k differences in output k
63 0x7e7e7e7e00000000 0x0400000000000000
62 0x7e7e7e7e00000000 0x0400000000000000
61 0x7a7e7e7e00000000 0x0800000000000000
60 0x727e7e7e00000000 0x1000000000000000
59 0x627e7e7e00000000 0x2000000000000000
58 0x427e7e7e00000000 0x4000000000000000
57 0x007e7e7e00000000 0x0000000000000000
...
...
52 0x007e7e7e00000000 0x0000000000000000
51 0x00007e7e00000000 0x0000000000000000
...
...
46 0x00007e7e00000000 0x0000000000000000
45 0x0000007e00000000 0x0000000000000000
...
...
40 0x0000007e00000000 0x0000000000000000
39 0x00000000027e7e7e 0x0000000002000000
38 0x00000000047e7e7e 0x0000000004000000
37 0x00000000087e7e7e 0x0000000008000000
36 0x00000000107e7e7e 0x0000000010000000
35 0x00000000207e7e7e 0x0000000020000000
34 0x00000000407e7e7e 0x0000000040000000
33 0x00000000007e7e7e 0x0000000000000000
...
...
28 0x00000000007e7e7e 0x0000000000000000
27 0x0000000000007e7e 0x0000000000000000
...
...
22 0x0000000000007e7e 0x0000000000000000
21 0x000000000000007e 0x0000000000000000
...
...
16 0x000000000000007e 0x0000000000000000
Figure 9.3: or and and-mask for flipping bits 16 . . . 63 of c
course, the input bit that is being flipped can also be either 0 or 1 and is therefore also
denoted by a star. We try to capture the output differences for flipping all possible
bits between two different inputs c. We write z7 when the bit flip is set to zero and
z˘7 when is set to one.
∨
The difference k[0]
based on flipping bits in z[7] is:
∨
∨
= (z7 mod 63) + 1 ⊕ (˘
z7 mod 63) + 1 ,
. . . k[0]
k[0]
6
1
from which we deduce that
k[0]1 . . . k[0]6 = (z7 mod 63) + 1 .
(9.1)
The remaining k[1]1 . . . k[1]6 , k[2]1 . . . k[2]6 and k[3]1 . . . k[3]6 can be found in a similar
y
x














































bit
↓
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
181
OR-mask of
differences in output k
0xfc00000000000000
0x00fc000000000000
0x0000fc0000000000
0x000000fc00000000
0x00000000fe000000
0x0000000000fe0000
0x000000000000fe00
0x00000000000000fe
0x7f7f7f7e7e7f7f7f
0x00007f7e7f000000
0x7f7e7e7e7f000000
0x7f7e7e7e7e7f0000
0x00007f7e7e7e7f00
0x7f7e7f7f7f7f7f00
0x7f7e7f7e7e7f7f00
0x7f7e7f7e7f7e7f00
AND-mask of
differences in output k
0x8000000000000000
0x0080000000000000
0x0000800000000000
0x0000008000000000
0x00000000fe000000
0x0000000000fe0000
0x000000000000fe00
0x00000000000000fe
0x0101010000010101
0x0000010001000000
0x0100000001000000
0x0100000000010000
0x0000010000000100
0x0100010101010100
0x0100010000010100
0x0100010001000100
Figure 9.4: or and and-mask for flipping bits 0 . . . 15 of c
Table 9.3: Input-output relations for z[7] ↔ k[0]
z[7] of c
****0*
***01*
**011*
*0111*
11111*
01111*
diff(c, 63)[0]
06
0e
1e
3e
7c
7e
z[7] of c
*****0
***0*1
**01*1
*011*1
0111*1
1111*1
diff(c, 62)[0]
04
0c
1c
3c
7c
7e
way by flipping bits in the input and closely looking at the input-output relations.
For more details on the reverse engineering of this function see [GdKGV11]. The
complete definition of the function is given in Section 9.4.2. Eventually, the modulo
operations are separated from the subfunction check and defined in the main function
hash0 . Also, the definition in Section 9.4.2 clarifies why the subfunction is called
check. It checks equalities between the different components of z and affects the
output accordingly.
Complement byte
The second byte of the input c is the complement byte y. It performs a complement
operation on the output of the function as Figure 9.4 clearly shows. Flipping bit
y7−i results in the complement of k[i]0 in the output, for i = 0 . . . 7. Note that no
other input bit influences any least significant output bit of the output bytes k[i]0 .
182
Furthermore, k[i]1 . . . k[i]6 are flipped, however, keep in mind that we do not involve
the action of byte x at this point, which prevents any permutation of the output.
Finally, every k[i]7 is not affected. It is important to observe that for k[4] . . . k[7] the
OR and AND-mask agree that the left 7 bits are always flipped while for k[0] . . . k[3]
this is not true. To be precise, the bits k[i]6 for i = 0 . . . 3 are never flipped. We found
that the output value z[j] that constitutes output byte k[i] is decremented by one if
j ≤ 3 except when y7−i = 0.
Permute byte
Finally, the byte x defines a permutation. Iterating over x while y and z[0] . . . z[7]
are constants shows that x is taken modulo 70. This follows from the fact that
the output values repeat every 70 inputs. The cumulative bitmasks of the output
differences, shown in Figure 9.4, do not provide information about the permutation
but do show that k[i]7 is affected. Experiments show that x is an injective mapping
on k[i]7 for i = 0 . . . 7. This means that it is possible to learn x by looking at the least
significant output bits k[i]7 .
Furthermore, we conclude that the permutation is independent of y and z. This
means that a permutation function permute can be constructed which takes x mod 70
as input and returns a particular mapping. We could recover this permutation because
the values for k[i]7 , for i = 0 . . . 7, directly relate to a unique mapping of the z input.
The hash0 function can be split up into check and permute subfunctions and is defined
in Section 9.4.2.
9.4.2
The function hash0
The following sequence of definitions precisely describe the recovered function hash0.
The details of this construction are not necessary to understand the attacks presented
in Section 9.6.5 and Section 9.7.3.
The function hash0 first computes x′ = x mod 70 which results in 70 possible
permutations. Then for all zi the modulus and additions are computed before calling
the subfunction check.
Then, the subfunction check is called twice, first on input z0′ , . . . , z3′ and then on
input z4′ , . . . , z7′ . The definition of the function check is as follows.
Definition 9.4.3. Let the function check : (F62 )8 → (F62 )8 be defined as
check(z[0] . . . z[7] ) = ck(3, 2, z[0] . . . z[3] ) · ck(3, 2, z[4] . . . z[7] )
183
where ck : N × N × (F62 )4 → (F62 )4 is defined as
ck(1, −1, z[0] . . . z[3] ) = z[0] . . . z[3]
ck(i, −1, z[0] . . . z[3] ) = ck(i − 1, i − 2, z[0] . . . z[3] )
ck(i, j, z[0] . . . z[3] ) =
ck(i, j − 1, z[0] . . . z[i] ← j . . . z[3] ), if z[i] = z[j] ;
ck(i, j − 1, z[0] . . . z[3] ),
otherwise.
Definition 9.4.4. Define the function permute : Fn2 × (F62 )8 × N × N → (F62 )8 as
permute(ǫ, z, l, r) = ǫ
permute(p0 . . . pn , z, l, r) =
(z[l] + 1) · permute(p0 . . . pn−1 , z, l + 1, r), if pn = 1;
z[r] · permute(p0 . . . pn−1 , z, l, r + 1),
otherwise.
Definition 9.4.5. Define the bitstring π ∈ (F82 )35 in hexadecimal notation as
π = 0x0F171B1D1E272B2D2E333539363A3C474B
4D4E535556595A5C636566696A6C71727478
Each byte in this sequence is a permutation of the bitstring 00001111. Note that this
list contains only the half of all possible permutations. The other half can be computed
by taking the bit complement of each element in the list.
Finally, the definition of hash0 is as follows.
Definition 9.4.6. Let the function hash0 : F82 × F82 × (F62 )8 → (F82 )8 be defined as
hash0(x, y, z[0] . . . z[7] ) = k[0] . . . k[7] where
′
= (z[i] mod (63 − i)) + i
z[i]
′
z[i+4]
i = 0...3
= (z[i+4] mod (64 − i)) + i
zˆ = check(z ′ )
π[x mod 35] ,
p=
π[x mod 35] ,
i = 0...3
if x7 = 1;
otherwise.
z˜ = permute(p, zˆ, 0, 4)
y(7−i) · z˜[i] · p(7−i) + 1,
k[i] =
y(7−i) · z˜[i] · p(7−i) ,
if y(7−i) = 1;
otherwise.
i = 0...7
This concludes the reverse engineering of the key diversification algorithm that is used
in iClass Standard and defined as
k = hash0(DESenc (K, id)) .
184
9.4.3
Weaknesses in iClass Standard key diversification
This section describes weaknesses in the design of the Omnikey Secure Mode and on
the iClass built-in key diversification and fortification algorithms. These weaknesses
will be later exploited in Section 9.4.4.
Omnikey Secure Mode
Even though encrypting the communication over USB is in principle a good practice,
the way it is implemented in the Omnikey Secure Mode adds little security. The
shared key kCUW that is used for this practice is the same for all Omnikey readers.
This key is included in software that is publicly available online, which only gives a
false feeling of security.
Weak key fortification
This section clarifies why hash0 is not strengthening the diversified key kid at all.
The entropy of the master key K1 is 56 bits. However, the diversified key kid is a
DES encryption of the identifiers id, which is a bijective mapping with an entropy of
64 bits. Contrarily, the function hash0(kid ) is not bijective, since it can produce the
same output (collisions) for a different input values of kid .
The modulo operations on x ( 256
70 ) and z[0] , . . . , z[7] are responsible for collisions in
the output. The modulo operation on x has the most influence to create a collision.
Without looking at z, the operation on x already shows that the average number of
pre-images is at least
256
≈ 3.66
70
Furthermore, the function hash0 is not an One-Way Function (OWF), since it
is possible to invert its operations. There are multiple pre-images because of the
mentioned modulo operations, but inverting them is straightforward, see Section 9.4.3
for more details.
Inverting hash0
It is relatively easy to compute the inverse of the function hash0. Let us first compute
the inverse of the function check. Observe that the function check−1 is defined just
as check except for one case where the condition and assignment are swapped, see
Definition 9.4.7.
Definition 9.4.7. Let the inverted function check−1 : (F62 )8 → (F62 )8 be defined as
check(z[0] . . . z[7] ) in Definition 9.4.3 except for the following case where
−1
ck (i, j − 1, z[0] . . . z[i] ← z[j] . . . z[3] ), if z[i] = j;
ck−1 (i, j, z[0] . . . z[3] ) =
ck−1 (i, j − 1, z[0] . . . z[3] ),
otherwise.
185
Definition 9.4.8. Define the function permute−1 : Fn2 × (F62 )8 × N × N → (F62 )8 as
permute−1 (p, z, l = 12, r) = ǫ
(z[r] − 1) · permute−1 (p, z, l + 1, r + 1), if pr = 1;
permute−1 (p, z, l < 4, r) =
permute−1 (p, z, l, r + 1),
otherwise.
z[l−4] · permute−1 (p, z, l + 1, r), if pl−4 = 0;
permute−1 (p, z, l ≥ 4, r) =
permute−1 (p, z, l + 1, r),
otherwise.
Next, we define the function hash0−1 , the inverse of hash0 . This function outputs a
set C of candidate pre-images. These pre-images output the same key k when applying
hash0. The definition of hash0−1 is as follows.
Definition 9.4.9. Let the function hash0−1 : (F82 )8 → {F82 × F82 × (F62 )8 } be defined
as
hash0−1 (k[0] . . . k[7] ) = C
where
C=
{x|x = x′ mod 70}
{z7 |z7 = z˙7 mod 61}
{z5 |z5 = z˙5 mod 63}
{z3 |z3 = z˙3 mod 60}
{z1 |z1 = z˙1 mod 62}
x′ is unique elem. in F82 s.t.
×
×
×
×
×
{y}
{z6 |z6
{z4 |z4
{z2 |z2
{z0 |z0
= z˙6
= z˙4
= z˙2
= z˙0
mod
mod
mod
mod
×
62} ×
64} ×
61} ×
63}
p = π[x′ mod 35] ⇔ x′7 = 1
p = π[x′ mod 35] ⇔ x′7 = 0
′
z˙[i] = z[i]
− (i mod 4)
i = 0...7
z ′ = check−1 (ˆ
z)
zˆ = permute−1 (p, z˜, 0, 0)
′
′
. . . k[i]
z˜[i] = k[i]
6
1
i = 0...7
′
pi = k[i]
7
k[i] − 1,
′
k[i]
=
k[i] ,
i = 0...7
yi = k[7−i]0
if y(7−i) = 1;
otherwise.
i = 0...7
i = 0...7
186
Weak key diversification algorithm
The iClass Standard key diversification algorithm uses a combination of single DES
and the proprietary function called hash0 , which we reverse engineered. Based on
our findings in the preceding sections, we conclude that the function hash0 is not
one-way nor collision resistant. In fact, it is possible to compute the inverse function
hash0−1 having a modest amount (on average 4) of candidate pre-images. After
recovering a secret card key, recovering an iClass master key is not harder than a
chosen plaintext attack on single DES. The use of single DES encryption for key
diversification results in weak protection of the master key. This is a critical weakness,
especially considering that there is only one master key for the HID application of
all iClass cards. Furthermore, the composition of single DES with the function hash0
does not strengthen the secret card key in any way.
Even worse, when we look at the modulo operations that are applied on the z
component of the hash0 function input, we see that this reduces the entropy of the
diversified card key with 2.23 bits.
9.4.4
Attacking iClass Standard key diversification
From the weaknesses that were explained in the previous section it can be concluded
that hash0 does not significantly increase the complexity of an attack on the master key K. In fact, the attack explained in this section requires one brute force run
on DES. For this key recovery attack we need a strong adversary model where the
adversary controls a genuine reader and is able to issue key update commands. Section 9.6.5 introduces an attack that allows a more restricted adversary. In this case,
we use a strong adversary that controls a genuine reader, like an Omnikey reader
in Secure Mode. The adversary controls this reader and is able to issue key update
commands. An attack consists of two phases and an adversary A needs to:
Phase 1
• emulate a random identity id to the reader;
• issue an update key command that updates from a known user defined master
key K′ to the unknown master key K that A wants to recover. Now, A can
obtain kid = hash0(DESenc (K, id)) from the XOR difference;
• compute the set of pre-images C by hash0−1 (kid );
• repeats Phase 1 until A obtains an output kid with |C| = 3.
Phase 2
• A checks for every candidate DES key K∗ ∈ {0, 1}56 if DESenc(K ∗ , id) = c, for
every c ∈ C;
187
• when the check above succeeds, A verifies the corresponding key K∗ against
another set of id and kid .
We have verified this attack on the two master keys K1 and K2 that are stored in
the Omnikey reader for the iClass application. The key K2 was also stored in the
naviGO software and we could check the key against pre-images that were selected
as described above. Although we did not find K1 stored in software we were still able
to verify it since we could dump the EEPROM of a reader where K1 was stored, see
Section 9.5.1. It would have been possible to recover hash0 from the EEPROM as
well, although the prior knowledge about hash0 allowed us to identify more quickly
where the remaining cryptographic functions were located in the EEPROM.
The attack above comes down to a brute force attack on single DES. A slightly
different variant is to keep the card identity id fixed and use a Time-Memory TradeOff (TMTO) that is constructed for a specific plaintext and runs through all possible
encryptions of this plaintext. Note that the table needs to be pre-computed and thus
a fixed plaintext must be chosen on forehand. This means that one fixed predefined
id is to be used in the attack. The number of pre-images can no longer be controlled.
In the worst case, the total number of pre-images is 512.
Finally, note that we need a strong adversary model in this attack. The adversary
needs to control a genuine reader, by which we mean that the adversary is able
to let the reader issue card key update commands. In a real-life setup this is not
really feasible. The reverse engineering of the cipher and authentication protocol of
iClass in Section 9.5 did not only reveal the iClass security mechanisms, but also
more weaknesses that are described in Section 9.6. We use some of these weaknesses
to lower the requirements on the adversary and deploy a second attack on iClass
Standard, when the adversary does not control the reader, in Section 9.4.4.
9.5
The iClass cipher
This section first describes the reverse engineering process employed to recover the
iClass cipher and to recover the iClass Elite key diversification algorithm. Then, we
only describe the reverse engineered iClass cipher. We use this in Section 9.6 to mount
a second (improved) attack on iClass Standard. The recovered key diversification
for iClass Elite and its corresponding weaknesses lead to the third attack which is
described in Section 9.7.
9.5.1
Firmware reverse engineering
In order to reverse engineer the cipher and the key diversification algorithm, we have
first recovered the firmware from an iClass reader. For this we used a technique
introduced in [Mer10] and later used in [GdKGV11]. Next, we will briefly describe
188
this technique. iClass readers (Fig. 9.5), as many other embedded devices, rely on
the popular PIC microcontroller (Fig. 9.5b) to perform their computations.
(a) iClass reader
(b) iClass reader where the epoxy resin has
been partially removed to expose the PIC
microcontroller
Figure 9.5: iClass readers
These microcontrollers are very versatile and can be flashed with a custom firmware.
The (program) memory of the microcontroller is divided into a number of blocks, each
of them having access control bits determining whether this block is readable/writable.
Even when the PIC is configured to be non-writable, it is always possible to reset the
access control bits by erasing the memory of the chip. At first glance this feature
does not seem very helpful to our reverse engineering goals since it erases the data
in the memory. Conveniently enough, even when the most common programming
environments do not allow it, the microcontroller supports erasure of a single block.
After patching the PIC programmer software to support this feature, it is possible to
perform the following attack to recover the firmware:
• Buy two iClass RW400 (6121AKN0000) readers.
• Erase block 0 on one of the readers. This resets the access control bits on block
0 to readable, writable.
• Write a small dumper program on block 0 that reads blocks 1, . . . , n and outputs
the data via one of the microcontroller’s output pins.
• Use the serial port of a computer to record the data. This procedure recovers
blocks 1, . . . , n.
• Proceed similarly with the other reader, but erasing blocks 1, . . . , n. This in
fact fills each block with NOP operations.
• At the end of block n write a dumper program for block 0.
• At some point the program will jump to an empty block and then reach the
dumper program that outputs the missing block 0.
Once we have recovered the firmware, it is possible to use IDA Pro and MPLAB to
189
disassemble, debug and reverse engineer the algorithms.
9.5.2
The cipher
This section describes the iClass cipher that we recovered from the firmware. This
cipher is interesting from an academic and didactic perspective as it combines two
important techniques in the design of stream ciphers from the ’80s and beginning of
the ’90s, i.e., Fibonacci generators and Linear Feedback Shift Registers (LFSRs).
The internal state of the iClass cipher consists of four registers as can be seen in
Figure 9.6. Two of these registers, which we call left (l) and right (r) are part of the
Fibonacci generator. The other two registers constitute linear feedback shift registers
top (t) and bottom (b). In order to understand the description of the cipher correctly,
take into account that the solid lines in Figure 9.6 represent byte operations while
dashed lines represent bit operations.
⊕ ⊕
input
k[0]
k[1]
k[2]
k[3]
k[4]
k[5]
⊕
⊕
⊕
⊕ ⊕
⊕
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
t
select(·)
⊕
r
l
M
U
X
⊕ ⊞
0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7
⊞
output
k[6]
⊕ ⊕ ⊕
⊕
0 1 2 3 4 5 6 7
b
k[7]
Figure 9.6: The iClass cipher
Definition 9.5.1 (Cipher state). A cipher state of iClass s is an element of F40
2
consisting of the following four components:
• the left register l = (l0 . . . l7 ) ∈ F82 ;
• the right register r = (r0 . . . r7 ) ∈ F82 ;
• the top register t = (t0 . . . t15 ) ∈ F16
2 ;
• the bottom register b = (b0 . . . b7 ) ∈ F82 .
The cipher has an input bit which is used (among others) during authentication to
shift in the card challenge cC and the reader nonce nR . With every clock tick a cipher
state s evolves to a successor state s′ . Both LFSRs shift to the right and the Fibonacci
generator iterates using one byte of the key (chosen by the select(·) function) and the
bottom LFSR as input. During this iteration each of these components is updated,
190
receiving additional input from the other components of the cipher. With each iteration, the cipher produces one output bit. The following sequence of definitions
describes the cipher in detail; see also Figure 9.6.
Definition 9.5.2. The feedback function for the top register T : F16
2 → F2 is defined
by
T (x0 x1 . . . . . . x15 ) = x0 ⊕ x1 ⊕ x5 ⊕ x7 ⊕ x10 ⊕ x11 ⊕ x14 ⊕ x15 .
Definition 9.5.3. The feedback function for the bottom register B : F82 → F2 is defined by
B(x0 x1 . . . x7 ) = x1 ⊕ x2 ⊕ x3 ⊕ x7 .
Definition 9.5.4 (Selection function). The selection function select : F2 × F2 × F82 →
F32 is defined by
select(x, y, r) = z0 z1 z2
where
z0 = (r0 ∧ r2 ) ⊕ (r1 ∧ r3 ) ⊕ (r2 ∨ r4 )
z1 = (r0 ∨ r2 ) ⊕ (r5 ∨ r7 ) ⊕ r1 ⊕ r6 ⊕ x ⊕ y
z2 = (r3 ∧ r5 ) ⊕ (r4 ∧ r6 ) ⊕ r7 ⊕ x
Definition 9.5.5 (Successor state). Let s = hl, r, t, bi be a cipher state, k ∈ (F82 )8 be
a key and y ∈ F2 be an input bit. Define the successor cipher state s′ = hl′ , r′ , t′ , b′ i
as
t′ ← (T (t) ⊕ r0 ⊕ r4 )t0 . . . t14
l′ ← (k[select(T (t),y,r)] ⊕ b′ ) ⊞ l ⊞ r
b′ ← (B(b) ⊕ r7 )b0 . . . b6
r′ ← (k[select(T (t),y,r)] ⊕ b′ ) ⊞ l .
We define the successor function suc which takes a key k ∈ (F82 )8 , a state s and an
input y ∈ F2 and outputs the successor state s′ . We overload the function suc to
multiple bit input x ∈ Fn2 which we define as
suc(k, s, ǫ) = s
suc(k, s, x0 . . . xn ) = suc(k, suc(k, s, x0 . . . xn−1 ), xn ) .
Definition 9.5.6 (Output). Define the function output which takes an internal state
s = hl, r, t, bi and returns the bit r5 . We also define the function output on multiple
input bits which takes a key k, a state s and an input x ∈ Fn2 as
output(k, s, ǫ) = ǫ
output(k, s, x0 . . . xn ) = output(s) · output(k, s′ , x1 . . . xn )
where s′ = suc(k, s, x0 ).
191
Definition 9.5.7 (Initial state). Define the function init which takes as input a key
k ∈ (F82 )8 and outputs the initial cipher state s = hl, r, t, bi where
t ← 0xE012
l ← (k[0] ⊕ 0x4C) ⊞ 0xEC
b ← 0x4C
r ← (k[0] ⊕ 0x4C) ⊞ 0x21
Definition 9.5.8 (MAC function). Define the function MAC : (F82 )8 × Fn2 → F32
2 as
MAC(k, m) = output(k, suc(k, init(k), m), 032 ) .
9.6
Weakness in iClass
This section describes weaknesses in the design and implementation of iClass. We
present four weaknesses that are later exploited in Section 9.6.5 to mount a attack
that recovers the systems master key.
9.6.1
Weak keys
The cipher has a clear weakness when the three rightmost bits of each key byte are
the same. Let us elaborate on that.
Proposition 9.6.1. Let β be a bitstring of length three. Then, for all keys k ∈ F64
2
of the form k = α[0] β . . . α[7] β with α[i] ∈ F52 the cipher outputs a constant Cβ .
This is because the output of the cipher is determined by the three rightmost (least
significant) bits of register r, the three rightmost bits of l and the three rightmost bits
of the selected key byte XOR b. Furthermore, only the rightmost bit of r influences
register b. This means that the 5 leftmost bits of r and the 5 leftmost bits of each
key byte affect only the key byte selection, but for the key under consideration this
does not affect the output. The same holds for cC and nR as they are just input to
the select(·) function. The following table shows the corresponding MAC value for
each possible value of β.
The manufacturer seems to be aware of this feature of the cipher since the function
hash0, used in key diversification, prevents such a key from being used. This weakness combined with the weakness described in Section 9.6.2 and 9.6.3 results in a
vulnerability exploited in Section 9.6.5.
9.6.2
XOR key update weakness
In order to update a card key, the iClass reader does not send the new key to the
card in the clear but instead it sends the XOR of the old and the new key (see
Section 9.3.1). This simple mechanism prevents an adversary from eavesdropping the
new key during key update. Although, this key update mechanism introduces a new
192
weakness, namely, it makes it possible for and adversary to make partial modifications
to the existing key. A key update should be an atomic operation. Otherwise it allows
an adversary to split the search space in a Time-Memory Trade-Off (TMTO), see
Section 3.2. Moreover, in case the cipher has some weak keys like the ones described
in Section 9.6.1, it allows an adversary to force the usage of one of these keys.
9.6.3
Privilege escalation
Several privilege escalation attacks have been described in the literature [KSRW04,
DDSW11]. The privilege escalation weakness in iClass concerns the management of
access rights over an application within the card. After a successful authentication
for application 1 has been executed, the reader is granted read and write access to
this application. Then, it is possible to execute a read command for a block within
application 2 without loosing the previously acquired access rights. More precisely, a
read command on block n within application 2, with n 6= cC , returns a sequence of
64 ones which indicates that permission is denied to read this block. Surprisingly, this
read attempt on application 2 does not affect the previously acquired access rights
on application 1. This read command though, has the side effect of loading the key
k2 into the internal state of the cipher. In particular, from this moment on the card
accepts write commands on application 1 that have a valid MAC computed using
key k2.
9.6.4
Lower card key entropy
After careful inspection of the function hash0 (Section 9.4.3) it becomes clear that
this function attempts to fix the weak key weakness presented in this section.
The function hash0 makes sure that, when looking at the last bit of each key
byte, exactly four of them are zeros (and the other four of them are ones). Due to
8!
this restriction there are only (4!)
2 = 70 possibilities for the last bits of each key byte,
8
instead of 2 = 256, reducing the entropy of the key by 1.87 bits. This constitutes
the biggest part of the 2.23 bits entropy loss (Section 9.4.3) that is caused by hash0 .
9.6.5
Key recovery attack on iClass Standard
This section shows how the weaknesses described in Section 9.6 can be exploited.
Concretely, we propose an attack that allows an adversary to recover a card key by
wirelessly communicating with a card and a reader. Once the card key has been
recovered, the weak key diversification weakness described in Section 9.4.3 can be
exploited in order to recover the master key. Next, we describe the attack in detail.
In order to recover a target card key k1 from application 1, an adversary A proceeds
as follows. First, A eavesdrops a legitimate authentication trace on the e-purse with
key k1, while making sure that the e-purse is not updated. If the reader attempts
193
to update the e-purse, this can be prevented by playing as man-in-the-middle or
by simply jamming the e-purse update message. Next, the adversary replays this
authentication trace to the card. At this point the adversary gains read and write
access to application 1. Although, in order to actually be able to write, the adversary
still needs to send a valid MAC with k1 of the payload. To circumvent this problem,
the adversary proceeds as described in Section 9.6.3, exploiting the privilege escalation
weakness. At this point the adversary still has read and write access to application 1
but he is now able to issue write commands using MACs generated with the default
key k2 [HID06] to write on application 1. In particular, A is now able to modify
k1 at will. Exploiting the XOR key update weakness described in Section 9.6.2, the
adversary modifies the card key k1 into a weak key by setting the three rightmost bits
of each key byte the same. Concretely, the adversary runs 23×7 = 221 key updates
3
on the card with ∆ = 05 δ[0] . . . 05 δ[6] 08 ∈ F64
2 and δ[i] = abc ∈ F2 for all possible
bits a, b and c. One of these key updates will produce a weak key, i.e., a key of the
form k = α[0] β . . . α[7] β with α[i] ∈ F52 . Exploiting the weak key property described
in Section 9.6.1, after each key update A runs 8 authentication attempts, one for
each possible value of β, using the MAC values shown in Table 9.4. Note that a
failed authentication will not affect the previously acquired access rights. As soon
as an authentication attempt succeeds, the card responds with a MAC value that
univocally determines β as stated in Proposition 9.6.1. Knowing β, the adversary is
able to recover the three rightmost bits of k1[i] by computing β ⊕ δ[i] for i = 0 . . . 6.
Furthermore, the three rightmost bits of k[7] are equal to β ⊕ 000 = β. In this way, the
adversary recovers 3 × 8 = 24 bits of k1 and only has to search the remaining 40 bits
of the key, using the legitimate trace eavesdropped in the beginning for verification.
Table 9.4: Corresponding MAC for each value of β
β
000
001
010
011
100
101
110
111
Cβ = MAC(k, cC · nR )
BF 5D 67 7F
10 ED 6F 11
53 35 42 0F
AB 47 4D A0
F6 CF 43 36
59 7F 4B 58
1A A7 66 46
E2 D5 69 E9
This attack can be further optimized. The restriction on the last bit of each
byte imposed by hash0 , described at the end of Section 9.6.4, reduces the number of
required key updates from 221 to almost 219 . Therefore, it reduces the total number
of authentication attempts to 219 × 8 = 222 . Once the adversary has recovered the
card key k1, as we already mention in Section 9.6.4, recovering the master key is just
as hard as breaking single DES.
194
9.7
iClass Elite
This section describes in detail the built-in key diversification algorithm of iClass
Elite. Besides the obvious purpose of deriving a card key from a master key, this
algorithm intends to circumvent weaknesses in the cipher by preventing the usage of
certain ‘weak’ keys. In this way, it is patching a weakness in the iClass cipher. After
the description of the iClass Elite key diversification in Section 9.7.1 we describe the
weaknesses of this scheme in Section 9.7.2. Finally, the third and fastest attack of
this chapter, concerning iClass Elite, is given in Section 9.7.3.
First, recall the key diversification of the iClass Standard system that we described in Section 9.4.2. In this scheme, the iClass reader first encrypts the card
identity id with the master key K, using single DES. The resulting ciphertext is
then input to a function called hash0 which outputs the diversified key k, i.e.,
k = hash0(DESenc (K, id)). Here the DES encryption of id with master key K outputs a cryptogram c of 64 bits. These 64 bits are divided as c = hx, y, z[0] , . . . , z[7] i ∈
F82 × F82 × (F62 )8 which is used as input to the hash0 function. This function introduces
some obfuscation by performing a number of permutations, complement and modulo
operations. Besides that, it checks for and removes patterns like similar key bytes,
which could produce a strong bias on the cipher. Finally, the output of hash0 is the
diversified card key k = k[0] , . . . , k[7] ∈ (F82 )8 .
Remark 9.2. The DES implementation used in iClass is non-compliant with the
NIST standard [FIP77]. Concretely, iClass deviates from the standard in the
way of representing keys. According to the standard a DES key is of the form
hk0 . . . k6 p0 , . . . , k47 . . . k55 p7 i where k0 . . . k55 are the actual key bits and p0 . . . p7 are
parity bits. Instead, in iClass, a DES key is of the form hk0 . . . k55 p0 . . . p7 i.
9.7.1
Key diversification on iClass Elite
The iClass Elite system is sold as a more secure and advanced solution than the iClass
Standard variant. HID introduces iClass Elite (a.k.a. High Security) as the solution
for “those who want a boost in security” [Cum03]. iClass Elite aims to solve the obvious limitations of having just one single world-wide master key for all iClass systems.
Instead, iClass Elite allows customers to have a personalized master key for their
own system. To this purpose, HID has modified the key diversification algorithm,
described in Section 9.4.2 by adding an additional layer to it. This modification only
affects the way in which readers compute the corresponding card key but does not
change anything on the cards themselves. This section describes this key diversification algorithm in detail. Then, Section 9.7.2 describes two weaknesses that are later
exploited in Section 9.7.3.
We first need to introduce a number of auxiliary functions and then we explain
this algorithm in detail.
195
Definition 9.7.1 (Auxiliary functions). Let us define the following auxiliary functions. The bit-rotate left function
rl : F82 → F82 as rl(x0 . . . x7 ) = x1 . . . x7 x0 .
The bit-rotate right function
rr : F82 → F82 as rr(x0 . . . x7 ) = x7 x0 . . . x6 .
The nibble-swap function swap
swap : F82 → F82 as swap(x0 . . . x7 ) = x4 . . . x7 x0 . . . x3 .
Definition 9.7.2. Let the second hash function hash1 : (F82 )8 → (F82 )8 be defined as
hash1(id[0] . . . id[7] ) = k[0] . . . k[7]
where
′
mod 128,
k[i] = k[i]
i = 0...7
′
= id[0] ⊕ · · · ⊕ id[7]
k[0]
′
′ )+1
= rr(id[4] ⊞ k[2]
k[4]
′
= id[0] ⊞ . . . ⊞ id[7]
k[1]
′
′ )+1
= rl(id[5] ⊞ k[3]
k[5]
′
′
k[2]
= rr(swap(id[2] ⊞ k[1]
))
′
′
k[6]
= rr(id[6] ⊞ (k[4]
⊕ 3C))
′
′
k[3]
= rl(swap(id[3] ⊞ k[0]
))
′
′
k[7]
= rl(id[7] ⊞ (k[5]
⊕ C3))
Definition 9.7.3. Define the rotate key function rk : (F82 )8 × N → (F82 )8 as
rk(x[0] . . . x[7] , 0) = x[0] . . . x[7]
rk(x[0] . . . x[7] , n + 1) = rk(rl(x[0] ) . . . rl(x[7] ), n)
16
Definition 9.7.4. Let the third hash function hash2 : (F82 )8 → (F64
be defined as
2 )
cus
hash2(K ) = y[0] z[0] . . . y[7] z[7] where
z[0] = DESenc (Kcus , Kcus )
z[i] = DESdec (rk(Kcus , i), z[i−1] )
i = 1...7
y[0] = DESdec (z[0] , Kcus )
y[i] = DESenc (rk(Kcus , i), y[i−1] )
i = 1...7
Next we introduce the Selected key. This key is used as input to the standard iClass
key diversification algorithm. It is computed by taking a selection of bytes from
hash2(Kcus ). This selection is determined by each byte of hash1(id) seen as a byte
offset within the bitstring hash2(Kcus ).
196
Definition 9.7.5. Let h ∈ (F82 )128 . Let k sel ∈ (F82 )8 be the Selected key defined as
h ← hash2(Kcus );
sel
k[i]
← h[hash1(id)[i] ]
i = 0...7
The last step to compute the diversified card key is just like in iClass
k ← hash0(DESenc (k sel , id)) .
9.7.2
Weaknesses in iClass Elite key diversification
This section describes two weaknesses in the key diversification algorithm of iClass
Elite. These weaknesses are exploited in Section 9.7.3 to mount an attack against
iClass Elite that recovers the custom master key.
Redundant key diversification on iClass Elite
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
Card identity id
0B 0F FF F7 FF 12
04 0E 08 F7 FF 12
09 0D 05 F7 FF 12
0A 0C 06 F7 FF 12
0F 0B 03 F7 FF 12
08 0A 0C F7 FF 12
0D 09 09 F7 FF 12
0E 08 0A F7 FF 12
03 07 17 F7 FF 12
3C 06 E0 F7 FF 12
01 05 1D F7 FF 12
02 04 1E F7 FF 12
07 03 1B F7 FF 12
00 02 24 F7 FF 12
05 01 21 F7 FF 12
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
e0
01
78
7B
7A
7D
74
77
76
69
20
63
62
65
5C
5F
01
02
03
04
05
06
07
08
09
0A
0B
0C
0D
0E
0F
hash1(id)
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
00 00 45 01
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
45
Recovery
Byte 00, 01 in 224
Byte 02 in 216
Byte 03 in 216
Byte 04 in 216
Byte 05 in 216
Byte 06 in 216
Byte 07 in 216
Byte 08 in 216
Byte 09 in 216
Byte 0A in 216
Byte 0B in 216
Byte 0C in 216
Byte 0D in 216
Byte 0E in 216
Byte 0F in 216
Figure 9.7: Chosen card identities
Assume that an adversary somehow learns the first 16 bytes of hash2(Kcus ), i.e., y[0]
and z[0] . Then he can simply recover the master custom key Kcus by computing
Kcus = DESenc (z[0] , y[0] ) .
Furthermore, the adversary is able to verify that he has the correct Kcus by checking
the following equality
z[0] = DESenc (Kcus , Kcus ) .
197
Weak key-byte selection on iClass Elite
Yet another weakness within the key diversification algorithm of iClass Elite has to do
with the way in which bytes from hash2(Kcus ) are selected in order to construct the
key k sel . As described in Section 9.7.1, the selection of key bytes from hash2(Kcus )
is determined by hash1(id). This means that only the card’s identity decides which
bytes of hash2(Kcus ) are used for k sel . This constitutes a serious weakness since no
secret is used in the selection of key bytes at all. Especially considering that, for some
card identities, the same bytes of hash2(Kcus ) are chosen multiple times by hash1(id).
In particular, this implies that some card keys have significantly lower entropy than
others. What is even more worrying, an adversary can compute by himself which
card identities have this feature.
9.7.3
Key recovery attack on iClass Elite
In order to recover a master key Kcus , an adversary proceeds as follows. First, exploiting the weakness described in Section 9.7.2, the adversary builds a list of chosen
card identities like the ones shown in Figure 9.7. This Figure contains a list of 15 card
identities and their corresponding key-byte selection indices hash1(id). The selection
of card identities in this list is malicious. They are chosen such that the resulting
key k sel has very low entropy (in fact, it is possible to find several lists with similar
characteristics).
For the first card identity in the list, the resulting key k sel is built out of only
three different bytes from hash2(Kcus ), namely 0x00, 0x01 and 0x45. Therefore, this
key has as little as 24 bits of entropy (instead of 56). Next, the adversary will initiate
an authentication protocol run with a legitimate reader, pretending to be a card with
identity id = 0x000B0FFFF7FF12E0 as shown in the list. Following the authentication
protocol, the reader will return a message containing a nonce nR and a MAC using
k. The adversary will repeat this procedure for each card identity in the list, storing
a tuple hid, nC , nR , MACi for each entry. Afterwards, off-line, the adversary tries all
224 possibilities for bytes 0x00, 0x01 and 0x45 for the first key identity. For each try,
he computes the resulting k and recomputes the authentication run until he finds a
MAC equal to the one he got from the reader. Then he has recovered bytes 0x00,
0x01 and 0x45 from hash2(Kcus ).
The adversary proceeds similarly for the remaining card identities from the list.
Although, this time he already knows bytes 0x00, 0x01 and 0x45 and therefore only
two bytes per identity need to be explored. This lowers the complexity to 216 for
each of the remaining entries in the list. The bytes that need to be explored at
each step are highlighted with boldface in the list. At this point the adversary has
recovered the first 16 bytes of hash2(Kcus ). Finally, exploiting the weakness described
in Section 9.7.2, the adversary is able to recover the custom master key Kcus with a
total computational complexity of 225 DES encryptions.
198
9.8
Conclusion
We have shown that the security of several building blocks of iClass is unsatisfactory.
Again, obscurity does not provide extra security and there is always a risk that it can
be circumvented. In fact, experience shows that instead of adding extra security it
often covers up negligent designs.
It is hard to imagine why HID decided, back in 2002, to use single DES for key
diversification considering that DES was already broken in practice in 1997 [LG98].
Especially when most (if not all) HID readers are capable of computing 3DES. Another unfortunate choice was to design their proprietary hash0 function instead of
using an openly designed and community reviewed hash function like SHA-3. From
a cryptographic perspective, their proprietary function hash0 fails to achieve any desirable security goal.
Furthermore, we have found many vulnerabilities in the cryptography and implementation of iClass that result in two key recovery attacks. Our first attack requires
one eavesdropped authentication trace with a genuine reader (which takes about
10ms). Next, the adversary needs 222 authentication attempts with a card, which
in practice takes approximately six hours. To conclude the attack, the adversary
needs only 240 off-line MAC computations to recover the card key. The whole attack
can be executed within a day. For the attack against iClass Elite, an adversary only
needs 15 authentication attempts with a genuine reader to recover the custom master
key. The computational complexity of this attack is negligible, i.e., 225 DES encryptions. This attack can be executed from beginning to end in less than five seconds.
We have successfully executed both attacks in practice and verified the claimed attack
times.
The built-in key diversification and especially the function hash0 is advertised as
a security feature but in fact it is a patch to circumvent weaknesses in the cipher.
The cipher is a basic building block for any secure protocol. Experience shows that
once a weakness in a cipher has been found, it is extremely difficult to patch it in a
satisfactory manner. Using a well known and community reviewed cipher is a better
alternative. The technique described in [RSH+ 12] could be considered as a palliating
countermeasure for our first attack.
More is not always better: the key diversification algorithm of iClass Elite requires
fifteen DES operations more than iClass Standard while it achieves inferior security.
Instead, it would have been more secure and efficient to use 3DES than computing
16 single DES operations in an ad hoc manner.
A practical counter-measure until migration would be to stop using the iClass Elite
diversification scheme and only use iClass Standard with customized master keys for
all applications. However, such measure should only be considered as a temporary
mitigation and not as a definite solution as the (more expensive) attack on iClass
Standard still applies.
In line with the principles of responsible disclosure, we have notified the manu-
199
facturer HID Global and informed them of our findings back in November 2011. By
the time of writing this chapter, HID has extended their product line with support
for AES-enabled Mifare DESFire EV1 cards4
9.9
Acknowledgments
We are thankful to Milosch Meriac for his kind support while bypassing the PIC’s
read protection mechanisms which enabled the firmware recovery of the iClass reader.
The authors would also like to thank the anonymous reviewers for their outstanding
work. Their constructive and valuable comments helped us to substantially improve
the quality of this study.
4 www.hidglobal.com/iclass-hf-migration-reader-family-datasheet
Chapter 10
Megamos Crypto
10.1
Disclaimer
Due to an interim injunction1 , ordered by the High Court of London on Tuesday the
25th of June, 2013, the authors are restrained from publishing the technical contents of
the scientific article Dismantling Megamos Crypto: Wirelessly Lockpicking a Vehicle
Immobilizer [VGE13] until further notice.
10.2
Historical claim
Figure 10.1 contains the cryptographic hash (SHA-512) of the original final paper [VGE13] which was scheduled to appear in the proceedings of the 22nd USENIX
Security Symposium, Washington DC, August 2013.
9d05ba88740499eecea3d8609174b444
43683da139f78b783666954ccc605da8
4601888134bf0c23ba46fb4a88c056bf
bbb629e1ddffcf60fa91880b4d5b4aca
Figure 10.1: Cryptographic hash (SHA-512) of the original paper [VGE13]
1 http://www.bailii.org/ew/cases/EWHC/Ch/2013/1832.html
202
Megamos Crypto
This page is intentionally left blank
Part III
Back matter
Conclusion
In computer security research it is common practice to spend a significant part of our
time analyzing existing cryptosystems. In our field we cannot prove that a cryptographic technique or mechanism is secure. The best way to gain confidence that such
a technique is secure is by independent peer-reviews and thorough public scrutiny.
If the scientific community, industry and general public do not manage to break
a cryptosystem after some time, then confidence is gained in such a technique or
mechanism. In this way the security research progresses to develop the best possible
protection mechanisms in the field of computer security.
Cryptosystems which are kept secret lack public scrutiny and carry the risk of being deployed in many (millions of) devices before potential cryptographic weaknesses
come to light. Once a cryptosystem is proven to be insecure, it tends to quickly lose
the trust of its users. It is difficult and costly to migrate widely deployed systems
to more secure solutions in a reasonably fast manner. Public exposure on the other
hand, allows the biggest stake-holder, the general public, to independently assess the
protection that is offered by the cryptosystem.
History shows that, despite secrecy of the algorithm, most vulnerabilities of a
cryptosystem eventually get exposed, privately or publicly. Furthermore, non-public
exchange of cryptographic design weaknesses in a secret algorithm enables adversaries
to abuse the system and potentially carry out malicious activities without being detected.
Nevertheless, there can be reasons to specifically choose to design a proprietary
cryptographic algorithm. For instance, when the developer intends to acquire a patent
on the design. In such a case the proprietary algorithm becomes publicly available at
a later stage (published in a patent). Publishing of the patent with the algorithm still
allows public and scientific scrutiny. Contrarily, a reason to design a secret algorithm
is to avoid compatible or counterfeit products from competitors. However, such an
approach might have a different design goal as primary target. For instance, to create
a vendor-lock situation, in stead of delivering secure cryptographic algorithms and
protocols.
206
Conclusion
Finally, there are sincere arguments to advocate the use of secret algorithms in a
strictly controlled environment. For instance, institutes like government agencies and
military establishments have the resources, knowledge and ability to extend secure
cryptographic designs without directly compromizing its original security strength.
When physical access to a system that implements a secret design is strictly controlled, there are at least two factors that can increase its security properties. First,
the secrecy adds an extra obstacle for an adversary to overcome before in-depth cryptographic analysis can be performed. Secondly, the altered parameters, additional
computations and specific use might increase the overall cryptographic strength. With
no limitations on resources, a different set of cryptographic operations might be a better fit than the general-purpose standardized cryptographic algorithms.
Apart from this exception, this study reinforces the point that has been made
many times: secrecy of an algorithm does not add measurable security to a publicly
deployed cryptosystem. Especially in the long term, it is wise to assume that the
inner workings eventually get exposed to adversaries. Such metrics have a serious
impact when the security of the cryptosystem mostly depends depends on the secrecy
of the algorithm (security by obscurity). It is difficult to design a strong cryptographic
algorithm and, without proper independent peer-reviews, there is a great risk that an
unintended design mistake compromises the security of the cipher.
Deployment of badly designed cryptographic algorithms is undesirable, regardless
of their secrecy. This dissertation shows that weak and vulnerable ciphers lead to
insecure products. The ciphers addressed in this study are derived from obsolete and
insecure designs. Surprisingly, most of these ciphers have been massively deployed
since the nineties, while a decade before that the literature already contained a large
collection of studies that prove the insecurity of similar cipher designs.
With the introduction of cheaper and more powerful hardware it is much easier to implement secure cryptographic algorithms that require a significant amount
of computation. Although the ciphers addressed in this thesis are embedded into
products which are still widely deployed and used by the general public, the industry is starting to offer compatible replacements which utilize openly designed and
community-reviewed cryptographic algorithms. The academic community supports
this trend and works closely together with several international institutions, governments and industries to achieve better and more secure cryptographic algorithms.
A lesson that can be learned from the examples illustrated in this dissertation is the
security impact of combined vulnerabilities. The security of a cryptosystem depends
on the system as a whole. Implementation weaknesses can be utilized by an adversary
to exploit a cryptosystem more efficiently. Combining such vulnerabilities can be a
serious threat, even if a cryptographic algorithm itself is not particularly weak. For
instance, when a cipher specification states that an Initialization Vector (IV) should
be initialized with a random bitstring, then the cryptosystem should ensure this at
all times. The National Institute of Standards and Technology (NIST) introduced a
statistical test suite [RSN+ 01] that can be used to automatically estimate the random-
Conclusion
207
ness of an IV. Additionally, the implementation of the component and interface to the
rest of the cryptosystem should be considered. Any external influence on the IV value
must be seen as a potential security compromise of the cryptosystem. In order to find
such problems it is good practice to incorporate some form of formal verification in the
development and implementation of security products, see for instance [FL12]. Furthermore, systematic and automated model checking techniques proposed in [Tre08]
can help to detect and avoid implementation weaknesses like privilege escalations.
Alternatively, formalizing the whole design in a theorem prover [Bla01, JWS11] may
reveal additional weaknesses.
It remains an open question whether a comprehensive automated framework could
detect the impact of combined security vulnerabilities in a cryptosystem. An interesting study is to learn the capabilities, limitations and practicality of such a framework.
A quick start could be made by using the in-depth overview of vulnerabilities presented in this dissertation. Automated techniques and methodologies that generalize
these weaknesses in a framework which tests for combined vulnerabilities in a cryptosystem would be extremely useful for the development of future designs.
Bibliography
[ABP+ 13]
(1)
[ABV12]
(2)
[AC09]
(3)
[ACG89]
(4)
[AH88]
(5)
[AJO08]
(6)
[AK96]
(7)
Nadhem J AlFardan, Daniel J Bernstein, Kenneth G Paterson,
Bertram Poettering, and JC Schuldt. On the security of RC4 in
TLS. In 22nd USENIX Security Symposium (USENIX Security
2013). USENIX Association, 2013.
Gergely Alpár, Lejla Batina, and Roel Verdult. Using NFC phones
for proving credentials. In 16th Measurement, Modelling, and Evaluation of Computing Systems and Dependability and Fault Tolerance
(MMB&DFT 2012), volume 7201 of Lecture Notes in Computer Science, pages 317–330. Springer-Verlag, 2012.
Martin Albrecht and Carlos Cid. Algebraic techniques in differential
cryptanalysis. In Fast Software Encryption, pages 193–208. SpringerVerlag, 2009.
Mikhail J Atallah, Richard Cole, and Michael T Goodrich. Cascading
divide-and-conquer: A technique for designing parallel algorithms.
SIAM Journal on Computing, 18(3):499–532, 1989.
Hamid Reza Amirazizi and Martin E Hellman. Time-memoryprocessor trade-offs. IEEE Transactions on Information Theory,
34(3):505–512, 1988.
Gildas Avoine, Pascal Junod, and Philippe Oechslin. Characterization and improvement of time-memory trade-off based on perfect
tables. ACM Transactions on Information and System Security (TISSEC 2008), 11(4):1–22, 2008.
Ross J. Anderson and Markus G. Kuhn. Tamper resistance - a cautionary note. In 2nd USENIX Workshop on Electronic Commerce,
pages 1–11. USENIX Association, 1996.
210
[AK03]
(8)
[AM97]
(9)
[And91]
(10)
[And95]
(11)
[And03]
(12)
[And10]
(13)
[Arm04]
(14)
[AS09]
(15)
[AT06]
(16)
[AT07]
(17)
[AT09]
(18)
Bibliography
Frederik Armknecht and Matthias Krause. Algebraic attacks on combiners with memory. In 23rd International Cryptology Conference,
Advances in Cryptology (CRYPTO 2003), volume 2729 of Lecture
Notes in Computer Science, pages 162–175. Springer-Verlag, 2003.
Ross Anderson and Charalampos Manifavas. Chameleon - a new kind
of stream cipher. In 4th International Workshop on Fast Software
Encryption (FSE 1997), volume 1267 of Lecture Notes in Computer
Science, pages 107–113. Springer-Verlag, 1997.
Ross J Anderson. Tree functions and cipher systems. Cryptologia,
15(3):194–202, 1991.
Ross Anderson. Searching for the optimum correlation attack. In 2nd
International Workshop on Fast Software Encryption (FSE 1994),
volume 1008 of Lecture Notes in Computer Science, pages 137–143.
Springer-Verlag, 1995.
Ross Anderson. Cryptography and competition policy: issues with
‘trusted computing’. In Proceedings of the twenty-second annual symposium on Principles of distributed computing, pages 3–10. ACM,
2003.
Ross J. Anderson. Security Engineering: A guide to building dependable distributed systems. Wiley, 2010.
Frederik Armknecht. Improving fast algebraic attacks. In 11th International Workshop on Fast Software Encryption (FSE 2004), volume
3017 of Lecture Notes in Computer Science, pages 65–82. SpringerVerlag, 2004.
Kazumaro Aoki and Yu Sasaki. Meet-in-the-middle preimage attacks
against reduced SHA-0 and SHA-1. In 29th International Cryptology
Conference, Advances in Cryptology (CRYPTO 2009), volume 5677
of Lecture Notes in Computer Science, pages 70–89. Springer-Verlag,
2009.
Standard read/write crypto identificastion IC - e5561.
Datasheet, September 2006. Atmel Corporation.
Product
CryptoMemory specification. Product Datasheet, April 2007. Atmel
Corporation.
CryptoRF specification, AT88SCxxxxCRF.
March 2009. Atmel Corporation.
Product Datasheet,
Bibliography
[AT11]
(19)
[Bab95]
(20)
[BB05]
(21)
[BB06]
(22)
[BBD+ 99]
(23)
[BBD06]
(24)
[BBF83]
(25)
[BBK03]
(26)
[BBK08]
(27)
[BBS99]
(28)
211
Embedded avr microcontroller including rf transmitter and immobilizer lf functionality for remote keyless entry - ATA5795C. Product
Datasheet, November 2011. Atmel Corporation.
Steve Babbage. A space/time tradeoff in exhaustive search attacks
on stream ciphers. In European Convention on Security and Detection, volume 408 of Conference Publications, pages 161–166. IEEE
Computer Society, 1995.
David Brumley and Dan Boneh. Remote timing attacks are practical.
Computer Networks, 48(5):701–716, 2005.
Elad Barkan and Eli Biham. Conditional estimators: An effective
attack on A5/1. In 12th International Workshop on Selected Areas in
Cryptography (SAC 2005), volume 3897 of Lecture Notes in Computer
Eli Biham, Alex Biryukov, Orr Dunkelman, Eran Richardson, and
Adi Shamir. Initial observations on Skipjack: Cryptanalysis of
Skipjack-3XOR. In 5th International Workshop on Selected Areas
in Cryptography (SAC 1998), volume 1556 of Lecture Notes in Computer Science, pages 362–376. Springer-Verlag, 1999.
Alexander Becher, Zinaida Benenson, and Maximillian Dornseif.
Tampering with motes: Real-world physical attacks on wireless sensor
networks. In 3rd International Conference on Security in Pervasive
Computing (SPC 2006), volume 3934 of Lecture Notes in Computer
R Kenneth Bauer, Thomas A. Berson, and Richard J. Feiertag. A
key distribution protocol using event markers. ACM Transactions on
Computer Systems (TOCS), 1(3):249–255, 1983.
Elad Barkan, Eli Biham, and Nathan Keller. Instant ciphertextonly cryptanalysis of GSM encrypted communication. In 23rd International Cryptology Conference, Advances in Cryptology (CRYPTO
2003), volume 2729 of Lecture Notes in Computer Science, pages
600–616. Springer-Verlag, 2003.
Elad Barkan, Eli Biham, and Nathan Keller. Instant ciphertextonly cryptanalysis of GSM encrypted communication. Journal of
Cryptology, 21(3):392–429, 2008.
Eli Biham, Alex Biryukov, and Adi Shamir. Cryptanalysis of Skipjack
reduced to 31 rounds using impossible differentials. In 18th International Conference on the Theory and Application of Cryptographic
Techniques, Advances in Cryptology (EUROCRYPT 1999), volume
212
Bibliography
[BBS06]
(29)
[BC94]
(30)
[BC08]
(31)
[BCM08]
(32)
[BCM12]
(33)
[BCO04]
(34)
[BD00]
(35)
[BDK05]
(36)
Elad Barkan, Eli Biham, and Adi Shamir. Rigorous bounds on cryptanalytic time/memory tradeoffs. In 26th International Cryptology
2006.
Stefan Brands and David Chaum. Distance-bounding protocols.
In 12th International Conference on the Theory and Application of
Cryptographic Techniques, Advances in Cryptology (EUROCRYPT
1993), volume 765 of Lecture Notes in Computer Science, pages 344–
359. Springer-Verlag, 1994.
Eli Biham and Yaniv Carmeli. Efficient reconstruction of RC4 keys
from internal states. In 15th International Workshop on Fast Software
Jean Pierre Benhammou, Vincent C. Colnot, and David J. Moore.
Secure memory device for smart cards. US Patent 7395435 B2, July
2008.
David Basin, Cas Cremers, and Simon Meier. Provably repairing
the ISO/IEC 9798 standard for entity authentication. In 1st International Conference on Principles of Security and Trust, pages 129–148.
Eric Brier, Christophe Clavier, and Francis Olivier. Correlation
power analysis with a leakage model. In 6th International Workshop
on Cryptographic Hardware and Embedded Systems (CHES 2004),
Eli Biham and Orr Dunkelman. Cryptanalysis of the A5/1 GSM
stream cipher. In 1st International Conference on Cryptology in India, Progress in Cryptology (INDOCRYPT 2000), volume 1977 of
Lecture Notes in Computer Science, pages 43–51. Springer-Verlag,
2000.
Eli Biham, Orr Dunkelman, and Nathan Keller. A related-key rectangle attack on the full KASUMI. In 11th International Conference
on the Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2005), volume 3788 of
2005.
Bibliography
[BdKGP+ 12]
(37)
[BDL97]
(38)
[BE02]
(39)
[Ben80]
(40)
[BER07]
(41)
[BFL+ 93]
(42)
[BFSB06]
(43)
[BG07]
(44)
[BGL05]
(45)
213
Arjan Blom, Gerhard de Koning Gans, Erik Poll, Joeri de Ruiter,
and Roel Verdult. Designed to fail: A USB-connected reader for
online banking. In 17th Nordic Conference on Secure IT Systems
(NordSec 2012), volume 7617 of Lecture Notes in Computer Science,
pages 1–16. Springer-Verlag, 2012.
Dan Boneh, Richard A DeMillo, and Richard J Lipton. On the importance of checking cryptographic protocols for faults. In 16th International Conference on the Theory and Application of Cryptographic
Techniques, Advances in Cryptology (EUROCRYPT 1997), volume
Mark Blunden and Adrian Escott. Related key attacks on reduced
round KASUMI. In 9th International Workshop on Fast Software
Jon Louis Bentley. Multidimensional divide-and-conquer. Communications of the ACM, 23(4):214–229, 1980.
Andrey Bogdanov, Thomas Eisenbarth, and Andy Rupp.
A
hardware-assisted realtime attack on A5/2 without precomputations.
In 9th International Workshop on Cryptographic Hardware and Embedded Systems (CHES 2007), volume 4727 of Lecture Notes in Computer Science, pages 394–412. Springer-Verlag, 2007.
Simon Blythe, Beatrice Fraboni, Sanjay Lall, Haroon Ahmed, and
Ugo de Riu. Layout reconstruction of complex silicon chips. IEEE
journal of solid-state circuits, 28(2):138–145, 1993.
Michael Brutscheck, Marco Franke, Andreas Th Schwarzbacher, and
Steffen Becker. Determination of pin types and minimisation of test
vectors in unknown CMOS integrated circuits. In International Conference on Electronic Devices and Systems (EDS IMAPS CS 2006),
pages 64–69, 2006.
Côme Berbain and Henri Gilbert. On the security of IV dependent
stream ciphers. In 14th International Workshop on Fast Software
Lawrence D Bodin, Lawrence A Gordon, and Martin P Loeb. Evaluating information security investments using the analytic hierarchy
process. Communications of the ACM, 48(2):78–83, 2005.
214
[BGN05]
(46)
[BGS+ 05]
(47)
[BGV+ 12]
(48)
[BGW01]
(49)
[BHL06]
(50)
[Bih97]
(51)
[Bir04]
(52)
[BJ04]
(53)
[BK14]
(54)
[BKL+ 07]
(55)
Bibliography
Eli Biham, Louis Granboulan, and Phong Q Nguyễn. Impossible
fault analysis of RC4 and differential fault analysis of RC4. In 12th
Stephen C. Bono, Matthew Green, Adam Stubblefield, Ari Juels,
Aviel D. Rubin, and Michael Szydlo.
Security analysis of a
cryptographically-enabled RFID device. In 14th USENIX Security
Symposium (USENIX Security 2005), pages 1–16. USENIX Association, 2005.
Josep Balasch, Benedikt Gierlichs, Roel Verdult, Lejla Batina, and
Ingrid Verbauwhede. Power analysis of Atmel CryptoMemory - recovering keys from secure EEPROMs. In 12th Cryptographers’ Track at
the RSA Conference, Topics in Cryptology (CT-RSA 2012), volume
Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting mobile
communications: the insecurity of 802.11. In 7th International Conference on Mobile Computing and Networking (MOBICOM 2001),
pages 180–189. ACM, 2001.
Andrea Bittau, Mark Handley, and Joshua Lackey. The final nail
in WEP’s coffin. In 27th IEEE Symposium on Security and Privacy
(S&P 2006), pages 386–400. IEEE Computer Society, 2006.
Eli Biham. A fast new DES implementation in software. In 4th
Alex Biryukov. Block ciphers and stream ciphers: The state of the
art. IACR Cryptology ePrint Archive, 2004(94):1–22, 2004.
Jean Pierre Benhammou and Mary Jarboe. Security at an affordable
price. Atmel Applications Journal, 3:29–30, 2004.
Christian Brandt and Michael Kasper. Don’t push it: Breaking iButton security. In 6th International Symposium on Foundations and
Practice of Security, volume 8352 of Lecture Notes in Computer Science, pages 369–387. Springer-Verlag, 2014.
Andrey Bogdanov, Lars R Knudsen, Gregor Leander, Christof Paar,
Axel Poschmann, Matthew JB Robshaw, Yannick Seurin, and Charlotte Vikkelsoe. PRESENT: An ultra-lightweight block cipher. In 9th
Bibliography
215
International Workshop on Cryptographic Hardware and Embedded
Systems (CHES 2007), volume 4727 of Lecture Notes in Computer
[BKR11]
(56)
[BKZ11]
(57)
[Bla01]
(58)
[Blo04]
(59)
[BM03]
(60)
[BMS06]
(61)
[Bog07a]
(62)
[Bog07b]
(63)
[Bog07c]
(64)
Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger.
Biclique cryptanalysis of the full AES. In 17th International Conference on the Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2011), volume
Alex Biryukov, Ilya Kizhvatov, and Bin Zhang. Cryptanalysis of
the Atmel cipher in SecureMemory, CryptoMemory and CryptoRF.
In 9th Applied Cryptography and Network Security (ACNS 2011),
Bruno Blanchet. An efficient cryptographic protocol verifier based
on prolog rules. In 14th IEEE workshop on Computer Security Foundations (CSFW 2001), pages 82–96. IEEE Computer Society, 2001.
Eric Blossom. Gnu radio: tools for exploring the radio frequency
spectrum. Linux journal, 2004(122):4, 2004.
Colin Boyd and Anish Mathuria. Protocols for authentication and
key establishment. Springer-Verlag, 2003.
Alex Biryukov, Sourav Mukhopadhyay, and Palash Sarkar. Improved
time-memory trade-offs with multiple data. In 12th International
Workshop on Selected Areas in Cryptography (SAC 2005), volume
Andrey Bogdanov. Attacks on the KeeLoq block cipher and authentication systems. In 3rd Conference on RFID Security (RFIDSec
2007), volume 2007, 2007.
Andrey Bogdanov. Cryptanalysis of the KeeLoq block cipher. IACR
Cryptology ePrint Archive, 2007:55, 2007.
Andrey Bogdanov. Linear slide attacks on the KeeLoq block cipher.
In 3rd International Conference on Information Security and Cryptology (INSCRYPT 2007), volume 4990 of Lecture Notes in Computer
Science, pages 66–80. Springer, 2007.
216
[BP08]
(65)
[BPVV98]
(66)
[BS76]
(67)
[BS91]
(68)
[BS93]
(69)
[BS97]
(70)
[BS99]
(71)
[BS00]
(72)
[BSW01]
(73)
[BvDKM13]
(74)
[BVvE13]
(75)
Bibliography
Andrey Bogdanov and Christof Paar. On the security and efficiency
of real-world lightweight authentication protocols. In 1st Workshop on Secure Component and System Identification (SECSI 2008).
ECRYPT, 2008.
Johan Borst, Bart Preneel, Joos Vandewalle, and Joos V. On the
time-memory tradeoff between exhaustive key search and table precomputation. In 19th Symposium in Information Theory in the
Benelux, pages 111–118, 1998.
Jon Louis Bentley and Michael Ian Shamos. Divide-and-conquer in
multidimensional space. In 8th ACM Symposium on Theory of Computing (STOC 2013), pages 220–230. ACM, 1976.
Eli Biham and Adi Shamir. Differential cryptanalysis of DES-like
cryptosystems. Journal of Cryptology, 4(1):3–72, 1991.
Eli Biham and Adi Shamir. Differential cryptanalysis of the Data
Encryption Standard, volume 28. Springer-Verlag, 1993.
Eli Biham and Adi Shamir. Differential fault analysis of secret key
cryptosystems. In 17th International Cryptology Conference, Advances in Cryptology (CRYPTO 1997), volume 1294 of Lecture Notes
in Computer Science, pages 513–525. Springer-Verlag, 1997.
Alex Biryukov and Adi Shamir. Real time cryptanalysis of the alleged
A5/1 on a PC, 1999.
Alex Biryukov and Adi Shamir. Cryptanalytic time/memory/data
tradeoffs for stream ciphers. In 6th International Conference on the
Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2000), volume 1976 of Lecture
Alex Biryukov, Adi Shamir, and David Wagner. Real time cryptanalysis of A5/1 on a PC. In 8th International Workshop on Fast
Software Encryption (FSE 2000), volume 1978 of Lecture Notes in
Computer Science, pages 1–18. Springer-Verlag, 2001.
Victor Bos, Ton van Deursen, Piotr Kordy, and Sjouke Mauw. Alatex
macro package for message sequence charts. Describing MSC macro
package version 2.0, April 2013. Université du Luxembourg.
Willem Burgers, Roel Verdult, and Marko van Eekelen. Prevent session hijacking by binding the session to the cryptographic network
credentials. In 18th Nordic Conference on Secure IT Systems (NordSec 2013), volume 8208 of Lecture Notes in Computer Science, pages
Bibliography
[BW99]
(76)
[C+ 06]
(77)
[C+ 07]
(78)
[CBW08]
(79)
[CC90]
(80)
[CCC+ 09]
(81)
[CCCS92]
(82)
[CDMP05]
(83)
[CF08]
(84)
217
Alex Biryukov and David Wagner. Slide attacks. In 6th International
Workshop on Fast Software Encryption (FSE 1999), volume 1636 of
1999.
Rafik Chaabouni et al. Break WEP faster with statistical analysis.
Technical report, technical report, EPFL, LASEC, 2006.
LAN/MAN Committee et al. IEEE standard for information technology - telecommunications and information exchange between systems
- local and metropolitan area networks - specific requirements part
11: Wireless LAN medium access control (MAC) and physical layer
(PHY) specifications (IEEE Std 802.11-2007), 2007.
Nicolas T. Courtois, Gregory V. Bard, and David Wagner. Algebraic
and slide attacks on KeeLoq. In 15th International Workshop on
Fast Software Encryption (FSE 2008), volume 5086 of Lecture Notes
Elliot J Chikofsky and James H Cross. Reverse engineering and design
recovery: A taxonomy. Software, IEEE, 7(1):13–17, 1990.
Chun-Chieh Chen, Inn-Tung Chen, Chen-Mou Cheng, Ming-Yang
Chih, and Jie-Ren Shih. A practical experience with RFID security.
In 10th International Conference on Mobile Data Management: Systems, Services and Middleware (MDM 2009), pages 395–396. IEEE
Paul Camion, Claude Carlet, Pascale Charpin, and Nicolas Sendrier.
On correlation-immune functions. In 11th International Cryptology
Conference, Advances in Cryptology (CRYPTO 1991), volume 576 of
1992.
Jean-Sébastien Coron, Yevgeniy Dodis, Cécile Malinaud, and
Prashant Puniya. Merkle-damg˚
ard revisited: How to construct a hash
function. In 25th International Cryptology Conference, Advances in
Cryptology (CRYPTO 2005), volume 3621 of Lecture Notes in Computer Science, pages 430–448. Springer-Verlag, 2005.
Claude Carlet and Keqin Feng. An infinite class of balanced functions
with optimal algebraic immunity, good immunity to fast algebraic
attacks and good nonlinearity. In 14th International Conference on
the Theory and Application of Cryptology and Information Security,
Advances in Cryptology (ASIACRYPT 2008), volume 5350 of Lecture
218
[CG95]
(85)
[CG12]
(86)
[CGD96]
(87)
[CGE12]
(88)
[CGY08]
(89)
[Cif94]
(90)
[CJS01]
(91)
[CKBR06]
(92)
[CKY89]
(93)
[Cla04]
(94)
Bibliography
Cristina Cifuentes and K John Gough. Decompilation of binary programs. Software: Practice and Experience, 25(7):811–829, 1995.
Qi Chai and Guang Gong. BUPLE: securing passive RFID communication through physical layer enhancements. In 7th International
Workshop on RFID Security and Privacy (RFIDSec 2011), pages
Andrew Clark, Jovan Dj Golić, and Ed Dawson. A comparison of fast
correlation attacks. In 3rd International Workshop on Fast Software
Qi Chai, Guang Gong, and Daniel Engels.
How to develop
clairaudience-active eavesdropping in passive RFID systems. In 13th
IEEE International Symposium on a World of Wireless, Mobile and
Multimedia Networks (WoWMoM 2012), pages 1–6. IEEE Computer
Society, 2012.
Luo Chunyu, Deng Guishi, and Guo Yanhong. Copyright protection model of embedded systems and its application in digital tv settop-box. In Computational Intelligence and Design (ISCID 2008),
volume 2, pages 130–133. IEEE Computer Society, 2008.
Cristina Cifuentes. Reverse compilation techniques. PhD thesis,
Queensland University of Technology, School of Computing Science,
1994.
Vladimor V Chepyzhov, Thomas Johansson, and Ben Smeets. A
simple algorithm for fast correlation attacks on stream ciphers. In
7th International Workshop on Fast Software Encryption (FSE 2000),
Glenn Carl, George Kesidis, Richard R Brooks, and Suresh Rai.
Denial-of-Service attack-detection techniques. Internet Computing,
10(1):82–89, 2006.
John F Canny, Erich Kaltofen, and Lakshman Yagati. Solving systems of nonlinear polynomial equations faster. In 2nd International
Symposium on Symbolic and Algebraic Computation (ISSAC 1989),
pages 121–128. ACM, 1989.
Christophe Clavier. Side channel analysis for reverse engineering
(scare) - an improved attack against a secret A3/A8 gsm algorithm.
IACR Cryptology ePrint Archive, 2004, 2004.
Bibliography
[Cla07]
(95)
[CM03]
(96)
[CMK+ 11]
(97)
[CNO08]
(98)
[Cop94]
(99)
[COQ09]
(100)
[Cor99]
(101)
[Cou03a]
(102)
[Cou03b]
(103)
219
Christophe Clavier. An improved SCARE cryptanalysis against a secret A3/A8 GSM algorithm. In 3rd Conference on Information Systems Security (ICISS 2007), volume 4812 of Lecture Notes in Computer Science, pages 143–155. Springer-Verlag, 2007.
Nicolas T Courtois and Willi Meier. Algebraic attacks on stream
ciphers with linear feedback. In 22nd International Conference on
the Theory and Application of Cryptographic Techniques, Advances
in Cryptology (EUROCRYPT 2003), volume 2656 of Lecture Notes
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis,
Franziska Roesner, and Tadayoshi Kohno. Comprehensive experimental analyses of automotive attack surfaces. In 20th USENIX Security Symposium (USENIX Security 2011), pages 77–92. USENIX
Association, 2011.
Nicolas Courtois, Karsten Nohl, and Sean O’Neil. Algebraic attacks
on the crypto-1 stream cipher in MIFARE Classic and oyster cards.
IACR Cryptology ePrint Archive, 2008:166, 2008.
Don Coppersmith. The data encryption standard (DES) and its
strength against attacks. IBM journal of research and development,
38(3):243–250, 1994.
Nicolas T. Courtois, Sean O’Neil, and Jean-Jacques Quisquater.
Practical algebraic attacks on the Hitag2 stream cipher. In 12th
Information Security Conference (ISC 2009), volume 5735 of Lecture
Jean-Sébastien Coron. Resistance against differential power analysis for elliptic curve cryptosystems. In 1st International Workshop
Nicolas T Courtois. Fast algebraic attacks on stream ciphers with
linear feedback. In 23rd International Cryptology Conference, Advances in Cryptology (CRYPTO 2003), volume 2729 of Lecture Notes
Nicolas T Courtois. Higher order correlation attacks, xl algorithm
and cryptanalysis of toyocrypt. In 5th International Conference on
Information Security and Cryptology (ICISC 2002), volume 2587 of
2003.
220
[Cou05]
(104)
[Cou09]
(105)
[CP02]
(106)
[CS91]
(107)
[CS05]
(108)
[CSY+ 10]
(109)
[Cum03]
Bibliography
Nicolas T Courtois. Algebraic attacks on combiners with memory
and several outputs. In 11th International Conference on Information
Security and Cryptology (ICISC 2008), volume 3506 of Lecture Notes
Nicolas T. Courtois. The dark side of security by obscurity - and
cloning MIFARE Classic rail and building passes, anywhere, anytime. In 4th International Conference on Security and Cryptography
(SECRYPT 2009), pages 331–338. INSTICC Press, 2009.
Nicolas T Courtois and Josef Pieprzyk. Cryptanalysis of block ciphers
with overdefined systems of equations. In 8th International Conference on the Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2002), volume
Vladimir Chepyzhov and Ben Smeets. On a fast correlation attack
on certain stream ciphers. In 10th International Conference on the
Theory and Application of Cryptographic Techniques, Advances in
Cryptology (EUROCRYPT 1991), volume 547 of Lecture Notes in
David Clark and Kevin Simmons. A dynamic 2D laser mark. Industrial Laser Solutions For Manufacturing, 20(8):19, 2005.
Ming-Yang Chih, Jie-Ren Shih, Bo-Yin Yang, Jintai Ding, and ChenMou Cheng. Mifare classic: Practical attacks and defenses. In 20th
Cryptology and Information Security Conference (CISC 2010). Chinese Cryptology and Information Security Association, 2010.
Nathan Cummings. iClass levels of security, April 2003.
(110)
[Cum06]
(111)
[CV95]
(112)
[CW02]
(113)
Nathan Cummings. Sales training. Slides from HID Technologies,
March 2006.
Florent Chabaud and Serge Vaudenay. Links between differential
and linear cryptanalysis. In 13th International Conference on the
Steve Christey and
nerability
disclosure
Chris Wysopal.
Responsible vulhttp://tools.ietf.org/html/
process.
draft-christey-wysopal-vuln-disclosure-00, 2002. RFC draft.
Bibliography
221
[CWHWW03] Nancy Cam-Winget, Russ Housley, David Wagner, and Jesse Walker.
(114)
Security flaws in 802.11 data link protocols. Communications of the
ACM, 46(5):35–39, 2003.
[DC94]
(115)
[DC06]
(116)
[DCJP01]
(117)
[DDMP04]
(118)
[DDSW11]
(119)
[Den82]
(120)
[DGB88]
(121)
[DH76]
(122)
[DH79]
(123)
[DHW+ 12]
(124)
Ed Dawson and Andrew Clark. Divide and conquer attacks on certain
classes of stream ciphers. Cryptologia, 18(1):25–40, 1994.
Christophe De Cannière. Trivium: A stream cipher construction
inspired by block cipher design principles. In 9th International Conference on Information Security (ISC 2006), volume 4176 of Lecture
Christophe De Canniere, Thomas Johansson, and Bart Preneel.
Cryptanalysis of the Bluetooth stream cipher. Technical report,
COSIC internal report, 2001.
Anupam Datta, Ante Derek, John C Mitchell, and Dusko Pavlovic.
Abstraction and refinement in protocol derivation. In 17th Computer
Security Foundations Workshop (CSFW 2004), pages 30–45. IEEE
Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and Marcel Winandy. Privilege escalation attacks on Android. In 13th Information Security Conference (ISC 2010), volume 6531 of Lecture
Dorothy Elizabeth Robling Denning. Cryptography and data security.
Addison-Wesley Longman Publishing Co., Inc., 1982.
Yvo Desmedt, Claude Goutier, and Samy Bengio. Special uses and
abuses of the fiat-shamir passport protocol. In 7th International
Cryptology Conference, Advances in Cryptology (CRYPTO 1987),
Whitfield Diffie and Martin E Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22(6):644–654,
1976.
Whitfield Diffie and Martin E Hellman. Privacy and authentication:
An introduction to cryptography. Proceedings of the IEEE, 67(3):397–
427, 1979.
Benedikt Driessen, Ralf Hund, Carsten Willems, Carsten Paar, and
Thorsten Holz. Don’t trust satellite phones: A security analysis of
two satphone standards. In 33rd IEEE Symposium on Security and
Privacy (S&P 2012), pages 128–142. IEEE Computer Society, 2012.
222
[Din94]
(125)
[Dip09]
(126)
[dKG08]
(127)
[dKG13]
(128)
[dKGdR12]
(129)
[dKGG10]
(130)
[dKGHG08]
(131)
[dKGV09]
(132)
[DKR97]
(133)
[DKS10]
(134)
Bibliography
Cunsheng Ding. The differential cryptanalysis and design of natural stream ciphers. In 1st International Workshop on Fast Software
Brian Dipert. The Zune HD: more than an iPod touch wanna-be?
Electrical Design News (EDN), page 20, October 2009.
Gerhard de Koning Gans. Analysis of the MIFARE Classic used
in the OV-chipkaart project. Master’s thesis, Radboud University
Nijmegen, 2008.
Gerhard de Koning Gans. Outsmarting Smart Cards. PhD thesis,
Radboud Universiteit Nijmegen, Nijmegen, Netherlands, April 2013.
Gerhard de Koning Gans and Joeri de Ruiter. The smartlogic tool:
Analysing and testing smart card protocols. In 5th International
Conference on Software Testing, Verification, and Validation (ICST
2012), pages 864–871. IEEE Computer Society, 2012.
Gerhard de Koning Gans and Flavio D. Garcia. Towards a practical
solution to the RFID desynchronization problem. In 6th Workshop
on RFID Security (RFIDSec 2010), volume 6370 of Lecture Notes in
Gerhard de Koning Gans, Jaap-Henk Hoepman, and Flavio D. Garcia. A practical attack on the MIFARE Classic. In 8th Smart Card
Research and Advanced Applications Conference (CARDIS 2008),
Gerhard de Koning Gans and Roel Verdult. Proxmark.org – A radio
frequency identification tool. http://www.proxmark.org, 2009. Research
and Developers Community.
Joan Daemen, Lars Knudsen, and Vincent Rijmen. The block cipher
Square. In 4th International Workshop on Fast Software Encryption (FSE 1997), volume 1267 of Lecture Notes in Computer Science,
Orr Dunkelman, Nathan Keller, and Adi Shamir. A practical-time
related-key attack on the KASUMI cryptosystem used in GSM and
3G telephony. In 30th International Cryptology Conference, Advances
in Cryptology (CRYPTO 2010), volume 6223 of Lecture Notes in
Bibliography
[DLMV05]
(135)
[DM95]
(136)
¨
[DMOPV07]
(137)
[DR98]
(138)
[DR02]
(139)
[DR11]
(140)
[DS08]
(141)
[DS09]
(142)
[DSP07]
(143)
[DST04]
(144)
[DTC
¸ B09]
(145)
223
Rémy Daudigny, Hervé Ledig, Frédéric Muller, and Frédéric Valette.
SCARE of the DES. In 3rd International Conference on Applied
Cryptography and Network Security (ACNS 2005), pages 393–406.
Donald Davies and Sean Murphy. Pairs and triplets of DES S-boxes.
Journal of Cryptology, 8(1):1–25, 1995.
¨
Elke De Mulder, Siddika Berna Ors,
Bart Preneel, and Ingrid Verbauwhede. Differential power and electromagnetic attacks on a FPGA
implementation of elliptic curve cryptosystems. Computers & Electrical Engineering, 33(5):367–382, 2007.
Joan Daemen and Vincent Rijmen. Aes proposal: Rijndael, 1998.
Joan Daemen and Vincent Rijmen. The Design of Rijndael: AES The Advanced Encryption Standard. Springer-Verlag, 2002.
Thai Duong and Juliano Rizzo. Here come the XOR Ninjas. White
paper, Netifera, May 2011.
H¨
useyin Demirci and Ali Aydın Sel¸cuk. A meet-in-the-middle attack
on 8-round AES. In 15th International Workshop on Fast Software
Itai Dinur and Adi Shamir. Cube attacks on tweakable black box
polynomials. In 28th International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2009), volume 5479 of Lecture Notes in Computer Science, pages 278–299. Springer-Verlag, 2009.
Orr Dunkelman, Gautham Sekar, and Bart Preneel. Improved meetin-the-middle attacks on reduced-round DES. In 8th International
Conference on Cryptology in India, Progress in Cryptology (INDOCRYPT 2007), volume 4859 of Lecture Notes in Computer Science, pages 86–100. Springer-Verlag, 2007.
H¨
useyin Demirci, Ali Aydin Sel¸cuk, and Erkan T¨
ure. A new meet-inthe-middle attack on the IDEA block cipher. In 10th International
˙
H¨
useyin Demirci, Ihsan
Ta¸skın, Mustafa C
¸ oban, and Adnan Baysal.
Improved meet-in-the-middle attacks on AES. In 10th International Conference on Cryptology in India, Progress in Cryptology
224
Bibliography
(INDOCRYPT 2009), volume 5922 of Lecture Notes in Computer
[DvE14]
(146)
[Dwo04]
(147)
[Dwo05]
(148)
[Dwo07]
(149)
[Dwy87]
(150)
[EG85]
(151)
[EJ03a]
(152)
[EJ03b]
(153)
[EKM+ 08]
(154)
[EM02]
(155)
[EMST78]
(156)
Hristo Dimitrov and Kim van Erkelens. Evaluation of the feasible
attacks against RFID tags for access control systems, 2014.
Morris Dworkin. Recommendation for block cipher modes of operation: The CCM mode for authentication and confidentiality. NIST
Special publication (800-38C), 38C:1–27, 2004.
Morris Dworkin. Recommendation for block cipher modes of operation: The CMAC mode for authentication. NIST Special Publication
(800-38B), 38B:1Ở25, 2005.
Morris Dworkin. Recommendation for block cipher modes of operation: Galois/counter mode (GCM) and GMAC. NIST Special
publication (800-38D), 38D:1–39, 2007.
Rex A Dwyer. A faster divide-and-conquer algorithm for constructing
delaunay triangulations. Algorithmica, 2(1-4):137–151, 1987.
Shimon Even and Oded Goldreich. On the power of cascade ciphers. ACM Transactions on Computer Systems (TOCS), 3(2):108–
116, 1985.
Patrik Ekdahl and Thomas Johansson. Another attack on A5/1.
IEEE Transactions on Information Theory, 49(1):284–289, 2003.
Patrik Ekdahl and Thomas Johansson. A new version of the stream
cipher SNOW. In 9th International Workshop on Selected Areas in
Thomas Eisenbarth, Timo Kasper, Amir Moradi, Christof Paar,
Mahmoud Salmasizadeh, and Mohammad T Manzuri Shalmani. On
the power of power analysis in the real world: A complete break of the
KeeLoq code hopping scheme. In 28th International Cryptology Conference, Advances in Cryptology (CRYPTO 2008), volume 5157 of
2008.
125khz crypto read/write contactless identification device, EM4170.
Product Datasheet, Mar 2002. EM Microelectronic-Marin SA.
William F Ehrsam, Carl HW Meyer, John L Smith, and Walter L
Tuchman. Message verification and transmission error detection by
block chaining. US Patent 4,074,066, Feb 1978.
Bibliography
[ETS08]
(157)
[ETS11]
(158)
[ETS12]
(159)
[FAH+ 10]
(160)
[FCC09]
(161)
[FDv11]
(162)
[FDW04]
(163)
[FGMR10]
(164)
[FHMM10]
(165)
[FHMM11]
(166)
225
Smart cards; UICC – contactless front-end (CLF) interface; host controller interface (hci) (ETSI TS 102 613), 2008. European Telecommunications Standards Institute (ETSI).
Smart cards; UICC – contactless front-end (CLF) interface; part 1:
Physical and data link layer characteristics (ETSI TS 102 613), 2011.
European Telecommunications Standards Institute (ETSI).
Universal mobile telecommunications system (UMTS); LTE; 3G security; specification of the 3GPP confidentiality and integrity algorithms; document 2: KASUMI specification (ETSI TS 135 202), 2012.
European Telecommunications Standards Institute (ETSI).
Martin Feldhofer, Manfred Josef Aigner, Michael Hutter, Thomas
Plos, Erich Wenger, and Thomas Baier. Semi-passive RFID development platform for implementing and attacking security tags. In 2nd
International Workshop on RFID/USN Security and Cryptography
(RISC 2010), pages 1–6. IEEE Computer Society, 2010.
Guidelines for evaluating the environmental effects of radio frequency
radiation, April 2009.
ˇ
Aurélien Francillon, Boris Danev, and Srdjan Capkun.
Relay attacks
on passive keyless entry and start systems in modern cars. In 18th
Network and Distributed System Security Symposium (NDSS 2011).
The Internet Society, 2011.
Martin Feldhofer, Sandra Dominikus, and Johannes Wolkerstorfer.
Strong authentication for RFID systems using the aes algorithm. In
6th International Workshop on Cryptographic Hardware and Embedded Systems (CHES 2004), pages 357–370. Springer-Verlag, 2004.
Renato Ferrero, Filippo Gandino, Bartolomeo Montrucchio, and
Maurizio Rebaudengo. Fair anti-collision protocol in dense RFID
networks. In 3rd International EURASIP Workshop on RFID Technology (EURASIP-RFID 2010), pages 101–105. IEEE Computer Society, 2010.
Lishoy Francis, Gerhard Hancke, Keith Mayes, and Konstantinos
Markantonakis. Practical nfc peer-to-peer relay attack using mobile phones. In Radio Frequency Identification: Security and Privacy
Issues, volume 6370 of Lecture Notes in Computer Science, pages
Lishoy Francis, Gerhard P Hancke, Keith Mayes, and Konstantinos
Markantonakis. Practical relay attack on contactless transactions by
using nfc mobile phones. IACR Cryptology ePrint Archive, 2011:618,
2011.
226
[FIP77]
(167)
[FIP93]
(168)
[FIP01]
(169)
[FIP08]
(170)
[FIP14]
(171)
[FJ03]
(172)
[FL01]
(173)
[FL12]
(174)
[Flu02]
(175)
[Fly08]
(176)
[FLZ+ 10]
(177)
Bibliography
PUB FIPS. Data encryption standard (DES). National Bureau of
Standards (NBS), 46(0), 1977.
PUB FIPS. Secure hash standard (SHS). National Institute for Standards and Technology (NIST), 180(0), 1993.
PUB FIPS. Advanced encryption standard (AES). National Institute
for Standards and Technology (NIST), 197(1), 2001.
PUB FIPS. The keyed-hash message authentication code (hmac). National Institute for Standards and Technology (NIST), 1:1Ở13, 2008.
PUB FIPS.
Secure hash algorithm-3 (SHA-3) standard:
Permutation-based hash and extendable-output functions. National
Institute for Standards and Technology (NIST), 202(0), 2014.
Jean-Charles Faugere and Antoine Joux. Algebraic cryptanalysis of
hidden field equation (hfe) cryptosystems using gröbner bases. In
23rd International Cryptology Conference, Advances in Cryptology
(CRYPTO 2003), volume 2729 of Lecture Notes in Computer Science,
Scott Fluhrer and Stefan Lucks. Analysis of the E0 encryption system. In 8th International Workshop on Selected Areas in Cryptography (SAC 2001), volume 2259 of Lecture Notes in Computer Science,
Riccardo Focardi and Flaminia L. Luccio. Secure recharge of disposable RFID tickets. In 8th International Workshop on Formal Aspects
of Security and Trust (FAST 2011), volume 7140 of Lecture Notes in
Scott Fluhrer. Improved key recovery of level 1 of the Bluetooth
encryption system. IACR Cryptology ePrint Archive, 2002(68):1–6,
2002.
Flylogic. Atmel CryptoMemory AT88SC153/1608 security alert. Retrieved from http://www.flylogic.net/blog/?p=25 on October 13th, 2009,
2008.
Xiutao Feng, Jun Liu, Zhaocun Zhou, Chuankun Wu, and Dengguo
Feng. A byte-based guess and determine attack on SOSEMANUK.
Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2010), volume 6477 of Lecture Notes in Computer Science,
Bibliography
[FMS01]
(178)
[FN91]
(179)
[FNS75]
(180)
[fSN97]
(181)
[GB06]
(182)
[GBM02]
(183)
[GBPV10]
(184)
227
Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the
key scheduling algorithm of RC4. In 8th International Workshop on
Selected Areas in Cryptography (SAC 2001), volume 2259 of Lecture
Amos Fiat and Moni Naor. Rigorous time/space tradeoffs for inverting functions. In Proceedings of the twenty-third annual ACM
symposium on Theory of computing, pages 534–541. ACM, 1991.
Horst Feistel, William A Notz, and J Lynn Smith. Some cryptographic techniques for machine-to-machine data communications.
Proceedings of the IEEE, 63(11):1545–1554, 1975.
National Institute for Standards and Technology (NIST). Announcing request for candidate algorithm nominations for the advanced
encryption standard (AES). Federal Register, 62(177):48051Ở–48058,
1997.
Bill Glover and Himanshu Bhatt. RFID essentials. O’Reilly Media,
Inc., 2006.
Jovan Dj Golić, Vittorio Bagini, and Guglielmo Morgari. Linear
cryptanalysis of Bluetooth stream cipher. In 21st International Conference on the Theory and Application of Cryptographic Techniques,
Advances in Cryptology (EUROCRYPT 2002), volume 2332 of Lecture Notes in Computer Science, pages 238–255. Springer-Verlag,
2002.
Benedikt Gierlichs, Lejla Batina, Bart Preneel, and Ingrid Verbauwhede. Revisiting higher-order DPA attacks. In 10th Cryptographers’ Track at the RSA Conference, Topics in Cryptology (CT-RSA
[GdKGM+ 08] Flavio D. Garcia, Gerhard de Koning Gans, Ruben Muijrers, Peter
(185)
van Rossum, Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs. Dismantling MIFARE Classic. In 13th European Symposium
on Research in Computer Security (ESORICS 2008), volume 5283 of
2008.
[GdKGV11]
(186)
Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Exposing iClass key diversification. In 5th USENIX Workshop on Offensive
Technologies (WOOT 2011), pages 128–136. USENIX Association,
2011.
228
[GdKGV12]
(187)
[GdKGV14]
(188)
Bibliography
Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Tutorial: Proxmark, the swiss army knife for RFID security research.
Technical report, Radboud University Nijmegen, 2012.
Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Wirelessly lockpicking a smart card reader. International Journal of Information Security, pages 1–18, 2014.
[GdKGVM12] Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, and
(189)
Milosch Meriac. Dismantling iClass and iClass Elite. In 17th European Symposium on Research in Computer Security (ESORICS
[GFMR11]
(190)
[GGvR08]
(191)
[GH05]
(192)
[GKVW05]
(193)
[GL02]
(194)
[GLRW10]
(195)
Filippo Gandino, Renato Ferrero, Bartolomeo Montrucchio, and
Maurizio Rebaudengo. Probabilistic DCS: An RFID reader-to-reader
anti-collision protocol. Journal of Network and Computer Applications, 34(3):821–832, 2011.
David Galindo, Flavio D. Garcia, and Peter van Rossum. Computational soundness of non-malleable commitments. In 4th Information
Security Practice and Experience Conference (ISPEC 2008), volume
Flavio D. Garcia and Jaap-Henk Hoepman. Off-line karma: A decentralized currency for peer-to-peer and grid applications. In 3th
Applied Cryptography and Network Security (ACNS 2005), volume
Marcin Gomulkiewicz, Miroslaw Kutylowski, Heinrich Theodor Vierhaus, and Pawel Wla´z. Synchronization fault cryptanalysis for breaking A5/1. In 4th International Workshop on Experimental and Efficient Algorithms (WEA 2005), volume 3503 of Lecture Notes in
Lawrence A Gordon and Martin P Loeb. The economics of information security investment. ACM Transactions on Information and
System Security (TISSEC), 5(4):438–457, 2002.
Jian Guo, San Ling, Christian Rechberger, and Huaxiong Wang. Advanced meet-in-the-middle preimage attacks: First results on full
Tiger, and improved results on MD4 and SHA-2. In 16th International Conference on the Theory and Application of Cryptology and
Information Security, Advances in Cryptology (ASIACRYPT 2010),
Bibliography
229
[GM04]
(196)
[GMO01]
(197)
[GMPS14]
(198)
[GNR08]
(199)
[Gol67]
(200)
[Gol96]
(201)
[Gol97a]
(202)
[Gol97b]
(203)
[Gou02]
(204)
Praveen S Gauravaram and William L Millan. Improved attack on
the cellular authentication and voice encryption algorithm (CAVE).
In Cryptographic Algorithms and their Uses (CAU 2004), pages 1–13.
Queensland University of Technology, 2004.
Karine Gandolfi, Christophe Mourtel, and Francis Olivier. Electromagnetic analysis: Concrete results. In 3rd International Workshop
Sourav Sen Gupta, Subhamoy Maitra, Goutam Paul, and Santanu
Sarkar. (non-) random sequences from (non-) random permutations
Ợ analysis of RC4 stream cipher. Journal of Cryptology, 27(1):67–
108, 2014.
Timo Gendrullis, Martin Novotnỳ, and Andy Rupp. A real-world
attack breaking A5/1 within hours. In 10th International Workshop
S.W. Golomb. Shift Register Sequences. Holden-Day Series in Information Systems. Holden-Day, 1967.
Jovan Dj Golić. On the security of nonlinear filter generators. In 3rd
Jovan Dj. Golić. Cryptanalysis of alleged A5 stream cipher. In 16th
International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 1997),
Jovan Dj. Golić. Linear statistical weakness of alleged RC4 keystream
generator. In 16th International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 1997), volume 1233 of Lecture Notes in Computer Science,
Louis Goubin. A refined power-analysis attack on elliptic curve cryptosystems. In 6th International Workshop on Theory and Practice in
230
Bibliography
Public Key Cryptography (PKC 2003), volume 2567 of Lecture Notes
[GR05]
(205)
[Gra02]
(206)
[Gro71]
(207)
[GS07]
(208)
[GST13]
(209)
[GvR06a]
(210)
[GvR06b]
(211)
[GvR08]
(212)
[GvR10]
(213)
[GVRS07]
(214)
Simson Garfinkel and Beth Rosenberg. RFID: Applications, Security,
And Privacy. Addison-Wesley Publishing Company Incorporated,
2005.
Louis Granboulan. Flaws in differential cryptanalysis of Skipjack. In
8th International Workshop on Fast Software Encryption (FSE 2001),
El Groth. Generation of binary sequences with controllable complexity. IEEE Transactions on Information Theory, 17(3):288–296, 1971.
Gary M. Gaukler and Ralf W. Seifert. Applications of RFID in supply
chains. In Trends in supply chain design and management, pages 29–
48. Springer, 2007.
Daniel Genkin, Adi Shamir, and Eran Tromer. RSA key extraction
via low - bandwidth acoustic cryptanalysis. IACR Cryptology ePrint
Archive, 2013(857):1Ợ57, 2013.
Flavio D. Garcia and Peter van Rossum. Sound computational interpretation of formal hashes. Technical Report ICIS-R06001, Institute
for Computing and Information Sciences, Radboud University Nijmegen, 2006.
Flavio D. Garcia and Peter van Rossum. Sound computational interpretation of symbolic hashes in the standard model. In 1st International Workshop on Security, Advances in Information and Computer
Security (IWSEC 2006), volume 4266 of Lecture Notes in Computer
Flavio D. Garcia and Peter van Rossum. Sound and complete computational interpretation of symbolic hashes in the standard model.
Theoretical Computer Science, 394(1–2):112–133, 2008.
Flavio D. Garcia and Peter van Rossum. Modeling privacy for off-line
RFID systems. In 9th Smart Card Research and Advanced Applications (CARDIS 2010), volume 6035 of Lecture Notes in Computer
Flavio D Garcia, Peter Van Rossum, and Ana Sokolova. Probabilistic
anonymity and admissible schedulers. CoRR, abs/0706.1019, 2007.
Bibliography
231
[GvRVWS09] Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wich(215)
ers Schreur. Wirelessly pickpocketing a MIFARE Classic card. In
30th IEEE Symposium on Security and Privacy (S&P 2009), pages
3–15. IEEE Computer Society, 2009.
[GvRVWS10] Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wich(216)
ers Schreur. Dismantling SecureMemory, CryptoMemory and CryptoRF. In 17th ACM Conference on Computer and Communications
Security (CCS 2010), pages 250–259. ACM, 2010.
[HA03]
(217)
[Han05]
(218)
[Han06]
(219)
[HCJ02]
(220)
[Hel80]
(221)
[Hen11]
(222)
[HHBR+ 08]
(223)
[HHJ+ 06]
(224)
Russ Housley and William Arbaugh. Security problems in 802.11based networks. Communications of the ACM, 46(5):31–34, 2003.
Gerhard P. Hancke. A practical relay attack on ISO 14443 proximity
cards. Technical report, University of Cambridge Computer Laboratory, 2005.
Gerhard P. Hancke. Practical attacks on proximity identification
systems (short paper). In 27th IEEE Symposium on Security and
Shai Halevi, Don Coppersmith, and Charanjit Jutla. Scream: A
software-efficient stream cipher. In 9th International Workshop on
Martin E. Hellman. A cryptanalytic time-memory trade-off. IEEE
Transactions on Information Theory, 26(4):401–406, 1980.
Martin Henzl. Security of contactless smart cards. In 17th annual
student conference and competition STUDENT EEICT 2011, pages
585–589. Faculty of Information Technology BUT, 2011.
Daniel Halperin, Thomas S. Heydt-Benjamin, Benjamin Ransford,
Shane S. Clark, Benessa Defend, Will Morgan, Kevin Fu, Tadayoshi
Kohno, and William H. Maisel. Pacemakers and implantable cardiac
defibrillators: Software radio attacks and zero-power defenses. In
29th IEEE Symposium on Security and Privacy (S&P 2008), pages
Jaap-Henk Hoepman, Engelbert Hubbers, Bart Jacobs, Martijn Oostdijk, and RonnyWichers Schreur. Crossing borders: Security and
privacy issues of the european e-passport. In 1st International Workshop on Security, Advances in Information and Computer Security
(IWSEC 2006), volume 4266 of Lecture Notes in Computer Science,
232
[HHJK12]
(225)
[HID06]
(226)
[HID08]
Bibliography
Martin Henzl, Petr Hanacek, Peter Jurnecka, and Matej Kacic. A
concept of automated vulnerability search in contactless communication applications. In 46th Annual IEEE International Carnahan
Conference on Security Technology (ICCST 2012), pages 180–186.
IEEE Computer Society, 2012.
HID Global. HID management key letter, November 2006.
(227)
13.56 MHz contactless iClass card. Product Features and Specifications, October 2008. HID Global.
[HID09]
HID Global. iClass RW100, RW150, RW300, RW400 readers, 2009.
(228)
[Hil29]
(229)
[Hil31]
(230)
[HJM07]
(231)
[HJSW06]
(232)
[HK05]
(233)
[HM13]
(234)
[HMM09]
(235)
[HN00]
(236)
[Hou73]
(237)
Lester S. Hill. Cryptography in an algebraic alphabet. American
Mathematical Monthly, 36(6):306–312, 1929.
Lester S Hill. Concerning certain linear transformation apparatus
of cryptography. American Mathematical Monthly, pages 135–154,
1931.
Martin Hell, Thomas Johansson, and Willi Meier. Grain: a stream cipher for constrained environments. International Journal of Wireless
and Mobile Computing, 2(1):86–93, 2007.
John Halamka, Ari Juels, Adam Stubblefield, and Jonathan Westhues. The security implications of VeriChip cloning. Journal of the
American Medical Informatics Association, 13(6):601–607, 2006.
Gerhard P Hancke and Markus G Kuhn. An RFID distance bounding
protocol. In 1st International Conference on Security and Privacy for
Emerging Areas in Communications Networks (SecureComm 2005),
pages 67–73. IEEE Computer Society, 2005.
Jin Hong and Sunghwan Moon. A comparison of cryptanalytic tradeoff algorithms. Journal of Cryptology, 26(4):559–637, 2013.
Gerhard P Hancke, KE Mayes, and Konstantinos Markantonakis.
Confidence in smart token proximity: Relay attacks revisited. Computers & Security, 28(7):615–627, 2009.
M. Hermelin and K. Nyberg. Correlation properties of the Bluetooth
combiner. In 2nd Information Security and Cryptology (ICISC 1999),
Barron Cornelius Housel. A Study of Decompiling Machine Language
into High-Level Machine Independent Languages. PhD thesis, Purdue
University, Computer Science, 1973.
Bibliography
[HP00]
(238)
[HR00]
(239)
[HR03]
(240)
[HSH+ 08]
(241)
[HSH+ 09]
(242)
[HTTN88]
233
Helena Handschuh and Pascal Paillier. Reducing the collision probability of alleged Comp128. In 3rd Smart Card Research and Advanced
Applications Conference (CARDIS 1998), volume 1820 of Lecture
Philip Hawkes and Gregory G Rose. Exploiting multiples of the connection polynomial in word-oriented stream ciphers. In 6th International Conference on the Theory and Application of Cryptology and
Information Security, Advances in Cryptology (ASIACRYPT 2000),
Philip Hawkes and Gregory G Rose. Guess-and-determine attacks on
SNOW. In 9th International Workshop on Selected Areas in Cryptography (SAC 2002), volume 2595 of Lecture Notes in Computer
J Alex Halderman, Seth D Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A Calandrino, Ariel J Feldman, Jacob
Appelbaum, and Edward W Felten. Lest we remember: cold-boot
attacks on encryption keys. In 17th USENIX Security Symposium
(USENIX Security 2008), pages 45–60. USENIX Association, 2008.
J Alex Halderman, Seth D Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A Calandrino, Ariel J Feldman, Jacob
Appelbaum, and Edward W Felten. Lest we remember: cold-boot
attacks on encryption keys. Communications of the ACM, 52(5):91–
98, 2009.
(243)
Motoki Hirano, Mikio Takeuchi, Takahisa Tomoda, and Kin-Ichiro
Nakano. Keyless entry system with radio card transponder. IEEE
Transactions on Industrial Electronics, 35:208–216, 1988.
[IC04]
PicoPass 2KS. Product Datasheet, Nov 2004. Inside Contactless.
(244)
[ICA03]
(245)
[IKD+ 08]
(246)
[INF07]
(247)
Machine readable travel documents, 2003. International Civil Aviation Organization (ICAO).
Sebastiaan Indesteege, Nathan Keller, Orr Dunkelmann, Eli Biham,
and Bart Preneel. A practical attack on KeeLoq. In 27th International
Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2008), volume 4965
2008.
Intelligent 10 kbit EEPROM, with contactless interface compliant to
ISO/IEC 15693, and ISO/IEC 18000-3 mode 1, and security logic,
234
Bibliography
SRF 55V10S. Short Product Information, Jul 2007. Infineon Technologies AG.
[IRMTT+ 10]
(248)
[ISO94]
(249)
[ISO96]
(250)
[ISO99]
(251)
[ISO00]
(252)
[ISO01]
(253)
[ISO04]
(254)
[ISO05]
(255)
[ISO07]
(256)
[ISO11]
(257)
Rob Millerb Ishtiaq Roufa, Hossen Mustafaa, Sangho Ohb
Travis Taylora, Wenyuan Xua, Marco Gruteserb, Wade Trappeb, and
Ivan Seskarb. Security and privacy vulnerabilities of in-car wireless
networks: A tire pressure monitoring system case study. In 19th
USENIX Security Symposium (USENIX Security 2010), pages 323–
338. USENIX Association, 2010.
Radio frequency identification of animals – code structure (ISO/IEC
11784), 1994. International Organization for Standardization (ISO).
Radio frequency identification of animals – technical concept
(ISO/IEC 11785), 1996. International Organization for Standardization (ISO).
Information technology – security techniques – entity authentication – part 2: Mechanisms using symmetric encipherment algorithms
(ISO/IEC 9798 part 2), 1999. International Organization for Standardization (ISO).
Identification cards – contactless integrated circuit(s) cards – vicinity
cards (ISO/IEC 15693), 2000. International Organization for Standardization (ISO).
Identification cards – contactless integrated circuit cards – proximity
cards (ISO/IEC 14443), 2001. International Organization for Standardization (ISO).
Information technology – telecommunications and information exchange between systems – near field communication interface and
protocol 1 (NFCIP-1) (ISO/IEC 18092), 2004. International Organization for Standardization (ISO).
Information technology – telecommunications and information exchange between systems – near field communication interface and
protocol 2 (NFCIP-2) (ISO/IEC 21481), 2005. International Organization for Standardization (ISO).
Information technology – telecommunications and information exchange between systems – near field communication wired interface
(NFC-WI) (ISO/IEC 28361), 2007. International Organization for
Standardization (ISO).
Information technology – telecommunications and information exchange between systems – front-end configuration command for
Bibliography
235
(NFC-FEC) (ISO/IEC 16353), 2011. International Organization for
Standardization (ISO).
[Jar04]
(258)
[JIC05]
(259)
[JJ00]
(260)
[JJ02]
(261)
[JLR+ 13]
(262)
[Jon03]
(263)
[JS97]
(264)
[Jue06]
(265)
[JWS11]
(266)
[KA09]
(267)
Mary Jarboe. Introduction to CryptoMemory. Atmel Applications
Journal, 3:28, 2004.
Specification of implementation for integrated circuit(s) cards (JICSAP/JSA JIS X 6319), 2005. Japan IC Card System Application
Council (JICSAP).
Thomas Johansson and Fredrik Jönsson. Fast correlation attacks
through reconstruction of linear polynomials. In 20th International
Fredrik Jönsson and Thomas Johansson. A fast correlation attack on
lili-128. Information Processing Letters, 81(3):127–132, 2002.
Keting Jia, Leibo Li, Christian Rechberger, Jiazhe Chen, and Xiaoyun Wang. Improved cryptanalysis of the block cipher KASUMI.
In 19th International Conference on Selected Areas in Cryptography
(SAC 2012), volume 7707 of Lecture Notes in Computer Science,
Jakob Jonsson. On the security of CTR + CBC-MAC. In 9th International Workshop on Selected Areas in Cryptography (SAC 2002),
Norman D. Jorstad and Landgrave T. Smith. Cryptographic algorithm metrics. In 20th National Information Systems Security
Conference. National Institute of Standards and Technology (NIST),
1997.
Ari Juels. RFID security and privacy: A research survey. IEEE
Journal on Selected Areas in Communications, 24(2):381–394, 2006.
Bart Jacobs and Ronny Wichers Schreur. Logical formalisation and
analysis of the MIFARE Classic card in PVS. In 2nd International
Conference on Interactive Theorem Proving, volume 6898 of Lecture
Chong Hee Kim and Gildas Avoine. RFID distance bounding protocol with mixed challenges to prevent relay attacks. In 8th International Conference on Cryptology and Network Security (CANS 2009),
236
[KAK+ 09]
(268)
[KCP07]
(269)
[KCR+ 10]
(270)
[Ken77]
(271)
[Ker83]
(272)
[Kes00]
(273)
[Key76]
(274)
[Key12]
Bibliography
Chong Hee Kim, Gildas Avoine, Fran¸cois Koeune, Fran¸cois-Xavier
Standaert, and Olivier Pereira. The swiss-knife RFID distance bounding protocol. In 11th International Conference on Information Security and Cryptology (ICISC 2008), volume 5461 of Lecture Notes in
Timo Kasper, Dario Curluccio, and Christof Paar. An embedded system for practical security analysis of contactless smartcards. In Workshop in Information Security Theory and Practice (WISTP 2007),
Karl Koscher, Alexei Czeskis, Franziska Roesner, Franziska Patel,
Tadayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor,
Danny Anderson, Hovav Shacham, and Stefan Savage. Experimental
security analysis of a modern automobile. In 31rd IEEE Symposium
on Security and Privacy (S&P 2010), pages 447–462. IEEE Computer
Society, 2010.
Stephen Thomas Kent. Encryption-based protection for interactive
user/computer communication. In 5th Symposium on Data Communications (SIGCOMM 1977), pages 5–7. ACM, 1977.
Auguste Kerckhoffs. La cryptographie militaire. Journal des Sciences
Militaires, 9(1):5–38, 1883.
Gregory Kesden. Content scrambling system (CSS), 2000. Carnegie
Mellon University.
Edwin Key. An analysis of the structure and complexity of nonlinear binary sequence generators. IEEE Transactions on Information
Theory, 22(6):732–736, 1976.
Keyline. Transponder guide.
2012.
http://www.keyline.it/files/884/transponder_
(275)
guide_16729.pdf ,
[KJJ99]
Paul Kocher, Joshua Jaffe, and Benjamin Jun. Differential power
analysis. In 19th International Cryptology Conference, Advances in
Cryptology (CRYPTO 1999), volume 1666 of Lecture Notes in Computer Science, pages 388–397. Springer-Verlag, 1999.
(276)
[KJJR11]
(277)
Paul Kocher, Joshua Jaffe, Benjamin Jun, and Pankaj Rohatgi. Introduction to differential power analysis. Journal of Cryptographic
Engineering, 1(1):5–27, 2011.
Bibliography
[KJL+ 13]
(278)
[KKMP09]
(279)
[Kle08]
(280)
[KM05]
(281)
[Koc96]
(282)
[KP09]
(283)
[KPP+ 06]
(284)
[KPPM12]
(285)
[Kra01]
(286)
237
ChangKyun Kim, Eun-Gu Jung, Dong Hoon Lee, Chang-Ho Jung,
and Daewan Han. Cryptanalysis of INCrypt32 in HID’s iClass systems. IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, 96(1):35–41, 2013.
Markus Kasper, Timo Kasper, Amir Moradi, and Christof Paar.
Breaking KeeLoq in a flash: on extracting keys at lightning speed.
In 2nd International Conference on Cryptology in Africa, Progress in
Cryptology (AFRICACRYPT 2009), volume 5580 of Lecture Notes in
Andreas Klein. Attacks on the RC4 stream cipher. Designs, Codes
and Cryptography, 48(3):269–286, 2008.
Michael Knebelkamp and Herbert Meier. Latest generation technology for immobiliser systems. Elektron, 13(2):22–25, 2005.
Paul C Kocher. Timing attacks on implementations of Diffie-Hellman,
RSA, DSS, and other systems. In 16th International Cryptology Conference, Advances in Cryptology (CRYPTO 1996), volume 1109 of
1996.
Jongsung Kim and Raphael Chung-Wei Phan. Advanced differentialstyle cryptanalysis of the NSA’s skipjack block cipher. Cryptologia,
33(3):246–270, 2009.
Sandeep Kumar, Christof Paar, Jan Pelzl, Gerd Pfeiffer, and Manfred Schimmler. Breaking ciphers with COPACOBANA—a costoptimized parallel code breaker. In 8th International Workshop on
Cryptographic Hardware and Embedded Systems (CHES 2006), volume 4249 of Lecture Notes in Computer Science, pages 101–118.
Maria Kalenderi, Dionisios Pnevmatikatos, Ioannis Papaefstathiou,
and Charalampos Manifavas. Breaking the GSM A5/1 cryptography
algorithm with rainbow tables and high-end FPGAS. In 22nd International Conference on Field Programmable Logic and Applications
(FPL 2012), pages 747–753. IEEE Computer Society, 2012.
Hugo Krawczyk. The order of encryption and authentication for protecting communications (or: How secure is SSL?). In 21st International Cryptology Conference, Advances in Cryptology (CRYPTO
238
[Kra02]
(287)
[KRW99]
(288)
[KSB08]
(289)
[KSP10]
(290)
[KSRW04]
(291)
[KSW97]
(292)
[KSW99]
(293)
[Kuh88]
(294)
[KW05]
(295)
Bibliography
Matthias Krause. BDD-based cryptanalysis of keystream generators.
In 21st International Conference on the Theory and Application of
Cryptographic Techniques, Advances in Cryptology (EUROCRYPT
Lars R Knudsen, Matthew JB Robshaw, and David Wagner. Truncated differentials and skipjack. In 19th International Cryptology
of Lecture Notes in Computer Science, pages 165–180. SpringerVerlag, 1999.
M. Ayoub Khan, Manoj Sharma, and Prabhu R. Brahmanandha.
FSM based manchester encoder for UHF RFID tag emulator. In
17th International Conference on Computing, Communication and
Networking (ICCCn 2008), pages 1–6. IEEE Computer Society, 2008.
Timo Kasper, Michael Silbermann, and Christof Paar. All you can
eat or breaking a real-world contactless payment system. In 14th International Conference on Financial Cryptography and Data Security
(FC 2010), volume 6052 of Lecture Notes in Computer Science, pages
Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin, and Dan S.
Wallach. Analysis of an electronic voting system. In 25th IEEE
Symposium on Security and Privacy (S&P 2004), pages 27–40. IEEE
John Kelsey, Bruce Schneier, and David Wagner. Related-key cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X, NewDES, RC2, and
TEA. In 1st International Conference on Information and Communications Security (ICICS 1997), volume 1334 of Lecture Notes in
John Kelsey, Bruce Schneier, and David Wagner. Mod n cryptanalysis, with applications against RC5P and M6. In 6th International
1999.
GJ Kuhn. Algorithms for self-synchronizing ciphers. In 1st Southern African Conference on Communications and Signal Processing
(COMSIG 1988), pages 159–164. IEEE, 1988.
Ziv Kfir and Avishai Wool. Picking virtual pockets using relay attacks
on contactless smartcard. In 1st International Conference on Secu-
Bibliography
239
rity and Privacy for Emerging Areas in Communications Networks
(SecureComm 2005), pages 47–58. IEEE Computer Society, 2005.
[KW06]
(296)
[KWH99]
(297)
[LA+ 08]
(298)
[Lan01]
(299)
[LC
¸ A+ 04]
(300)
[LCPW01]
(301)
[LEG03]
(302)
[LEG06]
(303)
[LG98]
(304)
[LMM91]
(305)
Ilan Kirschenbaum and Avishai Wool. How to build a low-cost,
extended-range RFID skimmer. In 15th USENIX Security Symposium (USENIX Security 2006), pages 43–57. USENIX Association,
2006.
Paul D Kundarewich, Steven JE Wilton, and Alan J Hu. A CPLDbased RC4 cracking system. In IEEE Canadian Conference on Electrical and Computer Engineering, volume 1, pages 397–402. IEEE
Chein-Shan Liu, Satya N Atluri, et al. A novel time integration
method for solving a large system of non-linear algebraic equations.
Computer Modeling in Engineering & Sciences (CMES), 31(2):71–83,
2008.
Carl E Landwehr. Computer security. International Journal of Information Security, 1(1):3–13, 2001.
Albert Levi, Erhan C
¸ etinta¸s, Murat Aydos, C
¸ etin Kaya Ko¸c, and
M Ufuk C
¸ a˘
glayan. Relay attacks on bluetooth authentication and
solutions. In 19th International Symposium on Computer and Information Sciences (ISCIS 2004), pages 278–288. Springer-Verlag, 2004.
David P Leech, Michael W Chinworth, Gary G. Payne, and Christopher M. Waychoff. The economic impacts of NIST’s data encryption
standard (DES) program. Technical report, National Institute of
Standards and Technology (NIST), 2001.
LEGIC prime data media MIM256 and MIM1024. Public Datasheet,
Feb 2003. LEGIC Identsystems Ltd.
Frequently asked questions about LEGIC. LEGIC FAQ, Nov 2006.
LEGIC Identsystems Ltd.
Mike Loukides and John Gilmore, editors. Cracking DES: Secrets of
Encryption Research, Wiretap Politics and Chip Design. O’Reilly &
Associates, Inc., Sebastopol, CA, USA, 1998.
Xuejia Lai, James L Massey, and Sean Murphy. Markov ciphers and
differential cryptanalysis. In 10th International Conference on the
240
[LMV05]
(306)
[LS04]
(307)
[LSS05]
(308)
[LSS06]
(309)
[LST+ 09]
(310)
[LV04a]
(311)
[LV04b]
(312)
[LV08]
(313)
[LW05]
(314)
Bibliography
Yi Lu, Willi Meier, and Serge Vaudenay. The conditional correlation
attack: A practical attack on Bluetooth encryption. In 25th International Cryptology Conference, Advances in Cryptology (CRYPTO
Tom Lookabaugh and Douglas C Sicker. Security and lock-in. In
Economics of Information Security, pages 225–246. Springer-Verlag,
2004.
Kerstin Lemke, Ahmad-Reza Sadeghi, and Christian Stựble. An open
approach for designing secure electronic immobilizers. In Information Security Practice and Experience (ISPEC 2005), volume 3439 of
2005.
Kerstin Lemke, Ahmad-Reza Sadeghi, and Christian St¨
uble. Antitheft protection: Electronic immobilizers. Embedded Security in Cars,
pages 51–67, 2006.
Stefan Lucks, Andreas Schuler, Erik Tews, Ralf-Philipp Weinmann,
and Matthias Wenzel. Attacks on the DECT authentication mechanisms. In 9th Cryptographers’ Track at the RSA Conference, Topics
in Cryptology (CT-RSA 2009), volume 5473 of Lecture Notes in Computer Science, pages 48–65. Springer-Verlag, 2009.
Yi Lu and Serge Vaudenay. Cryptanalysis of Bluetooth keystream
generator two-level E0. In 10th International Conference on the
Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2004), volume 3329 of Lecture
Yi Lu and Serge Vaudenay. Faster correlation attack on Bluetooth
keystream generator E0. In 24th International Cryptology Conference, Advances in Cryptology (CRYPTO 2004), volume 3152 of Lecture Notes in Computer Science, pages 407–425. Springer-Verlag,
2004.
Yi Lu and Serge Vaudenay. Cryptanalysis of an E0-like combiner
with memory. Journal of Cryptology, 21(3):430–457, 2008.
Ophir Levy and Avishai Wool. Uniform framework for cryptanalysis
of the Bluetooth E0 cipher. In 1st International Conference on Security and Privacy for Emerging Areas in Communications Networks
(SecureComm 2005), pages 365–373. IEEE Computer Society, 2005.
Bibliography
[LXZ13]
(315)
[Man03]
(316)
[Man05a]
(317)
[Man05b]
(318)
[Mar57]
(319)
[Mat94]
(320)
[Mat97]
(321)
[MB01]
(322)
[MC01]
(323)
[McG02]
(324)
241
Jinlong Lu, Longsen Xu, and Maolin Zhang. Research on contactless
IC card simulation technology. In 3rd International Conference on
Information Engineering and Applications (IEA 2012), volume 216
of Lecture Notes in Electrical Engineering, pages 97–102. SpringerVerlag, 2013.
Stefan Mangard. A simple power-analysis (spa) attack on implementations of the aes key expansion. In 5th International Conference on
Information Security and Cryptology (ICISC 2002), volume 2587 of
2003.
Itsik Mantin. A practical attack on the fixed RC4 in the WEP mode.
Cryptology and Information Security, Advances in Cryptology (ASIACRYPT 2005), volume 3788 of Lecture Notes in Computer Science,
Itsik Mantin. Predicting and distinguishing attacks on RC4 keystream generator. In 24th International Conference on the Theory
and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2005), volume 3494 of Lecture Notes in Computer
Harry M Markowitz. The elimination form of the inverse and its
application to linear programming. Management Science, 3(3):255–
269, 1957.
Mitsuru Matsui. Linear cryptanalysis method for DES cipher. In 12th
International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 1993),
Mitsuru Matsui. New block encryption algorithm MISTY. In 4th
Sjouke Mauw and Victor Bos. Drawing Message Sequence Charts
with LATEX. TUGBoat, 22(1-2):87–92, March/June 2001.
KeeLoq crypto read/write transponder module, HCS410/WM. Product Datasheet, Jan 2001. Microchip Technology Incorporated.
David McGrew. Counter mode security: Analysis and recommendations. Cisco Systems, November, 2002.
242
[MDDR04]
(325)
[MDO94]
(326)
[MDS99]
(327)
[Mer10]
(328)
[Mes00]
(329)
[MH81]
(330)
[Mil01]
(331)
[Mir02]
(332)
[MJB05]
(333)
[MK08]
(334)
[MM93]
(335)
Bibliography
Jelena Mirkovic, Sven Dietrich, David Dittrich, and Peter Reiher.
Internet Denial of Service: Attack and Defense Mechanisms (Radia
Perlman Computer Networking and Security). Prentice Hall PTR,
2004.
William Millan, EP Dawson, and LJ O’Connor. Fast attacks on treestructured ciphers. In 1st Workshop in Selected Areas in Cryptography
(SAC 1994), pages 146–158, 1994.
Thomas S Messerges, Ezzy A Dabbish, and Robert H Sloan. Investigations of power analysis attacks on smartcards. In USENIX
workshop on Smartcard Technology. USENIX Association, 1999.
Milosch Meriac. Heart of darkness - exploring the uncharted backwaters of HID iClass security. In 27th Chaos Computer Congress
(27C3), December 2010.
Thomas S Messerges. Using second-order power analysis to attack
DPA resistant software. In 2nd International Workshop on Cryptographic Hardware and Embedded Systems (CHES 2000), volume
Ralph C Merkle and Martin E Hellman. On the security of multiple
encryption. Communications of the ACM, 24(7):465–467, 1981.
Sandra Kay Miller. Facing the challenge of wireless security. Computer, 34(7):16–18, 2001.
Ilya Mironov. (not so) random shuffles of RC4. In 22nd International
Alexander Maximov, Thomas Johansson, and Steve Babbage. An
improved correlation attack on A5/1. In 12th International Workshop on Selected Areas in Cryptography (SAC 2002), volume 3897
2005.
Alexander Maximov and Dmitry Khovratovich. New state recovery
attack on RC4. In 28th International Cryptology Conference, Advances in Cryptology (CRYPTO 2008), volume 5157 of Lecture Notes
Ueli M Maurer and James L Massey. Cascade ciphers: The importance of being first. Journal of Cryptology, 6(1):55–61, 1993.
Bibliography
[MOPS13]
(336)
[MOTW09]
(337)
[MPC04]
(338)
[MPG11]
(339)
[MPO05]
(340)
[MS88]
(341)
[MS89]
(342)
[MS00]
(343)
[MS02]
(344)
243
Amir Moradi, David Oswald, Christof Paar, and Pawel Swierczynski.
Side-channel attacks on the bitstream encryption mechanism of Altera Stratix II: facilitating black-box analysis using software reverseengineering. In International Symposium on Field Programmable
Gate Arrays (FPGA 2013), pages 91–100. ACM, 2013.
H Gregor Molter, Kei Ogata, Erik Tews, and Ralf-Philipp Weinmann.
An efficient FPGA implementation for an DECT brute-force attacking scenario. In 5th International Conference on Wireless and Mobile
Communications (ICWMC 2009), pages 82–86. IEEE Computer Society, 2009.
Willi Meier, Enes Pasalic, and Claude Carlet. Algebraic attacks and
decomposition of boolean functions. In 27th International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2004), volume 3027 of Lecture
Subhamoy Maitra, Goutam Paul, and Sourav Sen Gupta. Attack
on broadcast RC4 revisited. In 18th International Workshop on Fast
Stefan Mangard, Norbert Pramstaller, and Elisabeth Oswald. Successfully attacking masked AES hardware implementations. In 7th
International Workshop on Cryptographic Hardware and Embedded
Systems (CHES 2005), volume 3659 of Lecture Notes in Computer
Willi Meier and Othmar Staffelbach. Fast correlation attacks on
stream ciphers. In 7th International Conference on the Theory and
Application of Cryptographic Techniques, Advances in Cryptology
(EUROCRYPT 1988), volume 330 of Lecture Notes in Computer Science, pages 301–314. Springer-Verlag, 1988.
Willi Meier and Othmar Staffelbach. Fast correlation attacks on
certain stream ciphers. Journal of Cryptology, 1(3):159–176, 1989.
Rita Mayer-Sommer. Smartly analyzing the simplicity and the power
of simple power analysis on smartcards. In 2nd International Workshop on Cryptographic Hardware and Embedded Systems (CHES
Itsik Mantin and Adi Shamir. A practical attack on broadcast RC4.
In 8th International Workshop on Fast Software Encryption (FSE
244
Bibliography
[MSB+ 06]
(345)
[MSSS11]
(346)
[MT99]
(347)
[Mul56]
(348)
[Mul04]
(349)
[Mul09]
(350)
[MV04]
(351)
[MVOV10]
(352)
[NESP08]
(353)
[NFC06]
(354)
David Moore, Colleen Shannon, Douglas J Brown, Geoffrey M
Voelker, and Stefan Savage. Inferring internet denial-of-service activity. ACM Transactions on Computer Systems (TOCS), 24(2):115–
139, 2006.
Dominik Merli, Dieter Schuster, Frederic Stumpf, and Georg Sigl.
Semi-invasive EM attack on FPGA RO PUFs and countermeasures.
In 6th Workshop on Embedded Systems Security (WESS 2011), pages
1–9. ACM, 2011.
Serge Mister and Stafford E Tavares. Cryptanalysis of RC4-like ciphers. In 5th International Workshop on Selected Areas in Cryptography (SAC 1998), volume 1556 of Lecture Notes in Computer Science,
David E Muller. A method for solving algebraic equations using an
automatic computer. Mathematical Tables and Other Aids to Computation, 10(56):208–215, 1956.
Frédéric Muller. Differential attacks against the Helix stream cipher.
In 11th International Workshop on Fast Software Encryption (FSE
Collin Mulliner. Vulnerability analysis and attacks on nfc-enabled
mobile phones. In 1st International Workshop on Sensor Security
(IWSS 2009), pages 695–700. IEEE Computer Society, 2009.
David A McGrew and John Viega. The security and performance
of the galois/counter mode (GCM) of operation. In 5th International Conference on Cryptology in India, Progress in Cryptology
(INDOCRYPT 2004), volume 3348 of Lecture Notes in Computer
Alfred J Menezes, Paul C Van Oorschot, and Scott A Vanstone.
Handbook of applied cryptography. CRC press, 2010.
Karsten Nohl, David Evans, Starbug, and Henryk Plötz. Reverse
engineering a cryptographic RFID tag. In 17th USENIX Security
Symposium (USENIX Security 2008), pages 185–193. USENIX Association, 2008.
Technical specification, NFC data exchange format (NDEF), 2006.
NFC Forum - NDEF 1.0.
Bibliography
[NFC10]
(355)
[NFC11]
(356)
[NFC13]
(357)
[Noh08]
(358)
[Noh10]
(359)
[Nov03]
(360)
[NP07]
(361)
[NTW10]
(362)
[NXP10]
245
Technical specification, connection handover, 2010. NFC Forum Connection Handover 1.2.
Technical specification, nfc activity specification, 2011. NFC Forum
- ACTIVITY 1.0.
Technical specification, personal health device communication, 2013.
NFC Forum - PHDC 1.0.
Karsten Nohl. Cryptanalysis of crypto-1. Computer Science Department University of Virginia, White Paper, 2008.
Karsten Nohl. Immobilizer security. In 8th International Conference
on Embedded Security in Cars (ESCAR 2010), 2010.
Roman Novak. Side-channel attack on substitution blocks. In 1st
International Conference on Applied Cryptography and Network Security (ACNS 2003), volume 2846 of Lecture Notes in Computer Science, pages 307–318. Springer-Verlag, 2003.
Karsten Nohl and Henryk Plötz. Mifare, little security, despite obscurity. Presentation on the 24th Congress of the Chaos Computer
Club in Berlin (24C3), December 2007.
Karsten Nohl, Erik Tews, and Ralf-Philipp Weinmann. Cryptanalysis
of the DECT standard cipher. In 17th International Workshop on
(363)
Transponder IC, Hitag2. Product Data Sheet, Nov 2010. NXP Semiconductors.
[NXP11]
Hitag pro. Product Data Sheet, 2011. NXP Semiconductors.
(364)
[NXP13]
(365)
[Oec03]
(366)
[OMHT06]
(367)
Mifare application directory (MAD). Application note, Jan 2013.
NXP Semiconductors.
Philippe Oechslin. Making a faster cryptanalytic time-memory tradeoff. In 23rd International Cryptology Conference, Advances in Cryptology (CRYPTO 2003), volume 2729 of Lecture Notes in Computer
Elisabeth Oswald, Stefan Mangard, Christoph Herbst, and Stefan
Tillich. Practical second-order DPA attacks for masked smart card
implementations of block ciphers. In 6th Cryptographers’ Track at
the RSA Conference, Topics in Cryptology (CT-RSA 2006), volume
246
[ORSVH95]
(368)
[OSS+ 13]
(369)
[Pas09]
(370)
[PDMS09]
(371)
[PEK+ 09]
(372)
[Pen96]
(373)
[PFS00]
(374)
[PGV94]
(375)
[Pha02]
(376)
[PHI98]
(377)
Bibliography
Sam Owre, John Rushby, Natarajan Shankar, and Friedrich
Von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software
Engineering, 21(2):107–125, 1995.
David Oswald, Daehyun Strobel, Falk Schellenberg, Timo Kasper,
and Christof Paar. When reverse-engineering meets side-channel
analysis–digital lockpicking in practice. In 20th International Conference on Selected Areas in Cryptography (SAC 2013), Lecture Notes
in Computer Science. Springer-Verlag, 2013.
Enes Pasalic. On guess and determine cryptanalysis of LFSRbased stream ciphers. IEEE Transactions on Information Theory,
55(7):3398–3406, 2009.
Nikolaos Petrakos, George W Dinolt, James Bret Michael, and Pantelimon Stanica. Cube-type algebraic attacks on wireless encryption
protocols. IEEE Computer, 42(10):103–105, 2009.
Christof Paar, Thomas Eisenbarth, Markus Kasper, Timo Kasper,
and Amir Moradi. Keeloq and side-channel analysis-evolution of an
attack. In 6th International Workshop on Fault Diagnosis and Tolerance in Cryptography (FDTC 2009), pages 65–69. IEEE Computer
Society, 2009.
Walter T Penzhorn. Correlation attacks on stream ciphers: Computing low-weight parity checks based on error-correcting codes. In 3rd
Slobodan Petrovic and Amparo Fuster-Sabater. Cryptanalysis of the
A5/2 algorithm. IACR Cryptology ePrint Archive, 2000(52):1Ợ7,
2000.
Bart Preneel, René Govaerts, and Joos Vandewalle. Hash functions
based on block ciphers: A synthetic approach. In 13th International
Raphael Chung-Wei Phan. Cryptanalysis of full Skipjack block cipher. Electronics Letters, 38(2):69–71, 2002.
MIFARE Classic 1k, MF1ICS50. Public product data sheet, July
1998. Philips Semiconductors.
Bibliography
[PHI99]
(378)
[PK79]
(379)
[Ple77]
(380)
[PM07]
(381)
[PN12]
(382)
[PP04]
(383)
[PPPM13]
(384)
[PS96]
(385)
[PS00]
(386)
[QS01]
(387)
247
Security transponder plus remote keyless entry – HITAG2 plus,
PCF7946AT. Product Profile, Jun 1999. Philips Semiconductors.
Gerald J Popek and Charles S Kline. Encryption and secure computer
networks. ACM Computing Surveys (CSUR), 11(4):331–356, 1979.
Vera S Pless. Encryption schemes for computer confidentiality. IEEE
Transactions on Computers, 100(11):1133–1136, 1977.
Goutam Paul and Subhamoy Maitra. Permutation after RC4 key
scheduling reveals the secret key. In 14th International Workshop on
Selected Areas in Cryptography (SAC 2007), volume 4876 of Lecture
Henryk Pl¨
otz and Karsten Nohl. Peeling away layers of an RFID security system. In 16th International Conference on Financial Cryptography and Data Security (FC 2012), volume 7035 of Lecture Notes
Souradyuti Paul and Bart Preneel. A new weakness in the RC4 keystream generator and an approach to improve the security of the
cipher. In 11th International Workshop on Fast Software Encryption (FSE 2004), volume 3017 of Lecture Notes in Computer Science,
Panagiotis Papantonakis, Dionisios Pnevmatikatos, Ioannis Papaefstathiou, and Charalampos Manifavas. Fast, FPGA-based rainbow
table creation for attacking encrypted mobile communications. In
23rd International Conference on Field Programmable Logic and Applications (FPL 2013), pages 1–6. IEEE Computer Society, 2013.
David Pointcheval and Jacques Stern. Security proofs for signature
schemes. In 15th International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 1996), volume 1070 of Lecture Notes in Computer Science,
Thomas Pornin and Jacques Stern. Software-hardware trade-offs:
Application to A5/1 cryptanalysis. In 2nd International Workshop
Jean-Jacques Quisquater and David Samyde. Electromagnetic analysis (EMA): Measures and counter-measures for smart cards. In Smart
Card Programming and Security, volume 2140 of Lecture Notes in
248
[RCT05]
(388)
[Ree77]
(389)
[Rei62]
(390)
[RLS11]
(391)
[RM99]
(392)
[Roo95]
(393)
[RRST02]
(394)
[RSA78]
(395)
[RSH+ 12]
(396)
[RSN+ 01]
(397)
[Rub79]
(398)
[Rue86]
(399)
Bibliography
Melanie Rieback, Bruno Crispo, and Andrew Tanenbaum. RFID
guardian: A battery-powered mobile device for RFID privacy management. In 10th Australasian Conference on Information Security
and Privacy (ACISP 2005), volume 3574 of Lecture Notes in Computer Science, pages 184–194. Springer-Verlag, 2005.
James Reeds. “Cracking” a random number generator. Cryptologia,
1(1):20–26, 1977.
Edgar C Reinke. Classical cryptography. The Classical Journal,
58(3):113–121, 1962.
Michael Roland, Josef Langer, and Josef Scharinger. Security vulnerabilities of the NDEF signature record type. In 3rd International
Workshop on Near Field Communication (NFC 2011), pages 65–70.
IEEE Computer Society, 2011.
Kristoffer H Rose and Ross Moore. Xy-pic reference manual, 1999.
Andrew Roos. A class of weak keys in the RC4 stream cipher, 1995.
Josyula R Rao, Pankaj Rohatgi, Helmut Scherzer, and Stephane
Tinguely. Partitioning attacks: or how to rapidly clone some GSM
cards. In 23rd IEEE Symposium on Security and Privacy (S&P 1997),
Ronald L Rivest, Adi Shamir, and Len Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2):120–126, 1978.
Amir Rahmati, Mastooreh Salajegheh, Dan Holcomb, Jacob Sorber,
Wayne P. Burleson, and Kevin Fu. TARDIS: Time and remanence
decay in SRAM to implement secure protocols on embedded devices
without clocks. In 21st USENIX Security Symposium (USENIX Security 2012), pages 221–236. USENIX Association, 2012.
Andrew Rukhin, Juan Soto, James Nechvatal, Miles Smid, Elaine
Barker, Stefan Leigh, Mark Levenson, Mark Vangel, David Banks,
Alan Heckert, James Dray, and San Vo. A statistical test suite for the
validation of random number generators and pseudo random number
generators for cryptographic applications. NIST Special Publication
(800-22), 22:1–152, 2001.
Frank Rubin. Decrypting a stream cipher based on J-K flip-flops.
IEEE Transactions on Computers, 100(7):483–487, 1979.
Rainer A Rueppel. Stream ciphers. In Analysis and Design of Stream
Ciphers, pages 5–16. Springer-Verlag, 1986.
Bibliography
[Rue92]
(400)
[Rv10]
(401)
[SA00]
(402)
[SA03]
(403)
[SAHK07]
(404)
[Sai11]
(405)
[Sch98a]
(406)
[Sch98b]
(407)
[SDK+ 13]
(408)
[Sha49]
(409)
[Sha04]
(410)
249
R.A. Rueppel. Stream ciphers. Contemporary cryptology: The science
of information integrity, pages 65–134, 1992.
ˇ
Kasper Bonne Rasmussen and Srdjan Capkun.
Realization of rf distance bounding. In 19th USENIX Security Symposium (USENIX
Security 2010), pages 389–402. USENIX Association, 2010.
Frank Stajano and Ross J. Anderson. The resurrecting duckling:
Security issues for ad-hoc wireless networks. In 7th International
Workshop on Security Protocols (WSP 2000), volume 1796 of Lecture
Sergei P Skorobogatov and Ross J Anderson. Optical fault induction
attacks. In 4th International Workshop on Cryptographic Hardware
and Embedded Systems (CHES 2002), volume 2523 of Lecture Notes
Nobuyuki Sugio, Hiroshi Aono, Sadayuki Hongo, and Toshinobu
Kaneko. A study on higher order differential attack of KASUMI. IEICE Transactions on Fundamentals of Electronics, Communications
and Computer Sciences, 90(1):14–21, 2007.
Teruo Saito. A single-key attack on 6-round KASUMI. IACR Cryptology ePrint Archive, 2011(584):1Ợ13, 2011.
Bruce Schneier. Cryptographic design vulnerabilities. Computer,
31(9):29–33, 1998.
Bruce Schneier. Security pitfalls in cryptography. In EDI FORUMOAK PARK-, volume 11, pages 65–69. The EDI Group, Ltd., 1998.
Daehyun Strobel, Benedikt Driessen, Timo Kasper, Gregor Leander,
David Oswald, Falk Schellenberg, and Christof Paar. Fuming acid
and cryptanalysis: Handy tools for overcoming a digital locking and
access control system. In 33rd International Cryptology Conference,
Advances in Cryptology (CRYPTO 2013), volume 8042 of Lecture
Claude E Shannon. Communication theory of secrecy systems. Bell
system technical journal, 28(4):656–715, 1949.
Adi Shamir. Invited talk: Stream ciphers: Dead or alive? In 10th
International Conference on the Theory and Application of Cryptology and Information Security, Advances in Cryptology (ASIACRYPT
2004), volume 3329 of Lecture Notes in Computer Science, page 78.
250
[She94a]
(411)
[She94b]
(412)
[SHXZ11]
(413)
[Sie84]
(414)
[Sie85]
(415)
[Sim64]
(416)
[Sin66]
(417)
[SIR02]
(418)
[SIR04]
(419)
[SKK+ 97]
(420)
[Sko05]
(421)
Bibliography
SJ Shepherd. An approach to the cryptanalysis of mobile stream
ciphers. In IEE Colloquium on Security and Cryptography Applications to Radio Systems, volume 1994/141, 1994. (COMMERCIALIN-CONFIDENCE).
SJ Shepherd. Cryptanalysis of the GSM A5 cipher algorithm. In IEE
Colloquium on Security and Cryptography Applications to Radio Systems, volume 1994/141, 1994. (COMMERCIAL-IN-CONFIDENCE).
Siwei Sun, Lei Hu, Yonghong Xie, and Xiangyong Zeng. Cube cryptanalysis of Hitag2 stream cipher. In 10th International Conference
on Cryptology and Network Security (CANS 2011), volume 7092 of
2011.
Thomas Siegenthaler. Correlation-immunity of nonlinear combining
functions for cryptographic applications. IEEE Transactions on Information Theory, 30(5):776–780, 1984.
Thomas Siegenthaler. Decrypting a class of stream ciphers using
ciphertext only. IEEE Transactions on Computers, 100(1):81–85,
1985.
William Simon. Mathematical magic. Courier Dover Publications,
1964.
Abraham Sinkov. Elementary cryptanalysis: a mathematical approach. Mathematical Association of America, 1966.
Adam Stubblefield, John Ioannidis, and Aviel D. Rubin. Using the
Fluhrer, Mantin, and Shamir attack to break WEP. In 9th Network
and Distributed System Security Symposium (NDSS 2002). The Internet Society, 2002.
Adam Stubblefield, John Ioannidis, and Aviel D. Rubin. A key recovery attack on the 802.11b wired equivalent privacy protocol (WEP).
ACM Transactions on Information and System Security, 7(2):319–
332, 2004.
Christoph L Schuba, Ivan V Krsul, Markus G Kuhn, Eugene H Spafford, Aurobindo Sundaram, and Diego Zamboni. Analysis of a denial
of service attack on tcp. In 18th IEEE Symposium on Security and
Sergei P Skorobogatov. Semi-invasive attacks - a new approach to
hardware security analysis. Technical report, University of Cambridge, Computer Laboratory, 2005.
Bibliography
[Sko09]
(422)
[Smi71]
(423)
[SNC09]
(424)
[SS02]
(425)
[SSAQ02]
(426)
[SSB11]
(427)
[SSVV13]
(428)
[ST02]
(429)
[Ste99]
(430)
[Ste13]
(431)
251
Sergei Skorobogatov. Local heating attacks on flash memory devices.
In 2nd IEEE International Workshop on Hardware - Oriented Security and Trust (HOST 2009), pages 1–6. IEEE Computer Society,
2009.
John Lynn Smith. The design of lucifer, a cryptographic device for
data communications. Technical report, IBM Thomas J. Watson
Research Laboratory, 1971.
Mate Soos, Karsten Nohl, and Claude Castelluccia. Extending SAT
solvers to cryptographic problems. In 12th International Conference on Theory and Applications of Satisfiability Testing (SAT 2009),
Pamela Samuelson and Suzanne Scotchmer. The law and economics
of reverse engineering. Yale Law Journal, pages 1575–1663, 2002.
David Samyde, Sergei Skorobogatov, Ross Anderson, and J-J
Quisquater. On a new way to read data from memory. In 1st International IEEE Security in Storage Workshop (SISW 2002), pages
Asia Slowinska, Traian Stancescu, and Herbert Bos. Howard: a dynamic excavator for reverse engineering data structures. In 18th Network and Distributed System Security Symposium (NDSS 2011), San
Diego, CA, 2011. The Internet Society.
Pouyan Sepehrdad, Petr Susil, Serge Vaudenay, and Martin Vuagnoux. Smashing WEP in a passive attack. In 20th International
2013.
13.56 mhz short range contactless memory chip with 4096 bit EEPROM, anti-collision functions and anti-clone functions, SRIX4K. Preliminary Product Datasheet, May 2002. ST Microelectronics.
Frank A. Stevenson. Cryptanalysis of contents scrambling system
(CCS), November 1999.
Marc Stevens. New collision attacks on SHA-1 based on optimal
joint local-collision analysis. In 32nd International Conference on
the Theory and Application of Cryptographic Techniques, Advances
in Cryptology (EUROCRYPT 2013), volume 7881 of Lecture Notes
252
[Sti05]
(432)
[Str69]
Bibliography
Douglas R Stinson. Cryptography: theory and practice. CRC press,
2005.
(433)
Volker Strassen. Gaussian elimination is not optimal. Numerische
Mathematik, 13(4):354–356, 1969.
[Sun94]
Tzu Sun. Art of war. Basic Books, 1994.
(434)
[SVV11a]
(435)
[SVV11b]
(436)
[SW06]
(437)
[SWT01]
(438)
[TB09]
(439)
[Tec05]
(440)
[Tew12]
(441)
[TI04]
(442)
[Tre08]
(443)
Pouyan Sepehrdad, Serge Vaudenay, and Martin Vuagnoux. Discovery and exploitation of new biases in RC4. In 17th International
Pouyan Sepehrdad, Serge Vaudenay, and Martin Vuagnoux. Statistical attack on RC4. In 30th International Conference on the Theory
and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2009), volume 6632 of Lecture Notes in Computer
Yaniv Shaked and Avishai Wool. Cryptanalysis of the Bluetooth E0
cipher using OBDD’s. In 9th International Conference on Information Security (ISC 2006), volume 4176 of Lecture Notes in Computer
Dawn Xiaodong Song, David Wagner, and Xuqing Tian. Timing
analysis of keystrokes and timing attacks on SSH. In 10th USENIX
Security Symposium (USENIX Security 2001). USENIX Association,
2001.
Erik Tews and Martin Beck. Practical attacks against WEP and
WPA. In 2nd ACM Conference on Wireless Network Security
(WISEC 2009), pages 79–86. ACM, 2009.
Constructivecard Technologies. A review of the cryptomemory algorithm performance, jan 2005.
Erik Tews. DECT Security Analysis. PhD thesis, Doctoral Dissertation, May 2012, TU Darmstadt, 2012.
Radio frequency identification systems – digital signature transponder plus, DST+. Product Specification, July 2004. Texas Instruments
Incorporated.
Jan Tretmans. Model based testing with labelled transition systems. In Formal Methods and Testing (FORTEST 2008), volume
Bibliography
[TT80]
(444)
[TWP07]
(445)
[vdBP13]
(446)
[VdKGG12]
(447)
[VDWKP09]
(448)
[Ver08a]
(449)
[Ver08b]
(450)
[VGB12]
(451)
[VGE13]
(452)
[VK11]
(453)
[vN11]
(454)
253
Moiez A. Tapia and Jerry H. Tucker. Complete solution of boolean
equations. IEEE Transactions on Computers, 100(7):662–665, 1980.
Erik Tews, Ralf-Philipp Weinmann, and Andrei Pyshkin. Breaking
104 bit WEP in less than 60 seconds. In 8th International Workshop
on Information Security Applications (WISA 2007), volume 4867 of
2007.
Fabian van den Broek and Erik Poll. A comparison of time-memory
trade-off attacks on stream ciphers. In 6th International Conference
on Cryptology in Africa, Progress in Cryptology (AFRICACRYPT
Roel Verdult, Gerhard de Koning Gans, and Flavio D. Garcia. A
toolbox for RFID protocol analysis. In 4th International EURASIP
Workshop on RFID Technology (EURASIP RFID 2012), pages 27–
34. IEEE Computer Society, 2012.
Gauthier Van Damme, Karel M. Wouters, Hakan Karahan, and Bart
Preneel. Offline NFC payments with electronic vouchers. In 1st
ACM Workshop on Networking, Systems, and Applications on Mobile
Handhelds (MobiHeld 2009), pages 25–30. ACM, 2009.
Roel Verdult. Proof of concept, cloning the OV-chip card. Technical
report, Radboud University Nijmegen, 2008.
Roel Verdult. Security analysis of RFID tags. Master’s thesis, Radboud University Nijmegen, 2008.
Roel Verdult, Flavio D. Garcia, and Josep Balasch. Gone in 360
seconds: Hijacking with Hitag2. In 21st USENIX Security Symposium
(USENIX Security 2012), pages 237–252. USENIX Association, 2012.
Roel Verdult, Flavio D. Garcia, and Barı¸s Ege. Dismantling megamos crypto: Wirelessly lockpicking a vehicle immobilizer. In 22nd
USENIX Security Symposium (USENIX Security 2013). USENIX Association, 2013.
Roel Verdult and Fran¸cois Kooman. Practical attacks on NFC enabled cell phones. In 3rd International Workshop on Near Field Communication (NFC 2011), pages 77–82. IEEE Computer Society, 2011.
ˇ
Petr Stembera
and Martin Novotný. Breaking Hitag2 with reconfigurable hardware. In 14th Euromicro Conference on Digital System
Design (DSD 2011), pages 558–563. IEEE Computer Society, 2011.
254
[VOW96]
(455)
[VOW99]
(456)
[VV07]
(457)
[Wag99]
(458)
[WBD74]
(459)
[WCAA00]
(460)
[Wei00]
(461)
[WFY+ 02]
(462)
[WGB98]
(463)
[WHF02]
(464)
Bibliography
Paul C Van Oorschot and Michael J Wiener. Improving implementable meet-in-the-middle attacks by orders of magnitude. In
16th International Cryptology Conference, Advances in Cryptology
(CRYPTO 1996), volume 1109 of Lecture Notes in Computer Science, pages 229–236. Springer-Verlag, 1996.
Paul C Van Oorschot and Michael J Wiener. Parallel collision search
with cryptanalytic applications. Journal of Cryptology, 12(1):1–28,
1999.
Serge Vaudenay and Martin Vuagnoux. Passive–only key recovery
attacks on RC4. In 14th International Workshop on Selected Areas in
David Wagner. The boomerang attack. In 6th International Workshop on Fast Software Encryption (FSE 1999), volume 1636 of Lecture Notes in Computer Science, pages 156–170. Springer-Verlag,
1999.
Edward L Wilson, Klaus-J¨
urgen Bathe, and William P Doherty. Direct solution of large systems of linear equations. Computers & Structures, 4(2):363–372, 1974.
DJ Weaver, JRA Cleaver, L Avery, and H Ahmed. Multilayer
integrated-circuit imaging with contrast enhancement in a large-area,
high-resolution electron-beam system. Microelectronic engineering,
53(1):641–644, 2000.
Steve H Weingart. Physical security devices for computer subsystems:
A survey of attacks and defenses. In 2nd International Workshop
Dai Watanabe, Soichi Furuya, Hirotaka Yoshida, Kazuo Takaragi,
and Bart Preneel. A new keystream generator mugi. In 9th International Workshop on Fast Software Encryption (FSE 2002), volume
David Wagner, Ian Goldberg, and Marc Briceno. Gsm cloning. Web
page about COMP-128 version, 1, 1998.
Doug Whiting, Russ Housley, and Niels Ferguson. Aes encryption
& authentication using CTR mode & CBC-MAC. IEEE P802, 11,
2002.
Bibliography
255
[WHWC07]
Pang-Chieh Wang, Ting-Wei Hou, Jung-Hsuan Wu, and Bo-Chiuan
Chen. A security module for car appliances. International Journal of
World Academy Of Science, Engineering and Technology, 26:155–160,
2007.
(465)
[Wie90]
(466)
[Wie07]
(467)
[WIF03]
(468)
[WKR+ 08]
(469)
[WMT+ 13]
(470)
[WP07]
(471)
[WS02]
(472)
[WSD+ 99]
(473)
[WSK97]
(474)
JM Wiesenfeld. Electro-optic sampling of high-speed devices and
integrated circuits. IBM Journal of Research and Development,
34(2.3):141–161, 1990.
I.C. Wiener. Philips/NXP Hitag2 PCF7936/46/47/52 stream cipher
reference implementation. http://cryptolib.com/ciphers/hitag2/, 2007.
Wi-Fi protected access: Strong, standards-based, interoperable security for today’s Wi-Fi networks, 2003.
Jung-Hsuan Wu, Chien-Chuan Kung, Jhan-Hao Rao, Pang-Chieh
Wang, Cheng-Liang Lin, and Ting-Wei Hou. Design of an in-vehicle
anti-theft component. In 8th International Conference on Intelligent
Systems Design and Applications (ISDA 2008), volume 1, pages 566–
569. IEEE Computer Society, 2008.
Michael Weiner, Maurice Massar, Erik Tews, Dennis Giese, and Wolfgang Wieser. Security analysis of a widely deployed locking system.
In 20th ACM Conference on Computer and Communications Security
(CCS 2013), pages 929–940. ACM, 2013.
Hongjun Wu and Bart Preneel. Differential-linear attacks against
the stream cipher Phelix. In 14th International Workshop on Fast
Anthony D Wood and John A Stankovic. Denial of service in sensor
networks. Computer, 35(10):54–62, 2002.
David Wagner, Leone Simpson, Ed Dawson, John Kelsey, William
Millan, and Bruce Schneier. Cryptanalysis of ORYX. In 5th International Workshop on Selected Areas in Cryptography (SAC 1998),
David Wagner, Bruce Schneier, and John Kelsey. Cryptanalysis of the
cellular message encryption algorithm. In 17th International Cryptology Conference, Advances in Cryptology (CRYPTO 1997), volume
256
Bibliography
[WSvRG+ 08] Ronny Wichers Schreur, Peter van Rossum, Flavio D. Garcia, Wouter
(475)
Teepe, Jaap-Henk Hoepman, Bart Jacobs, Gerhard de Koning Gans,
Roel Verdult, Ruben Muijrers, Ravindra Kali, and Vinesh Kali. Security flaw in MIFARE Classic. Press release, Digital Security group,
Radboud University Nijmegen, The Netherlands, March 2008.
[WTHH11]
(476)
[WWW07]
(477)
[WY05]
(478)
[XHW94]
(479)
[ZF06]
(480)
[ZJS+ 09]
(481)
[ZXF13]
(482)
[ZYSQ13]
(483)
Michael Weiner, Erik Tews, Benedikt Heinz, and Johann Heyszl. Fpga
implementation of an improved attack against the DECT standard
cipher. In 13th International Conference on Information Security and
Cryptology (ICISC 2010), volume 6829 of Lecture Notes in Computer
Marko Wolf, Andre Weimerskirch, and Thomas Wollinger. State of
the art: Embedding security in vehicles. EURASIP Journal on Embedded Systems, 2007:074706, 2007.
Xiaoyun Wang and Hongbo Yu. How to break MD5 and other hash
functions. In 24th International Conference on the Theory and Application of Cryptographic Techniques, Advances in Cryptology (EUROCRYPT 2005), volume 3494 of Lecture Notes in Computer Science,
SB Xu, DK He, and XM Wang. An implementation of the GSM
general data encryption algorithm A5. In Advanced in Cryptology
(CHINACRYPT 1994), volume 94, pages 287–291, 1994.
Bin Zhang and Dengguo Feng. New guess-and-determine attack on
the self-shrinking generator. In 12th International Conference on
the Theory and Application of Cryptology and Information Security,
Advances in Cryptology (ASIACRYPT 2006), volume 4284 of Lecture
Yang Zhenye, Yang Jiexue, Wang Songming, Hong Jiexin, and Chen
Kuncheng. New method of hardware encryption against piracy. In
Information Technology and Applications (IFITA 2009), volume 2,
Bin Zhang, Chao Xu, and Dengguo Feng. Real time cryptanalysis of Bluetooth encryption with condition masking. In 33rd International Cryptology Conference, Advances in Cryptology (CRYPTO
Yuanyuan Zhou, Yu Yu, Fran¸cois-Xavier Standaert, and JeanJacques Quisquater. On the need of physical security for small embedded devices: a case study with COMP128-1 implementations in
Bibliography
257
SIM cards. In 17th International Conference on Financial Cryptography and Data Security (FC 2013), volume 7859 of Lecture Notes in
Index
Access condition, 31
Advanced Encryption Standard, 23
Adversary, 17
Algebraic attacks, 60
Asymmetric cryptography, 24
Attack complexity, 21
Authentication attempt, 33
Authentication protocol, 29
Authenticity, 3
Authorization, 31
Authorization model, 32
Availability, 2, 3
Balanced output, 54
Black box, 35
Blocking attack, 48
Brute-force attack, 21
Candidate disqualification, 57
Candidate elimination, 57
Chaining of encryption, 27
Challenge-response, 29
Challenge-response pair, 33
Cipher, 17
Cipher complexity, 21
Cipher components, 33
Cipher specification, 20
Ciphertext, 17
Communication blocking attack, 48
Communication channel, 2
Communication session, 31
Complexity, 21
Computational complexity, 21
Computations, 22
Confidential communication channel, 2
Confidentiality, 2
Credentials, 32
Cryptanalysis, 49
Cryptanalytic techniques, 49
Cryptographic algorithm, 20
Cryptographic challenge-response, 29
Cryptographic operation, 2
Cryptographic session, 27
Cryptography, 4, 17
Cryptosystem, 20
Custom cryptography, 86
Data Encryption Standard, 23
Data integrity, 2
Decryption, 17
Differential attack, 58
Diversified keys, 31
Divide-and-conquer, 51
Eavesdropping, 42
Encryption, 2, 17
Encryption layer, 37
Encryption oracle, 30, 35
Encryption state, 47
Entity, 3, 17
Entity authentication, 2, 3
Entropy, 21
Error prone, 25
Exhaustive search, 21
Filter function, 33
260
Genuine entity, 17
Initialization vector, 30
Injection attack, 47
Integrity checks, 36
intermediate state, 63
Internal cipher state, 25
Internal state, 25
Invasive attacks, 65
Invertible function, 33
Kerckhoffs’s principle, 4, 22
Key space, 21
Keystream, 25
Legitimate party, 17
Linear boolean function, 61
Linear cryptanalysis, 61
Low cohesion, 33
Mafia fraud, 43
Malleability attack, 50
Mathematical computation, 2
Meet-in-the-middle attack, 63
Message Authentication, 2
Message authentication, 3
Message tampering, 2
Micro-controller, 1
Mutual authentication, 30
Non-invasive attacks, 65
Non-linear filter function, 33
Non-linear function, 33
Non-linearity, 20
Non-repudiation, 2, 3
One-time pad, 24
Parity bit, 36
Passive eavesdropping, 42
Perfect cipher, 21
Perfect Secrecy, 25
Plaintext, 17
Predecessor state, 35
Private key, 24
Index
Privilege escalation, 35
Proprietary cryptography, 4
Public key, 24
Reflection attack, 46
Relay attack, 42
Relay station, 43
Replay attack, 45
Secret key, 24
Secure channel, 2
Secure Hash Algorithm, 23
Secure Hash Standard, 23
Semi-invasive attacks, 65
Session, 27
Side-channel attacks, 65
Single authentication, 30
State machine, 36
State transitions, 36
Stream cipher, 33
Substitution, 18
Successor function, 27
Successor state, 35
Symmetric authentication protocol, 46
Symmetric cryptography, 24
Tampering, 2
Third party, 17
Time-memory trade off, 78
Trace, 42
Transform, 17
Transmission tampering, 50
Unilateral authentication, 30
Acronyms
3DES
Triple DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3GPP
3rd Generation Partnership Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ADC
Analog-to-Digital Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
AES
Advanced Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ASK
Amplitude-Shift Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
ASIC
Application-Specific Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
AKA
Authentication and Key Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
BPLM
Binary Pulse Length Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
BP
Bi-Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
BTS
Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CBC
Cipher Block Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
CCD
Charge-Coupled Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
CCM
Counter with CBC-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CD
Compact Disc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
CERT
Computer Emergency Response Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
CMAC
Cipher-based Message Authentication Code . . . . . . . . . . . . . . . . . . . . . . . . . 29
CRC
Cyclic Redundancy Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
CSS
Content Scramble System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
CTR
Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
DAC
Digital-to-Analog Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
DECT
Digital Enhanced Cordless Telecommunications . . . . . . . . . . . . . . . . . . . . . 76
DES
Data Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
262
Acronyms
DoD
Department of Defence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
DOS
Denial-of-Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
DPA
Differential Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
DRM
Digital Rights Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
DSAA
DECT Standard Authentication Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 77
DSC
DECT Standard Cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
DST
Digital Signature Transponder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
DSP
Digital Signal Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
DVD
Digital Versatile Disc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
EFF
Electronic Frontier Foundation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
EM
Electromagnetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
EPIC
Electronic Privacy Information Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
ETSI
European Telecommunications Standards Institute . . . . . . . . . . . . . . . . . . 73
FIB
Focused Ion Beam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
FPGA
Field Programmable Gate Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
FSK
Frequency-Shift Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
GCM
Galois Counter Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
GEO
Geostationary Earth Orbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
GMR
GEO Mobile Radio Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
GNU
GNU’s Not Unix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
GPL
General Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
GSM
Global System for Mobile Communications . . . . . . . . . . . . . . . . . . . . . . . . . 37
HMAC
Hashed Message Authentication Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
HF
High Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IC
Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
ICAO
International Civil Aviation Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
ICT
Information and Communication Technology . . . . . . . . . . . . . . . . . . . . . . . . . 8
IEC
International Electrotechnical Commission . . . . . . . . . . . . . . . . . . . . . . . . . . 84
IETF
Internet Engineering Task Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
IPsec
Internet Protocol Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ISO
International Organization for Standardization . . . . . . . . . . . . . . . . . . . . . . 84
IV
Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
LF
Low Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
MAC
Message Authentication Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Acronyms
263
NBS
National Bureau of Standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
NCSC
National Cyber Security Centre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
NDA
Non-Disclosure Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NFC
Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
NFCIP
NFC Interface and Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
NIST
National Institute of Standards and Technology . . . . . . . . . . . . . . . . . . . . . 23
NRZ
Non-Return-to-Zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
NSA
National Security Agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
OOK
On-Off Keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
OSI
Open Systems Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
OTP
One-time Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
OWF
One-Way Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
PKES
Passive Keyless Entry and Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
QPLM
Quad Pulse Length Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
RC4
Rivest Cipher 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
RSA
Rivest, Shamir and Adleman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
RF
Radio Frequency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
RFID
Radio Frequency Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
RKE
Remote Keyless Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
OECD
Organization for Economic Co-operation and Development . . . . . . . . . . 75
PC
Personal Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
PRNG
Pseudo Random Number Generator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
PSK
Phase-shift keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
RFC
Request for Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
SDR
Software Defined Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
SEI
Software Engineering Institute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
SHA-3
Secure Hash Algorithm-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SHS
Secure Hash Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SIG
Special Interest Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SIM
Subscriber Identity Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
SPA
Simple Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
SSH
Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
TIA
Telecommunications Industry Association . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
TLS
Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
264
Acronyms
TMTO
Time-Memory Trade-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
UICC
Universal Integrated Circuit Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
UID
Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
UHF
Ultra-High Frequency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
US
United States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
USB
Universal Serial Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
US
United States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
USD
United States Dollar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
USRP
Universal Software Radio Peripheral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
VPN
Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
WEP
Wired Equivalent Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
WPA
Wi-Fi Protected Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
WPA2
Wi-Fi Protected Access II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
XOR
exclusive-or . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
List of Figures
1.1
General categorization of cryptography and study focus . . . . . . . .
9
2.1
Caesar substitution using a rotation of three positions . . . . . . . . .
18
2.2
Substitution example . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3
Scytale transposition using a split position of seven characters . . . . .
19
2.4
Modified Caesar substitution using a random permutation . . . . . . .
21
2.5
Enigma machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.6
Typical non-linear stream cipher system . . . . . . . . . . . . . . . . .
26
2.7
Two-pass single authentication protocol . . . . . . . . . . . . . . . . .
30
2.8
Two-pass mutual authentication protocol . . . . . . . . . . . . . . . .
31
2.9
Three-pass mutual authentication protocol . . . . . . . . . . . . . . . .
32
3.1
Replay attack on a three-pass mutual authentication protocol . . . . .
43
3.2
Relay attack on an access control system that uses an NFC smart card
44
3.3
Replay attack on a two-pass mutual authentication protocol . . . . . .
45
3.4
Demonstration of a reflection attack . . . . . . . . . . . . . . . . . . .
46
3.5
Injection attack on a protocol without proper session integrity checks .
47
3.6
Blocking attack on the second part of the communication . . . . . . .
48
3.7
Malleability attack alters the value of a money transfer . . . . . . . . .
50
3.8
Divide-and-conquer cipher . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.9
Computation of the first three encryption . . . . . . . . . . . . . . . .
52
3.10 Divide-and-conquer attack by dividing odd and even keystream bits .
52
3.11 Stream cipher with correlation weakness, initialized by secret key k . .
53
3.12 Boolean input-ouput table that corresponds to Definition 3.2.1 . . . .
54
3.13 Non-linear stream cipher, initialized by secret key k
. . . . . . . . . .
56
3.14 Boolean input-ouput table that corresponds to Definition 3.2.2 . . . .
56
266
List of figures
3.15 First five evaluations of f (·)
. . . . . . . . . . . . . . . . . . . . . . .
57
3.16 Non-linear stream cipher initialized with key XOR nonce . . . . . . . .
59
3.17 A linear stream cipher, initialized by secret key k . . . . . . . . . . . .
61
3.18 Evaluation of ks0 ks1 . . .ks7 = 10110101 leads to the equalities of (d) .
62
3.19 cryptosystem which is vulnerable to a meet-in-the-middle attack . . .
63
4.1
Legic obfuscation [PN12] . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.2
Weak PRNG implementation allowing only 2
− 1 states [WMT 13] .
70
4.3
Obscurity function [SDK 13] . . . . . . . . . . . . . . . . . . . . . . .
71
4.4
DST cipher [BGS 05] . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.5
KeeLoq encryption [CBW08] . . . . . . . . . . . . . . . . . . . . . . .
72
4.6
ORYX cipher [WSD 99] . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.7
COMP128 [RRST02] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.8
A5/1 cipher [BB06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.9
A5/2 cipher [BBK03] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.10 KASUMI [DKS10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.11 DSAA init [MOTW09] . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.12 DSC cipher [Tew12] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.13 GMR-1 cipher [DHW 12] . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.14 GMR-2 cipher [DHW 12] . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.15 CCS decryption [Kes00] . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.16 E0 cipher [DCJP01] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.17 Skipjack cipher [BBS99] . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.18 RC4 cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
4.19 WEP encryption protocol [C 07] . . . . . . . . . . . . . . . . . . . . .
82
5.1
RFID chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
6.1
Memory layout of the Mifare Classic . . . . . . . . . . . . . . . . . . .
98
6.2
Authentication trace . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
6.3
Authentication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.4
Initialization Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.5
Nearly equal LFSR states . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.6
First bit of encrypted reader nonce . . . . . . . . . . . . . . . . . . . . 103
6.7
6.8
Structure of the CRYPTO1 stream cipher . . . . . . . . . . . . . . . . 104
Subsequences s¯ and t¯. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.9
Trace of a failed authentication attempt . . . . . . . . . . . . . . . . . 110
7.1
Car keys with a Hitag2 transponder/chip . . . . . . . . . . . . . . . . 124
7.2
Immobilizer unit around the ignition barrel . . . . . . . . . . . . . . . 124
31
+
+
+
+
+
+
+
List of figures
267
7.3
Keyless hybrid transponder and engine start/stop button . . . . . . . 124
7.4
Experimental setup for eavesdropping . . . . . . . . . . . . . . . . . . 129
7.5
Reader modulation of a read command . . . . . . . . . . . . . . . . . 129
7.6
Communication from transponder to reader . . . . . . . . . . . . . . . 129
7.7
Message flow for reading memory block 0 . . . . . . . . . . . . . . . . 132
7.8
Structure of the Hitag2 stream cipher, based on [Wie07] . . . . . . . . 133
7.9
Hitag2 authentication protocol . . . . . . . . . . . . . . . . . . . . . . 133
7.10 Read id without redundancy messages . . . . . . . . . . . . . . . . . . 136
7.11 Read id using 6 redundancy messages . . . . . . . . . . . . . . . . . . 136
7.12 Starting the ignition of a car with the Proxmark . . . . . . . . . . . . 142
7.13 Immobilizer authentication protocol using AES . . . . . . . . . . . . . 146
8.1
Logical memory structure . . . . . . . . . . . . . . . . . . . . . . . . . 152
8.2
The schematic of the SecureMemory and CryptoMemory cipher . . . . 153
8.3
9.1
9.2
Schematic representation of the function hash0 . . . . . . . . . . . . . 179
9.3
or and and-mask for flipping bits 16 . . . 63 of c . . . . . . . . . . . . . 180
9.4
or and and-mask for flipping bits 0 . . . 15 of c
9.5
iClass readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
9.6
The iClass cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.7
Chosen card identities . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
. . . . . . . . . . . . . 181
10.1 Cryptographic hash (SHA-512) of the original paper [VGE13] . . . . . 201
International Journals
[1] Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Wirelessly lockpicking a smart card reader. International Journal of Information Security,
pages 1–18, 2014.
International Conferences
[1] Flavio D. Garcia, Gerhard de Koning Gans, Ruben Muijrers, Peter van Rossum,
Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs. Dismantling MIFARE
Classic. In 13th European Symposium on Research in Computer Security (ESORICS 2008), volume 5283 of Lecture Notes in Computer Science, pages 97–114.
[2] Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers Schreur.
Wirelessly pickpocketing a MIFARE Classic card. In 30th IEEE Symposium on
Security and Privacy (S&P 2009), pages 3–15. IEEE Computer Society, 2009.
[3] Flavio D. Garcia, Peter van Rossum, Roel Verdult, and Ronny Wichers Schreur.
Dismantling SecureMemory, CryptoMemory and CryptoRF. In 17th ACM Conference on Computer and Communications Security (CCS 2010), pages 250–259.
ACM, 2010.
[4] Roel Verdult and Franc Ơấois Kooman. Practical attacks on NFC enabled cell
phones. In 3rd International Workshop on Near Field Communication (NFC
2011), pages 77–82. IEEE Computer Society, 2011.
[5] Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Exposing
iClass key diversification. In 5th USENIX Workshop on Offensive Technologies (WOOT 2011), pages 128–136. USENIX Association, 2011.
270
[6] Josep Balasch, Benedikt Gierlichs, Roel Verdult, Lejla Batina, and Ingrid Verbauwhede. Power analysis of Atmel CryptoMemory - recovering keys from secure EEPROMs. In 12th Cryptographers’ Track at the RSA Conference (CTRSA 2012), volume 7178 of Lecture Notes in Computer Science, pages 19–34.
[7] Gergely. Alpár, Lejla Batina, and Roel Verdult. Using NFC phones for proving
credentials. In 16th Measurement, Modelling, and Evaluation of Computing
Systems and Dependability and Fault Tolerance (MMB&DFT 2012), volume
7201 of Lecture Notes in Computer Science, pages 317–330. Springer-Verlag,
2012.
[8] Roel Verdult, Flavio D. Garcia, and Josep Balasch. Gone in 360 seconds: Hijacking with Hitag2. In 21st USENIX Security Symposium (USENIX Security
2012), pages 237–252. USENIX Association, 2012.
[9] Flavio D. Garcia, Gerhard de Koning Gans, Roel Verdult, and Milosch Meriac.
Dismantling iClass and iClass Elite. In 17th European Symposium on Research
in Computer Security (ESORICS 2012), volume 7459 of Lecture Notes in Computer Science, pages 697–715. Springer-Verlag, 2012.
[10] Roel Verdult, Gerhard de Koning Gans, and Flavio D. Garcia. A toolbox for
RFID protocol analysis. In 4th International EURASIP Workshop on RFID
Technology (EURASIP RFID 2012), pages 27–34. IEEE Computer Society,
2012.
[11] Arjan Blom, Gerhard de Koning Gans, Erik Poll, Joeri de Ruiter, and Roel
Verdult. Designed to fail: A USB-connected reader for online banking. In
17th Nordic Conference on Secure IT Systems (NordSec 2012), volume 7617 of
Lecture Notes in Computer Science, pages 1–16. Springer-Verlag, 2012.
[12] Roel Verdult, Flavio D. Garcia, and Barı¸s Ege. Dismantling megamos crypto:
Wirelessly lockpicking a vehicle immobilizer. In 22nd USENIX Security Symposium (USENIX Security 2013). USENIX Association, 2013.
[13] Willem Burgers, Roel Verdult, and Marko van Eekelen. Prevent session hijacking by binding the session to the cryptographic network credentials. In
18th Nordic Conference on Secure IT Systems (NordSec 2013), volume 8208 of
Lecture Notes in Computer Science, pages 33–50. Springer-Verlag, 2013.
Manuscripts and Technical Reports
[1] Roel Verdult. Proof of concept, cloning the OV-chip card. Technical report,
Radboud University Nijmegen, January 2008.
271
[2] Ronny Wichers Schreur, Peter van Rossum, Flavio Garcia, Wouter Teepe, JaapHenk Hoepman, Bart Jacobs, Gerhard de Koning Gans, Roel Verdult, Ruben
Muijrers, Ravindra Kali, and Vinesh Kali. Security flaw in MIFARE Classic. Press release, Digital Security group, Radboud University Nijmegen, The
Netherlands, March 2008.
[3] Roel Verdult. Security analysis of RFID tags. Master’s thesis, Radboud University Nijmegen, July 2008.
[4] Flavio D. Garcia, Gerhard de Koning Gans, and Roel Verdult. Tutorial: Proxmark, the swiss army knife for RFID security research. Tutorial at 8th Workshop
on RFID Security and Privacy (RFIDSec 2012), Radboud University Nijmegen,
2012.
Curriculum Vitae
Roel Verdult was born on the 20th of October 1982 in Zevenaar, The Netherlands. In
2004 he obtained his BSc from the Faculty of Engineering, at the HAN University of
Applied Sciences, The Netherlands. He continued his master’s degree at the Radboud
University Nijmegen and followed the security research track of the computer science
department. In 2008 he obtained his MSc degree from the Radboud University Nijmegen, The Netherlands. His thesis, entitled “Security Analysis of RFID Tags”, has
been awarded with the highest possible grade.
In July 2008, he joined the Digital Security group at the Faculty of Science of
the Radboud University Nijmegen as an assistant researcher. In 2011 he became a
PhD student under the supervision of prof. dr. Bart Jacobs and dr. Lejla Batina.
His research has been funded by a joint PhD grant between the universities Radboud
University Nijmegen, The Netherlands and KU Leuven, Belgium.
His research covers a variety of security topics which include (but are not limited
to) the electronic passports, contactless smartcards, Radio Frequency Identification
(RFID), Near Field Communication (NFC), secure storage, authentication protocols
and other types of transmission security. The relevance of his research is recognized
by the significant awards received from national and international institutions:
• International Hermesdorf Prize
Radboud University Nijmegen award for special attention in the media during
2013, January 2014
• Best Paper Award
USENIX Workshop on Offensive Technologies 2011, Augustus 2011
• Outstanding Paper Award
IEEE Symposium on Security and Privacy 2009, May 2009
• Most Appealing Master Thesis
Aia Software Master Thesis Award, January 2009
274
Curriculum vitae
• National student of the year
Dutch award was presented by LSVB, ISO and ScienceGuide, November 2008
• Information Security Award
Joop Bautz nomination, October 2008
• NWO I/O Award
Netherlands Organisation for Scientific Research (NWO), September 2008
• Gratuity for the MIFARE Classic research
Radboud University Nijmegen, September 2008
Titles in the IPA Dissertation Series since 2009
M.H.G. Verhoef. Modeling and Validating Distributed Embedded Real-Time
Control Systems. Faculty of Science,
Mathematics and Computer Science,
RU. 2009-01
M. de Mol. Reasoning about Functional Programs: Sparkle, a proof assistant for Clean.
Faculty of Science, Mathematics and Computer Science, RU. 2009-02
M. Lormans. Managing Requirements
Evolution. Faculty of Electrical Engineering, Mathematics, and Computer
Science, TUD. 2009-03
M.P.W.J. van Osch.
Automated
Model-based Testing of Hybrid Systems.
Faculty of Mathematics and Computer
Science, TU/e. 2009-04
H. Sozer. Architecting Fault-Tolerant
Software Systems. Faculty of Electrical
Engineering, Mathematics & Computer
Science, UT. 2009-05
M.J. van Weerdenburg.
Efficient Rewriting Techniques.
Faculty
of Mathematics and Computer Science,
TU/e. 2009-06
H.H. Hansen. Coalgebraic Modelling:
Applications in Automata Theory and
Modal Logic. Faculty of Sciences, Division of Mathematics and Computer Science, VUA. 2009-07
A. Mesbah.
Analysis and Testing
of Ajax-based Single-page Web Applications. Faculty of Electrical Engineering, Mathematics, and Computer Science, TUD. 2009-08
A.L. Rodriguez Yakushev. Towards
Getting Generic Programming Ready
for Prime Time. Faculty of Science,
UU. 2009-9
K.R. Olmos Joffré. Strategies for
Context Sensitive Program Transformation. Faculty of Science, UU. 2009-10
J.A.G.M. van den Berg. Reasoning about Java programs in PVS using
JML. Faculty of Science, Mathematics
and Computer Science, RU. 2009-11
M.G. Khatib. MEMS-Based Storage Devices. Integration in EnergyConstrained Mobile Systems. Faculty of
Electrical Engineering, Mathematics &
Computer Science, UT. 2009-12
S.G.M. Cornelissen. Evaluating Dynamic Analysis Techniques for Program
Comprehension. Faculty of Electrical
Engineering, Mathematics, and Computer Science, TUD. 2009-13
D. Bolzoni.
Revisiting Anomalybased Network Intrusion Detection Systems. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2009-14
H.L. Jonker. Security Matters: Privacy in Voting and Fairness in Digital
Exchange. Faculty of Mathematics and
Computer Science, TU/e. 2009-15
M.R. Czenko. TuLiP - Reshaping
Trust Management. Faculty of Electrical
T. Chen.
Clocks, Dice and Processes. Faculty of Sciences, Division
VUA. 2009-17
C. Kaliszyk. Correctness and Availability: Building Computer Algebra on
top of Proof Assistants and making Proof
Assistants available over the Web. Faculty of Science, Mathematics and Computer Science, RU. 2009-18
R.S.S. O’Connor. Incompleteness &
Completeness: Formalizing Logic and
Analysis in Type Theory. Faculty of Science, Mathematics and Computer Science, RU. 2009-19
B. Ploeger.
Improved Verification
Methods for Concurrent Systems. Faculty of Mathematics and Computer Science, TU/e. 2009-20
T. Han.
Diagnosis, Synthesis and
Analysis of Probabilistic Models. Faculty
of Electrical Engineering, Mathematics
& Computer Science, UT. 2009-21
R. Li. Mixed-Integer Evolution Strategies for Parameter Optimization and
Their Applications to Medical Image
Analysis. Faculty of Mathematics and
Natural Sciences, UL. 2009-22
J.H.P. Kwisthout. The Computational Complexity of Probabilistic Networks. Faculty of Science, UU. 2009-23
T.K. Cocx.
Algorithmic Tools for
Data-Oriented Law Enforcement. Faculty of Mathematics and Natural Sciences, UL. 2009-24
A.I. Baars. Embedded Compilers. Faculty of Science, UU. 2009-25
M.A.C. Dekker. Flexible Access Control for Dynamic Collaborative Environ-
ments. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2009-26
J.F.J. Laros. Metrics and Visualisation for Crime Analysis and Genomics.
Faculty of Mathematics and Natural Sciences, UL. 2009-27
C.J. Boogerd. Focusing Automatic
Code Inspections. Faculty of Electrical
Engineering, Mathematics, and Computer Science, TUD. 2010-01
M.R. Neuh¨
au484er. Model Checking
Nondeterministic and Randomly Timed
Systems. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2010-02
J. Endrullis. Termination and Productivity. Faculty of Sciences, Division
VUA. 2010-03
T. Staijen. Graph-Based Specification
and Verification for Aspect-Oriented
Languages. Faculty of Electrical Engineering, Mathematics & Computer Science, UT. 2010-04
Y. Wang. Epistemic Modelling and
Protocol Dynamics. Faculty of Science,
UvA. 2010-05
J.K. Berendsen. Abstraction, Prices
and Probability in Model Checking
Timed Automata. Faculty of Science,
RU. 2010-06
A. Nugroho. The Effects of UML Modeling on the Quality of Software. Faculty
of Mathematics and Natural Sciences,
UL. 2010-07
A. Silva. Kleene Coalgebra. Faculty
of Science, Mathematics and Computer
Science, RU. 2010-08
J.S. de Bruin. Service-Oriented Discovery of Knowledge - Foundations, Implementations and Applications. Faculty
UL. 2010-09
D. Costa. Formal Models for Component Connectors. Faculty of Sciences,
Division of Mathematics and Computer
Science, VUA. 2010-10
M.M. Jaghoori. Time at Your Service: Schedulability Analysis of RealTime and Distributed Services. Faculty
UL. 2010-11
R. Bakhshi. Gossiping Models: Formal
Analysis of Epidemic Protocols. Faculty
of Sciences, Department of Computer
Science, VUA. 2011-01
B.J. Arnoldus. An Illumination of
the Template Enigma: Software Code
Generation with Templates.
Faculty
TU/e. 2011-02
E. Zambon.
Towards Optimal IT
Availability Planning: Methods and
Tools. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2011-03
L. Astefanoaei. An Executable Theory of Multi-Agent Systems Refinement.
J. Proenc
¸a. Synchronous coordination of distributed components. Faculty
UL. 2011-05
A. Moralı. IT Architecture-Based Confidentiality Risk Assessment in Networks
of Organizations. Faculty of Electrical
M. van der Bijl. On changing models in Model-Based Testing. Faculty of
C. Krause. Reconfigurable Component
Connectors. Faculty of Mathematics
and Natural Sciences, UL. 2011-08
M.E. Andrés. Quantitative Analysis
of Information Leakage in Probabilistic
and Nondeterministic Systems. Faculty
of Science, Mathematics and Computer
Science, RU. 2011-09
M. Atif. Formal Modeling and Verification of Distributed Failure Detectors.
P.J.A. van Tilburg.
From Computability to Executability – A processtheoretic view on automata theory. Faculty of Mathematics and Computer Science, TU/e. 2011-11
Z. Protic.
Configuration management for models: Generic methods
for model comparison and model coevolution. Faculty of Mathematics and
S. Georgievska. Probability and Hiding in Concurrent Processes. Faculty
TU/e. 2011-13
S. Malakuti.
Event Composition
Model: Achieving Naturalness in Runtime Enforcement. Faculty of Electrical
M. Raffelsieper. Cell Libraries and
Verification. Faculty of Mathematics
and Computer Science, TU/e. 2011-15
C.P. Tsirogiannis. Analysis of Flow
and Visibility on Triangulated Terrains.
Y.-J. Moon. Stochastic Models for
Quality of Service of Component Connectors. Faculty of Mathematics and
R. Middelkoop. Capturing and Exploiting Abstract Views of States in OO
Verification. Faculty of Mathematics
M.F. van Amstel. Assessing and Improving the Quality of Model Transformations. Faculty of Mathematics and
A.N. Tamalet. Towards Correct Programs in Practice.
Faculty of Science, Mathematics and Computer Science, RU. 2011-20
H.J.S. Basten. Ambiguity Detection
for Programming Language Grammars.
Faculty of Science, UvA. 2011-21
S. Kemper. Modelling and Analysis of
Real-Time Coordination Patterns. Faculty of Mathematics and Natural Sciences, UL. 2011-24
J. Wang. Spiking Neural P Systems.
A. Khosravi. Optimal Geometric Data
Structures. Faculty of Mathematics and
A. Middelkoop. Inference of Program Properties with Attribute Grammars, Revisited. Faculty of Science,
UU. 2012-02
Z. Hemel. Methods and Techniques
for the Design and Implementation of
Domain-Specific Languages.
Faculty
of Electrical Engineering, Mathematics,
and Computer Science, TUD. 2012-03
T. Dimkov. Alignment of Organizational Security Policies: Theory and
Practice. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2012-04
S. Sedghi. Towards Provably Secure Efficiently Searchable Encryption. Faculty
M. Izadi. Model Checking of Component Connectors. Faculty of Mathematics and Natural Sciences, UL. 2011-22
F. Heidarian Dehkordi.
Studies
on Verification of Wireless Sensor Networks and Abstraction Learning for System Inference.
Faculty of Science,
RU. 2012-06
L.C.L. Kats. Building Blocks for Language Workbenches. Faculty of Electrical Engineering, Mathematics, and
Computer Science, TUD. 2011-23
K. Verbeek.
Algorithms for Cartographic Visualization.
Faculty of
TU/e. 2012-07
D.E. Nadales Agut. A Compositional
Interchange Format for Hybrid Systems:
Design and Implementation. Faculty of
Mechanical Engineering, TU/e. 2012-08
H. Beohar. Refinement of Communication and States in Models of Embedded
Systems. Faculty of Mathematics and
H. Rahmani. Analysis of ProteinProtein Interaction Networks by Means
of Annotated Graph Mining Algorithms.
G. Igna. Performance Analysis of RealTime Task Systems using Timed Automata. Faculty of Science, Mathematics and Computer Science, RU. 2013-02
S.D. Vermolen. Software Language
Evolution. Faculty of Electrical Engineering, Mathematics, and Computer
L.J.P. Engelen. From Napkin Sketches
to Reliable Software.
Faculty of
TU/e. 2012-11
F.P.M. Stappers. Bridging Formal
Models – An Engineering Perspective.
W. Heijstek.
Software Architecture Design in Global and ModelCentric Software Development. Faculty
UL. 2012-13
C. Kop. Higher Order Termination.
Faculty of Sciences, Department of Computer Science, VUA. 2012-14
E. Zambon. Abstract Graph Transformation – Theory and Practice. Faculty
B. Lijnse. TOP to the Rescue – TaskOriented Programming for Incident Response Applications. Faculty of Science, Mathematics and Computer Science, RU. 2013-04
G.T. de Koning Gans. Outsmarting Smart Cards. Faculty of Science,
RU. 2013-05
M.S. Greiler. Test Suite Comprehension for Modular and Dynamic Systems. Faculty of Electrical Engineering, Mathematics, and Computer Science, TUD. 2013-06
L.E. Mamane. Interactive mathematical documents: creation and presentation. Faculty of Science, Mathematics
A. Osaiweran. Formal Development of
Control Software in the Medical Systems
Domain. Faculty of Mathematics and
M.M.H.P. van den Heuvel. Composition and synchronization of real-time
components upon one processor. Faculty
TU/e. 2013-08
W. Kuijper. Compositional Synthesis
of Safety Controllers. Faculty of Electrical Engineering, Mathematics & Computer Science, UT. 2012-16
J. Businge. Co-evolution of the Eclipse
Framework and its Third-party Plug-ins.
S. van der Burg. A Reference Architecture for Distributed Software Deployment. Faculty of Electrical Engineering, Mathematics, and Computer Science, TUD. 2013-10
J.J.A. Keiren. Advanced Reduction
Techniques for Model Checking. Faculty
TU/e. 2013-11
D.H.P. Gerrits. Pushing and Pulling:
Computing push plans for disk-shaped
robots, and dynamic labelings for moving points. Faculty of Mathematics and
M. Timmer. Efficient Modelling, Generation and Analysis of Markov Automata. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2013-13
M.J.M. Roeloffzen. Kinetic Data
Structures in the Black-Box Model. Faculty of Mathematics and Computer Science, TU/e. 2013-14
L. Lensink. Applying Formal Methods
in Software Development. Faculty of Science, Mathematics and Computer Science, RU. 2013-15
C. Tankink. Documentation and Formal Mathematics — Web Technology
meets Proof Assistants. Faculty of Science, Mathematics and Computer Science, RU. 2013-16
C. de Gouw. Combining Monitoring
with Run-time Assertion Checking. Faculty of Mathematics and Natural Sciences, UL. 2013-17
J. van den Bos. Gathering Evidence:
Model-Driven Software Engineering in
Automated Digital Forensics. Faculty of
Science, UvA. 2014-01
D. Hadziosmanovic.
The Process
Matters: Cyber Security in Industrial
Control Systems. Faculty of Electrical
A.J.P. Jeckmans. CryptographicallyEnhanced Privacy for Recommender
Systems. Faculty of Electrical Engineering, Mathematics & Computer Science,
UT. 2014-03
C.-P. Bezemer. Performance Optimization of Multi-Tenant Software Systems. Faculty of Electrical Engineering, Mathematics, and Computer Science, TUD. 2014-04
T.M. Ngo. Qualitative and Quantitative Information Flow Analysis for
Multi-threaded Programs. Faculty of
A.W. Laarman. Scalable Multi-Core
Model Checking. Faculty of Electrical
J. Winter. Coalgebraic Characterizations of Automata-Theoretic Classes.
Faculty of Science, Mathematics and
Computer Science, RU. 2014-07
W. Meulemans.
Similarity Measures and Algorithms for Cartographic
Schematization. Faculty of Mathematics
A.F.E. Belinfante. JTorX: Exploring
Model-Based Testing. Faculty of Electrical Engineering, Mathematics & Computer Science, UT. 2014-09
A.P. van der Meer. Domain Specific
Languages and their Type Systems. Faculty of Mathematics and Computer Science, TU/e. 2014-10
B.N. Vasilescu. Social Aspects of Collaboration in Online Software Communities. Faculty of Mathematics and Computer Science, TU/e. 2014-11
A.J. van der Ploeg. Efficient Abstractions for Visualization and Interaction.
Faculty of Science, UvA. 2015-02
R.J.M. Theunissen.
Supervisory
Control in Health Care Systems.
Faculty of Mechanical Engineering,
TU/e. 2015-03
F.D. Aarts. Tomte: Bridging the Gap
between Active Learning and Real-World
Systems. Faculty of Science, Mathematics and Computer Science, RU. 2014-12
T.V. Bui. A Software Architecture
for Body Area Sensor Networks: Flexibility and Trustworthiness.
Faculty
TU/e. 2015-04
N. Noroozi. Improving Input-Output
Conformance Testing Theories. Faculty
TU/e. 2014-13
A. Guzzi.
Supporting Developers’
Teamwork from within the IDE. Faculty
of Electrical Engineering, Mathematics,
and Computer Science, TUD. 2015-05
M. Helvensteijn. Abstract Delta Modeling: Software Product Lines and Beyond. Faculty of Mathematics and Natural Sciences, UL. 2014-14
T. Espinha.
Web Service Growing Pains: Understanding Services and
Their Clients. Faculty of Electrical Engineering, Mathematics, and Computer
P. Vullers. Efficient Implementations
of Attribute-based Credentials on Smart
Cards. Faculty of Science, Mathematics
F.W. Takes. Algorithms for Analyzing
and Mining Real-World Graphs. Faculty
UL. 2014-16
M.P. Schraagen. Aspects of Record
Linkage. Faculty of Mathematics and
G. Alpár.
Attribute-Based Identity Management: Bridging the Cryptographic Design of ABCs with the Real
World. Faculty of Science, Mathematics
S. Dietzel. Resilient In-network Aggregation for Vehicular Networks. Faculty
E. Costante. Privacy throughout the
Data Cycle. Faculty of Mathematics and
S. Cranen. Getting the point — Obtaining and understanding fixpoints in
model checking. Faculty of Mathematics
R. Verdult. The (in)security of proprietary cryptography. Faculty of Science, Mathematics and Computer Science, RU. 2015-10

The (in)security of proprietary cryptography

Transcription

Similar documents

PigPen Cipher Worksheet

CSE5473 Homework 1 (due Wednesday, February 11) 0. A

Celebrity Cipher - The Baytown Sun

Cipher Type Detection

NET 311 D Project

Document 6517139

CA SiteMinder® SPS Integrated Documents 12.52

Classical Techniques: Substitution  Substitute a character, digit or symbol for each

Faculty of Computers & Information Computer Networks