[taler-anastasis] branch master updated: fixed some images ack draft

[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 c6639f8  fixed some images ack draft
c6639f8 is described below

commit c6639f8bfe10ede2f1f307a7a3701fcc5d07a4cc
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Wed Jun 3 16:58:24 2020 +0200

    fixed some images ack draft
---
 doc/thesis/acknowledgments.tex         |   3 +++
 doc/thesis/images/recovery_process.png | Bin 37488 -> 49986 bytes
 doc/thesis/images/secret_split.png     | Bin 49879 -> 62384 bytes
 doc/thesis/images/system_design.png    | Bin 41561 -> 52261 bytes
 doc/thesis/implementation.tex          |  20 ++++++++++++++++----
 5 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/doc/thesis/acknowledgments.tex b/doc/thesis/acknowledgments.tex
new file mode 100644
index 0000000..86776c4
--- /dev/null
+++ b/doc/thesis/acknowledgments.tex
@@ -0,0 +1,3 @@
+\begin{abstract}
+We wish to thank Christian Grothoff for the help and support he has provided 
throughout our work on Anastasis. We also thank the GNU Taler SA which provided 
us feedback within the development and helped us to apply to different fundings.
+\end{abstract}
\ No newline at end of file
diff --git a/doc/thesis/images/recovery_process.png 
b/doc/thesis/images/recovery_process.png
index 3ad0c10..44557a3 100644
Binary files a/doc/thesis/images/recovery_process.png and 
b/doc/thesis/images/recovery_process.png differ
diff --git a/doc/thesis/images/secret_split.png 
b/doc/thesis/images/secret_split.png
index 3288f6f..f6fcc4e 100644
Binary files a/doc/thesis/images/secret_split.png and 
b/doc/thesis/images/secret_split.png differ
diff --git a/doc/thesis/images/system_design.png 
b/doc/thesis/images/system_design.png
index ce99711..20d7de7 100644
Binary files a/doc/thesis/images/system_design.png and 
b/doc/thesis/images/system_design.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index ebbed60..5873a18 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -30,7 +30,8 @@ This section describes a happy flow of the two protocols of 
Anastasis, key split
 \item Next the client requests the server configuration(GET /configuration). 
The configuration lists the available authentication methods and the protocol 
version of the server.
 \item The client downloads the server salt(GET /salt). The salt is used to 
generate the server specific account public key, which identifies the user.
 \item After the user has generated the public key, he will create a truth 
object on the client. The truth object contains all the needed information for 
the recovery for this key share. This truth object is sent encrypted to the 
server and stored under a UUID the client generated(POST /truth/\$UUID).
-\item The user will now repeat the steps 1-5 until he thinks that he has setup 
a sufficient amount of authentication methods. The user can now combine these 
providers to create policies. For example he has stored three truth objects on 
different providers. This means he can now define combinations with these 
providers for example A+B, A+C and B+C. This means he has three ways to recover 
his secret.
+\item In this scenario the client has not jet paid for the upload. This means 
the server will respond with the status code payment required. The client first 
has to do a payment with our payment provider GNU Taler. After the successfull 
payment the client will receive a payment identifier. With this payment 
identifier he can resend the previously failed request.
+\item The user will now repeat the steps 1-6 until he thinks that he has setup 
a sufficient amount of authentication methods. The user can now combine these 
providers to create policies. For example he has stored three truth objects on 
different providers. This means he can now define combinations with these 
providers for example A+B, A+C and B+C. This means he has three ways to recover 
his secret.
 \item After the user has generated the policies the client will generate a 
recovery document. The recovery document contains a list of all UUID's used, a 
list of the policies and the encrypted core secret of the user. The client will 
now send a encrypted recovery document to each provider used in the recovery 
document(POST /policy/\$ACCOUNT\_PUB). Through this the recovery document is 
distributed and has no single point of failure.
 \end{enumerate}
 
@@ -45,9 +46,12 @@ This section describes a happy flow of the two protocols of 
Anastasis, key split
 \item The user selects a server on which he previously stored a recovery 
document.
 \item Next the client downloads the server salt to compute the server specific 
account public key(GET /salt). 
 \item After the user generated the public key he will download the recovery 
document. At this point he can define if he wants a specific version or the 
latest version of the recovery document. In the graphic the client downloads 
the latest version(GET /policy/\$ACCOUNT\_PUB).
-\item The client will now decrypt the recovery document and list all policies 
and authentication methods. The user now has to solve these challenges. For 
example he has to answer a secure question or he has to type in a pin which was 
sent to him by SMS.(GET /truth/\$UUID?resonse=\$RESPONSE) \\ 
+\item The client will now decrypt the recovery document and list all policies 
and authentication methods. The user now has to solve these challenges. In this 
example the user has to answer a secure question which was sent to him in the 
recovery document.(GET /truth/\$UUID?resonse=\$RESPONSE) \\
+\item Note the server can define that a challenge has a certain cost, in this 
scenario the server rejects the first request because the user has not jet 
paid. After the payment with our payment provider GNU Taler the user can resend 
the request.
 After each successfully solved challenge the client will check if one of the 
policies is fulfilled. If one of the policies is finished, the client will 
decrypt the core secret and provide it to the user.
 \end{enumerate}
+This graphic shows the flow for a sequre question. If the user would have 
chosen a complex authentication method like SMS or E-Mail, the client would 
first need to start the challenge with the request (GET /truth/\$UUID). The 
server would then notifify the user that he will answer out of bounds. After 
that the user would have to provide for example the pin sent to him by SMS with 
the same request as before(GET /truth/\$UUID?resonse=\$RESONSE).
+
 
 \subsection{Libraries}
 In this section the libraries used for Anastasis are presented.
@@ -71,8 +75,16 @@ GNU libmicrottpd is a small C library which provides a easy 
way to run a HTTP se
 We use GNU Libmicrohttpd in Anastasis to provide a simple webserver. The main 
reason why we didn't use apache or nginx is that we do not need a standalone 
webserver. The Anastasis webserver just has to handle some API requests, a 
standalone webserver is not needed for that and would make the infrastructure 
more complex to maintain and develop. Since GNU Libmicrohttpd is also part of 
the GNU project it will remain free software.\cite{libmicrohttpd}
 
 \subsection{Testing}
-
-
+To test our application we used the GNU Taler testing library as our 
foundation. 
+This library allows you to create testing instances of both the Anastasis 
application and the GNU Taler payment system. We implemented unit tests for 
every command in our application. A simplified test flow would be the following.
+\begin{enumerate}
+\item The testing library starts an instance of the Anastasis server and a GNU 
Taler merchant and exchange service.
+\item The Anastasis server will connect to a test database only used for 
testing.
+\item The testing library first sets up the database and tests if it can 
create records.
+\item Next we test the Anastasis crytpo API, it tests all the cryptographic 
functions used in the API. The most important part is that the recreation of 
the keys and decryption works as intended.
+\item After the basic parts of the application are tested the client will test 
every request in the Anastasis server API. It will check if the server responds 
the intended way and if the status codes are correct.
+\item At the end the whole application flow is tested, the testing library 
will first perform a secret split and then a secret recovery. It tests if the 
core functionality of the application works and if the secret is recovered 
correctly.
+\end{enumerate}
 
 \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. \\

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.