summaryrefslogtreecommitdiffhomepage
path: root/doc/servers.mdwn
blob: d190603c7d9d472ef2335af58ff6636544497d6d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
There are currently not enough keysafe servers. We need at least 3 for
keysafe to work. Please contact <id@joeyh.name> if you would like to run a
keysafe server.

## Server categories

Keysafe's server list puts servers in three categories:

1. **Recommended**: Servers that meet all best practices for security and
   are run by a well-known, trusted entity.

   Keysafe prefers to store data only on Recommended servers when possible.

2. **Alternate**: Servers that are not secured well enough to be
   Recommended.

   Keysafe will store data on Alternate servers if it has to, but will
   avoid storing enough data to allow the key to be recovered using only
   the data stored on Alternate servers.

   For example, with 2 of 3 shares needed to restore a key, keysafe can
   store 1 share on an Alternate server, and the other 2 shares on two
   Recommended servers.

3. **Untrusted**: Servers that are not secured well or are run by an untrusted
   entity.
   
   Keysafe will never store data on Untrusted servers. 
   
   If a server becomes untrusted and keysafe stored data on it in the past,
   keysafe will warn the user about this problem.
   
   The only time keysafe will use untrusted servers is if it's restoring a
   key, and cannot find enough shares on Recommended/Alternate
   servers, and has to fall back to downloading from an Untrusted server.

## Server list

### Recommended

#### hlmjmeth356s5ekm.onion

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA1
	
	The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
	Purism. It is located in the EU (Cyprus).
	
	We intend to run this server for at least 10 years (through 2027),
	or failing that, to transition any data stored on it to another
	server that is of similar or higher security.
	
	Our warrant canary is <https://puri.sm/warrant-canary/>,
	and is updated quarterly.
	-----BEGIN PGP SIGNATURE-----
	Version: GnuPG v1
	
	iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B
	TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj
	eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR
	3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv
	E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU
	niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv
	+GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW
	wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ
	/Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY
	4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG
	CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/
	Br5jFZujcQ0u7GzqvaDB
	=RmK4
	-----END PGP SIGNATURE-----

### Alternate

#### keysafe.joeyh.name

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256
	
	  keysafe.joeyh.name is provided by me, Joey Hess.
	
	  I intend to run this server for at least 10 years (through 2027),
	  or failing that, to transition any data stored on it to another
	  server that is of similar or higher security.
	
	  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
	  hosting provider is accessing the contents of the server, and so
	  this server is not securely hosted enough to be Recommended.
	-----BEGIN PGP SIGNATURE-----
	
	iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ
	3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v
	iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I
	x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9
	BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD
	3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt
	BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6
	da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/
	he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf
	GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m
	7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK
	lhmhvShr0WRqB8fWYPkc
	=SNGN
	-----END PGP SIGNATURE-----
</pre>

#### thirdserver

  Provided by Marek Isalski at [Faelix](http://www.faelix.net/).
  Currently located in UK, but planned move to CH.  
  Vetting to Recommended level in progress.

## Detailed requirements

### Alternate

* Keysafe port only exposed via tor hidden service.
* Dedicated to only running keysafe, no other services. (Other than tor and 
  ssh for admin)
* The set of people who administer the server, and procedures for giving
  others access is well-defined.
* Noone who has access to the server also has access to any Recommended
  server.
* Commitment to either keep the server running long-term (ie, 10+ years),
  or transition the data to a replacement server that meets these
  requirements and that must not contain any related shards.
* No other open ports (other than ssh).
* Ssh authentication only by ssh key, not password.
* Either off-server backup, or replication of shards to additional disks.
  (rsync to additional local disks would work perfectly well and avoids
  the complications of RAID)
* Any off-server backup is strongly encrypted.
  (There's a trade-off here; any backup widens the attack surface.
  It may be better to run some servers without backups and adjust the
  number of shards needed to recover keys; a server losing its data
  need not be catastrophic.)
* Any backup should take care to not leak information about what objects
  were present on the server at multiple times in the past. That would 
  let an attacker who can access the backups make guesses about shares
  belong with other shares stored on other servers in the same time period.
  See [[details]] for how that makes it somewhat easier for an attacker.

  keysafe --backup-server can be used to generate encrypted files to back up,
  in a way that is designed to avoid these problems.

* Similarly, the filesystem and storage system should not allow rolling back
  to old snapshots.

### Recommended

* Everything in Alternate, to start with.
* Run by a well known and trustworthy entity.
* Noone who has access to the server also has access to any other
  Recommended or Alternate server.
* Warrant canary.
* Hardware is hosted in-house. A VM at a cloud provider is right out
  because the provider could be made to give access to it without the
  server operator knowing about it. Which would bypass the warrant canary.
* The keysafe data store and any swap partitions are encrypted,
  and have to be manually unlocked when the server is booted.

## Server scaling

Each key takes a minimum of 64 KiB to store, perhaps more for gpg keys
with lots of signatures. So 10 GiB of disk is sufficient for 160 thousand
users, which is enough for a small keysafe server.

The keysafe server uses very little memory and CPU. It does rate limiting
with client-side proof-of-work to prevent it being abused for
general-purpose data storage.

There is some disk IO overhead, because keysafe updates the mtime and ctime
of all shards stored on the server, as frequently as every 30 minutes.
Once a large number of shards are stored, this could become a significant
source of disk IO.

## Server setup

It's early days still, but keysafe's server code works well enough.

* `git clone git://keysafe.branchable.com/ keysafe` or
  `git clone https://git.joeyh.name/git/keysafe.git/`
* Be sure to verify the gpg signature of the git repository!
* You will need to install keysafe from source; see its INSTALL file.
  Use `make install` to install it, including a systemd service file.
* `systemctl enable keysafe.service`
* Install tor and set up a tor hidden service. Keysafe listens on port 4242
  by default, so use that port.
* Configure the server to meet all the requirements for Alternate or
  Required.
* Once ready, email id@joeyh.name to get added to keysafe's server list.

Here's a the [[code/propellor]] config for my own keysafe server:
<http://source.propellor.branchable.com/?p=source.git;a=blob;f=joeyconfig.hs;h=15a00f7c2dffa15ed275fdd44e84e2edcc226559;hb=b9f87f0c08d94c5d43224a2c6bbacb332ebfc1b6#l460>
--[[Joey]]