[liberationtech] Secure Email Survey
Guido Witmond
guido at witmond.nl
Tue Nov 26 12:09:59 PST 2013
On 11/25/13 16:01, Dan Meredith wrote:
> Hello LibTech,
>
> The Open Technology Fund is surveying projects working on next
> generation secure email or email-like communication. The purpose of this
> survey is to identify potential areas of collaboration, better
> understand the trade-offs made by the different projects, and to help
> the internet freedom community better understand these projects. This
> survey's findings will be published publicly to serve the above purpose.
>
> So far, we have invited these projects to participate:
>
> ansamb.com
> bitmail.sf.net
> bitmessage.org
> darkmail.info
> flowingmail.com
> leap.se
> mailiverse.com
> mailpile.is
> mailvelope.com
> mega.co.nz
> opencom.io
> parley.co
> perzo.com
> pond.imperialviolet.org
> retroshare.sf.net
> scramble.io
> startmail.com
>
> All these projects are working on email or email-like communication that
> departs from traditional encrypted OpenPGP or S/MIME email in one way or
> another. Although this survey only applies to asynchronous messages
> (i.e. not synchronous chat), there is a great deal of diversity among
> the approaches. Some projects are open source, some are not. Some
> projects provide services, some provide only software. There are
> centralized, federated, and peer-to-peer approaches. There are HTML5
> apps, desktop apps, mobile apps, and extensions. You get the idea.
>
> Please let us know if we are missing any projects.
I believe you might be interested in mine. It's a project that tries to
use existing technologies in a slightly different way to achieve a very
high level of privacy and security by default. It could be used to get
Granny use encryption.
Although I aim at encrypting the Web, it can be easily used for an
email-like service. One does not preclude the other.
I've completed the survey and attached it here.
With Regards, Guido Witmond.
-------------- next part --------------
General project information
------------------------------
What is the name of the project?
- Eccentric Authentication
Do you represent the project?
- Yes
Do you want to share your email address?
- Yes, guido at witmond.nl
What programming languages is the project primarily written in?
- Go
What is the distribution license of the project???s software?
- AGPL v3+
Is there a URL to the project???s source code, and if so, what is it?
- https://github.com/gwitmond/eccentric-authentication
https://github.com/gwitmond/ecca-proxy
Where is the design of the software and protocols used documented?
- http://eccentric-authentication.org
Is the project email or email-like (or both)? In other words, does it use SMTP?
- No SMTP at all.
- It uses a web site to:
- introduce strangers to each other;
- exchange public keys;
- transmit encrypted private messages.
- It could be backported to IMAP.
Which of the following applications does your project include:
* A user agent (currently a web proxy to run on the end users computer)
* A web site that sends out some specific HTTP-headers
What platforms does the project currently support?
- Debian Gnu/Linux 64 bit.
- Any other sytstem that compiles Go(lang), libsqlite3 and libunbound.
What platforms does the project plan to support?
- Planning on getting a Firefox plug in
Do you also provide service using your software? (For example, do you provide email accounts for users?
* We do have a few demo sites running. These are for free.
* Some parts of the protocol could be outsourced to a third party.
- There could be a (paid) service for the part that does client certificate signing. It could help site operators that don't feel so confident with cryptography.
- Also, the web hosting can be outsourced.
* Best not to outsource the sites' Root CA key management. It might lead to a gagged disclosure leading to a duplicate site undetectable to the user agent. It will be detected soon, but some harm may have been done.
If you have not already, when do you plan to launch a ???public beta??? of your software or service?
- Still alpha.
In addition to email/email-like communication, what other types of communication does your software or service support, if any?
- Primarily, it's a protocol to exchance keys between total strangers;
- We use public signed messages and private encrypted messages;
- Email-like messaging is one use case of the protocol.
General security questions
--------------------------------
Which crypto libraries does the project primarily rely on?
* the user agent at the client requires:
- TLS 1.2 with renegotiation. Implemented with the Go-crypto libraries. Could be ported to any language with a decent crypto-library. Go does not implement renogiation :-(
- Uses DNSSEC and DANE with all their crypto. The user agent does the DNSSEC-resolving.
- No javascript is used for encryption. All crypto and authentication happens at a layer below javascript, out of control of javascript.
- No WebRTC either.
The server uses bog-standard http-servers with TLS. It must be
configered with a server certificate and a Root certificate for client
certificates.
The Third Part, the certificate signer uses Go and their crypto-libraries.
Which of the following security properties or features does the project currently provide:
* Meta-data protection - YES (each account is independent)
* Short authentication strings - NA
* Forward secrecy - NO (for messages), YES (for web traffic)
* Automatic discovery of public keys - YES
* Automatic authentication of public keys - YES
* Device awareness (encrypt separately to each of a recipient's devices) - NO
* Secure local storage - NO, expected to be provided by the users' device
* Secure cloud backup - NA
* Secure synchronization (same view into data among different devices) - NO
* Protection from traffic analysis - NO, Need Tor/VPN/...
* Anonymity - YES (reading public messages is anonymous)
* Pseudonymity - YES (writing is pseudonymous)
* Other:
* Secure public key exchange between total strangers: YES
* Protection against domain name hijacking: YES
* Censorship-resistence: YES
* Single or multiple identities per user: Multiple
* Encrypted traffic matching on timing and size: NO
Which of the above security properties does the project plan to provide in the future?
- We have ideas on protection from traffic analysis. Will be at the network level, separate from Eccentric Authentication.
For applications with a client-server architecture, of the security properties listed above, which would still hold if the server's private keys were compromised?
* There are two servers involved. The primary web server and the certificate signer.
- When the web server (including private key) gets compromised, the attacker can learn what non-Tor connections read and write (public messages). It could learn who writes private messages to whom.
When the certificate signer gets compromised, the attacker can create new certificates for existing accounts in a MitM attack. People that have previously exchanged messages are immune to this. New communication partners might detect it before they send the first message and will detect it after the first round trip. The protocol declares the site 'untrusted'.
It can be mitigated with regular key-roll-overs of the client certificate signing key.
When the Root CA private key, leaks, that site is lost. (Each site has their own Certificate signer and their own Root CA.). The Root CA private key lives on a smart card and is only used to sign the web server certificate and the Client signer Root. (A subCA).
What entities must a user trust when they use your software? In other words, if a particular entity is compromised, in what ways could this entity undermine the security of the user?
- Users need to trust their own hardware, operating systems. The users private keys are stored on the users device.
- They need to trust our software, the ecca-proxy, or when they use the future plug in, the whole of firefox on top of that.
- To counter these threats, an end user operating system should use partitioning. For example, Qubes-os.rg, Genode.org, Minix.org perhaps and when it's ready, the Hurd. :-)
We don't have deterministic builds. We aim for the common users for whom compiling software is an unwanted action.
What are the primary threat models the project seeks to address? For example:
* Protect against user errors that hurt privacy and security;
* Protect against the loss of privacy when signing up at a site;
* Protect end users against site operators colluding against users;
* Protect end users against errors done by server operators;
* Protect activists by creating lots of encrypted traffic to hide the important Tor in the noise;
* Protect against passive wiretaps;
* Protect against active wiretaps; MitM;
* Protect against disclosure of identities when a server gets taken over;
We are trying to split the global social graph into many smaller local
social graphs. Each web site forms the nucleus of a social graph. We
expect people to sign up at sites they find interesting. Each account
is unique and independent of other accounts. We hope people will sign
up with multiple accounts to isolate their blogging on parenting from
their blogging on nuclear energy.
We hope that people will use the public parts of the network to create
private networks. By sending an encrypted message through the web
site, people can create new encrypted channels. For example. Daters at
a dating site can set up ZTRP connection, authenticated with their
public keys they use for the dating site. See the Brucon-presentation
(pdf) at eccentric-authentication.org.
Eccentric authentication addresses the issue of how to exchange public
keys between strangers who have never met in real life. That's
something that not many crypto-protocols address. Usually it's assumed
in crypto-protocols that a certain Alice wants to communicate with a
certain Bob and they need to be sure that they are indeed who they
are.
Eccentric Authentication can also be used to create a public known,
easy to type 'email-like' address. People can create an account
somewhere. Print the nickname@@sitename on a business card and there
is your public email address. The only requirement is that the site
allows anonymous message submission.
If this is done inside a company, they can create an internal
email-like system. The company has the choice of allowing or
disallowing message submission to individual employees. The
requirement here is that the company performs identitiy validation of
their employees before signing a client certificate. When employees
use this account to send message to others, they speak officially on behalf of the employer.
For private use, employees have their own accounts elsewhere. Perhaps
even on their personal phone. No need to use company mail for private
matters.
How do you defend against these threats?
- It's all part of the protocol.
- We use pseudonymous client certificates signed by each site. We expect people to acquire as many certificate as they have passwords at sites.
- We use a global network to monitor double signing of an account name;
- We advise to use Tor for all connections.
Has the project had an external security audit?
- No.
Would the project welcome an external security audit?
- Absolutely!
If the project includes service, what potentially user identifying information do you keep in your log files?
- The logs can contain creation of accounts, every use of that account at the site, and the IP-addresses of the end point.
- The logs reveal who writes private message to whom. (the metadata, not the contents)
Features
-----------------------------------
What mechanisms does the project use to prevent spam?
- Each site can decide wheter to allow anonymous message submission or if it needs a client certificate.
This makes it possible to have an open mailbox, or a members only message box for a dating site, a forum.
Receivers of messages at a open mailbox are required to do all spam-, malware and other filtering.
If the software includes user passwords, what happens if a user forgets their password?
- The protocol does not use password at all.
People are encouraged to add a passphrase to their keys, or a swipe-pattern, a fingerprint scan, iris-scan.
That's entirly up to the paranoia of the user and their perceived value of the account.
Key Management
-----------------------------------
If the project uses public key cryptography, what type(s) does it use?
- We must to be compatible with what current web servers accept for client authentication.
- And with what most browsers accept as server certificates.
- There is nothing in the protocol that specifies a certain type of keys. We specify that it needs to be albe to log in at sites, can be used to encrypt and sign messages.
How and where are public/private key-pairs generated?
- Client-side, using the user agent.
How and where are private keys stored and backed up, if applicable?
- Private keys are stored on the clients' device.
- When a user loses a private key, they lose access to that account. Forever.
- Mitigation strategies are: ordinary backups; data synchronisation between multiple devices; printing out a qr-code of the keys and storing these in a vault.
How and where are other users??? public keys stored after being discovered or validated?
- There are two places for public keys/certificates;
1. The global PGP-keyserver like distributed storage;
2. The end user's local file system.
The first allows everyone to validate there are no duplicates;
The second is used to remember the identity of a known communication partner; We don't do a certificate/public key lookup every time it's needed. It would reduce privacy and the load would be too high to handle.
How do you handle key expiration and/or revocation?
- Expiration is a decision for the site operator. We expect most to create long term certificates for their customers.
- Revocation, we don't. We expect people to go through certificates like they go through underwear and delete their private key when they want to close the account. This teaches sites to minimise the amount of state they keep about their customers.
- Paid services can return an error when an account is overdue, for example refusing to accept messages for that account; removing the data of the account. It's their site.
- The current protocol is already complex enough.
- Eccentric Authentication should not be used for high-value accounts. At a bank, it can be used as the first-level of authentication. For depositing, banks should use the hand held token generators where people type in the transaction details and return the token to the bank.
Which, if any, of the following mechanisms do you support (or plan to support) for key discovery:
* Key discovery happens when people
* find an interesting signed blog at a blog site; the signature contains the public key;
Which, if any, of the following mechanisms do you support (or plan to support) for key validation:
* The central registrar is used to verify there is only one certificate for the {nickname,sitename} tuple.
* Currently the plans are to use Ben Laurie's Certificate Transparency. This part of the project is still in the design phase.
Further questions for HTML5 apps
-----------------------------------
HTML 5 is free to use for app builders. The Eccentric protocol happens at a deeper layer.
In fact, with an extension, eccentric can be used to prevent XSS, XSRF attacks. See our web site for Cryptographic Same Origin Policy, to replace the brittle domain name based SOP.
Further questions for email-like software
---------------------------------------------
Does the project support, or plan to support, backward compatibility with email?
- A open message box could be used to create an IMAP interface.
How would you describe the architecture of the project???s software?:
(a) Decentralized.
What does the project use as the unique identifier for user addresses?
(b) username@@domain notice the double @.
If the project has a peer-to-peer architecture, how does it route messages? For example, does this routing rely on a DHT, friend network, etc?
- Message are send via the site.
- People are encouraged to use other networks besides that.
Further questions for email software
----------------------------------------
Does the project support OpenPGP for message encryption?
- N/A
If so, does the project send OpenPGP/MIME by default?
- N/A
Does the project support S/MIME for message encryption?
- The current demo uses openssl smime to create signed messages and validate these.
- It could use other message signing protocols, XML-signing, Salmon Magic signatures.
Does the project support, or plan to support, the OpenPGP header or something similar? (i.e. http://josefsson.org/openpgp-header/)
- Not at all.
Does the project include its own user interface for reading and composing messages?
- Yes.
Does the project allow the use of existing mail user agents (e.g. Thunderbird)?
- No.
If the project includes an MX server component, does the Mail Transfer Agent use StartTLS for server-to-server relay?
- N/A. No mail server.
If StartTLS is supported, are there any conditions under which StartTLS is required? (e.g. always, DANE, whitelist, etc)
- N/A (not a mail server)
If StartTLS is supported, do you enable ciphers that are not-forward secret or have fewer than 128 bits?
- N/A (not a mail server)
More information about the liberationtech
mailing list