[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: spellchecker
|
From: |
gnunet |
|
Subject: |
[taler-anastasis] branch master updated: spellchecker |
|
Date: |
Sat, 06 Jun 2020 19:18:35 +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 f8af1ac spellchecker
f8af1ac is described below
commit f8af1accdbe69b566cb5855f4e281488d835c915
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Sat Jun 6 19:18:18 2020 +0200
spellchecker
---
doc/thesis/acknowledgments.tex | 4 +-
doc/thesis/business_model.tex | 16 ++++----
doc/thesis/conclusion.tex | 8 ++--
doc/thesis/design.tex | 18 ++++-----
doc/thesis/images/secret_split.png | Bin 62384 -> 62299 bytes
doc/thesis/implementation.tex | 78 ++++++++++++++++++-------------------
doc/thesis/server_architecture.tex | 14 +++----
doc/thesis/thesis.tex | 5 +--
8 files changed, 71 insertions(+), 72 deletions(-)
diff --git a/doc/thesis/acknowledgments.tex b/doc/thesis/acknowledgments.tex
index dd41ed1..4094f7c 100644
--- a/doc/thesis/acknowledgments.tex
+++ b/doc/thesis/acknowledgments.tex
@@ -2,5 +2,5 @@
\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. 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
+Additionally, 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.
diff --git a/doc/thesis/business_model.tex b/doc/thesis/business_model.tex
index 85a280a..46aceb6 100644
--- a/doc/thesis/business_model.tex
+++ b/doc/thesis/business_model.tex
@@ -1,15 +1,15 @@
\section{Business model}
\subsection{Introduction}
-We are currently in the process of building a start-up for the Anastasis
application. This business model shows an overview how we want to build our
start-up and how we want to continue our work on the project.
+We are currently in the process of building a start-up for the Anastasis
application. This business model shows an overview how we want to build our
start-up and how we want to continue our work on the project.
\subsection{Executive Summary}
Users of cryptography are frequently facing the challenge to secure their core
secrets (private keys), and the contemporary default of asking them to remember
strong passphrases is inadequate for mass adoption. The loss of such a core
secret can cause severe damage for a user. Our project was conceived as a
solution to
similar problems several privacy enhancing software projects are facing today.
Specifically, the Swiss Pretty Easy Privacy project (https://pep.foundation),
an E-Mail encryption solution which needs an easy way for users to recover
their private keys to avoid the loss of encrypted E-Mails.
The GNU Taler team (lead by Prof. Grothoff) is building an electronic payment
system and is facing an equivalent challenge: the European Central Bank
informed them about a requirement for electronic wallets denominated in Euros
to support password-less data recovery.
We designed Anastasis to address this common problem of cryptographic consumer
products.
-Within our bachelor thesis we could build a working prototype of the
application.
-But this application is not a finished finished product. Within the thesis we
only could implement rudimentary authentication methods. To satisfy the
-requirements of our industry partners we need to have several different
authentication methods (SMS, Videoindent...) implemented. Additionally, the
Anastasis environment will need proper automatization. Specifically, monitoring
of the integration with external authentication providers, the correct
operation of the backup mechanism and the business logic. To make Anastasis
ready for public usage we estimate the need of an additional year of
development.
+Within our bachelor thesis we could build a working prototype of the
application.
+But this application is not a finished product. Within the thesis we only
could implement rudimentary authentication methods. To satisfy the
+requirements of our industry partners we need to have several different
authentication methods (SMS, Videoident...) implemented. Additionally, the
Anastasis environment will need proper automatization. Specifically, monitoring
of the integration with external authentication providers, the correct
operation of the backup mechanism and the business logic. To make Anastasis
ready for public usage we estimate the need of an additional year of
development.
The resulting start-up would initially receive B2B revenue from companies that
need our solution for their cryptographic consumer product. In addition to
Taler and PEP we are in discussion with developers of crypto currencies from
Zug and Lausanne. Subsequently these contacts would evolve into distribution
channels,
and Anastasis would eventually earn money directly from its users.
Cryptographic solutions which are not open to the public are not trustworthy.
As seen lately with the Crypto AG. Experts recommend to only use Free and Libre
Open Source Software (FLOSS) especially for cryptography. Therefore, Anastasis
is licensed under the Affero GPL which will prevent other companies
@@ -18,7 +18,7 @@ Being first to market and thus the default provider in
various consumer products
\subsection{Market review and innovation potential}
-There are already some key recovery or key splitting solutions on the market.
For example, there is a solution from Coinbase. Coinbase is a global digital
asset exchange company, providing a venue to buy and sell digital currencies.
Coinbase also uses wallets secured with private keys. To recover this private
key the user has to provide a 12 words recovery phrase. Coinbase now offers a
solution to securely deposit this recovery phrase onto the users Google Drive.
The security here lies w [...]
+There are already some key recovery or key splitting solutions on the market.
For example, there is a solution from Coinbase. Coinbase is a global digital
asset exchange company, providing a venue to buy and sell digital currencies.
Coinbase also uses wallets secured with private keys. To recover this private
key the user has to provide a 12 words recovery phrase. Coinbase now offers a
solution to securely deposit this recovery phrase onto the users Google Drive.
The security here lies w [...]
Today information losses from security incidents are rampant, either because
data is exposed (loss of confidentiality) or because users lose their data
because of lacking backups (loss of availability). As seen in the study of the
Global Data Protection Index 2018 \cite{global_data_index}, 76\% of those
interviewed had an availability incident. 1TB of data loss or 20 hours of
downtime reportedly costs half a million dollars. On the other hand, loss of
confidential private data can result [...]
Prominent cases in which sometimes enormous amounts of money have been gone
useless by losing the key to the digital wallet clarify the urgent need of a
key recovery system like Anastasis. For example the case QuadrigaCX exchange
was heavily discussed in the media when the chief executive, Gerald Cotton,
unexpectedly died and left £145 million in a “cold wallet”.
\cite{millions_lost} In some cases there is a workaround to recover a lost key,
provided there is a security hole in the digit [...]
@@ -44,11 +44,11 @@ As mentioned earlier our customers will be primarily other
solutions which need
Many applications with decentralized structures need such a solution.
Other possible customers are users of digital currencies or users of OpenPGP
solutions.
\subsubsection{Cost structure}
-The main costs for our start-up is the salary of our employees. We need to
have two fulltime employees for the development and one part time employee for
the business development. Additional costs for the start-up are the costs for
registering a company. To provide Anastasis we need Cloud-services, these would
also cost a little bit.
+The main cost for our start-up is the salary of our employees. We need to have
two fulltime employees for the development and one part time employee for the
business development. Additional costs for the start-up are the costs for
registering a company. To provide Anastasis we need Cloud-services, these would
also cost a little bit.
\subsubsection{Revenue streams}
In the beginning, businesses like Taler Systems SA will pay us to operate an
Anastasis server and to help them integrate our protocol with their software.
-Once we have many end-users utilizing Anastasis, they will have to pay
directly for the service. The users have to pay a subscription fee and micro
payments for each transaction. For example a user has to pay 0.1 CHF per month
for the subscription and 0.01 CHF for each upload. Additionaly the user would
have to pay for expenisve authentication methods like video identification.
+Once we have many end-users utilizing Anastasis, they will have to pay
directly for the service. The users have to pay a subscription fee and micro
payments for each transaction. For example a user has to pay 0.1 CHF per month
for the subscription and 0.01 CHF for each upload. Additionally, the user would
have to pay for expensive authentication methods like video identification.
\subsection{Project plan}
Our objective for the first year is for Anastasis to implement several
authentication services, have a working cloud deployment with good monitoring,
and to be integrated with various cryptographic consumer products.
@@ -60,4 +60,4 @@ Key milestones are the various integrations of the different
authentication meth
\includegraphics[scale=0.65]{images/project_plan.png}
\caption{Business project plan}
\label{fig:bi_project_plan}
-\end{figure}
\ No newline at end of file
+\end{figure}
diff --git a/doc/thesis/conclusion.tex b/doc/thesis/conclusion.tex
index 79470a7..86bbdf8 100644
--- a/doc/thesis/conclusion.tex
+++ b/doc/thesis/conclusion.tex
@@ -1,5 +1,5 @@
\section{Conclusion and outlook}
-The Anastasis project was a very interesting experience for us. We could learn
alot in software development and learned alot about the process of funding
proposals.
-We may did not meet all the technical requirements, but instead we have been
able to establish many business oppurtunities.\\
-The Anastasis project won't be finished by this point, at the moment we are
starting to build a start-up to be able to continue working on Anastasis.
-We think that our protocol is good designed and can solve the problem of key
recovery. We hope that in the future people can backup their keys with
Anastasis.
+The Anastasis project was a very interesting experience for us. We could learn
a lot in software development and learned a lot about the process of funding
proposals.
+We may did not meet all the technical requirements, but instead we have been
able to establish many business opportunities.\\
+The Anastasis project will not be finished by this point, at the moment we are
starting to build a start-up to be able to continue working on Anastasis.
+We think that our protocol is good designed and can solve the problem of key
recovery. We hope that in the future people can back up their keys with
Anastasis.
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 8503925..74158f3 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -1,13 +1,13 @@
\section{Design}
-Anastasis is a service that allows the user to securely deposit a core secret
with an open set of escrow providers and recover it if the secret is lost. The
core secret itself is protected from the escrow providers by encrypting it with
a master key. The main objective of Anastasis is to ensure that the user can
reliably recover the core secret, while making this difficult for everyone
else. Furthermore, it is assumed that the user is unable to reliably remember
any secret with sufficien [...]
+Anastasis is a service that allows the user to securely deposit a core secret
with an open set of escrow providers and recover it if the secret is lost. The
core secret itself is protected from the escrow providers by encrypting it with
a master key. The main objective of Anastasis is to ensure that the user can
reliably recover the core secret, while making this difficult for everyone
else. Furthermore, it is assumed that the user is unable to reliably remember
any secret with sufficien [...]
\\
To uniquely identify users, an “unforgettable” identifier is used. This
identifier should be difficult to guess for anybody but the user. However, the
identifier is not expected to have sufficient entropy or secrecy to be
cryptographically secure. Examples for such identifier would be a concatenation
of the full name of the user and their social security or passport number(s).
For Swiss citizens, the AHV number could also be used. \\
\\
-The adversary model of Anastasis has two types of adversaries: weak
adversaries which do not know the user’s identifier, and strong adversaries
which somehow do know a user’s identifier. For weak adversaries the system
guarantees full confidentiality. For strong adversaries, breaking
confidentiality additionally requires that Anastasis escrow providers must have
colluded. The user is able to specify a set of policies which determine which
Anastasis escrow providers would need to collude [...]
+The adversary model of Anastasis has two types of adversaries: weak
adversaries which do not know the user’s identifier, and strong adversaries
which somehow do know a user’s identifier. For weak adversaries, the system
guarantees full confidentiality. For strong adversaries, breaking
confidentiality additionally requires that Anastasis escrow providers must have
colluded. The user can specify a set of policies which determine which
Anastasis escrow providers would need to collude to bre [...]
\\
-A recovery document includes all of the information a user needs to recover
access to their core secret. It specifies a set of escrow methods, which
specify how the user should convince the Anastasis server that they are “real”.
Escrow methods can for example include SMS-based verification,
Video-identfication or a security question. For each escrow method, the
Anastasis server is provided with truth, that is data the Anastasis operator
may learn during the recovery process to authentica [...]
+A recovery document includes all the information a user needs to recover
access to their core secret. It specifies a set of escrow methods, which
specify how the user should convince the Anastasis server that they are “real”.
Escrow methods can for example include SMS-based verification,
Video-identification or a security question. For each escrow method, the
Anastasis server is provided with truth, that is data the Anastasis operator
may learn during the recovery process to authenticate [...]
-\subsection{Systemarchitecture}
+\subsection{System architecture}
This graphic shows the basic construct of the Anastasis application. It shows
a simplified flow of the application. The details of each component is shown
later.
\begin{figure}[H]
\centering
@@ -17,11 +17,11 @@ This graphic shows the basic construct of the Anastasis
application. It shows a
\end{figure}
\begin{enumerate}
-\item The Anastasis CLI interacts with the anastasis api. The anastasis\_api
is responsible for the communication with the user. The anastasis\_api also
handles the communication between the other client components.
-\item After the user provided their unforgetable secret, the crypto\_api
derives the needed key material for the further communication. This is
simplified, in reality the client would first need to download the server salt
to generate the user keys.
+\item The Anastasis CLI interacts with the Anastasis API. The Anastasis\_API
is responsible for the communication with the user. The Anastasis\_API also
handles the communication between the other client components.
+\item After the user provided their unforgettable secret, the Crypto\_API
derives the needed key material for the further communication. This is
simplified, in reality the client would first need to download the server salt
to generate the user keys.
The crypto\_api is later also responsible for the decryption and encryption of
the data, sent or received from the server.
-\item The service\_api is responsible for the communication with the anastasis
server. The anastasis\_api sends the previously generated data and the user
selected request to the service.
-\item The service\_api generates the requested HTTP request and sends it to
the webserver. The service\_api is also responsible to handle the server answer
to the request.
+\item The Service\_API is responsible for the communication with the Anastasis
server. The Anastasis\_API sends the previously generated data and the user
selected request to the service.
+\item The Service\_API generates the requested HTTP request and sends it to
the webserver. The Service\_API is also responsible to handle the server answer
to the request.
\item The webserver handles the requests sent to him by the clients. It will
then send the request to the according handle. The webserver will later send
back the requested data or the status code of the operation back to the client
application.
\item Each operation has a different handle. The handle will then process the
request. It will either store or lookup the requested data on the database.
When the request is finished, the handle will send back the data or the status
code to the webserver and afterwards to the client.
-\end{enumerate}
\ No newline at end of file
+\end{enumerate}
diff --git a/doc/thesis/images/secret_split.png
b/doc/thesis/images/secret_split.png
index f6fcc4e..b16a175 100644
Binary files a/doc/thesis/images/secret_split.png and
b/doc/thesis/images/secret_split.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 5873a18..e6d436d 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -1,17 +1,17 @@
-\section{Implementation}
+Argon2\section{Implementation}
The whole Anastasis software is written in C. We decided to use C because of
the various cryptographic libraries and the available documentations.
-Additionally GNU Taler and Sync which are working close with Anastasis are
also written in C. This makes the integration of our application much easier.\\
+Additionally, GNU Taler and Sync which are working close with Anastasis are
also written in C. This makes the integration of our application much easier.\\
The whole Anastasis application consists of multiple components. On the
following
-graphic is a overview over all the components in Anastasis. \\
+graphic is an overview over all the components in Anastasis. \\
\begin{figure}[H]
\centering
\includegraphics[scale=0.5]{images/system-architecture.png}
\caption{Secret split process}
\label{fig:secret_split}
\end{figure}
-On the left are some of the planed authentication methods from the
application. On the right side of the box are the core parts which are
necessary to operate Anastasis commercially, these parts are planned for the
future and not part of this thesis. \\
+On the left are some of the planed authentication methods from the
application. On the right side of the box are the core parts which are
necessary to operate Anastasis commercially, these parts are planned and not
part of this thesis. \\
At the bottom section are the external libraries used for the project. These
libraries are presented in the section Libraries. \\
-In the center is the core implementation of Anastasis.
+In the centre is the core implementation of Anastasis.
\subsection{Application flow}
This section describes a happy flow of the two protocols of Anastasis, key
splitting and key recovery.
@@ -25,12 +25,12 @@ This section describes a happy flow of the two protocols of
Anastasis, key split
\end{figure}
\begin{enumerate}
-\item The user selects a new escrow provider on which he wants to store a
truth object.
-\item The client software downloads the terms of service for this provider(GET
/terms). This is also a check if the server is available, if this command
doesn't respond the client will abort the process.
+\item The user selects a new escrow provider on which he wants to store a
truth object.
+\item The client software downloads the terms of service for this provider(GET
/terms). This is also a check if the server is available if this command
doesn't respond the client will abort the process.
\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 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 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
must do a payment with our payment provider GNU Taler. After the successful
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}
@@ -44,44 +44,44 @@ This section describes a happy flow of the two protocols of
Anastasis, key split
\end{figure}
\begin{enumerate}
\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 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. 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.
+After each successfuly 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).
+This graphic shows the flow for a secure 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 notify 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.
\subsubsection{GNU Taler}
-GNU Taler is one of the main reason why we started to implement Anastasis,
since the application needs a system to backup the private keys of their users.
+GNU Taler is one of the main reasons why we started to implement Anastasis,
since the application needs a system to back up the private keys of their users.
"GNU Taler is a privacy-preserving payment system. Customers can stay
anonymous, but merchants can not hide their income through payments with GNU
Taler. This helps to avoid tax evasion and money laundering."\cite{gnu_taler}
\\
-To operate GNU Taler the user needs to install an electronic wallet. This
wallet is secured with a private key. Here comes Anastasis into play, Anastasis
will secure this private key for the user. \\
+To operate GNU Taler the user needs to install an electronic wallet. This
wallet is secured with a private key. Here comes Anastasis into play, Anastasis
will secure this private key for the user. \\
In our implementation GNU Taler is also our payment system. We decided to use
GNU Taler because both Anastasis and GNU Taler are privacy preserving
applications. If we for example used credit cards for payments the user would
no longer be anonymous which is a core part of Anastasis.
Additionally GNU Taler is in the GNU package, this means it will always remain
free software.\cite{gnu_taler}
\subsubsection{PostgreSQL}
-PostgreSQL is a open source object-relational database. PostgreSQL has over 30
years of active development which makes it a very stable and reliable software.
\\
-We use PostgreSQL as our database on the Anastasis server. We decided to use
PostgreSQL because its a open source and lightweight software which has a big
community.
-This means there are alot of helpful documentations and
forums.\cite{postgresql}
+PostgreSQL is an open source object-relational database. PostgreSQL has over
30 years of active development which makes it a very stable and reliable
software. \\
+We use PostgreSQL as our database on the Anastasis server. We decided to use
PostgreSQL because it is an open source and lightweight software which has a
big community.
+This means there are a lot of helpful documentations and
forums.\cite{postgresql}
\subsubsection{Libcurl}
Libcurl is a free URL transfer library. Libcurl supports a wide range of
protocols and a C API. Libcurl is also ready for IPv6 and SSL certificates. \\
-For Anastasis we use Libcurl to generate the client side HTTP requests. We
decided to use Libcurl because it is also written in C and free software. The
software is also well supported and has a good documentation.
+For Anastasis we use Libcurl to generate the client-side HTTP requests. We
decided to use Libcurl because it is also written in C and free software. The
software is also well supported and has a good documentation.
This makes the integration in our application very easy.\cite{libcurl}
\subsubsection{GNU Libmicrohttpd}
-GNU libmicrottpd is a small C library which provides a easy way to run a HTTP
server.
-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}
+GNU libmicrottpd is a small C library which provides an easy way to run a HTTP
server.
+We use GNU Libmicrohttpd in Anastasis to provide a simple webserver. The main
reason why we did not use apache or nginx is that we do not need a standalone
webserver. The Anastasis webserver just must 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.
+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 Next we test the Anastasis crypto 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}
@@ -95,20 +95,20 @@ The public account key is Crockford base32-encoded in the
URI to identify the ac
\\
When confidential data is uploaded to an Anastasis server, the respective
payload is encrypted using AES-GCM with a symmetric key and initialization
vector derived from the identifier and a high-entropy nonce. The nonce and the
GCM tag are prepended to the ciphertext before being uploaded to the Anastasis
server. This is done whenever confidential data is stored with the server.\\
\\
-The core secret of the user is (AES) encrypted using a symmetric master key.
Recovering this master key requires the user to satisfy a particular policy.
Policies specify a set of escrow methods, each of which leads the user to a key
share. Combining those key shares (by hashing) allows the user to obtain a
policy key, which can be used to decrypt the master key. There can be many
policies, satisfying any of these will allow the user to recover the master
key. A recovery document contain [...]
+The core secret of the user is (AES) encrypted using a symmetric master key.
Recovering this master key requires the user to satisfy a policy. Policies
specify a set of escrow methods, each of which leads the user to a key share.
Combining those key shares (by hashing) allows the user to obtain a policy key,
which can be used to decrypt the master key. There can be many policies,
satisfying any of these will allow the user to recover the master key. A
recovery document contains the encry [...]
\subsection{Key Derivations}
-EdDSA and ECDHE public keys are always points on Curve25519 and represented
using the standard 256 bit Ed25519 compact format. The binary representation is
converted to Crockford Base32 when transmitted inside JSON or as part of URLs.\\
+EdDSA and ECDHE public keys are always points on Curve25519 and represented
using the standard 256-bit Ed25519 compact format. The binary representation is
converted to Crockford Base32 when transmitted inside JSON or as part of URLs.\\
\\
To start, a user provides their private, unique and unforgettable identifier
as a seed to identify their account. For example, this could be a social
security number together with their full name. Specifics may depend on the
cultural context, in this document we will simply refer to this information as
the identifier.\\
\\
-This identifier will be first hashed with SCrypt, to provide a kdf\_id which
will be used to derive other keys later. The Hash must also include the
respective server\_salt. This also ensures that the kdf\_id is different on
each server. The use of SCrypt and the respective server\_salt is intended to
make it difficult to brute-force kdf\_id values and help protect user’s
privacy. Also this ensures that the kdf\_ids on every server differs. However,
we do not assume that the identifier o [...]
+This identifier will be first hashed with Argon2, to provide a kdf\_id which
will be used to derive other keys later. The Hash must also include the
respective server\_salt. This also ensures that the kdf\_id is different on
each server. The use of Argon2 and the respective server\_salt is intended to
make it difficult to brute-force kdf\_id values and help protect user’s
privacy. Also this ensures that the kdf\_ids on every server differs. However,
we do not assume that the identifier o [...]
\begin{lstlisting}
-user_identifier_create(identifier, server_salt, keysize)
+user_identifier_create(identifier, server_salt, keysize)
{
kdf_id = Argon2(identifier, server_salt, keysize)
return kdf_id
-}
+}
\end{lstlisting}
\textbf{identifier}: The secret defined from the user beforehand. \\
@@ -123,7 +123,7 @@ For users to authorize “policy” operations we need an EdDSA
key pair. As we
For the generation of the private key we use the kdf\_id as the entropy
source, hash it to derive a base secret which will then be processed to fit the
requirements for EdDSA private keys. From the private key we can then generate
the corresponding public key. Here, “ver” is used as a salt for the HKDF to
ensure that the result differs from other cases where we hash kdf\_id. \\
\begin{lstlisting}
eddsa_keys_create (kdf_id, salt, keysize)
-{
+{
ver_secret = HKDF(kdf_id, salt, keysize)
eddsa_priv = eddsa_d_to_a(ver_secret)
eddsa_pub = get_eddsa_pub(eddsa_priv)
@@ -144,7 +144,7 @@ return eddsa_priv, eddsa_pub
\textbf{eddsa\_d\_to\_a()}: Function which converts the ver\_key to a valid
EdDSA private key. Specifically, assuming the value eddsa\_priv is in a 32-byte
array “digest”, the function clears and sets certain bits as follows: \\
\begin{lstlisting}
-digest[0] = (digest[0] & 0x7f) | 0x40;
+digest[0] = (digest[0] & 0x7f) | 0x40;
digest[31] &= 0xf8;
\end{lstlisting}
@@ -154,7 +154,7 @@ digest[31] &= 0xf8;
\subsection{Encryption}
-For symmetric encryption of data we use AES256-GCM. For this we need a
symmetric key and an initialization vector (IV). To ensure that the symmetric
key changes for each encryption operation, we compute the key material using an
HKDF over a nonce and the kdf\_id. Additionaly a salt is added so the different
encryption keys differ fundamentaly. For example for the recovery document key
the salt "erd" is added. \\
+For symmetric encryption of data, we use AES256-GCM. For this we need a
symmetric key and an initialization vector (IV). To ensure that the symmetric
key changes for each encryption operation, we compute the key material using an
HKDF over a nonce and the kdf\_id. Additionally, a salt is added so the
different encryption keys differ fundamentally. For example for the recovery
document key the salt "erd" is added. \\
\begin{lstlisting}
encryption_key_create(kdf_id, salt, nonce)
@@ -172,7 +172,7 @@ return iv,key
\textbf{ivsize}: Size of the AES GCM IV, here 12 bytes \\
-\textbf{nonce}: 32-byte nonce, must never match “ver” (which it cannot as the
length is different). Of course, we must avoid key reuse. So, we have to use
different nonces to get different keys and ivs (see below). \\
+\textbf{nonce}: 32-byte nonce, must never match “ver” (which it cannot as the
length is different). Of course, we must avoid key reuse. So, we must use
different nonces to get different keys and ivs (see below). \\
\textbf{key}: Symmetric key which is later used to encrypt the documents with
AES256-GCM. \\
@@ -190,7 +190,7 @@ encrypt(kdf_id, data, salt)
{
nonce = generate_random_bytes(32)
iv, key = encryption_key_create(kdf_id, salt, nonce)
- encrypted_data, aes_gcm_tag = AES256_GCM(data, iv, key)
+ encrypted_data, aes_gcm_tag = AES256_GCM(data, iv, key)
encrypted_data = nonce + aes_gcm_tag + encrypted_data
return encrypted_data
}
@@ -214,14 +214,14 @@ recovery_document_encrypt(kdf_id, recovery_document)
\textbf{nonce}: Nonce which is used to generate keys and ivs which are used
for the encryption. The nonce must contain either eks or erd.
-\textbf{encrypted\_data}: The encrypted data contains the either a recovery
document or a key share which was encrypted and the nonce and the
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the
next 12 Bytes are the
+\textbf{encrypted\_data}: The encrypted data contains the either a recovery
document or a key share which was encrypted and the nonce and the
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the
next 12 Bytes are the
aes\_gcm\_tag.
\subsubsection{Signatures}
The EdDSA keys are used to sign the data sent from the client to the server.
Everything the client sends to server is signed. The following algorithm is
equivalent for Anastasis-Policy-Signature.
\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
+(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub
\end{lstlisting}
@@ -229,11 +229,11 @@ ver_res = eddsa_verifiy(h_body,
anastasis-account-signature, eddsa_pub
\textbf{h\_body}: The hashed body. \\
-\textbf{ver\_res}: A boolean value. True: Signature verification passed,
False: Signature verification failed. \\
+\textbf{ver\_res}: A Boolean value. True: Signature verification passed,
False: Signature verification failed. \\
\\
When requesting policy downloads, the client must also provide a signature:
\begin{lstlisting}
-(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
+(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
\end{lstlisting}
@@ -241,8 +241,8 @@ ver_res = eddsa_verifiy(version,
anastasis-account-signature, eddsa_pub)
\textbf{version}: The version requested as a 64-bit integer, for the “latest
version”. \\
-\textbf{ver\_res}: A boolean value. True: Signature verification passed,
False: Signature verification failed. \\
+\textbf{ver\_res}: A Boolean value. True: Signature verification passed,
False: Signature verification failed. \\
\subsection{Availability Considerations}
-Anastasis considers two main threats against availability. First, the
Anastasis server operators must be protected against denial-of-service attacks
where an adversary attempts to exhaust operator’s resources. The API protects
against these attacks by allowing operators to set fees for all operations.
Furthermore, all data stored comes with an expiration logic, so an attacker
cannot force servers to store data indefinitively.
-A second availability issue arises from strong adversaries that may be able to
compute the account keys of some user. While we assume that such an adversary
cannot successfully authenticate against the truth, the account key does
inherently enable these adversaries to upload a new policy for the account.
This cannot be prevented, as the legitimate user must be able to set or change
a policy using only the account key. To ensure that an adversary cannot exploit
this, policy uploads first [...]
+Anastasis considers two main threats against availability. First, the
Anastasis server operators must be protected against denial-of-service attacks
where an adversary attempts to exhaust operator’s resources. The API protects
against these attacks by allowing operators to set fees for all operations.
Furthermore, all data stored comes with an expiration logic, so an attacker
cannot force servers to store data indefinitely.
+A second availability issue arises from strong adversaries that may be able to
compute the account keys of some user. While we assume that such an adversary
cannot successfuly authenticate against the truth, the account key does
inherently enable these adversaries to upload a new policy for the account.
This cannot be prevented, as the legitimate user must be able to set or change
a policy using only the account key. To ensure that an adversary cannot exploit
this, policy uploads first o [...]
diff --git a/doc/thesis/server_architecture.tex
b/doc/thesis/server_architecture.tex
index 21f3743..0692699 100644
--- a/doc/thesis/server_architecture.tex
+++ b/doc/thesis/server_architecture.tex
@@ -10,11 +10,11 @@ The database schema of Anastasis is structured as follows.
\end{figure}
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 Truth table is responsible for storing the key shares and its
authentication method. The key share and the truth are stored encrypted in the
database. The truth is only decrypted during authentication. The key share 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.
+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
at least 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 [...]
+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 recovery document 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 duplicate of the document. Last
the signature ensures the inte [...]
\subsection{Server API}
The webserver of Anastasis runs a RESTful API. For a detailed documentation of
the
@@ -24,15 +24,15 @@ REST API see the rest\_api\_documentation in the appendix.
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)}
-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.
+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 must
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. \\
-The user first has to send a request to server that he wants to
authenticate(GET /truth/\$UUID).
+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 must 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)}
-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
+The user defines a secure question and answer and stores it on a server. The
server stores the instructions, 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.
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
index cc806d4..7ced33c 100644
--- a/doc/thesis/thesis.tex
+++ b/doc/thesis/thesis.tex
@@ -40,15 +40,14 @@
Dennis Neufeld (\texttt{dennis.neufeld@students.bfh.ch })}
\maketitle
\clearpage
-
\pagenumbering{roman}
\include{acknowledgments}
\include{abstract}
-
\tableofcontents
\clearpage
-
+\include{glossary}
+\clearpage
\pagenumbering{arabic}
\include{introduction}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-anastasis] branch master updated: spellchecker,
gnunet <=