5

How would one go about creating a secure email architecture?

I'm thinking specifically about protecting email from routine surveillance from oppressive regimes and corporations.

I had a think about what it might look like. I envisage an email server which receives an unencrypted email, then looks up the intended recipient's GNUPG public key, and encrypts the email, before storing it on disk.

This would prevent the content of emails being stolen, or read. But the headers as well as the body of the email would need to be encrypted, which makes for problems when interoperating with standard email clients.

The only thing I can think of is something which operates in a similar way to the old Type I remailers used to, where the whole message (headers and body) were encrypted. This would mean custom clients.

Are there any existing attempts at doing something different? Any other approaches?

A

4 Answers 4

5

Unless it is encrypted before going to the server, there isn't much point in encrypting it on the server. If the server is going to do bad things, it can just not encrypt it. Additionally, decryption on the other end would have to be done on the server, so the recipient server could also leak it.

The connection in between servers can be secure if TLS (an existing but under-utilized) technology is used between servers. Similarly, TLS can be used between the client and server to protect the message in transit the entire way. Simply having a mail server that refuses to talk to a non-TLS supporting mail server would do everything your proposed system would.

If you need secrecy from the servers as well, then you have no choice but to encrypt/decrypt on the final client which is what PGP/GPG currently do already.

3

It sounds like you're talking about receiving clear text emails and then encrypting them. If this is the case, the architecture is already insecure.

What you could do is set up a mail relay server which handles encrypted mail transfers on behalf of end users. Those users would handle their key management and distribution and contacts' public keys. All your relay would need to do would be to relay mail based on sender/recipient addresses. Once you've done initial troubleshooting, you could then disable logging.

With the above, you'd hold no keys and have no records. Outside of you somewhere on the interwebs, someone's going to strip out the mail addresses and subject lines. I don't know how to protect against this...

I'm curious about other responses to this.

2
  • Receiving clear text emails is a given, there's no way around this. I'm just trying to envisage what a system might look like that was as secure as possible within the constraints. The entry point to the system needs to receive plain text emails, then encrypt them, headers and all. With the old remailer network, you had an option of having your incoming mail land in a Usenet newsgroup. Your client would pick up the messages from there. Possibly a variant on that would work.
    – Avram
    Jun 14, 2013 at 13:39
  • So you could have the endpoint connected using a secure protocol (TLS/SSL per AJ below) and have everything encrypted centrally using keys per client. If anyone monitors entry points at least the channels for connectivity are encrypted so the plain text mail are encapsulated. My response above was based on decentralising the encryption process to the endpoints and having encrypted data in transit so the central environment has no visibility except over headers. The above provides full visibility centrally prior to the encryption.
    – AndyMac
    Jun 14, 2013 at 14:09
2

Anything you do outside a secure network is subject to traffic analysis. With the advent of big, extremely big number-crunching facilities there is little hope of hiding in the complexity of routine Internet traffic.

Oppressive regimes maintain a lot of Tor exit nodes and attempt to jam or intercept dark networks.

Corporations run e-mail/contact services that feed back to said oppressive regimes.

I'm afraid unless you run your own net e-mail security is an illusion. Once your (supposedly secure) communications are detected, you are no longer anonymous; you will be tracked, your keys and recipients' mail folders may be subpoenaed, your contacts may be waterboarded, hence there's almost no chance to have secure e-mail architecture.

The problem with e-mail as an essentially insecure service is that you inherently leave traces - messages are intended for further perusal. Traces are BAD - traces are incriminating - even in countries with oppressive regimes the legal system is not fully arbitrary, so it needs some evidence to prey upon if your colleagues and you fail to co-operate with the prosecution. Would suggest looking into off-the-record messaging instead.

The most secure place for information is in one's head, never on paper (or in any durable storage).

1
  • I largely agree. Trying to make email secure is like trying to make a sieve airtight. There could be a component stored on a hidden Tor service perhaps.
    – Avram
    Jun 14, 2013 at 13:42
0

You may want to look into a best-of-breed type of email encryption provider. I've worked with companies like DataMotion in the past and they secure all outbound communications and typically they're able to track all of the messages too, which helps in case you need to prove that you're encrypting the messages. I don't know specifically what type of environment you have, but I would imagine that they're flexible enough to handle what you have in place. Good luck!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .