Software for organizations and people
MBBSoftware Blog - Practical Ways and Best Practices for Safe Online Communication Hi guest
Sign up - Login

Practical Ways and Best Practices for Safe Online Communication

By Miroslav B. Bonchev
Part I
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.
Part II
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.
Miroslav B. Bonchev
6-th August 2012
London, England
We would love to know your thoughts and opinions on this article. Please leave any comments or questions you may have about it in the box below, and create a free account or subscribe to our newsletter if you wish to be notified when we publish new articles.
Community Content
(To enter your comments you must be signed in. Log in or create FREE account.)
Be the first to comment.
Information Presenter
Act On File
Audio Control
Photo Window
Vat # Validator
Information Presenter
for Museums and Art galleries
for Resorts, Hotels and Cruises
for Parks of any kind
for any business
Encryption and Authentication
Safe Online Communication
Website Testimonials
Learn how to store private keys
Make The Most From Your Files
Convenient Volume Control
Photo Window - an Awesome Gift
My Account
FAQ - Forum
Email this page
Public Authentication Key
Public Encryption Key

© Copyright 2020 MBBSoftware. All Rights Reserved.
Machine translation:

Email this page
use semicolon to separate emails eg: joe@abc.com; lea@abc.com
a link to this page will be automatically added to your message
Please type the anti-bot text below.
Type text:
Thank you for subscribing to the MBBSoftware newsletter.
Enter your email address:
Please type the anti-bot text below.
Type text: