[taler-anastasis] 04/05: worked on introduction

[gnunet]

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

dennis-neufeld pushed a commit to branch master
in repository anastasis.

commit 0f70355524d5ce92dd30dce54837bce9bc996ce9
Author: Dennis Neufeld <dennis.neufeld@students.bfh.ch>
AuthorDate: Fri Jun 5 20:04:42 2020 +0000

    worked on introduction
---
 doc/thesis/acknowledgments.tex              |   2 +-
 doc/thesis/images/system-architecture_2.png | Bin 0 -> 76910 bytes
 doc/thesis/images/user_id.png               | Bin 0 -> 44157 bytes
 doc/thesis/introduction.tex                 |  19 +++++++++++++++++--
 doc/thesis/project_management.tex           |   2 +-
 doc/thesis/related_work.tex                 |   4 ++--
 6 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/doc/thesis/acknowledgments.tex b/doc/thesis/acknowledgments.tex
index 3eced13..dd41ed1 100644
--- a/doc/thesis/acknowledgments.tex
+++ b/doc/thesis/acknowledgments.tex
@@ -1,6 +1,6 @@
 \section*{Acknowledgements}
 \addcontentsline{toc}{section}{Acknowledgements}
-We wish to thank Christian Grothoff for the help and support he has provided 
throughout our work on Anastasis. He helped us resolve bugs and provided us 
feedback for the development. Additionaly he helped us to edit our bachelor 
thesis documents.
+We wish to thank Christian Grothoff for the help and support he has provided 
throughout our work on Anastasis. He helped us resolve bugs and provided us 
feedback for the development. Additionally he helped us to edit our bachelor 
thesis documents.
 We also wish to thank the GNU Taler team, Vaishnavi Mohan, Nana Karlstetter 
and Leon Schumacher which supported us writing and presenting a funding 
proposal.
 Additionaly we want to thank Florian Dold which gave us feedback for our REST 
API documentation.
 We also want to thank Emmanuel Benoist for providing us the paper for MIDATA.  
\ No newline at end of file
diff --git a/doc/thesis/images/system-architecture_2.png 
b/doc/thesis/images/system-architecture_2.png
new file mode 100644
index 0000000..7c2cbd0
Binary files /dev/null and b/doc/thesis/images/system-architecture_2.png differ
diff --git a/doc/thesis/images/user_id.png b/doc/thesis/images/user_id.png
new file mode 100644
index 0000000..42c741c
Binary files /dev/null and b/doc/thesis/images/user_id.png differ
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
index f78e82f..97b33a0 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -1,8 +1,9 @@
 \section{Introduction}
 Secure storage of private cryptographic keys or in general every kind of core 
secret is a big problem because most current key management systems just reduce 
the problem of memorizing a high-entropy passphrase or key to memorizing a 
low-entropy passphrase. This of course cannot be the solution because you 
undermine the whole security of a cryptographic system using such solutions.\\
 Key management systems have to deal with the question, how to store a key. 
Keys are used to encrypt high sensitive personal data and therefore they must 
be kept safely. Only the legitimated owner of a key should have the possibility 
to recover a lost key. Most people have difficulties memorizing a high-entropy 
passphrase and therefore tend to use low-entropy passphrases. That is why you 
can't rely on memorizing a password which is needed to recover a key.\\
+We have a software solution for the described problem. We call our solution 
"Anastasis" which is a term for restoration to health in medicine.\\
 
-There are several applications which are in need of a key escrow system with 
the described properties. For example for email encryption using Pretty Good 
Privacy (PGP)~\cite{garfinkel1995} you need a private key which is stored to 
the device running PGP. Losing the PGP private key means following: All 
received emails which are encrypted with a key derived from the private key are 
unreadable and you need to build your trust network again. Because emails could 
contain high sensitive inform [...]
+There are several applications which are in need of a key escrow system like 
Anastasis. For example for email encryption using Pretty Good Privacy 
(PGP)~\cite{garfinkel1995} you need a private key which is stored to the device 
running PGP. Losing the PGP private key means following: All received emails 
which are encrypted with a key derived from the private key are unreadable and 
you need to build your trust network again. Because emails could contain high 
sensitive information, it is ne [...]
 
 Another application relying on a core secret are cryptocurrencies like 
Bitcoin. Each user of Bitcoin needs a so called Wallet which stores and 
protects the private keys of the user. Those private keys legitimate its owners 
to spend the bitcoins corresponding to the keys \cite{LLLW*2017}. Therefore 
losing those keys means losing all the corresponding Bitcoins which in some 
cases could be a loss of millions of Euros \cite{millions_lost}.\\
 
@@ -19,7 +20,21 @@ For Anastasis we have following design principles, in order 
of importance:
 \end{enumerate}
 
 \subsection{Approaches}
-FIXME
+Our approach to solve the problem of key management is to split a secret into 
several shares and to distribute the shares with an open set of escrow 
providers (see figure \ref{fig:system_arch2}). To restore the secret again, the 
user has to authenticate with the escrow providers. After successful 
authentication the user gets the shares to reassemble the secret.
+\begin{figure}[H]
+\centering
+\includegraphics[scale=0.33]{images/system-architecture_2.png}
+\caption{System architecture}
+\label{fig:system_arch2}
+\end{figure}
+
+
+\begin{figure}[H]
+\centering
+\includegraphics[scale=0.3]{images/user_id.png}
+\caption{Derivation of user identifier}
+\label{fig:user_id}
+\end{figure}
 
 \subsection{Applications}
 FIXME
\ No newline at end of file
diff --git a/doc/thesis/project_management.tex 
b/doc/thesis/project_management.tex
index 19391cd..b869c07 100644
--- a/doc/thesis/project_management.tex
+++ b/doc/thesis/project_management.tex
@@ -3,7 +3,7 @@ This section describes the project planing of Anastasis. A 
detailed reflection o
 \subsection{Project plan}
 The following graphic shows our project plan how we planed to implement 
Anastasis and write our bachelor thesis.
 \begin{figure}[H]
-               \includegraphics[scale=0.6]{images/project_plan_anastasis.pdf}
+               \includegraphics[scale=0.6]{images/project_plan_anastasis.png}
        \caption{Anasasis project plan}
        \label{fig:project_plan_anastasis}
 \end{figure}
diff --git a/doc/thesis/related_work.tex b/doc/thesis/related_work.tex
index 117b25b..5bde002 100644
--- a/doc/thesis/related_work.tex
+++ b/doc/thesis/related_work.tex
@@ -104,8 +104,8 @@ In Anastasis we also need to store the phone number to the 
server. But in our ca
 \subsubsection{E-mail authentication}
 Authentication by email is very similar to SMS authentication. Here, the user 
receives a token by email and has to provide it during the authentication 
process.
 The handling of this token needs some considerations. The token should have 
-a validity period, this means for example the token would only be valid for 
one hour. This is a security measure to prevent malicious actions if the user's 
email account was compromised. Also the token should be a randomly generated 
passphrase which has atleast 8 characters.\\
-Another import part is that the email should never contain the requested 
information, in our case the keyshare. Because there is no guarante that the 
email channel is encrypted. Also the email and the keyshare information would 
be stored for a indefinite period in the user's mailbox. Also the mailbox could 
be compromised of read by an IT department.\cite{emailauthowasp} \\
+a validity period, this means for example the token would only be valid for 
one hour. This is a security measure to prevent malicious actions if the user's 
email account was compromised. Also the token should be a randomly generated 
passphrase which has at least 8 characters.\\
+Another import part is that the email should never contain the requested 
information, in our case the keyshare. Because there is no guarantee that the 
email channel is encrypted. Also the email and the keyshare information would 
be stored for a indefinite period in the user's mailbox. Also the mailbox could 
be compromised of read by an IT department.\cite{emailauthowasp} \\
 As mentioned in the SMS authentication section we also store the email 
encrypted on the server. The user has to provide the corresponding key to the 
server during authentication process.
 
 \subsubsection{VideoIdent}

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