Bitmask: encryption for mere mortals

# BitmasK: encryption for mere mortals ### IFF - March 2017

## Problem: provider access to data and keys

## Problem: encrypted email is ...complicated

## show me the code! https://0xacab.org/leap/ * ~10 important repos * GPL code

# How does this work?

1. email flow 2. ability to use multiple devices 3. key management 4. platform

## 1. Email Flow

## [picture of architecture]

## 2. ability to use multiple devices

# 🔑 🔄 ### Synchronization Of ### Locally Encrypted Data Among Devices

# data = 🖂 + 🔑

## 3. Key Management

## traditional openpgp management ## is hard for most users

## no single standard

## bitmask keymanager ## requires no user interaction

## interoperability is a must ### many projects converging #### (Watch AUTOCRYPT: Enigmail, K9, Mailpile, Pixelated, Bitmask)

## 4. LEAP Platform

## providers # ❤ ## the LEAP Platform

## sysadmins are human ### and deserve usability too

## "leap deploy"


sudo gem install leap_cli
leap new example --domain example.org
cd example
leap add-user --self
leap cert ca
leap cert csr
leap node add myshinynewnode services:couchdb,webapp,soledad,mx ip_address:1.1.1.3
leap init node
leap deploy

let a thousand providers bloom

🐧 thanks! questions?

## 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 (+ distribuded fs?!)

## Problem: Attachments * Syncing blobs in a convoluted store * Pluggable BlobsIO backend for server (in dev) * FS as MVP, others welcome! * Follow the "git-annex" model

## 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)

## keymanager current rules # TOFU (yes, but*) ### 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.

# Validation levels low == less trust on the source

## 1. Weak Chain _{ej: sks key servers, email attached key, OpenPGP header, ...}

## 2. Provider Trust _{ej: webfinger, provider mailvelope} Note: * Certified by the provider * Not auditable

## 3. Provider Endorsement _{ej: NickNym} Note: * auditable

## 4. Historical Auditing _{ej: CONIKS, google's transparent keyserver}

## 5. Known Key _{client pinned keys}

## 6. Fingerprint _{manual verification}

## LEAP platform ### A toolkit to make it easy for you to run a federated service provider.

* Configuration Management using puppet * Installs and configures the servers * leap_cli is the tool to deploy to the servers * Provider confiduration is stored on admin laptop

LEAP Platform Example: Setup single node email provider


sudo gem install leap_cli
leap new example --domain example.org
cd example
leap add-user --self
leap cert ca
leap cert csr
leap node add raspberry \
  services:couchdb,webapp,soledad,mx ip_address:1.1.1.3
leap init node
leap deploy

## LEAP Platform: Install and configure the server/s * Email: Postfix, spamassassin, clamav * Database: couchdb, stunnel * Webserver: apache * Encrypting remailer: leap-mx * Synchronisation: soledad * Account management, issue tracking: leap-webapp * Firewall: shorewall * Monitoring: nagios, check_mk

## Server-side techstack * PLatform: Puppet * leap_cli: ruby * leap_web: Ruby on Rails * leap_mx, soledad: Python Twisted

## Other LEAP components * SOLEDAD * Bonafide (registration, auth, pass change...) * Current Services: VPN, Encrypted Email

## LEAP Webapp * API for user authentication * Help Tickets * User Management * Payment processing * Customisable

## the client: Bitmask * basically an encryption proxy * protocol specific for mail * linux (deb, bundles), [windows, osx] * android client

## threat model * Active or passive adversary * Avoid the recovering of Communications Plaintext * Avoid the recovering of the Social Graph (*)

## trust model * do *not* trust the provider too much * passwords never reach the server in cleartext (srp + encrypted keys) * TOFU for key and certificate discovery * encrypted data * minimize metadata!

### backwards compatible * vpn * OpenPGP * imap, smtp (clientside proxies)

## VPN * prevent eavesdropping. * circunvent internet censorship. * firewall: prevent leaks (DNS, IPv6, ...). * static portable builds, mbed SSL * targeting home routers too (openwrt port) * autoconf, reconnect, fail close * obsproxy integration

## Problem: Attachments * Syncing blobs in a convoluted store * Pluggable BlobsIO backend for server (in dev) * FS as MVP, others welcome! * Follow the "git-annex" model

## keymanager current rules # TOFU (yes, but*) ### 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.

# Validation levels low == less trust on the source

## 1. Weak Chain _{ej: sks key servers, email attached key, OpenPGP header, ...}

## 2. Provider Trust _{ej: webfinger, provider mailvelope} Note: * Certified by the provider * Not auditable

## 3. Provider Endorsement _{ej: NickNym} Note: * auditable

## 4. Historical Auditing _{ej: CONIKS, google's transparent keyserver}

## 5. Known Key _{client pinned keys}

## 6. Fingerprint _{manual verification}

## users wants a webmail?

## give them a webmail ## (kudos to pixelated!)

let a thousand providers bloom

🐧 thanks! questions?

https://bitmask.net

https://leap.se

2. Regular Refresh

3. Key Replacement

LEAP Platform Example: Setup single node email provider

2. Regular Refresh

3. Key Replacement