[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated: dos2unix
From: |
gnunet |
Subject: |
[taler-anastasis] branch master updated: dos2unix |
Date: |
Sat, 06 Jun 2020 21:47:16 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository anastasis.
The following commit(s) were added to refs/heads/master by this push:
new 5da2d60 dos2unix
5da2d60 is described below
commit 5da2d60cc728fee81aeace4e10510193a1ea6bed
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Jun 6 21:47:13 2020 +0200
dos2unix
---
doc/thesis/abstract.tex | 33 +++++++++---
doc/thesis/introduction.tex | 122 ++++++++++++++++++++++----------------------
2 files changed, 88 insertions(+), 67 deletions(-)
diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
index 84192f9..55c2e76 100644
--- a/doc/thesis/abstract.tex
+++ b/doc/thesis/abstract.tex
@@ -2,12 +2,33 @@
\begin{abstract}
%\addcontentsline{toc}{section}{Abstract} % Usually not in TOC
-Everyone has probably noticed at least once through the media that someone has
lost their key to their electronic wallet and therefore huge sums of money have
become useless. Therefore, backup systems are essential to avoid such cases.\\
+Everyone has probably noticed at least once through the media that
+someone has lost their key to their electronic wallet and therefore
+huge sums of money have become useless. Therefore, backup systems are
+essential to avoid such cases.
-But how should one create and manage such a backup of a key? It certainly
makes no sense to encrypt a key with a different password and then use the
result as a backup. After all, this password can also be forgotten. Apart from
that, the question arises how or where to save such a backup. A simple storage
on e.g. Google Drive bears several risks: On the one hand, we are talking about
Google, a company that is known to cooperate with certain authorities, and on
the other hand, the cloud s [...]
-Unfortunately, to the best of our knowledge, there is no backup solution for
keys that works password-less while giving the user complete control over his
data.\\
+But how should one create and manage such a backup of a key? It
+certainly makes no sense to encrypt a key with a different password
+and then use the result as a backup. After all, this password can also
+be forgotten. Apart from that, the question arises how or where to
+save such a backup. A simple storage on e.g. Google Drive bears
+several risks: On the one hand, we are talking about Google, a company
+that is known to cooperate with certain authorities, and on the other
+hand, the cloud storage may be synchronized on several devices, to
+which someone else could possibly gain access. Unfortunately, to the
+best of our knowledge, there is no backup solution for keys that works
+password-less while giving the user complete control over his data.
-With Anastasis this gap shall be filled and a solution for secure recovery of
secret keys, which works without passwords or other key material, shall be
offered. This is achieved by splitting the key material across multiple
independent Anastasis service providers, and enabling users to recover their
master key by authenticating with each provider.\\
-Our protocol ensures that - without prior knowledge- the service providers
learn nothing from the protocol except the minimum amount of data required to
authenticate the user. Even that information is only disclosed at the time of
authentication.\\ \\
-This thesis describes the design and implementation of Anastasis.
+With Anastasis this gap shall be filled and a solution for secure
+recovery of secret keys, which works without passwords or other key
+material, shall be offered. This is achieved by splitting the key
+material across multiple independent Anastasis service providers, and
+enabling users to recover their master key by authenticating with each
+provider. Our protocol ensures that - without prior knowledge- the
+service providers learn nothing from the protocol except the minimum
+amount of data required to authenticate the user. Even that
+information is only disclosed at the time of authentication.
+
+This
+thesis describes the design and implementation of Anastasis.
\end{abstract}
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
index 34bdbc8..dbfb7e8 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -1,63 +1,63 @@
-\section{Introduction}
-Secure storage of private cryptographic keys or in general every kind of core
secret is a big problem. 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.\\
-
-\subsection{Principles}
-For Anastasis we have following design principles, in order of importance:
-\begin{enumerate}
- \item Anastasis must be Free Software.
- \item Anastasis must not rely on the trustworthiness of individual
providers. It must be possible to use Anastasis safely even if an individual
provider is compromised. Anastasis must minimize the amount of information
exposed to providers and the network.
- \item The user is in control.
- \item The system must be economical viable to operate. This implies
usability and efficiency of the system.
- \item Anastasis must support a diverse range of use cases.
-\end{enumerate}
-
-\subsection{Approaches}
-\subsubsection*{Secret sharing and recovery}
-Our approach to solve the problem of key management is to let the user split
their secret across multiple escrow providers (see
figure~\ref{fig:system_arch2}). To restore the secret again, the user has to
follow standard authentication procedures. After successful authentication the
user gets the secret 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}
-
-\subsubsection*{Derive user identifier}
-Every person has some hard to guess, semi-private and unforgettably inherent
attributes such as name and passport number, social security number or AHV
number (in Switzerland). We use those attributes to derive an user identifier
from (see figure~\ref{fig:user_id}).
-\begin{figure}[H]
-\centering
-\includegraphics[scale=0.3]{images/user_id.png}
-\caption{Derivation of user identifier}
-\label{fig:user_id}
-\end{figure}
-
-\subsection{Use cases}
-There are several applications which are in need of a key escrow system like
Anastasis. Some of them shall be introduced in this section.
-
-\subsubsection{Encrypted email communication}
-\subsubsection*{PGP}
+\section{Introduction}
+Secure storage of private cryptographic keys or in general every kind of core
secret is a big problem. 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.\\
+
+\subsection{Principles}
+For Anastasis we have following design principles, in order of importance:
+\begin{enumerate}
+ \item Anastasis must be Free Software.
+ \item Anastasis must not rely on the trustworthiness of individual
providers. It must be possible to use Anastasis safely even if an individual
provider is compromised. Anastasis must minimize the amount of information
exposed to providers and the network.
+ \item The user is in control.
+ \item The system must be economical viable to operate. This implies
usability and efficiency of the system.
+ \item Anastasis must support a diverse range of use cases.
+\end{enumerate}
+
+\subsection{Approaches}
+\subsubsection*{Secret sharing and recovery}
+Our approach to solve the problem of key management is to let the user split
their secret across multiple escrow providers (see
figure~\ref{fig:system_arch2}). To restore the secret again, the user has to
follow standard authentication procedures. After successful authentication the
user gets the secret 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}
+
+\subsubsection*{Derive user identifier}
+Every person has some hard to guess, semi-private and unforgettably inherent
attributes such as name and passport number, social security number or AHV
number (in Switzerland). We use those attributes to derive an user identifier
from (see figure~\ref{fig:user_id}).
+\begin{figure}[H]
+\centering
+\includegraphics[scale=0.3]{images/user_id.png}
+\caption{Derivation of user identifier}
+\label{fig:user_id}
+\end{figure}
+
+\subsection{Use cases}
+There are several applications which are in need of a key escrow system like
Anastasis. Some of them shall be introduced in this section.
+
+\subsubsection{Encrypted email communication}
+\subsubsection*{PGP}
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
necessary to be able to store the PGP private key securely.
-
-\subsubsection*{p\equiv p}
-Pretty Easy privacy (short p\equiv p) is "a cyber security solution which
protects the confidentiality and reliability of communications for citizens,
for public offices and for enterprises"~\cite{pepdoc}. It secures communication
via email by providing an end-to-end cryptography. For this the software uses a
private key. The impact of losing the private key is similar to those of PGP.\\
-
-\subsubsection{Digital currencies and payment solutions}
-\subsubsection*{Bitcoin}
-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}. The following
graphic illustrates the keys used in B [...]
-\begin{figure}[H]
- \centering
- \includegraphics[scale=3.5]{images/bitcoin-keys.png}
- \caption{Master key in Bitcoin Wallets~\cite{bitcoin-keys}}
- \label{fig:bitcoin_keys}
-\end{figure}
-
-\subsubsection*{Taler}
-Taler is a new electronic instant payment system for privacy-friendly online
transactions. Their digital wallets are storing electronic coins and are
protected with a private key which loss means losing all the money stored in
the wallet. Therefor the ECB (European Central Bank) informed Taler Systems SA
about the requirement for electronic wallets denominated in Euros to support
password-less data recovery. From this impulse the project Anastasis was
finally born.
-
-\subsubsection{Password manager}
-To avoid using low-entropy passwords and password reuse some people use
software password managers like KeePass\footnote{\url{https://keepass.info/}}.
Those password managers relieve you of the burden of remembering many passwords
and in most cases allow the generation of high-entropy passwords. The user only
has to remember the password for the password manager. And this exactly is the
problem: On the one hand, many users will tend to use an insecure, easy to
remember password even in t [...]
-Anastasis can store the passwords for password managers.
-
-\subsubsection{Hard drive encryption}
+
+\subsubsection*{p\equiv p}
+Pretty Easy privacy (short p\equiv p) is "a cyber security solution which
protects the confidentiality and reliability of communications for citizens,
for public offices and for enterprises"~\cite{pepdoc}. It secures communication
via email by providing an end-to-end cryptography. For this the software uses a
private key. The impact of losing the private key is similar to those of PGP.\\
+
+\subsubsection{Digital currencies and payment solutions}
+\subsubsection*{Bitcoin}
+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}. The following
graphic illustrates the keys used in B [...]
+\begin{figure}[H]
+ \centering
+ \includegraphics[scale=3.5]{images/bitcoin-keys.png}
+ \caption{Master key in Bitcoin Wallets~\cite{bitcoin-keys}}
+ \label{fig:bitcoin_keys}
+\end{figure}
+
+\subsubsection*{Taler}
+Taler is a new electronic instant payment system for privacy-friendly online
transactions. Their digital wallets are storing electronic coins and are
protected with a private key which loss means losing all the money stored in
the wallet. Therefor the ECB (European Central Bank) informed Taler Systems SA
about the requirement for electronic wallets denominated in Euros to support
password-less data recovery. From this impulse the project Anastasis was
finally born.
+
+\subsubsection{Password manager}
+To avoid using low-entropy passwords and password reuse some people use
software password managers like KeePass\footnote{\url{https://keepass.info/}}.
Those password managers relieve you of the burden of remembering many passwords
and in most cases allow the generation of high-entropy passwords. The user only
has to remember the password for the password manager. And this exactly is the
problem: On the one hand, many users will tend to use an insecure, easy to
remember password even in t [...]
+Anastasis can store the passwords for password managers.
+
+\subsubsection{Hard drive encryption}
Many companies need to backup high sensitive data to be able to recover them
in an emergency case. Those backups are often stored at external hard drives
which are encrypted using software like BitLocker~\cite{bitlocker}. For
encryption and decryption of the hardware additionally to the Trusted Platform
Module (TPM)~\cite{bajikar2002} of the computer or a key file often a password
is needed. In case of loosing a key file or a password, Anastasis can save from
data loss.
\ No newline at end of file
--
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: dos2unix,
gnunet <=