Introducing Usage-Based Encryption for a Secure and Versatile Access Control Scheme of Electronic Health Records on Cloud 1

In this study, we introduce Usage-Based Encryption (UBE) approach for a secure, efficient, ubiquitous and versatile management of Electronic Health Records (EHRs) on cloud. The primordial feature lies in delegating the fundamental security guidelines and procedures to the patient in terms of encryption, access control and digital signatures. In contrast with other frequently used approaches, the proposed scheme grants the patient enhanced independence from cloud providers’ policies and thus, renders increased administrative authority while sustaining a highly flexible and resourceful configuration. A comprehensive scheme is painstakingly detailed to encompass all tangible situations pertaining to a highly effective control of the EHR in a platform-free sphere. As a matter of fact, encryption and hashing modi operandi are scrupulously and relevantly fixed on to guarantee Confidentiality, Integrity and Availability (CIA). Furthermore, privileges and revocation of access are discussed in their minutiae from a usage perspective to provide patients broader maneuverability of their health records prior to housing them on clouds.


INTRODUCTION
P4 medicine or what is referred to as "Personalized, Predictive, Preventive and Participatory medicine" seems to pave a new age for an ever evolving and more daring approach to healthcare, worldwide.Promising measurement-and-diagnosis emerging technologies, almost-application-unlimited computational capabilities and ubiquitous access and/or transfer of information online using either internet or outernet infrastructures, have invigorated this promising avenue to start infiltrating into the medical system for numerous pertinent and relevant reasons.Examinations need no more take place at hospitals or clinics, but can be done "anywhere" and specialists or even intelligent expert systems would instantaneously analyze and make decisions in terms of prescriptions, medical conditions, prognosis, emergency alerts, etc.On the other hand, accessibility of patients' medical records might unveil hidden snags and pitfalls and seems to turn into a source of dilemmas and controversies regarding who should own the "medical data"; the use of connectivity for data availability and transmission can be easily intercepted and meddled for nefarious purposes.Issues of privacy and legal facets just add to the challenge but would certainly not hinder throwing down the gauntlet of traditional medicine, at least not for a long time, before witnessing the transformation of the entire process toward a more effective and somehow unavoidable path (Hood and Friend, 2011;Hood and Flores, 2012;Flores et al., 2013;Younesi and Hofmann-Apitius, 2013;Topol, 2015;Pack, 2016;Shortliffe and Cimino, 2013).
Recently, up-and-coming various strains and conundrums defy CDCs (Center for Disease Control), welfare and Businesses at large such as impending pandemics and their sequelae, safety and security repercussions associated with key personnel working in public enterprises such as nurses, doctors, aircraft crews, teachers and many other sensitive vocations and professions, etc., and which all endorse the idea of having some medical data obtainable within certain frameworks.Paper charts still exist in clinician offices, medical centers and hospitals; nonetheless, Electronic Medical Records (EMRs) and which are the digital versions of such information, reveal more beneficial and advantageous because they empower healthcare providers and officials with the capacity of tracking, identifying and preventing the aforementioned related issues; they are more legible, of course, as well.Furthermore, Electronic Health Records (EHRs) are devised now to be more broad and comprehensive hence, encompassing contact information, historical figures and mostly all relevant details to patients and their families, collected from healthcare providers of all kind and aim at sharing that information with authorized agencies and stakeholders such as laboratories, specialists, diagnosticians, legal experts, etc., across patients' country and sometimes beyond borders.EHRs can be used for quality improvement, population reporting, clinical research, health statistics, standardization, etc., (Bresó et al., 2015;Alyass et al., 2015;Ball and Lillis, 2001;Shortliffe and Cimino, 2013;Bates et al., 2001;Dolin, 1997).
EHRs are even inclusive of conditions of being sound in body, mind or spirit, freedom from physical disease or pain, etc., encapsulating the fact that the word "health" ranges more in sphere than the word "medical".This is in contrast with Personal Health Records (PHRs) which are privately managed by patients to follow up on their own health information yielding no public interest and/or concern in any way, shape or form.This raises the vital question of how to protect data from intruders and malicious attackers if we were to implement rife and omnipresent online medical databases and platformindependent applications (Dolin, 1997;Iakovidis, 1998;Papagounos and Spyropoulos, 1999;Garets and Davis, 2006).
In this study, we propose a quite outright stratagem that efficiently achieves bridling the setbacks and hitches of a "traditional" platform in order to secure the two paramount objectives of autonomy and nonmaleficence.Our promising approach relies on segregating EHRs into four primary segments based on a combination of parameters such as content, usagepurpose and sensitivity.Furthermore, different concomitant management subsystems in terms of encryption, access control and revocation, are used to ultimately and eventually provide a secure encapsulation of data onto cloud.Not only data will be encrypted when stored, but during upload/retrieval to/from cloud, as well.Besides, those actions shall be carried out while sustaining an optimal use of resources such as computational cost, management and storage space (Garets and Davis, 2006;Morton and Wiedenbeck, 2009;Collins et al., 2011;Kluge, 2004).
Usage-Based Encryption (UBE) will primarily depend on three variants of Federal Information Processing Standards (FIPS): the Advanced Encryption Standard (AES), the Rivest-Shamir-Adleman (RSA) and the Secure Hash Algorithm (SHA), which have been broadly adopted in innumerable applications because of their multifaceted virtues.Access control and revocation, privileges and other relevant security issues are devised in the context of securing the three main CIA components of a sound and sustainable EHR.
Furthermore, the entire EHR will be hosted on cloud which offers a ubiquitous and unlimited platform with a multitude of advantages when compared to other more traditional ones.Nonetheless, hosting information on cloud comes with a price: security is not absolutely guaranteed.Particularly, two critical and fundamental issues constitute imminent trust issues and risks: immunity of the algorithms used against attacks and administration.Our strategy includes tackling those major setbacks by giving the hand to the patient for optimal customization.This would remarkably find applications in developing countries where no structures for secure platforms exist to begin with (Bahga and Madisetti, 2013;Narayan et al., 2010;Zhang and Liu, 2010;Basu et al., 2012;Löhr et al., 2010;Xavier and Chandrasekar, 2015).
The main forte of the proposed scheme lies in endowing the patient with the lead in managing the EHR which will be fashioned on a usage-based platform rather than attributes or other more advanced parameters, whilst upholding a realistic user-friendly handle.Indeed, patients are becoming more involved in technology, managing smart devices and will inevitably be grasping IoT hence the proposed strategy would indubitably come home to them (Narayan et al., 2010;Zhang and Zhang, 2011;Yang et al., 2015).
This study will be divided in three sections.In the first one we will recall, validate and highlight the tools used in our platform; the second part will thoroughly encompass the core of the modus operandi which is entailed by the proclaimed lead via a systematic allocation of the tools in corroboration of specific and pertinent EHR component usage.A conclusive third section shall wrap up the presented components with key insights to the advantages and effectiveness of the overall structure.

LITERATURE REVIEW
Cloud computing: Cloud computing or simply cloud, is a physical, yet end-user virtual infrastructure which provides ubiquitous, utilitarian, per-demand access to remote, distributed and shared computing resources such as servers, applications, storage, networks, etc. and which can be swiftly supplied and freed up or idled with marginal supplier interface.According to NSIT, the model is composed of 5 essential characteristics, 3 service models and 4 deployment models.Core and prime interests in this context lie in the fact that cloud offers capabilities that appear both unlimited and omnipresent to the client throughout various physical and virtual resources subtending storage space, computational capabilities, bandwidth, etc., via dynamic allocation, contingent on the setup request.Moreover, the three service models -Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) -as well as the various deployment models (e.g., private, community, public and hybrid)offer an unprecedented and unequaled platform to deploy applications, memory and connectivity at their finest!Cloud was introduced in the late 2000s to allow for economies of scale over networks thus, granting organizations, companies, institutions, etc., the capability of moving from CAPEX (Capital Expenditures) to OPEX (Operational Expenditures) models of business via delivering maximal efficiency of shared resources and drastically reducing those businesses' infrastructure cost which would then be able to contemplate on their vision and ultimate objectives minus worrying about resource expertise, licensing, management, maintenance, operability, provision, etc., (Deepika et al., 2015;Griebel et al., 2015;Yang et al., 2015;Liu et al., 2015bLiu et al., , 2015a)).
Cloud is a growing grid witnessing a rapid growth of approximately 50% every year, yet its major setback resides in security and privacy issues.Information belonging to one client could be accidentally delivered to another as well as it might be simply intercepted by malicious attackers with villainous and/or iniquitous schemes.Consequently, even though cloud offers an unquestionably beneficial advantage for application and data storage, information need be protected against both intentional and unintentional misfortune (Jin and Chen, 2015;Ali et al., 2015).

Advanced Encryption Standard (AES):
The workhorse of our encryption process is the Advanced Encryption Standard (AES), a matrix-based data structure relying primarily on substitution-permutation networks.AES is fast in both software and hardware implementations.AES is interchangeably referred to as the Rijndael Cipher Algorithm which has been selected, after five years of standardization, by the US National Institute of Standards for Technology (NIST) in 2001 amongst fifteen contending algorithms to become the first publicly open cipher symmetric-key algorithm approved by the National Security Agency (NSA) for sensitive information (Rijmen and Daemen, 2001;Daemen and Rijmen, 2002;Standard, 2001;Sanchez-Avila and Sanchez-Reillol, 2001).
AES is in point of fact a variant of the Rijndael algorithm created by two Belgian cryptographers, Joan Daemen and Vincent Rijmen with a family of ciphers of various sizes pertaining to both keys and blocks; NIST selected only 3 different-key length versions but with a fixed block size, however.AES is included in the International Organization for Standardization/ International Electrotechnical Commission ISO/IEC 18033-3 standard where specified-length string-of-bits symmetric systems used to produce ciphertexts, denoted as block ciphers, are stipulated.
AES was designated as the US Federal Information Processing Standard (FIPS) 197; FIPS are specified standards devised for use in computer systems by nonmilitary government agencies or contractors with the aim of establishing requirements affecting computer security and interoperability where apposite conventions do not already exist; they customarily consist of tailored versions of those standards used in technical communities such as the American National Standards Institute (ANSI), the Institute of Electrical and Electronics Engineers (IEEE) and the International Organization for Standardization (ISO).The AES algorithm supplanted the Data Encryption Standard (DES) which was based on Horst Feistel design developed at IBM in 1977 and entitled as the FIPS 46-3 (Rijmen and Daemen, 2001;McLoone and McCanny, 2001;Akkar and Giraud, 2001;Nechvatal et al., 2001).
AES is a much more advanced algorithm in comparison with its precursor DES in terms of security and immunity against attacks.AES addressed two fundamental weakness and vulnerability issues; the encryption-key length has been multiplied and 128-, 192-and 256-variants were developed, making the algorithm unbreakable to known practical attacks that would allow anyone to read correctly implemented AES encrypted data.AES also refashioned the design and size of the encrypted block; it doubled its size which drastically augmented the amount of information that can be sent before engendering identical blocks which would probably yield to information leaking; this amount soared from 32 gigabytes to 256 exabytes (or 256 billion gigabytes).Moreover, AES' McCoy banks on a series of substitution and permutation instead of using the balanced Feistel network which renders the entire structure dramatically further immune to attacks.Finally, the U.S. Government announced that AES could be used to protect classified information in June 2003 and in 2011, Bogdanov et al. (2011) completed the first key-recovery biclique attack on full AES, which is faster than brute force by a factor of about four and concluded that theoretical attacks have no practical knock-on effect on AES security whatsoever in this context.In fact, the authors were visiting Microsoft Research Redmond while working on the results which proved that it requires 2^126.1 operations to recover an AES-128 key meaning that it would take billions of years for recovery as well as the need for storing 2^88 bits of data equivalent to about 38 trillion terabytes of data-more than all the data stored on all the computers on the planet (Sanchez-Avila and Sanchez-Reillol, 2001; Nechvatal et al., 2001;Alanazi et al., 2015;Yang et al., 2015;Guo and Yau, 2015;Nagaty, 2015;Alshehri et al., 2012).

Rivest-Shamir-Adleman (RSA):
In symmetric-key cryptography, every partaker has an identical private key.As the number of stakeholders increases, the transaction in question becomes more in jeopardy.An additional downside of symmetric-key cryptography is that the process is drastically slowed down (about thousand times) for every encryption/decryption maneuver compared to Public-Key Cryptosystems (PKCS).In the latter configuration, the key distribution is much easier since only the private key must remain confidential and thus, fewer keys need be generated -O (n) compared to O (n^2) (Thakur and Kumar, 2011; The owner chooses the persons or institutions he wishes to grant privileges to for each of the Prvt-ER, Say for example U1, U2, … Ui.
The owner chooses the persons or institutions he wishes to grant privileges to for each of the Prvt-Med, Say for example G1, G2, …Gj.
The owner chooses the persons or institutions he wishes to grant privileges to for each of the Prvt-NoMed Say for example R1, R2, ... Rk.The owner gets the public keys of the users so he will have kU1pub, KU2Pub, ... KUiPub.
The owner divides his data into subgroups D1, D2, … Dn where each subgroup is of a specific nature for example labs, x-ray, prescription… The owner gets their public keys by using their certificates so he will have KR1pub, KR2Pub, ... KRkPub.
The owner fills in the matrix: 1 0 1 is used when the owner wants to give privilege to the user for the group of data, 0 is used otherwise.A clustering algorithm is be used on the matrix.Such as cl1: (D1, D3), cl2 (D3, D6.), cl3… For each cluster the owner create a common symmetric master key MasterKey1, MasterKey2 and MasterKey3.The owner sends the masterKey1 to the all users in the group encrypted by their Public Key, For example send MasterKey1 as follows: E (Masterkey1, KG1Pub) to G1, E (Masterkey2, KG2Pub) to G2… The owner chooses different symmetric keys K1, K2, … Kk and applies E (K1, KR1pub) and sends to the user R1 same for all the other users.who are usually few.
The owner posts the public data in addition to its signed hashing on the cloud.
The owner posts all of this data on the cloud.
The owner encrypts the data for example D1.By applying E (D1, K1) and posts on the cloud.Same for the rest.Accessing data by legitimate users Any user can read the above data.In addition, any user, having the public key of the owner can verify the integrity of the data.
Any user Ui who wishes to have access to this data can use his private key to apply E (E (Prvt-ER, KUipub), KUipriv) and accesses the data.
Any user who wishes to access the data can apply E (E (Masterkey1, KG1Public), KG1Priv) and obtain masterkey1.Then, the user can use the Masterkey1 to apply D (E (cl1, MasterKey1), Masterkrey1) and have access to the data in the cluster.
Any user Ri who wishes to have access to this data can use his private key to apply E (E (K1, KRipub), KRipriv) and accesses K1.Later he can use K1 to apply D (E (D1, K1), K1) and accesses the data.

Revocation of access
No revocation is needed.
In case of revocation of access the data is re-encrypted with a new master symmetric key.
based on two ultimate and fundamental properties: document-centric and data-centric.
A typical medical record embraces elements such as a document header where rather conventional demographic data are established -for instance, patient name, gender, address, date of birth, identity card number, patient health number, some relevant dates of admission/discharge, etc. History, physical and consultation reports constitute another element which subtend information pertaining to history of present illness, past medical history, medications, physical examination in terms of vital signs (heart rate, pulse, blood pressure and body temperature), diagnostics, assessment and prescriptions, procedure history and results, allergies and adverse reactions, social and family history in terms of risk factors, marital status, psychological health, genetics, etc.Finally, operative and discharge reports constitute an additional and essential element in case the patient had undergone surgeries with the aim of underlying diagnoses prior and post procedures including looming complications.
Be that as it may, EHR will be viewed differently from the patient's perspective in terms of privacy and secrecy of information and thus, will be accordingly segregated and divided to reflect specific requirements when sharing information is on the Table 1.The proposed scheme spares the patient from digging into advanced concepts and offers a user-friendly platform to manage access control, encryption level and revocation of privileges; it rather subdivides data based on its usage.Additionally, it offers an effective tool for patients to preserve their right to privacy, particularly in countries or environments where no systematic policies are implemented in the context of a typical EHR and where no security/privacy legislation are in place, such as HIPAA in the United States.
Our method is founded on dividing EHRs into the following 4 components: • A public component designated by Publ-ER and which is related to impromptu and urgent situations such as when patients are administrated by ER medical personnel; this component shall comprise data such as contact information, blood type and other records that are purposely chosen by patients such as allergies and the like.• A private component designated by Prvt-ER that resembles the previous component with the main difference lies in the content; data is more sensitive and patients shall specify the type of information and the users who would be allowed to access and/or transfer them.The content is truly broad and subtends information such as pieces or entirety of their chronological records in terms of illnesses, treatment, prescriptions, surgery, etc. • A private component designated by Prvt-MED and which refers to more specific, case-dependent, targeted and/or personal information that is shared by a patient with doctors and diagnosticians whether those are specialists, generalists, or family doctors and thus, information here shall consist of diversified medical data in terms of laboratory tests, all kind of medical imaging and radiography (Xrays, MRI, CT-scan, fluoroscopy, etc.), chronic diseases, illnesses, procedures, other health issues (mental, psychological, etc.), therapies, medications, etc.
• A private component designated by Prvt-NoMeD and which refers to rather non but related to, medical information such as insurance-and financial-related data, subject matters pertaining to family/friends/acquaintance, etc.

RESULTS AND DISCUSSION
As mentioned before, Fig. 2 shows complete setup of the EHR which is divided in our simulation into 4 parts and are fully controlled by the patient.

Publ-ER part of the HER:
The first part, as in Fig. 3, called Publ-ER, contains any data that the patient judges is necessary to be accessed during emergency cases.This data is hashed first using a hashing algorithm and then the hash is encrypted with digital signature using the private key of the patient.This data is uploaded to the cloud and either a convenient message sent to the concerned party (ies) or carried on with the patient himself.
Hashing algorithm, as in Fig. 4, should only be used for verification of integrity.The data could be Hashed using SHA256 algorithm, a 256 character is created.The Hash is then encrypted using signer's private key.
The patient should choose to have his Name, Date of Birth, Blood type, any organ donation if exist and any information should he chose to have access to any emergency team.
The emergency team could have access to all chosen data available for them but the first they should check its integrity and authenticity, as in Fig. 5, to make sure that the data is not altered in any way or form.
While the data is available as text format with its Encrypted HASH character, the team could decrypt the HASH using the signer's Public Key and compare it to the HASH of the data itself, if it matches then the data is authenticated and verified.

Prvt-MED and Prvt-No MED parts of the EHR:
For the 2 nd and 3 rd parts, Prvt-MED, as in Fig. 6 and Prvt-No MED, as in Fig. 7, the patient uses Symmetric encryption and uploaded to the cloud, but with one key shared between both parties the patient from one side and his family members from the other side.
The Symmetric encryption used can be simulated using Matlab GUI, as in Fig. 8, it can encrypt a text file as well as an image sourced from for example sourced from an X-Ray machine.That same GUI is simulated so that both encryption and decryption are both tested.
The Matlab GUI will create a security code to be initialized and saved for later use for the decryption to recreate the image as in Fig. 9.It will also input the  While on the other side, the second part of MATLAB GUI, as in Fig. 10, will be required to decrypt the encrypted image.
The MATLAB GUI will use the same security code required to decrypt the image, will show the encrypted image, its decrypted image as well as the time taken for the system to decrypt.
The AES Symmetric encryption takes a readable data, whether a plaintext or image, scrambles it and transfers it to unreadable, then transfers it again to readable when needed.It is generally fast.The most important thing to remember is that both sides-the patient and the hospital/doctor need access to the same key.

Prvt-ER parts of the EHR:
The last part of the EHR, Prvt-ER, as in Fig. 11, uses Asymmetric encryption, uploaded to the cloud and a convenient message is sent to the concerned parties for pre-visit discussion as it is slow to decrypt.
The asymmetric encryption method (RSA) transfers the raw data also from readable to unreadable but with a twist of having 2 keys called public and private where the patient will have his private key stored in a private place for encrypting his data while having his public key known to all for decrypting.This same process was simulated using MATLAB RSA tools having images as well as text.
The objective of this study is to shed the light on a comprehensive structure for an innovative approach in dealing with patient, medical and health records.The idea is to incorporate the advantages of each of the aforementioned records' skeleton and curb the drawbacks of those existing platforms in the frame of a free, autonomous, versatile and omnipresent system that could be managed by patients and/or other "authorities".In few words, the main objective is to create a system that secures autonomy and non-maleficence in handling those records.The system relies on what we referred to as UBE or Usage-Based Encryption where three variants of FIPS standards are adopted to accomplish the acclaimed goals.Furthermore, a nifty modus operandi has been sketched to wittingly organize/command access control and revocation, specific privileges and security issues, at large.As a matter of fact, since those records are intended to be stored on cloud, our innovative approach knits all those loops of interest together by administering the upper hand in this structure to the patient with an advanced level of flexibility in customizing all pertinent and relevant aspects.
The outcomes are beyond satisfactory since the devised system allowed the patient to fully and successfully control his/her health records by choosing the ultimate scheme which is deemed as best fit for the third party that is meant to have access to it.It also allowed faultless yet smooth revocation of access when the patient deems it necessary to abolish the contact in question.Furthermore, the testing results demonstrated high level of security in terms of storage on cloud since the protocols are under the patient's full supervision and choice.In this sense, those principles applied in this case truly constitute a most general system that is ideal fit for health care applications at large.The relationships that interrelate all modi operandi adopted are indeed versatile since they can also be seen as a library where one could select the most appropriate organigram for the application in question under the umbrella of health care environment.Particularly and as a matter of fact, this approach could ultimately fit as an ideal solution for the management of health records in developing countries where governmental initiatives are extremely limited if not totally absent and where coping with the digital age requirements are still being significantly hindered by the infrastructure whether social, financial, or economic.
Moreover, the proposed scheme decisively offers significantly enhanced capabilities and features in contrast with most of the frequently used systems for a multitude of reasons and rationales.First and foremost, it is not frigid in terms of the tree of choices regarding the access control and type given to a third party involved in the sphere of the patient's medical and/or health records; the patient enjoys a flexible pattern out of which he/she can select and/or later modify the type of access to be granted.Second, the encryption algorithms used constitute an ideal basis to optimize space, computational time and practicality -the number of keys that is produced is reduced to the minimum required.Third, the system's structure allows to secure the data before sending it onto cloud which optimizes resources and prevent raw information from being intercepted by maleficent intruders or hackers -here also policies and protocols are monitored by the user and not left to cloud providers; all of this presented in a highly user-friendly graphical user interface with all options required to manage the entirety of the patient's records inclusive of all types such as lab-test results, images, diagnosis reports, prescriptions, medications, etc.Finally, yet importantly, the presented system indubitably establishes a comprehensive, powerful, secure, ubiquitous and versatile setting for the healthcare globe.

CONCLUSION
In this study, we proposed a Usage Based Encryption (UBE) approach that adapts leading standard encryption techniques with cryptographic hashing and digital signatures algorithms to different parts of a typical EHR.The innovative feature of the approach lies in categorizing information based on their usage rather than on advanced concepts which renders the management of the health record fathomable by the patient and most importantly allows for a significantly greater degree of maneuverability in terms of data segregation in the context of access control, encryption and revocation of privileges.Besides, the suggested structure does not rely on security measures provided and/or supplied by cloud providers, but allows a lowlevel granularity security policy to be implemented and managed by the patient-data is not left or sent raw or plain to cloud providers.
Furthermore, the suggested skeleton offers a versatile platform for the patient to specify and resourcefully reallocate the different parts of the health record via convenient choices of encryption/hashing algorithms.Finally, with the widespread of IaaS, SaaS and PaaS cloud providers and the digitization of almost the entirety of EHRs, the proposed solution allows the patient to safely preserve and easily share data in an efficient way while sustaining the EHR security goals: Confidentiality, Integrity and Availability (CIA).

Table 1 :
Below incorporates the details of the proposed method in encrypting/accessing the before mentioned EHR constituents in terms of policies, specification requirements and deemed actions