Cryptography Reference
In-Depth Information
adversary can write all previously read data to a blank Mifare Classic card. This
results in an almost perfect clone, differing from the original only in the single
block containing the read-only UID of the blank card. If the UID is verified by a
contactless system (compare with [16]), this type of card-cloning becomes useless
in practice. To allow for perfect clones, we implemented the features of Mifare
Classic on Chameleon. Thus, we have complete control of the content of every
memory block, including the previously unchangeable manufacturer block.
Optimized Crypto1.
A first approach to emulate a Mifare Classic card on
an AVR ATmega32 microcontroller [22] revealed diculties in complying to
the timing requirements given in ISO 14443. After a command is issued by the
reader, the card has to reply within 4.8 ms, or the reader will reach a timeout and
abort the connection. Compiling the open-source Crypto1 C-library [6] for an 8-
bit microcontroller results in inecient code regarding the underlying platform.
Hence, in [22] the time limit of 4.8 ms set in the protocol is exceeded with 11.7 ms
for an 18-byte encryption, neglecting all other necessary computations, such as
encoding the encrypted data. Since an 18-byte encryption is required every time
when reading or writing a block with appended CRC checksum, the existing
implementation is not suitable.
It became obvious that a significant speedup of Crypto1 is essential for a
successful Mifare Classic emulation. Hence, we implemented the cipher from the
scratch in AVR assembly. This allows to optimize the code for an 8-bit platform
and make use of special commands that may not be considered by the C compiler.
Using instructions to access bits of registers directly, the amount of clock cycles
required for an encryption was reduced, amongst others by replacing inecient
shifting and masking operations to access single bits with instructions that allow
accessing a particular bit in one clock cycle (e.g., SBRC, BST, BLD). We further
implemented the non-linear filter functions
f
a
,
f
b
and
f
c
of Crypto1 with lookup
tables to avoid time consuming boolean AND, OR and XOR operations. In the
first stage,
f
a
is used two and
f
b
three times with a 4-bit input of the state LFSR.
Their output is used to generate a 5-bit input to
f
c
, which in turn generates one
bit of keystream. For both
f
a
and
f
b
, we created a dedicated lookup table that
includes the respective shifting of the output. Thereby, the input of
f
c
can be
easily obtained by ORing the five outputs of
f
a
and
f
b
. This speed advantage
comes at the cost of storing one bit of information in one byte of memory. Finally,
the lookup table
f
c
is a simple 5-bit input, 1-bit output table. The overall size of
the lookup tables is 112 byte, formed by two 16-byte tables for
f
a
, three 16-byte
tables for
f
b
and one 32-byte table for
f
c
. With respect to the 192 kByte size of
the program memory, the tables are negligibly small.
Furthermore, we applied the idea of precomputation. When the nonce
n
C
is fixed before the authentication protocol is executed, the card is able to pre-
compute the corresponding answers
a
R
and
a
C
which saves time during the au-
thentication process. Precomputation of keystream bits is not possible because
of two reasons. Firstly, since the sector to be accessed by the reader cannot be
predicted, it is not clear which key has to be loaded into the LFSR. Secondly, the
Search WWH ::
Custom Search