% IMPORTANT: Render this document with PDFLaTeX
\documentclass[10pt,a4paper,titlepage]{book}
\usepackage[utf8x]{inputenc}
\usepackage{ucs}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage[usenames,dvipsnames]{color}
\usepackage{graphicx}
\usepackage
	[
		dvips,%one,                       % or dvips
%------------- Backref Switch ---------------------------
		pagebackref,                     % or backref
%------------- Color Links ------------------------------
		colorlinks=true,
		linkcolor=anonblue,                % defined below
		filecolor=Maroon,                % defined below
		citecolor=anonblue,                % defined below
		urlcolor=Maroon,
%------------- Doc Info ---------------------------------
		pdftitle={AN.ON Documentation},
		pdfauthor={Christoph Dähne, Sebastian Kurfürst},
		pdfsubject={AN.ON Documentation},
		pdfkeywords={Jap AN.ON ANON smart card},
%------------ Doc View ----------------------------------
		bookmarksopen=false,
		pdfpagemode=None
	]{hyperref}


%
% Define some eye-pleasing colors for this document
%
\definecolor{anonblue}{rgb}{0,.2588,.3882} % #006699

\author{Christoph Dähne, Sebastian Kurfürst}
\title{AN.ON Documentation}
\begin{document}
\maketitle
\tableofcontents
%--------------------------------------------
% -------------Task description--------------
%--------------------------------------------
\chapter{Task description}
For the \href{http://anon.inf.tu-dresden.de/index_en.html}{JAP} service of the \href{http://tu-dresden.de/}{TU Dresden} we programmed an applet for Java smart cards. JAP provides anonymity and unobservability to its users while surfing the internet. But it needs to do some \href{http://anon.inf.tu-dresden.de/dataretention_en.html}{data retention}. This data must be accessible quickly on federal requests for some given time, but naturally be inaccessible after that time period as well as for unauthorized requests from inside and outside.\\
Therefore the data is encrypted with a symmetric key, which again is encrypted asymmetrically. In order to receive the key for a particular date and Mix this encrypted information must be sent to the ANONCardApplet along with a configurable number of valid operator logins. The card checks the current date and returns the decrypted symmetric key logging the event, time and date, and involved operators.\\
Our task was to write this applet and parts of the \href{http://anon.inf.tu-dresden.de/develop/MixConfig_en.html}{MixConfig tool}, which we completed partially. See \ref{cha:outline} for more details.
%--------------------------------------------
% ---------Overview and Terminology----------
%--------------------------------------------
\chapter{Overview and Terminology}
\section{Outline of structure}
Some layers are explained in more details in \ref{cha:details} or \ref{cha:ANONCardAppletMethodWriting}.
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{layers.png} 
	\caption{program layers}
	\label{fig:layers}
\end{figure}
\subsection{Communication layer}
As can be seen in Figure \ref{fig:layers} no direct communication with the smart card is needed. Using the ISmartCard and the implementing class SmartCardProxy all method calls are forwarded to the smart card and the arguments are transformed into byte streams, the return values back to ``normal'' data.
\subsection{User roles}
The ANONCardApplet knows two types of users with different capabilities as shown in Figure \ref{fig:roles}. Note that one administrator or operator alone cannot necessarily do anything. A configurable minimum number of administrators or operators must be present. Some of the features can be switched of and the Figure does not show all of them.
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{usecases.pdf} 
	\caption{User roles}
	\label{fig:roles}
\end{figure}
\subsection{Project dependencies}
Dependencies are shown in Figure \ref{fig:dependencies}. To avoid errors in eclipse, the ApduConstants class must be compiled. See \ref{subsec:eclipse} for more details.
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{dependencies.pdf} 
	\caption{Project dependencies}
	\label{fig:dependencies}
\end{figure}

\section{Important Classes and Packages}
\subsection{ANONCardApplet}
The ANONCardApplet is installed at the smart card and is the only class accessible from outside of its package. All requests will invoke a call of the method process. We do not advice to build and transmit the \href{http://de.wikipedia.org/wiki/Application_Protocol_Data_Unit}{APDUs} by hand but to use Commands and our ConnectionManager. How to do that is written in \ref{cha:ANONCardAppletMethodWriting} for more details about the ANONCardApplet see \ref{sec:ANONCardApplet}.
\subsection{GUI}
The GUI is implemented in MixConfig, inside the package mixconfig.panels.smartcard. The GUI itself (InstallationWizard.groovy) is backed by a model (InstallationWizardFormModel.groovy). This means all validation and data checking happens in the Model, and is displayed in the GUI. Additionally, the Model can save itself to the card, and load its data from the smart card (via the ISmartCard interface, explained below). More details can be found at \ref{sec:GUIandModell}.
\subsection{ISmartCard}
We found it useful to use the smart card with the ANONCardApplet installed on it as a plain Java object, without any need to encode or decode data. All communication is wrapped in this interface.
\subsection{Proxy}
The SmartCardProxy is our implementation of the ISmartCard. It encodes arguments, builds commands, gives them to the connection manager and decodes its responses. Also some local prechecking of arguments is done to safe some performance. Some methods are still not implemented and performance can be increased as well (see \ref{cha:outline}).
\subsection{Commands}
\href{http://de.wikipedia.org/wiki/Application_Protocol_Data_Unit}{APDUs}, since they are basically byte streams, strongly lack readability. We build Commands instead, encapsulating different parts of an APDU into documented arguments with readable names.
%--------------------------------------------
% --------------Getting started--------------
%--------------------------------------------
\chapter{Getting started}
\section{Requirements}
\subsection{Subsystems}
For development the following is required. The stated version numbers except for the JCDK might not matter, but this configuration has worked fine on a \href{}{Ubuntu} system.
\begin{itemize}
	\item JDK 1.5 (Java Development Kit)
	\item AspectJ
	\item \href{http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR2/eclipse-java-galileo-SR2-linux-gtk-x86_64.tar.gz&url=http://d2u376ub0heus3.cloudfront.net/technology/epp/downloads/release/galileo/SR2/eclipse-java-galileo-SR2-linux-gtk-x86_64.tar.gz&mirror_id=1001}{Eclipse Galileo}
	\item \href{http://java.sun.com/javacard/downloads/index.jsp}{JCDK 2.2.1 (Java Card Development Kit)} on a card that supports garbage collection
	\item \href{http://www.eclipse.org/subversive/downloads.php}{Subversive for Eclipse}
\end{itemize}

\subsection{Libraries}
Some external libraries are automatically downloaded by the ant build (init-libs, init-jondo, init-groovy) of the MixConfig project:
\begin{itemize}
	\item \href{http://www.bouncycastle.org/latest_releases.html}{Bouncy Castle APIs}
	\item \href{http://dist.groovy.codehaus.org/distributions/groovy-binary-1.7.0.zip}{Groovy 1.7.0}
	\item \href{http://www.migcalendar.com/miglayout/versions/3.7.2/miglayout-3.7.2-swing-java14.jar}{Miglayout 3.7.2}
	\item \href{https://anon.inf.tu-dresden.de/svn/JavaCardStudents/ANONCard/trunk/java_card_kit-2_2_1/lib/apduio.jar}{APDU libraries of the JCDK 2.2.1 (Java Card Development Kit)}
	\item \href{https://anon.inf.tu-dresden.de/svn/JavaCardStudents/ANONCard/trunk/java_card_kit-2_2_1/lib/api.jar}{API of the JCDK 2.2.1}
\end{itemize}
\section{Set up workspace}
\label{sec:workspace}
As mentioned before, this work consists of several eclipse project, each having its own SVN repository:
\begin{itemize}
	\item ANONCard/
	\item ANONCardDoc/
	\item ANONCardTests/
	\item MixConfig/
\end{itemize}
\subsection{SVN directories}
All folders can be checked out in \href{https://anon.inf.tu-dresden.de/svn/JavaCardStudents/}{https://anon.inf.tu-dresden.de/svn/JavaCardStudents/}. We advice to finish reading this section before doing that.
\subsubsection{ANONCard}
This project contains the applet, that is first deployed and then runs on the Java smart card. Although it is written in kind of Java, note that the smart card usually supports only a small subset of Java.
\subsubsection{ANONCardDoc}
This project contains this documentation written in \LaTeX{}, but naturally the Java source files contain the Javadoc.
\subsubsection{ANONCardTests}
All jUnit tests belong to this location. They can be run with ant.
\subsubsection{MixConfig}
This is the configuration tool for the Mixes, which includes the configuration panel for the smart cards. 

\subsection{Eclipse}
\label{subsec:eclipse}
To set up your Eclipse workspace do the following:
\begin{enumerate}
	\item Start Eclipse and \href{http://benjchristensen.com/2009/06/24/eclipse-galileo-3-5-and-subversion/}{install Subversive}
	\item Check out ANONCard/trunk, ANONCardTests/trunk, MixConfig/trunk and ANONCardDoc
	\item Run the following targets from MixConfig/build.xml with ant:
	\begin{itemize}
		\item init-libs
		\item init-jondo
		\item init-groovy
		\item compile
	\end{itemize}
\end{enumerate}
If you get some error message while performing init-jondo concerning an unknown fingerprint, open a terminal and enter:
\begin{verbatim}
svn list https://svn.jondos.de/svnpub/JonDonym/trunk
\end{verbatim}


\section{jUnit tests}
\subsection{ANONCardTests}
The directory tests contains all jUnit test cases. They are in the same package as the unit under test. In order to test the ANONCardApplet we found it necessary to access private fields and emulate the behaviour of the smart cards operating system. The provided API library is incapable doing that.\\
Therefore we manipulate and extend classes using AspectJ. All AspectJ files can be found in ANONCardTests/tests/aspects. Note that altering those files might cause the jUnit tests to fail.\\
\\
To run the test suite just run the build.xml with ant. The default target is runall. In order to run single test (i.e. ANONCardAppletTest), just start the target (ANONCardAppletTest). The tests are \textbf{not recompiled automatically}, when run one by one.\\
\\
New tests can be added to the according package and the build.xml file needs to be extended.
\subsection{Run Applet in Emulator}
If you want to run the applet in the emulator you need to change the constructor a bit. Just look inside. Then open two terminals, go to ANONCardTests and run:
\begin{verbatim}
ant emulate
\end{verbatim}
\begin{verbatim}
ant runMixconfigEmulated
\end{verbatim}
\section{Install applet}
Go to the folder ANONCard and run:
\begin{verbatim}
ant deploy
\end{verbatim}
\section{Run applet}
Go to the folder MixConfig and run:
\begin{verbatim}
ant run-wizard
\end{verbatim}

%--------------------------------------------
% -------Writing new ANONCard methods--------
%--------------------------------------------
\chapter{How to write new ANONCardApplet methods}
\label{cha:ANONCardAppletMethodWriting}The smart card can only communicate by \href{http://de.wikipedia.org/wiki/Application_Protocol_Data_Unit}{APDUs}. With this implementation, the size of an APDU is limited to 127 bytes. Thus in theory all method calls with arguments bigger than 121 bytes ($127-6=121$) are split into multiple APDUs. The same applies to the responses, which can only contain 99 bytes each. This value appeared in practice and we are not sure where it comes from.\\
\section{Single APDU request}
\label{sec:SingleAPDURequest}We now will write an example method, which already exists: getVersion(). It needs no arguments and returns two bytes, indicating the ANONCardApplets version.\\
\\
\label{code:APDUConstants}First an unique instruction code has to be added to ApduConstants in mixconfig.tools.dataretention.smartcard.
\begin{verbatim}
public class ApduConstants {
  ...
  public final static byte 
  INSTRUCTION_GET_VERSION = (byte) 0x20;	
  ...
}
\end{verbatim}
\label{code:Command} Next we need a new command which must extend AbstractCommand. The source of AbstractCommand is very short and easy to read. So take a look inside.
\begin{verbatim}
public class GetVersionCommand extends AbstractCommand {
  public GetVersionCommand() {
    instruction = 
    ApduConstants.INSTRUCTION_GET_VERSION;
    expectedReturnDataLength = 0x0F;
  }

  public String getVersion() {
    return (int)rawResponse[0] + 
    "." + (int)rawResponse[1];
  }
}
\end{verbatim}
Now we can use the GetVersionCommand in the SmartCardProxy in mixconfig.tools.dataretention.smartcard. Don't forget to add the new method in the ISmartCard interface.
\begin{verbatim}
public class SmartCardProxy implements ISmartCard {
  ...
  @Override
  public String getVersion() throws ErrorCodeException {
    GetVersionCommand command = new GetVersionCommand();
    connectionManager.processCommand(command);
    return command.getVersion();
  }
  ...
}
\end{verbatim}
\label{code:ANONCardAppletMethod}Last thing to do is to add the new method actually to the ANONCardApplet. This requires two steps:
\begin{enumerate}
	\item Write the method
	\item ``Register" it in the callInstructionByCode method
\end{enumerate}
\begin{verbatim}
public class ANONCardApplet extends ... {
  ...
  private void callInstructionByCode(...) {
    switch (instructionCode) {
      case ApduConstants.INSTRUCTION_GET_VERSION:
        getVersion(apdu);
        break;
      ...
      default:
        ISOException.throwIt(...);
        break;
    }
  }
  ...
  protected void getVersion(APDU apdu) {
    sendReply(apdu, new byte[] { 
      APPLET_VERSION_MAJOR, APPLET_VERSION_MINOR 
    });
  }
  ...
}
\end{verbatim}

\section{Extended Response}
\label{sec:extResponse}
If you want to receive responses longer than 99 bytes, you need to use the DataSendChannel (see \ref{subsec:dataSendChannels}) of the ANONCardApplet. The response is then automatically split into multiple APDUs.\\
The first two steps are the same: 
\begin{enumerate}
	\item Choose an unique instruction code (see \ref{code:APDUConstants})
	\item Create a command class (see \ref{code:Command})
\end{enumerate}
As an example, we consider the method getLogEntry which returns the i-th entry of the ANONCardApplets log.\\
Now take a look inside the SmartCardProxy:
\begin{verbatim}
public class SmartCardProxy implements ... {
  ...
  @Override
  public List<LogEntry> getLog() {
    ...
    for (int i = 0; i < getLogSizeCommand.getSize(); i++) {
      GetLogEntryCommand getLogEntryCommand = new GetLogEntryCommand(i);
      try {
        connectionManager.processCommand(getLogEntryCommand);
        int logEntryLength = getLogEntryCommand.getLength();
        byte[] response = getExtendedResponse(logEntryLength);
        log.add(new LogEntry(...));
      } catch (ErrorCodeException e) {...}
    }
  ...
  }
}
\end{verbatim}
The GetLogEntryCommand returns the length of the data to receive in bytes and afterwards the data packages can be polled with getExtendedResponse(logEntryLength).\\
The changes to be made on the ANONCardApplet are quite the same as before (see \ref{code:ANONCardAppletMethod}). Although the DataSendChannel needs to be initialized.
\begin{verbatim}
protected void getLogEntry(APDU apdu) {
  LogEntry logEntry = log.getLogEntry(...);
  if (logEntry != null) {
    dataSendChannel.open(logEntry.getData());
    sendReply(apdu, dataSendChannel.lengthAsBytes());
  } else {
    ISOException.throwIt(ApduConstants.EXCEPTION_ILLEGAL_ARGUMENT);
  }
}
\end{verbatim}

\section{Multi APDU request}
\label{sec:extendedRequest}
Sending extended method arguments to the ANONCardApplet can be done using the DataReceiveChannel (\ref{subsec:dataReceiveChannels}) of the ANONCard. The steps again are very much the same as in \ref{sec:SingleAPDURequest}, except three details:
\begin{enumerate}
	\item No Command class is needed
	\item SmartCardProxy and
	\item ANONCardApplet method are slightly different
\end{enumerate}
We never needed to receive response data after sending an extended argument request to the ANONCardApplet, but it is possible to implement, i.e. with few modifications to the AbstractCommand.\\
As an example, we show how to reset the log. The extended argument data is a list of valid administrator $(name, PIN)$ pairs.\\
\\
In the SmartCardProxy you just use the method doDataTransmission, which will initialize and use the ReceiveDataChannel of the ANONCard.
\begin{verbatim}
public class SmartCardProxy implements ... {
  ...
  @Override
  public void resetLog(Map<String, String> administrators) throws ... {
    checkAdministratorMap(administrators);
    doDataTransmission(
      ApduConstants.INSTRUCTION_RESET_ANONCARDAPPLET_LOG, 
      Helpers.packUsers(administrators)
    );
  }
  ...
}
\end{verbatim}
To receive the transmitted data in the ANONCardApplet you can check, weather there is any in the channel and access it using the dataReceiveChannel field. The method call to resetLog is only invoked if the data transmission is completed. (The additional checking if the transmission has completed is done, because this method supports both: single and multiple APDU requests.)
\begin{verbatim}
public class ANONCardApplet extends ... {
  ...
  protected void resetLog(APDU apdu) {
    ...
    if (dataReceiveChannel.isTransmissionComplete()) {
      authenticated = checkAdminPermission(
          dataReceiveChannel.getData(), (short) 0, 
          dataReceiveChannel.length()
      );
      names = getNamesFromBytes(...);
      dataReceiveChannel.close();
    }
    ...
  }
  ...
}
\end{verbatim}
%--------------------------------------------
% -----------Implementation Details----------
%--------------------------------------------
\chapter{Implementation Details}
\label{cha:details}
\section{GUI and Model}
\label{sec:GUIandModell}

The GUI to configure the smart card is implemented in two parts: The GUI itself, and the underlying model which stores the data. As building a GUI with standard Java is very cumbersome, we decided to use Groovy as programming language (which is then compiled to Java byte code), and an open source layout manager called \href{http://www.miglayout.com/}{\textit{MigLayout}}\footnote{http://www.miglayout.com/}. As groovy has support for Domain Specific Languages, it is very easy to build the GUI declaratively. Following is an excerpt showing this.
\begin{verbatim}
def frame = swingBuilder.frame(
   title:'Installation Wizard',
   size:[300,300],
   pack: true,
   visible: true
  ) {
  panel(layout: new MigLayout("fill", "grow", "top")) {
  errorMessages = label(text: "<html>", constraints: 'wrap')
  tabbedPane(constraints:"") {
    panel(title: 'Administrator Settings', layout: new MigLayout()) {
      label(text: "needed number of administrators")
      textFieldConnectedToModel(
         targetProperty: 'neededNumberOfAdministrators',
         dataType: 'int',
         constraints: "wrap"
      )
      checkBoxConnectedToModel(
         text: '... can delete/create other admins...',
         targetProperty: "allowedToModifyAdministrators",
         constraints: "span"
      )
      userEditingAreaConnectedToModel(
         role: 'Administrator', 
         targetProperty: 'administrators'
      )	
    }
    ... [more tabs] ...
  }
}
\end{verbatim}
Here, the GUI hierarchy can be directly seen from the code. Additionally, we created some special helper methods which are used to bind the form to the underlying model, all methods ending with *connectedToModel. There, one could set the targetProperty, which is the target property of the model the form element should be bound to.

Now have a look at the corresponding model (InstallationWizardFormModel): here, two things are very important:
\begin{itemize}
\item Every model class needs to have the @Bindable annotation on top of it, as the GUI needs to install some property change listeners.
\item All \textit{lists} in the model need to be of the type ObservableList, as all lists need property change notification support as well.
\end{itemize}

Figure \ref{fig:formfields} shows how the model and the user interface works together, and how the listeners work: Simple form fields work the most straightforward way. On form initialization, the data is loaded from the model and displayed in the form. Additionally, a change listener to the form field is added, which changes the model on every value change (and this, in turn, triggers validation -- see below).

For compound properties, like lists of users or files, it is a bit more complex. If the button to add a field is pressed, a new element is simply added to the array in the model. This triggers a callback which then refreshes the user interface, displaying the new element. The editing of the individual values works as described above. Removing an element works the same way as just described.

\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{formfields.pdf} 
	\caption{Form fields}
	\label{fig:formfields}
\end{figure}

Additionally, validation constraints can be defined in the model as follows: All constraints are listed in a Map with the name "constraints". The key for each constraint is the field to which this constraint applies (or GLOBAL if the constraints are not tied to a single field), and the value for each constraint is an anonymous function which checks the constraint, and returns an array of error messages if the validation fails, or null if there was no validation error.

All this can be seen in the following code snippet:

\begin{verbatim}
@Bindable
class InstallationWizardFormModel extends AbstractFormModel {
  protected def constraints = [
    neededNumberOfAdministrators: {
      if (this.neededNumberOfAdministrators > this.administrators.size()) {
        return ["<b>Needed number of administrators</b> must be
          smaller or equal than the total number of administrators!"]
      }
      return null
    },
    ... more constraints follow here ...
  ]
}   
\end{verbatim}

Now, only one question remains: How is the model saved to the smart card, and restored from the smart card? For this, the model has the method saveToCard(), which connects to the card, and commits all changes atomically, i.e. inside a transaction. For more details on the implementation of the transaction, see  section \ref{subsec:Configuration}. For loading the data from the card, the method loadFromCard() is used.

\section{ANONCardApplet}
\label{sec:ANONCardApplet}
The ANONCardApplet holds the encryption keys and checks permissions on requests. Almost every possible instruction code has its own protected method. Short examples can be found in \ref{cha:ANONCardAppletMethodWriting}. This section only explains parts of the applet, which cannot be documented well enough using Javadoc. You need to read the Javadoc! The applet overrides some methods from its superclass. We advice to read its documentation, too.
\subsection{Flow of a request}
\label{subsec:flowofarequest}
In Figure \ref{fig:singelAPDUrequest} you can see, how a APDU request flows throw the ANONCardApplet. This only holds for single APDU requests (see \ref{sec:SingleAPDURequest}). Not shown in this overview the DataReceiveChannel (see \ref{subsec:dataReceiveChannels}) is closed, too.
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{requestflow_single.pdf} 
	\caption{Method calls in the ANONCardApplet on a single APDU request}
	\label{fig:singelAPDUrequest}
\end{figure}
In the case of an extended APDU request (see \ref{sec:extendedRequest}) the method calls are slightly different as can be seen in Figure \ref{fig:extendedAPDUrequest}. The first APDU opens the DataReceiveChannel (see \ref{subsec:dataReceiveChannels}) and already determines the instruction code for the method call (myOperation) which is executed after all argument data has been transmitted. All but the last APDU deliver pieces of data to the data channel and the last one additionally invokes the method call. Note, that the data channel is not closed automatically, but will be as soon as the next APDU arrives. Naturally it can be closed ``by hand'' in myOperation.
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{requestflow_extended.pdf} 
	\caption{Method calls in the ANONCardApplet on an extended APDU request}
	\label{fig:extendedAPDUrequest}
\end{figure}

\subsection{Configuration and transactions}
\label{subsec:Configuration}
The settings are saved in the ANONCardApplet:configuration object. Since users can be removed and added changes on the configuration have to be atomic and complete. To achieve that, we use transactions (see Figure \ref{fig:settings}).
\begin{figure}[hbtp]
	\centering
	\includegraphics[width=12cm]{settings.pdf} 
	\caption{Transaction protocol to change settings}
	\label{fig:settings}
\end{figure}
To change the configuration you must follow these steps:
\begin{enumerate}
	\item Start a transaction
	\item Change settings
	\item Commit the transaction with \textbf{old} administrator logins
\end{enumerate}
The configuration objects are never initialized after the installation of the applet. See its constructor for more details.

\section{Virtual data channels}
\label{sec:dataChannels}
Some argument or response data extends the size of one \href{http://de.wikipedia.org/wiki/Application_Protocol_Data_Unit}{APDUs} (see \ref{sec:extResponse} and \ref{sec:extendedRequest}) and need to be split into multiple ones. Since the channels are placed on the smart card, the channel to send data to the smart card that it must receive is called DataReceiveChannel and vice versa.
\subsection{DataSendChannel}
\label{subsec:dataSendChannels}
The protocol is very simple. When a response is too long, the DataSendChannel needs to be opened and the data can be polled one package at a time using the GetNextDataPackageCommand. Each data package is transmitted exactly once and the channel is closed automatically, when all data has been sent. See \ref{sec:extResponse} for an example.
\subsection{DataReceiveChannel}
\label{subsec:dataReceiveChannels}
For extended arguments the DataReceiveChannel is to be used. See \ref{sec:extendedRequest} for an example. The protocol is shown in Figure \ref{fig:receiveChannel}. The DataReceiveChannel was once named DataTransmissionChannel, the name of the instruction code constants stayed the same, but are also defined in the ApduConstants class.
\begin{figure}[pbth]
	\centering
	\includegraphics[width=18cm,angle=90]{datatransmission.pdf} 
	\caption{Protocol of the DataReceiveChannel - APDU.INS is the APDU byte containing the instruction code}
	\label{fig:receiveChannel}
\end{figure}
%--------------------------------------------
% ----------Outline and Open Topics----------
%--------------------------------------------
\chapter{Outline and open topics}
\label{cha:outline}
\section{Communication with timeserver}
The ANONCardApplet is supposed to check, whether a symmetric key must be still delivered or whether the time period for data retention already has passed. While decrypting the applet can determine the day of creation of the key. As todays date, the applet uses system time of the MixConfig tool, which is quite insecure. Instead the card should communicate with several timeservers using the attached PC as a proxy in a secure way.

\section{Signatures of seed}
Saved symmetric keys are an asymmetrically encrypted tuple of $(Kr, date)$ where $Kr$ is some kind of random seed for the symmetric key $key$. In order to improve security it would be nice to sign it additionally alike $(Kr, date,$ $sign(hash(Kr, date)))$ and implement that in a way that the date neither can be altered nor a new tuple can be created with the same $Kr$ and another $date^{\prime{}}$ which would result in the same $key$.

\section{Optimizes applet memory allocation}
The current implementation is not designed for low memory consumption. The only slight optimization is done for logging. We neither use the transient memory of the smart card, which would make sense i.e. for the data channels. A lot of optimization can be done here, too.\\
Additionally it would be very nice to not need garbage collection. To achieve that the only memory allocation, for objects as well as for plain data types, has to be done only during the installation of the applet.

\section{Optimize applet performance}
The applet neither is design for high performance. The applet code can be optimized for sure and the current SmartCardProxy i.e. lacks caching.

\section{PIN input via card reader}
To increase security further PINs can be typed in on some smart card readers instead the PC. It was optional for our task to make it possible. Currently PINs are entered always via the PC. We can imagine to add the possibility to configure an applet that it enforces the use of such devices and blocks access if the card reader has no input field.

\section{Automated testing of an installed applet}
The test suit so far compiles the ANONCardApplet and other components using a standard Java compiler. This allows developers to use nice features like jUnit, debugging with breakpoints and fast testing on home computers without smart card readers. On the other side, some classes needs to be manipulated with aspects and the behaviour of the smart cards OS might differ from the expected behaviour simulated using the aspects. Also the encryption, a vital function of the card, can be tested poorly.\\
Therefore it would be a great improvement to have test, that communicate with a real ANONCardApplet installed on a not-emulated, real smart card. The tests must be possible to be run automatically and to be extended.

\end{document}