Towards a viable and secure health information system - Part 1

IT for HealthCare - Why it is important..

IT has influenced all most all aspects of human life - from education to communication to transport to banking & trading - for the betterment of the respective fields, and healthcare by no means can have an exception.

Large amount of medical records are generated on a daily basis which include patients' medical history, prescriptions, laboratory results, radiology reports, medications etc.

Generating, storing, maintaining and sharing them as electronic medical records (EMR) has many advantages over paper based medical records.
Making a patient's medical records available as EMRs provides easy and fast access from anywhere a patient goes for treatments which reduces cost and risk of repeating harmful diagnosis tests and treatments . It also avoids missing of any critical information regarding the patient's medical history.
EMRs interfaced with PHR (Personal Health Record) Systems provides patients the better access and control over their medical records. Also, EMRs in turn aid insurance claiming processes and providing statistics for medical research which again contributes to advancement of healthcare.

There are many initiatives and lot of research going on to realize the goal of a robust healthcare information system while protecting patients' privacy and security. But no country has yet achieved the  ultimate country wide system - AFAIK.

Concerns in adopting EHR..

Examples for PHR services that have been emerged over the past years are google health and microsoft health vault, to interface with existing EMR systems. Paper at [1] and the article at [2] talks about the issues encountered and solutions applied wrt above two services in a pilot project.

And this article [3] discusses how the non-effective healthcare information system caused discontinuation of Google Health.

Therefore, along with all the advantages, there are technical, political and practical issues in implementing a country wide robust health information system, among which security risks and privacy concerns play a major role since a healthcare system is involved with highly sensitive and critical data. 

Better the access more the advantages and more the security and privacy concerns invloved.

Research problems inspired from those concerns & my views..

I happened to read this interesting paper at [4] which discusses the recommendations made by PCAST (President's Council of Advisor's on Science and Technology) Health Information Technology Report in its chapter 5, based on the identified problems and requirements - in the space of security and privacy - in healthcare IT. 

While some of the recommended solutions in the above report can be addressed with off the shelf solutions, some opens up research problems for the research community.

This paper[1] identifies and expands research problems which are inspired by the recommendations presented in the PCAST report.

Note:  At the final stages of the series of blog posts that I have been writting on this, I found that the PCAST report on which the research paper[4] was based, has caused some arguments in the field. For an example, refer document [5]. However, the purpose of my research and these blog posts is solely to identify research problems in the space of security and identity management in healthcare information system which upon realizing, will cause human advancement, and not to advocate the PCAST report.

The paper[1] is the focus of the series of posts starting with this. There I summarize the main aspects that the paper discusses with regard to security & privacy of healthcare information systems (IS), along with my views and findings on them where applicable.

Before going into detail, following diagram illustrates the main points to be discussed around a secure healthcare IS.

Lets discuss each of the above aspects in detail..

1. Identity Management and Authentication
Lets start with the first aspect which is managing patients' identities and authenticating users in health information systems.

• Each citizen's EMRs need to be mapped with his/her identity in a robust and accurate manner. This becomes more challenging when EMRs for the same patient is generated by multiple healthcare providers. The report highlights the issue of some countries rejecting to have existing physical identities such as national identity number, social security number to uniquely identifying users and mapping EMRs to user identities which may result in issues such as mapping of one patient's EMRs to multiple identities and multiple patients' EMRs to same identity, when reconciling/merging EMRs from different healthcare providers who have used to store EMRs in different formats in legacy storage.

• On the other hand, authenticating users to access EMRs via different mechanisms such as from their PHR applications on the desktops, mobile devices etc is a critical aspect where proper authentication factors needs to be identified to avoid privacy and confidentiality breaches.

• The report identifies authentication factors in three categories: phisycal credentials, biometrics, secrets and suggests that authentication should happen involving at least two of these factors.

• The paper suggests that the obvious solution is to assign a globally unique healthcare identification number to all patients and every healthcare provider, [which of course can have political & technical issues(wrt legacy databases) involved] because without unique id, managing medical records in a large system consisting of multiple providers and many incompatible vendors becomes a problem as discussed above as well.

• As paper identifies, research problems that are inspired by the above discussed requirements and issues include:

          1. developing/improving existing biometric techniqques to identify individuals          

          2. developing techniques to reconcile data from different sources

          3. developing authentication techniques that are less vulnerable to attacks

Let me mention my views on the above aspects based on my knowledge of existing solutions in the domain and my findings about ongoing research efforts in the domain:

• I too strongly agree with the paper's suggestion on assigning a globally unique id to index individual's EMRs.

Regarding identity management and authentication:

• Although different healthcare providers participate in a country wide  healthcare information system, citizen's identity should be maintained with a centralized trusted authority  which we can identify as the identity provider(IdP) in the entire system. This can be considered as provided by national security infrastructure. Thereby we can avoid having duplicated patients' identities in different systems and also multiple credential anti patterns. Individual healthcare service providers can integrate with the central system and act as relying parties to retrieve a particular user's identity information and to rely on getting the users authenticated from the identity provider.

• With that type of interaction between the systems, existing web based authentication mechanisms such as SAML2 Web browser based Single Sign On and OpenID based decentralized Single Sign On can be used to provide users with seamless access to different portals/web applications in the healthcare information system while managing identity and authentication at a single place.

• And if it is a web service of a  third party healthcare service provider that the user needs to authenticate to, brokered authentication mechanisms built on top of WS-Security such as WS-Trust can be used.

• But in this kind of a centralized identity and authentication management  system, authentication at the central identity provider should be performed based on strong authentication factors including biometrics (such as fingerprint which can be supported easily than other biometrics based authentication)  because an attack at the IdP can lead to attacker gaining access to patient's identity and seamless access to other applications to access EMRs and PHRs.

• An example implementation of XMPP based multifactor authentication to avoid phishing attacks on OpenID provider, can be found here. Some research projects have analyzed different authentication mechanisms including biometrics. For eg: "Human Factors in Online Security and Privacy" project[6] in CERIAS has done such analysis.

• Further, when enforcing authentication at the back-end web services which expose different types of EMRs of a patient and which are usually accessed through different user applications (such as web portals, mobile applications, PHR applications etc) by different principals (such as doctors, laboratory scientists, patients etc), it is better to use  mutual  authentication based trusted sub system pattern where only the trusted applications are allowed to access BE services on behalf of the users who were authenticated at the front end applications. This avoids users credentials being propagated to BE services which expose sensitive EMRs  and thereby reduces the risks that can be caused by individual user credentials breaches. By this way, authentication and authorization of the individual users can be performed at two different layers for which I will give an example in a future post.

• In summary, we discussed identity management and authentication aspect of HealthCare IS in detail in this post and it is clear that there should be an agreed unique identity attribute to map patients' records and while there are number of existing solutions that can be used address the issues in this aspect, there are active research in identifying better and stronger authentication mechanisms.

To be continued...

In this post, we only discussed one aspect out of the several aspects illustrated in the above image, related to a secure healthcare information system. We'll discuss about the other aspects explored in the paper at [4], in the coming posts.

Motivation...

I am passionate about the research carried out in the area of healthcare information systems - mainly related to the security and privacy aspects of it, being computer security is the area of my preferred specialization.

And I believe that I have come across a great paper during the research on the $subject.

The paper[1] has successfully achieved its goal of drawing the attention of the security and privacy research community on the problems in health care IT that needs new solutions, based on the requirements and recommendations highlighted in the PCAST report on health information technology.

References:
[1] The military health system’s personal health record pilot with Microsoft HealthVault and Google Health
[2] Personal Health Records In Action: Google Health and Microsoft HealthVault
[3] How a Broken Medical System Killed Google Health
[4]   A Research Roadmap for Healthcare IT Security inspired by the PCAST Health Information Technology Report
[5] PCAST Workgroup Letter to the National Coordinator
[6] Human Factors in Online Security and Privacy

Security Patterns - Direct Authentication & Role Based Access Control

Authentication and authorization are vital aspects of any secured system or service which expose business assets to outside. Authentication itself is not sufficient when you want to restrict access to different resources for different types of authenticated users.

There are different authentication and authorization patterns.

In this post we will look at how to implement direct authentication and role based access control.

Direct Authentication

In direct authentication, clients share their credentials with server through a trust relationship established prior to the actual service invocation - eg: during user registration.
And when the client accesses the secured service, provided credentials are validated against the ones stored in the user store.
We call this direct authentication since the server itself stores client's credentials and validates them at authentication.

Role Based Access Control
Authorization models have evolved over time. In role based access control, users are assigned to a particular role and the permissions to that role. This is scalable than user-centric permission model where permissions are assigned per user, but coarse grained and coupled with application code as opposed to policy based access control which we'll look at in a future post.

Let us secure a service with above security mechanisms using WSO2 open source Enterprise Service Bus (ESB).

Overview
Before taking you through the steps, following is the architecture diagram of our solution.

- BE Service which exposes the actual business logic is fronted by a proxy service in ESB so that BE service is not exposed to out side directly and also we can enforce all the QoS, auditing, necessary transformation at ESB in this way.

- Proxy service is secured using Web Service Security mechanism to require a UserName Token(containing user name, password of the user) to authenticate the user and RBAC to authorize the user before invoking the BE service.

- User credentials are stored in Active Directory user store connected to ESB.

 Steps:
1.Download and extract latest ESB pack from here.

2.Configure Active Directory as User Store : locate user-mgt.xml file from [ESB_Home]/repository/conf and enable the ActiveDirectoryUserStoreManager element and provide appropriate information to connect to AD in your domain. (WSO2 products can be integrated with heterogeneous user stores and you can connect to any user store that you prefer.)

3.Start the server and access the management console from the browser: https://localhost:9443/carbon and login with credentials : admin, admin.

4.BE Service : Echo Service in ESB will serve as the BE service in our above deployment. Obtain its url(http://localhost:8280/services/echo) and wsdl(http://localhost/services/echo?wsdl) which will be used to create the proxy service.

5. Proxy Service: From left hand panel, select "Services->Add->Proxy Services" and create a pass through proxy with name "SecuredEchoProxy", url and publish wsdl url with the ones obtained in the previous option.

6. Applying Security: Go to the proxy service's dash board like the one shown in above image and select "Security" under Quality of Service Configuration.

Enforcing Authentication:

- select enable security -> yes
- select the WS-Security mechanism we are going to apply -> Username Token

Enforcing Authorization:

- Click Next.
- Select which Roles are authorized to access this resource.

- Finish applying security.

You can invoke the proxy service from SOAP UI client or a java client with different user names belonging to different roles and test.

I have attached a maven project here with a java client which can invoke a service secured with UserName Token security policy.

UserName Token Security Policy:

Message Communication:
Request:

   
      
         
            2012-09-15T12:21:11.203Z
            2012-09-15T12:26:11.203Z
         
         
            admin
            admin
         
      
      https://localhost:8243/services/SecuredEchoProxy 
      urn:uuid:a205c52e-0d22-465b-87c4-8192de4e3cbc
      urn:echoInt
   
   
      
         1
      
   

Response:

   
      
         
            
               2012-09-15T12:21:11.824Z
               2012-09-15T12:26:11.824Z
            
         
         urn:uuid:6ece26cd-e349-4246-9481-7b05f6d928c1
         urn:echoIntResponse
         urn:uuid:a205c52e-0d22-465b-87c4-8192de4e3cbc
      
      
         
            1
         
      
   

Remarks:
1. Request message contains user name and password of the user according to the UserName Token profile of WS-Security. Since password is sent in plain text, the security policy enforces a transport binding which requires HTTPS to be used in message communication to provide confidentiality at transport level.

2. As security policy requires, both request and response contains timestamp values to avoid replay attacks.

3. Rampart is used as the underlying SOAP security processing module. In the security policy shown above, rampart specific configuration is commented out for the  purpose of clarity.

Digital Signature by Example

We use digital signature for two main purposes in message communication:

1. To guarantee the integrity of the content (i.e to ensure that message has not been changed during transmission from sender to receiver)

2. To authenticate the message origination (i.e to verify that the message was sent from the party that we think it is sent from)

We use cryptographic mechanisms to generate and verify digital signature.

Before going into the code level, let me briefly mention the steps involved in creating and verifying the digital signature.

Pre-requisites:

Have your keystore created with private key and public key. You can refer to the posts at here and here for the steps in creating a keystore with private/public key pair using java keytool.

Creating digital signature at the sender:

1. Computing the hash value of the content to be signed...

Here we use hash functions in cryptography to create a fixed length hash value such that it is impossible to calculate the original content or the length of the content from the hash value. This is called message digest or one-way encryption. Hence hash functions provide a digital fingerprint of the content to be signed.

2. Encrypting the hash value with his/her private key...

Here we use asymmetric key cryptography to encrypt the hash value computed from the message content.

Verifying digital signature at the receiver:

1. Decrypting the signature and obtaining the message digest..

Receiver once again applies asymmetric key cryptography to decrypt the message signature using sender's public key. 

How does the receiver obtain sender's public key?

It can happen in different ways according to the message communication protocol that you use. Usually communicating parties can exchange keys before the message communication, in a trusted way or the sender can send the certificate containing the public key along with the signed content and the signature. It is not recommended to send the public key itself since it is susceptible to MIM attacks. You can read more about it from here.

At this step, message origin authentication happens. Since only the one who owns the private key related to the public key used to decrypt the signature, can sign the message - we can identify who has sent the message.

2. Comparing the hash values to verify message integrity...

Receiver computes the hash value on the original message and compares it with the hash value sent by the sender, which was obtained in the above step after decrypting the digital signature. If the two values are identical, receiver can verify that the message integrity is protected during the transmission.

Now let us see how we can create and verify digital signature over some text content with an existing private/public key pair in the keystore named 'mykeystore.jks', using Java Security API.

I hope the comments in the following source code will help you understand each step performed in doing this.

package org.digital.signature.sample;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.security.*;
import java.security.cert.*;
import java.security.cert.Certificate;


public class Sample {
    //keystore related constants
    private static String keyStoreFile = "/home/hasini/Digital-Signature/sample/src/main/resources/mykeystore.jks";
    private static String password = "mypassword";
    private static String alias = "mycert";

    public static void main(String[] args) {

        try {
            KeyStore keystore = KeyStore.getInstance("JKS");
            char[] storePass = password.toCharArray();

            //load the key store from file system
            FileInputStream fileInputStream = new FileInputStream(keyStoreFile);
            keystore.load(fileInputStream, storePass);
            fileInputStream.close();

            /***************************signing********************************/
            //read the private key
            KeyStore.ProtectionParameter keyPass = new KeyStore.PasswordProtection(storePass);
            KeyStore.PrivateKeyEntry privKeyEntry = (KeyStore.PrivateKeyEntry) keystore.getEntry(alias, keyPass);
            PrivateKey privateKey = privKeyEntry.getPrivateKey();

            //initialize the signature with signature algorithm and private key
            Signature signature = Signature.getInstance("SHA256withRSA");
            signature.initSign(privateKey);

            //Read the string into a buffer
            String data = "{\n" +
                          "  \"schemas\":[\"urn:scim:schemas:core:1.0\"],\n" +
                          "  \"userName\":\"bjensen\",\n" +
                          "  \"externalId\":\"bjensen\",\n" +
                          "  \"name\":{\n" +
                          "    \"formatted\":\"Ms. Barbara J Jensen III\",\n" +
                          "    \"familyName\":\"Jensen\",\n" +
                          "    \"givenName\":\"Barbara\"\n" +
                          "  }\n" +
                          "}";

            byte[] dataInBytes = data.getBytes();

            //update signature with data to be signed
            signature.update(dataInBytes);

            //sign the data
            byte[] signedInfo = signature.sign();

            System.out.println(signedInfo.toString());

            /**************************verify the signature****************************/
            Certificate publicCert = keystore.getCertificate(alias);

            //create signature instance with signature algorithm and public cert, to verify the signature.
            Signature verifySig = Signature.getInstance("SHA256withRSA");
            verifySig.initVerify(publicCert);

            //update signature with signature data.
            verifySig.update(dataInBytes);

            //verify signature
            boolean isVerified = verifySig.verify(signedInfo);

            if (isVerified) {
                System.out.println("Signature verified successfully");
            }
            
        } catch (NoSuchAlgorithmException e) {
            e.printStackTrace();
        } catch (KeyStoreException e) {
            e.printStackTrace();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (CertificateException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        } catch (UnrecoverableKeyException e) {
            e.printStackTrace();
        } catch (UnrecoverableEntryException e) {
            e.printStackTrace();
        } catch (InvalidKeyException e) {
            e.printStackTrace();
        } catch (SignatureException e) {
            e.printStackTrace();  
        }
    }
}

References:

[1] http://docs.oracle.com/javase/tutorial/security/apisign/index.html

[2] http://www.garykessler.net/library/crypto.html#intro