[taler-anastasis] branch master updated: thesis 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 614cc45  thesis documentation
614cc45 is described below

commit 614cc451343852524f55365afb8a72b71599dc4a
Author: Dominik Meister <address@hidden>
AuthorDate: Tue May 26 18:20:11 2020 +0200

    thesis documentation
---
 doc/thesis/client_architecture.tex  | 139 ++++++++++++++
 doc/thesis/images/system_design.png | Bin 0 -> 41561 bytes
 doc/thesis/server_architecture.tex  | 351 ++++++++++++++++++++++++++++++++++++
 doc/thesis/thesis.tex               |   8 +-
 4 files changed, 495 insertions(+), 3 deletions(-)

diff --git a/doc/thesis/client_architecture.tex 
b/doc/thesis/client_architecture.tex
new file mode 100644
index 0000000..4b99ba1
--- /dev/null
+++ b/doc/thesis/client_architecture.tex
@@ -0,0 +1,139 @@
+\section{Client architecture}
+The Anastasis client architecture consists of two components. A client API 
which communicates with the server and a command line application which 
interacts with the user. The structure of these two components is shown here.
+
+\subsection{Client API}
+The Anastasis Client uses three APIs. The Crypto API which provides the 
different
+cryptographic functions, a service API which sends the request to the server 
and the main client API which manages the communication between the different 
APIs.
+
+\subsubsection{Crypto API}
+
+\subsubsection{Service API}
+
+\subsubsection{Client API}
+
+
+\subsection{Client Application CLI}
+There are two client applications which interact with the user. First the 
Anastasis splitter and second the Anastasis assembler. The splitter application 
is responsible for the backup of the core secret. The assembler is then 
responsible for the recovery of the secret. \\
+ \\ 
+\textbf{Anastasis splitter} \\
+ \\
+\textbf{Available commands: }
+\begin{itemize}
+\item server add \$URL : this command lets the user add escrow providers. The 
command will check if the server is available under the provided url. Afterwards
+it will download its terms and salt. The server needs to be added before the 
user can do any uploads on it.
+\item truth add \$server \$method \$truth : with this command the user can 
upload
+a truth on a previously added server. He needs to specify the method used and 
the
+truth for the method, for example the phone number or the question and the 
answer.
+The programm will check if the server supports the provided method before 
uploading.
+\item policy add \$truth1 \$truth2... : after the user has added all the 
truths he can start to create policies. He can combine the truths in any way he 
wishes. It is also possible to just store one truth in a policy, but this is 
not recommended since it defies the design of the application.
+\item policy : shows all created policies.
+\item truth : shows all created truths.
+\item server : shows all added servers.
+\item publish \$secret : if the user is finished he can publish the 
configuration. The application will then generate the recovery document with 
the provided information and secret. Afterwards it will upload the recovery 
document on every used server.
+\end{itemize}
+Below is an example flow of the application. \\
+\begin{lstlisting}
+//The user starts the programm and passes a json document
+//containing the unforgetable secret(name, social security number..)
+$ anastasis-splitter --me=identity.json 
+splitter> server add $URL1
+OUTPUT: protocol compatibility, high-level terms,
+available policy methods: sms
+=> Server #1 available
+splitter> server add $URL2
+OUTPUT: protocol compatibility, high-level terms, 
+available policy methods: sms, question
+=> Server #2 available
+splitter> truth add server#1 sms +492452526
+=> Truth #1 added for server #1
+splitter> truth add server#2 mail "hoehenweg 80, Biel"
+=> Sorry, server #2 does not support 'mail' 
+splitter> truth add question "favorite color" "red"
+=> Truth #2 added
+splitter> policy add truth#1 truth#2
+=> Policy #1 defined
+splitter> policy
+Policy#1: #truth#1 #truth2
+splitter> truth
+truth#1: server#1 sms  +492452526
+truth#2: server#2 question "favorite color" <OMITTED>
+splitter> truth --secrets
+truth#1: sms  +492452526
+truth#2: question "favorite color" "red"
+splitter> server
+server#1: http://anastasis.example.com/ methods: sms,
+insured up to: 420 KUDOS, cost: 0.4 KUDOS
+splitter> publish 
+Server#1 failure: 402 payment required: 
+payto://pay/ABALSASDFA KUDOS:0.3
+Server#2 failure: 402 payment required: 
+payto://pay/ABALSAADAS KUDOS:0.5
+Total: 0.8 KUDOS
+# Here: taler-wallet-cli payto://pay/ABALASDFA used to pay!
+splitter> publish 
+Server#2 failure: 402 payment required
+# Here: taler-wallet-cli payto://pay/ABASDFASDF used to pay!
+splitter> publish "my super secret"
+Thank you for using Anastasis.
+$
+\end{lstlisting}
+\textbf{Anastasis assembler} \\
+ \\
+\textbf{Available commands:} \\
+\begin{itemize}
+\item truth : shows all available truths in the recovery document and its 
status
+( (-) not solved (+) solved )
+\item policies : shows all available policies in the recovery document and
+the respective status of the truths used in each policy.
+\item try \$truth : this command starts a truth which needs interaction with 
external services like sms or e-mail. It also shows the instructions to solve a 
truth.
+\item answer \$truth \$answer : this command tries to answer the selected 
truth with the provided answer. The application will check the answer and give 
a feedback to the user. Everytime a truth is solved, the client\_api will check 
if a policy is solved, if a policy was solved successfully the application will 
print out the recovered core secret.
+\end{itemize}
+Below is an example flow of the application. \\
+\begin{lstlisting}
+//The user starts the programm and passes a json document
+//containing the unforgetable secret(name, social security number..),
+//a url to a escrow provider which stores his recovery document and
+//the requested version of the recovery document. The client will then
+//download the recovery document within the startup
+$ anastasis-assembler --import https://anastasis.example.com/ 
+--policy-version=42 --me=identity.json 
+assembler> truth 
+truth#1(-): KUDOS 0.0 question "favorite color"
+truth#2(-): KUDOS 0.4 sms
+truth#3(-): KUDOS 2.6 post
+assembler> policies
+policy#1: KUDOS 0.4 truth#1 truth#2 missing
+policy#2: KUDOS 3.0 truth#1 truth#2 truth#3 missing
+assembler> try truth#2
+payto://pay/BASDFASD
+# SMS arrives asynchronously  
+assembler> answer truth#2 1234
+Success truth#2  
+assembler> answer truth#1 "blue"  
+Failed truth#1
+assembler> truth
+truth#1(-): KUDOS 0.0 question "favorite color" 
+truth#2(+): KUDOS 0.4 sms  
+truth#3(-): KUDOS 2.6 post
+assembler> policies
+policy#1: KUDOS 0.0 truth#1 missing
+policy#2: KUDOS 2.6 truth#1 truth#3 missing
+assembler> answer truth#2 "red"  
+Success truth#2
+//One of the policies was solved successfully and the secret is recovered.
+Secret was: "my super secret"
+$
+\end{lstlisting}
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/thesis/images/system_design.png 
b/doc/thesis/images/system_design.png
new file mode 100644
index 0000000..ce99711
Binary files /dev/null and b/doc/thesis/images/system_design.png differ
diff --git a/doc/thesis/server_architecture.tex 
b/doc/thesis/server_architecture.tex
new file mode 100644
index 0000000..7670af9
--- /dev/null
+++ b/doc/thesis/server_architecture.tex
@@ -0,0 +1,351 @@
+\section{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.
+
+\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{Obatain terms of service}
+\textbf{GET /terms}
+\\
+Obtain the terms of service provided by the escrow provider.
+\\
+\textbf{Response: } \\
+Returns an EscrowTermsOfServiceResponse. \\ 
+
+\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.
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
index 3ab0fcc..70bf7c1 100644
--- a/doc/thesis/thesis.tex
+++ b/doc/thesis/thesis.tex
@@ -1,9 +1,7 @@
 \documentclass{scrartcl}
 \usepackage{lipsum}
-\usepackage{draftwatermark}
 %%\usepackage[french]{babel}
 %%\usepackage[ngerman]{babel}
-\SetWatermarkText{DRAFT}
 
 %% Choose default font for the document
 %% Warning : only ONE of the following should be enabled
@@ -48,11 +46,15 @@
 
 \include{design}
 
+\include{server_architecture}
+
+\include{client_architecture}
+
 \include{implementation}
 
 \include{business_model}
 
-\include{conclusion}
+\include{conclusion} 
 
 %% Print the bibibliography and add the section to th table of content
 \printbibliography[heading=bibintoc]

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