aboutsummaryrefslogtreecommitdiff
path: root/doc/system-documentation/server_architecture.tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/system-documentation/server_architecture.tex')
-rw-r--r--doc/system-documentation/server_architecture.tex134
1 files changed, 134 insertions, 0 deletions
diff --git a/doc/system-documentation/server_architecture.tex b/doc/system-documentation/server_architecture.tex
new file mode 100644
index 0000000..264f488
--- /dev/null
+++ b/doc/system-documentation/server_architecture.tex
@@ -0,0 +1,134 @@
1\subsection{Server architecture} \label{sec:serverarch}
2
3The Anastasis server architecture consists of two components. A web
4server with a REST API and a PostgreSQL database. The structure of
5these two components is shown in Figure~\ref{fig:anastasis:server}.
6
7\begin{figure}[H]
8 \centering
9 \includegraphics[scale=0.45]{images/server_api.png}
10 \caption{Anastasis server architecture}
11 \label{fig:anastasis:server}
12\end{figure}
13
14The webserver of Anastasis provides a RESTful API. For a detailed
15documentation of the REST API, see
16appendix ~\ref{appendix_server_api}.
17
18\newpage
19\subsubsection{Database}
20
21The database schema of Anastasis is shown in
22Figure~\ref{fig:anastasis_database}.
23\begin{figure}[H]
24 \centering
25 \includegraphics[scale=0.5]{images/anastasis-db.png}
26 \caption{Anastasis database schema}
27 \label{fig:anastasis_database}
28\end{figure}
29
30The database schema consists of four main tables:
31
32\begin{itemize}
33\item The {\em Truth} table is responsible for storing the key shares and
34 its authentication method. The key share and the authentication data are stored
35 encrypted in the database. The authentication data is only decrypted during
36 authentication. The key share is never decrypted for the
37 server. This protects the privacy of the customer. Likewise, the
38 user data is protected after a possible theft.
39\item The {\em User} table contains the identification of the user and an
40 expiration timestamp. This timestamp is a subscription period. This
41 timestamp is updated after each payment the user makes. Users for
42 whom the subscription has expired are periodically deleted.
43\item The {\em Payments} table contains the details of a payment from a
44 user. The payment is used either for the post-counter or the
45 subscription. The post-counter is decremented after each upload of a
46 recovery document. The user can only upload the recovery document if
47 the provided payment contains a post-counter which is at least 1.
48 Through this measure we can prevent people from maliciously filling
49 our database.
50\item The {\em Recoverydocument} table contains the recovery
51 information. The recovery document is stored encrypted in the
52 database. This offers better protection, as explained earlier for
53 the Truth table. Each recovery document record also contains a
54 version, a hash of the recovery document and a signature. The
55 version attribute allows the user to lookup a specific version of
56 the document. The hash is used to check if the user uploads a
57 duplicate of the document. The signature attests the
58 integrity of the recovery data.
59\end{itemize}
60
61
62\subsubsection{Authentication methods}
63
64This section describes an overview over the different possible
65authentication methods for Anastasis. In our implementation only the
66secure question is implemented. The other methods are just explained
67how they would be implemented.
68
69In all cases, the authentication process begins by the user decrypting
70their (encrypted) recovery document, which contains a list of Anastasis
71providers, associated authentication methods, truth\_seeds and associated
72truth encryption keys. The recovery process than varies slightly
73depending on the authentication method.
74
75\paragraph{SMS (sms)}
76
77The user tells the server with a request that they wants to authorize
78key recovery (via GET /truth/\$TRUTH\_PUB), providing a way to decrypt the
79truth with the phone number. The server will then generate a \$PIN and
80send it via an SMS provider to the stored number in the truth
81object. The client then must send another request with the sent \$PIN
82(via GET /truth/\$TRUTH\_PUB?response=\$PIN). The server can now check
83if the two PINs match. Upon success, the server returns the encrypted
84key share.
85
86\paragraph{Video identification (vid)}
87
88This method allows the user to identify via video-call. Since the
89respective images must be passed on to the video identification
90service in the event of password recovery, it must be ensured that no
91further information about the user can be derived from them. Hence,
92the user's client software must try to delete metadata that could
93result in accidental information leakage about the user from the image
94before encrypting and uploading it to the Anastasis provider.
95
96For recovery, the user must first send a request to server that they
97wants to authorize recovery (GET /truth/\$TRUTH\_PUB). The Anastasis
98provider will then decrypt the user's image and send a request with a
99\$TOKEN to a video authentication provider that a user wants to
100authenticate, and respond to the user with a link to a video
101conference. The video authentication provider then checks via video
102conference that the user in the image is the same that they have on
103the video link. Upon success, the video provider releases the \$TOKEN
104to the user. The client then must send another request with the
105\$TOKEN (via GET /truth/\$TRUTH\_PUB?response=\$TOKEN). The Anastasis
106provider checks that the tokens match, and upon success returns the
107encrypted key share.
108
109\paragraph{Post identification (post)}
110
111The user tells the Anastasis provider with a request that they want
112to authenticate using Post identification (GET /truth/\$TRUTH\_PUB). The
113Anastasis provider uses the request to decrypt the user's truth to
114determine the user's postal address, and sends them letter containing
115a \$PIN. Upon receiving the letter, the client then has to send
116another request with the \$PIN (GET /truth/\$TRUTH\_PUB?response=\$PIN). The
117server can now check if the two PINs match. Upon success the server
118will release the encrypted key share.
119
120\paragraph{Security question (qa)}
121
122The user provided Anastasis with a secure question and a (normalized)
123answer. The secure question becomes part of the encrypted recovery
124document, and is never disclosed to weak adversaries, even during
125recovery. The encrypted truth on the server only contains a (salted)
126hash of the answer. The Anastasis provider cannot learn the plaintext
127answer. Because of the salt, and it cannot mount a confirmation attack
128either.
129
130If the user wants to recover the key share from the server, they must
131provide the (salted) hash of the answer to the security question (via
132GET /truth/\$TRUTH\_PUB?response=\$HASH). The server then checks if the
133stored and the provided hash match. Upon success the server responds
134with the encrypted key share.