Leap Encryption Access Project

LEAP Encryption Access Project

Encryption should be
simple to provide and easy to use

Tools for secure network communications
Decentralization of service providers

Crypto is Hard

But wait, you said...

Encryption should be
simple to provide and easy to use

So...

Solve the Hard Problems

The “Big 7”

Authenticity problem
Meta-data problem
Asynchronous problem
Group problem
Resource problem
Availability problem
Update problem

Authenticity problem

Public key validation is very difficult for users to manage, but without it you cannot have confidentiality

Nicknym - auto discovery and validation of public keys, transparently!

Meta-data problem

Existing protocols are vulnerable to meta-data analysis, even though meta-data is often much more sensitive than content

Downgrade-proof DNSSEC/DANE

With one or more opportunistic schemes:

Auto alias pairs
Onion routing headers
Third party dropbox
Mixmaster with signatures

- DNSSEC: Short term. Opportunistic TLS for email and chat among servers/providers Effective external observers, no protection of user from provider By itself, potential weaknesses to advanced attacks ( timing, traffic analysis ) In the long term, we plan to adopt one of several different schemes for securely routing meta-data. These include: - Auto alias pairs auto negotiate aliases Advantage: backwards compatible Disadvantage: server stores list of aliases - Onion-routing-headers A message from user A to user B is encoded so that the “to” routing information only contains the name of B’s server. When B’s server receives the message, it unwraps (unencrypts) a supplementary header that contains the actual user “B”. Like aliases, this provides no benefit if both users are on the same server. As an improvement, the message could be routed through intermediary servers. - Third party dropbox To exchange messages, user A and user B negotiate a unique “dropbox” URL for depositing messages, potentially using a third party. To send a message, user A would post the message to the “dropbox”. To receive a message, user B would regularly polls this URL to see if there are new messages. - Mixmaster with signatures Messages are bounced through a mixmaster-like set of anonymization relays and then finally delivered to the recipient’s server. The user’s client only displays the message if it is encrypted, has a valid signature, and the user has previously added the sender to a ‘allow list’ (perhaps automatically generated from the list of validated public keys). For a great discussion comparing mix networks and onion routing, see Tom Ritter’s blog post on the topic.

Asynchronous problem

For encrypted communication, you must currently choose between forward secrecy or the ability to communicate asynchronously

OpenPGP vs. OTR
Stop-gap: Layer forward secret transport atop OpenPGP
Long term: Collaborate with others to create new encryption protocol standards

With the pace of growth in digital storage and decryption, forward secrecy is increasingly important. Otherwise, any encrypted communication you engage in today is likely to become cleartext communication in the near future. In the example of email and chat, we have OpenPGP with email and OTR with chat: the former provides asynchronous capabilities, and the latter forward secrecy, but neither one supports both abilities. We need both better security for email and the ability to send/receive offline chat messages. In the short term, we are layering forward secret transport for email and chat relay on top of traditional object encryption (OpenPGP). This approach is identical to our stop-gap approach for the meta-data problem, with the one addition that relaying servers need the ability to not simply negotiate TLS transport, but to also negotiate forward secret ciphers and to prevent a cipher downgrade. This approach is potentially effective against external network observers, but does not achieve forward secrecy from the service providers themselves. In the long term, we plan to work with other groups to create new encryption protocol standards that can be both asynchronous and forward secret. : Forward Secrecy Extensions for OpenPGP Triple elliptical curve Diffie-Hellman handshake

Group problem

In practice, people work in groups, but public key cryptography doesn’t

First we...ummm
Interesting work in secure file backup/sync/sharing (e.g. Wuala and SpiderOak)
Proxy re-encryption
Ring signatures

We have a lot of ideas, but we don’t have any solutions yet to fix this. Essentially, the question is how to use existing public key primitives to create strong cryptographic groups, where membership and permissions are based on keys and not arbitrary server-maintained access control lists. Most of the interesting work in this area has been done by companies working on secure file backup/sync/sharing, such as Wuala and Spideroak. Unfortunately, there are not yet any good open protocols or free software packages that can handle group cryptography. ### There is some free software work on some of interesting building blocks that could be useful in building group cryptography. For example: ### - Proxy re-encryption: See Wikipedia This allows the server to re-encrypt to new recipients without gaining access to the cleartext. The SELS mailing list manager (Secure Email List Services) uses OpenPGP to implement a clever scheme for proxy re-encryption. - Ring signatures: See Wikipedia This allows any member of a group to sign, without anyone knowing which member.

Resource problem

There are no open protocols to allow users to securely share a resource

Yup, still got nothin' :/
"Read-write-web", meet ["Group problem" solution here]
Again, possibilities from file sync (Lazy Revocation and Key Regression)

Availability problem

People want to smoothly switch devices, and restore their data if they lose a device, but this very difficult to do securely

Soledad - Synchronization of Locally Encrypted Documents Among Devices
phew! we weren't out of ideas!

Update problem

Almost universally, software updates are done in ways that invite attacks and device compromises

TUF (thanks, Thandy/Tor!)

The sad state of update security is especially troublesome because update attacks can now be purchased off the shelf by repressive regimes. The problem of software update is particular bad on desktop platforms. In the case of mobile and HTML5 apps, the vulnerabilities are not as dire, but the issues are also harder to fix. To address the update problem, LEAP is adopting a unique update system called Thandy from the Tor project. Thandy is complex to manage, but is very effective at preventing known update attacks. Thandy, and the related TUF, are designed to address the many security vulnerabilities in existing software update systems. In one example, other update systems suffer from an inability of the client to confirm that they have the most up-to-date copy, thus opening a huge vulnerability where the attacker simply waits for a security upgrade, prevents the upgrade, and launches an attack exploiting the vulnerability that should have just been fixed. Thandy/TUF provides a unique mechanism for distributing and verifying updates so that no client device will install the wrong update or miss an update without knowing it. Related to the update problem is the backdoor problem: how do you know that an update does not have a backdoor added by the software developers themselves? Probably the best approach is that taken by Gitian, which provides a “deterministic build process to allow multiple builders to create identical binaries”. We hope to adopt Gitian in the future.

So, what have you got?

Services

Encrypted Internet Proxy aka VPN

Chat (in progress)

Services in Planning

Client-Encrypted Filehosting

Voip

Collaborative Text Editor

For Users

Bitmask-Client for Mac OS, Linux, Android (Windows coming)

For Providers

Automate Installation and Configuration of the services
Secure Crypto presets (TLS parameters, etc)

leap-platform

Puppet recipes for configuring the server


# smtp TLS                                                                    
postfix::config {                                                             
  'smtp_use_tls':        value  => 'yes';                                     
  'smtp_tls_CApath':     value  => '/etc/ssl/certs/';                         
  'smtp_tls_CAfile':     value  => $ca_path;                                  
  'smtp_tls_cert_file':  value  => $cert_path;                                
  'smtp_tls_key_file':   value  => $key_path;                                 
  'smtp_tls_ask_ccert':  value  => 'yes';                                     
  'smtp_tls_loglevel':   value  => '1';                                       
  'smtp_tls_exclude_ciphers':                                                 
    value => 'aNULL, MD5, DES';                                               
  # upstream default is md5 (since 2.5 and older used it), we force sha1      
  'smtp_tls_fingerprint_digest':                                              
    value => 'sha1';                                                          
  'smtp_tls_session_cache_database':                                          
    value => 'btree:${queue_directory}/smtp_cache';                           
  'smtp_tls_security_level':                                                  
    value  => 'may';                                                          
  # see issue #4011                                                           
  'smtp_tls_protocols':                                                       
    value => '!SSLv2, !SSLv3';                                                
}

Provider Config

Server Layout, IPs, contact details, etc


$ cat provider.json 
//
// General service provider configuration.
//
{
  "domain": "example.org",
  "name": {
    "en": "example"
  },
  "description": {
    "en": "You really should change this text"
  },
  "contacts": {
    "default": "admin@example.org"
  },
  "languages": ["en"],
  "default_language": "en",
  "enrollment_policy": "open"
}

$ cat nodes/web1.json 
{
  "ip_address": "99.231.92.23",
  "services": "webapp",
  "tags": "production"
}

Leap-cli

Command Line Tools for Admins


$ leap --yes deploy
 Deploying to these nodes: web1, vpn1, couch1
 = updated hiera/couch1.yaml
 = updated hiera/web1.yaml
 = checking node 
   - [web1] ok
   - [couch1] ok
   - [vpn1] ok
 = synching configuration files
   - hiera/web1.yaml -> web1:/etc/leap/hiera.yaml
   - hiera/vpn1.yaml -> vpn1:/etc/leap/hiera.yaml
   - hiera/couch1.yaml -> couch1:/etc/leap/hiera.yaml
   - files/branding/tail.scss, files/branding/head.scss -> web1:/etc/leap
 = synching puppet manifests
   - /home/demo/leap/demo/leap_platform/[bin,puppet] -> web1:/srv/leap
   - /home/demo/leap/demo/leap_platform/[bin,puppet] -> vpn1:/srv/leap
   - /home/demo/leap/demo/leap_platform/[bin,puppet] -> couch1:/srv/leap
...

Setting up a new Provider

Initializing and deploying nodes

Provider Online

demo.bitmask.net - Reference Provider of LEAP

already open for beta testers

Interested Providers

Etc

Website: https://leap.se

Github Mirror: https://github.com/leapcode

Made with reveal.js