What can be done to support secure email?
Personal and business Internet users are showing interest in the concept of secure email. This is to assure that confidential emails only end up being viewed by the eyes of their intended recipients.
It is being driven by issues relating to confidential personal and business information being leaked to the Web along with a common personal worry regarding government surveillance in the age of terrorism and extremism. Along with this, activists, journalists and the like are wanting to rely on secure communications to pass through critical information in areas that are hostile to freedom of speech and the press. In some cases, people travelling through countries known to be hostile to freedom of speech like Russia and China have been encouraged to keep their data highly secure due to the espionage taking place in these countries.
More work needs to be done on secure email
There is a slow increasing prevalence of secure email platforms appearing on the Web. These platforms such as the Swiss-based ProtonMail and the secure iteration of Google’s GMail service are dependent on a Web-based user interface. Along with this, most of us are implementing instant-messaging platforms like WhatsApp, Viber and Telegram to send personally-confidential material to each other.
But they offer a series of features intended to assure personal privacy and corporate data security. They offer end-to-end encryption for the emails at rest (while they are on the servers pending delivery) and in transit (while they are being moved between servers). They also offer the ability for users to send seif-destructing emails that don’t stay in the recipient’s or the sender’s storage space after they are read unlike with conventional emails which stay in the user’s storage space after being sent or read. These self-destructing emails cannot even be forwarded to others or printed out (although it could be feasible to take a screenshot of that email and print or forward it). Some of these setups even have the ability to detect screenshots and let the sender know if the recipient took one of a confidential email. As well the metadata about the emails isn’t held on the servers.
But there are current limitations associated with these services. One of these is that the privacy features are only available to users who subscribe to the same email platform. This is because the common standards for secure email such as S/MIME, PGP and GnuPG only support basic key-based encryption and authentication abilities and the common email protocols like IMAP and POP3 don’t support email-handling control at the message level. As well, these services rely on a Webmail interface and require users to click on links sent as part of standard emails to view the secure messages if they aren’t part of that system.
There are certain features that need to be added to IMAP4 to allow for secure email handling. One of these is to permit message-level email control to permit self-destructing emails and to allow the sender to limit how the recipient can handle the messages. But the message-control features may run against legal-archive and similar requirements that will be asked of for business correspondence. In this situation, there may be the ability to indicate to senders or recipients if the emails are being archived as a matter of course and message-level email control can’t be assured.
Of course this may be about a newer feature-level email standard, preferably open-source or managed by many in computing academia and industry, to add this kind of secure email control.
Then there is the requirement to encourage the use of encrypted-email / authenticated-email standards like S/MIME or PGP within email endpoints, both Web-based and client-based. It will also include the ability for users to create asymmetrical key pairs and store their correspondents’ public keys in their contact manager software. There will also have to be the ability to support automated public-key discovery as a new contact is added, something currently feasible with encrypted messaging platforms that maintain their own contact directory.
Other questions that will come up in the course of building a secure email ecosystem is how the encryption keys are stored on the end-user’s system and whether an end-user needs to create new encryption keys when they change devices along with how to store them securely. This can be of concern with most computer users who typically maintain multiple devices, typically a smartphone along with a regular desktop or laptop computer and / or a tablet of the iPad ilk. Similarly there is the fact that one may not have the same computing device for the long haul, typically due to replacing one that has broken down or upgrading to a better-performing device.
There will also have to be the issue of security and portability thanks to issues like users temporarily using different computer devices such as friends’ computers, work / school computers or public computers. Here, it may be a question about where contact-specific encryption keys are held, whether on a server or on removable media along with how email sessions are handled on these temporary setups.
What will need to happen is for email platforms to support various secure-messaging features in a manner that can exist on a level playing field and without the need for correspondents to be on the same provider.
