In healthcare systems, Electronic Health Records (EHRs) contain sensitive information, such as all the patient records and doctor prescriptions, and these are stored on a medical server. Preserving the confidentiality of this vital information is an important issue in these systems. The system should have the means to avoid unauthorized users to access this information. This security problem is also tackled in the ProTego project, where an access control mechanism is developed as part of an integrated toolkit for data protection in healthcare. Without the appropriate access control mechanisms in place, it is impossible to protect the EHRs.
Traditionally, hospitals use either local servers or cloud systems to store these EHR data and medical staff (employees in the hospital) can access this information with some pre-defined access control rules. In this scenario, the access control is static (define once – used many times). Such an access control mechanism typically uses a Role-Based Access Control (RBAC) model. In the general RBAC model, the roles are assigned to the users and the permissions are assigned to the roles. There are also some constraints and role hierarchies defined in other RBAC models such as RBAC1, RBAC2 and RBAC3. For instance, the user can be a human and the role is a job function or job title like “doctor”. The permission is approval of the access to one or more objects in the system (this can be the patient’s information in the healthcare system). The holder of the permission – i.e. the authorized user – is then allowed to perform some action(s) on the object in the system, for example read or write access.
In the RBAC1 model, which is based on role hierarchies, there are senior and junior roles such as doctor and nurse roles, respectively. The doctor who is senior to the nurse inherits all permissions from the nurse. The doctor role can also have extra permissions in addition to those inherited from the nurse. In RBAC2, the same user is not permitted to have two roles, because this might lead to fraud. Finally, RBAC3 is a combination of RBAC1 and RBAC2.
Nowadays, the recent trend towards Bring-Your-Own-Device (BYOD) and the use of smart devices introduces several new security and privacy challenges to healthcare systems that cannot be tackled by RBAC. Fortunatelym, the Attribute-Based Access Control (ABAC) model can be an alternative solution for RBAC. In ABAC, the user can access the data if and only if s/he has all the attributes the data is associated with. Some basic ABAC models rely only on pre-defined static attributes such as “user identity”, “user role’’ and ‘’user company’’. In this ABAC model, the user will receive the credentials to access the data if s/he has all the attributes. However, s/he can access the data forever and anywhere using her/his mobile device. There are cases where one wants to avoid this. For example, suppose the user would access the data in a public place. Anybody within proximity could easily see the confidential data via shoulder surfing. Or even worse, an attacker could have stolen the mobile device and get unauthorized access to the data. The problem here is (1) that there is no real-time verification and (2) the mobile device stores all the static attributes inside the device. These security problems can be prevented by relying on the full potential of ABAC. More specifically, by using some dynamic attributes such as “time” and “location”, one can overcome the problem mentioned before. This enhanced ABAC model now stipulates that the user both needs to provide static attributes and dynamic attributes, the latter derived from the user behavior, to be granted access. In fact, an ABAC model which is based both on dynamic and static attributes can provide robustness against mobile device compromise attacks.
One can go even one step further. Due to the sensitivity of the healthcare records that are outsourced to the cloud, this information should remain confidential – i.e., encrypted – for everyone except the authorized user. Thus, integrating techniques such as Attribute-Based Encryption (ABE) into ABAC makes it possible to encrypt the outsourced medical information and protect these from the cloud system itself. Even if a malicious insider would get access to the cloud system, (s)he would not be able to retrieve the plaintext data. Within the ProTego project, this research direction will be further explored and integrated into the final version of the access control framework.
This blog post was written for the ProTego project by Farhad Aghili (KU Leuven – COSIC).
