Dynamic SSL Case Study #2:
Preventing Unauthorized Access to Sensitive Personal Data
Many government jurisdictions are implementing electronic health record systems allowing access to a patient's complete medical history to a variety of health care providers such as doctors, pharmacies, hospitals, emergency care providers, etc.
In this scenario, the patient's master health records and corresponding personal health number are stored on a secure server at a central Registry. Typically, a doctor's office would access the health record using the personal health number of the patient via a SSL-secured web interface to the Registry. Also, the patient themselves can review their medical history by using the same SSL-secured web interface.
Unfortunately, accessing health records with a personal health number leaves this system vulnerable, as unscrupulous employees at a doctor's office who should not have access to a patient's personal health number can steal the number and use it to access the confidential records of the patients.
Eliminating the use of the personal health number is not a feasible option given that the Registry uses a standard web interface which requires the personal health number for all their clients. The Registry cannot change their SSL-enabled system for one client without breaking it for all the other clients. Therefore, if a particular doctor's office wants to eliminate the use of the personal health number for privacy reasons, they are unable to do so.
The Solution: Using Dynamic SSL to eliminate internal access to the health number.
A doctor's office decides they will eliminate the internal use of the patient's health care number for privacy reasons. However, they still require access to the central Registry. To accomplish this, they randomly generate a "Patient ID" number that is used only within their office.
They map each Patient ID to the patient's health care number, and store the real health care number in a secure Dynamic-SSL enabled Token server that office staff do not have access to.
When a health care provider needs access to sensitive health records for a patient, they log on to the web interface of the Registry, but instead of entering the health care number (which they no longer have access to), they input the Patient ID for that patient. (Note that the web interface still expects the health care number, and does not have any knowledge of the Patient ID).
During the SSL session, the Dynamic SSL software then redirects the data stream, containing the Patient ID instead of the health care number, to the secure Token server. Inside the secure Token server, the Patient ID is replaced by the corresponding health care number for that patient. The data stream is then encrypted with the SSL keys of the Registry, and returned to the health care provider's PC, which then forwards the encrypted information to the Registry.
The Registry decrypts and processes the information, which contains the health care number, and returns the patient's health care record. In this scenario, the health care worker was able to access the Registry's web interface without ever having access to the patient's health care number, yet no changes were required to the Registry.