[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: implementation fix business sta
|
From: |
gnunet |
|
Subject: |
[taler-anastasis] branch master updated: implementation fix business start conclusion |
|
Date: |
Tue, 02 Jun 2020 17:23:57 +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 969bc0b implementation fix business start conclusion
969bc0b is described below
commit 969bc0bd07b90b62ac691d95a9e9a482e5d2caf9
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Tue Jun 2 17:23:09 2020 +0200
implementation fix business start conclusion
---
doc/thesis/bibliothek.bib | 36 ++++++++++++-
doc/thesis/business_model.tex | 68 ++---------------------
doc/thesis/conclusion.tex | 9 +++-
doc/thesis/implementation.tex | 122 ++++++++++++++++++++++++++++++++++--------
4 files changed, 146 insertions(+), 89 deletions(-)
diff --git a/doc/thesis/bibliothek.bib b/doc/thesis/bibliothek.bib
index 6be73ec..cc95d28 100644
--- a/doc/thesis/bibliothek.bib
+++ b/doc/thesis/bibliothek.bib
@@ -28,7 +28,41 @@
urldate = {2020-03-07},
url =
{https://www.delltechnologies.com/content/dam/uwaem/production-design-assets/en/gdpi/assets/infographics/dell-gdpi-vb-key-findings-deck.pdf)},
}
-
+@online{gnu_taler,
+ title = {GNU Taler: Features},
+ organization = {Taler Systems SA},
+ year = 2020,
+ urldate = {2020-06-02},
+ url = {https://taler.net/en/features.html},
+}
+@online{postgresql,
+ title = {PostgreSQL: The World's Most Advanced Open Source
Relational Database},
+ organization = {The PostgreSQL Global Development Group},
+ year = 2020,
+ urldate = {2020-06-02},
+ url = {https://www.postgresql.org/},
+}
+@online{libmicrohttpd,
+ title = {GNU Libmicrohttpd},
+ organization = {GNU project},
+ year = 2020,
+ urldate = {2020-06-02},
+ url = {https://www.gnu.org/software/libmicrohttpd/?},
+}
+@online{gnu_project,
+ title = {What is GNU?},
+ organization = {GNU project},
+ year = 2020,
+ urldate = {2020-06-02},
+ url = {https://www.gnu.org/},
+}
+@online{libcurl,
+ title = {libcurl - the multiprotocol file transfer library },
+ organization = {Curl},
+ year = 2020,
+ urldate = {2020-06-02},
+ url = {https://curl.haxx.se/libcurl/},
+}
@online{ccc_merkel,
title = {CCC-Tüftler hackt Merkels Iris und von der Leyens
Fingerabdruck},
author = {Stefan Krempl},
diff --git a/doc/thesis/business_model.tex b/doc/thesis/business_model.tex
index 2b1526d..85a280a 100644
--- a/doc/thesis/business_model.tex
+++ b/doc/thesis/business_model.tex
@@ -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 costs for our start-up are the cloud infrastructure, the authentication
services and the cost for the
-employees. For a detailed view see Budget.
+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.
+
\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. Additionaly the user would
have to pay for expenisve 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,64 +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}
-
-\subsection{Budget}
-FIXME
-\subsubsection{Staff and infrastructure}
-FIXME
-\begin{table}[H]
- \centering
- \begin{tabular}{ | l | l | l | l |}
- \rowcolor{lightgray}
- Expenses & Value & Earnings & Value \\ \hline
- Dominik Meister & 54'000 & Funding & 150'000 \\ \hline
- Dennis Neufeld & 54'000 & & \\ \hline
- Nana Karlstetter & 10'000 & & \\ \hline
- Travel expenses & 10'000 & & \\ \hline
- Cloud Services & 100 & & \\ \hline
- \rowcolor{lightgray}
- Total & 128'100& & 150'000 \\ \hline
- \end{tabular}
- \caption{Staff and infrastructure budget}
-\end{table}
-
-
-FIXME TEXT
-
-\subsubsection{Business}
-fixme text
-
-
-\begin{table}[H]
-\centering
- \begin{tabular}{ | l | l | l | l |}
- \rowcolor{lightgray}
- Expenses & Value & Earnings & Value \\ \hline
- Share capital & 20'000 & Taler Systems SA & 5'000 \\ \hline
- Notary & 2'000 & PEP foundation & 5'000 \\ \hline
- Registration & 600 & & \\ \hline
- Bank account & 400 & Equity & 20'000 \\ \hline
- \rowcolor{lightgray}
- Total & 23'000 & & 30'000 \\ \hline
- \end{tabular}
- \caption{Business budget}
-\end{table}
-
-fixme text
-
-\subsection{Revenue stream}
-FIXME
-\begin{table}[H]
- \centering
- \begin{tabular}{ | l | l | l | l | l | l |}
- \hline
- Year & Users & Clients & Sales & Profit & Employees \\ \hline
- 2020 & 0 & 1 & 5k & -100k & 2.5 FTE \\ \hline
- 2021 & 100000 & 2 & 30k & -50k & 1.5 FTE \\ \hline
- 2022 & 1000000 & 4 & 200k & 0k & 2.0 FTE \\ \hline
- 2023 & 5000000 & 5 & 500k & 100k & 2.0 FTE \\
- \hline
- \end{tabular}
- \caption{Revenue stream}
-\end{table}
\ No newline at end of file
+\end{figure}
\ No newline at end of file
diff --git a/doc/thesis/conclusion.tex b/doc/thesis/conclusion.tex
index b862fa2..0181d07 100644
--- a/doc/thesis/conclusion.tex
+++ b/doc/thesis/conclusion.tex
@@ -1,3 +1,8 @@
-\section{Motivation}
+\section{Conclusion and outlook}
+FIXME !!!!
-Motivation here
+The Anastasis project was a very interesting experience for us. Sadly we could
not meet all the requirements for the project, we were unable to integrate a
non complex authentication method. \\
+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.
+Thanks?
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index aa5255d..79ca1f8 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -1,7 +1,20 @@
\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.
+Additionaly 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 consits of multiple components. On the
following
+graphic is a 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
neccessary to operate Anastasis commercialy, these parts are planned for the
future 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.
\subsection{Application flow}
-This section describes a happy flow between the Anastasis server and the
client.
+This section describes a happy flow of the two protocols of Anastasis, key
splitting and key recovery.
\subsubsection{Secret splitting}
\begin{figure}[H]
@@ -11,14 +24,55 @@ This section describes a happy flow between the Anastasis
server and the client.
\label{fig:secret_split}
\end{figure}
-\subsubsection{Secret recovery}
+\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 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 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}
+\subsubsection{Secret recovery}
\begin{figure}[H]
\centering
\includegraphics[scale=0.5]{images/recovery_process.png}
\caption{Secret recovery process}
\label{fig:recovery_process}
\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 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 \\
+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}
+
+\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 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. \\
+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.
+Additionaly 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}
+\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 suported 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 didnt 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}
+
+
\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. \\
@@ -38,7 +92,11 @@ To start, a user provides their private, unique and
unforgettable identifier as
\\
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 [...]
\begin{lstlisting}
-kdf_id := SCrypt( 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. \\
@@ -52,15 +110,21 @@ 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}
-ver_secret:= HKDF(kdf_id, "ver", keysize)
-eddsa_priv := eddsa_d_to_a(ver_secret)
-eddsa_pub := get_EdDSA_Pub(eddsa_priv)
+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)
+return eddsa_priv, eddsa_pub
+}
\end{lstlisting}
\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
\textbf{kdf\_id}: Hashed identifier. \\
+\textbf{salt}: used that different keys are generated, the salt here is "ver".
\\
+
\textbf{key\_size}: Size of the output, here 32 bytes. \\
\textbf{ver\_secret}: Derived key from the kdf\_id, serves as intermediate
step for the generation of the private key. \\
@@ -78,10 +142,14 @@ 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. \\
+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. \\
\begin{lstlisting}
-(iv,key) := HKDF(kdf_id, nonce, keysize + ivsize)
+encryption_key_create(kdf_id, salt, nonce)
+{
+iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
+return iv,key
+}
\end{lstlisting}
\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
@@ -92,8 +160,6 @@ For symmetric encryption of data we use AES256-GCM. For this
we need a symmetric
\textbf{ivsize}: Size of the AES GCM IV, here 12 bytes \\
-\textbf{prekey}: Original key material. \\
-
\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{key}: Symmetric key which is later used to encrypt the documents with
AES256-GCM. \\
@@ -108,24 +174,36 @@ The keys we have generated are then used to encrypt the
\textbf{recovery documen
Before every encryption a 32-byte nonce is generated. From this the symmetric
key is computed as described above. We use AES256-GCM for the encryption of the
recovery document and the key\_share. To ensure that the key derivation for the
encryption of the recovery document differs fundamentally from that of an
individual key share, we use different salts (“erd” and “eks” respectively).
\begin{lstlisting}
-(iv0, key0) = HKDF(key_id, nonce0, "erd", keysize + ivsize)
-(encrypted_recovery_document, aes_gcm_tag) =
-AES256_GCM(recovery_document, key0, iv0)
-(iv_i, key_i) = HKDF(key_id, nonce_i, "eks",
-[optional data], keysize + ivsize)
-(encrypted_key_share_i, aes_gcm_tag_i) =
-AES256_GCM(key_share_i, key_i, iv_i)
+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 = nonce + aes_gcm_tag + encrypted_data
+ return encrypted_data
+}
+
+key_share_encrypt(kdf_id, key_share)
+{
+ encrypted_key_share = encrypt(kdf_id, key_share, "eks")
+ return encrypted_key_share
+}
+recovery_document_encrypt(kdf_id, recovery_document)
+{
+ encrypted_recovery_document = encrypt(kdf_id, recovery_document, "erd")
+ return encrypted_recovery_document
+}
+
\end{lstlisting}
\textbf{encrypted\_recovery\_document}: The encrypted recovery document which
contains the escrow methods, policies and the encrypted core secret. \\
-\textbf{nonce0}: Nonce which is used to generate key0 and iv0 which are used
for the encryption of the recovery document. Nonce must contain the string
“ERD”. \\
+\textbf{encrypted\_key\_share}: The encrypted key\_share which the escrow
provider must release upon successful authentication.\\
-\textbf{optional data}: Key material that optionally is contributed from the
authentication method to further obfuscate the key share from the escrow
provider. \\
+\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\_key\_share\_i}: The encrypted key\_share which the escrow
provider must release upon successful authentication. Here, i must be a
positive number used to iterate over the various key shares used for the
various escrow methods at the various providers. \\
-nonce\_i
-\textbf{nonce\_i}: Nonce which is used to generate key\_i and iv\_i which are
used for the encryption of the key share. i must be the same number as
specified above for encrypted\_key\_share\_i. Nonce must contain the string
“EKS” plus the according i. \\
+\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.
--
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: implementation fix business start conclusion,
gnunet <=