[taler-anastasis] branch master updated: minor fixes

[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 587f55e  minor fixes
587f55e is described below

commit 587f55e0d8f6b73b291033556ef0d4c456a66d74
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Tue Jun 2 17:45:34 2020 +0200

    minor fixes
---
 doc/thesis/implementation.tex      |  2 +-
 doc/thesis/server_architecture.tex | 13 +++++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 79ca1f8..d44f5e6 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -45,7 +45,7 @@ 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 downlaod 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 clien 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 clien 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) \\ 
 After each successfully solved challenge the client will check if one of the 
policies is fullfilled. If one of the policies is finished, the client will 
decrypt the core secret and provide it to the user.
 \end{enumerate}
 
diff --git a/doc/thesis/server_architecture.tex 
b/doc/thesis/server_architecture.tex
index 4bde737..21f3743 100644
--- a/doc/thesis/server_architecture.tex
+++ b/doc/thesis/server_architecture.tex
@@ -21,13 +21,18 @@ The webserver of Anastasis runs a RESTful API. For a 
detailed documentation of t
 REST API see the rest\_api\_documentation in the appendix.
 
 \subsection{Authentication Methods}
-This section describes the supported authentication methods in detail.
+This section describes an overview over the different possible authentication 
methods for Anastasis. In our implementation only the secure question is 
implemented. The other methods are just explained how they would be implemented.
 
 \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!
+The user tells the server with a request that he wants to authenticate with 
him(GET /truth/\$UUID. The server will then generate a pin and send it with an 
SMS provider to the stored number in the truth object. The client then has to 
send another request with the sent pin(GET /truth/\$UUID?resonse=\$RESPONSE). 
The server can now check if the two pins match. Upon success the server will 
release the encrypted key share.
 
 \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!
+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. \\ 
+The user first has to send a request to server that he wants to 
authenticate(GET /truth/\$UUID).
+The server will then send a request to the video authentication provider that 
a user wants to authenticate. The provider will generate a link to a video 
conference which is sent to the user. The authentication provider then checks 
with image if the user is legitimate. Upon success the video provider sends an 
ok to the server and the server will release the key share.
+
+\subsubsection{Post identification (post)}
+The user tells the server with a request that he wants to authenticate with 
him(GET /truth/\$UUID. The server will then send a letter containing a pin with 
a post-service to the users address which is stored in the truth object. The 
client then has to send another request with the sent pin(GET 
/truth/\$UUID?resonse=\$RESPONSE). The server can now check if the two pins 
match. Upon success the server will release the encrypted key share.
 
 \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.
+The user defines a secure question and answer and stores it on a server. The 
server stores the instcructions, here the question, encrypted. The answer is 
stored hashed on the server, the server will never learn the plaintext answer. 
If the user wants to release the key share from the server he must provide the 
hashed answer. The server then checks if the stored and the provided hash 
match. Upon success the server will send the encrypted key share. 
\ No newline at end of file

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