By Kevin Stine and Quynh Dang
Healthcare and health IT professionals are entrusted with protecting the privacy and confidentiality of patient data. To provide this protection, these professionals frequently look to commonly accepted technologies and methodologies to safeguard the data while at rest and in transit. One technology capable of providing this type of protection is encryption.
The HIPAA security rule has long identified encryption (an addressable implementation specification) as a mechanism to safeguard electronic protected health information. More recently, the standards and certification criteria for electronic health records (EHR) specified that EHRs must be able to encrypt and decrypt health information in order to qualify for stage 1 of the meaningful use incentive program.
Similarly, guidance accompanying the breach notification interim final rule identified encryption as one technology that can render protected health information "unusable, unreadable, or indecipherable to unauthorized individuals." Protected health information that is encrypted in accordance with this guidance is not subject to breach notification requirements under the interim final rule. The guidance discusses encryption as a mechanism to protect data in transit and at rest.
Implementing and managing an encryption solution requires an understanding of basic encryption processes, an awareness of the security properties provided by encryption, and knowledge of important requirements for effective encryption.
Encryption Basics
Encryption is a security control used primarily to provide confidentiality protection for data. It is a mathematical transformation to scramble data requiring protection (plaintext) into a form not easily understood by unauthorized people or machines (ciphertext). After being transformed into ciphertext, the plaintext appears random and does not reveal anything about the content of the original data. Once encrypted, no person (or machine) can discern anything about the content of the original data by reading the encrypted form of the data.
Encryption is a reversible transformation. It is useful only when encrypted data (ciphertext) can be reversed back to its original, unencrypted form (plaintext). If not reversible, the encrypted data are considered unreadable and unusable.
This reversal process is referred to as decryption. An encryption process has a corresponding decryption process, which is used to reverse the encrypted data (ciphertext) back to its original content (plaintext).
Each encryption and decryption function requires a cryptographic key. A cryptographic key is a string of binary digits used as an input to encryption and decryption functions.
In order for the encryption function to transform the plaintext into ciphertext and for the decryption function to reverse the ciphertext back to its original form, the encryption and decryption functions must use the same cryptographic key. This is referred to as a symmetric key. The encryption functions specified in the Advanced Encryption Standard are widely supported in current systems and software.
As depicted in the figure at right, the encryption function requires two inputs, plaintext and a cryptographic key, in order to output ciphertext.
Encryption Function The encryption function requires two inputs, plaintext and a cryptographic key, in order to output ciphertext. 
Decryption Function The decryption function requires two inputs, ciphertext and a cryptographic key, in order to output plaintext. 
Encryption in Widely Used Computer Applications
Encryption is widely used in many computer applications to protect data in transit and at rest. User involvement in the encryption process may vary for each application. For example, in some applications of secure Web browsing using Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocols, the use of encryption may be transparent to users. In other implementations, users may be required to enter a password to encrypt or decrypt the protected data if the cryptographic key is derived from the password.
Email can be encrypted by the sender and then decrypted by the intended recipient using Secure/Multipurpose Internet Mail Extensions (S/MIME). Email can be read only by the sender and the intended recipient.
Internet Protocol Security (IPsec) is a suite of network layer security protocols frequently used to establish virtual private networks. They enable only the two ends of a communication in a computer network to understand the encrypted messages exchanged between them.
The SSL protocol and its successor, TLS, are the primary endtoend security protocols used to protect information traversing the Internet. The most common usage scenario for these protocols is a Web browser, acting as a client for the human user, interacting with a Web server. Using SSL and TLS, encrypted messages between a Web browser and a Web server cannot be decrypted by any unauthorized party.
In addition to protecting data being transmitted over computer networks, encryption is also used to protect data at rest, such as data stored on hard drives, USB drives, and other enduser storage devices. For example, when an encrypted hard drive is stolen or in an unauthorized user's possession, the encrypted data on the hard drive are useless to the unauthorized user because the unauthorized user cannot reproduce the plaintext from the hard drive without the cryptographic key.
Requirements for Implementing Encryption
Encryption is an important security control to provide confidentiality protection for data. For encryption to be effective and to provide data confidentiality, it is important for the following requirements to be met.
Keep the cryptographic key secret. Encryption algorithms are made public to allow for interoperability, ease of use, and more open and effective analysis. The security of the encryption depends on the secrecy of the cryptographic key. The cryptographic key must be kept secret from all entities who are not allowed to see the plaintext. Any person or machine that knows the cryptographic key can use the decryption function to decrypt the ciphertext, exposing the plaintext. If a strong cryptographic key is generated but is not kept secret, then the data are no longer protected. Keeping the cryptographic key secret ensures confidentiality protection of the protected data.
Protect the cryptographic key from modification. The cryptographic key must always be protected from modification. For the ciphertext to be transformed to plaintext, the decryption function must use the same cryptographic key used by the encryption function to decrypt the ciphertext. If the cryptographic key is modified, the plaintext cannot be reproduced. When this happens, the plaintext (the protected data) is lost. It is very important to protect the cryptographic key from any modification (including being lost).
Like other files, cryptographic keys could be intentionally or unintentionally modified. For example, cryptographic keys could be unintentionally corrupted during transmission if an application or protocol using the cryptographic key does not operate as expected. A malicious user with access to the cryptographic key could intentionally modify the cryptographic key to prevent access to encrypted data. In either situation, plaintext data cannot be reproduced by the modified cryptographic key.
Therefore, any system using encryption should have a key recovery mechanism to recover the cryptographic key if it is lost or modified. An example of such a recovery mechanism is to make multiple copies of the cryptographic key, and store them separate from each other in locations unknown to unauthorized parties. If the original key is modified or lost, a recovery copy can be used.
Know the importance of cryptographic key length in choosing an encryption algorithm. To decrypt the ciphertext, an attacker must search for the cryptographic key by decrypting the ciphertext with all possible keys until the correct key is found. For example, if the cryptographic key is two bits long, there are four possible keys that the attacker may try (00, 01, 10, 11). The longer the key, the more possible keys the attacker must try.
Generally speaking, an encryption algorithm that uses a longer key provides a greater level of confidentiality protection. For example, the Advanced Encryption Standard using a 192bit key (AES192) provides stronger protection than the Advanced Encryption Standard using a 128bit key (AES128) because there are more possible values for a 192bit key than for a 128bit key.
Generate a strong cryptographic key and transport it securely. If an attacker can get information about certain bits of the key, then the encryption function using this key does not provide the necessary level of protection. For example, if the key is two bits and the attacker knows that the first bit of the key is equal to the second bit, then the attacker needs to try only two possible keys, 00 and 11, instead of four combinations.
Ideally, a cryptographic key is a randomly generated string of bits that provides the attacker with no information about any bits of the key. Keys can be generated using a Deterministic Random Bit Generator, a function used to generate highquality random bits for an encryption key. The National Institute of Standards and Technology's "Recommendation for Random Number Generation Using Deterministic Random Bit Generators" recommends NISTapproved mechanisms for the generation of random bits using deterministic methods.
Cryptographic keys can be generated solely by the encrypting entity, or through cooperation between the encrypting and decrypting entities, depending on the usage scenario. NIST's "Recommendation for Key ManagementPart 1" discusses approved cryptographic key generation methods when the key is generated solely by the encrypting party.
In many secure communication protocols (e.g., TLS), the cryptographic key may be generated through cooperation of the encrypting and decrypting entities. NIST's "Recommendation for Key ManagementParts 1 and 2" provide guidelines on these key agreement schemes.
In an application where the encrypting entity needs to share the key with a separate decrypting entity, the key must be transported to the decrypting entity in a secure manner. This transportation can be done physically using an electronic device such as a USB drive that holds the cryptographic key. It can also be done electronically over a computer network. NIST's "Recommendation for Key ManagementParts 1 and 2" provide guidelines on methods of secure key transport.
Encrypt all copies of the data. All data that require confidentiality protection should be encrypted if there is a possibility that an unauthorized person could access it. Data at rest in an operational environment are frequently encrypted. However, all copies of data, including data in storage and backup environments, should also be encrypted to provide comparable protection.
Transition to NISTapproved encryption functions. Over time, changes in the use of encryption may be necessary because of cryptographic attacks on encryption algorithms or the availability of more powerful computing techniques and/or devices. Data encrypted in the past using a nonNISTâ€“approved encryption algorithm or a NISTapproved encryption algorithm that has become obsolete should be encrypted using a current NISTapproved encryption algorithm to ensure a strong level of protection for the data. NIST's "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths" identifies current approved algorithms and timelines for acceptable use.
For more information on encryption processes and technologies, visit NIST's Computer Security Resource Center at http://csrc.nist.gov.
Kevin Stine is an information security specialist and Quynh Dang is a computer scientist for the National Institute of Standards and Technology, Information Technology Laboratory, Computer Security Division.
Article citation:
Stine, Kevin; Dang, Quynh.
"Encryption Basics"
Journal of AHIMA
82, no.5
(May 2011):
4446.
