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
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
|
:css
.reveal h1 {
margin-bottom: 30px;
}
.reveal h3 li {
margin-bottom: 10px;
}
.reveal h1, .reveal h3, .reveal p, .reveal li, .reveal .p {
text-shadow: 0px 0px 10px rgba(0, 0, 0, 1)
}
.left-column {
display: block;
width: 50%;
float: left;
}
.right-column {
width: 50%;
float: left;
}
.row {
display: table;
width: 100%;
}
ul.plain {
list-style-type: none;
}
.reveal p, .reveal .p, ul.plain li {
margin-top: 15px;
margin-bottom: 15px;
}
.reveal li {
margin-top: 10px;
margin-bottom: 10px;
}
%section(data-background="images/kid-jumping.svg" data-background-size="50%")
%h1 LEAP Encryption Access Project
.p.row
.left-column Elijah Sparrow<br>elijah@leap.se<br>@ecsparrow
.right-column Sean Leonard<br>MeanderingCode@leap.se<br>@MeanderingCode
%section
%h1 What is the goal?
%h3 Communication that is
%h3
%ul
%li super easy
%li super secure
%p
For example: email, chat, voice, files, VPN.
%section
%h1 What is the strategy?
%h3 Federated service providers<br>using open protocols
%p (Not peer-to-peer, not centralized)
%section
%h1 What is the strategy?
.row
.left-column
%h3 Bitmask
%p Cross platform client application
.right-column
%h3 LEAP Platform
%p Service provider automation
%section(data-background="")
%p
%img{src: "images/bitmask-icon.png", style:"height: 200px; width 200px; float: left;"}
%h1 Bitmask
%p With Bitmask App, you choose among any<br>LEAP-powered service provider.
%p Currently, we support VPN and Email.
%section
%h1 Bitmask
%h3
%ul
%li Auto-configuring
%li Single click VPN
%li Email via a local IMAP and SMTP services.
%p
%img{src: "images/bitmask-main-window.jpg" }
%section
%h1 LEAP Platform
%p A few people with high skill but without unlimited time should be able to run a service provider.
%pre
%code.bash(data-trim)
:preserve
sudo gem install leap_cli
leap new example --domain example.org
cd example
leap add-user --self
leap node add blueberry services:openvpn ip_address:1.1.1.1
leap node add rasberry services:couchdb,webapp ip_address:2.2.2.2
leap node init
leap deploy
%section
%h1 LEAP Platform
%ul
%li Everything is just a JSON configuration.
%li Can use git to maintain your provider.
%li Heavily customizable: override node behavior with tags & environments. Easy to fork.
%li Includes a testing and monitoring framework.
%li Includes a webapp with user management, help tickets and billing.
%p
See
%a(href="https://leap.se/platform") leap.se/platform
%section
%h3 How to make something easy and secure?
%p Just create a better user interface!
%p Yes and no.
%section
%h1 A better UI
%p
%img(src="images/bitmask-android.png")
%section
%h1 A better UI
%p In many cases, it turns out that is not enough.
%p No point in polishing a turd.
%section
%h1 Hard problems
%h3 in making security easy.
%ol
%li Data availability problem
%li Secure identity validation problem
%li Meta-data problem
%li Asynchronous forward secrecy problem
%p and many others...
%section
%h1 Data availability
%ul
%li Securely back up data to the cloud
%li Available on all devices
%li Ensure it is also encrypted locally
%li Ensure access to data even when offline
%section
%h1 Data availability
%ul.plain
%li
%b Issue 1:
can't use normal hashed passwords.
%li
%b Solution:
use Secure Remote Password, two pass authentication scheme built on a zero knowledge proof such that the server never has access to the password.
%section
%h1 Data availability
%ul.plain
%li
%b Issue 2:
when stored locally, we need the data in a database.
%li
%b Solution:
stored local in sqlcipher (encrypted sqlite db)
%section
%h1 Data availability
%ul.plain
%li
%b Issue 3:
don't trust the provider
%li
%b Solution:
clients individually encrypt each document record before synchronizing with distributed cloud database.
%a(href="https://leap.se/soledad") leap.se/soledad
%section
%h1 Secure identity
%p Bedrock precondition for secure communication between two people.
%p All other security properties flow from it.
%section
%h1 Secure identity
%ul.plain
%li
%b Zooko's triangle:
identifiers may be globally unique, easy to remember, or decentralized: pick two.
%li
%b The binding problem:
how to strongly bind a human name to a long random cryptographic key.
%section
%h1 Secure identity
%p Existing models don't work: X.509 or WoT.
%p New ideas: TOFU, DANE, CT, Namecoin.
%section
%h1 Secure identity
%p What we are trying:
%ul.plain
%li
%b TOFU:
Trust On First Use.
%li
%b Provider endorsement:
providers sign & revoke user public keys.
%li
%b Network perspective:
audit providers to keep them honest.
%p
%p Goals: gradual adoption, backward compatible, ramp up.
%p
See
%a(href="https://leap.se/nicknym") leap.se/nicknym
%section
%h1 Meta-data problem
%p The problems:
%ul.plain
%li Headers in email are not end-to-end encrypted.
%li Network observers, and your service provider, knows who you are corresponding with.
%section
%h1 Meta-data problem
%p Our solutions:
%ul.plain
%li
%b Short term:
use StartTLS with enforced certificate validation via DANE.
%li
%b Long term:
direct delivery of email to recipient's provider using SMTP over Tor.
%section
%h1 Asynchronous forward secrecy
%p Why forward secrecy? Needed to future-proof your security.
%ul.plain
%li
%b Short term:
frequently rotating OpenPGP encryption sub-keys.
%li
%b Long term:
Axolotl? <a href="https://github.com/trevp/axolotl/wiki">github.com/trevp/axolotl/wiki</a>
%section
%h1 Links
%p
LEAP Encryption Access Project
%a(href="https://leap.se") https://leap.se
%p
Bitmask App
%a(href="https://bitmask.net") https://bitmask.net
%p
Demo
%a(href="https://demo.bitmask.net") https://demo.bitmask.net
%section
%h1 Appendix
%section
%h1 Why not p2p?
%ul
%li <b>The "natural" network:</b> many to many networks don't look like networks found in nature, which follow a power law ("scale free") distribution.
%li <b>The Internet:</b> internet infrastructure is actually very polycentric rather than decentralized (more akin to a tree than a spider's web).
%li <b>Traffic Analysis:</b> p2p message routing schemes are more vulnerable to traffic analysis.
%li <b>Sybil Attacks:</b> By their nature, peer-to-peer networks are highly vulnerable to Sybil attacks, where an attacker creates fake participants in order to reveal secrets or hijack network.
%section
%h1 Why not p2p?
%ul
%li <b>Mobile:</b> Peer-to-peer networks are resource intensive, typically with every node in the network responsible for continually relaying traffic and keeping the network healthy.
%li <b>Identifiers:</b> There are no good schemes for secure p2p identity. Everyone uses fingerprints, but this makes user identifiers impossible to remember.
%li <b>Data Availability:</b> p2p has very poor data availability.
|
