introduction.tex (9869B)
1 \section{Introduction} 2 3 Keys are used to encrypt high sensitive personal data and therefore 4 they must be kept safely. Secure storage of private keys is known to 5 be a difficult problem --- especially for end-users with limited 6 skills in system administration and insufficiently redundant hardware. 7 A central objective for any solution is that only the legitimated 8 owner of a key must have the possibility to recover a lost key. 9 10 But how can one create a confidential backup of a key? It certainly 11 makes no sense to encrypt a key with a different password and then use 12 the result as a backup. After all, this merely shifts the problem from 13 the original key to the password, which is basically yet another key. 14 So simply encrypting the key is not helpful. But without encryption, 15 any copy of a key increases availability, but also the risk of the 16 key's confidentiality being compromised. 17 18 Most people have difficulties memorizing a high-entropy 19 passphrase. Hence, existing key management ``solutions'' often reduce 20 the problem of memorizing one or more high-entropy passphrases or keys 21 to memorizing a single low-entropy passphrase. This is not a good 22 solution, as the low-entropy passphrase undermines security. 23 24 In this thesis, we describe a software solution for the described 25 problem using secret splitting. We call our solution ``Anastasis'', 26 which is a medical term for the prognosis of full recovery. We will 27 call the information that Anastasis allows the user to recover their 28 {\em core secret}. 29 30 \subsection{Principles} 31 32 For Anastasis we have following design objectives, in order of importance: 33 34 \begin{enumerate} 35 \item Anastasis must be Free Software\footnote{\url{https://www.fsf.org/}}. Everyone must have the right to 36 run the program, study the source code, make modifications and share 37 their modifications with others. 38 \item Anastasis must not rely on the trustworthiness of individual providers. 39 It must be possible to use Anastasis safely, even if a subset of the 40 providers is malicious. Anastasis must minimize the amount of information 41 exposed to providers and the network. 42 \item Anastasis must put the user in control: They get to decide which 43 providers to use, and which combinations of authentication steps will 44 be required to restore their core secret. The core secret always remains exclusively 45 under the user's control, even during recovery. 46 \item Anastasis must be economical viable to operate. This implies usability 47 and efficiency of the system. 48 \item Anastasis must support a diverse range of use cases. 49 \end{enumerate} 50 51 52 \subsection{Approach} 53 54 \subsubsection*{Secret sharing and recovery} 55 56 Our approach to solve the problem of key recovery is to let the user 57 split their core secret across multiple escrow providers (see 58 Figure~\ref{fig:system_arch2}). To recover their core secret, the user has to 59 authorize key the recovery, usually by passing an authentication check 60 which they configured for the respective provider. 61 62 After successful authentication the user receives the secret shares 63 and is able to reassemble their core secret locally on their computer. 64 65 \begin{figure}[H] 66 \centering 67 \includegraphics[scale=0.33]{images/system-architecture_2.png} 68 \caption{System architecture} 69 \label{fig:system_arch2} 70 \end{figure} 71 72 \subsubsection*{Derive user identifier} 73 74 Every person has some hard to guess, semi-private and unforgettable 75 inherent attributes such as name and passport number, social security 76 number or AHV~\cite{jerome2015} number (in Switzerland). We use those attributes to 77 improve the security and privacy provided by Anastasis. Basically, 78 these attributes serve as weak key material, raising the bar for 79 attackers without the availability disadvantages of passphrases --- 80 which users may forget. Anastasis derives a ``user identifier'' from 81 such a set of unforgettable attributes (see Figure~\ref{fig:user_id}). 82 83 \begin{figure}[H] 84 \centering 85 \includegraphics[scale=0.3]{images/user_id.png} 86 \caption{Derivation of a user identifier} 87 \label{fig:user_id} 88 \end{figure} 89 90 \subsubsection*{Encrypt and encrypt and encrypt} 91 92 Anastasis uses several layers of encryption. First, the user's core 93 secret is encrypted with a master key. The master key is encrypted 94 with various policy keys. The policy keys are derived from various 95 secrets which are encrypted and distributed across various providers 96 together with information about the desired recovery authorization 97 procedure. This last encryption is done based on keys derived from the 98 user identity. These many layers of encryption are designed to 99 distribute trust and to minimize or delay information disclosure. 100 101 \subsubsection*{Private payments are integrated} 102 103 The Anastasis protocol includes provisions for privacy-preserving 104 electronic payments to the service providers, as well as resource 105 limitations to protect service providers against resource exhaustion 106 attacks. This ensures that it should be possible to operate the 107 service commercially. 108 109 110 \subsection{Use cases} 111 112 There are several applications which are in need of a key escrow 113 system like Anastasis. Some of them shall be introduced in this 114 section. 115 116 \subsubsection{Encrypted email communication} 117 118 For email encryption using Pretty Good Privacy 119 (PGP)~\cite{garfinkel1995} users need a private key which is typically 120 stored on the device running PGP. PGP uses a ``Web of trust'' to 121 establish the authenticity of keys. 122 123 Pretty Easy privacy (short p\equiv p) is ``a cyber security solution 124 which protects the confidentiality and reliability of communications 125 for citizens, for public offices and for 126 enterprises''~\cite{pepdoc}. It secures communication via email by 127 providing end-to-end encryption similar to PGP. A major difference is 128 that p\equiv p uses opportunistic encryption and so-called trustwords 129 to establish authenticity to avoid usability and privacy problems 130 associated with the ``Web of trust''~\cite{caronni2000}. 131 132 The impact of losing control over the private key is similar in both 133 systems: 134 135 \begin{itemize} 136 \item If the private key becomes unavailable, all emails which were 137 encrypted to that key become unreadable. Furthermore, the user would 138 likely need to rebuild their ``Web of trust''. 139 \item If the private key is 140 disclosed to an adversary, they might be able to decrypt that user's 141 encrypted emails -- which may go back years and could include highly 142 sensitive information. An adversary could also use the private key 143 to send cryptographically signed emails pretending to be the user. 144 \end{itemize} 145 146 147 \subsubsection{Digital currencies and payment solutions} 148 149 Another application relying on a core secret are cryptocurrencies like 150 Bitcoin. Each user of Bitcoin needs an electronic wallet which stores 151 and protects the private keys of the user. Those private keys 152 legitimate its owners to spend the bitcoins corresponding to the 153 keys.~\cite{LLLW*2017} 154 155 Losing Bitcoin wallet keys means losing all of the corresponding 156 Bitcoins. The reader may be familiar with stories from the mass media 157 about people who claim to have lost their key to their electronic 158 wallet and therefore huge sums of 159 cryptocurrency~\cite{millions_lost}. Backup systems are essential to 160 avoid such cases. 161 162 The following graphic illustrates the keys used in Bitcoin 163 wallets. In this case, the core secret Anastasis would store 164 is the ``master key'' $m$: 165 166 \begin{figure}[H] 167 \centering 168 \includegraphics[scale=3.5]{images/bitcoin-keys.png} 169 \caption[Master key in Bitcoin wallets]{Master key in Bitcoin wallets (from~\cite{bitcoin-keys})} 170 \label{fig:bitcoin_keys} 171 \end{figure} 172 173 GNU Taler\footnote{\url{https://taler.net/de/}} is a new electronic instant payment system for 174 privacy-friendly online transactions. The GNU Taler digital wallets are 175 storing electronic coins, and backups are protected with a key. 176 Losing the backup key means losing all the money stored in the wallet, 177 as well as the transaction history kept in the wallet. 178 179 The European Central Bank (ECB) informally informed Taler Systems SA 180 about the requirement for electronic wallets denominated in Euros to 181 support password-less data recovery to ensure users would not loose 182 their electronic funds if their device were to be damaged or lost. 183 184 This was the key impulse which motivated us to create Anastasis, 185 with the goal of enabling recovery of GNU Taler's backup keys via 186 Anastasis. 187 188 189 \subsubsection{Password managers} 190 191 To avoid using low-entropy passwords and password reuse, some people 192 use software password managers like 193 KeePass\footnote{\url{https://keepass.info/}}. Such password managers 194 relieve you of the burden of remembering many passwords and in most 195 cases allow the generation of high-entropy passwords. 196 197 The user only has to remember the password for the password 198 manager. However, as discussed before, this is still a major problem: 199 \begin{itemize} 200 \item On the one hand, users could use an insecure, easy to 201 remember password. In this case, an adversary gaining control 202 over the password manager's database could break into all systems 203 secured by keys managed by the password manager. 204 \item On the other hand, users could use a complex, high-entropy 205 passphrase. However, if that passphrase is forgotten, users 206 face the loss of all passwords and thus also all online 207 services that the password manager controlled for them. 208 \end{itemize} 209 210 Anastasis can be used to enable recovery of strong passphrases, 211 such as those that should be used to secure password managers. 212 213 214 \subsubsection{Hard drive encryption} 215 216 Data at rest is often protected using (full) drive encryption, for 217 example using software like 218 LUKS\footnote{\url{https://guardianproject.info/archive/luks/}}. For 219 encryption and decryption of the drive a combination of key files, 220 passphrases and Trusted Platform Modules (TPMs)~\cite{bajikar2002} are 221 used. 222 223 Anastasis can be used to backup and restore such key files or 224 passphrases.