further updates to the paper

1 files changed, 59 insertions, 21 deletions

diff --git a/paper/easycard.tex b/paper/easycard.tex
index 0e6cb30..9947179 100644
--- a/paper/easycard.tex
+++ b/paper/easycard.tex
@@ -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}