HIPAA & Cryptographic Standards

Health Insurance Portability Act (HIPAA)


HIPAA is a federal United States law that governs the handling and safekeeping of health information. Under HIPAA, it is important to maintain the integrity and privacy of such information. This information can be referred to as protected health information (PHI).

It has three broad rules, which include:

  1. The Privacy Rule
  2. The Security Rule
  3. The Breach Notification Rule

The most involved is the security rule, which has different safeguards you must abide to.

The security rule deals with all electronic PHI, and requires documentation of procedures and policies taken to enforce the safeguards. The safeguards include the technical safeguards, the administrative safeguards, and the physical safeguards.

I will be writing about the technical safeguards under the security rule, which includes:

  • Access Controls Are only those that have been granted access to stored data allowed to access it?

  • Audit Controls Are you keeping logs from the application and backend? Can they be tampered with, and who can access them? How long are they stored for?

  • Integrity Controls Do you have integrity checking for stored PHI?

  • Person/Entity Authentication How is authentication handled? Are users that access your application or backend who they claim to be?

  • Transmission Security Are communications encrypted in transit? Can you ensure the integrity of the data being sent and received?

Technical Safeguards Specifics


Access Controls

To prevent unauthorized users from accessing PHI, we can encrypt it. Only those with the key can then proceed to read the data. Keeping the key used for encryption secret is then necessary for access control standards to be met.

Options include full disk encryption, but you can be more specific such as volume, folder, or file encryption. An example of an encryption algorithm would be AES, or Triple-DES.

Audit Controls

It is necessary to audit and make logs of your application and your backend. Log files should be safe from malicious modifications or destruction. There should be documentation regarding these controls, such as how long they are stored for and who can access them.

Logs can also be encrypted to prevent access to users without the key.

Integrity Controls

Some options include a hash or a message authentication code (MAC). These will both provide integrity to data. Hash-based MACs (HMAC) which combine a secret key and a hash function to produce a hash can provide authentication and integrity. Examples include HMAC-SHA1 and HMAC-SHA256.

A lot of storage services will provide this service for your data automatically. For example, AWS S3 provides integrity checking for data.

Person/Entity Authentication

A digital signature algorithm and a hash function can be used to authenticate users. Some examples include: RSA, DSA, ECDSA.

Transmission Security

To ensure transmission security, you should use the latest version of TLS. TLS will provide integrity of data between application and backend, as well as encrypt all data being transmitted.

National Institute of Standards and Technology (NIST)


The NIST deals with many standards for technology, including cryptography. The Computer Security Division (CSD) and the Applied Cybersecurity Division (ACD) both work towards these goals. The CSD does research and development to provide standards and tools among other resources related to data privacy and security.

Encryption

A cryptographic encryption algorithm is normally based on a shared key which is used to encrypt and decrypt a message. In some cases different keys are used to encrypt and decrypt data, such as with RSA mentioned earlier.

  • DES A symmetric-key algorithm that was once the industry standard. It is now considered insecure due to the fact that a brute force attack is possible. Although it was once an industry standard and helped influence future encryption algorithms, it should be avoided due to its current vulnerabilities.

  • Triple-DES The problem with DES was that it had a small key (56-bits). By encrypting 3 times over with different keys we can achieve a key with 168 independent bits, which makes brute forcing Triple-DES currently computationally infeasible. It is still recommended you use AES over Triple-DES. DES was designed for performance in hardware and can run poorly on software implementations.

  • AES A symmetric-key algorithm to replace DES. It can use key lengths of 128, 192, and 256 bits. It is currently recommended algorithm for encryption for US federal organizations. Although AES and DES are both symmetric block cipher algorithms, the increase in the key length and the larger block size makes AES secure and it should be used over DES and Triple-DES.

  • RSA An industry standard asymmetric-key algorithm. A user can publish their public key, and anyone wishing to send them a encrypted message can encrypt it using that public key. The user can then decrypt any message encrypted with the public key with their private key which they keep to themselves (hence the private key). RSA is good for digital signatures and key exchanges. A key length of at least 2048 bits is recommended for RSA.

Hashes

A cryptographic hashing algorithm maps a data of arbitrary size and gives a fixed length hash value. Hashes are one-way functions, which means you can not go from the hash value back to the data input. Other names given to the hash include message digest, digests, and hash value.

One useful application of hashes is for storing passwords into a database. If the contents of the database are leaked, the hashed values do not reveal the users actual password. To find their password they would have to brute force a hashing algorithm to hash every possible password and compare the output to what is in the database.

To prevent password hashes being equivalent (if the same users have the same password) normally a randomly generated salt (random data) is also added to their password before being run through the hashing algorithm to produce unique hash values for all data.

  • MD5 MD5 produces a 128-bit hash value. It is no longer used as a cryptographic hash function, as it has many vulnerabilities. It still has wide-spread use as a checksum to verify data integrity. Since MD5 is vulnerable, if you use it for data integrity make sure it is NOT to check if it was tampered with, but if there was corruption (such as when downloading). Either way, the only benefit MD5 would have over other hashes is the fact that is less computationally expensive.

  • SHA-1 The Secure Hash Algorithm 1 (SHA-1) is a cryptographic hash function. It was quite widely used in the past, but it is no longer safe as it can feasibly be attacked with enough computational power. SHA-2 improves on this.

  • SHA-2 The Secure Hash Algorithm 2 (SHA-2) is the successor of SHA-1, which was deemed insecure. As of now, there have been no demonstrated attacks regarding SHA-2. It is one of the standards for hashing algorithms.

  • SHA-3 The Secure Hash Algorithm 3 (SHA-3) was not made to replace SHA-2, but since MD5 and SHA-1 were eventually unsafe, work on SHA-3 began early in anticipation of possible vulnerabilities in SHA-2. Since SHA-2 has been free of any attacks, SHA-3 is more of a back-up plan and also just became as standard in August, 2015.


There are many encryption algorithms and I have only gone over a few here, I recommend keeping up to date with cryptography, and making sure you stay up to date on possible vulnerabilities with current cryptographic algorithms.

Using a longer key length for your encryption algorithms will cause the possible number of keys to increase, in turn causing possible brute force attacks computationally infeasible or ineffective. Make sure to check that the key length you are using is long enough to prevent brute force attacks.

Lastly, if you do not have a need for stored PHI anymore, it is best to delete it. There is no reason to leave potentially harmful information stored, in the wrong hands, if you no longer need it.

Share Comments
comments powered by Disqus