In this two part article I will share a simple, elegant and powerful way to make your email communication secure and safe. First we will discuss what an email is in order to
recognize the root causes which make internet/email communication insecure unless proactive measures are taken. This will also equip the reader with some basic knowledge which
will make them able to think and make decisions on these issues themselves.
An email is basically a text file, just like any text file that you create with Notepad. That is the body of the email. An email server sends this text file to another server,
which on its way sends it to another server and so forth, until the file reaches the destination server. So for example if you send an email to employee12@BigCompany.com the
destination server is the mail server of BigCompany.com. The mail server stores the text file that you wrote in a folder similar to this: /mail/employee12. The sender server
places a bit of information called "header" before the actual message. The header contains certain information such as the email address of the recipient, and also "From",
"Reply-To", "Sender" and other fields. The internet has been wisely designed to be a decentralized system and thus there is no "central authority" to ensure the truthfulness of
the content of all these fields, nether there is a possibility to do that. Thus we hit the root of the first security risk – the sending server can place whatever data it likes
in the "From", "Reply-To", "Sender" and a few other fields of an email message. Spoofing is when one uses these facts and sends a message which appears as if sent by someone else,
i.e. tries to impersonate them and deceive the recipient.
As the email travels, the mail servers add their own fields to the header of the message, containing its address and other information. Thus if everything is fine one can trace
the servers through which the message travelled. However, now we notice the second problem, which is that every server actually reads, modifies and retransmits the message, and
thus it can also interpret or filter the message for key words and if decides it can make a copy of it, retransmit it to new recipients, and so forth. This of course is also true
for the destination server where all messages are finally stored as plain text files ready for access by the message recipient. So the administrators of all mail servers through
which an email message travels could read, store and exploit it if they so desire.
The third problem is that we cannot be sure that the content of the message was not modified while travelling. There are measures taken to ensure that there are no errors during
the travelling of the data packages, but these measures cannot prevent intentional changes which are easy to make on plain data. Thus we can summarize that an email message is
just like a postcard: it is open to be read by anyone, it is untrustworthy as it could have been modified while travelling to us, and unwarranted faith must be placed in it
regarding its place of origin.
In the second part we will look at the promised solution.
In this part of the article we will solve the problems of internet communication described in the first part. First we need to put the message in an envelope. This is achieved by encrypting
the message. Most people are acquainted with symmetric encryption which uses the same password for encryption and decryption. This is not suitable for our aim to encrypt an email since
it may be difficult to exchange passwords in a secure manner, especially with new contacts, let alone the logistical difficulty to maintain a separate password for each contact. The
alternative is asymmetric encryption which uses two passwords called public and private keys. The public key can be used to only encrypt the message but not to decrypt it or for anything
else. The private key can be used to decrypt or encrypt. One can use software such as the Cryptor module of
Act On File to produce public private key pairs. In order to be able send an encrypted message to someone using this method they
should first have published their encryption public key on their website, or social media account. Thus one can take their encryption public key and first encrypt their message to them,
using the Cryptor module of Act On File, and then send it. Thus their
message can be decrypted and read only by the recipient and nobody else, as only they have their private encryption key which is the only key that can be used to decipher the message.
Thus, in order for other people to be able to send you private (encrypted) messages you need to publish your own public encryption key on your website or social media account, so that
they can use it in the fashion described above.
The next problem is how the recipient of an email can authenticate that the apparent sender of the message sent it, and not someone who manipulated the headers of their mail server.
This problem is resolved by applying almost the same technique as for encryption. Using the Authenticator module of
Act On File, one generates a public private key pair for authentication. As with encryption they only need one pair of keys, the
public key should be provided to the recipients of the message via an authentic channel, such as the key being published on their website or social media account, while the private key
should be kept secret at all times. Then, they can use the Authenticator module of
Act On File to create a digital signature of the message, using the message itself and their private authentication key. Then they
send the message and its digital signature. The recipient of the message can authenticate it using the Authenticator
module of Act On File by using the message itself, its signature, and the apparent sender's public authentication key which they
take from their website. Since only the public key, complement to its private key used to create the digital signature, can be used to authenticate it the recipient can be certain that
the message has been sent by the apparent sender and that it has not been tampered with.
So far we have established that we need to encrypt the message using the recipient's public encryption key which we download from their website, and sign it using our private authentication key.
Sometimes when there are multiple recipients of an email, the email may be left open (unencrypted), or have to be encrypted with a common password/key pair known to all recipients. However, even
if a message is not encrypted it should still be authenticated to protect the recipient from spoofing and phishing attacks.
While a "Hi, how are you?" type of email can be sent in a security relaxed manner, any important communication should be encrypted and authenticated. In this case we strongly recommend that
the actual message is written as a file which the recipient can read, e.g. an Open Office or PDF file, with a digital signature appended to the file. The file is encrypted and signed using
software such as Act On File. The order of encrypting and signing is not important but must be known to the recipient of the message.
It is recommended to append the digital signature to the signed message file and not have it as a separate file. If using Act On File
to sign the message file, you can request it to append the signature to the signed file. Thus the user will be forced to authenticate the file, which will include removing the signature and
restoring the file to its original readable form, before they can open and read it. This technique will force the recipient to not be sloppy with their security, but authenticate the message
first if they wish to read it.
Some mailing programs are able to authenticate messages using certificates. Certificates often incur a yearly cost. More importantly, the above technique is decentralized in the spirit of
internet and does not involve any third parties. The possible alternative methodology using certificates requires certificate authority, which is an anti-internet centralized model. Further
one must believe that the certificate authority is trustworthy, thus introducing a security flaw. In addition, using two separate applications, as proposed, each in its own domain of
obligations, which are the email program to do the emailing and the security software to do the security work presents a proper distribution of tasks to whom they belong. A single emailing
application used for both tasks of emailing and securing the data breaks that paradigm, for example it could also send the data in readable form to anyone.
Another benefit from the above approach is that after authenticating and decrypting the message file recipient will have it also outside of the mailing software, which might help to
maintain a better archive than keeping files in a mailbox.
Act On File can be downloaded from: http://www.mbbsoftware.com/Products/Act-On-File/2012/Download.aspx.