From f6eec69d0cae3b2e540a3a85c7105c134d6734b4 Mon Sep 17 00:00:00 2001 From: kwadronaut Date: Fri, 9 Feb 2018 11:17:27 +0100 Subject: add 2018 fosdem presentation --- 2018fosdem/index.html | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 449 insertions(+) create mode 100644 2018fosdem/index.html (limited to '2018fosdem/index.html') diff --git a/2018fosdem/index.html b/2018fosdem/index.html new file mode 100644 index 0000000..aff19cc --- /dev/null +++ b/2018fosdem/index.html @@ -0,0 +1,449 @@ + + + + + + + + Bitmask: encryption for mere mortals + + + + + + + + + + + # + # + + + + + + + + + + + + +
+ +
+
+
+ # BitmasK: encryption for mere mortals + ### FOSDEM 2018 + ### kali - meskio - kwadronaut +

https://leap.se

+
+
+
+
+ ## Problem: encrypted email is ...complicated +
+ +
+ +
+
+ +
+ +
+ +
+ +
+
+
+ # Problem: providers +
+ +
+ +
+ +
+

Peer to peer?


+ + + +
+ + +
+ +
+

Better federation!

+

+
    +
  • Protect providers from their users
    • +
  • Protect users from the provider
    • +
+

+ +
+ +
+

What does
LEAP do?

+
    +
  • + LEAP Platform:
    toolkit to make it easier to run a service provider
    • +
  • + New protocols:
    so no need to trust your connection provider
    • +
  • + Bitmask client:
    smooth working client with compatible providers
    • +
+
+ +
+
+ # leap mail service + * End-to-end encryption + * Backwards compatible with email and current OpenPGP usage + * Service provider has no access to user data + * Automatic key discovery and validation + * Cloud synchronized for high availability on multiple devices +
+
+ + +
+
+

email service

+ + + +
+ +
+

soledad

+ +
+ +
+

mx

+ +
+ +
+ +
+ +
+
+
+

transitional key validation

+ + generic rules for automatic key management,
transition from TOFU to more advanced ruleset.
+
    +
  • bind key <-> email address
    • +
  • key directory
    • +
  • endorser (provider)
    • +
  • binding info: evidence for "educated guess"
    • +
  • verified key transition (automatic)
    • +
+ + [leap.se/en/docs/design/transitional-key-validation] +
+ +
+

TOFU

+ With a bunch of exceptions + +
+ +
+ ## 1. First Contact + + When one or more keys are first discovered for a particular email address, the key with the highest validation level is registered. +
+ +
+

2. Regular Refresh

+ +

All keys are regularly refreshed to check for modified expirations, or new subkeys, or new keys signed by old keys.

+

This refresh SHOULD happen via some anonymizing mechanism.

+
+ +
+

3. Key Replacement

+ +

A registered key MUST be replaced by a new key in one of the following situations, and ONLY these situations:

+
    +
  • Verified key transitions.
    • +
  • If the user manually verifies the fingerprint of the new key.
    • +
  • If the registered key is expired or revoked and the new key is of equal or higher validation level.
    • +
  • If the registered key has never been successfully used and the new key has a higher validation level.
    • +
  • If the registered key has no expiration date.
    • +
+ + +
+
+
+ ## VPN + + * Prevent eavesdropping. + * Circunvent internet censorship. + * Prevent leaks (DNS, IPv6, ...). +
+ +
+

LEAP platform

+ 

+sudo gem install leap_cli
+leap new example --domain example.org
+cd example
+leap add-user --self
+leap cert ca
+leap cert dh
+leap cert csr
+leap node add blueberry services:openvpn \
+     ip_address:1.1.1.1 openvpn.gateway_address:1.1.1.2
+leap node add raspberry services:couchdb,webapp \
+     ip_address:1.1.1.3
+leap init node
+leap deploy
+
+ +
+
+
+ ## sysadmins are human + ### and deserve usability too + +
+
+ ## "leap deploy" +
+
+ +
+
+
+ +
+ +
+ +
+ ## show me the code! + https://0xacab.org/leap/ + * ~10 important repos + * GPL code +
+
+
+
+ # current state +
+ +
+ ## Email Beta (0.10…) + ### works on Linux + ## Bitmask VPN + ### works on Linux && Android + +
+ +
+ ## next steps + * OSX and windows +
+
+ +
+ +

let a thousand providers bloom

+
+ +
+

🐧 thanks! questions?

+ QR with info contact for leap +

https://bitmask.net

+

https://leap.se

+

katzenpost.mixnetworks.org 😼

+
+ +
+
+ +
+
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+
+ +
+
+ ## 2. ability to use multiple devices +
+ +
+ # 🔑 🔄 + ### Synchronization Of + ### Locally Encrypted Data Among Devices +
+ +
+ # data = 🖂 + 🔑 +
+
+ +
+
+ ## bitmask keymanager + ## requires no user interaction +
+ +
+ ## interoperability is a must + ### many projects converging + #### (Watch AUTOCRYPT: Enigmail, K9, Mailpile, Bitmask) +
+
+ + +
+
+ ## SOLEDAD + * Synchronization of Locally Encrypted Data Among Devices + * auth: srp + * kdf: scrypt + * AES-256-GCM + * built on top of canonical's u1db + * vector clocks + * clientside: sqlcipher backend + * serverside: couchdb cluster +
+ +
+ ## Problem: Attachments + * Syncing blobs in a convoluted store + * Pluggable BlobsIO backend for server (in dev) + * FS as MVP, others welcome! +
+ +
+ +
+
+ # Validation levels + + low == less trust on the source +
+ +
+ ## 1. Weak Chain + sks key servers, email attached key, OpenPGP header, ... +
+ +
+ ## 2. Provider Trust + webfinger, provider mailvelope + + Note: + * Certified by the provider + * Not auditable +
+ +
+ ## 3. Provider Endorsement + NickNym + + Note: + * auditable +
+ +
+ ## 4. Historical Auditing + CONIKS, google's transparent keyserver +
+ +
+ ## 5. Known Key + client pinned keys +
+ +
+ ## 6. Fingerprint + manual verification +
+
+ + + +
+ + + + + + + -- cgit v1.2.3