How do I encrypt the source and destination IP address, along with various parts of an email?

Question

If the subject makes no sense to you, that's fine, it makes no sense to me.

I've been tasked with securing emails sent from some devices, and I'm looking for advice on intelligent questions to ask to clarify some requirements. Apparently the source and destination ip addresses need to be encrypted, along with the username used to log in, and the email message itself.

In order to encrypt the source and destination IP addresses of a conversation, it looks like I'd need to use something like IPSec, correct? And that would be done at the OS level, not just as part of an application when sending an email, correct?

For encrypting the username, I have no clue what that means. Seems like if I encrypt the credentials when attempting to log in, I won't be able to log in unless the server can decrypt them somehow.

For encrypting the email itself, if I use something like PGP, I would need to set up keys on the device sending the email, and the receiver's machine, correct?

I've done some research on the requirements, and the above is what I've come up with. Looking for some intelligent questions to ask, and validation of my assumptions above.

thanks,
Mark

Answer 1

To protect packet destinations, you need to abstract the network layer entirely - which usually means some form of encrypted VPN. This would mean no hardware on the local network would know what packets are being transmitted, where to or what they contain.

Unfortunately, this doesn't solve the real problem, just moves it upstream. Your VPN/encrypted link has to connect to the real network at some point and as soon as it does, you'll be forced to use correct routing information. You could mitigate this by moving IP blocks every so often / having multiple connections to the 'net but this could be complex to maintain.

An improved approach might be to use TOR to mask routing from your network. It's not perfect but it's another layer of defense.

So perhaps an SSL SMTP connection over your encrypted vpn to your mail server and encrypted email over TOR to the recipient(s) mail servers. (SSL on top of your VPN encryption to protect against other machines on the VPN. You may want to consider client certificates to guarantee the source of the email)

Edit: Having just spotted your use case in comments, and focusing purely on protecting the connection to the smtp server, I think it'll depend on how easy it is to uniquely configure the sensors.

If it's cheap, use a unique SSL client cert with each sensor. This will both secure the connection and confirm the ID of both parties - no spoofed sensors.

If it's costly to configure, use something PSK based - You still get the encryption but if one device is compromised, they all are [at least to anyone inside the VPN].

Answer 2

Source IPs - If you connect to a mail server you control, you can configure it to write fake source headers (does it really matter since you'll probably be using private network IP ranges for your senders machines?) - but the upstream mail server will see the real IP address for your immediate mail server. Whether or not it commits that information truthfully to the headers it writes is a different matter.

Destination IPs - At some point, they will need to appear in the clear to the MTAs that the email transits so that it can be properly routed. At that point, the MTAs handling that email will probably (as they should) write that information into the mail headers.

Encrypt the username - Presume this means securing the login process? Pass it through a secure tunnel.

Encrypting the email itself - depends on the sender and recipient email clients, and how much usability is required. You could go as far as just sending Truecrypted blobs back and forth as attachments, which requires no modifications to the email clients. Or as you mentioned, deploy a certificate-based system - the fine deployment details will depend very much on the email client, OS, and how much compatibility is needed (what happens when "outsiders" need to send or receive secure email?).

Answer 3

It's nontrivial for two highly technical people to exchange email with your requirements satisfied. Accomplishing that for communications between embedded devices and people who are managing them is mind-boggling. Encrypting content is the simplest requirement. OP could use GnuPG, and give each device a unique private key. Or as Basic suggested, OP could use OpenSSL and give each one a unique client key.

As long as login username is part of the message, there's no need to separately encrypt it. If usernames must remain obscured after message decryption, each user could have an anonymous or pseudonymous account ID.

Encrypting source and destination IPs makes no sense, as OP and others have observed. If it's merely necessary to obscure those IPs from casual observers on intervening networks, using proxies on each end would be sufficient. But if device managers must not know the public IPs of devices, and devices must not know the public IPs of device managers, you have quite a challenge.

Some (many) may laugh at this, but using Mixmaster remailer nyms may be the simplest approach in that case. Each device and manager would have an email address at a public or private Mixmaster nymserver. Some nymservers can be reached as Tor hidden services, for added anonymity. Outgoing encrypted messages specify a chain of Mixmaster remailers to be used in reaching the destination address. Encrypted replies can be directed to alt.anonymous.messages, and signed such that recipients can identify messages to them. Clients periodically download all messages in alt.anonymous.messages, optionally through Tor, and identify those that they can decrypt.

Answer 4

This depends on what you mean by "source and destination ip address."

Regular internet email based on SMTP records a list of IP addresses in the headers of a message as the message traversers from one "Mail Transfer Agent" (MTA) to another. You probably think of these as "mail servers." It's not uncommon for a single message to transit several MTAs between send and receive.

If you want to protect the IP address of the device the user used to type in the message, that's relatively simple. You'll need an MTA (i.e. mail server) that will accept email on your behalf and NOT record the IP address of the Mail User Agent (MUA) in the headers. This MTA would have to be well connected to the internet, and trusted enough by other MTA's for them to continue accepting messages from it. In this age of anti-SPAM warfare, this may get a bit tricky. Another approach would be to record the IP Address of the MTA itself as the MUA address.

The address of the final recipient's MUA is not normally recorded in the headers, simply because the MUA accesses the message via a protocol other than SMTP, typically IMAP or POP. Since recording the chain of addresses is really an MTA activity, the MUA usually doesn't do this. The POP or IMAP server you use might, but it's not common.

If you want to use the internet's SMTP email infrastructure, the MTAs involved are going to get marked in the message headers at some point.