This document is Copyright  2010 by the HIPAA Collaborative of Wisconsin (“HIPAA COW”). It may
be freely redistributed in its entirety provided that this copyright notice is not removed. It may not be
sold for profit or used in commercial documents without the written permission of the copyright holder.
This document is provided “as is” without any express or implied warranty. This document is for
educational purposes only and does not constitute legal advice. If you require legal advice, you should
consult with an attorney. HIPAA COW has not yet addressed all state preemption issues related to this
document. Therefore, this document may need to be modified in order to comply with Wisconsin law.
The Basics of Encryption
Purpose
The purpose of this document is to provide a high level overview of encryption, and some of the
standard techniques in which it is used to protect information. This includes such topics as encryption
types, hashing, email, data transfer, remote access, key management, and securing portable devices
like laptops, blackberry's, smartphones, etc.
This document does not intend to recommend or promote any particular product or technology. Where
specific brands or products are mentioned, they are used as examples only. There are many solutions
available, and this paper makes no attempt to recommend any one solution over another.
Definition
So what is encryption? Simply defined, encryption is:
"…the process of transforming information (referred to as plaintext) using an algorithm
(called cipher) to make it unreadable to anyone except those possessing special
knowledge, usually referred to as a key." (Wikipedia, 2009)
The Breach Notification Rule under section 45 CFR 164.402 defines:
"Unsecured protected health information means protected health information that is not
rendered unusable, unreadable, or indecipherable to unauthorized individuals through
the use of a technology or methodology specified by the Secretary in the guidance
issued under section 13402(h)(2) of Public Law 111-5 (American Recovery and
Reinvestment Act of 2009 (ARRA) on the HHS Web site."
The “Secretary” of the U.S. Department of Health and Human Services (HHS), according to ARRA,
Title XIII – Health Information Technology of Economic and Clinical Health Act (HITECH), Subtitle D,
Part 1, Improved Privacy Provisions and Security Provisions, Section 13402(h)(2), is supposed to:
“…. after consultation with stakeholders, issue (and annually update) guidance
specifying the technologies and methodologies that render protected health information
unusable, unreadable, or indecipherable to unauthorized individuals, including the use of
standards developed under section 3002(b)(2)(B)(vi) of the Public Health Service Act, as
added by section 13101 of this Act.”
…and finally, the Health Insurance Portability and Accountability Act of 1996 (HIPAA), states:
"A covered entity must, in accordance with §164.306… Implement a mechanism to
encrypt and decrypt electronic protected health information."
(45 CFR § 164.312(a)(2)(iv))
1
Asymmetric vs. Symmetric Encryption, and Hashing
“Are there different kinds of encryption? And how do I know if they are truly safe?”
There are a few things about encryption that are important to understand. There are many books and
other publications on the subject of encryption that go into much more detail, but here are the basic
things that everyone should understand:
Symmetric Encryption
Cryptographic solutions fall into one of two types. Symmetric encryption requires that each party who
wants to decipher the encoded message (cipher text) must have the secret key (or password). So if
Bob wanted to send Alice his grandmother’s secret recipe for chocolate chip cookies, he could encrypt
the message and use the key “My dog has fleas” to do so. Now for Alice to decrypt that message, she
would need to know the passphrase (or “key”). This works well when the intended recipients are few or
when there are only a small number of secret messages that will be delivered over time. However, the
management of secret keys for each message becomes complicated real fast especially as the number
of intended recipients grows. This can become a key management nightmare. The other issue is, how
do you deliver the secret keys to each recipient securely?
Asymmetric Encryption
Not long ago, some real smart people from MIT developed a system known as Public Key encryption.
Simply described, each person has two keys. One is a secret (or Private) key, and the other is a Public
key. Public keys can be stored in a public database (often online) for anyone to see. If Bob wants to
send Alice a secret message, all he needs to do is to encrypt that message with Alice’s Public key and
send her the message. The trick is that ONLY Alice’s Private key can decrypt the message. Now Alice
and Bob do not need to worry about sending the private keys to anyone, because they only need to
know each other's Public keys, and can keep their private keys to themselves.
Additionally, Bob can encrypt a message with his Private key knowing that anyone can decrypt it with
his Public key. Now why would Bob want to do this? Because anyone who used Bob’s Public key to
decrypt the message would KNOW that only Bob could have encrypted it (remember that Bob used his
Private key that only he knows). This process is referred to as “Digitally Signing” and it is used to prove
the Origin of the message. In this manner, a digital signature is much more reliable than a written
signature which can often be easily forged.
Hashing
Another clever use of encryption is to create a unique fixed length string of characters from a selected
text (such as the entire document). This string is called a HASH. If anything at all changes within that
document (or file) then the HASH is completely different. This process is used to verify the INTEGRITY
of the file. As an example, if you were to create a hash of the entire Library of Congress you could have
a hash that looks like this:
31a8b73156f221bfa56529145b608687
Now if I change only one comma in that entire collection of data, the hash produced would create a
completely different string, like this:
30d9e3bd5acd2036f4d0d7b19837269d
Using this hashing process, and by comparing the hashes of the original and received messages or
files, Alice could tell immediately if anything had been altered within the message.
2
A hash is a one way process and is impossible to reverse. That means that in no possible way could
you create all of the data in the Library of Congress with only the hash that was created. Because of
this, hashes can be posted publicly, or delivered without any concern of privacy or security shortcomings. In fact, many people will post the hashes for their applications on the same page as the
download so you can tell if the application has been altered in anyway.
As you can see, encryption is very useful in ensuring the confidentiality and integrity of data as well as
proving the point of origin (which serves to prove non-repudiation)
Algorithms
An algorithm is simply the mathematical formula used to encrypt the data. For example, in the following
illustration the sentence fragment is encrypted using a simple substitution algorithm:
Plain Text: The quick brown fox
Algorithm: A=1, b=2, c=3, d=4, etc… <space>=255
Cipher Text: 20 8 5 255 17 21 9 3 11 255 2 18 15 23 14 255 6 15 24
Over the years there have been many algorithms developed: DES (Data Encryption Standard), 3DES
(running data thru DES multiple times), AES (Advanced Encryption Standard), Blowfish, and others.
Many of the older algorithms have been broken, or ‘cracked’, and are now useless. The current federal
standard is AES.
Encryption algorithms are rated on several factors, most importantly the key length – the longer the key,
the stronger the encryption. DES and 3DES, for example, were originally created to use a 56-bit key.
Data encrypted with DES can now be cracked in a matter of hours on a moderately powerful computer.
The AES algorithm is available is 3 key strengths: 128-bit, 192-bit, and 256-bit; obviously, the 256-bit
key is the strongest. It is estimated that, on a machine that could crack a single DES key in one second,
it would take 149,000,000,000,000 (149 trillion) years to crack the AES128 algorithm; by comparison,
the age of the universe is currently estimated to be less than 20 billion years (NIST, 2000).
The federal FIPS 140-2 standard “specifies the security requirements that will be satisfied by a
cryptographic module utilized within a security system protecting sensitive but unclassified information”
(NIST, 2002). When choosing an encryption product, look for those that are certified to be compliant
with this federal standard – this ensures that it will meet any criteria specified by federal law, either now
or in the foreseeable future, and will be more than sufficient to pass an audit.
HIPAA and Encryption
The HIPAA encryption standard specified in the security rule is deemed "addressable" meaning that the
covered entity (CE) must either implement encryption or come up with a 'reasonable and appropriate'
solution to meet the regulatory requirement. As encryption technology has developed and become
more affordable, it is becoming more difficult to take the position that there are any 'reasonable and
appropriate' alternatives to encryption.
To add to the already complicated interpretation of the rule(s), the recent HITECH Act specifies severe
penalties for breaches of unsecured PHI, and further states that these penalties do not apply if data is
encrypted or otherwise rendered unusable, unreadable, or indecipherable.
Taking all this into consideration, the practical implication is that CEs will have exposure to regulatory
penalties unless data is encrypted. Recent audits by OCR, OIG, and other agencies indicate that these
agencies will not hesitate to impose sanctions for noncompliance involving a failure to encrypt. In short,
it is much safer to encrypt than to attempt to create an alternative solution.
3
But… what to encrypt, and how? Data (ePHI) may be stored and/or transmitted in many ways; are we
to believe that we must encrypt the data all the time, in all its forms?
Simply... no. As the result of a proper risk analysis, we can identify the specific areas requiring
encryption and implement the appropriate measures to safeguard the data. Some of these major areas
are illustrated in the following pages, with guidance on when and how to encrypt.
Common Uses
Email Encryption
“Okay, so we need to encrypt email – what does that mean, and how do we do it?”
While the above analysis would apply to both data in motion and data at rest, email presents one of the
most likely vehicles for breach, and is the first area to address when implementing encryption. As an
example, most patients have access to email, and it is a well understood technology; it is also one
common area likely to be investigated by an auditor.
The protocols used for sending email were created a long time ago when there was little if any concern
for privacy of the information being sent. Because of this, standard email is inherently not secure. The
data being delivered is transmitted in what is commonly referred to as “Plain Text”. What this means is
that a person could intentionally intercept data flowing between the sender and the receiver without
much effort, and could read the entire message. In this manner, this person could be copying the data,
or changing it at will. So how can you protect yourself and that information which could be leaked from
sending or receiving protected information in an email?
Public Key email encryption is generally managed in one of three ways:



At the desktop (local level)
At the gateway (network perimeter)
From a secure server outside of your network (in the “cloud”)
The encryption process is roughly the same in each case, although the steps necessary may differ. The
diagrams on the next pages explain the email encryption process in more detail:
4
Encryption is done using ‘Encryption Keys’ - these keys
are used to both encrypt and decrypt messages. Each
user has two keys – a Public Key and a Private Key. As
the names suggest, the Public Key is exchanged with
other users or gateways, while the Private Key is not. To
send an encrypted email, the sender encrypts it using the
recipient’s Public Key; only the recipient’s Private Key is
able to decrypt the message.
Encryption
Gateway
Private Key
Public Key
Private Key
User
Public Key
INTERNET
For every pair of users who need to exchange encrypted
email, each user must have the other person’s public key.
It becomes obvious that the more people a user needs to
communicate with, the more keys he/she must maintain.
Public Key
Private Key
User
Local Solution
Figure 1
5
Encryption is done using ‘Encryption Keys’ - these keys
are used to both encrypt and decrypt messages. Each
endpoint has two keys – a Public Key and a Private Key.
As the names suggest, the Public Key is exchanged with
other users or gateways, while the Private Key is not. To
send an encrypted email, the sender encrypts it using the
recipient’s Public Key; only the recipient’s Private Key is
able to decrypt the message.
Encryption
Gateway
Private Key
Public Key
Private Key
Encryption
Gateway
Public Key
INTERNET
Public Key
For every pair of users who need to exchange encrypted
email, each user must have the other person’s public key.
With a gateway system, this key exchange is automated.
Private Key
User
Gateway Solution
Figure 2
A cloud-based solution works similarly to the gateway solution shown above, but does not require
hardware or software, and there are fewer key management considerations.
There are advantages and disadvantages to each solution...
As the diagram on the next page shows (figure 3), the local solution encrypts the message from the
point of origin (Outlook, or some other email program), meaning it is encrypted over the local network
as well as over the Internet. A gateway solution leaves the message in plain text on the local network,
encrypting it only when it leaves the organization. However, management of the encryption keys is
automated with a gateway or cloud-based solution, while it is mostly a manual process with local
encryption.
The selection of an encryption solution MUST take all these factors into account. Also, gateway
solutions may ensure that encrypted emails can be sent to anyone, regardless of whether the recipient
has their own encryption solution; local solutions require the recipient to have a compatible encryption
solution as well.
6
Private Key A
Public Key B
Private Key B
User A
User B
Encrypted
Email
Message
Encrypted
Email
Message
Plain Email
Message
Plain Email
Message
INTERNET
Public Key B
on Gateway
Private Key A
on Gateway
Encrypted
Email
Message
Encrypted
Email
Message
Private Key B
on Gateway
Encryption
Gateway B
Encryption
Gateway A
Local Process
1) User creates email message and selects to encrypt
2) User checks for recipient’s Public Key
3) If key exists, message is encrypted and sent
4) If key does not exist, user must request (message NOT SENT)
5) Once keys are exchanged, message is recreated, encrypted and sent
6) If recipient does not support encryption, no communication is allowed
7) All key management is handled by the user(s)
8) Communication is only available if the recipient’s key is available
Gateway Process
1) User creates and sends email message normally
2) Gateway checks for recipient’s Public Key
3) If key exists, message is encrypted and sent
4) If key does not exist, encrypted message is stored on server
5) Recipient is notified (by plain email) that an encrypted message is waiting
6) Recipient logs onto server and retrieves encrypted message
7) All key management is handled by the gateway
8) Communication is always available
Figure 3
Cost is another factor that must be considered, and not just the amount of money spent to purchase a
solution; ongoing maintenance and support costs must be considered as well. Generally speaking, the
larger an organization, the more cost effective a gateway solution becomes.
Another option is to encrypt the message and/or data and include it as an attachment in an otherwise
unencrypted email. SecureZip, WinZip and PGP are examples of applications that have this capability –
they will compress the data into a smaller file, and apply an encryption algorithm. These are usually
protected by a password that controls the decryption process – without the password, the file is unable
to be opened and read. This method also has the advantage of being able to combine several data files
into a single encrypted-compressed object for emailing as a single attachment.
The danger of using this method is that a single password is the sole mechanism protecting the data
from unauthorized access; the weaker the password, the less secure the data. There are many utilities
available today that can crack a password-protected ZIP file; in many cases, only an hour or two may
be required to crack the password and access the data.
Having decided to implement an email encryption solution, regardless of whether it is local or gateway
based, the next question is, "What do I encrypt? …all email? …only PHI?" Well, it depends…
If PHI is to be sent outside the entity (i.e. to an external recipient) via email, it must be encrypted – that
much is indisputable. But what about non-PHI - corporate confidential data, such as accounting records
or employee files? In most cases, these are items that the CE would not want made public if they were
to be obtained by someone other than the intended recipient. There are many examples of non-PHI
data that should most likely be encrypted; only a complete risk assessment can determine which emails
7
need to be encrypted and which need not. Most encryption solutions – both local and gateway – have a
mechanism for applying policies on what and when to encrypt.
As a general rule, err on the side of encryption! While encryption is not explicitly required by the HIPAA
regulations, there is very little room (if any) for alternative safeguards.
Data Transfer
“We can’t afford to implement an email encryption solution, but we still need to transfer
patient data to and from our payers and other business associates. What can we do?”
Often, protected data (including ePHI) must be transferred to/from other entities or business associates
by a means other than email; File Transfer Protocol (FTP) is a common data transfer method. There
are several means of securing data over an FTP connection – the data itself may be encrypted
(protecting the data itself), the FTP connection may be secured (protecting the communication path), or
a combination of both may be used.
There are two common methods to secure the standard (and insecure) File Transfer Protocol (FTP).
The first method is to use Secure Shell (SSH) to copy the data from one location to another; this
method is generally referred to as SFTP. Setting up and configuring an SSH server is relatively easy
and inexpensive, and many companies currently support using this technology. The second method is
to use Secured Socket Layers (SSL) to protect the connection of a standard FTP transmission. This is
referred to as FTPS and is also very common.
And, as with email, the data itself may be encrypted; again, there are many utilities that can be used to
secure the data before sending.
For added protection, the two methods may be combined – sending an encrypted file over an encrypted
connection. The benefit to encrypting both the data and the communication path is to mitigate the risks
that each one has separately. For example, only protecting the communication path (data in transit)
may mean that unencrypted data is sitting on your internet facing server or the recipient’s internet
facing server for extended periods of time. If there were to be a breach of that system, there would be
no protection of the data that was delivered. If you only send encrypted data (data at rest) over a
standard unencrypted FTP connection, then the credentials that you are using to log in (or the ones
used to connect to your server) are being transmitted openly. A malicious person could capture these
credentials and log into the server themselves, altering the encrypted data file, or making a copy for
later use. As technology advances, it is very likely that the encrypted file captured today could be easily
decrypted in 5 years; most ePHI will still be as relevant and useful in 5 years as it is today.
“This would require us to learn something new - aren’t there any websites we can use?
That would be really easy, and we already know how to use the Internet.”
In addition to SFTP/FTPS, there are many Internet-based file transfer, or file storage and retrieval sites
which use SSL to protect the data transfer. The sender simply needs to set up an account with one of
these providers, create user accounts for those people with whom they need to share data, and copy
the data to the site. While this method is generally secure, extreme care should be taken when initially
choosing a provider for this service. Things to consider include system availability, system security,
what provision will be taken in the event that you wish to terminate your relationship, or if they go out of
business, etc.
8
Questions that should be asked include:






Do they employ redundant systems to ensure availability?
Do their servers need to be encrypted or have they determined through their risk analysis that
other compensating controls are sufficient?
Is the upload/download process secure (SSL / HTTPS / SFTP / SSH)?
Have they been certified to use the level of encryption that you or your business partners
demand (FIPS 140-2 compliant)?
Are their controls regularly audited?
Will they guarantee appropriate destruction methods of hard drives or backup tapes which may
contain your data?
“Well okay then, we can’t afford and don’t have the expertise to implement and support a
technical solution. We’ll just use a courier service and send copies of the data on CD.”
BZZZZZZZZT – not so fast! What happens if the courier loses the CD? ...or delivers it to the incorrect
place, or person? ...or, worse yet, makes a copy to sell to the highest bidder? The data must still be
protected; encrypting the data file(s) on the CD is the only way to ensure that. The methods presented
in this paper for encrypting data at rest will insure that your data is secure no matter what method is
used for transfer.
Remote Access
"We're trying to cut costs, and help the environment. I've heard about telecommuting;
how can I let my employees work from home?"
Telecommuting, or working from a remote location, is becoming a common method for controlling
expenses, and helps the environment by putting fewer cars on the road. Remote access systems allow
employees or other users to securely connect to applications and data as if they were in the office.
There are several means of granting access to applications and data from remote locations; one of the
most common is with a Virtual Private Network, or VPN. As the name suggests, the VPN creates a
temporary encrypted connection into the host network that exists only for as long as needed. There are
two types of VPN – either is just as secure.
The standard VPN requires a client utility to be installed on the remote workstation, and creates an
encrypted connection, or tunnel, into the company's network. This method uses keys (similar to the
keys used in email encryption) to authenticate the remote computer, and the IPSEC protocol to create
and secure (encrypt) the tunnel. One advantage to this is that the connection can be better controlled
by the company – connections are only allowed for computers with the appropriate client utility. Most
firewalls (you do have a firewall, don't you?) have the ability to deploy and establish VPN tunnels, using
their own client utilities. Remote users must still supply their ID and password to connect, just like they
were in the office.
Recently, a new type of VPN has become very popular – the SSL VPN. Instead of having an installed
client utility, the SSL VPN is set up as a secure website (similar to how banks provide online banking
services). Because there is no client to install, this has the advantage of being available to anyone,
from anywhere, and not just from a specific computer.
In either case – SSL or IPSEC – any/all client applications would need to be installed on the remote
computer in order to be accessed and used.
9
"Well that's no good – we don't have enough licenses to install our applications on every
computer that could be used to access our systems. How do we get around that?"
Another option – available with some SSL VPN solutions – is to make the applications available on the
website. After the user connects and logs into the network (oh yes, they still have to log in – again, think
online banking), the applications are published as icons on the web page. Citrix, with their Citrix Access
Gateway product, is probably the best known solution of this type.
"Our software vendor needs to access our server to update their application, but they
want to charge us for travel, food, and lodging. Can they use remote access instead?"
Absolutely! This is a great use of remote access technology, and can help offset the costs associated
with implementing such a solution. It also allows for faster response, and decreased downtime in the
event of a software problem.
"Our vendor says they want to establish a 'Lan-to-Lan' VPN – that sounds complicated
and expensive. What is it, and how does it work?"
A Lan-to-Lan (or L2L) VPN is very similar to the client-based IPSEC VPN discussed earlier. However,
instead of requiring a client utility, this solution creates a permanent encrypted tunnel between the two
networks. Again, many firewalls have this capability, and there are dedicated VPN solutions available
from companies like Cisco, Juniper, and others.
While there are many advantages to using this technology, VPN's can be expensive to implement and
maintain – only a complete risk assessment can determine whether this technology is appropriate for
any particular organization. The important point to remember is that if you decide to allow access
remotely, you must ensure that the connection and/or the data is encrypted.
Portable Devices
Laptops
"I've heard a lot on the news about laptops being stolen, and patient or employee
records being exposed. Some of our employees have laptops – what do I need to do?"
With many of today’s laptop computers providing portability as well as being suitable replacements for
desktop computers, more and more users have laptop computers. The result is increased risk to an
organization’s data which resides on the laptop, since laptop computers are more susceptible to being
lost or stolen. The best way to protect sensitive data is to not store it on the laptop hard drive in the first
place; through the use of remote applications (i.e. web applications, Citrix, etc.). However, if sensitive
data must be stored on the laptop computer hard disk drive, the best way to protect it is by use of
encryption. There are generally two ways to encrypt data on a laptop hard disk drive, full disk
encryption and file/folder level encryption, or some combination of the two methods. In any case,
properly centralized, IT managed data backup and key management are extremely important, since a
lost or damaged encryption key could result in permanent data loss. It is also important to consider your
requirements related to eDiscovery when looking at laptop data encryption (i.e. disk drive imaging,
recovery, archival, etc.). There are several types of encryption products available and the cost of
encrypting data on a laptop computer is generally quite small when compared to the risk of exposing
sensitive data.
10
File and Folder Level Encryption
File/folder level encryption is typically selective, being performed manually under direct user control, or
via an automated program. Some file/folder level encryption products can encrypt files automatically,
based on specific configuration for file encryption by file location (e.g., folder), file type (e.g.,
spreadsheets), or source application (e.g. Excel).
The Windows Encrypting File System (EFS) is one example of a basic file/folder level encryption
product. It can be centrally activated by using Active Directory Group Policy Objects to encrypt
specified files or folders. However, like all file/folder level encryption products, it relies on users to
properly write sensitive data into predefined protected folders, and cannot stop users from copying
sensitive data, which is supposed to be encrypted, to unencrypted locations (either on the hard disk
drive or on removable/portable media).
There are more sophisticated file/folder level encryption products which do more, and some offer
stronger policies and enforcement which make it less likely that sensitive data will go unencrypted on
the laptop hard disk drive or on removable/portable devices (e.g. USB drives).
Full Disk Encryption (FDE)
Full disk encryption (FDE) does just what the name implies; it encrypts everything stored on a physical
disk or a logical volume. The purpose of FDE is to ensure that all data written to the hard disk drive is
always encrypted. This includes not only sensitive data and files, but also application and operating
system files (i.e. page files, data caches, etc.). By applying encryption to the disk drive(s), any/all data
is encrypted the moment it is written to the drive, and it is completely inaccessible if the drive is
removed or is accessed externally. The only way to access the data on a FDE disk is to use the
approved, predefined access methods (usually the application used to create and manage the data).
How does it work? Just like other encryption schemes, a key is used to convert the data to an
unreadable form, and to convert it back into something readable when needed. An example of one type
of FDE encryption is the BitLocker feature in Windows 7. The BitLocker tool encrypts entire disk
volumes and utilizes security features of the laptop computer hardware and operating system (i.e.
Trusted Platform Module (TPM) chip, USB keys, etc.). Since it encrypts by disk volume, any data
written to unprotected volumes will be unencrypted.
There are FDE products which are more comprehensive and encrypt the entire contents of the hard
disk drive, sector by sector, and bit by bit (including boot sectors, swap files, OS files, and user data).
Most FDE products provide additional protection through the use of Pre-Boot Authentication (PBA),
authenticating the user before the operating system starts. The authentication, encryption, provisioning,
and reporting capabilities vary for each FDE product, but enterprise FDE products typically provide
features like Windows single sign-on, centralized administration (i.e. password resets), centralized
logging for security audit and compliance reporting, and features like a remote kill switch if a laptop
computer is reported lost/stolen or doesn’t periodically check in with the organization’s FDE server.
Comparing FDE and File/Folder Encryption
"I'm confused... what are the pros and cons of file and full disk encryption?"
The main drawback of file/folder level encryption is the possibility of sensitive data not getting encrypted
due to the selectivity of this method. Also, since individually encrypted files, or groups of files, can
migrate throughout the organization (i.e. onto file servers, as email attachments, etc.), use of
centralized key management and proper key archiving is imperative, to ensure these files can be
decrypted in the future.
11
A drawback with FDE is that initially encrypting an entire laptop disk drive can take hours, not including
the time necessary to ensure there is a full backup of the laptop disk drive before starting the encryption
process. Also, due to the way FDE works, encrypting every bit of the hard disk drive, FDE products
have a tendency to find bad laptop hard drives more quickly than they would otherwise be discovered
(if ever). In addition, proper procedures must be put in place since some FDE pre-boot authentication
methods can interfere with other programs used by the organization to manage the laptop computer
(i.e. asset tracking, sign-on processes, desktop administration, patching and auditing tools, etc.), since
they cannot remotely reboot the computer without the user’s credentials. Another consideration is the
potential impact to data recovery if a FDE laptop computer hard disk drive is corrupted or damaged.
Other Portable Media
"Many of our employees have Blackberry's, or some other kind of smart phone that
could allow them to take data with them on the road. Do these need to be encrypted?
And if so, how do we do it?"
Portable devices include Blackberry's and other mobile phones that support wireless access, and have
the ability to store messages and other data; this category also includes CD's, DVD's, USB or “thumb
drives”, iPod's, and similar devices. All of these devices have the capability to store confidential or
sensitive information that creates an increased risk of an intentional or accidental loss of confidential
patient or business information.
There are several controls that an organization could implement to address this risk:





Have a policy that forbids storing data on the device.
Deploy technology to limit what information is stored on the device.
Enable built-in functionality, i.e.,passwords, that controls access to the device.
Deploy technology to encrypt any data stored on the device.
Implement some combination of these controls.
The first control has a number of shortcomings, the least of which is how to measure compliance. This
approach does nothing to address the risk of a confidentiality breach if a device is lost or stolen.
The second control relies on technology to examine all data as it moves from corporate data storage to
a portable device. This approach typically uses a lexicon of sensitive words, phrases or other word and
number patterns to control the transfer of data. While this will reduce or control the type of data
transferred, it will not eliminate the risk of a confidentiality breach if a device is lost or stolen.
Many of these devices have built-in functionality that requires the entry of a password in order to use
the device. This feature would control access to the device and by extension limit access to all stored
data. However unless a strong password is used, one not easily guessed, there is still a considerable
risk that a lost or stolen device would result in a breach of confidential data.
Finally, data encryption delivers a high degree of confidentiality and provides a safe harbor if there is a
breach of patient information when a device is lost or stolen. Encryption renders the information
unreadable and unusable unless the encryption key is available.
Many of these devices offer encryption solutions already that should be explored. For example,
Blackberry Enterprise Server (BES) offers data encryption using the AES256 algorithm. Also, by
default, the BES Solution generates the master encryption key and message key that the BES and
BlackBerry devices use to encrypt and decrypt all data traffic between one another.
12
By using a combination of the last two control options, password controlled access and data encryption,
the risk of a breach of confidential information is significantly reduced. Adding the second control will
further lessen the risk by limiting what information can be transferred to the device. There are several
commercial security applications available that will enforce encryption and other controls on devices
that do not natively have this functionality, including the ability to bit-wipe the device (delete all data)
after a defined period of inactivity (days or weeks), or after a set number of failed password attempts.
Each business entity needs to determine which controls are appropriate. What is the risk associated
with information leaving the organization? What is the risk of the information falling into the wrong
hands - monetary fines, legal action, loss of intellectual capital, and loss of business reputation? Each
business has to decide what information needs to be protected. Each business has to consider the cost
of the control(s) and the value of the information needing protection. At the end of the day it boils down
to a business decision that is implemented with technology.
As discussed previously, SecureZip, WinZip, PGP, and other utilities can encrypt and passwordprotect data; once the data is encrypted you can deliver it by email, over an FTP (or similar) connection,
or on some other form a media (e.g., DVD, CD or USB Drive, etc). One of the most common
disadvantages with this method is in key management. It can become difficult to manage all of the keys
and passwords that belong to each file and for each intended recipient. You also need to ensure that
you are delivering the key in a secure manner.
Data at Rest
"I suppose now you're going to tell me that we need to encrypt our servers too? You
wouldn't really do that, would you?"
Data at rest is data that is stored on the disk drives of your servers and computers, on backup tapes, or
elsewhere, when it is not in use. You may ask why data that is safely locked away in your server room
needs to be encrypted; there are several reasons:



Virtually any server can be accessed from anywhere by someone who knows what they are
looking for and is motivated to get it. That means that unencrypted data could be available to
anyone who knows how to access your systems (yes, that includes employees)
Disk drives fail and are replaced; servers grow old and slow and are retired. These all need to
be properly disposed of - until a disk drive is totally destroyed the data on it is accessible. In
many cases failed drives are no longer locked in your server room, but rather are kept at the
desk of the IT person where the cleaning staff could simply walk away with it
Not all servers are kept in locked rooms, safely hidden away in a hospital’s basement.
Especially with small offices, often the only lock is the lock on the office door
The solution again is full disk encryption (FDE). By applying encryption to the disk drive(s), any/all data
is encrypted the moment it is written to the drive, and it is completely inaccessible if the drive is
removed or is accessed externally. The only way to access the data on a FDE disk is to use the
approved, predefined access methods (usually the application used to create and manage the data).
How does it work? Just like other encryption schemes, a key is used to convert the data to an
unreadable form, and to convert it back into something readable when needed. There are many
available options for implementing full disk encryption; users of newer Microsoft operating systems
even have a disk encryption program called Bit Locker built in and ready to use at no additional cost.
13
"We back up our servers to tape every night, and store the tapes off-site. Do we need to
encrypt them too?"
We all know that tapes wear out and get thrown away. Tapes are often stored off-site for safety, are
shipped from one building to another, or are even transferred across the country. With all this tape
movement, it is not uncommon for them to be lost. It is a trivial matter for someone to retrieve data from
a backup tape. Most vendors of tape backup solutions offer encryption as a standard part of their
product; use it - it is an inexpensive way to apply protection to the data stored on tape. If your tape
backups cannot be encrypted you should either not be sending tapes anywhere outside your facility, or
you should be looking for an alternative that supports encryption.
To dispose of old tapes, you could take them to an MRI unit and fire up the magnet, run them through a
trash compactor, burn them, or otherwise destroy the tape. For old hard disk drives, drilling a hole thru
the disk housing (and thru the platters inside) will render the disk permanently unreadable. In either
case, destroying the medium (disk, tape, etc) is the only sure way to prevent access to the data.
Securing The Keys
"As we encrypt more and more of our data, what happens if the keys get lost or a user
forgets a password?"
Key management can be a challenge – this section deals with the subject in detail.
Proper key management is probably one of the most important aspects of data encryption. The loss or
corruption of cryptographic keys can lead to the loss of access to systems and data. The larger and
more diverse your environment, the more distributed your keys can become. You will need to pay
particular attention to the importance of key lifecycle management. Key lifecycle management refers to
key management, generation, usage, storage, archival, and destruction.
Key Management
The proper management of cryptographic keys is essential to the effective use of cryptography for
security. Ultimately, the security of information protected by cryptography directly depends on the
protection afforded the keys. All keys need to be protected against modification, and keys used for data
encryption and digital signatures need to be protected against unauthorized disclosure. All users (end
users and administrators) need to be aware of their liabilities and responsibilities with respect to
properly managing cryptographic keys, and need to understand the importance of keeping their
cryptographic keys secure at all times. Managers and administrators should be prepared for the
possibility of cryptographic key compromise and should have proper controls in place to adequately
manage this type of situation. Whenever possible, organizations should utilize centrally stored and
managed cryptographic encryption keys. User generated and managed encryption keys require much
greater vigilance of key lifecycle management procedures, as the organization could lose access to
data if something were to happen to an employee or they were to leave the organization without
divulging the keys used to encrypt sensitive or mission critical company data.
Passwords are generally used to protect (encrypt) cryptographic keys used for data encryption and
digital signatures. Passwords are also keys, but are typically much simpler than the mathematically
generated cryptographic keys, and sometimes the cryptographic encryption key is derived from a user
entered password. As a result, data encryption systems are only as strong as their weakest link, which
is usually the password used to protect the cryptographic keys.
There are several different types of encryption keys; the National Institute of Standards and Technology
(NIST) defines about 20 different types. However, for data encryption, one can generally think of two
14
types of applications, applications which encrypt data in transit using short-term keys (i.e. FTP, SSL,
etc.), and applications which encrypt data at rest using long-term keys (i.e. WinZip, email, backup
systems, etc.). As one would expect, the key lifecycle management requirements will be different for
short-term and long-term keys.
Key Generation
The generation of keys is the most sensitive of all the cryptographic functions, and any inadequacies in
the implementation of the key generation function can seriously undermine the integrity of the system.
Security measures should be in place to prevent unauthorized disclosure, modification, or replacement
of keys. Depending on the key management implemented, some applications will locally generate keys
(e.g. using WinZip to encrypt files) and other applications will generate and distribution keys from a
central authority (e.g. centrally managed FDE). In either case, company employees must maintain
complete control of generated keys from the time of generation and throughout their lifecycle.
Key Usage
The use of cryptographic keys in applications may require special handling and protection practices to
ensure the confidentiality and integrity of the keys. You will need to establish procedures to ensure the
protection of sensitive cryptographic keys, and use of physical devices (i.e. portable USB drives, etc)
may be necessary to protect the keys. Authentication timeout features should be used to protect
cryptographic keys from compromise or misuse and key recovery mechanisms should be implemented
for cryptographic keys that are used to encrypt sensitive data.
Key Storage
The proper storage of cryptographic keys is critical to ensure the confidentiality and integrity of keys
used by end users, administrators, and automated applications. You will need to ensure that
appropriate storage methods are used whenever storing cryptographic keys. The two most common
ways to store cryptographic keys are software storage and hardware storage. Procedures are
necessary to manage software stored cryptographic keys due to greater vulnerability from key
exposure; if using passwords, strong passwords should be chosen for providing access to the keys.
There should also be adequate access controls for the encrypted key data file, to prevent theft or
misuse. If storing cryptographic keys in hardware storage, you will need procedures to provide for the
initialization, distribution, replacement, and destruction (as necessary) for the hardware token.
Key Archival
As part of the key lifecycle, archival of cryptographic keys is vital to ensuring that any data encrypted
with those keys is always available to authorized parties. Sensitive user or centrally managed
cryptographic keys should be archived for time periods which align with the data which has been
encrypted by those keys. This will ensure that encrypted data can always be decrypted for as long as
the encrypted data exists in the company’s data archives. For keys associated with digital signatures,
key archival times will determine the timeline for signature validation.
Key Destruction
As part of the key lifecycle, expiration is an important part of key management. Reasonable lifetimes for
keys should be determined, again aligned with the data encrypted with those keys. For keys associated
with digital signatures, procedures are needed for the deactivation/revocation of keys so that data
digitally signed prior to a compromise date (or date of loss) can be verified.
15
Summary
"That's way too much information to remember. How do I figure out what I need to do?"
The need for one or more encryption solutions in a healthcare setting is indisputable for all but the very
smallest of entities. There are several situations where encryption may be, and probably is necessary:


Data at rest
o Laptops
o Smartphones
o CDs / DVDs / Tapes
o Workstations / Servers
o iPods, Thumb drives, etc
Data in transit
o Email
o Data Transfer
o Remote Access
Of these, several are relatively easy and inexpensive to implement, and for smaller
organizations a single solution may provide security in multiple areas. For example, installing
PGP may allow you to do full disk encryption on laptops, create encrypted-compressed files for
transfer, and send / receive encrypted emails as well. As the size and/or complexity of the
environment increases, so does the difficulty and cost of implementing controls.
While it may be possible to protect PHI without implementing encryption, the risks associated
with such a non-solution are too great to ignore; the ARRA/HITECH breach notification
requirements alone are often a sufficient justification for encryption. So how do you determine
what to encrypt, when, and how? The following steps will help to answer those questions, and to
develop a solution:
1. Complete a risk assessment
a. Determine exposure to threats
2. Perform a full gap analysis
a. Current controls vs. risks vs. exposure
3. Determine residual risk
a. Actual exposure, and associated cost of non-compliance
4. Prioritize the findings
a. By exposure, by cost, or by some other appropriate comparison
5. Develop remediation plan(s)
a. Highest priority first
6. Implement solution(s)
a. Update your policies, if necessary
b. Don't forget to educate your users!
7. Document, document, document
a. All assessments, decisions, methods, etc, must be documented
b. Keep documentation for 6 years
8. Rinse, repeat
a. Security is not a goal, it is a process
Risk assessments are required by HIPAA anyway, so you're already doing the first step, right?
The gap analysis and residual risk determination steps are part of a complete risk management
strategy, so you should already be doing them as well. And, if the preceding statements are
correct, then you already know your risk exposure. All that remains is to assign the appropriate
priority to those risks, develop plans, and execute your strategy.
In most cases, the risks of not encrypting far outweigh the cost of implementing an encryption
solution. A risk assessment will help determine the areas of greatest need, and a well
16
documented plan will ease the deployment and management of the chosen solution and help to
make it more effective.
17
Appendix A
The links below are intended for reference only and are in no particular order. There are many
solutions available, from many vendors – the list below is a representative sampling of a few of
these solutions. The HIPAA Collaborative of Wisconsin (HIPAA-COW) neither endorses nor
recommends any individual company or product.
PGP Corporation – encryption solutions
http://www.pgp.com/index.html
WinZip – data compression and encryption
http://www.winzip.com/index.htm
Citrix Corporation – remote access solutions
http://www.citrix.com/English/ps2/products/product.asp?contentID=15005&ntref=prod_top
Checkpoint Corporation – firewall, VPN, and full disk encryption
http://www.checkpoint.com/products/index.html#gateways
http://www.checkpoint.com/products/datasecurity/pc/
Juniper Networks – firewall and VPN
http://www.juniper.net/us/en/products-services/security/
Cisco – routing, switching, remote access, and VPN
http://www.cisco.com/en/US/solutions/ns170/networking_solutions_products_genericcontent090
0aecd80511fa7.html
GNU GPG – encryption solutions
http://www.gnupg.org/
TrueCrypt – full disk encryption
http://www.truecrypt.org/
Guardian Edge – full disk encryption and endpoint protection
http://www.guardianedge.com/products/
WinMagic – full disk encryption and endpoint protection
http://www.winmagic.com/products
Barracuda Networks – VPN and gateway solutions
http://www.barracudanetworks.com/ns/products/sslvpn_overview.php
OpenVPN – VPN solutions
http://openvpn.net/
Credant – full disk and mobile device encryption
http://www.credant.com
Zix Corporation – email encryption
www.zixcorp.com
18
Blackberry
www.blackberry.com
SecureZip
www.pkware.com
Appendix B
The resources below are available for more information on many of the topics presented in this
paper. Again, HIPAA-COW makes no assertion or recommendation of any of the material
available via these links.
http://en.wikipedia.org/wiki/Encryption
http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html
http://www.hipaa.ihs.gov/index.cfm?module=use_of_encryption
http://en.wikipedia.org/wiki/Public-key_cryptography
http://otfedb.sdean12.org
http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
http://csrc.nist.gov/publications/PubsSPs.html
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf
http://hipaa-encryption.com/HIPAA-Compliance/phi-encryption/government-encryption-standardadvanced-encryption-standard-aes/
http://www.nist.gov/public_affairs/releases/aesq&a.htm
19