Stoppt die Online-Ãœberwachung! Jetzt klicken & handeln! Willst du auch an der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien:

Home > Tools

Personal and Corporate Email Encryption

Stephen M. Butler Margaret Murphey
Oracle DBA EDI Project Manager
First Choice Health Network

OVERVIEW

The protection of email containing patient-identifiable information is a hot topic. There are many proposed solutions. Some solutions are cumbersome to use. Other solutions do not appear to provide adequate protection. All have some level of inconvenience in their use. The authors feel they have found an implementation that can satisfy the highest level of required protection without imposing an unreasonable burden on the participants.

This paper explains the need for email encryption within the healthcare industry. The terminology associated with current encryption technology is discussed along with some suggested procedures. Finally it explores one implementation method that works well for email exchange between participants using divergent email programs. This particular implementation focuses on Windows-based email packages such as Outlook and Outlook Express. However, there are variants that work well for Mac and Unix-based systems.

BACKGROUND

The recent Patient Bill of Rights and the upcoming HIPAA requirements for Protected Health Information have set the stage dictating the need for email security and privacy.

Sending an email is equivalent to putting your message on a post card and dropping it into the local mailbox. Each person who handles the post card and anyone who snoops in your mailbox is able to casually read the post card. Similarly, any system that stores and forwards email provides an opportunity for an inquisitive person to intercept and read a copy of your message. Likewise, just as phone calls can be tapped, the wires carrying traffic (email and otherwise) can be tapped to capture the contents.

There are methods to ensure that your email is secure and private. In fact, you can guarantee that only the intended recipient can read the email - even if you should copy the message to other recipients.

Just as you may seal your message inside an envelope, perhaps even using a security envelope, you can wrap your email inside a container that will keep the contents secret. If somebody should tear a standard envelope open they would be able to read the contents. However, imagine an envelope that would continue to keep the contents secure even after the envelope is opened. That is the effect we have with encrypting email. Others can look at the contents but they are not meaningful until the recipient decrypts the message to read it. Both you and the recipient could store the email in encrypted form.

HIPAA GUIDELINES

For Protected Health Information to be deemed de-identified, the HIPPA "Standards for Privacy of Individually Identifiable Health Information: Final Rule" section 164.514(2) states:

  1. The following identifiers of the individual or of relatives, employers, or household members of the individual, are removed:
    1. Names;
    2. All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Census:
      1. The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and
      2. The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.
    3. All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
    4. Telephone numbers;
    5. Fax numbers;
    6. Electronic mail addresses;
    7. Social security numbers;
    8. Medical record numbers;
    9. Health plan beneficiary numbers;
    10. Account numbers;
    11. Certificate/license numbers;
    12. Vehicle identifiers and serial numbers, including license plate numbers;
    13. Device identifiers and serial numbers;
    14. Web Universal Resource Locators (URLs);
    15. Internet Protocol (IP) address numbers;
    16. Biometric identifiers, including finger and voice prints;
    17. Full face photographic images and any comparable images; and
    18. Any other unique identifying number, characteristic, or code; and
  2. The covered entity does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information.

ENCRYPTION

These requirements demonstrate that the simplest approach to sending member info across open networks (e.g. email) is to use a quality encryption product

There is an open standard for encrypting information that provides for the easy exchange between cooperating individuals and companies. This standard allows two methods for encrypting/decrypting data.

The first method requires the exchange of passwords between the participants. This can quickly get out of hand if you have to remember a password for every person with whom you communicate. If you were to receive messages from a dozen different folks you would need to know which password to use to decrypt each message. The added problem is finding a secure method by which to exchange the password!

The other method allows an individual to publish a public key. This means that anybody could send information to that individual simply by using the public key of the recipient. Only the recipient has the private key needed to decrypt the information. Thus, when you are the recipient you only need to know your private key. A hundred different folks could send you a message and you would only need your one key to decrypt each and every one of them.

On the other side, you would need to have available the public key for each person to whom you would send a message that contained sensitive information. This could quickly get out of hand if you needed to communicate with hundreds of folks.

Thankfully, technology exists that will let us quickly find and use a public key. This works in a manner similar to keeping an address book where you can quickly find and use a recipient's address (email or otherwise).

KEY MANAGEMENT

The business environment usually has a group of individuals that work together. Any member of the group can substitute for any other. Thus, encryption of data at the individual level does not make sense. Likewise, using a single key corporate-wide may not be wise. Especially if that key is also shared with the bulk transfer of information via automated EDI methods.

Therefore, a business needs at least two public keys, one for use by the bulk EDI methods and another for email. If the information content needs to be secured based at the business group level, then a company should identify those groups and create a public key for each group.

For example, the health care industry has at least the following distinctive groups: Utilization Management, Provider Relations, Customer Service, Claims, Member Services, etc. Each such group should have their own public key along with the corresponding private key. Thus, if the Customer Service private key became compromised the other keys would still be secure.

This is a good compromise between each individual having their own set of keys (where other staff members are unable to read their email when the individual is on vacation) and a single key used company wide. A single key has some additional concerns. Such as, what happens to your automated EDI interchanges when a disgruntled Customer Service employee leaves with your private key? Just as that employee would not have the keys to the President's office, you wouldn't expect them to have the keys to all of the EDI data.

PUBLIC KEY EXCHANGE

There are servers on the web that store individual or corporate public keys. A person wanting to locate such a public key can go to these servers and search to see if the recipient has posted their public key. It is easy to take this key and use it to encrypt a message to the recipient. The standard email system is then used to deliver the email. The recipient already has their private key so they will be able to decrypt and read the message. The sender can store the public key for easy use next time without having to go back to the web to look it up again. Likewise, a recipient may choose to distribute their public key directly to those who need to send them encrypted data. There are mechanisms in place to verify that the public key you received belongs to the person claiming ownership. You would be mortified to find out that private email messages to your sister where actually going to and being read by your father! Therefore, it is important to verify that the public key you are going to use really belongs to the person or company to whom you wish to send email.

This check involves contacting the intended recipient and comparing the fingerprint of their key against the fingerprint of the key you plan to use. You may choose to exchange public keys with your trading partners in a secure environment - perhaps physically exchanging diskettes in person. This needs to be done only once. Thereafter you have a secure environment in which to exchange any future keys (unless the key owner feels their key has been compromised).

PRIVATE KEY SECURITY

The best security is to never let anybody else know where your private key is located. However, in a corporate environment there will be a number of people who will need to use the same private key.

The second line of defense to ensure that somebody unwanted does not have access to your private key involves a little thing called a pass phrase. This is very similar to a password except it is longer and a lot harder to guess. A pass phrase (like a password) should be easy to remember, never written down, and extremely hard to guess. If somebody guesses your pass phrase they can steal your private key and read all messages being sent to you.

DIGITAL SIGNATURE

The signature on a letter provides an indication of who sent it. If you are very familiar with the individual's signature you gain an extra measure of confidence that the sender is really the person who signed the letter. However, when email arrives, you only know who claims to have sent it. Even if you regularly communicate with a friend, there is no guarantee that a middle person isn't pretending to be your friend.

The use of a digital signature, as part of encryption, removes a large portion of doubt (see Web of Trust) regarding who sent the information. Failure to use a digital signature is the equivalent of not signing a letter. Since the recipient's public key is used to encrypt, only the recipient can decrypt it. However, anybody with access to the public key could send an encrypted message.

When the sender both encrypts and signs the message, the recipient is able to both decrypt it and verify that the signature corresponds to the sender's public key. This means the recipient must have the sender's public key available to them. Therefore, the level of trust you have regarding the signature is a mirror image of the level of trust that the public key you have really does belong to the sender. So, if you have absolute trust in the sender's public key, then you can absolutely prove that the sender is the only person who could have signed the message. This is the only way to eliminate the possibility of a middle person acting as a go-between without either end being aware of the unwanted assistance.

WEB OF TRUST

When you receive a person's public key directly from them (they hand you a diskette that has only their public key on it) you have a very high level of trust that everything is as it appears. Especially when you look at the public key and see that it claims to be from the person who handed the diskette to you. The presumption is that you have the ability to prove who that person is or are intimately familiar with them and require no other outside proof.

But what happens when you get the public key via some third party? How much trust do you have in the third party? Perhaps they have proven to be worthy of your trust and you feel confident that they truly represent the sender.

Let's use an example to work through this. You and a few associates meet together and forge an alliance regarding a project. The communication needs to be secured and all of you agree to sign every message to negate the possibility of somebody infiltrating the alliance. Everybody generates a set of keys and makes the public key available to those in the alliance. The appropriate next step is for all of you to sign each other's public key, since you are staring at each other's eyeballs and can verify the veracity of each public key. In effect you have told anybody else who now gets a copy of one or more of these public keys that you have verified the ownership.

After a few weeks the alliance meets together with the spouses. Soon the spouses chime in that they would like to send messages using this secured method. However, nobody came prepared to generate new keys. Later, each spouse generates his or her own separate set of keys. Members of the original alliance now need only sign the public key of their spouse. At this point the public keys of the spouse could be transmitted via email to all the other spouses. Since each of these new keys is signed by at least one member of the original alliance, all members and their spouses can trust that these new keys really belong to the appropriate spouses.

Then one day your child asks your spouse to help them generate a key so they can communicate with a child of another associate. Your spouse signs your child's public key and emails it to their counterpart in the other family. Because you have signed your spouse's public key and your spouse has signed your child's public key the recipient's can be confident that this key does belong to your child. This can occur via email without needing to involve any of the associates. Nobody else but your spouse need sign your child's public key.

In a few hours your spouse receives the public key belonging to the other child. Since that key is signed by one of the parents, your spouse can be confident that it truly belongs to the other child. Thus the web expands.

This trust is dependent on two basic tenets:

  1. The person who signs a key must verify that it really belongs to the one the key claims to represent.
  2. The person whose key is signed is trustworthy to enforce tenet #1 on each key they sign.

The web of trust means that each public key you receive can be reached through some path of keys you trust, who trust some other set of keys of which one eventually trusts the key you just received. It might be a spider's web but it is only as strong as the trust exercised by each individual in the web.

Therefore, never sign a key unless you have absolute proof that this key belongs to the person asking you to sign it. Also, never sign a key unless you feel absolutely sure that the individual whose key you are signing will exercise this same level of caution.

SOFTWARE AVAILABILITY

There are publicly available and free-for-commercial use routines that provide "Pretty Good Encryption" - enough so that the US government forbade the export of these routines for a number of years. The software mentioned here will allow the exchange of encrypted information with PGP and other applications that are OpenPGP compliant.

GnuPG is an encryption/decryption program that runs on many flavors of operating systems (from Windows to Mac to Unix to Linux, etc). It is freely available for individual or commercial use from www.gnupg.org. There is a version that is easily downloaded and installed on a Windows machine located at ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-1.0.6.zip.

WinPT is an email plug-in that makes using GnuPG with Windows-compatible software a snap - simple use of a hot key combination to encrypt (ALT/SHIFT/E) or decrypt (ALT/SHIFT/D). It is also freely available for individual or commercial use via links from the above site or directly from www.winpt.org. It is easily downloaded and installed on a Windows machine. That version is located at www.winpt.org/devel/winpt-0.4.0-exe.zip.

PROPOSAL

Within the health care industry there is a need to transmit patient-identifiable information via email. There is also the need to exchange large amounts of this information via other bulk transfer methods.

Therefore, we suggest that each organization generate a public/private key pair with above normal level of security (e.g., 2048 bits long or larger). This key pair would be used for the bulk transfer of data (i.e., via FTP).

Each organization would:

  1. Arrange to exchange and sign these keys in the most secure fashion available (read Web of Trust above). This would become their main key.
  2. Generate as many other key pairs as needed by their organization based on the units within that organization.
  3. Sign their own additional keys using their main key.
  4. Install software compatible with the above-mentioned products such that outgoing email could be easily encrypted and/or signed. This same software would be able to decrypt incoming email.
  5. Distribute their public keys to their trading partners as needed (both main and unit level).
  6. Import the public keys from their trading partners such that they are readily available to those who need to send encrypted email.
  7. 7. Delegate one individual to be their Public Key administrator. This person must have an intimate knowledge regarding the Web of Trust and be trustworthy to see that all unit-level keys are signed by the organization's main key. This person would also ensure that the exchange and signing of the main public key took place under the highest level of security.

We suggest that a single public key ring be installed by each organization on their local network. This will reduce the administrative burden in distributing the public keys. A single private key ring containing only the unit-level private keys is also installed. Each private key will still be protected by the pass phrase for each unit.

This would allow the exchange of encrypted and signed email in an environment that:

  1. Allows co-workers within a unit to function even when one member is on vacation.
  2. Adheres to the philosophy behind the Web of Trust.
  3. Upon termination of an employee of a unit, provides for the easy replacement and distribution of a unit 's key.

Finally, we suggest that a group of long-term players in the health care industry put up a set of synchronized public key servers. This will facilitate the exchange of current public keys. It will also allow an organization to revoke one of its unit-level keys and issue a replacement.

SUMMARY

Installation and use of freely available software for commercial environments allows organizations to exchange sensitive information via email in a secure environment. This software can be configured to ease the management of public and private key rings within each company.

Both the Patient Bill of Rights and the HIPAA requirements point to a need for the health care industry to exchange patient- identifiable information in a secured mode. The encryption of email satisfies that requirement. Being able to digitally sign an encrypted email adds the additional security of verifying who sent the information. This will become a legal necessity should an organization need to prove from whom some information was received.

HTML transcript of  personal_and_corporate_e-mail_encryption.doc
by courtesy of its author  Stephen M. Butler   First Choice Health Network   Seattle, WA USA


connected by Silver Server Member of GILC European Digital Rights Big Brother Awards Austria
http://www.vibe.at/tools/winpt_guide/personal_and_corporate_e-mail_encryption.html
Questions/Comments to: info@vibe.at
last update: Sunday, 26-Mar-2006 13:16:56 CEST