further updates to the paper
This commit is contained in:
parent
17236b5612
commit
6a639f6c80
|
@ -96,17 +96,17 @@ transponder.
|
|||
\subsection{Attempting to use standard keys}
|
||||
|
||||
As some users of MIFARE Classic systems only use some sectors of a card, but
|
||||
not all, an attempt was made to authenticate to any of the blocks using the
|
||||
manufacturer-programmed standard keys. However, none of the card blocks were
|
||||
not all, an attempt was made to authenticate to any of the sectors using the
|
||||
manufacturer-programmed standard keys. However, none of the card sectors were
|
||||
using those standard keys.
|
||||
|
||||
This also means that we could not use the key recovery method described in
|
||||
FIXME, where keys of all other blocks are recovered based on the knowledge of
|
||||
they key of at least one different blocks.
|
||||
FIXME, where keys of all other sectors are recovered based on the knowledge of
|
||||
they key of at least one different sectors.
|
||||
|
||||
\subsection{Recovering the MIFARE CRYPTO1 keys}
|
||||
|
||||
Since none of the block keys was known, the publicly available MFCUK (MiFare
|
||||
Since none of the sector keys was known, the publicly available MFCUK (MiFare
|
||||
Classic Universal toolKit) implementation of the "Dark Side" attack (Nicolas T.
|
||||
Courtois) was used as a card-only attack.
|
||||
|
||||
|
@ -114,7 +114,7 @@ All that was required was the MFCUK Free Software, as well as a RFID
|
|||
reader as supported by libnfc. Compatible readers are widely available,
|
||||
among them one for EUR 30 from http://www.touchatag.com/e-store.
|
||||
|
||||
Using the MFCUK key recovery tool, the A and B keys for all blocks have
|
||||
Using the MFCUK key recovery tool, the A and B keys for all sectors have
|
||||
been recovered within FIXME. This attack can definitely be optimized
|
||||
by using special-purpose hardware such as the Proxmark, which gives
|
||||
hard-realtime control over the communication with the EasyCard.
|
||||
|
@ -124,7 +124,7 @@ common to all cards.
|
|||
|
||||
\subsection{Dumping the content of the EasyCard}
|
||||
|
||||
Once the block keys have all been recovered, the full content of the EasyCard
|
||||
Once the sector keys have all been recovered, the full content of the EasyCard
|
||||
can be dumped using any RFID reader supporting MIFARE Classic. The author
|
||||
chose to use the same reader that was used for the MFCUK key recovery combined
|
||||
with the nfc-mfclassic program (part of libnfc).
|
||||
|
@ -228,12 +228,12 @@ The result of this analysis can be found in the next section:
|
|||
|
||||
\section{Re-engineered EasyCard Data Format}
|
||||
|
||||
\subsubsection{Block 0 and 1: The header}
|
||||
\subsubsection{Sector 0 and 1: The header}
|
||||
FIXME
|
||||
|
||||
\subsubsection{Block 2: The card balance as value block}
|
||||
\subsubsection{Sector 2: The card balance as value block}
|
||||
|
||||
The first two sectors of Block 2 store the current remaining debit account
|
||||
The first two blocks of sector 2 store the current remaining debit account
|
||||
balance as a MIFARE Classic VALUE BLOCK. The format of this block is
|
||||
documented in the official NXP vendor documentation on the MIFARE chip
|
||||
used inside the card.
|
||||
|
@ -241,16 +241,16 @@ used inside the card.
|
|||
The value block is decremented every time payment is made with the card.
|
||||
|
||||
Given the MIFARE access bits, it is assumed that the RFID readers in public
|
||||
transportation as well as stores use key A for this block, as key A is
|
||||
transportation as well as stores use key A for this sector, as key A is
|
||||
sufficient to read and decrement the VALUE block.
|
||||
|
||||
Re-charging the card must happen using authentication with key B, as only
|
||||
Key B has permissions to increment and/or write to this block.
|
||||
Key B has permissions to increment and/or write to this sector.
|
||||
|
||||
\subsubsection{Block 3 through 5: The transaction log}
|
||||
\subsubsection{Sector 3 through 5: The transaction log}
|
||||
|
||||
Every time a transaction is made with the card, an entry in the transaction log
|
||||
on the card itself is generated. Every entry occupies one full 16-byte sector.
|
||||
on the card itself is generated. Every entry occupies one full 16-byte block.
|
||||
|
||||
The structure of a transaction log entry is as follows:
|
||||
\begin{itemize}
|
||||
|
@ -296,9 +296,9 @@ the same number in this field.
|
|||
|
||||
FIXME: Transaction log pointer
|
||||
|
||||
\subsubsection{Block 7: The last MRT entry/exit record}
|
||||
\subsubsection{Sector 7: The last MRT entry/exit record}
|
||||
|
||||
Sector 2 (Offset 0x1e0) contains a record dscribing the last MRT station
|
||||
Block 2 (Offset 0x1e0) contains a record dscribing the last MRT station
|
||||
that was entered using this EasyCard.
|
||||
\begin{itemize}
|
||||
\item Bytes 0...3 are unknown
|
||||
|
@ -308,7 +308,7 @@ that was entered using this EasyCard.
|
|||
\item Bytes 13..15 are unknown
|
||||
\end{itemize}
|
||||
|
||||
Sector 1 (Offset 0xd0) of the same sector contains a record using the same
|
||||
Block 1 (Offset 0xd0) of the same sector contains a record using the same
|
||||
structure. However, this record describes the last MRT station that was
|
||||
left using this EasyCard.
|
||||
|
||||
|
@ -316,7 +316,7 @@ It is assumed that this information is used by the system to compute both the
|
|||
distance (and thus fee) to be paid by the current ride, as well as any
|
||||
applicable discount in case a connection is made from MRT into a bus.
|
||||
|
||||
\subsubsection{Block 15: Maximum daily spending}
|
||||
\subsubsection{Sector 15: Maximum daily spending}
|
||||
|
||||
Sector 2 (Offset 0x3e0) contains a record used for keeping track of
|
||||
the amount of money spent on a single day. This is needed in order
|
||||
|
@ -338,13 +338,51 @@ card, the sum is re-set and starts new for that day.
|
|||
\section{Manipulating the EasyCard}
|
||||
|
||||
\subsection{Decreasing the Value of the card}
|
||||
FIXME
|
||||
|
||||
In order to decrease the account balance on the card, the following method
|
||||
was tested:
|
||||
|
||||
\begin{itemize}
|
||||
\item Make a purchase in a retail store that accepts the EasyCard
|
||||
\item Find the transaction log entry regarding this purchase and increase the transaction cost by some value. NTD 200 was chosen in this example. Decrease the {\em amount remaining after transaction} field accordingly by the same amount.
|
||||
\item Alter the two VALUE blocks in Sector 2 to reflect the subtracted amount. Make sure the backup copies (inverted and non-inverted) are updated, too.
|
||||
\item Alter the {\em amount spent per day} in Sector 15 to reflect the increased amount spent.
|
||||
\end{itemize}
|
||||
|
||||
Payment using the manipulated card was possible without any problem, provided
|
||||
that the to-be-paid amount is less than what the card considers the remaining
|
||||
balance.
|
||||
|
||||
Re-reading the card after the purchase indicates the full success of the
|
||||
operation. The purchase has left exactly the same changes in the card like
|
||||
it would have with a card that has a genuine lower value. None of the
|
||||
erroneosly increased (or decreased) numbers had been updated.
|
||||
|
||||
This specifically confirms that the vending terminal did not have an online
|
||||
connection to a centralized database. In that case, the erroneous values
|
||||
on the card would have been corrected and the original value restored.
|
||||
|
||||
\subsection{Increaing the value of the card}
|
||||
FIXME
|
||||
|
||||
The approach works similar to the previous one. First, a purchase in a store
|
||||
is being made, preferrably with relatively high value. Later, the transaction
|
||||
log record, card balance and amount spent per day fields are modified to make
|
||||
this purchase appear cheaper than it actually was. So after purchasing an item
|
||||
with 1000 NTD, the card will look like only 100 NTD were spent for the purchase,
|
||||
giving an extra balance of 900 NTD to the attacker.
|
||||
|
||||
\subsection{Bypassing the maximum daily spending of NTD 3000}
|
||||
FIXME
|
||||
|
||||
As the sum of all purchases on a given day-of-the-month is stored in Sector 15,
|
||||
there are two methods of evading the per-day payment limit:
|
||||
\begin{itemize}
|
||||
\item Simply zero-out the amount of money spent today, or
|
||||
\item simply alter the day-of-the-month field to a different day.
|
||||
\end{itemize}
|
||||
Both options might cause problems in case the terminal does consistency checks
|
||||
with the transaction log. So it would be wise for an attacker to also modify
|
||||
all purchases in the transaction log to appear as if they were made on a
|
||||
previous day.
|
||||
|
||||
\section{Mistakes of the EasyCard Corporation}
|
||||
|
||||
|
|
Loading…
Reference in New Issue