Cyber incidents are one of the most significant risks for companies. Encrypted communication is an important contribution to the prevention of cyber incidents and data breaches. Especially email communication.
S/MIME and PGP are the best-known and most "common" solutions for email encryption. Both methods have existed since the 1990s, but to date they have not been able to gain widespread acceptance, either in the private sphere or in business correspondence.
For companies, email is still the communication medium of choice and it is impossible to imagine today's business world without it. After all, it is the medium that everyone knows and uses.
However, for business communication that regularly contains sensitive data, email must first be made secure. This is achieved with encryption. It enables companies to protect their most valuable resource – their own data – from unauthorised access.
Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.
Edward Snowden, US Whistleblower
Companies therefore need email encryption – and with S/MIME and PGP, solutions for this purpose have been available for decades. But despite this, neither method has been able to support companies in encrypting their business communication across the board. How can this be?
The reason becomes clear when you take a closer look at how S/MIME and PGP actually work and what business requirements they fulfil.
First of all, it is important to know that the email encryption methods S/MIME and PGP are not compatible with each other. In order to protect their own emails by encrypting them with S/MIME or PGP, enterprises or users must first decide which method they want to use– and then clarify whether they can do so with their respective contact partner. It may therefore be necessary to make the extra effort to use both encryption methods in parallel.
What makes the use of S/MIME and PGP even more difficult in the private sector is that there is no "one S/MIME" or "one PGP" that can be used for email encryption. Email is used in many forms: there are email programmes that can be installed on an operating system directly as well as internet browsers that can access various email clients. The actual integration of email encryption with S/MIME and PGP depends on the individual circumstances of the person who wants to encrypt. Unfortunately, there is no one way that everyone can use S/MIME and PGP for email encryption, meaning these do not provide a uniform solution for all users.
For end users, email encryption simply needs to work. This means that it must be possible to send encrypted messages without in-depth technical knowledge or preconditions. Ideally, the user should have to do as little as possible for this themself; after all, not everyone is an IT administrator. S/MIME and PGP have clear shortcomings for the end user, particularly concerning the critical point of user-friendliness. This is because of the way these two encryption methods work and also because of all the things the user has to do to set them up.
Even with solutions for S/MIME and PGP specifically for the use of encryption in enterprises, there are differences in the concrete design and the scope of functions. For companies, however, the requirements go even further. They too need a solution for protected business communication that is easy to use and maintains email as a popular medium for their workforce as well as their communication partners. For this, it is crucial that the gain in security is not at the expense of usability. Any security solution can only be implemented effectively throughout the company if users first accept and then use it. Even the smallest hurdle in its application is often too high and can cause even the best technical solution to fail, so it really can't be simple enough.
In the modern business world, however, communication from and with enterprises also has major intersections with areas such as data protection, IT security, compliance, the automation of communication processes, etc. With this comes requirements and needs that go far beyond mere encryption and demand a lot more from communication solutions. Many solutions for companies that provide email security by means of common email encryption methods are more user-friendly than S/MIME and PGP are for private use. However, they fall short and do not provide the added value that makes the difference for today's business communication.
S/MIME ("Secure Multipurpose Internet Mail Extension") was developed in 1995 and defined in 1999. With this procedure, messages can be encrypted and signed so that their content cannot be read by unauthorised third parties, and the recipient knows that the specified sender is in fact the one who sent the message. It can be individually determined whether a message is to be encrypted and/or signed. Nowadays, S/MIME is supported by most email clients and does not require any additional software installation for private use. To use email encryption with S/MIME, two things are required:
- The X.509 certificate must be obtained for the user in question.
- This certificate must then be integrated into the respective email client of the user.
In the actual implementation, however, there are still a few intermediate steps for both of these points, which must be successfully completed by the respective user.
Nowadays, the use of S/MIME in enterprises is mostly done via special business solutions from third-party providers. The concrete implementation of such solutions for email encryption, which function on the basis of S/MIME, depends on the given circumstances and is carried out by the IT experts, usually the respective admin.
Encryption with S/MIME works with key pairs. Each communication partner has a public and a private key, which makes this an asymmetric encryption method as both parties use different keys. The encryption is carried out by the sender, who encodes the message by means of a session key; this takes place within the framework of a symmetrical encryption. The session key is then encrypted asymmetrically with the recipient's public key. Since both symmetric encryption (with the session key) and asymmetric encryption (with the public key) are used in this procedure, S/MIME is referred to as hybrid encryption.
During decryption, the recipient decodes the encrypted message with their private key. To ensure that no one else can do this, it is therefore important to store the private key carefully and to make sure that no one has access to it.
Signing emails serves to authenticate the identity of the sender and simultaneously transmits the sender's public key to the recipient. This enables the recipient to verify beyond doubt whether the email really comes from the specified sender. In the corporate environment, this is therefore particularly interesting for the defence against phishing attacks. With S/MIME, a unique signature is added to an email to be sent using the sender's private key. On the recipient's side, the signature is then checked using the sender's public key. If something is wrong, the recipient is notified and must assume that the message has been tampered with.
For encrypted email communication with S/MIME, the desired email communication partners must know the public key. This works on the one hand, as already mentioned, via the signature: with this, the public key of the sender is transmitted to the recipient at the same time. In addition to the possibility of transmitting the public key directly to the relevant contacts, it can also be uploaded to an external key server. Other methods include publishing the key on a website or transmission in physical form, for example on a USB stick. In practice, however, the latter is unusual and rather inconvenient. The public key is then used to encrypt all emails to the key holder. S/MIME does not work without the exchange of public keys.
Emails encrypted with S/MIME are then decrypted with the private key of the recipient. This decrypts the session key, which can then be used to decrypt the encrypted message.
The private key must therefore only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just an email or the correspondence with one contact partner, but everything.
For the use of S/MIME for email encryption, an X.509 certificate is required. Private users can obtain this from various providers or generate one themselves. The latter option is free of charge but quite time-consuming, as you have to make sure that your own certificate is accepted. It is then necessary to first create a so-called root certificate, which all contact partners must import for the email exchange before the public keys are finally exchanged. Typically, recognised certification authorities are therefore used to obtain certificates.
Certification authorities offer the advantage of ensuring that public keys and their owners really belong together, meaning that the key belongs to the intended recipient and that an email actually originates from the specified sender. This is an advantage over PGP, where this certainty does not exist in this form.
There are different classes for certificates; the class to which a certificate belongs depends on how the person who wants to obtain the certificate is checked:
- Class 1: the existence of specified email address is verified.
- Class 2: in addition to the email address, the name and, if applicable, the company are confirmed in writing.
- Class 3: the certificate holder must authenticate their identity, e.g. with the help of an identity card.
- Class 4: the certificate holder proves their identity by appearing in person at the respective certification authority. This would be the most secure way to authenticate identity, but it is impractical and expensive and therefore not an option that is actually used in practice.
These classes have no effect on the security of email encryption with S/MIME certificates; they only say something about whether/how the applicant for the certificate has confirmed their identity. The certificates are of limited validity, which is usually one year (but there are also those that are valid for longer). In order to be able to use S/MIME permanently and reliably, it is therefore absolutely necessary to ensure that you always have a currently valid certificate.
For the successful issue of a certificate, a number of provider-specific steps must be completed. After the certificate has been successfully issued, it can usually be downloaded or the private user receives an email which contains the corresponding URL where it can be retrieved.
Overall, setting up S/MIME is easier to implement than PGP. In recent years, technical requirements have been created to support S/MIME in various configurations.
S/MIME in an email client
After the S/MIME certificate has been obtained, a personal certificate must be generated and then installed. Next, the necessary settings must be made in the email client so that it uses S/MIME with the help of the corresponding certificate. Usually, the email client is restarted after the configuration is complete.
If you do not have Microsoft Office/Outlook, you can use the free email client Thunderbird to encrypt emails with S/MIME. However, this must first be installed, and the user account configured. Only then can the following steps be taken to set up S/MIME:
- Generate S/MIME certificate: either create the certificate yourself or obtain a certificate from an official certification authority. For the latter, you can use free or fee-based providers. However, it is essential to make sure that the provider is credible!
- Enter the email address for which the certificate is to be issued
- Carry out the provider-specific steps to create the certificate; this will then be sent to the specified email address
- Save the personal password for using the certificate or print it out if necessary
- Download the certificate from the email inbox and store it in the desired location
- Open the account settings in the Thunderbird email client and select "Manage certificates" in the "Security" menu
- Import the certificate under "Your certificates"; for this, the corresponding password must be entered
After going through all these steps, emails can now be signed and encrypted with S/MIME in Thunderbird via the security menu. It is also possible to set signing and encryption as the default for sending emails.
Apple end devices with their "Mail" client are inherently capable of using S/MIME for email encryption. This makes it easier for users, as they therefore do not need to install any additional software and can obtain the necessary certificate straightaway. The creation of this certificate also works here by calling up the website of the desired certificate provider and the user entering the required data (see procedure for Windows). The certificate must then be downloaded and stored in a suitable location. It can then be opened and inserted into the keychain administration. Last but not least, a restart of the email programme is necessary to complete the setup of S/MIME. If the email encryption with S/MIME is also to be used on mobile devices, i.e. on the iPhone or iPad, the certificate must be converted from the .p7s format to the .p12 format. This can be done via the keychain administration. The certificate in the new format is then sent by email to the desired end devices.
In order to use S/MIME on Android, an appropriate certificate must first be obtained (for a description of this procedure, see the section on S/MIME for Windows). However, setting up S/MIME for Android is more complicated than for Apple.
For the integration of S/MIME, users are dependent on applications that can be obtained from the Google Play Store. There are also free options for this; however, with these you have to anticipate advertising. Plug-ins are also often needed to import certificates. These can also be downloaded from the Google Play Store. After successfully importing the certificate, the respective S/MIME settings can finally be made in the application.
When you briefly estimate how many employees would have to set up S/MIME manually – and how many of their contact partners would potentially have to do the same – does this sound like a practicable solution for everyday business in companies? Hardly! Not to mention the hurdles in the actual use of S/MIME for email encryption.
There are various providers on the market who have specialised in the use of S/MIME for email encryption in companies. Their solutions reduce the workload for their corporate customers that the respective company's own admin would otherwise have had when setting up S/MIME for the staff independently and manually. As a rule, such products are gateway solutions; otherwise, the use of S/MIME would be very costly. In addition, much of this would then also take place at the individual user level. This would be critical, however, as there would be a great dependence on correct user behaviour and the admin would thus have fewer opportunities to exert centralised influence with regard to IT security and compliance.
A mail gateway has the advantage that the administrator has leeway for a company-specific configuration. For example, they can connect archiving for their own company or centrally define encryption. At the same time, however, despite the use of S/MIME, this no longer represents end-to-end encryption because there is no encryption from the sender to the gateway for the email. As a concrete example: from Outlook to the Exchange Server, it would be a completely ordinary (and thus unencrypted) email.
Implementation takes less time with such S/MIME solutions and usability for end users is better than it is with "regular S/MIME", such as in the private sector.
- Size restrictions for file attachments
Often, it is not the messages themselves but rather the attached files that contain the data worth protecting and requiring encryption. This quickly results in file sizes of more than 25 MB. However, operating within a regular email infrastructure, such files are too large for mail servers and thus cannot be transmitted in encrypted form between sender and recipient. Some of the S/MIME solutions do have additional modules for the transfer of large files that can be added – but this is usually associated with an extra charge.
- Ad hoc
Even if different S/MIME solutions work together and encryption takes place: all those who do not use S/MIME (and this is still the clear majority) are left out and excluded from ad hoc communication. There are alternative approaches for recipients without S/MIME, e.g. making the message available in a web mailer; but here the recipient must first log in with a username and password. This creates another hurdle, which is detrimental to usability on the recipient's side. *
- Static key pairs
S/MIME solutions use static key pairs: the public key is used for encryption and the private key for decryption. These do not change during their entire period of validity and remain the same for all correspondence. If a private key is compromised and third parties have access to the business correspondence, not only can one email from the person concerned be viewed but also retroactively all data that can be decrypted with the compromised key. If the user is unaware of the unauthorised access, even all future incoming messages and files will be affected until a new key is used.
- Metadata such as the subject line are transmitted unencrypted
While messages with S/MIME are protected by encryption in transmission, metadata such as the subject line is excluded from this. But even subject lines contain data worthy of protection, which, especially when aggregated, allows valuable and personal conclusions to be drawn. These can be misused, for example in social engineering attacks.
*Of note for recipients without S/MIME: For incoming and outgoing emails via portal solutions, meaning those outside an email inbox, the company's own archiving is not connected. If, for example, emails are to be archived on the recipient's side, this must be done manually each time by the respective user, which the administrator has no influence over. This can pose major problems for a company's compliance.
With the solutions offered by various providers, email encryption for companies is becoming more practical – in setting up S/MIME for the admin as well as in using encryption for users in the workforce.
Nevertheless, it is important to realise that there are also significant shortcomings. Secure digital communication for companies reaches its limits, even with S/MIME solutions, when it comes to simple ad hoc exchanges with anyone where everything transmitted is encrypted – including subject lines and large files. In addition, all communication partners must use a solution based on S/MIME so that the encrypted exchange of mails also functions without hurdles. Contacts who do not use S/MIME are left out in the cold and suffer noticeable disadvantages.
Encryption on the basis of S/MIME thus means that encrypted emails can no longer be exchanged
- between anyone
- at any time and
Thus, encryption ultimately becomes a hurdle to usability after all. This, however, means that email loses a great deal of its most important feature.
The use of communication solutions that remain in the email infrastructure in their approach also entails potential risks from man-in-the-middle attacks. This is because even if emails are protected in transfer with SSL/TLS, they are unencrypted on the mail servers en route. Added to this are the size limitations of the mail server when sending and receiving files and the fact that redundancies often arise in data storage. Thus, the mail server quickly degenerates into a data graveyard, which results in additional costs for the company. In addition, there is significant potential for GDPR violations if the overview of which data is stored where and for how long is lost.
Compliance is a particularly important area, in combination with the increasing automation of communication processes and adaptability to company-specific IT security, where modern communication solutions must offer enterprises added value. Here, however, many S/MIME solutions often fall short.
What about email encryption using PGP, how does this method compare in terms of acquisition and set-up? And what steps are needed in order to use PGP to encrypt email communication?
PGP ("Pretty Good Privacy") was developed as early as 1991. With this method, messages, including emails, can be encrypted and/or signed. Encryption prevents the messages from being read by unauthorised third parties. The signature ensures that the message is authentic, i.e. that it really comes from the sender, and that its integrity is given, i.e. that it has not been changed or replaced after signing.
With PGP, the encryption process works with key pairs consisting of a public and a private key for each communication partner. Since both parties use different keys, this is basically an asymmetric encryption method. However, these procedures require a lot of computing power, which is why the entire message is not encoded with the public key. The encryption is done with so-called session keys, which are symmetrical and are created randomly and each time anew. The session key is then asymmetrically encrypted with the recipient's public key and appended to the sent message. In this way, the required computing power can be noticeably reduced, which is particularly important when sending messages to multiple recipients. Through the combination of asymmetric encryption (with public keys) and symmetric encryption (with session keys), PGP is a hybrid encryption.
When signing with PGP, a unique fingerprint is generated from the plain text of the respective message by a cryptological hash function (SHA-256), which is then encrypted with the sender's private key and appended to the message. The recipient can then use the sender's public key to check whether the message actually is from the sender or whether it has been manipulated by a third party.
For encrypted email communication to take place at all, the desired email communication partners must know the public key. Therefore, it is necessary to either transmit it directly to the respective contacts or to upload it to an external key server. The public key is then used to encrypt all emails to the key holder. The exchange of public keys is an essential component without which PGP would not work. This process requires – depending on which form of PGP is used – some intermediate steps that have to be carried out for each individual communication partner.
However, since it is possible for a person with a public key to impersonate someone else, it requires verification of the authenticity of that key.
For verification of key authenticity, PGP uses a decentralised approach, the so-called "web of trust". This is based on participants in the web of trust who express their trust in each other and confirm that public keys belong to specified owners by signing them. This is therefore a manual process without a central authority. With GnuPG, a free encryption system that conforms to the OpenPGP standard, the software itself determines the trustworthiness of a key. If existing signatures of a public key have already been made by users who are credible in the web of trust, the corresponding degree of trustworthiness is derived from this. The more the corresponding users are trusted, the higher the degree of credibility for the key that was classified as trustworthy by them. Each signing of a key creates a certificate (which acts as a digital confirmation). Each certificate that a public key receives from the participants in the web of trust is then attached to it. The more such certificates a key receives, the greater the certainty that the key and the stated owner really belong together.
However, all of this requires prior technical knowledge on the part of the users and is neither easy nor intuitive to handle for those less experienced. Moreover, public keys are also linked to personal data. The signatures of keys by other people contain a list of all those who have checked it and confirmed the identity of the key holder. In terms of data protection, this is an aspect that users should be aware of. And as far as data sovereignty is concerned, there is a restriction for PGP users: once public keys have been uploaded to a key server, they can no longer be deleted. Since key servers synchronise globally with each other, uploaded keys can quickly be accessed everywhere (regardless of who uploaded them and regardless of whether they are in fact the owners of the keys). This means that the corresponding email address is published as well and can be found by anyone. After uploading to a key server, users in the web of trust consequently no longer have any influence on the dissemination of the data.
The encrypted emails are decrypted with the private key; this must only be known to its owner and must also be protected by a password. If the private key should fall into the hands of a third party, the entire communication for which this key was used is affected. This means not just one email or the correspondence with one contact partner, but everything.
In order to install and use PGP on your own system, the following steps must be completed:
- Install the appropriate PGP software (available for purchase or free of charge) for your operating system and email client
- Generate a public and a private key; the concrete design of this part differs depending on the operating system and sometimes requires some intermediate steps. For Linux, it is necessary to do the following:
- Enter the corresponding command in the command line
- Select the type of encryption
- Specify the key length in bits
- Specify the validity period of the keys as well as the name and email address for which the keys are to be valid
- Define a so-called passphrase for the private key
- Upload the public key to a key server or forward it by email to all contacts with whom encrypted communication is to take place
- Keep the private key safe, i.e. store it locally on your device and protect it with a password (e.g. in a password manager).
- Ensure that all communication partners also use PGP and share their public key
- Check the trustworthiness of the public keys of contact partners
There is also the option of using online PGP tools. There, key pairs can be generated, and emails can be encrypted or decrypted. Free open-source services are available for this, which run in web browsers and do not require registration. Although the handling is somewhat simpler in comparison, there are also some steps to go through. The following parameters must be determined in order to set the appropriate keys:
- Name and email address for the keys to be applied
- Preferred key algorithm
- Key length
- Validity period of the keys
- Passphrase for the private key
Once all this has been determined, the keys can be generated and downloaded.
Users of various webmail services, such as Web.de or GMX in Germany, can send emails and attached files using end-to-end encryption. This is based on Mailvelope, a free software for encryption in web browsers that can be integrated into webmail services.
In order to use this function, however, users must first set up encryption. For example, the following steps are necessary at Web.de:
- Download the browser extension from Mailvelope (free of charge)
- Assign a key password
- Set up the backup (to restore the key password and activate the encryption on other devices)
With Mailvelope, encrypted messages can be exchanged not only with other Mailvelope users but also with communication partners who use a different PGP encryption, such as Ggp4win or Thunderbird.
However, nothing works without PGP – all contacts who do not use PGP encryption software are left out. And there is a size limit of 50MB for the encryption of attached files, since you are still within the infrastructures of the email providers.
For those who want to encrypt emails on their smartphone, the use of PGP is unfortunately also quite difficult – because here, too, there is no approach that fits all end devices or operating systems.
Apple does support end-to-end encryption in its iOS operating system, but this only applies to the S/MIME standard. For iPhones and iPads, no other application is possible as a default application besides the in-house email app. No external extensions are permitted for Apple's email client either, so if you want to use PGP, you have to do so via external apps, which often need to be purchased and are not necessarily user-friendly. Even with these, encryption only applies to the content of the sent email – metadata such as recipient and subject line are transferred unprotected and are thus readable.
For email encryption on Android devices, an email client that supports PGP is required as well as software for managing the keys. There are free and paid apps for this.
The actual setup of the email programme varies and depends on which app you have chosen. For the free Squeaky Mail app, the following steps are necessary:
- Install the Squeaky Mail app on the Android device
- Open the Squeaky Mail app
- Use the setup wizard:
- Click Next
- Enter your email address and password
- Click Next
- Label the mailbox with the desired name
- Enter the name with which the emails are to be sent
- Click Done
Now, the key management software must be set up. For the paid programme PGP KeyRing this is done as follows:
- Copy the key pair (which you need to create beforehand!) to the Android device.
Note: You should refrain from doing this by email, as email communication is not yet
encrypted and this transmission path is therefore not secure.
- Import the key pair into PGP KeyRing:
- Open the PGP KeyRing app and insert the private key via the download icon
- Tap on “File” to select a file on the Android device
- Enter the corresponding file path or select the file via the folder icon
- Select the corresponding folder with the key pair in the file manager and tap on the file with the keys
Once all these steps have been completed, the foundation is in place for exchanging encrypted emails with Android end devices. This in turn requires further steps for the user in the actual implementation.
Reading encrypted emails is possible after entering your own secret password. Encrypted messages are sent by selecting the option “Encrypt”, selecting the corresponding keys and finally confirming the entries. However, this only applies to sending to communication partners whose public keys are already known. If the public keys still have to be exchanged between sender and recipient, the whole process is much more complicated and requires numerous steps. For the sake of clarity, these intermediate steps are not formulated in the following list:
- Export your own public key (further intermediate steps required)
- Send your own public key to the desired contact partner (further intermediate steps required)
- Import the contact partner's public key into your own PGP KeyRing (further intermediate steps required)
- Express your trust in the imported public key and select the desired trust level (further intermediate steps required)
Before secure encrypted exchange of emails can begin, the technical prerequisites for this – on both sides – must first be established in numerous steps.
There are implementations that use the OpenPGP standard, such as the free open-source programme GnuPG mentioned earlier. Its advantage lies in being available for standard operating systems such as Windows, Linux, and MacOS X and that it also works on iOS and Android smartphones. While the broader application possibilities of GnuPG are a relief, they do not cover everything – for Windows Phones, for example, a different implementation is necessary. There are also other specialised products, such as Gpg4win for Windows, gpg4go for Outlook 2010, GPGtools for MacOS, or Enigmail for Thunderbird.
Over the years, PGP encryption has undoubtedly been repeatedly adapted to meet technical circumstances and requirements. For the user, however, none of this has translated into the same degree of usability: it is still rather complex and does not provide a great user experience, which is why PGP's successful breakthrough for widespread use has not happened.
Let PGP die!
Jürgen Schmidt, Senior Editor & Senior Fellow Security at heise Security (2015 editorial)
Even though PGP has been further developed and improved over the years, for the vast majority of users it simply remains too technical a solution with a multitude of requirements for the end user. It prevents the suitability for mass adoption if the entire key management – which is very time-consuming with PGP – is passed on to the user. For this reason, PGP is more of a community solution that is used among the IT-savvy and in the private sphere.
If you want to use PGP for email encryption with your communication partners, you have to do a lot of preliminary work:
- It already requires solid technical knowledge to even be able to correctly determine which concrete PGP solution is required by your own IT requirements
- Implementation still causes considerable effort
- If the contact partners are not prepared to go to all the trouble and expense, your own efforts will have been in vain
- Those who rely on PGP must also ensure (after their own complex PGP setup) that all necessary external contacts do likewise
Taking the route of a manual setup would mean an enormous amount of work for the IT department of any company. After all, as the effort clearly shows, you can't just leave your own employees to set up PGP on their own. Rather, it is necessary to conduct training for the entire staff on the correct handling of this email encryption method and to accompany the implementation of PGP.
It is important to remember that the steps described above must be carried out for each individual email address of an enterprise! However, since PGP does not work if it is only used by one side, this is only half the battle. The external contacts with whom communication is to take place must also use PGP successfully – obviously, something that your own company's IT has no influence on.
- Setting up PGP manually requires the purchase of additional software (often for a fee). In order to avoid potential security risks, it must therefore be ensured in advance that the additional software is from reputable providers
- In this case, it is necessary to calculate the time and costs involved in the installation as well as the training of the entire staff
- PGP is prone to user error due to its high complexity and poor usability. This is a high risk, especially for a company's data protection and compliance
Corporate solutions that rely on PGP for the encryption of email content do exist – but they are much less common than those based on S/MIME. With PGP in particular, despite further developments such as OpenPGP and gnupg, usability is still the biggest hurdle standing in the way of successful application in everyday business.
Although there are approaches to PGP solutions from third-party providers that make installation and use easier, this is usually at the expense of security. For example, if a key can be created in a browser and email can be encrypted there, then this process no longer has to take place in the email client. On the one hand, this is easier to handle; on the other hand, however, it also results in the private key not being stored on the user's computer, but with a third-party provider. This provider thus holds the proverbial key to the entire email communication (protected by encryption) – and consequently presents a lucrative target for hacker groups or intelligence agencies.
It is possible to get around this and set up a company-owned key server. In this case, there is more room for a company-specific design of email communication protected by encryption. However, this also requires effort upfront in which correspondingly granular settings have to be made during setup. Companies must be aware of this and clarify important questions in advance:
What, for example, if employees leave the company and their email address continues to receive encrypted emails from external contacts that are important for the company?
As is evident, the enterprise’s admin and IT have to do quite a bit for the security and company-appropriate management of the private keys.
And with all this effort, PGP only secures the information in the email itself. Metadata such as the sender or subject of an email are not included in its encryption. The problem of large and sensitive file attachments is also not or only partially solved. And in the end, encrypted exchange, despite all your efforts, still depends on whether your communication partners also have PGP installed and successfully in use.
Just like S/MIME, PGP is built on the system and infrastructure of email. As such, various basic problems still remain, even with corporate solutions:
- Size restrictions for file attachments
- Ad hoc communication is only possible among PGP users
- Static key pairs remain a potential security risk
Metadata such as the subject line are transferred unencrypted
S/MIME and PGP work within email infrastructure. This brings with it the aforementioned size restrictions for file attachments as specified by mail servers. Another problem, however, lies in the way email and email clients work, and this can jeopardise security – cue "Efail".
In 2018, Efail revealed the possibility of successfully bypassing email encryption with S/MIME and PGP. Researchers found significant security vulnerabilities due to which emails encrypted with S/MIME and PGP could be decrypted and read by third parties. The starting point was the dependence on the way email clients work.
The vulnerabilities that were uncovered in Efail were from man-in-the-middle attacks, which are mainly possible when effective transport encryption such as TLS (Transport Layer Security) is not in place. But even if the encryption takes place on the transmission path with TLS, emails are unencrypted on the mail servers en route. Emails are not transferred directly from sender to recipient, but via intermediate stations (mail servers) which are not easily traceable for communication partners.
This circumstance makes it easier for third parties to intercept emails en route. Intelligence agencies, for example, can intercept emails in this way and store them. Decryption can then be tackled at a later point in time, for example by specifically trying to obtain the private key or when the computing power required for decryption is more readily available.
If an attacker had access to the encrypted email as well as the possibility to send an email (modified by themself) to the recipient, S/MIME and PGP could be successfully bypassed. Through encryption, the contents of emails are initially protected from foreign eyes. However, this protection could be undermined by the way an email client handles emails. In the case of Efail, the clients that usually executed active content by default and reloaded external content were exploited.
One possibility for a successful attack was for third parties to manipulate an encrypted email intercepted en route. This was done by supplementing it with HTML code, which, for example, loaded an image before the email went on to the recipient. On the recipient's end, this email was then decrypted as usual with the recipient's private key. In order to be able to load the image, the regularly configured client (meaning HTML is activated) then sent the decrypted text to the attacker. This vulnerability affected both PGP and S/MIME. Even though the problem with this vulnerability was not the encryption itself, emails were not protected from unauthorised third parties despite the use of S/MIME and PGP. This problem could initially be solved by switching off the loading of external images. However, the approach of switching off HTML as well would have been rather counterproductive, because many things in normal (i.e. unencrypted) emails could no longer be read due to the high HTML distribution.
Another security problem of S/MIME and PGP came to light when so-called "direct exfiltration" was used, which was based on an implementation error of the MIME standard in email clients. In technical terms, the exact procedure is very complex; simplified, it went as follows: intercepted emails were manipulated by implementing certain additions before and after the encrypted text of the email. After some intermediate steps, the decrypted text was finally copied by the recipient's email client into a URL and sent to a server controlled by the attacker. The attacker thus received the decrypted text of the email via the URL.
When taking a closer look at all the steps that must be undertaken to set up and use S/MIME and PGP, it instantly becomes clear why these two methods have not been able to establish themselves in email encryption for private use or for use in enterprises:
- For private use, they are too costly, too technical, and too complex for users
- For use in enterprises, they are time-consuming and cost-intensive, even in the form of encryption solutions from various providers, and their scope of services is limited
Secure communication can thus not take place ad hoc and with ease – and is in most cases reduced to those who also use S/MIME and PGP. In addition, the dependence on email infrastructure and the functioning of email clients not only restricts the scope of services, but can also directly affect security, as noted in Efail.
Email encryption with S/MIME or PGP are therefore not the most viable options for enterprises in practice and have therefore never been able to gain widespread acceptance. Nevertheless, there is still an urgent need for enterprises to have secure digital communication, especially since the requirements of the modern business world go beyond mere encryption.
We need to think about encryption not as this sort of arcane, black art. It's a basic protection.
Edward Snowden, US whistle-blower
The good news is that there are alternatives to S/MIME and PGP that provide secure email encryption and usability as well as offer enterprises significant added value in areas such as compliance and automation.
Email encryption and modern business communication: simply secure – with Cryptshare
Cryptshare for Outlook Teaser
What Cryptshare for Outlook is - in 39 secondsShow more
With S/MIME and PGP, emails are encrypted and secured during transfer, with the exception having been pointed out in Efail. However, the use of S/MIME and PGP does not sufficiently fulfil the very important requirements for modern digital communication and thus does not meet the needs of modern enterprises. This has noticeable disadvantages:
As a widespread form of messaging, email can be used easily and ad hoc by everyone for exchanges with anyone. In B2B and especially in B2C communication, this is of vital importance. This key aspect, however, is completely undermined by the complexity of S/MIME and PGP. Even with a fully set up S/MIME or PGP solution, it is by no means a given that the recipients’ side uses the same solution and that the exchange of encrypted messages via email can thus take place smoothly.
Solutions that are complex for users, such as S/MIME and PGP, run the risk of not being accepted by the staff. Especially when they involve additional tasks for the users. As a result, emails continue to be sent unencrypted in everyday business. Or even more detrimental, users switch to unauthorised (yet easy to handle) alternative solutions, especially if their own communication solution is not used by their contact partners. This results in Shadow IT for enterprises, which includes undermining data security and higher vulnerability to cyberattacks.
Complex solutions that require a technically extensive effort are a nightmare for in-house IT administrators. From roll-out to end user support in day-to-day use, they require considerable training – and still remain prone to user error.
S/MIME and PGP encrypt the content of email messages but information about the subject, sender, and recipient is sent unencrypted. Thus, they can provide hackers with valuable information for social engineering attacks.
Large files that are attached to emails, and often contain very sensitive data, are not protected by S/MIME and PGP and are therefore transmitted unencrypted. The size limit of mail servers for email attachments remains.
As a secure digital transfer service, Cryptshare offers you encryption not only of emails but also of subject lines and file attachments. There is no size limit for your data exchanges, so you can send files with several gigabytes without any problems. All transfer processes are logged, ensuring traceability for your company's compliance.
The retention period of transfers on the Cryptshare Server can be tailored company-specific through an individual configuration so that data graveyards are effectively prevented. This not only helps your compliance with data protection regulations but also saves you money.
What makes Cryptshare special is that, from the beginning, it was designed so truly anyone could use it – intuitively and without deep technical knowledge. Every IT administrator will confirm: effective security only works in combination with high usability!
However, usability does not end with your own staff but also extends to their communication partners: Cryptshare works bidirectionally, which means that all communication partners can not only receive messages and files from the sender, but also send them back. All of this works ad hoc and without any preconditions – internet access and a web browser are all you need to communicate digitally in a secure way.
With Cryptshare, there is no need to:
- Buy and renew certificates
- Exchange keys
- Create and manage user accounts
- Install software
With Cryptshare, your employees continue to benefit from the ease and familiarity of email and can engage in ad hoc exchanges with third parties. Integrations for Outlook and HCL Notes allow staff to securely conduct business communication directly from their own work environment. Thanks to the Cryptshare API, it is also possible to connect Cryptshare directly to in-house tools or to send information generated automatically from system processes. For the recipient of a Cryptshare transfer, it does not matter whether the transfer was sent by a person or a system.
Communicating easily and securely from mobile devices? No problem! With Cryptshare, it doesn't matter whether it is an iPhone, iPad, Android or other end device. Again: no technical preconditions are necessary, and it can be used ad hoc.
For the regular exchange of information with fixed communication partners, you can further increase usability with Cryptshare QUICK Technology. QUICK creates permanent secure connections and, after activation, takes care of all one-time passwords for future transfers between communication partners. Users do not need any help from the administrator and can easily activate QUICK on their own. Afterwards, they do not need to worry about passwords; they automatically communicate in encrypted form. QUICK is convenient security that will save your enterprise valuable time.
For companies with up to 50 employees who are looking for a communication solution that fits their needs, we have created Cryptshare.express: an online model that enables the secure digital exchange of messages and large files. It is ready for use as a service and set-up only takes a few minutes.
Email encryption and large attachments with Outlook
In this video you will learn how easy it is to exchange encrypted email and large files via Outlook with Cryptshare.Show more
Let's assume an employee wants to send an email with personal data. In addition, they have several file attachments that they would like to transfer. These not only contain several gigabytes of data, but also sensitive information. The employee must therefore transmit both the message and the file attachments in encrypted form.
If their employer has opted for the Cryptshare for Outlook integration, all they need to do are these simple steps:
- Select the recipient and compose the email in the Outlook client, as you typically do
- Click on the "Send with Cryptshare" button
- Select the files to be attached to the email
- Click on the regular "Send" button and select the desired transfer settings (e.g., whether the subject of the email should also be encrypted or whether the sender would like to receive a delivery confirmation)
- Click on the "Start Transfer" button
With Cryptshare, the encrypted message and data transfer is reduced to the actual transfer itself. which not only applies to Cryptshare for Outlook but to the Cryptshare for Notes integration as well. Neither the employee nor the recipient side needs to meet any prior technical requirements but can communicate with each other simply and ad hoc. Incidentally, this procedure applies to every email address of every recipient to which the employee wants to send messages or files.
But what if an employee suddenly realises that they have accidentally sent the wrong file or sent the transfer to the wrong recipient? After all, this is a mistake that has happened to almost everyone at some point – and can have very unpleasant consequences: this can mean a GDPR violation or even the loss of a company's intellectual property. Don't worry, because Cryptshare has a solution for this, too! With the revoke feature, this is no longer a risk: even after sending a transfer, the employee as the sender can retroactively block access to erroneously sent files. This allows them to quickly correct their mishap and prevent the accidental loss of data for their company.