[taler-anastasis] branch master updated: system design documentation

[gnunet]

This is an automated email from the git hooks/post-receive script.

ds-meister pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new 9f3c075  system design documentation
9f3c075 is described below

commit 9f3c0756c0b600c2764d134572140d3e5122d652
Author: Dominik Meister <address@hidden>
AuthorDate: Mon May 25 20:32:23 2020 +0200

    system design documentation
---
 doc/thesis/conclusion.tex          |   3 +
 doc/thesis/design.tex              | 376 ++++++++++++++++++++++++++++++++++++-
 doc/thesis/images/anastasis-db.png | Bin 0 -> 52516 bytes
 doc/thesis/implementation.tex      |   8 -
 doc/thesis/motivation.tex          |   3 +
 doc/thesis/thesis.tex              |   9 +-
 6 files changed, 383 insertions(+), 16 deletions(-)

diff --git a/doc/thesis/conclusion.tex b/doc/thesis/conclusion.tex
new file mode 100644
index 0000000..b862fa2
--- /dev/null
+++ b/doc/thesis/conclusion.tex
@@ -0,0 +1,3 @@
+\section{Motivation}
+
+Motivation here
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index f597ed6..b58440d 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -1,19 +1,383 @@
 \section{Design}
+Anastasis is a service that allows the user to securely deposit a core secret 
with an open set of escrow providers and recover it if the secret is lost. The 
core secret itself is protected from the escrow providers by encrypting it with 
a master key. The main objective of Anastasis is to ensure that the user can 
reliably recover the core secret, while making this difficult for everyone 
else. Furthermore, it is assumed that the user is unable to reliably remember 
any secret with sufficien [...]
+\\
+To uniquely identify users, an “unforgettable” identifier is used. This 
identifier should be difficult to guess for anybody but the user. However, the 
identifier is not expected to have sufficient entropy or secrecy to be 
cryptographically secure. Examples for such identifier would be a concatenation 
of the full name of the user and their social security or passport number(s). 
For Swiss citizens, the AHV number could also be used. \\
+\\
+The adversary model of Anastasis has two types of adversaries: weak 
adversaries which do not know the user’s identifier, and strong adversaries 
which somehow do know a user’s identifier. For weak adversaries the system 
guarantees full confidentiality. For strong adversaries, breaking 
confidentiality additionally requires that Anastasis escrow providers must have 
colluded. The user is able to specify a set of policies which determine which 
Anastasis escrow providers would need to collude  [...]
+\\
+A recovery document includes all of the information a user needs to recover 
access to their core secret. It specifies a set of escrow methods, which 
specify how the user should convince the Anastasis server that they are “real”. 
Escrow methods can for example include SMS-based verification, 
Video-identfication or a security question. For each escrow method, the 
Anastasis server is provided with truth, that is data the Anastasis operator 
may learn during the recovery process to authentica [...]
 
-\subsection{Serverarchitecture}
+\subsection{Systemarchitecture}
 
-\subsubsection{Database}
+\subsubsection{Recovery procedure}
 
-\subsubsection{Server API}
+\subsubsection{Upload procedure}
 
 
+\subsection{Server architecture}
+The Anastasis server architecture consists of two components. A web server 
with a REST API and a PostgreSQL database. The structure of these two 
components is shown here.
+\subsection{Database}
+The database schema of Anastasis is structured as follows.
+\\
+\includegraphics[scale=0.50]{images/anastasis-db.png}
+\\
+The database schema consists of 4 tables. \\
+The Truth table is responsible for storing the keyshares and its 
authentication method. The keyshare and the truth are stored encrypted in the 
database. The truth is only decrypted during authentication. The keyshare is 
never decrypted for the server. This protects the privacy of the customer. 
Likewise, the user data is protected after a possible theft. \\
+The User table contains the identification of the user and an expiration 
timestamp. This timestamp is a subscription period. This timestamp is updated 
after each payment the user makes. Users for whom the subscription has expired 
are periodically deleted. \\
+The Payments table contains the details of a payment from a user. The payment 
is used either for the post-counter or the subscription. The post-counter is 
decremented after each upload of a recovery document. The user can only upload 
the recovery document if the provided payment contains a post-counter which is 
atleast 1.
+Through this measure we can prevent people from maliciously filling our 
database. \\
+The Recoverydocument table contains the recovery information. The recovery 
document is stored encrypted in the database.This offers better protection, as 
explained earlier for the Truth table. Each Recoverydocument record also 
contains a version, a hash of the recovery document and a signature. The 
version attribute allows the user to lookup a specific version of the document. 
The hash is used to check if the user uploads a dupplicate of the document. 
Last the signature ensures the integ [...]
 
+\subsection{Server API}
+The server api is a RESTful API which has the following endpoints.
 
-\subsection{Clientarchitecture}
+\subsubsection{Obtain Salt}
+\textbf{GET /salt}
+\\
+Obtain the salt used by the escrow provider. Different providers will use 
different high-entropy salt values. The resulting provider salt is then used in 
various operations to ensure cryptographic operations differ by provider. A 
provider must never change its salt value. \\
+\textbf{Response: } \\  
+Returns a "SaltResponse".
+\begin{lstlisting}
+interface SaltResponse { 
+  // salt value, at least 128 bits of entropy 
+  server_salt: string; 
+}
+\end{lstlisting}
 
-\subsubsection{Client API}
+\subsubsection{Obatain terms of service}
+\textbf{GET /terms}
+\\
+Obtain the terms of service provided by the escrow provider.
+\\
+\textbf{Response: } \\
+Returns an EscrowTermsOfServiceResponse. \\ 
 
-\subsubsection{Client Application CLI}
+\begin{lstlisting}
+interface EscrowTermsOfServiceResponse { 
+
+  // minimum supported protocol version
+  min_version: number;
+
+  // maximum supported protocol version
+  max_version: number;
+
+  // supported authentication methods
+  auth_methods: AuthenticationMethod[];
+
+  // Payment required to maintain an account to store
+  // policy documents for a month.
+  // Users can pay more, in which case the storage time
+  // will go up proportionally.
+  monthly_account_fee: Amount;
+
+  // Amount required per policy upload. Note that the amount is NOT
+  // charged additionally to the monthly_storage_fee. Instead, 
+  // when a payment is made, the amount is divided by the policy_upload_fee
+  // (and rounded down) to determine how many uploads can be made 
+  // under the associated payment identifier.
+  policy_upload_ratio: Amount;
+
+  // maximum policy upload size supported
+  policy_size_limit_in_bytes: number;
+
+  // maximum truth upload size supported
+  truth_size_limit_in_bytes: number;
+
+  // how long until the service expires deposited truth
+  // (unless refreshed via another POST)?
+  truth_expiration: RelativeTime;
+
+  // Payment required to upload truth.  To be paid per upload.
+  truth_upload_fee: Amount;
+
+  // Limit on the liability that the provider is offering with
+  // respect to the services provided.
+  liability_limit: Amount;
+
+  // HTML text describing the terms of service in legalese.
+  // May include placeholders like "${truth_upload_fee}" to
+  // reference entries in this response.
+  tos: string;
+}
+\end{lstlisting}
+
+\begin{lstlisting}
+interface AuthenticationMethod {
+  // name of the authentication method
+  name: string;
+
+  // Fee for accessing truth using this method
+  usage_fee: Amount;
+
+}
+\end{lstlisting}
+
+\subsubsection{Manage Policy}
+This API is used by the Anastasis client to deposit or request encrypted 
recovery documents with the escrow provider. Generally, a client will deposit 
the same encrypted recovery document with each escrow provider, but provide 
different truth to each escrow provider. \\
+\\
+Operations by the client are identified and authorized by \$ACCOUNT\_PUB, 
which should be kept secret from third parties. \$ACCOUNT\_PUB should be an 
account public key using the Crockford base32-encoding.\\
+\\
+In the following, UUID is always defined and used according to RFC 4122. \\
+\\
+\textbf{GET /policy/\$ACCOUNT\_PUB[?version=\$NUMBER]} \\
+\\
+Get the customer’s encrypted recovery document. If “version” is not specified, 
the server returns the latest available version. If “version” is specified, 
returns the policy with the respective “version”. The response must begin with 
the nonce and an AES-GCM tag and continue with the ciphertext. Once decrypted, 
the plaintext is expected to contain: 
+\begin{itemize}
+\item the escrow policy
+\item the separately encrypted master public key
+\end{itemize}
+
+\textbf{Status Codes: } \\
+\begin{itemize}
+\item 200 OK – The escrow provider responds with an EncryptedRecoveryDocument 
object.
+\item 304 Not modified – The client requested the same ressource it already 
knows.
+\item 400 Bad request – The \$ACCOUNT\_PUB is not an EdDSA public key.
+\item 402 Payment Required – The account’s balance is too low for the 
specified operation. See the Taler payment protocol specification for how to 
pay.
+\item 403 Forbidden – The required account signature was invalid.
+\item 404 Not Found – The requested resource was not found.
+\end{itemize}
+Note that the key shares required to decrypt the master public key are not 
included, as for this the client needs to obtain authorization. The policy does 
provide sufficient information for the client to determine how to authorize 
requests for truth. \\
+ \\
+The client MAY provide an “If-None-Match” header with an Etag. In that case, 
the server MUST additionally respond with an “304” status code in case the 
resource matches the provided Etag.\\
+ \\
+Anastasis-Version: \$NUMBER — The server must return actual version of the 
encrypted recovery document via this header. If the client specified a version 
number in the header of the request, the server must return that version. If 
the client did not specify a version in the request, the server returns latest 
version of the EncryptedRecoveryDocument.\\
+ \\
+Etag: Set by the server to the Base32-encoded SHA512 hash of the body. Used 
for caching and to prevent redundancies. The server MUST send the Etag if the 
status code is 200 OK.\\
+ \\
+If-None-Match: If this is not the very first request of the client, this 
contains the Etag-value which the client has reveived before from the server. 
The client SHOULD send this header with every request (except for the first 
request) to avoid unnecessary downloads.\\
+ \\
+Anastasis-Account-Signature: The client must provide Base-32 encoded EdDSA 
signature over hash of body with \$ACCOUNT\_PRIV, affirming desire to download 
the requested encrypted recovery document. The purpose used MUST be 
TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD (1401).\\
+
+\textbf{POST /policy/\$ACCOUNT\_PUB} \\
+ \\
+Upload a new version of the customer’s encrypted recovery document. While the 
document’s structure is described in JSON below, the upload should just be the 
bytestream of the raw data (i.e. 32 bytes nonce followed by 16 bytes tag 
followed by the encrypted document). If request has been seen before, the 
server should do nothing, and otherwise store the new version. The body must 
begin with a nonce, an AES-GCM tag and continue with the ciphertext. The format 
is the same as specified for th [...]
+ \\
+\textbf{Status Codes: } \\
+\begin{itemize}
+\item 204 No Content – The encrypted recovery document was accepted and 
stored. “Anastasis-Version” and “Anastasis-UUID” headers incidate what version 
and UUID was assigned to this encrypted recovery document upload by the server.
+\item 304 Not modified – The same encrypted recovery document was previously 
accepted and stored. “Anastasis-Version” header incidates what version was 
previously assigned to this encrypted recovery document.
+\item 400 Bad request – The \$ACCOUNT\_PUB is not an EdDSA public key or 
mandatory headers are missing. The response body MUST elaborate on the error 
using a Taler error code in the typical JSON encoding.
+\item 402 Payment Required – The account’s balance is too low for the 
specified operation. See the Taler payment protocol specification for how to 
pay. The response body MAY provide alternative means for payment.
+\item 403 Forbidden – The required account signature was invalid. The response 
body may elaborate on the error.
+\item 409 Conflict – The If-Match Etag does not match the latest prior version 
known to the server.
+\item 413 Request Entity Too Large – The upload is too large or too small. The 
response body may elaborate on the error.
+\end{itemize}
+\textit{If-Match:} Unless the client expects to upload the first encrypted 
recovery document to this account, the client should provide an Etag matching 
the latest version already known to the server. If this header is present, the 
server MUST refuse the upload if the latest known version prior to this upload 
does not match the given Etag. \\
+\textit{If-None-Match:} This header must be present and set to the SHA512 hash 
(Etag) of the body by the client. The client should also set the “Expect: 
100-Continue” header and wait for “100 continue” before uploading the body. The 
server MUST use the Etag to check whether it already knows the encrypted 
recovery document that is about to be uploaded. The server MUST refuse the 
upload with a “304” status code if the Etag matches the latest version already 
known to the server.
+Anastasis-Policy-Signature: The client must provide Base-32 encoded EdDSA 
signature over hash of body with \$ACCOUNT\_PRIV, affirming desire to upload an 
encrypted recovery document.\\
+\textit{Payment-Identifier:} Base-32 encoded 32-byte payment identifier that 
was included in a previous payment (see 402 status code). Used to allow the 
server to check that the client paid for the upload (to protect the server 
against DoS attacks) and that the client knows a real secret of financial value 
(as the kdf\_id might be known to an attacker). If this header is missing in 
the client’s request (or the associated payment has exceeded the upload limit), 
the server must return a 40 [...]
+ \\
+\begin{lstlisting}
+interface EncryptedRecoveryDocument { 
+  // Nonce used to compute the (iv,key) pair for encryption
+  // of the encrypted_compressed_recovery_document.
+  nonce: [32]; //bytearray
+
+  // Authentication tag
+  aes_gcm_tag: [16]; //bytearray
+
+  // Variable-size encrypted recovery document. After decryption,
+  // this contains a gzip compressed JSON-encoded RecoveryDocument.
+  // The nonce of the HKDF for this encryption must include the
+  // string "ERD".
+  // bytearray of undefined length
+  encrypted_compressed_recovery_document: []; 
+
+}
+\end{lstlisting}
+ \\
+\begin{lstlisting}
+
+interface RecoveryDocument {
+  // Account identifier at backup provider, AES-encrypted with
+  // the (symmetric) master_key, i.e. an URL
+  // https://sync.taler.net/$BACKUP_ID and
+  // a private key to decrypt the backup.  Anastasis is oblivious
+  // to the details of how this is ultimately encoded.
+  backup_account: []; //bytearray of undefined length
+
+  // List of escrow providers and selected authentication method
+  methods: EscrowMethod[];
+
+  // List of possible decryption policies
+  policy: DecryptionPolicy[];
+
+}
+\end{lstlisting}
+
+\begin{lstlisting}
+interface EscrowMethod {
+  // URL of the escrow provider 
+  // (including possibly this Anastasis server)
+  provider_url : string;
+
+  // Name of the escrow method (e.g. security question, SMS etc.)
+  escrow_method: string;
+
+  // UUID of the escrow method (see /truth/ API below).
+  uuid: string;
+
+  // Key used to encrypt the Truth this EscrowMethod is related to.
+  // Client has to provide this key to the server when using /truth/
+  truth_encryption_key: [32]; //bytearray
+
+  // Salt used to encrypt the truth on the Anastasis server.
+  truth_salt: [32]; //bytearray
+
+  // The challenge to give to the user (i.e. the security question
+  // if this is challenge-response).
+  // (Q: as string in base32 encoding?)
+  // (Q: what is the mime-type of this value?)
+  //
+  // For some methods, this value may be absent.
+  //
+  // The plaintext challenge is not revealed to the
+  // Anastasis server.
+  challenge: []; //bytearray of undefined length
+}
+
+\end{lstlisting}
+
+\begin{lstlisting}
+interface DecryptionPolicy {
+  // Salt included to encrypt master key share when
+  // using this decryption policy.
+  policy_salt: [32]; //bytearray
+
+  // Master key, AES-encrypted with key derived from
+  // salt and keyshares revealed by the following list of
+  // escrow methods identified by UUID.
+  encrypted_master_key: [32]; //bytearray
+
+  // List of escrow methods identified by their uuid.
+  uuid: string[];
+
+}
+\end{lstlisting}
+
+\subsubsection{Manage Truth}
+This API is used by the Anastasis client to deposit truth or request a 
(encrypted) key share with the escrow provider.\\
+ \\
+An escrow method specifies an Anastasis provider and how the user should 
authorize themself. The truth API allows the user to provide the (encrypted) 
key share to the respective escrow provider, as well as auxiliary data required 
for such an respective escrow method. \\
+ \\
+An Anastasis-server may store truth for free for a certain time period, or 
charge per truth operation using GNU Taler.
+ \\
+\textbf{POST /truth/\$UUID}
+ \\
+Upload a TruthUploadRequest-Object according to the policy the client created 
before (see RecoveryDocument). If request has been seen before, the server 
should do nothing, and otherwise store the new object. \\
+ \\
+\textbf{Status Codes: } \\
+\begin{itemize}
+\item 204 No content – Truth stored successfully.
+\item 304 Not modified – The same truth was previously accepted and stored 
under this UUID. The Anastasis server must still update the expiration time for 
the truth when returning this response code.
+\item 402 Payment Required – This server requires payment to store truth per 
item. See the Taler payment protocol specification for how to pay. The response 
body MAY provide alternative means for payment.
+\item 409 Conflict – The server already has some truth stored under this UUID. 
The client should check that it is generating UUIDs with enough entropy.
+\item 412 Precondition Failed – The selected authentication method is not 
supported on this provider.
+\end{itemize}
+ \\
+\textbf{Details:} \\
+\begin{lstlisting}
+interface TruthUploadRequest {
+  // Contains the information of an interface EncryptedKeyShare,
+  // but simply as one binary block (in Crockford Base32 
+  // encoding for JSON).
+  key_share_data: []; //bytearray
+
+  // Key share method, i.e. "security question", "SMS", "e-mail", ...
+  method: string;
+
+  // Nonce used to compute the (iv,key) pair for encryption of the
+  // encrypted_truth.
+  nonce: [32]; //bytearray
+
+  // Authentication tag of encrypted_truth
+  aes_gcm_tag: [16]; //bytearray
+
+  // Variable-size truth. After decryption,
+  // this contains the ground truth, i.e. H(challenge answer),
+  // phone number, e-mail address, picture, fingerprint, ...
+  // **base32 encoded**.
+  //
+  // The nonce of the HKDF for this encryption must include the
+  // string "ECT".
+  encrypted_truth: [80]; //bytearray
+
+  // mime type of truth, i.e. text/ascii, image/jpeg, etc.
+  truth_mime: string;
+}
+\end{lstlisting}
+ \\
+\textbf{GET /truth/\$UUID[?response=\$RESPONSE]} \\
+ \\
+Get the stored encrypted key share. If \$RESPONSE is specified by the client, 
the server checks if \$RESPONSE matches the expected response specified before 
within the TruthUploadRequest (see encrypted\_truth). Also, the user has to 
provide the correct truth\_encryption\_key with every get request (see below). 
When \$RESPONSE is correct, the server responses with the encrypted key share. 
The encrypted key share is returned simply as a byte array and not in JSON 
format. \\
+
+\textbf{Status Codes: } \\
+\begin{itemize}
+\item 200 OK – EncryptedKeyShare is returned in body (in binary).
+\item 202 Accepted – The escrow provider will respond out-of-band (i.e. SMS). 
The body may contain human-readable instructions on next steps.
+\item 303 See Other – The provider redirects for authentication (i.e. video 
identification/WebRTC). If the client is not a browser, it should launch a 
browser at the URL given in the “Location” header and allow the user to re-try 
the operation after successful authorization.
+\item 402 Payment Required – The service requires payment for access to truth. 
See the Taler payment protocol specification for how to pay. The response body 
MAY provide alternative means for payment.
+\item 403 Forbidden – The server requires a valid “response” to the challenge 
associated with the UUID.
+\item 404 Not Found – The server does not know any truth under the given UUID.
+\item 503 Service Unavailable – Server is out of Service.
+\end{itemize}
+ \\
+\textbf{Truth-Decryption-Key:} Key used to encrypt the truth (see 
encrypted\_truth within TruthUploadRequest) and which has to provided by the 
user. The key is stored with the according EscrowMethod. The server needs this 
key to get the info out of TruthUploadRequest needed to verify the \$RESPONSE.
+ \\
+\textbf{Details:}
+\begin{lstlisting}
+interface EncryptedKeyShare {
+  // Nonce used to compute the decryption (iv,key) pair.
+  nonce_i: [32]; //bytearray
+
+  // Authentication tag
+  aes_gcm_tag_i: [16]; //bytearray
+
+  // Encrypted key-share in base32 encoding.
+  // After decryption, this yields a KeyShare.  Note that
+  // the KeyShare MUST be encoded as a fixed-size binary
+  // block (instead of in JSON encoding).
+  //
+  // HKDF for the key generation must include the
+  // string "eks" as salt. Depending on the method,
+  // the HKDF may additionally include
+  // bits from the response (i.e. some hash over the
+  // answer to the security question)
+  encrypted_key_share_i: [32]; //bytearray
+}
+\end{lstlisting}
+  \\
+\begin{lstlisting}
+interface KeyShare {
+  // Key material to concatenate with policy_salt 
+  // and KDF to derive the key to decrypt the master key.
+  key_share: [32]; //bytearray
+
+  // Signature over method, uuid, and key_share.
+  account_sig: EddsaSignature;
+}
+\end{lstlisting}
+
+\subsection{Authentication Methods}
+This section describes the supported authentication methods in detail.
+
+\subsubsection{SMS (sms)}
+Sends an SMS with a code to the users phone. The must send this code back with 
his request (see \$RESPONSE under ‘Manage truth’). If the transmitted code is 
correct, the server responses with the requested encrypted key share. FIXME: 
details!
+
+\subsubsection{Video identification (vid)}
+Requires the user to identify via video-call. The user is expected to delete 
all metadata revealing information about him/her from the images before 
uploading them. Since the respective images must be passed on to the video 
identification service in the event of password recovery, it must be ensured 
that no further information about the user can be derived from them. FIXME: 
details!
+
+\subsubsection{Security question (qa)}
+Asks the user a security question. The user sends back a hash over the answer. 
If the hash value matches with the one the server is expecting, the server 
answers with the requested encrypted key share. A different hash function over 
the same security answer is used to provide optional data for the decryption of 
the (encrypted) key share.
+
+\subsubsection{Post-Indent (post)}
+Physical address verification via snail mail. FIXME: details!
+
+\subsection{Client architecture}
+
+\subsection{Client API}
+
+\subsection{Client Application CLI}
 
 
 
diff --git a/doc/thesis/images/anastasis-db.png 
b/doc/thesis/images/anastasis-db.png
new file mode 100644
index 0000000..4a2fc5c
Binary files /dev/null and b/doc/thesis/images/anastasis-db.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 914a8cc..70cd883 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -1,12 +1,4 @@
 \section{Implementation}
-Anastasis is a service that allows the user to securely deposit a core secret 
with an open set of escrow providers and recover it if the secret is lost. The 
core secret itself is protected from the escrow providers by encrypting it with 
a master key. The main objective of Anastasis is to ensure that the user can 
reliably recover the core secret, while making this difficult for everyone 
else. Furthermore, it is assumed that the user is unable to reliably remember 
any secret with sufficien [...]
-\\
-To uniquely identify users, an “unforgettable” identifier is used. This 
identifier should be difficult to guess for anybody but the user. However, the 
identifier is not expected to have sufficient entropy or secrecy to be 
cryptographically secure. Examples for such identifier would be a concatenation 
of the full name of the user and their social security or passport number(s). 
For Swiss citizens, the AHV number could also be used. \\
-\\
-The adversary model of Anastasis has two types of adversaries: weak 
adversaries which do not know the user’s identifier, and strong adversaries 
which somehow do know a user’s identifier. For weak adversaries the system 
guarantees full confidentiality. For strong adversaries, breaking 
confidentiality additionally requires that Anastasis escrow providers must have 
colluded. The user is able to specify a set of policies which determine which 
Anastasis escrow providers would need to collude  [...]
-\\
-A recovery document includes all of the information a user needs to recover 
access to their core secret. It specifies a set of escrow methods, which 
specify how the user should convince the Anastasis server that they are “real”. 
Escrow methods can for example include SMS-based verification, 
Video-identfication or a security question. For each escrow method, the 
Anastasis server is provided with truth, that is data the Anastasis operator 
may learn during the recovery process to authentica [...]
-
 \subsection{Cryptography}
 When a user needs to interact with Anastasis, the system first derives some 
key material, but not the master secret, from the user’s identifier using 
different HKDFs. These HKDFs are salted using the respective escrow provider’s 
server salt, which ensures that the accounts for the same user cannot be easily 
correlated across the various Anastasis servers. \\
 \\
diff --git a/doc/thesis/motivation.tex b/doc/thesis/motivation.tex
new file mode 100644
index 0000000..b862fa2
--- /dev/null
+++ b/doc/thesis/motivation.tex
@@ -0,0 +1,3 @@
+\section{Motivation}
+
+Motivation here
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
index c71abd0..3ab0fcc 100644
--- a/doc/thesis/thesis.tex
+++ b/doc/thesis/thesis.tex
@@ -1,6 +1,5 @@
 \documentclass{scrartcl}
 \usepackage{lipsum}
-\usepackage{listings}
 \usepackage{draftwatermark}
 %%\usepackage[french]{babel}
 %%\usepackage[ngerman]{babel}
@@ -22,7 +21,13 @@
 \addbibresource{bibliothek.bib}
 
 \usepackage{graphicx}
-
+\usepackage{listings}
+\lstset{language=C,
+    basicstyle=\ttfamily,
+    keywordstyle=\bfseries,
+    showstringspaces=false,
+    morekeywords={include, printf, interface}
+}
 
 \begin{document}
 \title{Anastasis}

-- 
To stop receiving notification emails like this one, please contact
address@hidden.