DISCLAIMER: The information provided in this article, other knowledge base articles, and the Compliancy Group website do not, and are not intended to, constitute legal advice. All information, content, and materials in the Knowledge Base and on the Compliancy Group website are for general informational purposes only.
What is Encryption?
The HIPAA Security Rule defines encryption as “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.”
This article will explore the various types of encryption, and encryption best practices in the context of HIPAA.
Where is Encryption Mentioned in the HIPAA Security Rule?
Encryption is mentioned twice in the HIPAA Security Rule. Each mention is in the “Technical Safeguards” requirement of that rule (45 CFR 164.312), and appears as a measure, or implementation specification, to be implemented:
The first mention is in the Technical Safeguard “access controls” standard. To implement access controls, covered associates and business associates must, among other measures, implement:
(iv) Encryption and decryption: Implement a mechanism to encrypt and decrypt electronic protected health information. (45 CFR 164.312(a)(2)(iv)).
The second mention is in the Technical Safeguard “transmission security” standard. To implement transmission security, covered entities and business associates must, among other measures, implement:
(ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. (45 CFR 164.312(e)(2)(ii)).
What are the Types of Encryption?
There are several types of encryption. These include:
1. End-to-End Encryption (E2EE)
End-to-end encryption (E2EE) safeguards the privacy of messages exchanged by individuals. E2EE prevents others from accessing the cryptographic keys needed to communicate. An encryption key is a string of bits (data) that is used to encode and decode data using cryptographic algorithms. A cryptographic algorithm, also known as a cipher or encryption algorithm, is a mathematical procedure that transforms data into an unreadable format to protect it and ensure its secrecy. This process is called encryption.
Some common encryption algorithms used in E2EE include:
a. Advanced Encryption Standard (AES). AES is a strong and secure encryption standard that uses a symmetric key algorithm, where the same key is used to encrypt and decrypt data. It uses 128-, 192-, or 256-bit keys to encrypt and decrypt data
b. RSA Encryption Algorithm. RSA is Commonly used to secure internet communications, such as email.
c. Asymmetric encryption. In asymmetric encryption, the sender uses a public key to encrypt messages, and the recipient uses a unique private key to decrypt them
d. Public key encryption. Public key encryption works through the use of two keys, a public key and a private key. Data encrypted with the public key can only be decrypted with the private key.
Let’s take a look at how end-to-end encryption works, using public key encryption as an example.
The process of “public key” end-to-end encryption works as follows:
a. The sender begins the process by encrypting the message locally on their device, using the public key of the recipient (a public key is a large numerical value that is used to encrypt data or verify signatures. It is one of two keys in a key pair, the other being the private key, which is only known to the owner).
b. The recipient receives the message on their device.
c. The recipient then decrypts the message using their private key.
d. The recipient then reads the message.
Through this process, all encryption and decryption take place on the users’ devices. Therefore, there is no opportunity for an intermediary to read user data.
What are the Benefits of End-to-End Encryption?
Using end-to-end encryption prevents an intermediary between two communicating parties from intercepting a communication. End-to-end encryption therefore protects the privacy of email messages as well as communications made through applications such as Zoom.
2. SSL and TLS
SSL (Secure Socket Layer) is a technology that applications or browsers can use to create a secure, encrypted communication channel over any network. Since the early days of internet usage, the SSL protocol has been used to encrypt data transferred between a computer and an email server. The presence of SSL is determined by looking at the wording in front of a URL: If the wording is “https” rather than “http,” the SSL protocol is being used. This protocol offers enhanced security; if the address is “http,” the level of protection is lower.
SSL is an older technology that contains some security flaws.
Transport Layer Security (TLS) is the upgraded version of SSL that fixes existing SSL vulnerabilities.
Together, SSL and TLS form a continuously updated protocol series. The protocols are typically referred to as a combined acronym, “SSL/TLS.”
With the SSL/TLS protocol, data is only encrypted between a user’s device and an email server. The email server (e.g., Gmail) has the decryption keys, which are the keys that decrypt the data. SSL/TLS encryption terminates at the server. This means that whoever controls the server can view messages before the message is passed on to the intended recipient.
In contrast, with E2EE, there is no “intermediary” (i.e., service controller) with end-to-end encryption that can read the message. With end-to-end encryption, the data is encrypted on the sender’s system. This allows only the intended recipient to decrypt and read the message. No one “in-between” can read the message, destroy it, or otherwise tamper with it.
What is Open SecureShell (OpenSSH)?
Open SecureShell (OpenSSH) is a collection of open-source tools based on the Secure Shell (SSH) protocol. Open SecureShell enables secure remote logins and network services. OpenSSH is used by Linux and other non-Windows administrators to manage remote systems across platforms. OpenSSH encrypts communication over networks and includes features such as cryptographic host key verification.
Under HIPAA, When Should PHI be Encrypted?
It is a HIPAA best practice to encrypt ALL communications (those with patients, those with vendors, etc.) that contain PHI/ePHI.
Under the HIPAA Privacy Rule right of access requirement, covered entities may send patients their PHI through unencrypted communications, if and only if the covered entity has first warned the patient of the risk that an unsecured communication may be intercepted, and the patient has then consented to the communication with awareness of the risk.
HIPAA does not have a “consent to unsecured communication” provision other than the one discussed above; as such, communications between providers, between providers and business associates, between business associates, and between HIPAA-covered entities and entities not covered by HIPAA, should be encrypted if it is reasonable and appropriate to do so.
164.312(e)(2)(ii) states that covered entities and business associates should “Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.” It is a best practice to encrypt PHI both when it is stored, and when it is transmitted. When data is stored, the data is “at rest.” PHI “at rest” should be encrypted. PHI should also be encrypted when it is being transmitted from one point to another. When data is being stored, it is “in transit.” PHI “in transit” should also be encrypted.
What are HIPAA Encryption Best Practices?
HIPAA-covered entities can consider using these encryption best practices:
Data-in-Transit
TLS 1.2 or higher is considered the minimum best practice to address encryption for data in transit.
Data-at-Rest
HIPAA-covered entities should encrypt sensitive data at rest on servers, applications, and databases containing sensitive data. Storage-layer encryption, also known as server-side encryption, suffices for this purpose. Additional encryption methods may include application-layer encryption, also known as client-side encryption, where access to the data storage device(s) does not permit access to the plain-text data.
Ultimately, the HIPAA-covered organization must determine what type and level of encryption is sufficient, given its operating environment and existing security posture.
Required v. Addressable
The two HIPAA implementation specifications mentioned above ((164(a)(2)(iv) and 164(e)(2)(ii)) are addressable, as opposed to required.
When a specification is “addressable,” an organization must assess whether the measure is reasonable and appropriate in its specific context. This assessment can be done by conducting a risk assessment. If, through the assessment, it is determined that encryption is reasonable and appropriate, then the organization must implement it. However, if an alternative measure can provide the same or greater level of protection, then that measure can be implemented instead. The organization must document its decision and implement the alternative measure.
Further Reading
https://www.hipaajournal.com/hipaa-compliance-for-saas/
General Cybersecurity Best Practices for Small/Med/Large Healthcare Providers:
https://405d.hhs.gov/Documents/HICP-Main-508.pdf
Small: https://405d.hhs.gov/Documents/tech-vol1-508.pdf
Med/Large: https://405d.hhs.gov/Documents/tech-vol2-508.pdf
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article