What makes the Dark Internet Email Environment project look promising is the Dark Mail Alliance consists of the same principled and highly skilled engineers who brought us PGP/OpenPGP and Silent Circle products.
GPG should be an ideal solution for protecting emails on third-party servers – it’s highly scalable, since each person needs only a private key and access to a list of public keys, it’s extensively documented and it has APIs that enable developers to incorporate GPG into their applications. Breaking GPG is non-trivial, and it would be unrealistic for the authorities to expect its developers could maintain a backdoor in an open source project.
The reality is that few people are using PGP/GPG/OpenPGP, since most of us want everything on demand with minimum effort. We all want to sign into our email accounts, or a service like FaceBook, and have our messages instantly available. Hardly anyone wants to download and configure anything, and is why numerous innovative privacy solutions fail to gain traction. StartMail and DIME are two different approaches to solving this.
My understanding, after reading through the Architecture and Specifications document, is that DIME is fairly close to what an automated GPG solution would provide, alongside a form of onion routing. Overall it’s about ensuring everything sensitive, including email headers, is protected between the sender and recipient.
Development is based around four protocols:
* Dark Mail Transfer Protocol (DMTP)
* Dark Mail Access Protocol (DMAP)
* Signet Data Format
* Message Data Format (D/MIME)
DIME should be deployable without too much work. Speaking to Ars Technica, Levison stated: ‘You update your MTA, you deploy this record into the DNS system, and at the very least all your users get end-to-end encryption where the endpoint is the server… And presumably more and more over time, more of them upgrade their desktop software and you push that encryption down to the desktop.’.
The message structure consists of an ‘envelope’ encapsulating the message body and email headers. Protected information includes the sender and recipient addresses. A layered encryption method allows the mail relays to access only the data they need to forward the messages, and using D/MIME the sender and receiver identities are considered part of the protected content. That is, the sender and receiver addresses are considered part of the payload, and should be encrypted along with the message body, which is something GPG doesn’t do.
This is important because the claim that authorities are inspecting only the ‘metadata’ of our Internet communications is misleading. Email addresses and message headers are actually contained within the payload of the TCP/IP traffic being inspected – the content must be read in order to read the email addresses.
Unlike conventional email, the message headers (including the To and From fields) really are processed as confidential, and instead routing is determined by the Origin and Destination fields (AOR and ADR).
Public keys, signatures and other things associated with identities are managed as ‘signets’ – all the cryptographic information required for end-to-end encryption between communicating parties. There are two types of ‘signet’: Organisational signets are mapped to domains and contain keys for things like TLS. User signets, on the other hand, are mapped to individual email addresses, and contain public keys associated with them.
There are three modes: Trustful, Cautious and Paranoid. These specifically relate to whether the client or servers handle key storage and encryption. Users have the option of a) ensuring that only client devices have a usable decryption key, and b) trusting LavaBit to manage their cryptographic keys that apparently are extremely difficult for LavaBit admins themselves to access.
Dark Mail Transfer Protocol (DMTP)
DMTP handles the delivery of encrypted messages, with another protocol, D/MIME should protect the content against interception. Basically the email or message is encapsulated, with headers only revealing enough information for servers to relay the message. In order for the encryption to be implemented, the sender must look up the recipient’s public key(s), which happens through a ‘Signet Resolver’ to find a ‘signet’ that contains the public key.
DMTP is also the transfer protocol for retrieving ‘signets’.
The transport method is actually quite similar to conventional email. It uses an additional field to the domain name records, pointing to the DIME relay server.
One requirement of DMTP is that all sessions must be secured by TLS, and with a specific cipher suite (ECDHE-RSA-AES256-GCM-SHA3841).
Dark Mail Access Protocol (DMAP)
The finer details for this haven’t been established yet, and this section appears to be notes of a few points. DMAP is being designed to handle the key exchange and authentication side of the secure email implementations, making sure the client’s keyring is synched with the ‘signet’ admin servers.
DMAP is to incorporate something called ‘Zero-knowledge password proof’ (ZKPP), a way for two entities to confirm that each knows a secret value without exchanging that value.
Installation of DIME on Mail Servers
A development version of the DIME library can already be installed on a Linux system. Unfortunately I haven’t managed to get this compiled and installed on Linux Mint, even with the dependencies sorted. I’m still working on installing these on a CentOS server.
The dime executable enables the lookup of signet/address mappings, verification of the signets, the changing of DX server hostnames and the reading of DIME management records. The sending and receiving servers are determined using the dmtp tool. Signets, they are generated and managed using signet as .ssr files.
A proof-of-concept program (genmsg) in included for sending Dark Mail messages in the command line. To do this, the sender specifies the sender address, the recipient address and the path to the ed25519 signing key.
Once on the server, the messages are stored in a typical database scheme on a Magma server.