Email encryption is essentially a compliance requirement in U.S. healthcare.
Yes, it's possible to have patients sign a waiver to receive sensitive information via unencrypted email, but it's hard to track when dealing with large numbers of patients. In addition, covered entities still need to encrypt email when sending protected health information (PHI) to other covered entities and business associates. In fact, encryption is a central component of HIPAA compliant email.
When it comes to email attachments, there's some confusion as to what encryption methods will encrypt them and which ones won't. For example, not all encryption methods encrypt email headers. Is the same true for attachments?
As such, this post will answer the question: What types of encryption methods encrypt email attachments?
Transport Layer Security (TLS) and email attachments
Transport Layer Security, or TLS, is an encryption protocol that's used to secure the communication channel between both email clients and email servers.
When an email attachment is sent over a modern TLS connection, the data is encrypted in transit, making it impossible for bad actors to decipher the content.
There's a couple caveats with TLS when it comes to encrypting email attachments:
- As of today, only TLS 1.2 and 1.3 are considered secure. TLS 1.0 and 1.1 are not secure. The same is true with SSL v3 and SSL v2, which are predecessors to TLS.
- If the recipient mail server is not setup to accept to TLS email via STARTTLS, the email is automatically downgraded to clear text and is sent unencrypted over the internet. This is because the email protocol (SMTP) was designed with message delivery as its highest priority. Message encryption is a lower priority with SMTP. Our deep domain expertise in email security resulted in our first patent to directly address this issue.
See related: Paubox eliminates obsolete TLS protocols, follows NSA guidance
Pretty Good Privacy (PGP) and email attachments
PGP, or Pretty Good Privacy, uses public key cryptography to encrypt email messages and attachments. The sender uses the recipient's public key to encrypt the email and the recipient uses their private key to decrypt it. In theory, this method ensures that only the recipient can read the email and that the content remains secure even if the email is intercepted by a third party. As we’ll see, PGP can no longer make this case.
However, there are considerable caveats to using PGP for encrypting email attachments:
- Security. PGP has been criticized for having numerous security vulnerabilities in the past, which has led to organizations to be hesitant adopting it.
- Complexity. PGP requires users to generate and manage their own public and private keys, which can be a complex and time-consuming process for non-technical users. In addition, each recipient's public key needs to be installed on every device used to check email.
- Lack of Integration. PGP requires additional software and plugins to be installed in order to work with most email clients, which is a barrier to adoption.
- Ease of use. PGP is not as user-friendly as some other encryption methods, which makes it far less adopted.
Learn more: PGP and S/MIME aren’t as secure as you think
See also: What does seamless encryption mean? Hint: It’s not PGP
S/MIME and email attachments
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of MIME data, which includes email attachments.
S/MIME requires both the sender and the recipient to have a digital certificate, which is used to encrypt and sign the message.
As with PGP, S/MIME has legitimate caveats when it comes to encrypting email attachments:
- Security concerns. S/MIME also shares criticisms for having its share of security vulnerabilities. For example, EFAIL garnered a lot of attention in 2018 when it was revealed both PGP and S/MIME could be defeated.
- Complexity and ease of use. As with PGP, S/MIME is difficult to setup and use. This is especially true in larger organizations. This is precisely why most of us cannot remember the last (or first) time we've received an S/MIME encrypted email attachment.
Password-protected ZIP files
We've saved the least effective method of encrypting email attachments for last: password-protected zip files.
This method involves compressing an attachment into a ZIP file and setting a password. The password must then be shared with the recipient, who can use it to extract the attachment(s) from the ZIP file. This method is simple and widely used, but it does not provide nearly the same level of security as other methods.
Here are the downsides to using password-protected zip files to encrypt email attachments:
- The password can be easily shared, intercepted, or cracked. A cursory search on google reveals an abundance of tools to break password-protected PDF documents.
- Some types of password-protected zip files can't be opened on Windows computers.
In our opinion, relying on password-protected zip attachments to achieve HIPAA compliance is an unnecessary risk.
When choosing an encryption method for email attachments, it's important to balance security with ease of use. In our opinion, that balance is met with TLS encryption, provided you can ensure TLS encryption is always supported. That's precisely what we've done with Paubox and its patented approach to HIPAA compliant email.