TIPS & BEST PRACTICE 02. DEC 2016
Email encryption for recipients without certificates
Should you use alternative delivery methods or
issue certificates yourself?
Encryption with password – proven technology, very user friendly
Not every email address you want to exchange confidential emails with has a detectable valid certificate. In this case, where a secure email gateway is being used, password-based encryption procedures are normally applied to enable quick and secure communication. The recipient receives the confidential message as a password-protected PDF, HTML or ZIP file attachment.
Another common variant of password-based encryption is to provide an HTTPS-protected web inbox which is created on the fly. This allows companies to conduct delay-free encrypted communication with any recipient. Setting up accounts for external users and password management is largely done automatically, with no added workload for employees. To guarantee a high level of security, the PIN required to activate the account can be sent by text message.
Issuing ad hoc certificates – security concerns and practical issues
Another way of communicating confidentially with recipients without certificates is to provide them with an automatically generated certificate. Although this may sound like a viable approach, it needs to be examined in detail.
When sending a confidential email, the sender’s organisation acts as a certification authority (CA) and issues a certificate on the fly for the recipient. With simple certificate managing solutions which do not have access to the mail flow there is no time delay: the complex enrolment process which is normally required is cut short, as the sender also creates the recipient’s private key.
In this way, the recipient gets the encrypted message, the private key and the certificate in quick succession. The problem with this method is that it bypasses the security-related functions of the public key infrastructure (PKI): the private key is no longer secret, as at least one company – the one that issued the key – knows the recipient’s private key. The distribution logic used, namely sending the certificate and the private key together with the confidential email shortly after one another through the same channel, also fails to meet the security requirement of a PKI.
The emergence of unmanageable “certificate zoos”
Another problem to consider if the spontaneous issuing of certificates were to become general practice would be the uncontrolled propagation and dissemination of the ad hoc certificates described above. A PKI participant normally only has one or two certificates, which are used by all their communication partners. It’s a bit like having just one phone number, which all your contacts can use to reach you. But if a large number of companies now create certificates for the recipients of their messages, an individual will be issued with a separate certificate from each of several communication partners. But the certificates are not restricted to use with the communication partners who issued them, so how can the recipient know which key to use and when? If the person to whom the certificate was “donated” regularly signs emails to third parties with the related private key, the dissemination of the certificate will become unstoppable and total chaos will ensue. The CAs required for validation do not exist and help-desk staff at all the companies concerned will be called in but will be unable to help.
Compliance-averse shadow IT
Another problem can occur in the B2B sector in particular if a centrally managed Windows update at the recipient’s end causes all the keys of the local keystore to be lost. As these keys are completely unknown to the company’s central IT department, the keys and certificates cannot be restored. The pseudo PKI which is implanted is part of the “shadow IT”, the use of which presumably also breaches compliance regulations at the donee company.
Frustration among private users
Different problems occur when sending confidential data to end users (B2C). Users have technology forced upon them that they often cannot use. The use of webmail providers is commonplace among private users. The ad hoc provision of certificates is usually restricted to the S/MIME standard, but webmail providers do not support this technology: attempts to communicate this way lead to frustration and delays while a new channel of communication is found.
New role for companies after eIDAS and VDG
The ad hoc issuance of x.509 certificates for external communication partners also imposes upon the company the role of a certification authority. According to the eIDAS regulation, it means a company becomes a trust service in accordance with European law, with all the legal implications that it involves. In Germany, even stricter compliance regulations are currently being formulated with the Vertrauensdienstegesetz (Trust Services Act), which the issuing companies will be subject to.
Conclusion: organised chaos with legal obligations is best avoided!
Even if our encryption products have the basic technical capability to easily issue certificates to third parties, we believe that password-based encryption for recipients without certificates is by far the best option. For exchanging confidential emails quickly and easily, Z1 SecureMail Gateway with Z1 Messenger component is the tried and trusted solution.
