[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: fixed some images ack draft
From: |
gnunet |
Subject: |
[taler-anastasis] branch master updated: fixed some images ack draft |
Date: |
Wed, 03 Jun 2020 16:58:30 +0200 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-anastasis] branch master updated: fixed some images ack draft,
gnunet <=