Sending standard, plaintext e-mail containing information related to the care of an identifiable MUSC patient violates both federal law and MUSC policy. Standard e-mail provides grossly inadequate safeguards for the confidentiality, integrity, and authenticity of the information it contains, making it completely unsuitable for the communication of patient care information.
There are two potential solutions to the problem. The first approach would be to require all persons communicating patient-care related information via e-mail -- including clinicians, patients, and other parties involved in their health care (e.g. family members) -- to use inherently secure e-mail software, such as PGP. The second approach would be to implement a stand-alone Web server to support secure e-mail communications among all these parties.
The Technical Overview section provides an overview of standard e-mail communications, secure communications using PGP, and secure communications using a stand-alone Web server.
Although PGP is a better overall solution than a stand-alone Web server, there will be some users who, for one reason or another, cannot use a PGP-enabled e-mail client. Therefore, although we should recommend PGP as the preferred solution, we should also implement a stand-alone Web server as the "fall back" solution for users who cannot use PGP.
The costs of implementing, operating, maintaining and administering the proposed stand-alone Web server would be significant. However, with this Web server available, we would be able to offer both our clinicians and our patients a reasonably convenient and (to them) zero-cost way to exchange e-mail securely. While encouraging the use of PGP by those who are capable, we can avoid the high cost of supporting the use of PGP by less technically inclined users, by providing the stand-alone Web server for their use.
Over the next several years, more and more users in our target populations will be capable of using end-to-end secure e-mail protocols. As the use of PGP (and similar, standards-based protocols for secure e-mail) becomes more commonplace, the use of the stand-alone Web server would taper off, and the cost of maintaining and administering it would fall as well. Eventually, it could be retired from service.
Technical and administrative requirements, cost estimates, time frame for implementation, etc.
In this section, we consider hypothetical users Alice and Bob, and illustrate the flow of data when Alice sends a message to Bob in each of three ways: (A) via standard e-mail, (B) via PGP, and (C) via a stand-alone Web server. After following the flow of data for each approach, we summarize its relative strengths and weaknesses.
A. Standard E-Mail
Please refer to Figure 1.
Alice uses her e-mail client software to query Bob's LDAP server and obtain his e-mail address.
Alice uses her e-mail client software to compose a message to Bob, and her e-mail client software then transmits her message (From: Alice, To: Bob) to her SMTP server.
Alice's SMTP server relays the message to Bob's SMTP server.
Bob's SMTP server relays the message to Bob's IMAP server, where it is stored in Bob's mailbox. Typically, Bob's e-mail client software will then inform him that he has received new mail from Alice.
Bob uses his e-mail client software to retrieve a copy of the message from his mailbox on the IMAP server. Bob reads the message, which appears to be From: Alice.
Strengths:
Ease of use: Both Alice and Bob use the e-mail client software they are already familiar with.
Low cost: No new hardware, software, or administrative costs.
Others?
Weaknesses:
No security: Standard e-mail provides no assurance of confidentiality (messages are transmitted and stored in plaintext), no assurance of authenticity (forgery is trivial), and no assurance of message integrity (messages can be surreptitiously altered during transmission or storage).
Others?
B. PGP
Please refer to Figure 1 again.
If Alice does not already know Bob's public key, she uses her e-mail client software (with built-in support for PGP) to obtain Bob's public key from his LDAP server.
Alice uses her e-mail client software to compose a message to Bob, which she then encrypts with Bob's public key and signs with her private key, and her e-mail client software then transmits her encrypted message (From: Alice, To: Bob) to her SMTP server.
Alice's SMTP server relays the encrypted message to Bob's SMTP server.
Bob's SMTP server relays the encrypted message to Bob's IMAP server where, still encrypted, it is stored in Bob's mailbox. Typically, Bob's e-mail client software will then inform him that he has received new mail from Alice.
Bob uses his e-mail client software to retrieve a copy of the encrypted message from his mailbox on the IMAP server. Bob's e-mail client software uses Bob's private key to decrypt the message, which appears to be From: Alice.
If Bob does not already know Alice's public key, he uses his e-mail client software to obtain Alice's public key from her LDAP server. Bob's e-mail client software can then use Alice's public key to verify her signature, confirming that Alice was in fact the author of the message. Bob's e-mail client software can also verify that the message has not been altered since Alice composed it.
Strengths:
Highest security: PGP provides strong authentication, and strong assurance of message confidentiality and integrity.
Ease of use for some users: Some (but not all) e-mail client software applications can be "PGP-enabled" in a fairly transparent manner.
Reasonably low cost: No new hardware or administrative costs. Some users would need to purchase client software.
Others?
Weaknesses:
Training and support: Some older e-mail client software applications cannot be "PGP-enabled", and thus some users would need to learn and use a new, separate application for sending and receiving secure e-mail. Also, the security features of PGP, once set up, are nearly transparent, but the users of both "PGP-enabled" and native PGP e-mail client software must get past the initial configuration of the security features. Some of the configuration steps, such as generation of public/private key pairs, can be perplexing for less technically inclined users.
Others?
C. Stand-Alone Web Server
Please refer to Figure 2 now. The Web server is "stand-alone" in the sense that the Web server would not accept messages from any other e-mail servers, nor would it relay messages to any other e-mail servers, except as described in Step 3 below. All users of the Web server would need an account and a mailbox on the Web server, and so all messages "in the system" would be authenticated. Message confidentiality and integrity, at least during network transmission between the server and users' Web browsers, would be protected by SSL.
Alice uses her Web browser to log into the Web server and query the server for Bob's address.
Alice uses her Web browser with a form presented by the Web server to compose a message to Bob. When she posts the form, the Web server will store the message (From: Alice, To: Bob) in Bob's mailbox on the Web server.
The Web server sends a terse "You have mail on the Web server" message to Bob's SMTP server.
Bob's SMTP server relays the "You have mail" message to Bob's IMAP server, where it is stored in Bob's mailbox. Typically, Bob's e-mail client software will then inform him that he has received new mail from the Web server.
Bob uses his e-mail client software to retrieve a copy of the "You have mail" message from his mailbox on the IMAP server. Conveniently, this terse message contains a URL which Bob can access to read Alice's message. Bob clicks on the URL or pastes it into his Web browser. Bob uses his Web browser to log into the Web server, and reads the message from Alice.
Strengths:
Reasonably good security: The stand-alone Web server would only accept mail from authenticated, registered users. The server would require users to connect using SSL-enabled Web browsers, which would provide assurance of message confidentiality and integrity during network transit. During storage on the server, messages would not be encrypted, nor would they enjoy any protection against surreptitious modification, beyond whatever protection the server operating system provided.
Others?
Weaknesses:
Highest cost: New hardware and administrative costs. Every user of the Web server would need to be registered, including clinicians, patients, parents of minor patients, etc. Every user of the Web server would have a mailbox on the server, and someone would need to manage this storage.
Training and support: All users of the Web server would need to learn and use a new, separate user interface for sending and receiving secure e-mail through their Web browser.
Others?
Last modified: $Id: email-security-proposal.html,v 1.6 2001/05/31 13:44:38 gadsden Exp $
