main.tex

\documentclass{article}
\input{preamble}
\begin{document}

\maketitle

% Project Information sheet:
% http://www.cs.ru.nl/~erikpoll/spp/javacard_project.pdf

The source code belonging to this document can be found at \href{https://github.com/pohlm01/Security-Protocol-Project-Code}{GitHub}\footnote{\url{https://github.com/pohlm01/Security-Protocol-Project-Code}}.

\section{Use Cases}
Our group decided to design, develop and implement an electronic purse system.
This system consists of the following components:
\begin{itemize}
    \item Smart cards
    \item Reload terminals
    \item POS (point-of-sale) terminals
    \item Initialization terminals
    \item A back end
\end{itemize}
The issuer of the cards uses the initialization terminal to initialize a new card and deliver the initialized card to the end user.
At every reload terminal, the user can load money on their smart card and can pay for goods and services at every POS terminal that salesmen supply.
An example application for this system is a university canteen.
Students can load money on their student cards at reload terminals.
Later, they can pay for lunch and food at the POS terminals in the university canteen.
We will define the following use cases:
\begin{enumerate}[label={UC\arabic*:}, ref={UC\arabic*}, leftmargin=3\parindent]
    \item \label{uc:person} The card is initialized at an initialization terminal once before being provided to the end user.
    
    \item \label{uc:reload} At a reload terminal, the end user can increase the balance of the smart card by paying with cash or with a bank card.
    
    \item \label{uc:payment} At the POS terminal, the end user can pay for goods and services with the smart card.
    A user can use a POS terminal, even if the terminal is not connected to the back end (offline).

    \item A POS or reload terminal can be deactivated remotely with some delay (e.g., one week).
    
    \item The end user can declare the card as lost or stolen, which results in the card being blocked.
    For the sake of simplicity of the protocol, we do not allow the unblocking of a blocked card.
    
\end{enumerate}
\subsection{Lifecycle}
The smart-card lifecycle is depicted in Figure~\ref{fig:lifecycle}.
In the \emph{Initial} state, the program is already loaded on the card, but no data exist yet.
In an actual application, the possibility to upload other applets or remove existing ones would already be disabled at this stage.

By uploading the required data onto the card, the card will move to the state \emph{Personalized}.
This is done with the initialization terminal and the initialization protocol as described in Section~\ref{sec:perProtocol}.
At this stage, the card is still in possession of the card issuer.
By handing the card over to the end user, the card transits to the \emph{Issued} state.
Internally to the card, this does not make a difference to the previous state.

We decide between two end states.
Either a card gets \emph{Blocked} because it was lost or stolen, or it moves to the \emph{End-of-Live} state because it reached its expiration date or the transaction counter, which is explained later, overflows.
The two end states do not make a difference internally to the card, both result in the card refusing any interaction.
A card that is blocked or End-of-Live cannot be unblocked.

\begin{figure}
    \centering
    \input{figures/lifecycle}
    \caption{Lifecycle of the smart-card}
    \label{fig:lifecycle}
\end{figure}


\section{Attacker Model}\label{attackerModel}
To understand possible attack scenarios, we must first list what a potential attack would like to achieve.
The goals of an attacker, i.e., the threats considered in our protocol, are:
\begin{enumerate}[label={T\arabic*:}, leftmargin=2\parindent, ref={T\arabic*}]
    \item \label{threat:increaseWithoutPaying}
    The end user is interested in increasing their balance (which is stored on the card) without actually paying for it.
    
    \item \label{threat:payWithoutDecrease}
    The end user is interested in forging a payment such that the POS terminal shows a successful transaction without the card's balance decreasing.
    
    \item \label{threat:denyPayment}
    The end user is interested in denying having done a payment that actually happened, in order to get the money back.
    
    \item \label{threat:forgingPayments} The salesman is interested in forging payments by either 
    \begin{enumerate}[ref={\theenumi~\alph*}]
        \item \label{threat:inventNewPayments}
        inventing payments that never happened or
        \item \label{threat:alterPaymentDetails}
        by altering the details of payments that happened, such as the money source and destination or the amount transferred.
    \end{enumerate}
        
    \item \label{threat:chargeMoreThanDisplayed}
    The salesman is interested in charging more money than shown on the terminal display (if there is any).

    \item \label{threat:invaldTermial} A third person is interested in operating unauthorized POS terminals to collect payment proofs and get the money from the institution operating the system, e.g., by inserting the collected payment proofs into the log of a valid terminal.

    \item \label{threat:stolenCard} A third person is interested in using a stolen or lost card to pay with it at POS terminals.
\end{enumerate}

% Power:
%   Active MITM
%   card tear (pulling it out of the terminal while operating)
We assume an attacker that is able to shut down the card and the terminal at any (precise) point in time, e.g., by tearing the card out of the terminal or by removing the power supply of the terminal, respectively.
Additionally, an attacker is capable of performing an active man-in-the-middle attack.
This means it can read and alter any communication between the smart card and the terminal.

% TCB
%   Assume tamper-resistance
%   which persons do we have to trust?
On the other hand, we assume the smart cards and terminals to be tamper resistant.
This means it is not possible for an attacker to extract key material from the card or terminal, and the software and data stored are integer and cannot be changed.
Still, we do not want the security of the whole system to be compromised in case of a single failure in this assumption.

Furthermore, we have to trust the correctness of data fed to the terminals, e.g., the reload terminal being able to correctly count the cash inserted and that nobody tampers with the connection between the money counting machine and the terminal.
Likewise, we have to trust the clock signal the terminal provides to the card, as the card cannot keep track of time itself.
Moreover, we assume that communication between the back end and the terminals is secure.

We also do not specifically secure the initialization step.
Securing the initialization is not needed, as this functionality is already disabled when the card is given to the end user.
It is also impossible to create a valid card in case someone gets their hands on some uninitialized card, as this would require the knowledge of private secrets only known by the back end.
We do not even have to trust the person initializing the cards too much, as the private key of the card is generated within the card and, given that the software was not tampered with, cannot be exported.
The person thus could create a lot of cards with no money on them, which is not too interesting as a business model.


\section{Security Requirements}
Our system will adhere to the following security requirements (SRs). After each SR, we indicate which threat from Section~\ref{attackerModel} it aims to prevent.
\begin{enumerate}[label={SR\arabic*:}, ref={SR\arabic*}, leftmargin=3\parindent]
    \item \label{sr:mutualAuth}
    The card and the reload/POS terminal are mutually authenticated. (\ref{threat:increaseWithoutPaying}, \ref{threat:payWithoutDecrease}, \ref{threat:invaldTermial})
    
    \item \label{sr:messageAuth}
    The increase and decrease balance messages from the reload and POS terminal, respectively, are authenticated. (\ref{threat:increaseWithoutPaying}, \ref{threat:payWithoutDecrease}, \ref{threat:chargeMoreThanDisplayed})
    
    \item \label{sr:replayProtection}
    A message altering a card's balance is usable only once. (\ref{threat:increaseWithoutPaying}, \ref{threat:inventNewPayments})
    
    \item \label{sr:messageIntegrity}
    A breach of integrity in the communication between a card and a reload/POS terminal is noticed. (\ref{threat:increaseWithoutPaying}, \ref{threat:payWithoutDecrease}, \ref{threat:alterPaymentDetails})
    
    \item \label{sr:atomic}
    Money transfer between a card and terminal must behave atomically. (\ref{threat:increaseWithoutPaying}, \ref{threat:payWithoutDecrease})

    \item \label{sr:nonRepudiation}
    A terminal can prove a transaction is being made. (\ref{threat:denyPayment})

    \item \label{sr:block}
    POS and reload terminals as well as cards can be deactivated remotely by trustful parties, i.e., the back end. (\ref{threat:invaldTermial}, \ref{threat:stolenCard})

    \item \label{sr:keyLeakage}
    When a key leaks from either a card or a terminal, the system as a whole should not be compromised. (\ref{threat:increaseWithoutPaying}--\ref{threat:invaldTermial})
\end{enumerate}

We decided against the following security requirements:
\begin{itemize}
    \item We do not encrypt the traffic between the card and the various terminals.
    The reason is that we do not see any relevant threat that would get mitigated by that, and would therefore only complicate the protocol without a real improvement.
    We are unsure if there is any legal requirement to encrypt the traffic, e.g., for privacy reasons.
    If so, the protocol needs to be modified accordingly.
    The same applies if we would use a pin to authenticate the cardholder.
    
    \item We decided against the authentication of the cardholder (e.g., by PIN protection), as we took systems like the Dutch \emph{Chipknip} or the usage of the student identity card for paying in the university canteen in Germany as a model.
\end{itemize}


\section{Key Distribution and Protocols}
\subsection{Notation} \label{sec:notation}
The following notation will be used throughout the section:
\begin{itemize}
    \item Private keys are lowercase
    
    \item Public keys are capitalized
    
    \item The subscript indicates the owner (c: Card, p: POS, r: Reload, b: Back end).
    In some places, the letter t is used to indicate any terminal.

    \item Unique identifiers of the cards and terminals are written as: ID$_{c/r/t}$

    \item The expiration dates are written as: expDate$_{c/r/t}$

    \item Encryption will be notated as: Enc$_{\textrm{Key}}$(Message)

    \item Decryption will be notated as: Dec$_{\textrm{Key}}$(Ciphertext)
    
    \item Computation of a hash will be notated as: H(Message)
    
    \item Certificates will be written as: Cert$_\textrm{owner}^\textrm{issuer}$(attributes)

    \item Signatures will be written as: Sign$_{\textrm{Key}}$(message).
    The notation includes purely the signature, but not the signed content.

    \item Verifying Signatures will be written as: Verif$_{\textrm{Key}}$(signature, message)

    \item ``$\|$'', i.e., two vertical bars, indicate concatenation

    \item The sequence diagram describing the reload and payment protocol has some additional notation to where variables are stored:
    \begin{itemize}
        \item A variable stored in the RAM of the card is marked \ramc{blue}.
        \item A variable stored in the EEPROM of the card is marked \eepromc{red}.
        % \item A variable stored in the RAM of the terminal is written \ramt{italic}.
        % \item A variable stored in the EEPROM of the terminal is \eepromt{underlined}.
    \end{itemize}
\end{itemize}

\subsection{Common Operations}
\begin{itemize}
    \item To verify a certificate, the following steps will be taken:
        \begin{itemize}
            \item Check the expiration date
            \item Verif$_{K_b}$(signature $S$, certificate content)
            \item Check if the usage byte (see Table~\ref{tab:certStructure}) matches
            \item Terminals check if the card ID is part of the most recent CRL\@.
        \end{itemize}

    \item Signatures are calculated as Sign$_{\textrm{Key}}$(message) $\coloneqq$ \textrm{Enc}$_{\textrm{Key}}($H(message)).

    \item Signatures are verified by checking if the decryption of the signature matches the hash of the message.
    Verif$_{\textrm{Key}}$(signature, message) := H(message) $\stackrel{?}{=} \textrm{Dec}_{\textrm{Key}}$(Signature).
\end{itemize}

\subsection{Key and Certificate Distribution}

Table~\ref{tab:keys} shows an overview of the keys used in the protocol.
\begin{table}[ht]
    \centering
    \input{tables/keys}
    \caption{Keys used in the protocol}
    \label{tab:keys}
\end{table}

Table~\ref{tab:certs} gives an overview of all certificates used.

In order to synchronize all transactions with the back end, the reload and POS terminals are required to connect to the back end periodically.
We assume this period to be one week.
To enforce this, the certificates to authenticate the POS and reload terminals are valid for one week at most.
This makes it possible to block cards and to deactivate any fraudulent terminal within one week at most, see Section~\ref{sec:blocking} for details.

\begin{table}[t]
    \centering
    \input{tables/certs}
    \caption{Certificates used in the protocol}
    \label{tab:certs}
\end{table}

Certificates will have the structure as defined in Table~\ref{tab:certStructure}.
\begin{table}[ht]
    \centering
    \begin{tabular}{|p{8cm}|}
    \hline
        ID (card or terminal ID) \\
    \hline
        Expiration date \\
    \hline
        Public key of the certificate owner \\
    \hline
        One byte indicating the intended usage: \texttt{0x01}: card, \texttt{0x02}: POS terminal, \texttt{0x03}: reload terminal \\
    \hline
        $S = \textrm{Sign}_{k_b}$(all of the above) \\
    \hline
    \end{tabular}
    \caption{General structure of the certificates used}
    \label{tab:certStructure}
\end{table}

\subsection{Used Ciphers and Keys}
We used the following ciphers and keys in our implementation:
\begin{itemize}
    \item All keys are 2048-bit RSA keys.
    \item Signatures are generated using the SHA1 digest and RSA with PKCS\#1 padding.
\end{itemize}
We decided on these schemes and key lengths, as they are the most secure versions supported by our JavaCard.

\subsection{Security Protocols}
\subsubsection{Personalization Protocol} \label{sec:perProtocol}
The Personalization Protocol depicted in Figure~\ref{fig:PersonProtocol} describes the steps taken for use case~\ref{uc:person}.
The Initialization Terminal functions as a channel for the back end. 
The smart card is given the public key of the back end and generates its own public-private key-pair in steps~\ref{seq:InitBackendKeyToCard}--\ref{seq:InitGenKey}.
This ensures that only the card knows its private key.
Using freshly generated keys for each card ensures that the whole system stays secure even if a single card gets compromised (\ref{sr:keyLeakage}).

Steps~\ref{seq:InitIdAndDateToCard}--\ref{seq:InitStoreIdAndDate} add the card ID and expiration date to the card.

In steps~\ref{seq:InitSignBackEnd} and~\ref{seq:InitSignatureToCard} the smart card receives the signature of its certificate from the back end.
The protocol finishes with the smart card blocking its initialization functionality and sending a success message to the initialization terminal in steps \ref{seq:InitBlock} and \ref{seq:InitOk}, respectively.

After the initialization process, every smart card contains the following information in the non-volatile memory:
\begin{itemize}
    \item The private key $k_c$ of the card
    \item The certificate of the card consisting of
    \begin{itemize}
        \item the card ID
        \item the expiration date
        \item the public key of the card $K_c$
        \item the byte \texttt{0x01} indicating that it is a \textbf{card} certificate
        \item and the signature with the back end key $k_b$
    \end{itemize}
    \item The public key $K_b$ of the back end
    \item A boolean specifying whether the card is blocked or not
    \item A boolean specifying that the card is initialized and can therefore not be initialized again
\end{itemize}

 \begin{figure}[ht]
     \centering
     \input{figures/PersonProtocol}
     \caption{Personalization Protocol}
     \label{fig:PersonProtocol}
 \end{figure}

\subsubsection{Mutual Authentication} \label{sec:mutualAuth}
The reload and payment protocols are using the same mutual authentication between the card and terminal.
Therefore, Figure~\ref{fig:MutualAuth} shows the authentication procedure used in both protocols.

In steps~\ref{seq:AUTHSendTerminalId}--\ref{seq:AUTHSendCardId}, the card and terminal exchange their metadata, and the card increases its counter in Step~\ref{seq:AUTHIncreaseTerminalCounter} to prevent replay attacks.

In steps~\ref{seq:AUTHSendTerminalKey}--\ref{seq:AUTHSendCardSignature}, the public keys and signatures get exchanged.
Importantly, the card checks the validity of the terminal signature in Step~\ref{seq:AUTHVerifyTerminalSignature} using the public backend key.
The terminal also checks the cards' signature validity in Step~\ref{seq:AUTHVerifCardCert}.
After this step, the card and terminal are passively verified, meaning that a simple replay attack could reach this state.

Steps~\ref{seq:AUTHSendActiveAuth}--\ref{seq:AUTHVerifChallange} make sure that the card and terminal are in the possession of their private keys by letting them sign the terminal or card details including the counter, respectively.
Using the counter ensures that a replay attack is not possible, as each time, there needs to be a different content signed.
After this, the card and terminal are mutually authenticated and the rest of the reload or payment protocol can proceed.

In case, the card got revoked by a valid CRL, the card will get blocked as described in Section~\ref{sec:blockCards}.

\begin{figure}
    \centering
    \input{figures/MutualAuthentication}
    \caption{Mutual authentication protocol.
    See Section~\ref{sec:notation} for details on the notation.
    }
    \label{fig:MutualAuth}
\end{figure}

\subsubsection{Reload Protocol}
The sequence diagram in Figure~\ref{fig:ReloadProtocol} shows the procedure implementing use case~\ref{uc:reload}.

The mutual authentication between the card and the terminal is the same as for~\ref{uc:payment} and therefore separately depicted in Figure~\ref{fig:MutualAuth} and explained in Section~\ref{sec:mutualAuth}.

Figure~\ref{fig:stateMachine} additionally clarifies the state machine implemented by the  RAM-variable ``state'' on the card to detect and ignore out-of-order messages.

\begin{figure}
    \centering
    \input{figures/ReloadProtocol}
    \caption{Protocol to reload the card.
    See Section~\ref{sec:notation} for details on the notation.
    }
    \label{fig:ReloadProtocol}
\end{figure}

The following explains the steps of the reload protocol depicted in Figure~\ref{fig:ReloadProtocol}.

\begin{itemize}
    \item After the mutual authentication described in Section~\ref{sec:mutualAuth} is completed, the terminal asks the user what amount to load on the card and collects the money in Step~\ref{seq:RELaskAmount}.
    \item In Step~\ref{seq:RELSendAmount}, the terminal sends the amount (in Cents) to be reloaded to the card.
    \item In Step~\ref{seq:RELStoreAmount}, the card checks that the amount is positive and stores it in RAM for later use.
    \item In Step~\ref{seq:RELStateAmountReceived}, the card alters it internal state to \texttt{AMOUNT\_RECEIVED} to detect and ignore out-of-order messages in the next function call.

    \item In Step~\ref{seq:RELSendAmountSignature}, the terminal sends a signature over the amount, card counter, and card ID\@.
          This ensures that the previously send amount was not altered on the way.
          Including the card counter and card ID ensures that the signature can never be replayed, as it is guaranteed to be different every time.
          This guarantee is based on the fact that the card, which we consider a trusted computing base, ensures that no counter is used twice, and we do not issue two cards with the same ID\@.

    \item After increasing the counter and verifying the signature in Step~\ref{seq:RELFirstIncreaseCounter} and~\ref{seq:RELVerifAmount}, respectively, the card sets its state to \texttt{RELOAD\_AMOUNT\_AUTHENTICATED} to keep track of the state in Step~\ref{seq:RELStateAmountAuthenticated}.

    \item In Step~\ref{seq:RELSignS4}, the card signs all relevant transaction details.
    After verification in Step~\ref{seq:RELVerifS4}, the terminal keeps a log of the details in Step~\ref{seq:RELLog}, together with this signature serving as proof of the transaction.
    This ensures non-repudiation, as the logged information is enough for a third party to verify that only the legitimate card could have done this payment (\ref{sr:nonRepudiation}).

    \item In steps~\ref{seq:RELSignS5}--\ref{seq:RELVerifS5} we increase the card counter once again and send a signature from the terminal to the card.
          That way, the card can verify that the terminal successfully logged the transaction and can therefore actually increase the balance in Step~\ref{seq:RELalterBalance}.
          Sending an additional signature after logging the transaction details and only increasing the balance afterward makes sure that a potential attack is always at the disadvantage of an attacker.

    \item In Step~\ref{seq:RELStateFinish}, the card sets its state to \texttt{FINISHED}.
    As it is stored in RAM, it can be reset to \texttt{NONE} by powering down the card, i.e., pulling it out of the terminal.
    There is no other way to reset this variable to make it harder for a fraudulent terminal to perform multiple transactions in a row without reinserting the card.

    \item In Step~\ref{seq:RELShowSuccess} the user gets printed a success message in the display of the terminal in case the terminal has one.
\end{itemize}

\subsubsection{Payment}
The sequence diagram in Figure~\ref{fig:POSProtocol} shows the procedure implementing use case~\ref{uc:payment}.

The mutual authentication between the card and the terminal is the same as for~\ref{uc:reload} and therefore separately depicted in Figure~\ref{fig:MutualAuth} and explained in Section~\ref{sec:mutualAuth}.

\begin{figure}
    \centering
    \input{figures/POSProtocol}
    \caption{Protocol to pay at a POS.
    See Section~\ref{sec:notation} for details on the notation.
    }
    \label{fig:POSProtocol}
\end{figure}

The following explains the steps of the payment protocol depicted in Figure~\ref{fig:POSProtocol}.

\begin{itemize}
    \item In Step~\ref{seq:POSaskAmount}, the POS terminal receives the amount (in Cents) to be paid from the cash desk.
    \item As for the reload protocol, the terminal sends this amount to the card in Step~\ref{seq:POSSendAmount}, which checks that is positive, stores it for later, and sets the state to \texttt{AMOUNT\_RECEIVED} in Steps~\ref{seq:POSStoreAmount} and~\ref{seq:POSStateAmountReceived}.

    \item In steps~\ref{seq:POSSendAmountSignature}--\ref{seq:POSVerifAmount}, the terminal sends a signature for the amount to the card, which verifies it.
          As in the reload protocol, including the card counter and card ID ensures that a replay attack is not possible.

    \item Different from the reload protocol, the balance is altered in Step~\ref{seq:POSalterBalance}, i.e., before it gets logged by the POS terminal.
          The reason for the difference is that we always want a potential attack to be at the disadvantage of the attacker.
          In this case, blocking of message~\ref{seq:POSSignS4} or a precisely timed card tear attack would only result in a disadvantage for the user:
          The payment would not have been confirmed, i.e., the user will not receive the goods it wants to pay, but the balance was already decreased.

    \item In Step~\ref{seq:POSStateFinish}, the state is set to \texttt{FINISHED}.
          As it is stored in RAM, it can be reset to \texttt{NONE} by powering down the card, i.e., pulling it out of the terminal.

    \item In Step~\ref{seq:POSSignS4}, the card signs all relevant transaction details.
          The terminal keeps a log of the details in Step~\ref{seq:POSLog}, together with this signature serving as proof of the transaction.
          This ensures non-repudiation, as the logged information is enough for a third party to verify that only the legitimate card could have done this payment (\ref{sr:nonRepudiation}).

    \item In Step~\ref{seq:POSShowSuccess} the user gets printed a success message in the terminal display in case the terminal has one.
\end{itemize}


\begin{figure}
    \centering
    \input{figures/stateMachine}
    \caption{State machine of the card, ensuring that no messages can be played out of sequence}
    \label{fig:stateMachine}
\end{figure}

\subsection{Blocking} \label{sec:blocking}
The following describes the blocking procedure of terminals and cards needed to comply with~\ref{sr:block}.

\subsubsection{Terminals} \label{sec:blockTerminal}
The certificates for terminals are only issued for a rather short period of time, for example, one week.
This enforces the terminal to connect to the back end periodically.
By not issuing a new certificate for a terminal, the terminal is blocked.
This assumes that the clock provided by the terminal is genuine.
If it is not, a terminal can use an old certificate and just provide some clock signal that is within the validity range of this old certificate.

Another case in which the terminal is blocked temporarily occurs if the terminal counter used in the reload and payment protocols in figures~\ref{fig:POSProtocol} and~\ref{fig:ReloadProtocol} would overflow.
To ensure that signature $S_2$ is still unique, the terminal needs a new certificate with a new expiration date.
Therefore, the terminal blocks itself until it got a new certificate.
After each certificate refresh, the counter is reset to zero.

\subsubsection{Cards} \label{sec:blockCards}
The cards can reach their end-of-live by different means.
The normal case would be that the certificate on the card expired.
As we trust the clock signal of the terminals, the card can check if it is expired and put its state to blocked in that case.

Similarly, we can set the state of a card to End-of-Live in the backend as soon as the certificate expired, as we can be sure that the card will block itself as soon as it would be used again.

Another way the card can get blocked is by revoking the certificate through a certificate revocation list (CRL) which is containing the following:
\begin{itemize}
    \item The list of all card IDs that got revoked,
    \item an expiration date,
    \item and a signature of the above, signed by the back end.
\end{itemize}
This would be helpful if the card gets lost or stolen.
The card would get blocked in the backend, which periodically distributes the CRL\@.
The POS and reload terminals will receive an update of that CRL every time they connect to the back end.
In case, the card is revoked by a valid CRL, steps~\ref{seq:AUTHSendBlockCard}--\ref{seq:AUTHProveBlock} of the mutual authentication protocol get executed to block the card.
Preferably, the CRLs are distributed as soon as possible. 
However, there is a trade-off between being able to operate offline and blocking cards as soon as possible.

The blocking works as follows:
If a card that is on the CRL connects to a terminal, it will perform a full mutual auth first, to ensure that the blocking can only be performed by genuine terminals to prevent DoS attacks.
After that, the terminal sends a block command to the card in Step~\ref{seq:AUTHSendBlockCard} which contains a signature of the card ID and card counter.
This ensures that the message could not be known before by an attacker without the terminal private key, as the counter is guaranteed to be new every time.

After successful verification of the signature in Step~\ref{seq:AUTHVerifBlockCommand}, the card blocks itself in Step~\ref{seq:AUTHBlockCard} and sends back a signed confirmation in Step~\ref{seq:AUTHProveBlock}.
Due to space limitations on the page, we omitted the signature verification at the terminal side in the figure, which nevertheless happens.

The confirmation is stored in the log of the terminal and (later) synchronized to the back end.
As the back end now knows that the card is blocked and cannot be unblocked again, it can delete the card ID from upcoming CRLs in order to keep it short.
In case the card is never used again after it was marked lost or stolen, the CRL entry will be kept until the certificate of the card is expired.

The last way a card can enter the blocked state is by an exhaustion of the counter used.
As described in the payment and reload protocols in figures~\ref{fig:ReloadProtocol} and~\ref{fig:POSProtocol} this counter is continuously increased to prevent replay attacks.
As soon as this counter reaches its maximum value, the card will block to prevent the reuse of the counter, functioning as a nonce.

\section{Changes Since Last Version}
    \subsection{Personalization Protocol}
    In the original proposal, we wanted to send the public key of the back end together with the expiration date and card ID in one APDU\@.
    As the used RSA key is already 256 bytes in size, it fills up the whole APDU, and thus we needed to split up the messages into two (steps~\ref{seq:InitBackendKeyToCard} and~\ref{seq:InitIdAndDateToCard}).

    \subsection{Reload and Payment Protocol}
    As with the personalization protocol, we experienced the limitation of the APDU size with the reload and payment protocol.
    Therefore, we split up the sending of certificates into three messages each (metadata, public key, and signature).
    Additionally, when sending signed information such as an amount of money, we first send the information and then the signature in a separate message.

    \subsection{List of Limitations and Shortcomings}
    \begin{itemize}
        \item A card ID cannot be deleted from a CRL\@.
        \item As described in Section~\ref{sec:blockTerminal}, the terminal block itself if the terminal counter overflows until the certificate gets refreshed.
        We omitted that step in the implementation for time reasons.
        Therefore, our implementation would be vulnerable, if a single terminal would process more than about one billion transactions within the lifetime of one certificate, which is supposed to be one week only.
        We do not consider this a big problem for now.
        \item There exists no way for a user to see their current balance stored on the card in the current implementation.
        This could easily be added between Step~\ref{seq:RELStateAmountReceived} and~\ref{seq:RELSendAmountSignature}, but there was no consent within the group whether it would be a privacy problem.
        Thus, we decided to omit the implementation for now.
        Instead, a user needs to rely on the -- possibly slightly outdated -- information in the back end.
        \item Due to time reasons, we also omitted displaying information on the terminal display, as specified in the last step of the reload and payment protocol.
        \item In case of errors, such as an expired card or a balance that is too low, there are no helpful error messages shown to the user.
        This is to be improved later.
    \end{itemize}

\end{document}