Go to Top

安徽快三推荐: Emails and GDPR – The Need and Drawbacks of Encrypting Emails

With the GDPR in full effect now, some companies still struggle with the processes to make their IT compliant to the new regulations. Since the GDPR covers many aspects of data security as well as reasons for data leakage there is almost not a single IT process not effected by the new European law. While most of the process to change are quite obvious, some are not.

Such a required change is the need to encrypt emails which contain personal information of clients and customers, employees or anyone else. Since article 25 of the GDPR requires data protection “by design and by default” for all business (IT) processes for products and services and the whole law is supposed to make personal data more secure and to prevent data leaks more unlikely, many lawyers argue that this new law requires all emails to be encrypted by default. Even though it is not clear now, if this is true or not, it makes sense to – if you did not do so already, to think about the consequences.

Remember: An email is like a postcard! When you send an email, some people like for example the enterprise IT administrator or the internet service provider can read its content if they want to. Therefore sending a normal email including personal or sensitive information without encryption is considered to be illegal under GDPR.

Email encryption is not as common as it should be. That is because of the fact, that implementation of this feature is not easy. There are currently two different methods available to choose from:

  1. Transport encryption

Transport encryption means that the email(s) will be encrypted when they are send (transferred) from one server to another. The emails are send through an encrypted tunnel when using this method. The emails are encrypted when the depart from one server and decrypted when the arrive on the other server. All emails on the server are not encrypted when they are stored on the server. Sending encrypted emails over the internet you would use for example the POP3S email transfer protocol with the Transport Layer Security (TLS) network protocol (which is the new name for the Secure Sockets Layer (SSL) protocol used for quite some years now).

TLS combined with POP3S therefore creates an encryption tunnel – also known as site-to-site-encryption or end-to-end-encryption, which is a great solution when you connect two servers directly. However most companies do not have such close relations that they connect their email servers directly. Most likely there will be some other server on the way, where the emails will pass through. Therefore another solution is needed… such as…

  1. Content encryption

When using content encryption the email will be encrypted and not the network transport tunnel where the email is transferred through. Today the most common standards for email content encryption is either the S/MIME (Secure/Multipurpose Internet Mail Extensions) standard or using Open PGP.

S/MIME can be for example implemented in your MS Exchange Server. S/MIME is based on asymmetric cryptography and uses a pair of of mathematically related keys to operate. Those are the public and private keys. An email is encrypted with the recipient (not the senders) public key, while the email is decrypted with your private key. Even though the technology of S/MIME is not easy to explain, I try to keep it simple here: When implementing S/MIME in an MS Exchange Server a certificate is produced which contains the signature of the user and also contains his public key. When he sends another user (user “B”) this signature, he proves that he is the person he claims to be and gives his email recipient his public key and therefore gives him the right to send him encrypted emails. When user B then sends an encrypted email the next time to user A, the email client of user A ?recognizes“ that the email is from a secure and known sender, searches for his private key inside the email client and decrypts the email on the fly.

The same procedure is true for OpenPGP. It is also based on public and private key exchange for encryption and decryption of emails. You generate a pair of keys – one that encrypts the email (the public key) and the other one that decrypts the encrypted email (the private key). You share your public key to all those persons you want to get encrypted emails from. Once you receive an encrypted email from a known source your email client will decrypt your email. That is how it works. However implementing an OpenPGP solution can be quite time-consuming and difficult. An example of how this can be done, can be found here

Nowadays when enterprises use encryption for emails they implement S/MIME in their MS Exchange or other email exchange server while private individuals use OpenPGP based encryption solutions like for example GnuPG or other open source variants.

 

The dangers of email encryption

As we have seen using transport email encryption like TLS means that on both the sender as well as on the receiving email server (as well as the email clients) the messages as well as their attachments are stored non-encrypted. Therefore when an email server malfunctions like for example when an internal hard disk drive fails or when the whole systems stops due to user errors of the software, data recovery experts like those from Ontrack Data Recovery are able to reassemble the file systems as well as the emails without greater challenges.

However when content encryption – regardless if S/MIME, OpenPGP or a gateway solution – is used, there can be cases where recovery of encrypted emails is challenging.

In any case the so-called public and private keys must be available to the data recovery experts in order to begin or try to recover any emails. If these keys – or in case of the private key, which is actually a certificate – are not available, then there is not a slight chance to recover the original content inside the email.

Since for example the smallest symmetric key length (or key size) of OpenPGP is 128 Bit, it would take 1.44 billon years to crack that symmetric encryption key. And with 256 Bit keys most crypto experts state that it is impossible even for governmental security agencies and their supercomputers to decrypt that encryption key.

Therefore you should always keep and store your encryption keys, certificates or decryption passwords separate from the original email server or desktop computer so when a data loss occurs, then the data recovery experts can use them later on when they were able to recover the encrypted raw data.

 

 

Picture copyright: John-Mark Smith/www.pexels.com

https://www.pexels.com/photo/brown-paper-envelope-on-table-211290/

CCO license

Leave a Reply

Your email address will not be published. Required fields are marked *

  • 全国人大代表、上海市黄浦区委书记杲云:打造卓越的全球城市核心区 2018-12-12
  • 那些吃不惯汉堡牛排的中国留学生们,是怎么在美国活下来的? 2018-12-12
  • 深圳白石洲村民旧城改造有户主一栋楼补偿四千万,算不算勤劳致富? 2018-12-12
  • 崇拜不劳而获是腐败的根源之一,正气不足是腐败的第二个根源,沉迷于初级趣味易滋生腐败,提高素质力争不想腐,以医者之心防治腐败。 2018-12-09
  • 为什么1000元的人民币千万不能发行?看完明白国家的良苦用心 2018-12-09
  • 西班牙vs阿根廷6比1狂胜 梅西因伤作壁上观愤然离场 2018-12-03
  • 从“乡土味”到“高级感”,吴昕只走了这几步 2018-11-28
  • 为了人民重托——记政府工作报告起草 2018-11-28
  • 国家发改委:粤港澳大湾区规划纲要很快就会出台 2018-11-21
  • 亚冠出局恒大国脚日落西山 新生代无人难再称霸中超 2018-11-16
  • “藏族院士”多吉:大自然是慷慨的,也是有原则的 2018-11-16
  • 都以为机器人普及了,一切都不是问题了?机器人不需要不断升级?机器人生产啥?不需要人设计? 2018-11-04
  • 无业已婚男假冒“飞行员” 空降婚恋网骗多名女孩 2018-11-04
  • 请问,建立市场经济后,原计划经济哪里去?改革后,我们还在实行计划经济,为何没有提及? 2018-10-12
  • 端午出游自驾 三个不得不知的急救知识 2018-10-12
  • 423| 349| 394| 843| 976| 605| 893| 133| 503| 294|