PAX

[Full title: PAX: Using Pseudonymization and Anonymization to Protect Patients’ Identities and Data in the Healthcare System]

International Journal of Environmental Research and Public Health Article PAX: Using Pseudonymization and Anonymization to Protect Patients’ Identities and Data in the Healthcare System Mishall Al-Zubaidie 1,2, * , Zhongwei Zhang 2 and Ji Zhang 2 1 Thi-Qar University, Nasiriyah 64001, Iraq 2 Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia; Zhongwei.Zhang@usq.edu.au (Z.Z.); Ji.Zhang@usq.edu.au (J.Z.) * Correspondence: Mishall.Al-Zubaidie@usq.edu.au or u 1070801@umail.usq.edu.au; Tel.: +61-469-869-029 Received: 13 March 2019; Accepted: 23 April 2019; Published: 27 April 2019 Abstract: Electronic health record (EHR) systems are extremely useful for managing patients’ data and are widely disseminated in the health sector. The main problem with these systems is how to maintain the privacy of sensitive patient information. Due to not fully protecting the records from unauthorised users, EHR systems fail to provide privacy for protected health information Weak security measures also allow authorised users to exceed their specific privileges to access medical records. Thus, some of the systems are not a trustworthy source and are undesirable for patients and healthcare providers. Therefore, an authorisation system that provides privacy when accessing patients’ data is required to address these security issues. Specifically, security and privacy precautions should be raised for specific categories of users, doctor advisors, physician researchers, emergency doctors, and patients’ relatives. Presently, these users can break into the electronic systems and even violate patients’ privacy because of the privileges granted to them or the inadequate security and privacy mechanisms of these systems. To address the security and privacy problems associated with specific users, we develop the Pseudonymization and Anonymization with the XACML (PAX) modular system, which depends on client and server applications. It provides a security solution to the privacy issues and the problem of safe-access decisions for patients’ data in the EHR. The results of theoretical and experimental security analysis prove that PAX provides security features in preserving the privacy of healthcare users and is safe against known attacks Keywords: anonymity; ECDSA; electronic health record (EHR); PAX; pseudonym; XACML 1. Introduction Data privacy is a prerequisite for any system, but especially for those systems, such as healthcare systems, that transmit user-sensitive data [ 1 ]. The healthcare system uses authorisation policies to enable healthcare providers to access required patients’ data. Ensuring patients’ privacy means preventing unauthorised users from accessing this data. Unfortunately, many healthcare systems transmit user requests or store policies with explicit plaintext, thus exposing patients’ data to the public The personally controlled electronic health record (PCEHR) system provided by the National E-health Transition Authority (NEHTA) in Australia argues that security and privacy should be properly addressed in healthcare systems [ 2 ]. 1.1. Security in EHR Systems The security of medical records in the electronic health record (EHR) system has been a major focus of health and academic institutions, since the efficiency and quality of patients’ data management [ 1 , 3 ] Int. J. Environ. Res. Public Health 2019 , 16 , 1490; doi:10.3390/ijerph 16091490 www.mdpi.com/journal/ijerph

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 2 of 36 by using the World Wide Web. EHR systems include identifications and patients’ data that require authorisation privileges to determine access control for authorised users [ 4 ]. Accurate medical data is essential for diagnosing diseases and determining the condition of patients during their online transfer from patient to healthcare provider [ 5 , 6 ]. Any change to this data causes health problems for patients. In addition, penetration of medical records of patients with diseases such as HIV infection or dermatological conditions can lead to discrimination, harassment, or even death of the patient if the diagnostic data changes during the transition from client to server [ 6 , 7 ]. In a broad sense, a terrorist may cause national instability by disclosing patients’ data, changing the data, destroying the data, or impersonating some patients [ 8 ]. Healthcare systems, and in particular, EHR systems, should provide end-to-end privacy for patients’ data. In addition, data storage and authorisation policies for patients in a central server yield data management gains but are an attractive target for hackers [ 8 ]. Therefore, there should be security mechanisms to protect the privacy of the patient as well as to prevent the penetration of policies on the server 1.2. Privacy of Critical Medical Cases The use of patients’ data for various purposes, such as consultations, access by a relative or caregiver, research, and emergency (secondary or indirect use) is a major challenge for authorisation systems; for example, the researcher should not exceed the limits of privacy granted to him/her [ 4 ]. In an emergency, when the patients’ doctor is unavailable or the patient does not have the capacity to give consent to another doctor, the patient’s privacy is seriously compromised [ 9 ]. In addition, if the patient is incapacitated, a relative is responsible for receiving the patient’s data [ 10 ]. Sometimes, the doctor also needs to consult another doctor to treat a patient’s condition. All these cases can result in the intrusion and penetration of data. The sharing of medical records among users of the EHR system allows patients’ data to be misused or abused by malicious breaches [ 11 ]. Many examples of penetration of the medical records for patients, such as medical staff who sold medical records to cancer patients, accessed medical records for patients at Washington University [ 12 ] or unauthorised access attacks exposed (June 2016) millions of healthcare records [ 13 ]. In 2018, the U.S. Department of Health and Human Services pointed out that unauthorised access/disclosure attacks targeted many health institutions and penetrated huge health records [ 14 ]. These penetrations show that the healthcare system requires a high level of security. Furthermore, an internal attack penetrates medical records more easily than external attacks because each practitioner has a privilege that allows him/her to access the server system. Many access control models have been used in the EHR, such as mandatory access control (MAC), discretionary access control (DAC), role-based access control (RBAC), and attribute-based access control (ABAC), and each model has specific authorisation mechanisms for data access [ 2 ]. In our project, we adopted the integration of the RBAC and ABAC to support a security level based on both role and user attributes. Therefore, EHR systems require mechanisms to ensure the privacy of patients’ data while protecting authorisation policies and healthcare provider requests [ 15 ]. In order to develop a successful project, privacy must be provided to the patient via the following measures: 1 Preventing attackers from accessing patient data and making data anonymous in case attackers do gain access to the data (i.e., external attacks) 2 Preventing legitimate users from exceeding their privileges (i.e., internal attacks) 3 Securing all requests, policies, and data of the change on the server or during the transfer between the clients and server to ensure the accuracy and reliability of patient data 4 Applying anonymity to requests and policies to hide users’ identities 5 Applying random pseudonym to requests, policies, and data to separate data associated with the real attributes of patients.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 3 of 36 1.3. Our Contributions Our contributions to providing full privacy and security of patients’ records can be summarised as follows: • Combining ABAC and RBAC In this project, we integrate two existing models (ABAC and RBAC) to develop a system that provides handling of patients’ information at the coarse-grained and fine-grained levels. Our model fits the privacy and security requirements for medical records in the EHR by merging a user’s ID with the role as a single attribute entered in signature to identify subjects and objects • Separating users into two sets We have proposed separating users into direct and indirect sets for patients’ records to allow the server to distinguish between users’ requests. This significantly reduces the penetration rate of internal attacks • Using ECDSA’s signatures with XACML The anonymity property has been applied to the requests and policies of subjects. This feature was used during the implementation of the ECDSA signature algorithm with XACML to prevent attackers from determining the identity of healthcare providers (to prevent knowledge of the relation between a physician with a particular patient) • Using Shamir scheme with signatures We used the Shamir scheme with the ECDSA signatures in the third protocol of authorising indirect users. This procedure is necessary to verify unauthorised users of patients’ data who could be conducting serious attacks on the EHR system • Using random pseudonym with patients’ data The pseudonym property has been applied to the requests and policies of subjects and resources. This feature prevents hackers from knowing that the data belongs to a particular patient (separating data from real attributes) • Validating PAX scheme PAX scheme has simulated with an automated validation of Internet security protocols and applications (AVISPA) tool that is an efficient and flexible tool for testing and analysis attacks in modern research. AVISPA has used to validate that PAX is secure against both passive and active attacks. Additionally, Burrows, Abadi and Needham (BAN) logic has used to ensure request source, freshness and entity legitimacy 1.4. Structure of the Paper The report proceeds as follows. Section 2 discusses previous studies related to our research. Basic concepts about the techniques used in the PAX system will be introduced in Section 3 . Section 4 describes the proposed authorisation model. Section 5 describes users’ scenarios and security analysis in the authorisation system. Section 6 presents comparison between PAX and previous studies The conclusion and recommendations for future work are presented in Section 7 . 2. Related Work This Section discusses related works [ 2 , 6 , 8 , 9 , 16 – 18 ], and highlights their shortcomings The PERMIS project was proposed by [ 16 ] with the RBAC model. It described the conceptual authorisation of the credential validation service (CVS) before the approval stage of the access decisions for the resource as well as the distributed management of the credentials. However, the PERMIS system does not adequately protect the CVS. PERMIS also suffers from the problem of inheriting managers for all the attributes of their followers (hospital department managers or specialist doctors who inherit all their practitioners’ attributes and thus have access to patients’ data, which can lead to significant internal attacks) and also uses one signature of a public key cryptography (PKC#12) file for policies and attributes.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 4 of 36 Quantin et al. [ 8 ] suggested using non-central medical records to eliminate issues of standardization and structure in data access requests. However, this scheme suffered from the use of a single aggregator that was similar to the dataset on the central server, which is vulnerable to attack. In addition, patients’ data comes from different sources and have different structures and standards; this difference causes a burden on the aggregator. Moreover, the authors used Rivest, Shamir, and Adleman’s (RSA) encryption algorithm, and this algorithm uses a large key size of 1024 bits, which causes a burden on the server. In addition, the aggregator needs time and storage to convert the data into a single context. Furthermore, this scheme suffered from the collision and doubloon problems due to the transference and transformation of patients’ data contexts The pseudonymization of information for privacy in an e-health (PIPE) project was designed to protect health data in the EHR through a layered system that included many keys such as an external key pair, an internal key pair, a symmetric key pair, and a shared key. It relied on RBAC to protect the keys [ 6 ]. This scheme used the Shamir scheme as a backup mechanism to retrieve the patients’ keys in the case of the loss of the smart card. However, this scheme did not explain the symmetric and asymmetric encryption algorithms used to generate pseudonym for users. In addition, the scheme increases the complexity of the server system with the use of many keys, especially if the scheme is used by a large health institution. In addition, the server must use the keystore to store the keys, and this requires protection and a storage space on the server Gajanayake et al. [ 2 ] integrated four access control models (DAC, MAC, RBAC, and purpose based access control [PBAC]) to obtain a single model that limits user access control of the medical record. However, their scheme addressed only the doctor and the patient and did not address different classes of healthcare providers. In addition, data and requests are clearly transmitted between client and server The healthcare system for patient privacy (HCPP) project was designed for the EHR to protect the privacy of patient data [ 9 ]. Researchers focused on an emergency scenario regarding the protection of patients’ data. They used a backup mechanism that allows the doctor to access patients’ health information without access to confidential parameters. However, this search relies on encrypting all patient data. When a client wants to access patient data, the server uses a keyword to perform an encrypted data mining operation. This process is very expensive for the server for two reasons. First, the server must encrypt the entire massive database with the continuous addition of new records, and second, the server must continuously mine each access request. In addition, their system did not support levels of authorisation and privileges (roles and attributes) that are more secure in providing privacy to patients’ records. In addition, researchers have reported that the patient has not been exposed to collusion because the patient does not attack himself, but this is not true because some impersonation attacks do the job without the theft or loss of the patient’s device. Moreover, this search did not specify the type of encryption algorithm used, which is very important for security and server performance, and addressed only emergency cases Jo & Chung [ 17 ] proposed an XML access control system (XACS) that enables users to access specific elements in an XML document. This system relies on removing certain parts of the XML document to allow users who are authorised to see certain parts of an XML document. However, requester information is transmitted explicitly over the Internet to a server, which makes it easier for an attacker to penetrate the privacy of users. In addition, it does not address internal attacks that are applied by legitimate users even though certain parts of the XML document have been removed Seol et al. [ 18 ] proposed an access control model based on partial encryption and XML signing in EHR’s documents within a cloud environment. Their model is supported in two phases: the first phase is access control using XACML and the second is to encrypt and sign data with XML. However, the cloud environment presents multiple security and privacy problems in the EHR system because of the distributed exchange of data between the various health centres. In addition, their scheme uses encryption in XML requests and responses, which will be extremely costly for legitimate entities exchanges in healthcare systems. In addition, in the first phase, requests and responses are clearly

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 5 of 36 sent between the legitimate parties and therefore are exposed to attack. They also did not address the pseudonym mechanism that prevents access to real users’ information 3. Overview of Security and Privacy Techniques in EHR Systems The EHR system needs a set of techniques to implement the management and privacy of patients’ data. In our project, we focus on the security aspect of authorising legitimate users. The EHR system collects and stores medical records on a server, and each medical record is associated with a set of attributes that allow healthcare providers or patients to access it later. Several countries, such as Australia, the USA, and the UK have implemented EHR by taking advantage of dealing with patients’ data over the Internet [ 5 ]. Therefore, our project used a set of techniques with the EHR. This section describes the threat model and the basic concepts of these techniques: • Threat model Many serious risks to healthcare systems that require the building of a threat model to detect weaknesses in these systems. Dolev-Yao threat model [ 19 ] is used to test users’ authorisation in PAX. It is a formal model, a practical way of analyzing authorisation protocols in real environments. This model is very efficient in examining and analyzing various attacks. We assume that attacks can be internal, external, active, and passive. Additionally, we suppose that attributes server ( AS ) is trustworthy and safe against information repository penetration attacks. In this model, we address the following threats: – The attacker can flood the server with intensive authorisation requests, which is to stop the service from healthcare’s users and destroy the network – The attacker performs an attack to penetrate the repository on the central server, to access the patient’s data and reveal their identities – The attacker performs a Man-in-the-middle (MITM) attack to modify the data and to become a legitimate user in the network – The attacker sends a fake authorisation request during the execution of a forgery/impersonation attack to gain access to patient data – The attacker can launch an eavesdropping attack to obtain authorisation requests, and then perform an analysis of these requests to detect the correlation between data, information, and pseudonyms – The attacker can execute timing attacks by using the time period to reveal user authorisation information • Access control in EHR systems Any system needs access control (AC) models to determine users’ access to the data repository. There are many AC models, and each one depends on a particular method and set of rules One of the most distinct AC models is role-based access control (RBAC). This model relies on the classification of users into roles, and each role has privileges and rights regarding data access [ 2 ]. With RBAC, the security of the system is based on the structure of the system’s roles assigned to users [ 20 ]. Each role in the system is assigned according to the job of the user in the organization [ 21 ]. RBAC was introduced to solve problems with previous access models such as DAC. As shown in Figure 1 , the RBAC model divides users into roles (such as a patient, doctor, and researcher) In recent years, there has been significant interest in using the attribute-based access control (ABAC) model for the protection of data privacy. This model is designed to access data more accurately (fine-grained) and securely. It handles user attributes (such as name, address, age, mobile, location, time) to allow users to access the server’s repository. ABAC proposed to go beyond the limitations in the rules and design of the most well-known control access models (DAC, MAC, and RBAC) [ 22 , 23 ]. ABAC is a rich model because it deals with a

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 6 of 36 wide range of user attributes. ABAC supports administration, authorisation of context-aware, risk-intelligence, and scalability in various applications such as the Internet, IoT, Big Data, cloud computing, and VANET [ 24 ]. The attributes in ABAC are categorized into subject, object, action, and environment. As shown in Figure 2 , each user has a set of attributes that allows him/her to access data in the server • Distributed AC implementation technology The most important component in the proposed EHR system is the EHR repository. The repositories contain data in various forms because these systems have difficulties dealing with different coordinates for data. Therefore, the use of extensible access control (XML) is suitable for the exchange of various data via the Internet. XML is a symbolic language and uses a simple and flexible method designed to describe, exchange, and manage data across the Internet. However, XML should support security and privacy mechanisms that provide different levels of protection of sensitive data in the whole or part of the XML document [ 17 ]. Access to data is a major challenge in big data management systems (EHR) that use different techniques. In addition, the exchange of information over the Internet has become essential and needs to achieve access authorisation, particularly in healthcare applications. Extensible access control markup language (XACML) standards include both access control (authorisation) and data management based on XML in the different systems [ 25 ]. Effectively, XACML offers features for data access and authorisation for the users at the fine-grained level, which is the most flexible and effective [ 26 – 28 ]. This technology is presented by the organization for the advancement of structured information standards (OASIS). This standard has many of the features that qualify it for use on the Internet, such as combining policy, combining algorithm, attribute, multiple subjects, policy distribution, implementation independency and obligations [ 23 , 28 , 29 ]. This technique is based on the specific policies first and then on many modules such as policy enforcement point (PEP), policy decision point (PDP), policy administration point (PAP), policy information point (PIP), and policy retrieval point (PRP) to evaluate the request for access [ 4 ], as shown in Figure 3 (PEP sends and receives requests and accesses responses to the repository; PDP evaluates the decision; PAP creates policies based on users’ attributes; PIP retrieves users’ attributes; and PRP retrieves the users’ data from the repository). The result of the decision (permit, deny, not applicable, indeterminate) is sent to the subject via PEP [ 23 ]. • Elliptic curve digital signature algorithm (ECDSA) Proposed by Scott Vanstone in 1992 [ 30 ], the elliptic curve digital signature algorithm (ECDSA) is an asymmetric signature algorithm that depends on the use of the points on the curve to sign data. It has been used to provide integrity, authentication, and non-repudiation properties in the communications network with limited capacity in terms of power and processing. The algorithm depends on the elliptic curve discrete logarithm problem (ECDLP). It is impervious against different attacks when the parameters are accurately selected [ 31 ], i.e., it is difficult to obtain k from P and Q (where k is an integer and P and Q are two points on the curve) [ 32 , 33 ]. ECDSA uses small parameters which expedites the performance of computations, thus reducing time and storage [ 34 ]. These features are very important for large organizations and constrained-source devices such as wireless sensor networks (WSN) that require processing power, memory, bandwidth, or power consumption [ 35 ]. More details about ECDSA’s signature and verification are available in [ 31 ]. • Shamir scheme The secret sharing scheme or the Shamir ( SS s , t ) scheme depends on a set of keys/secrets sharing ( SS s ) and threshold ( t ) to produce a master key/secret ( MS ). The master secret can be created from some or all of the SS s [ 36 ]. In this scheme, t specifies the minimum number of keys/secrets that allow reconfiguring MS [ 37 , 38 ]. This scheme consists of two phases: Generation and Reconstruction. In the Generation phase, the server divides MS into a set of secrets sharing ( SS 1 , SS 2 , .., SS n ), and each client ( C i ) securely receives one secret sharing ( SS ) that is part of MS In the Reconstruction phase, C i needs to achieve any set of secrets ( SS s ) required by relying on the

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 7 of 36 value of t to construct MS (correctness and homomorphism properties). If C i has t -1 from SS s , C i fails to obtain information from server (secrecy property). Calculating the MS is a very difficult operation for the attacker. In addition, the secrets that are configured for the MS are anonymous users; the attacker does not know if these secrets belong to any of the users [ 6 ]. The Shamir scheme provides an anonymity solution to generate a MS with several features such as full security in hiding C i s’ SS s , a MS size equal to C i s’ SS s sizes, easy creation of a MS from a set of keys/secrets, and creation of a new key/secret for one-time use [ 33 ]. Figure 1. Scheme of role-based access control (RBAC) model Figure 2. Scheme of attribute-based access control (ABAC) model.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 8 of 36 Figure 3. Scheme of XACML 4. Our Proposed Authorisation Model In this Section, we will provide details about our new authorisation scheme that support security and privacy mechanisms to ensure legitimate users’ authorisation in healthcare applications This Section will be divided into the network model, applying privacy concepts and PAX authorisation protocols for users 4.1. Network Model As shown in Figure 4 , Pseudonymization and Anonymization with the XACML (PAX) is an authorisation system that works with EHR. The network model consists of four entities: client ( C i ), central server ( CS ), attributes server ( AS ) and data server ( DS ). These entities communicate with each other in the PAX framework to accomplish authorisation and privacy preservation of users in access to the patients’ datasets CS is the portal that prevents users from accessing directly to both AS and DS . Patients’ data are stored on the data server ( DS ) and are fully separated from the attributes of the users (patients and healthcare providers) that stored on the attributes server ( AS ). Each C i creates an access request and sends it to the CS . Then, CS verifies the authorisation information for the user’s request, if this request is valid, CS sends the authorisation request to AS for an evaluation; otherwise, CS sends the “deny” response to C i . When AS receives the authorisation request from CS , AS evaluates the access request by PDPs modules, verifies signatures, pseudonyms, and other security parameters. If all evaluations and tests are valid, AS sends a request to DS to retrieve patient data; otherwise, AS sends the “deny” response to CS . After that, DS checks for signatures (Sigs) and privacy parameters (PP), if all operations are correctly performed, DS sends the required data with pseudonyms and Sigs to AS which in turn sends the “permit” response to C i by CS to allow access to the dataset. The authorised user will receive the “permit” response and the copy of the required data. The PAX system uses two PDPs (PDP 1 and PDP 2) to implement the user authorisation process, as shown in Figure 4 . In this project, we focus on securing requests and policies to provide a high level of user privacy. PAX depends on the Balana Project, which is the only open source project that implements XACML v 3.0 to ensure privacy and security for patients’ medical records.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 9 of 36 Figure 4. Pseudonymization and Anonymization with the XACML (PAX) model 4.2. Implementation of PAX In this section, we will introduce the privacy concepts in PAX • EHR’s users in PAX Security and privacy address where, when, and why data is available and who can access the data repository. Patients and healthcare providers require services that are efficient, fast, and continuous and at the same time incorporate strict restrictions to determine data access Therefore, AC to medical records has several challenges in terms of security and privacy: 1 Legitimate users should not exceed their privileges 2 Users’ roles in the EHR system should be defined. For example, a doctor can have several roles, such as an emergency doctor and a researcher doctor 3 Data should be anonymous when it reaches the wrong user due to misuse or attacks 4 Compliance with medical standards for EHR (such as HIPAA) is essential In PAX, we divide users into two categories: – Direct users: These users include those who are directly associated with the data, such as the patient and the doctor – Indirect users: These users include those who are not directly and continuously associated with the data, such as advisors, patients’ relatives, researchers, and emergency doctors Although PAX includes both categories of users, this project focuses on indirect users (Figure 5 shows a flow chart for authorisation of direct and indirect users in PAX). Any healthcare system can be exposed to an internal attack by indirect users if there are no security and privacy mechanisms to prevent them • Users’ pseudonym in PAX Several methods are used to protect the privacy of patients’ data, such as encryption and anonymization. However, these methods suffer from disadvantages. For example, encryption of patients’ data [ 7 ] has the following disadvantages: 1 The researcher or emergency doctor will not benefit from the encrypted data, and if he/she can decrypt the patients’ data, this is a breach of security in the healthcare system 2 Large database encryption is very expensive for the server system, which leads to unnecessary time consumption and reduced processor performance [ 39 ].

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 10 of 36 3 The database of patients’ data requires the continuous addition and deletion of records, and if the data is encrypted, this will increase the burden on the server [ 40 , 41 ]. 4 Encryption can contain direct information about the patients. The penetration of this encryption will leave the patients’ identity and information exposed [ 42 ]. The anonymization of patients’ data requires the following: 1 The removal of all the attributes associated with the patient that prevents the healthcare provider from dealing with the associated patient’s data [ 7 ]. 2 Adding a large set of counterfeit records, which greatly increases the size of the database and therefore consumes server resources, especially with the continuous use of the database by healthcare providers To solve these problems, we apply random pseudonyms with PAX to separate the association between patients’ attributes and data. The medical records transmitted between the client and server do not contain any patients’ attributes. This prevents the attackers from identifying patients. In PAX, we propose to use four datasets: the first was for users’ attributes (patients and healthcare providers); the second was for applying pseudonyms to users; the third was for users’ policies (on AS ); and the fourth was for patients’ data (on DS ). When the EHR system wants to add a new healthcare provider or patient, the PAX randomly generates a pseudonym for that user and adds it to the second dataset. Suppose that we have a dataset for random pseudonyms, as in Table 1 . PAX generates pseudonyms (such as p 429 or d 761) for patients or healthcare providers during the addition of a letter representing the user’s role ( UR ) such as p or d plus a random client’s number ( CN ). Each subject’s pseudonym ( SP ) and object’s pseudonym ( OP ) consists of UR and CN (internal pseudonym), which are not transferred between entities and are used for policy verification at AS . XACML’s request in PAX depends on the SP and OP (external pseudonym), and both SP and OP are divided into role’s number ( RN ) and user’s number ( UN ) (after replacing UR with RN and CN with RN ) and the latter are segmented into three parts (low (l), medium (m), and high (h)) with length 8 bits per part as in Table 2 . These pseudonyms are associated with the users’ IDs. It enables users to access a specific patient’s data without exceeding granted privileges and rights • Using ECDSA’s signatures PAX uses ECDSA (NIST prime-256) with requests and policies to ensure that security requirements apply to the privacy of patients’ data. We have applied ECDSA signatures with subjects’ and objects’ attributes to ensure integrity property to prevent changing attributes in requests and policies, authentication property to prevent external attackers and non-repudiation property to prevent authorised users from denying their requests to receive medical records. The application of security requirements is very important in systems that use sensitive data, such as healthcare systems. In PAX, the C i signs the request with pseudonyms ( RN and UN ), and the servers ( CS and AS ) verify the request’s Sigs. If valid, the AS assigns the request to the PDPs engines (after replacing Sigs(external pseudonym) with Sigs(internal pseudonym)) in XACML v 3.0; otherwise, the request is rejected. PAX uses ECDSA’s Sigs to hide parts of SP and OP when exchanging XACML’s requests between PAX entities. The high performance and security level makes this algorithm suitable for application in large systems (such as EHR) • Policies administration in PAX System Administrator is responsible for creating policies for healthcare providers and patients in AS by PAP. Policy in PAX consists of the policy ID, subject, object, and rules for policy implementation. The first process in the PAX system is to create datasets for pseudonyms and attributes for all users. The process of creating policies depends on previous datasets. PAX uses ECDSA to generate a signature of SP ( S sp ) and a signature of OP ( S op ) based on the pseudonyms ( UR and CN ) for both SP and OP . Creating signature-based policies and pseudonyms protects

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 11 of 36 policies on the server in a way that is immune to internal and external attacks (policies do not depend on users’ real attributes). For example, the system administrator creates a user policy by entering the doctor’s name and UR and patient’s name, PAX creates this policy as shown in Figure 6 . The policy parameters are highlighted in green: d 20 represents the SP and uses as policy’s ID; the first long 128-bit hexadecimal number represents the S op ; and the second long 128-bit hexadecimal number represents the S sp . This policy can include a set of rules such as determining the date of data access, the time specified on a given day, or the number of access times • Clients’ requests and server’s responses PAX’s users must create an authorisation request to access medical records. This request consists of subjects’ and objects’ attributes. The C i application in PAX uses the parts of RN and UN as a single attribute to generate the ECDSA’s Sig for the subjects and the objects. Figure 7 shows the client’s request to access patient data (where the request parameters are highlighted in green; C i S 2 tm || RN op tm || UN op tm || N C || C i S 4 tm in resource segment represents the object’s attributes; and the C i S 1 tm || RN sp tm || UN sp tm || N C || TS C tm || SN C tm in access-subject segment represents the subject’s attributes). In addition, the C i application uses a part of RN sp to explain to the AS the user’s role to determine the desired policy after verifying the Sigs. Then, the C i sends the request to the AS by CS for evaluation. The AS evaluates the request in the PDP engines, and the response (permit or deny) returns to the C i by CS • Using Shamir scheme In PAX, we implemented the Shamir scheme to increase the level of security for indirect users (advisors, patients’ relatives, researchers, and emergency). Indirect users are legitimate users who can perform an internal attack because of the rights granted to them. PAX uses ECDSA to sign all signatures of healthcare users to create a master signature (MS). Then, PAX uses the Shamir scheme to generate secrets sharing ( SS s ) from a MS. Each indirect user receives SS via a secure communication channel C i needs a set of SS s to reproduce MS. PAX uses t = 3, which means that the randomly selected SS s require at least 3 SS s to generate MS . In addition, depending on RN sp , AS specifies that the user’s role is indirect and use the Shamir scheme with ECDSA’s Sig to verify the original MS and then evaluate the request by PDP 2. Using Shamir’s scheme with XACML adds the property of authenticity, as an indirect user cannot access data with the same SS s This operation enables PAX to secure the privacy of patients’ data and protect patients’ data from internal and external attacks. When an indirect user wants access to medical records, he/she does not know whether the SS s used to generate the MS belong to any specific healthcare providers Table 1. Internal and external pseudonyms of users Users U R CN Internal Pseudonym RN U N External Pseudonym patient p p 1 .. p n doctor d d 1 .. d n advisor a a 1 .. a n relative pr 1 .. n pr 1 .. pr n 1 .. n 1 .. n 1 .. n researcher r r 1 .. r n (48-bit) emergency e e 1 .. e n Shamir - - Table 2. Parts of SP and OP SP OP RN sp U N sp RN op U N op RN sp l RN sp m RN sp h UN sp l UN sp m UN sp h RN op l RN op m RN op h UN op l UN op m UN op h

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 12 of 36 C i creates and sends the request to CS CS receives user’s request, verifies and sends it to AS AS receives user’s request, evaluates it Verify PP+Sigs (ECDSA)? Communication denied Is the request for direct user? Evaluation of authorisation request with two PDPs (Figure 14 ) Evaluation of authorisation request with single PDP 1 (Figure 8 ) Is the direct user authorised? Is the indirect user authorised? Access denied (server’s repository) Access granted for patient-specific data from DS Access granted for patient (s)-specific data from DS No Yes No Yes No No Yes Yes Figure 5. Authorisation of direct and indirect users Figure 6. PAX policy.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 13 of 36 Figure 7. C i ’s request 4.3. PAX Authorisation Protocols In this section, we will provide in detail PAX’s protocols framework in authorising direct and indirect users. PAX uses four protocols for direct users such as doctor and five protocols for indirect users such as researcher to secure communication among PAX’s entities. The request in protocols includes PP for a subject (sender) and object (receiver). • Authorisation protocols for direct subjects and objects To run through the authorisation process for direct users of PAX, the security techniques mentioned in the previous sections will be the basis for building the PAX authorisation system. In this section, we will explain the protocols of authorising direct users such as doctors and patients to access medical records (EHR) – Prerequisite procedures There are a set of steps that must be taken before authorisation can begin 1 Create two datasets (attributes, pseudonym) on AS . If datasets are established, the processes are to add new users or delete direct users 2 Create policies (dataset 3) for all direct users based on anonymity and pseudonym 3 Storage of medical records (dataset 4) for patients in the DS ’s repository (after collecting them from patients using wireless medical devices, this process requires security mechanisms, but the process of storing medical records safely is beyond the scope of this research). We assume that patients’ data is located on the DS – Authorisation protocols The following protocols detail how the direct user is associated with the EHR in DS . Figure 8 depicts generally the authorisation process, while Figures 9 – 12 show the authorisation protocols of direct users with PAX entities 1 First protocol as shown in Figure 9 : * PAX’s user enters the subject ID ( S ID ), object ID ( O ID ), subject role ( S R ) and object role ( O R ) to the C i application C i replaces S ID , O ID , S R and O R with CN sp , CN op , UR sp and UR op respectively. After that, internal pseudonyms are replaced with UN sp , UN op , RN sp RN op respectively. Then, C i generates random nonces ( N C and SN C ) and new timestamp ( TS C i ) SN C is a random secret between C i and CS C i computes 4 Sigs ( C i S 1 , C i S 2 , C i S 3 and C i S 4 ) C i S 1 and C i S 2 is used to ensure the legitimacy of C i in CS C i S 3 is used to protect SN C between C i and

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 14 of 36 CS C i S 4 is used to validate C i in both AS and DS (depending on RN op h and UN op h ) C i hides all Sigs such as C i S 1 temporary ( C i S 1 tm ) and PP such as TS C tm and SN C tm . At this point, C i sends XACML’s request to CS that including subject’s information ( C i S 1 tm || RN sp tm || UN sp tm || N C || TS C tm || SN C tm ) and object’s information ( C i S 2 tm || RN op tm || UN op tm || N C || C i S 4 tm ) * CS receives XACML’s request from C i , cuts Sigs and PP from access-subject ( C i S 1 tm , RN sp tm , UN sp tm , N C , TS C tm and SN C tm ) and resource ( C i S 2 tm , RN op tm , UN op tm , N C and C i S 4 tm ). Then, CS extracts RN sp l , UN sp l , RN op l and UN op l from receiving parameters ( such as RN sp tm ) UN sp l and UN op l is used to retrieve UN sp m and UN op m from datasets CS extracts C i S 4 , SN C , TS C i and checks timestamp. Then, CS computes Sigs ( CSS 1 , CSS 2 and CSS 3 ), and uses CSS 1 to extract original C i S 1 and C i S 2 . After that, CS checks CSS 2 = C i S 1 and CSS 3 = C i S 2 . If the Sigs are not identical, CS cancels the connection; otherwise, it moves to the next protocol 2 Second protocol as shown in Figure 10 : * CS generates random secret ( SN CS ) and new timestamp ( TS CS ) between CS and AS . Then, CS computes the secret signature ( CSS 4 ) to protect SN CS . In addition, CS hides C i ’s parameters such as N C and TS C i to use them with validation operations in AS and DS . In addition, all Sigs (such as CSS 2 tm ) and PP (such as N CS and TS CS tm ) are anonymously hidden by CS . At this point, CS sends XACML’s request to AS * AS receives the request, cuts Sigs and PP. After that, AS extracts original parameters (such as C i S 4 and TS CS ) and checks timestamp AS computes ASS 1 (to extract CSS 2 and CSS 3 ) and computes ASS 2 and ASS 3 (to check ASS 2 = CSS 2 and ASS 3 = CSS 3 ) AS retrieves RN op h and UN op h from dataset (depending on RN op m and UN op m ) and computes ASS 4 to ensure C i request is legitimate after checks ASS 4 = C i S 4 AS uses the parts of external pseudonyms to specify UR sp , UR op , CN sp and CN sp AS retrieves Sigs of SP and OP ( S sp and S op ) depending on the internal SP and OP AS uses PDP 1 engine to evaluate XACML’s request after adding S sp and S op to that request AS specifies user’s policy in PAP and checks user’s attributes in PIP. PDP 1 applies policy to get a decision (permit, deny, not applicable and indeterminate). If decision=“permit”, AS uses UR sp to specify user’s role (direct/indirect). If UR sp =direct, AS sends the data retrieval request by PRP to DS ; if UR sp =indirect, AS sends the Shamir request that contain at least 2 SS s to ensure legitimate indirect users. Otherwise AS sends reject response to C i by CS 3 Third protocol as shown in Figure 11 : * Similarly, AS generates random secret ( SN AS ) and timestamp ( TS AS ) between AS and DS AS computes ASS 5 to protect secret ( SN AS ) between AS and DS Additionally, AS computes ASS 6 to ensure legitimate PP ( RN op m and UN op m ) in DS . All Sigs (such as ASS 6 tm ) and PP (such as TS AS tm and SN AS tm ) are anonymously hidden by AS . Then, AS sends XACML’s request to DS * DS receives the request, cuts Sigs and PP. After that, DS extracts original parameters (such as C i S 4 and SN AS ) and checks timestamp DS computes DSS 1 (to extract ASS 6 ) and retrieves RN op h and RN op m depending on RN op l . Then, DS computes DSS 2 and DSS 3 to check DSS 2 = ASS 6 and DSS 3 = C i S 4 . If AS ’s parameters validated in DS correctly, DS computes timestamp ( TS DS ) and signs patient’s data ( DSS 4 ). All Sigs (such as DSS 4 tm ) and PP (such as TS DS tm ) are anonymously hidden by DS . At this point, DS sends the response to AS .

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 15 of 36 * AS receives the response, extracts PP (such as TS DS ) and checks timestamp AS tests the Sigs checking (such as ASS 6 = DSS 2 ). Then, AS computes data signature ( ASS 7 ) to check data integrity by ASS 7 = DSS 4 4 Fourth protocol as shown in Figure 12 : * AS prepares the response to CS by generating a new timestamp ( TS AS ), hides data signature ( ASS 7 ) with ASS 2 , ASS 3 , C i S 4 and secret signature ( ASS 1 ) AS hides PP and sends the response that contains decision and patient’s data to CS * CS receives the response and extracts Sigs and PP CS computes data signature ( DSS 5 ) to check data integrity ( CSS 5 = ASS 7 ). Then, CS checks other Sigs ( CSS 2 , CSS 3 and CSS 4 ) with received Sigs ( ASS 2 , ASS 3 and C i S 4 ) to ensure legitimacy of AS CS prepares the response to C i by generating a new timestamp and hides data signature ( CSS 5 ) with CSS 2 , CSS 3 , C i S 4 and secret signature ( CSS 1 ) CS sends the response to C i * C i receives the response, extracts PP and checks timestamp C i computes data signature ( C i S 5 ) to check data integrity by C i S 5 = CSS 5 . Then, C i extracts signatures ( CSS 2 , CSS 3 , CSS 1 and C i S 4 ) and checks them with original signatures ( C i S 1 , C i S 2 , C i S 3 and C i S 4 ) respectively C i uses CSS 2 , CSS 3 and CSS 1 (secret signature between C i and CS ) to check legitimacy of CS while uses C i S 4 to check legitimacy of AS and DS . If all Sigs are validated, namely, authorised C i received securely correct data • Authorisation protocols for indirect subjects and objects Indirect user authorisation is an important process to secure sensitive patients’ data in the EHR stored in DS . PAX offers additional procedures to prevent the abuse of indirect user privileges – Prerequisite procedures There are a set of steps that must be performed before authorisations are applied 1 Steps from 1 to 3 are similar to those for direct users 2 The Shamir scheme is used to generate the SS s from MS for the number of users, each C i has unique SS same length as MS , and authorised with two policies for each indirect user on AS . The policy evaluation process is also done with two, PDP 1 and PDP 2, evaluation engines. The use of two evaluation engines is very important in separating direct and indirect users and increasing security in the privacy of medical records 3 The PAX authorisation system identifies certain medical records (the patients’ history at a given time such as a year or more ago) for indirect users who can access them, as shown in Figure 13 (researcher case) – Authorisation protocols The following protocols detail how the indirect user obtains medical records in PAX. Figure 14 illustrates generally the authorisation of indirect users, while Figures 9 – 12 and 15 show the authorisation protocols of indirect users in PAX 1 The steps of the first and second protocols are similar to the ones of the direct users authorisation 2 Third protocol as shown in Figure 15 : * AS computed MS previously by signing all users’ signatures. Then, AS computes Shamir scheme to generate SS s with the same number of users (each C i has one unique SS ). In PAX, C i needs at least 3 SS s to generate original MS . In this protocol, AS generates a new timestamp and retrieves at least 2 SS s . After that, AS hides SS s with ASS 2 , C i S 4 , S sp and secret signature ( ASS 1 ) as well as parameters (such as

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 16 of 36 TS AS tm and UN sp tm ) are anonymously hidden. At this point, AS sends request to CS * CS receives the request, extracts PP and checks timestamp. Then, CS removes the secret signature ( CSS 4 ) and adds the secret signature ( CSS 1 ) in CSS 2 tm CS generates a new timestamp ( TS CS ), hides PP and sends the request to C i * C i receives Shamir’s request, extracts PP and checks timestamp. Then, C i computes C i S 6 to extract SS s and retrieves his SS . At the moment, C i can generate MS from Shamir ( C i ’s SS || SS s ), hides MS with C i S 6 and C i S 3 , generates timestamp and hides PP. At this point, C i sends the response to CS * CS receives the response, extracts PP and checks timestamp. Also, CS removes CSS 1 and adds CSS 4 in C i S 6 tm CS generates a new timestamp, hides PP and sends the response to AS * AS receives Shamir response, extracts PP and checks timestamp. Then, AS extracts the received MS and checks it with the saved original MS . After that, AS retrieves C i ’s SS depending on S sp ( UR sp || CN sp ) and assigns the request ( SS , S op ) to PDP 2 AS specifies policy depending on policy’s ID (Shamir|| SP ), checks attributes in PIP and PDP 2 applies policy in PAP to produce the decision. If the decision is “permit”, AS creates a data retrieval request by PRP to DS; otherwise AS sends reject response to C i by CS 3 The fourth and fifth protocols are similar to the third and fourth ones respectively in direct user authorisation DS sends the response to the C i by AS and CS . If C i is an advisor, relative, or emergency doctor, C i will receive specific patient’s data; otherwise, if C i is researcher doctor, C i will receive a set of medical records Figure 8. Authorisation of direct users.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 17 of 36 C i CS Enters S ID , O ID , S R and O R Replaces S ID with CN sp , O ID with CN op S R with UR sp and O R with UR op Replaces CN sp , CN op , UR sp and UR op with UN sp , UN op , RN sp and RN op SP = RN sp || UN sp , OP = RN op || UN op UN sp = UN spl || UN spm || UN sph UN op = UN opl || UN opm || UN oph RN sp = RN spl || RN spm || RN sph RN op = RN opl || RN opm || RN oph Generates new N C , SN C and TS Ci C i S 1 = ECDSA ( RN spm || UN spm || N C || TS Ci ) C i S 2 = ECDSA ( RN opm || UN opm || N C || TS Ci ) C i S 3 = ECDSA ( SN C ) C i S 4 = ECDSA ( RN oph || UN oph || TS Ci ) C i S 1 tm = C i S 1 ⊕ C i S 3 , C i S 2 tm = C i S 2 ⊕ C i S 3 TS Ctm = TS Ci ⊕ SN C ⊕ RN spm ⊕ UN spm SN Ctm = UN spm ⊕ UN opm ⊕ SN C ⊕ C i S 4 ⊕ C i S 1 tm C i S 4 tm = C i S 4 ⊕ UN spm ⊕ UN opm ⊕ C i S 2 tm RN sptm = RN spl ⊕ C i S 1 tm ⊕ SN Ctm RN optm = RN opl ⊕ C i S 2 tm ⊕ SN Ctm UN sptm = UN spl ⊕ C i S 1 tm ⊕ SN Ctm UN optm = UN opl ⊕ C i S 2 tm ⊕ SN Ctm Request=( C i S 1 tm || RN sptm || UN sptm || N C || TS Ctm || SN Ctm , C i S 2 tm || RN optm || UN optm || N C || C i S 4 tm ) Sends XACML’s request Receive XACML’s request From access-subject: Cuts C i S 1 tm , RN sptm , UN sptm , N C , TS Ctm and SN Ctm From resource: Cuts C i S 2 tm , RN optm , UN optm , N C and C i S 4 tm Extracts RN spl = RN sptm ⊕ C i S 1 tm ⊕ SN Ctm Similarly, extracts RN opl , UN spl and UN opl Retrieves UN spm and UN opm from datasets depending on UN spl and UN opl C i S 4 = C i S 4 tm ⊕ UN spm ⊕ UN opm ⊕ C i S 2 tm SN C = UN spm ⊕ UN opm ⊕ SN Ctm ⊕ C i S 4 ⊕ C i S 1 tm TS Ci = TS Ctm ⊕ SN C ⊕ RN spm ⊕ UN spm Checks TS CS − TS Ci ≤ 4 T , CSS 1 = ECDSA ( SN C ) C i S 1 = C i S 1 tm ⊕ CSS 1 , C i S 2 = C i S 2 tm ⊕ CSS 1 CSS 2 = ECDSA ( RN spm || UN spm || N C || TS Ci ) CSS 3 = ECDSA ( RN opm || UN opm || N C || TS Ci ) Checks CSS 2 = C i S 1 and CSS 3 = C i S 2 Figure 9. Protocol of PAX model between C i and CS CS AS Creates new XACML’s request Generates new SN CS and TS CS CSS 4 = ECDSA ( SN CS ) CSS 2 tm = CSS 2 ⊕ CSS 4 , CSS 3 tm = CSS 3 ⊕ CSS 4 N CS = N C ⊕ TS Ci ⊕ TS CS ⊕ SN CS TS Ctm = TS Ci ⊕ SN CS ⊕ RN spm ⊕ UN spm TS CStm = TS CS ⊕ SN CS ⊕ RN opm ⊕ UN opm SN CStm = UN spm ⊕ UN opm ⊕ SN CS ⊕ C i S 4 ⊕ CSS 2 tm C i S 4 tm = C i S 4 ⊕ UN spm ⊕ UN opm ⊕ CSS 3 tm RN sptm = RN spl ⊕ CSS 2 tm ⊕ SN CStm RN optm = RN opl ⊕ CSS 3 tm ⊕ SN CStm UN sptm = UN spl ⊕ CSS 2 tm ⊕ SN CStm UN optm = UN opl ⊕ CSS 3 tm ⊕ SN CStm Request=( CSS 2 tm || RN sptm || UN sptm || N CS || TS Ctm || TS CStm || SN CStm , CSS 3 tm || RN optm || UN optm || C i S 4 tm ) Sends XACML’s request Receive XACML’s request Similarly for CS : Cuts security parameters, extracts RN spl , RN opl , UN spl and UN opl Retrieves UN spm and UN opm Extracts C i S 4 , SN CS , TS Ci , TS CS and N C , checks TS AS ASS 1 = ECDSA ( SN CS ) CSS 2 = CSS 2 tm ⊕ ASS 1 , CSS 3 = C i S 3 tm ⊕ ASS 1 ASS 2 = ECDSA ( RN spm || UN spm || N C || TS Ci ) ASS 3 = ECDSA ( RN opm || UN opm || N C || TS Ci ) Checks ASS 2 = CSS 2 and ASS 3 = CSS 3 Retrieves RN oph and UN oph ASS 4 = ECDSA ( RN oph || UN oph || TS Ci ) , ASS 4 = C i S 4 SP = RN sp || UN sp , OP = RN op || UN op Specifies UR sp , UR op , CN sp and CN sp depending on RN sp and RN op , UN sp and UN sp Retrieves S sp and S op depending on SP and OP (internal pseudonym) Uses PDP 1 to evaluate request ( S sp , S op ) Specifies policy depend on policy’s ID ( SP ) Checks attributes ( S ID , O ID , S R , O R ) in PIP, applies policy in PAP If decision =“permit”, then If UR sp = direct user, then Sends data retrieval request by PRP to DS If UR sp = indirect user, then Sends request with Shamir scheme to C i by CS Figure 10. Protocol of PAX model between CS and AS .

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 18 of 36 AS DS Creates new data retrieval request Generates new SN AS and TS AS ASS 5 = ECDSA ( SN AS ) ASS 6 = ECDSA ( RN opm || UN opm || SN AS || TS AS || C i S 4 ) RN optm = RN opl ⊕ TS AS ⊕ SN AS ASS 6 tm = ASS 6 ⊕ TS AS ⊕ ASS 5 TS Ctm = TS Ci ⊕ SN AS ⊕ UN oph TS AStm = TS AS ⊕ SN AS ⊕ UN opm SN AStm = UN opm ⊕ SN AS ⊕ C i S 4 ⊕ ASS 6 tm C i S 4 tm = C i S 4 ⊕ UN oph ⊕ SN AStm ⊕ UN opm UN optm = UN opl ⊕ ASS 6 tm ⊕ SN AStm Request=( ASS 6 tm || RN optm || UN optm || SN AStm || TS Ctm || TS AStm || C i S 4 tm ) Sends data retrieval request Receives data retrieval request Extracts UN opl , retrieves UN opm and UN oph depending on UN opl Extracts C i S 4 , SN AS , TS Ci and TS AS , checks TS DS DSS 1 = ECDSA ( SN AS ) , extracts ASS 6 and RN opl Retrieves RN oph and RN opm depending on RN opl DSS 2 = ECDSA ( RN opm || UN opm || SN AS || TS AS || C i S 4 ) DSS 3 = ECDSA ( RN oph || UN oph || TS Ci ) Checks DSS 2 = ASS 6 and DSS 3 = C i S 4 Sends data retrieval response Generates new TS DS DSS 4 = ECDSA ( "Data" ) DSS 4 tm = DSS 4 ⊕ DSS 1 ⊕ C i S 4 DSS 2 tm = DSS 2 ⊕ DSS 4 ⊕ TS DS ⊕ DSS 1 C i S 4 tm = C i S 4 ⊕ DSS 1 ⊕ TS DS TS DStm = TS DS ⊕ SN AS ⊕ UN oph UN optm = UN opl ⊕ DSS 2 tm ⊕ TS DStm Response=( DSS 2 tm || DSS 4 tm || UN optm || TS DStm || C i S 4 tm || "Data") Sends data retrieval response Receives data retrieval response Extracts UN opl and TS DS , checks TS AS Extracts C i S 4 , DSS 2 and ASS 6 Checks ASS 6 = DSS 2 , extracts DSS 4 ASS 7 = ECDSA ( "Data" ) , checks ASS 7 = DSS 4 Figure 11. Protocol of PAX model between AS and DS C i CS AS Sends decision and data response Generates new TS AS ASS 2 tm = ASS 2 ⊕ ASS 1 ⊕ ASS 7 ⊕ CiS 4 ASS 3 tm = ASS 3 ⊕ ASS 1 ⊕ ASS 7 ⊕ CiS 4 TS AStm = TS AS ⊕ SN CS ⊕ UN opm UN sptm = UN spl ⊕ ASS 2 tm ⊕ TS AStm Response=( ASS 2 tm || ASS 3 tm || UN sptm || TS AStm || "Decision & Data") Sends response Receives decision and data response Extracts UN spl and TS AS , checks TS CS Extracts ASS 7 = CSS 2 ⊕ CSS 4 ⊕ CiS 4 ⊕ ASS 2 tm CSS 5 = ECDSA ( "Data") Checks CSS 5 = ASS 7 , extracts ASS 2 and ASS 3 Checks CSS 2 = ASS 2 and CSS 3 = ASS 3 Extracts ASS 1 and C i S 4 Checks the corresponding values for CSS 4 and C i S 4 Sends response Generates new TS CS CSS 2 tm = CSS 2 ⊕ CSS 1 ⊕ CSS 5 ⊕ CiS 4 CSS 3 tm = CSS 3 ⊕ CSS 1 ⊕ CSS 5 ⊕ CiS 4 TS CStm = TS CS ⊕ SN C ⊕ UN opm UN sptm = UN spl ⊕ CSS 2 tm ⊕ TS CStm Response=( CSS 2 tm || CSS 3 tm || UN sptm || TS CStm || "Decision & Data") Sends response Receives decision and data response Extracts UN spl and TS CS , checks TS Ci Extracts CSS 5 C i S 5 = ECDSA ( "Data") Checks C i S 5 = CSS 5 Extracts CSS 2 and CSS 3 Checks C i S 1 = CSS 2 and C i S 2 = CSS 3 Extracts CSS 1 and C i S 4 Checks the corresponding values for original C i S 3 and C i S 4 Figure 12. Protocol of PAX model between AS , CS and C i .

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 19 of 36 Int. J. Environ. Res. Public Health 2019 , 16 , 5 21 of 34 require the patient’s consent. Abraham should not know any secrets healthcare providers have used to authorise access to Rose’s data PAX provides security and privacy for all previous scenarios; indirect users cannot access the patient’s personal information because it is separate and completely hidden from the data. As a result, the user can retrieve this data to improve healthcare without penetrating the repository in DS Figure 15. Users’ scenarios in PAX *********************************** * Patient’s Data * *********************************** Pseudonym: RN optm & UN optm check 1: report: status: date: check 2: report: status: date: check 3: report: status: date: check 4: report: status: date: check 5: report: status: date: Figure 16. Part of Sarah’s data ********************************* * Patients’ DataSet * ********************************* ------------------------------------------------ No Check Report Status time date ------------------------------------------------ 1 check 3 Report 3 still 23:21:33 2017-09-05 2 check 1 Report 1 ok 14:36:45 2017-09-08 3 check 2 Report 2 normal 17:09:57 2017-09-08 5 check 3 Report 3 still 17:10:09 2017-09-10 6 check 2 Report 2 normal 12:28:20 2017-09-11 Figure 17. Part of medical records for patients 5.2. Security Analysis Security and privacy mechanisms in PAX have evaluated under theoretical analysis, BAN logic and AVISPA tool 5.2.1. Theoretical Security Analysis Organizational and managerial features are important in healthcare systems, but the key player in applying these systems is the use of security and privacy mechanisms for patient records [ 11 ]. Medical records in the EHR are sensitive data and require security mechanisms to protect their privacy from attackers. Also, the different levels and privileges of healthcare providers make the development of security mechanisms and authorisation models very difficult [ 4 ]. Moreover, applying privacy to medical records (EHR) requires the use of access models in the authorisation of users. Integrating Figure 13. Part of medical records for patients Figure 14. Authorisation of indirect users C i CS AS Sends Shamir’s request MS = ECDSA ( users 0 signatures ) SS s = Shamir ( MS , t , numberso f users ) Each C i has one SS Generates new TS AS Retrieves randomly 2 SS s or more ASS 2 tm = ASS 2 ⊕ ASS 1 ⊕ SS s ⊕ C i S 4 ⊕ S sp TS AStm = TS AS ⊕ SN CS ⊕ UN opm UN sptm = UN spl ⊕ ASS 2 tm ⊕ TS AStm Request=( ASS 2 tm || UN sptm || TS AStm ) Sends request Receives Shamir’s response Extracts UN spl and TS CS , checks TS AS MS = C i S 6 tm ⊕ S sp ⊕ ASS 1 Checks recieved MS with saved MS Uses PDP 2 to evaluate request ( SS , S op ) Specifies policy depend on policy’s ID ( Shamir || SP ) Checks attributes in PIP, applies policy in PAP If decision =“permit”, then creates data retrieval request by PRP to DS and sends to C i by CS (Figures 11 and 12 ) Receives Shamir’s request Extracts UN spl and TS AS , checks TS CS CSS 2 tm = ASS 2 tm ⊕ CSS 4 ⊕ CSS 1 Generates new TS CS TS CStm = TS CS ⊕ SN C ⊕ UN opm UN sptm = UN spl ⊕ CSS 2 tm ⊕ TS CStm Request=( CSS 2 tm || UN sptm || TS CStm ) Sends request Receives Shamir’s response Extracts UN spl and TS Ci , checks TS CS C i S 6 tm = C i S 6 tm ⊕ CSS 1 ⊕ CSS 4 Generates new TS CS TS CStm = TS CS ⊕ SN CS ⊕ UN opm UN sptm = UN spl ⊕ C i S 6 tm ⊕ TS CStm Response=( CiS 6 tm || UN sptm || TS CStm ) Sends response Receives Shamir’s request Extracts UN spl and TS CS , checks TS Ci C i S 6 = ECDSA ( SP ) SS s = CiS 1 ⊕ C i S 3 ⊕ CSS 2 tm ⊕ C i S 4 ⊕ C i S 6 Retrieves his SS MS = Shamir ( C 0 i sSS || SS s ) C i S 6 tm = C i S 6 ⊕ C i S 3 ⊕ MS Generates new TS Ci TS Ctm = TS Ci ⊕ SN C ⊕ UN spm UN sptm = UN spl ⊕ C i S 6 tm ⊕ TS Ctm Response=( C i S 6 tm || UN sptm || TS Ctm ) Sends response Figure 15. Protocol of PAX model for indirect users.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 20 of 36 5. Discussion In this Section, we discuss users scenarios and security analysis in PAX and demonstrate PAX’s ability to protect patients’ data during security and privacy implementation. In addition, the use of formal tools in the PAX security analysis is to prove security measures in repelling healthcare risks 5.1. Direct and Indirect Users Scenarios in PAX This Section illustrates four case scenarios in PAX that involve obtaining access to medical records in the EHR. We present our perspective of securing the privacy of patients’ data through the integration of anonymity, pseudonym, and XACML in our project. To provide user scenarios, we impose a number of EHR users with the PAX system, as shown in Figure 16 . The patient may suffer from many diseases such as diabetes, dementia, cancer, addiction, blood pressure, and heart disease, which means that the patient is associated with more than one doctor. The patient does not want other healthcare providers to access his/her personal information because of embarrassment or his/her psychological state. In addition, the doctor has treated a set of patients. Therefore, ensuring privacy in non-disclosure of personal information to patients requires each indirect user to apply HIPAA standards Assume we have three patients, Sara, John, and Rose, who suffer from diseases such as cancer, dementia, and diabetes respectively. Each disease requires a different level of care. For instance, a patient suffering from dementia needs a family member who assists with all of the patient’s tasks and is able to access all of the patient’s data. We assume that Julia is one of John’s relatives. In addition, there is a group of healthcare providers, including Simon, Adam, Hawa, and Abraham, who want access to patients’ medical records. These users can have different roles; for example, Adam may have the roles of advisor and doctor, and Abraham may be a doctor and an emergency doctor. Different user roles can be a major reason for breaching the privacy of medical records. Users such as patients (Sara and Rose) and the physician (Simon) need direct authorisation to EHR data because of persistent and regular requests to access the repository. For example, Simon is the general practitioner (GP) for Sara and needs to access her data every day or even more than once a day (under the PAX system, Sara’s data is private in data access requests by both Sara and Simon, as shown in Figure 17 ). 1 The first scenario (advisor): Simon needs a consultant (such as Adam) to diagnose Sara’s disease or to submit treatment suggestions (after taking Sara’s consent to seek specialist advice). Adam is not associated with Sara permanently and continuously and does not need Sara’s personal information; he only needs certain details of the patient’s data and medical reports. Therefore, in PAX, Adam needs to enter his name (Adam), the name of the doctor (Simon), and Sara’s pseudonym to access Sara’s data; he does not need to know Sara’s real attributes. Figure 17 shows Sara’s data, which can be obtained by Simon and Adam. We note from Figure 17 that the data received does not contain any of Sara’s attributes, and Adam does not use any real attributes for Sara, which means that PAX provides a high level of security and privacy that can prevent external and internal attacks 2 The second scenario (relative of a patient): Because the patient (John) suffers from dementia, he is unable to perform his duties. John needs a family helper (such as Julia) to access his medical data without misuse or to bypass these privileges to other medical records. Julia needs a request that contains her Sigs and John’s pseudonym to be considered a legitimate user in the system but is not authorised to access John’s data until the CS and AS complete the third authorisation protocol with the Shamir scheme 3 The third scenario (researcher): Hawa is a researcher and tries to access the server’s repository to use EHR in evaluating a medical study to develop a disease treatment. The researcher needs access to medical records sporadically and not permanently. The researcher is not associated with a particular patient and needs access to a set of the patients’ data. In addition, this indirect user does not need access to the patients’ attributes. Figure 13 shows a set of medical records obtained by Hawa in the case of authorisation without using any of the patients’ real attributes.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 21 of 36 4 The fourth scenario (emergency doctor): When Rose’s health has deteriorated significantly and suddenly, her doctor is not available for some reason. Rose needs an emergency doctor to treat and assess her condition quickly (e.g., Abraham). The emergency doctor needs to access Rose’s data without accessing personal information. In an emergency, access to a patient’s data does not require the patient’s consent. Abraham should not know any secrets healthcare providers have used to authorise access to Rose’s data PAX provides security and privacy for all previous scenarios; indirect users cannot access the patient’s personal information because it is separate and completely hidden from the data. As a result, the user can retrieve this data to improve healthcare without penetrating the repository in DS Figure 16. Users’ scenarios in PAX Int. J. Environ. Res. Public Health 2019 , 16 , 5 21 of 34 require the patient’s consent. Abraham should not know any secrets healthcare providers have used to authorise access to Rose’s data PAX provides security and privacy for all previous scenarios; indirect users cannot access the patient’s personal information because it is separate and completely hidden from the data. As a result, the user can retrieve this data to improve healthcare without penetrating the repository in DS Figure 15. Users’ scenarios in PAX *********************************** * Patient’s Data * *********************************** Pseudonym: RN optm & UN optm check 1: report: status: date: check 2: report: status: date: check 3: report: status: date: check 4: report: status: date: check 5: report: status: date: Figure 16. Part of Sarah’s data ********************************* * Patients’ DataSet * ********************************* ------------------------------------------------ No Check Report Status time date ------------------------------------------------ 1 check 3 Report 3 still 23:21:33 2017-09-05 2 check 1 Report 1 ok 14:36:45 2017-09-08 3 check 2 Report 2 normal 17:09:57 2017-09-08 5 check 3 Report 3 still 17:10:09 2017-09-10 6 check 2 Report 2 normal 12:28:20 2017-09-11 Figure 17. Part of medical records for patients 5.2. Security Analysis Security and privacy mechanisms in PAX have evaluated under theoretical analysis, BAN logic and AVISPA tool 5.2.1. Theoretical Security Analysis Organizational and managerial features are important in healthcare systems, but the key player in applying these systems is the use of security and privacy mechanisms for patient records [ 11 ]. Medical records in the EHR are sensitive data and require security mechanisms to protect their privacy from attackers. Also, the different levels and privileges of healthcare providers make the development of security mechanisms and authorisation models very difficult [ 4 ]. Moreover, applying privacy to medical records (EHR) requires the use of access models in the authorisation of users. Integrating Figure 17. Part of Sarah’s data 5.2. Security Analysis Security and privacy mechanisms in PAX have been evaluated under theoretical analysis, BAN logic and AVISPA tool.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 22 of 36 5.2.1. Theoretical Security Analysis Organizational and managerial features are important in healthcare systems, but the key player in applying these systems is the use of security and privacy mechanisms for patient records [ 11 ]. Medical records in the EHR are sensitive data and require security mechanisms to protect their privacy from attackers. In addition, the different levels and privileges of healthcare providers make the development of security mechanisms and authorisation models very difficult [ 4 ]. Moreover, applying privacy to medical records (EHR) requires the use of access models in the authorisation of users Integrating RBAC and ABAC gives more powerful features to PAX users. The result is an access control model based on roles and attributes that handle users’ requests at the coarse-grained and fine-grained levels. To increase security and privacy in the authorisation model, we have added a set of mechanisms to hide and separate personal information about data. The PAX system ensures that legitimate users access their specific data and, on the other hand, the privacy of medical records is maintained. Any healthcare system should support the basic security features of confidentiality, integrity, and availability (C.I.A.) [ 7 ], and there is a set of security features included in PAX 1 Integrity and non-repudiation of requests User requests and policies need protection from change or repudiation. We used the ECDSA algorithm to sign user attributes. Any change in the Sigs will be detected in the server because the server checks the users’ requests before authorising access to the data. In addition, the signatory party cannot deny its Sig. These features make the system immune against changing attacks such as MITM 2 Authentication and authorisation of requests Each EHR requires authentication and authorisation properties to protect medical records from unauthorised access. We applied ECDSA to the XACML v 3.0 to support these properties in PAX The use of Sigs in XACML between the C i and the CS , AS and DS support user authentication in addition to the use of policies and rules to identify authorised users and the level of access granted to them by providing anti privileged insider and authorisation policies 3 Confidentiality and anonymization One of the security features of hiding information is confidentiality. We applied ECDSA to add confidential requests to subjects and objects, and we added a Shamir scheme (backup or fail-open mechanism) to provide anonymity of SS s to users of the EHR system. This process prevents the attacker from seeing explicit attributes and does not allow the hacker to know the user-configured SS for any healthcare provider. A Shamir scheme ensures the anonymity of the Sig. This backup mechanism enables indirect users to access protected health information (PHI) with privacy and security 4 Pseudonymization A patient’s privacy requires the separation of personal information from the patient’s data Pseudonym prevents the intruder from knowing the data of any of the patients. PAX supports pseudonym in both subjects’ and objects’ attributes using pseudonyms for real attributes. This feature supports the privacy of a patient’s data 5 Audit and activities PAX records all user activities (requests and responses) to access medical records. It monitors user activities, including the number of access times, the result of the decision, and the amount of data required. The audit process is important for any healthcare system in determining users’ activities. PAX stores and organizes requests and responses for each user (patient, doctor, advisor, relative, researcher, and emergency doctor) separately to facilitate the management of these activities There is a range of attacks that pose a serious risk to any healthcare system. PAX’s security mechanisms act as countermeasures (as shown in Table 3 ) against known attacks 1 Availability attacks The server is vulnerable to the denial of service (DoS) attacks that are intended to disable the

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 23 of 36 service. In PAX, the indirect user creates a random Sig based on SS s provided by healthcare providers. The attacker cannot use the same SS s because the CS and AS will ignore the request The abundance of medical records is critical to healthcare providers’ flexible access. Therefore, supporting robustness in any healthcare system depends on preventing DoS attacks. Although the PAX system limits the risk of DoS attacks and provides successfully anti DoS, it does not do so fully because the attacker can still send requests without penetrating the patient’s personal information and data 2 Data and policies datasets attacks The data in the single server is considered an attractive treasure for attackers. In addition, policies contain the attributes and roles of users, which can assist attackers in carrying out an attack to recognise and access patients’ data. In PAX, even if the attacker obtained a patient’s data, the data would not be useful because both the stored and movable data would have a pseudonym. In addition, the data is stored (on DS ) separately from policies (on AS ) as well as PAX policies are associated with pseudonym and anonymity (both CS and DS do not have real attributes datasets for users), which prevent attackers from revealing subjects’ and objects’ attributes. Consequently, PAX provides effectively authorisation policies and anti datasets attacks 3 Modification attacks on requests Users’ requests from clients to server in PAX are fully protected from modification. PAX uses random nonces and Sigs to detect changing operation by intruders. Thus, PAX fully is secure against MITM attacks 4 Replay attacks The intruder cannot resend authorisation request to the network later because PAX produces a new timestamp ( TS C , TS CS , TS AS , and TS DS ) between PAX’s entities. Therefore, PAX withstands securely against replay attacks 5 Unauthorised access attacks User access to a repository depends on authorisation policies. We use XACML v 3.0 to create user policies. Integrating RBAC and ABAC into XACML prevents internal/external unauthorised users from accessing patients’ data. Thus, PAX reliably provides anti privileged insider depending on users’ role and attributes 6 Traffic analysis attacks To perform this attack, the hacker must analyse either the requests or the data moving between the source and the target. In PAX, if we assume that the attacker has some attributes (such as the name) and expects a specific patient, the attacker cannot use a keyword (name) and analyse it with multiple requests or medical records, even if it is the same user, to reveal its real attributes; the attacker cannot identify this data for a particular patient. Using pseudonym and anonymity prevents attackers from tracking/leaking traffic. For example, if advisor 1 and advisor 2 want patient 1 data, the generated requests will be different. This prevents the parsing of requests. As a result, PAX supports anonymity, pseudonym, anti traceability and anti leakage features 7 Impersonation attacks The intruder cannot impersonate PAX’s entities ( C i , CS , AS and DS ) because PAX uses secret nonces ( SN C , SN CS and SN AS ) and secret Sigs among entities to support mutual authentication and prevent impersonation attacks. Thereupon, PAX resists impersonation attacks of the fake client/server 8 Timing attacks This attack exploits the security procedure while calculating the time period for security operations (such as encryption and signing). PAX prevents these attacks because when the attacker gets multiple requests for the same user, the attacker will find that these requests contain different Sigs, and the attacker does not have the parameters to generate the Sig. In addition, ECDSA’s Sigs with 256-bit is resistant to timing attacks. Hence, PAX robustly prevents timing attacks.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 24 of 36 5.2.2. Proof of PAX Security Protocol To verify request source, freshness and legitimacy of entity in PAX, we have used Burrows, Abadi and Needham (BAN) logic that depends set of rules such as seeing (SR), message meaning (MMR), nonce verification (NVR), jurisdiction (JR), freshness conjuncatenation (FCR) and shared secret (SSR) (details about BAN’s notations and rules is available in [ 43 – 45 ]). With BAN, we prove that each entity in PAX deals with other legitimate entity when transferring the message (M) from the indirect user to the servers and vice versa. BAN structures consist of goals (G), idealized form, hypotheses (H) and proofs of goals by applying rules and hypotheses • Goals : PAX must provide the following goals to securely exchange messages among PAX entities – G 1 : C i |≡ C i CiS 3 −− * ) −− CS – G 2 : CS |≡ C i CSS 1 −− * ) −− CS – G 3 : CS |≡ CS CSS 4 −− * ) −− AS – G 4 : AS |≡ CS ASS 1 −−− * ) −−− AS – G 5 : AS |≡ DS ASS 5 −−− * ) −−− AS – G 6 : DS |≡ AS DSS 1 −−− * ) −−− DS • Idealized form : The messages (M) are represented in a BAN formula – M 1 : C i → CS : C i S 1 tm || RN sptm || UN sptm || N C || TS Ctm || SN Ctm , C i S 2 tm || RN optm || UN optm || N C || C i S 4 tm : h SN C i CiS 3 – M 2 : CS → AS : CSS 2 tm || RN sptm || UN sptm || N CS || TS Ctm || TS CStm || SN CStm , CSS 3 tm || RN optm || UN optm || C i S 4 tm : h SN CS i CSS 4 – M 3 : AS → CS : ASS 2 tm || UN sptm || TS AStm : h SN CS i ASS 1 – M 4 : CS → C i : CSS 2 tm || UN sptm || TS CStm : h SN C i CSS 1 – M 5 : C i → CS : C i S 6 tm || UN sptm || TS Ctm : h SN C i CiS 3 – M 6 : CS → AS : CiS 6 tm || UN sptm || TS CStm : h SN CS i CSS 4 – M 7 : AS → DS : ASS 6 tm || RN optm || UN optm || SN AStm || TS Ctm || TS AStm || C i S 4 tm : h SN AS i ASS 5 – M 8 : DS → AS : DSS 2 tm || DSS 4 tm || UN optm || TS DStm || C i S 4 tm || "Data": h SN AS i DSS 1 – M 9 : AS → CS : ASS 2 tm || ASS 3 tm || UN sptm || TS AStm || "Decision & Data": h SN CS i ASS 1 – M 10 : CS → C i : CSS 2 tm || CSS 3 tm || UN sptm || TS CStm || "Decision & Data": h SN C i CSS 1 • Hypotheses : Sets of hypotheses to analyse PAX’s security – H 1 : C i |≡ # ( SN C ) – H 2 : C i |≡ # ( TS Ci ) – H 3 : CS |≡ # ( SN C ) – H 4 : CS |≡ # ( TS CS ) – H 5 : CS |≡ # ( SN CS ) – H 6 : AS |≡ # ( SN CS ) – H 7 : AS |≡ # ( TS AS ) – H 8 : AS |≡ # ( SN AS ) – H 9 : DS |≡ # ( SN AS ) – H 10 : DS |≡ # ( TS DS ) – H 11 : CS |≡ C i = ⇒ SN C – H 12 : AS |≡ CS = ⇒ SN CS – H 13 : DS |≡ AS = ⇒ SN AS – H 14 : C i |≡ C i KCSpu 7−−−→ CS – H 15 : CS |≡ CS KCpu 7−−−→ C i – H 16 : CS |≡ CS KASpu 7−−−→ AS – H 17 : AS |≡ AS KCSpu 7−−−→ CS – H 18 : AS |≡ AS KDSpu 7−−−→ DS – H 19 : DS |≡ DS KASpu 7−−−→ AS • Proofs : We have used BAN logic to prove goals based on rules and hypotheses – M 1 : C i → CS : * SR : S 1: CS M 1 * MMR : Using MMR, S 1 and H 14, S 2: CS |≡ C i |∼ SN C * NVR and FCR : Using NVR, FCR, S 2, H 1 and H 2, S 3: CS |≡ C i |≡ SN C * JR : Using JR,S 3 and H 11, S 4: CS |≡ SN C * SSR : Using SSR, S 3, H 1 and H 2, S 5: CS |≡ C i CSS 1 −− * ) −− CS ( G 2 ) – M 2 : CS → AS : * SR : S 6: AS M 2 * MMR : Using MMR, S 6 and H 16, S 7: AS |≡ CS |∼ SN CS * NVR and FCR : Using NVR, FCR, S 7, H 4 and H 5, S 8: AS |≡ CS |≡ SN CS * JR : Using JR, S 8 and H 12, S 9: AS |≡ SN CS

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 25 of 36 * SSR : Using SSR, S 8, H 4 and H 5, S 10: AS |≡ CS ASS 1 −−− * ) −−− AS ( G 4 ) – M 3 : AS → CS : * SR : S 11: CS M 3 * MMR : Using MMR, S 11 and H 17, S 12: CS |≡ AS |∼ SN CS * NVR and FCR : Using NVR, FCR, S 12, H 6 and H 7, S 13: CS |≡ AS |≡ SN CS * JR : Using JR, S 13 and H 12, S 14: CS |≡ SN CS * SSR : Using SSR, S 13, H 6 and H 7, S 15: CS |≡ CS CSS 4 −− * ) −− AS ( G 3 ) – M 4 : CS → C i : * SR : S 16: C i M 4 * MMR : Using MMR, S 16 and H 15, S 17: C i |≡ CS |∼ SN C * NVR and FCR : Using NVR, FCR, S 17, H 3 and H 4, S 18: C i |≡ CS |≡ SN C * JR : Using JR, S 18 and H 11, S 19: C i |≡ SN C * SSR : Using SSR, S 18, H 3 and H 4, S 20: C i |≡ C i CiS 3 −− * ) −− CS ( G 1 ) – M 5 : C i → CS : Similar to the M 1 ( G 2 ) – M 6 : CS → AS : Similar to the M 2 ( G 4 ) – M 7 : AS → DS : * SR : S 21: DS M 7 * MMR : Using MMR, S 21 and H 18, S 22: DS |≡ AS |∼ SN AS * NVR and FCR : Using NVR, FCR, S 22, H 7 and H 8, S 23: DS |≡ AS |≡ SN AS * JR : Using JR, S 23 and H 13, S 24: DS |≡ SN AS * SSR : Using SSR, S 23, H 7 and H 8, S 25: DS |≡ DS DSS 1 −−− * ) −−− AS ( G 6 ) – M 8 : DS → AS : * SR : S 26: AS M 8 * MMR : Using MMR, S 26 and H 19, S 27: AS |≡ DS |∼ SN AS * NVR and FCR : Using NVR, FCR, S 27, H 9 and H 10, S 28: AS |≡ DS |≡ SN AS * JR : Using JR, S 28 and H 13, S 29: AS |≡ SN AS * SSR : Using SSR, S 28, H 9 and H 10, S 30: AS |≡ AS ASS 5 −−− * ) −−− DS ( G 5 ) – M 9 : AS → CS : Similar to the M 3 ( G 3 ) – M 10 : CS → C i : Similar to the M 4 ( G 1 ) 5.2.3. Proof of PAX Security Mechanism In this Section, we simulate the PAX scheme using the AVISPA tool to test and analyse that user authorisation information is safe during its transition between PAX entities and immune against active and passive attacks • AVISPA Briefly After designing any authorisation scheme, this scheme should be validated and its accuracy verified under a security analysis tool such as AVISPA to analyse, trace, observe and test the possibility of threat experimentally. The AVISPA tool is a push-button, testing/proofing model and is used directives and expressive terms intermediate format (IF) and output format (OF) to achieve simulation of security analysis [ 3 , 46 , 47 ]. AVISPA is a formal tool for analysing security schemes and applied by researchers to evaluate recent security protocols [ 48 – 51 ]. This tool is based on the Dolev-Yao (dy) model in analysis protocols during the transmission of information in the communication channels. It provides many features to analyse security schemes, such as a practical assessment of error detection and tracking, statistics, accurate results, testing of many techniques on the one protocol, ease of use, robustness of this tool to implement security

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 26 of 36 protocols [ 46 ]. This tool deals with high-level protocol specification language (HLPSL) and 4 backends such as Constraint-Logic-based Attack Searcher (CL-AtSe) to extract the results of the scheme analysis (more detailed information about the HLPSL language and the description of the AVISPA tool is available in [ 46 , 52 ]). • PAX with AVISPA In terms of HLSPL with AVISPA, PAX consists of four core (essential) roles: client ( C i ), centralServer ( CS ), attributesServer ( AS ) and dataServer ( DS ). In addition, there are supporting roles such as session, and environment, goal specification section. Essential roles include a transition section (to specify the sequence of communication operations in network framework). Supporting roles include a composition section (to specify the linking of sessions and roles). PAX depends on asymmetric cryptography by using ECDSA with public keys ( KC pu , KCS pu , KAS pu and KDS pu ) to perform security requirements (integrity, authentication and non-repudiation) Moreover, PAX applies nonces ( SN C , SN CS , SN AS and SN DS ) to support anonymity and timestamps ( TS C , TS CS , TS AS and TS DS ) to support freshness. Authorisation process for indirect users is illustrated by the HLPSL scripts in Figures A 1 – A 4 (in Appendix A ). Each role consists of the number of transitions, the receiving process (RCV), the sending process (SND), the sender’s claim process of fresh value and correct (witness), the validation process in receiver for the sender’s claim (request), the process of creating a fresh value for the nonce and timestamp (new) and the use of the private key (_inv) in PAX’s entities. At first, C i receives the start signal as in Figure A 1 , then the SND and RCV operations continue until the authorisation process is completed as in Figure 18 . Figure A 5 shows the roles of session, environment, and goal section. In the session role, a composition process has been performed for the four roles ( clienti , centralServer , attributeServer and dataServer ) and specifies the send and receive channels in the Dolev-Yao model. In the environment role, the PP, the goals specified in the goal section, and the known information for the intruder ( intruder _ knowledge ) have been defined. In this role, one or more sessions are composed, and we tested our scheme with sessions for replay, MITM, and impersonating entity attacks. We assumed that an intruder ( I ) creates a public key ( ki ) and has knowledge of the public keys ( kCpu , kCSpu , and kASpu ) of PAX’s entities in the network. Intruder attempts to resend legitimate user requests later, intercepts/modifies these requests, or impersonates the connecting entities using i constant rather than ci , cs , as and ds . The results displays that these attacks cannot penetrate the security goals in our scheme. Goal section describes verified goals in PAX, and provides 10 goals of secrecy (such as S _ ID , O _ ID , S _ R and O _ R represent the first secret (sec 1) and known only for both ci and cs ) and eight goals of authentication (such as UNspm , UNopm and TScs represent the first authentication between ci and cs ) • Simulation Result In this section, the simulation result is based on CL-AtSe backend in the AVISPA. Figure 19 displays the simulation result with the CL-AtSe backend, PAX clearly and accurately achieves the SAFE result in the SUMMARY section, bounded number of sessions in the DETAILS section, the goals of the scheme achieved (as_specified) in the GOAL section as well as statistical numbers such as time, number of nodes, and analysed states in the STATISTICS section. Based on this result, we note that our scheme is capable of preventing passive and active attacks such as replay, MITM, and impersonating, and that the goals of the scheme in Figure A 5 successfully prevented the violation of legitimate users information in the network authorisation.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 27 of 36 Int. J. Environ. Res. Public Health 2019 , 16 , 5 27 of 34 Figure 18. PAX’s framework in AVISPA SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS TYPED_MODEL PROTOCOL /home/span/span/testsuite/results/PAX.if GOAL As~Specified BACKEND CL-AtSe STATISTICS Analysed : 6912 states Reachable : 6912 states Translation: 2.12 seconds Computation: 139.21 seconds Figure 19. PAX’s result in CL-AtSe 6. Comparison Studies with Other Research In this Section, we explain how our project addresses the gaps in related works ([ 2 , 6 , 8 , 9 , 16 – 18 ]) PAX has not suffered from PERMIS’s problems [ 16 ] because each request to the healthcare provider has been signed randomly with the ECDSA algorithm, which includes both the roles ( RN s ) and the pseudonyms ( UN s ). In PAX, the policies are stored on the attributes server as Sigs and pseudonym rather than as explicit attributes in XACML (each user in PAX has attributes separate from other users that prevent the inheritance of attributes). Compared with [ 8 ], PAX has solved all requests standardization and structure problems by including XACML v 3.0 and ECDSA. XACML v 3.0 offers standardization, and generic and rich policy language and is unified with the context of subjects’ requests. It does not have problems converting requests from different sources. We also use ECDSA to generate very small keys relative to RSA to improve server performance. Furthermore, PAX does not need the keys complexity in PIPE [ 6 ] because XACML has the flexibility to handle practitioners and patients’ requests as well as we use only one high-performance signature algorithm. In our project, all the attributes in the requests and policies are not clearly written as in [ 2 ]. Moreover, data is anonymous to the patient when the data transferred from the source to the target because it is linked with a random pseudonym. Instead of one situation (emergency) as in HCPP, our project used several realistic situations such as doctor advisors, physician researchers, emergency doctors, and patients’ relatives for healthcare users and used the XACML v 3.0 policy language, which is effective for authorising users. Our project does not require continuous mining [ 9 ] of patient data but relies on an internal pseudonym to access medical records. XACS [ 17 ] offers protection only against external attacks, whereas PAX offers protection against internal and external attacks by preventing attackers from identifying the personal information of legitimate users or patients’ data. Finally, The access control model in [ 18 ] deals with real attributes, whereas PAX integrates signatures and pseudonyms within XACML’s policies and requests to prevent the exchange of users’ attributes clearly during the authorisation process in healthcare applications [ 18 ] Table 3 compares the security features provided in PAX and related works Figure 18. PAX’s framework in AVISPA Int. J. Environ. Res. Public Health 2019 , 16 , 5 27 of 34 Figure 18. PAX’s framework in AVISPA SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS TYPED_MODEL PROTOCOL /home/span/span/testsuite/results/PAX.if GOAL As~Specified BACKEND CL-AtSe STATISTICS Analysed : 6912 states Reachable : 6912 states Translation: 2.12 seconds Computation: 139.21 seconds Figure 19. PAX’s result in CL-AtSe 6. Comparison Studies with Other Research In this Section, we explain how our project addresses the gaps in related works ([ 2 , 6 , 8 , 9 , 16 – 18 ]) PAX has not suffered from PERMIS’s problems [ 16 ] because each request to the healthcare provider has been signed randomly with the ECDSA algorithm, which includes both the roles ( RN s ) and the pseudonyms ( UN s ). In PAX, the policies are stored on the attributes server as Sigs and pseudonym rather than as explicit attributes in XACML (each user in PAX has attributes separate from other users that prevent the inheritance of attributes). Compared with [ 8 ], PAX has solved all requests standardization and structure problems by including XACML v 3.0 and ECDSA. XACML v 3.0 offers standardization, and generic and rich policy language and is unified with the context of subjects’ requests. It does not have problems converting requests from different sources. We also use ECDSA to generate very small keys relative to RSA to improve server performance. Furthermore, PAX does not need the keys complexity in PIPE [ 6 ] because XACML has the flexibility to handle practitioners and patients’ requests as well as we use only one high-performance signature algorithm. In our project, all the attributes in the requests and policies are not clearly written as in [ 2 ]. Moreover, data is anonymous to the patient when the data transferred from the source to the target because it is linked with a random pseudonym. Instead of one situation (emergency) as in HCPP, our project used several realistic situations such as doctor advisors, physician researchers, emergency doctors, and patients’ relatives for healthcare users and used the XACML v 3.0 policy language, which is effective for authorising users. Our project does not require continuous mining [ 9 ] of patient data but relies on an internal pseudonym to access medical records. XACS [ 17 ] offers protection only against external attacks, whereas PAX offers protection against internal and external attacks by preventing attackers from identifying the personal information of legitimate users or patients’ data. Finally, The access control model in [ 18 ] deals with real attributes, whereas PAX integrates signatures and pseudonyms within XACML’s policies and requests to prevent the exchange of users’ attributes clearly during the authorisation process in healthcare applications [ 18 ] Table 3 compares the security features provided in PAX and related works Figure 19. PAX’s result in CL-AtSe 6. Comparison of Our Study with Other Research In this section, we explain how our project addresses the gaps in related works [ 2 , 6 , 8 , 9 , 16 – 18 ]. PAX has not suffered from PERMIS’s problems [ 16 ] because each request to the healthcare provider has been signed randomly with the ECDSA algorithm, which includes both the roles ( RN s ) and the pseudonyms ( UN s ). In PAX, the policies are stored on the attributes server as Sigs and pseudonym rather than as explicit attributes in XACML (each user in PAX has attributes separate from other users that prevent the inheritance of attributes). Compared with [ 8 ], PAX has solved all requests standardization and structure problems by including XACML v 3.0 and ECDSA. XACML v 3.0 offers standardization, and generic and rich policy language and is unified with the context of subjects’ requests. It does not have problems converting requests from different sources. We also use ECDSA to generate very small keys relative to RSA to improve server performance. Furthermore, PAX does not need the keys complexity in PIPE [ 6 ] because XACML has the flexibility to handle practitioners and

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 28 of 36 patients’ requests and we use only one high-performance signature algorithm. In our project, all the attributes in the requests and policies are not clearly written as in [ 2 ]. Moreover, data is anonymous to the patient when the data is transferred from the source to the target because it is linked with a random pseudonym Instead of one situation (emergency) as in HCPP, our project used several realistic situations such as doctor advisors, physician researchers, emergency doctors, and patients’ relatives for healthcare users and used the XACML v 3.0 policy language, which is effective for authorising users. Our project does not require continuous mining [ 9 ] of patient data but relies on an internal pseudonym to access medical records. XACS [ 17 ] offers protection only against external attacks, whereas PAX offers protection against internal and external attacks by preventing attackers from identifying the personal information of legitimate users or patients’ data. Finally, The access control model in [ 18 ] deals with real attributes, whereas PAX integrates signatures and pseudonyms within XACML’s policies and requests to prevent the exchange of users’ attributes clearly during the authorisation process in healthcare applications [ 18 ]. Table 3 compares the security features provided in PAX and related works Table 3. Comparison of security features Security Feature Chadwick et al. Quantin et al. Riedl et al. Gajanayake et al. Sun et al. Jo & Chung Seol et al. PAX [ 16 ] [ 8 ] [ 6 ] [ 2 ] [ 9 ] [ 17 ] [ 18 ] Mutual authentication X Preserving anonymity X X X X Pseudonym X X X X Anti DoS X X X X Anti dataset attack X X Anti MITM X X X X X X Anti replay X X X X X X X Anti privileged insider X X Anti traceability X X X Anti impersonation X Anti timing X X Anti leakage X X X Authorisation policies X X X X X 7. Conclusions and Future Work The security and privacy of medical records have become essential requirements for the establishment of any healthcare system in recent years. To ensure the provision of security and privacy, this paper proposes a PAX authorisation system that supports pseudonym, anonymity and XACML. Specifically, the proposed system uses a random pseudonym to separate personal information about patients’ data, anonymity to hide subjects’ information, and XACML to create distributed access control policies to authorise subjects’ requests to objects’ records in EHR. Different from a large amount of theoretical investigation in the existing literature, this paper achieves the security and privacy preservation by utilizing the pseudonym and anonymity techniques, which can reduce the unnecessary time consumption and the burden on the server. Security analyses using the theoretical method or formal methods (BAN and AVISPA) demonstrate that PAX is safe, maintains the privacy of healthcare users and alleviates the risk of penetrating compared to existing research. We believe that the PAX system provides a security high-level that maintains patients’ privacy, and the system especially protects patients’ information from indirect users (advisors, patients’ relatives, researchers, and emergency doctors), who have been considered a serious security threat to any healthcare system because they can carry out internal attacks using the privileges granted to them. To further develop the proposed PAX system, we intend to add some features to support security and privacy in EHR 1 PAX requires an authentication mechanism that is more stringent to identify legitimate users in the network and prevent counterfeit requests. We intend to use a one-time password based on users’ attributes, temporary parameters, and Sigs to support the authentication of legitimate users in PAX.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 29 of 36 2 Patients’ data requires devices (such as WSN) to be aggregated accurately and continuously and sent to the CS and DS . However, data collection and storage on the server requires security mechanisms 3 We will focus on patients’ data without the use of cryptographic mechanisms in examining the patients’ daily condition, use patients’ real data to test PAX with large data, and allow PAX to distinguish between patients’ history, daily status, and purpose of data access. We will also encrypt the patients’ old medical records (within a certain period) that are not frequently retrieved by healthcare providers in a manner that does not affect the efficiency of the server in providing the service to users 4 We will investigate the application of a light hash algorithm to generate patients’ pseudonyms, which support increased randomization while maintaining system performance as an additional security measure to protect the privacy of medical records in EHR 5 We intend to build an evaluation system to assess PAX in the exchange of requests among network entities C i , CS , AS and DS in terms of authorisation request delay, cost of signature and verification, storage and throughput Author Contributions: conceptualization, M.A. and Z.Z.; methodology, M.A.; software, M.A.; formal analysis, Z.Z.; writing—original draft preparation, M.A.; writing—review and editing, M.A., Z.Z. and J.Z.; supervision, Z.Z. and J.Z.; project administration, M.A Funding: This research received no external funding Conflicts of Interest: The authors declare that they have no conflict of interest Abbreviations The following abbreviations are used in this manuscript: C i Client entity CS , AS , DS Central server, Attributes server and Data server MS Master secret/Master signature SS One secret sharing S ID , O ID Subject ID, Object ID S R , O R Subject role, Object role UR i User’s role (patient, patient relative or provider) CN i Client’s number RN i Role’s number UN i User’s number SP , OP Subject ’s pseudonym and Object ’s pseudonym S sp , S op Signature of SP and Signature of OP RN sp , UN sp RN i , UN i for SP RN op , UN op RN i , UN i for OP N , SN Random nonces and random secret nonce TS Timestamp C i S j Signature generated by C i and j is signature number CSS j Signature generated by CS ASS j Signature generated by AS DSS j Signature generated by DS k , ⊕ , tm Concatenation operation, Exclusive or operation and Temporary

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 30 of 36 Appendix A The following scripts represent roles in AVISPA tool: Int. J. Environ. Res. Public Health 2019 , 16 , 5 30 of 34 role clienti(Ci,CS:agent,KCpu,KCSpu:public_key,H:hash_func, S_ID,O_ID,S_R,O_R:message,SND,RCV:channel(dy)) played_by Ci def= local State:nat, TSc,TScs,TSctm,TScstm,Nc,SNc,SNctm:text, CiS 1,CiS 2,CiS 3,CiS 4,CiS 5,CiS 6,CiS 1 tm,CiS 2 tm,CiS 4 tm, CiS 6 tm,CSS 2 tm,CSS 3 tm,CSS 5:text, SP,OP,UNspl,UNspm,UNsph,UNopl,UNopm,UNoph, RNspl,RNspm,RNsph,RNopl,RNopm,RNoph:text, RNspn,RNopn,UNspn,UNopn:text,AS,DS:agent, MS,SS,SSs,Decision,Data:text const Section~1,sec 2,sec 3,sec 4,sec 5,sec 6,auth 1,auth 2:protocol_id init State := 0 transition 1.State=0 /\ RCV(start) =|> State’:=1 /\Nc’:=new()/\SNc’:=new()/\TSc’:=new() /\CiS 1’:={H(RNspm.UNspm.Nc’.TSc’)}_inv(KCpu) /\CiS 2’:={H(RNopm.UNopm.Nc’.TSc’)}_inv(KCpu) /\CiS 3’:={H(SNc’)}_inv(KCpu)/\ CiS 4’:={H(RNoph .UNoph.TSc’)}_inv(KCpu) /\CiS 1 tm’:=xor(CiS 1’,CiS 3’)/\CiS 2 tm’:=xor(CiS 2’,CiS 3’) /\TSctm’:=xor(TSc’,xor(SNc’,xor(RNspm,UNspm))) /\SNctm’:=xor(UNspm,xor(UNopm,xor(SNc’ ,xor(CiS 4’,CiS 1 tm’)))) /\CiS 4 tm’:=xor(CiS 4’,xor(UNspm,xor(UNopm,CiS 2 tm’))) /\RNspn’:=xor(RNspl,xor(CiS 1 tm’,SNctm’)) /\RNopn’:=xor(RNopl,xor(CiS 2 tm’,SNctm’)) /\UNspn’:=xor(UNspl,xor(CiS 1 tm’,SNctm’)) /\UNopn’:=xor(UNopl,xor(CiS 2 tm’,SNctm’)) %Ci sends XACML’s request to CS /\SND(CS.CiS 1 tm’.RNspn’.UNspn’.Nc’.TSctm’.SNctm’ .CiS 2 tm’.RNopn’.UNopn’.Nc’.CiS 4 tm’) /\secret({S_ID,O_ID,S_R,O_R},sec 1,{Ci,AS}) /\secret({SNc’,CiS 3’,TSc’},sec 2,{Ci,CS}) /\secret({CiS 1’,CiS 2’},sec 3,{Ci,CS,AS}) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{Ci,CS}) %Ci receives first authorisation response from CS 2. State = 1/\RCV(Ci.CSS 2 tm’.UNspn’.TScstm’)=|> State’:= 2 /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNc,UNopm)) /\CiS 6’:={H(SP)}_inv(KCpu) /\SSs’:=xor(CiS 1,xor(CiS 3,xor(CSS 2 tm’,xor(CiS 4,CiS 6’)))) /\MS’:= {(SS.SSs’)} /\CiS 6 tm’:=xor(CiS 6’,xor(CiS 3,MS’)) /\secret({OP,CiS 4},sec 5,{Ci,AS,DS}) /\secret({SP,CiS 6,MS’,SS},sec 6,{Ci,AS}) /\TSc’:=new()/\TSctm’:=xor(TSc’,xor(SNc,UNspm)) /\UNspn’:=xor(UNspl’,xor(CiS 6 tm’,TSctm’)) %Ci sends Shamir’s response to CS /\SND(CS.CiS 6 tm’.UNspn’.TSctm’) /\witness(Ci,CS,auth 1,{UNspm,UNopm,TScs}) %Ci receives decision & data from CS 3.State=2/\RCV(Ci.CSS 2 tm’.CSS 3 tm’.UNspn’.TScstm’ .Decision.Data)=|> State’:=3 /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNc,UNopm)) /\CSS 5’:=xor(CiS 1’,xor(CiS 3’,xor(CSS 2 tm’,CiS 4’))) /\CiS 5’:={H(Data)}_inv(KCSpu) /\CiS 1’:=xor(CSS 2 tm’,xor(CiS 3,xor(CiS 5’,CiS 4))) /\CiS 2’:=xor(CSS 3 tm’,xor(CiS 3,xor(CiS 5’,CiS 4))) /\CiS 3’:=xor(CiS 2’,xor(CSS 2 tm’,xor(CiS 5’,CiS 4))) /\CiS 4’:=xor(CiS 1’,xor(CiS 3’,xor(CiS 5’,CSS 2 tm’))) /\request(Ci,CS,auth 2,{SNc,CiS 3,CiS 4,TSc}) end role Figure A 1. C i role of PAX in HLPSL role centralServer(CS,Ci,AS:agent,KCSpu,KCpu,KASpu:public_key, H:hash_func,SND,RCV:channel(dy)) played_by CS def= local State:nat,TSc,TScs,TSas,TSctm,TScstm,TSastm,Nc,Ncs,SNc, SNcs,SNctm,SNcstm:text,CSS 1,CSS 2,CSS 3,CSS 4,CSS 5,CSS 2 tm, CSS 3 tm,CiS 1,CiS 2,CiS 4,CiS 1 tm,CiS 2 tm,CiS 4 tm,CiS 6 tm:text, ASS 2,ASS 3,ASS 7,ASS 2 tm,ASS 3 tm:text,Decision,Data:text, UNspl,UNspm,UNopl,UNopm,RNspl,RNspm,RNopl,RNopm, RNspn,RNopn,UNspn,UNopn:text const Section~2,sec 3,sec 4,sec 7,auth 1,auth 2,auth 3,auth 4:protocol_id init State := 0 transition %CS receives XACML’s request from Ci 1.State=0 /\ RCV(CS.CiS 1 tm’.RNspn’.UNspn’.Nc’.TSctm’.SNctm’ .CiS 2 tm’.RNopn’.UNopn’.Nc’.CiS 4 tm’)=|>State’:=1 /\RNspl’:=xor(RNspn’,xor(CiS 1 tm’,SNctm’)) /\RNopl’:=xor(RNopn’,xor(CiS 2 tm’,SNctm’)) /\UNspl’:=xor(UNspn’,xor(CiS 1 tm’,SNctm’)) /\UNopl’:=xor(UNopn’,xor(CiS 2 tm’,SNctm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNspm,xor(UNopm,CiS 2 tm’))) /\SNc’:=xor(UNspm,xor(UNopm,xor(SNctm’,xor(CiS 4’,CiS 1 tm’)))) /\TSc’:=xor(TSctm’,xor(SNc’,xor(RNspm,UNspm))) /\CSS 1’:={H(SNc’)}_inv(KCpu) /\CiS 1’:=xor(CiS 1 tm’,CSS 1’)/\CiS 2’:= xor(CiS 2 tm’,CSS 1’) /\CSS 2’:={H(RNspm.UNspm.Nc’.TSc’)}_inv(KCpu) /\CSS 3’:={H(RNopm.UNopm.Nc’.TSc’)}_inv(KCpu) /\secret({SNc’,CSS 1’,TSc’},sec 2,{CS,Ci}) /\secret({CSS 2’,CSS 3’},sec 3,{CS,Ci,AS}) %CS creates authorisation request to AS /\SNcs’:=new() /\TScs’:=new() /\CSS 4’:= {H(SNcs’)}_inv(KCSpu) /\CSS 2 tm’:=xor(CSS 2’,CSS 4’) /\CSS 3 tm’:=xor(CSS 3’,CSS 4’) /\Ncs’:=xor(Nc’,xor(TSc’,xor(TScs’,SNcs’))) /\TSctm’:=xor(TSc’,xor(SNcs’,xor(RNspm,UNspm))) /\TScstm’:=xor(TScs’,xor(SNcs’,xor(RNopm,UNopm))) /\SNcstm’:=xor(UNspm,xor(UNopm,xor(SNcs’,xor(CiS 4’,CSS 2 tm)))) /\CiS 4 tm’:=xor(CiS 4’,xor(UNspm,xor(UNopm,CSS 3 tm’))) /\RNspn’:=xor(RNspl,xor(CSS 2 tm’,SNcstm’)) /\RNopn’:=xor(RNopl,xor(CSS 3 tm’,SNcstm’)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,SNcstm’)) /\UNopn’:=xor(UNopl,xor(CSS 3 tm’,SNcstm’)) %CS sends request to AS /\SND(AS.CSS 2 tm’.RNspn’.UNspn’.Ncs’.TSctm’.TScstm’.SNcstm’ .CSS 3 tm’.RNopn’.UNopn’.CiS 4 tm’) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{CS,AS}) /\secret({SNcs’,CSS 4’,TScs’,Nc’},sec 7,{CS,AS}) %CS receives authorisation response from AS 2.State=1 /\ RCV(CS.ASS 2 tm’.UNspn’.TSastm’)=|> State’:=2/\CSS 2 tm’:=xor(ASS 2 tm’,xor(CSS 4,CSS 1)) /\TScs’:=new() /\TScstm’:=xor(TScs’,xor(SNc,UNopm)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,TScstm’)) /\witness(CS,AS,auth 3,{UNspm,UNopm,Nc,TSc,TSas}) %CS sends authorisation response to Ci /\SND(Ci.CSS 2 tm’.UNspn’.TScstm’) %CS receives Shamir’s response from Ci 3. State = 2 /\RCV(CS.CiS 6 tm’.UNspn’.TSctm’)=|> State’:=3/\UNspl’:=xor(UNspn’,xor(CiS 6 tm’,TSctm’)) /\TSc’:=xor(TSctm’,xor(SNc,UNspm)) /\CiS 6 tm’:=xor(CiS 6 tm’,xor(CSS 1,CSS 4)) /\request(CS,Ci,auth 1,{UNspm,UNopm,TScs}) /\TScs’:=new() /\TScstm’:=xor(TScs’,xor(SNcs,UNopm)) /\UNspn’:=xor(UNspl,xor(CiS 6 tm’,TScstm’)) %CS sends Shamir’s response to AS /\SND(AS.CiS 6 tm’.UNspn’.TScstm’) %CS receives decision & data response from AS 4.State=3 /\RCV(CS.ASS 2 tm’.ASS 3 tm’.UNspn’.TSastm’.Decision Data)=|>State’:=4/\UNspl’:=xor(UNspn’,xor(ASS 2 tm’,TSastm’)) /\TSas’:=xor(TSastm’,xor(SNcs,UNopm)) /\ASS 7’:=xor(CSS 2,xor(CSS 4,xor(CiS 4,ASS 2 tm))) /\CSS 5’:={H(Data)}_inv(KASpu) /\ASS 2’:=xor(ASS 2 tm’,xor(CSS 4,xor(ASS 7,CiS 4))) /\ASS 3’:=xor(ASS 3 tm,xor(CSS 4,xor(ASS 7,CiS 4))) /\CiS 4’:=xor(ASS 2 tm’,xor(CSS 4,xor(ASS 7,ASS 2’))) /\request(CS,AS,auth 4,{SNcs,CSS 1,CiS 4,TScs}) /\TScs’:=new() /\CSS 2 tm’:=xor(CSS 2,xor(CSS 1,xor(CSS 5,CiS 4))) /\CSS 3 tm’:=xor(CSS 3,xor(CSS 1,xor(CSS 5,CiS 4))) /\TScstm’:=xor(TScs’,xor(SNc,UNopm)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,TScstm’)) %CS sends decision & data response to Ci /\SND(Ci.CSS 2 tm’.CSS 3 tm’.UNspn’.TScstm’.Decision.Data) /\witness(CS,Ci,auth 2,{SNc,CSS 1,CiS 4,TSc}) end role Figure A 2. CS role of PAX in HLPSL Figure A 1. C i role of PAX in high-level protocol specification language (HLPSL).

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 31 of 36 Int. J. Environ. Res. Public Health 2019 , 16 , 5 30 of 34 role clienti(Ci,CS:agent,KCpu,KCSpu:public_key,H:hash_func, S_ID,O_ID,S_R,O_R:message,SND,RCV:channel(dy)) played_by Ci def= local State:nat, TSc,TScs,TSctm,TScstm,Nc,SNc,SNctm:text, CiS 1,CiS 2,CiS 3,CiS 4,CiS 5,CiS 6,CiS 1 tm,CiS 2 tm,CiS 4 tm, CiS 6 tm,CSS 2 tm,CSS 3 tm,CSS 5:text, SP,OP,UNspl,UNspm,UNsph,UNopl,UNopm,UNoph, RNspl,RNspm,RNsph,RNopl,RNopm,RNoph:text, RNspn,RNopn,UNspn,UNopn:text,AS,DS:agent, MS,SS,SSs,Decision,Data:text const Section~1,sec 2,sec 3,sec 4,sec 5,sec 6,auth 1,auth 2:protocol_id init State := 0 transition 1.State=0 /\ RCV(start) =|> State’:=1 /\Nc’:=new()/\SNc’:=new()/\TSc’:=new() /\CiS 1’:={H(RNspm.UNspm.Nc’.TSc’)}_inv(KCpu) /\CiS 2’:={H(RNopm.UNopm.Nc’.TSc’)}_inv(KCpu) /\CiS 3’:={H(SNc’)}_inv(KCpu)/\ CiS 4’:={H(RNoph .UNoph.TSc’)}_inv(KCpu) /\CiS 1 tm’:=xor(CiS 1’,CiS 3’)/\CiS 2 tm’:=xor(CiS 2’,CiS 3’) /\TSctm’:=xor(TSc’,xor(SNc’,xor(RNspm,UNspm))) /\SNctm’:=xor(UNspm,xor(UNopm,xor(SNc’ ,xor(CiS 4’,CiS 1 tm’)))) /\CiS 4 tm’:=xor(CiS 4’,xor(UNspm,xor(UNopm,CiS 2 tm’))) /\RNspn’:=xor(RNspl,xor(CiS 1 tm’,SNctm’)) /\RNopn’:=xor(RNopl,xor(CiS 2 tm’,SNctm’)) /\UNspn’:=xor(UNspl,xor(CiS 1 tm’,SNctm’)) /\UNopn’:=xor(UNopl,xor(CiS 2 tm’,SNctm’)) %Ci sends XACML’s request to CS /\SND(CS.CiS 1 tm’.RNspn’.UNspn’.Nc’.TSctm’.SNctm’ .CiS 2 tm’.RNopn’.UNopn’.Nc’.CiS 4 tm’) /\secret({S_ID,O_ID,S_R,O_R},sec 1,{Ci,AS}) /\secret({SNc’,CiS 3’,TSc’},sec 2,{Ci,CS}) /\secret({CiS 1’,CiS 2’},sec 3,{Ci,CS,AS}) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{Ci,CS}) %Ci receives first authorisation response from CS 2. State = 1/\RCV(Ci.CSS 2 tm’.UNspn’.TScstm’)=|> State’:= 2 /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNc,UNopm)) /\CiS 6’:={H(SP)}_inv(KCpu) /\SSs’:=xor(CiS 1,xor(CiS 3,xor(CSS 2 tm’,xor(CiS 4,CiS 6’)))) /\MS’:= {(SS.SSs’)} /\CiS 6 tm’:=xor(CiS 6’,xor(CiS 3,MS’)) /\secret({OP,CiS 4},sec 5,{Ci,AS,DS}) /\secret({SP,CiS 6,MS’,SS},sec 6,{Ci,AS}) /\TSc’:=new()/\TSctm’:=xor(TSc’,xor(SNc,UNspm)) /\UNspn’:=xor(UNspl’,xor(CiS 6 tm’,TSctm’)) %Ci sends Shamir’s response to CS /\SND(CS.CiS 6 tm’.UNspn’.TSctm’) /\witness(Ci,CS,auth 1,{UNspm,UNopm,TScs}) %Ci receives decision & data from CS 3.State=2/\RCV(Ci.CSS 2 tm’.CSS 3 tm’.UNspn’.TScstm’ .Decision.Data)=|> State’:=3 /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNc,UNopm)) /\CSS 5’:=xor(CiS 1’,xor(CiS 3’,xor(CSS 2 tm’,CiS 4’))) /\CiS 5’:={H(Data)}_inv(KCSpu) /\CiS 1’:=xor(CSS 2 tm’,xor(CiS 3,xor(CiS 5’,CiS 4))) /\CiS 2’:=xor(CSS 3 tm’,xor(CiS 3,xor(CiS 5’,CiS 4))) /\CiS 3’:=xor(CiS 2’,xor(CSS 2 tm’,xor(CiS 5’,CiS 4))) /\CiS 4’:=xor(CiS 1’,xor(CiS 3’,xor(CiS 5’,CSS 2 tm’))) /\request(Ci,CS,auth 2,{SNc,CiS 3,CiS 4,TSc}) end role Figure A 1. C i role of PAX in HLPSL role centralServer(CS,Ci,AS:agent,KCSpu,KCpu,KASpu:public_key, H:hash_func,SND,RCV:channel(dy)) played_by CS def= local State:nat,TSc,TScs,TSas,TSctm,TScstm,TSastm,Nc,Ncs,SNc, SNcs,SNctm,SNcstm:text,CSS 1,CSS 2,CSS 3,CSS 4,CSS 5,CSS 2 tm, CSS 3 tm,CiS 1,CiS 2,CiS 4,CiS 1 tm,CiS 2 tm,CiS 4 tm,CiS 6 tm:text, ASS 2,ASS 3,ASS 7,ASS 2 tm,ASS 3 tm:text,Decision,Data:text, UNspl,UNspm,UNopl,UNopm,RNspl,RNspm,RNopl,RNopm, RNspn,RNopn,UNspn,UNopn:text const Section~2,sec 3,sec 4,sec 7,auth 1,auth 2,auth 3,auth 4:protocol_id init State := 0 transition %CS receives XACML’s request from Ci 1.State=0 /\ RCV(CS.CiS 1 tm’.RNspn’.UNspn’.Nc’.TSctm’.SNctm’ .CiS 2 tm’.RNopn’.UNopn’.Nc’.CiS 4 tm’)=|>State’:=1 /\RNspl’:=xor(RNspn’,xor(CiS 1 tm’,SNctm’)) /\RNopl’:=xor(RNopn’,xor(CiS 2 tm’,SNctm’)) /\UNspl’:=xor(UNspn’,xor(CiS 1 tm’,SNctm’)) /\UNopl’:=xor(UNopn’,xor(CiS 2 tm’,SNctm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNspm,xor(UNopm,CiS 2 tm’))) /\SNc’:=xor(UNspm,xor(UNopm,xor(SNctm’,xor(CiS 4’,CiS 1 tm’)))) /\TSc’:=xor(TSctm’,xor(SNc’,xor(RNspm,UNspm))) /\CSS 1’:={H(SNc’)}_inv(KCpu) /\CiS 1’:=xor(CiS 1 tm’,CSS 1’)/\CiS 2’:= xor(CiS 2 tm’,CSS 1’) /\CSS 2’:={H(RNspm.UNspm.Nc’.TSc’)}_inv(KCpu) /\CSS 3’:={H(RNopm.UNopm.Nc’.TSc’)}_inv(KCpu) /\secret({SNc’,CSS 1’,TSc’},sec 2,{CS,Ci}) /\secret({CSS 2’,CSS 3’},sec 3,{CS,Ci,AS}) %CS creates authorisation request to AS /\SNcs’:=new() /\TScs’:=new() /\CSS 4’:= {H(SNcs’)}_inv(KCSpu) /\CSS 2 tm’:=xor(CSS 2’,CSS 4’) /\CSS 3 tm’:=xor(CSS 3’,CSS 4’) /\Ncs’:=xor(Nc’,xor(TSc’,xor(TScs’,SNcs’))) /\TSctm’:=xor(TSc’,xor(SNcs’,xor(RNspm,UNspm))) /\TScstm’:=xor(TScs’,xor(SNcs’,xor(RNopm,UNopm))) /\SNcstm’:=xor(UNspm,xor(UNopm,xor(SNcs’,xor(CiS 4’,CSS 2 tm)))) /\CiS 4 tm’:=xor(CiS 4’,xor(UNspm,xor(UNopm,CSS 3 tm’))) /\RNspn’:=xor(RNspl,xor(CSS 2 tm’,SNcstm’)) /\RNopn’:=xor(RNopl,xor(CSS 3 tm’,SNcstm’)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,SNcstm’)) /\UNopn’:=xor(UNopl,xor(CSS 3 tm’,SNcstm’)) %CS sends request to AS /\SND(AS.CSS 2 tm’.RNspn’.UNspn’.Ncs’.TSctm’.TScstm’.SNcstm’ .CSS 3 tm’.RNopn’.UNopn’.CiS 4 tm’) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{CS,AS}) /\secret({SNcs’,CSS 4’,TScs’,Nc’},sec 7,{CS,AS}) %CS receives authorisation response from AS 2.State=1 /\ RCV(CS.ASS 2 tm’.UNspn’.TSastm’)=|> State’:=2/\CSS 2 tm’:=xor(ASS 2 tm’,xor(CSS 4,CSS 1)) /\TScs’:=new() /\TScstm’:=xor(TScs’,xor(SNc,UNopm)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,TScstm’)) /\witness(CS,AS,auth 3,{UNspm,UNopm,Nc,TSc,TSas}) %CS sends authorisation response to Ci /\SND(Ci.CSS 2 tm’.UNspn’.TScstm’) %CS receives Shamir’s response from Ci 3. State = 2 /\RCV(CS.CiS 6 tm’.UNspn’.TSctm’)=|> State’:=3/\UNspl’:=xor(UNspn’,xor(CiS 6 tm’,TSctm’)) /\TSc’:=xor(TSctm’,xor(SNc,UNspm)) /\CiS 6 tm’:=xor(CiS 6 tm’,xor(CSS 1,CSS 4)) /\request(CS,Ci,auth 1,{UNspm,UNopm,TScs}) /\TScs’:=new() /\TScstm’:=xor(TScs’,xor(SNcs,UNopm)) /\UNspn’:=xor(UNspl,xor(CiS 6 tm’,TScstm’)) %CS sends Shamir’s response to AS /\SND(AS.CiS 6 tm’.UNspn’.TScstm’) %CS receives decision & data response from AS 4.State=3 /\RCV(CS.ASS 2 tm’.ASS 3 tm’.UNspn’.TSastm’.Decision Data)=|>State’:=4/\UNspl’:=xor(UNspn’,xor(ASS 2 tm’,TSastm’)) /\TSas’:=xor(TSastm’,xor(SNcs,UNopm)) /\ASS 7’:=xor(CSS 2,xor(CSS 4,xor(CiS 4,ASS 2 tm))) /\CSS 5’:={H(Data)}_inv(KASpu) /\ASS 2’:=xor(ASS 2 tm’,xor(CSS 4,xor(ASS 7,CiS 4))) /\ASS 3’:=xor(ASS 3 tm,xor(CSS 4,xor(ASS 7,CiS 4))) /\CiS 4’:=xor(ASS 2 tm’,xor(CSS 4,xor(ASS 7,ASS 2’))) /\request(CS,AS,auth 4,{SNcs,CSS 1,CiS 4,TScs}) /\TScs’:=new() /\CSS 2 tm’:=xor(CSS 2,xor(CSS 1,xor(CSS 5,CiS 4))) /\CSS 3 tm’:=xor(CSS 3,xor(CSS 1,xor(CSS 5,CiS 4))) /\TScstm’:=xor(TScs’,xor(SNc,UNopm)) /\UNspn’:=xor(UNspl,xor(CSS 2 tm’,TScstm’)) %CS sends decision & data response to Ci /\SND(Ci.CSS 2 tm’.CSS 3 tm’.UNspn’.TScstm’.Decision.Data) /\witness(CS,Ci,auth 2,{SNc,CSS 1,CiS 4,TSc}) end role Figure A 2. CS role of PAX in HLPSL Figure A 2. CS role of PAX in HLPSL.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 32 of 36 Int. J. Environ. Res. Public Health 2019 , 16 , 5 31 of 34 role attributesServer(AS,CS,DS:agent,KASpu,KCSpu,KDSpu:public_key, Ssp,Sop:text,H:hash_func,SND,RCV:channel(dy)) played_by AS def= local State:nat, TSc,TScs,TSas,TSds,TSctm,TScstm,TSastm,TSdstm,Nc, Ncs,SNcs,SNas,SNcstm,SNastm:text, ASS 1,ASS 2,ASS 3,ASS 4,ASS 5, ASS 6,ASS 7,ASS 2 tm,ASS 3 tm,ASS 6 tm:text, CiS 4,CiS 4 tm,CiS 6 tm,CSS 2, CSS 3,CSS 2 tm,CSS 3 tm,DSS 2 tm,DSS 4 tm,DSS 4:text, SP,OP,URsp,UNsp,URop,UNop,RNsp,RNop:text, UNspl,UNspm,UNsph,UNopl,UNopm,UNoph:text, RNspl,RNspm,RNsph,RNopl,RNopm,RNoph:text, RNspn,RNopn,UNspn,UNopn:text, S_ID,O_ID,S_R,O_R:message,Ci:agent,SSs,MS,Data,Decision:text const Section~1,sec 3,sec 4,sec 5,sec 6,sec 7,sec 8,sec 9,sec 10,auth 3,auth 4 ,auth 5,auth 6:protocol_id init State := 0 transition %AS receives from CS 1.State = 0 /\ RCV(AS.CSS 2 tm’.RNspn’.UNspn’.Ncs’.TSctm’.TScstm’ .SNcstm’.CSS 3 tm’.RNopn’.UNopn’.CiS 4 tm’)=|> State’:= 1 /\RNspl’:=xor(RNspn’,xor(CSS 2 tm’,SNcstm’)) /\RNopl’:=xor(RNopn’,xor(CSS 3 tm’,SNcstm’)) /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,SNcstm’)) /\UNopl’:=xor(UNopn’,xor(CSS 3 tm’,SNcstm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNspm,xor(UNopm,CSS 3 tm’))) /\SNcs’:=xor(UNspm,xor(UNopm,xor(SNcstm’,xor(CiS 4’,CSS 2 tm’)))) /\TSc’:=xor(TSctm’,xor(SNcs’,xor(RNspm,UNspm))) /\TScs’:=xor(TScstm’,xor(SNcs’,xor(RNopm,UNopm))) /\Nc’:=xor(Ncs’,xor(TSc’,xor(TScs’,SNcs’))) /\ASS 1’:= {H(SNcs’)}_inv(KCSpu) /\CSS 2’:=xor(CSS 2 tm’,ASS 1’) /\CSS 3’:=xor(CSS 3 tm’,ASS 1’) /\ASS 2’:= {H(RNspm.UNspm.Nc’.TSc’)}_inv(KCSpu) /\ASS 3’:= {H(RNopm.UNopm.Nc’.TSc’)}_inv(KCSpu) /\ASS 4’:={H(RNoph.UNoph.TSc’)}_inv(KCSpu) /\SP’:=URsp.UNsp/\OP’:=URop.UNop /\secret({S_ID,O_ID,S_R,O_R},sec 1,{AS,Ci}) /\secret({ASS 2’,ASS 3’},sec 3,{AS,CS,Ci}) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{AS,CS}) /\secret({OP’,CiS 4’},sec 5,{AS,DS,Ci}) /\secret({SP’,Ssp,MS,SSs},sec 6,{AS,Ci}) /\secret({SNcs’,ASS 1’,TScs’,Nc},sec 7,{AS,CS}) /\secret(Sop,sec 8,AS) %AS creates Shamir’s request /\TSas’:=new() /\ASS 2 tm’:=xor(ASS 2,xor(ASS 1,xor(SSs,xor(CiS 4’,Ssp)))) /\TSastm’:=xor(TSas’,xor(SNcs’,UNopm)) /\UNspn’:=xor(UNspl’,xor(ASS 2 tm’,TSastm’)) %AS sends Shamir’s request to CS /\SND(CS.ASS 2 tm’.UNspn’.TSastm’) %AS receives Shamir’s response from CS 2.State=1 /\ RCV(AS.CiS 6 tm’.UNspn’.TScstm’)=|> State’:= 2/\UNspl’:=xor(UNspn’,xor(CiS 6 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNcs,UNopm)) /\MS’:=xor(CiS 6 tm’,xor(Ssp,ASS 1)) /\request(AS,CS,auth 3,{UNspm,UNopm,Nc,TSc,TSas}) %AS creates data retrieval request /\SNas’:=new()/\TSas’:=new() /\ASS 5’:={H(SNas’)}_inv(KASpu) /\ASS 6’:={H(RNopm.UNopm.SNas’.TSas’.CiS 4)}_inv(KASpu) /\RNopn’:=xor(RNopl,xor(TSas’,SNas’)) /\ASS 6 tm’:=xor(ASS 6’,xor(TSas’,ASS 5’)) /\TSctm’:=xor(TSc,xor(SNas’,UNoph)) /\TSastm’:=xor(TSas’,xor(SNas’,UNopm)) /\SNastm’:=xor(UNopm,xor(SNas’,xor(CiS 4,ASS 6 tm’))) /\CiS 4 tm’:=xor(CiS 4,xor(UNoph,xor(SNastm’,UNopm))) /\UNopn’:=xor(UNopl,xor(ASS 6 tm’,TSastm’)) /\secret({SNas’,ASS 5’,TSas’},sec 9,{AS,DS}) /\secret({RNoph,UNoph,ASS 6’},sec 10,{AS,DS}) %AS sends data retrieval request to DS /\SND(DS.ASS 6 tm’.RNopn’.UNopn’.SNastm’.TSctm’.TSastm’.CiS 4 tm’) /\ witness(AS,DS,auth 5,{CiS 4,ASS 6}) %AS receives data retrieval response from DS 3.State=2/\ RCV(AS.DS.DSS 2 tm’.DSS 4 tm’.UNopn’.TSdstm’ .CiS 4 tm’.Data) =|> State’:=3 /\UNopl’:=xor(UNopn’,xor(DSS 2 tm’,TSdstm’)) /\TSds’:=xor(TSdstm’,xor(SNas,UNoph)) /\CiS 4’:=xor(CiS 4 tm’,xor(ASS 5,TSds’)) /\DSS 4’:=xor(DSS 4 tm’,xor(ASS 5,CiS 4’)) /\ASS 6’:=xor(DSS 2 tm’,xor(DSS 4’,xor(TSds’,ASS 5))) /\ASS 7’:={H(Data)}_inv(KDSpu) /\request(AS,DS,auth 6,{SNas,ASS 5,RNoph,UNoph}) %AS creates decision & data response /\TSas’:=new() /\ASS 2 tm’:=xor(ASS 2,xor(ASS 1,xor(ASS 7,CiS 4))) /\ASS 3 tm’:=xor(ASS 3,xor(ASS 1,xor(ASS 7,CiS 4))) /\TSastm’:=xor(TSas’,xor(SNcs,UNopm)) /\UNspn’:=xor(UNspl,xor(ASS 2 tm’,TSastm’)) %AS sends data retrieval response (Data and Decision) to CS /\SND(CS.ASS 2 tm’.ASS 3 tm’.UNspn’.TSastm’.Decision.Data) /\witness(AS,CS,auth 4,{SNcs,ASS 1,CiS 4,TScs}) end role Figure A 3. AS role of PAX in HLPSL role dataServer(DS,AS:agent,KDSpu,KASpu:public_key, H:hash_func,SND,RCV:channel(dy)) played_by DS def= local State:nat, TSc,TSctm,TSas,TSastm,TSds,TSdstm,SNas,SNastm:text, OP,UNopl,UNopm,UNoph:text, RNopl,RNopm,RNoph,RNopn,UNopn:text, DSS 1,DSS 2,DSS 3,DSS 4:text, DSS 2 tm,DSS 4 tm,CiS 4,CiS 4 tm,ASS 6 tm:text, Ci:agent,Data:text const Section~5,sec 9,sec 10,auth 5,auth 6:protocol_id init State := 0 transition 1.State = 0 /\ RCV(DS.ASS 6 tm’.RNopn’.UNopn’.SNastm’ .TSctm’.TSastm’.CiS 4 tm’)=|>State’:=1 /\UNopl’:=xor(UNopn’,xor(ASS 6 tm’,TSastm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNoph,xor(SNastm’,UNopm))) /\SNas’:= xor(UNopm,xor(SNastm’,xor(CiS 4’,ASS 6 tm’))) /\TSc’:=xor(TSctm’,xor(SNas’,UNoph)) /\TSas’:=xor(TSastm’,xor(SNas’,UNopm)) /\RNopl’:=xor(RNopn’,xor(TSas’,SNas’)) /\DSS 1’:={H(SNas’)}_inv(KASpu) /\DSS 2’:={H(RNopm.UNopm.SNas’.TSas’.CiS 4’)}_inv(KASpu) /\DSS 3’:={H(RNoph.UNoph.TSc’)}_inv(KASpu) /\secret({OP,CiS 4’},sec 5,{DS,AS,Ci}) /\secret({SNas’,DSS 1’,TSas’},sec 9,{DS,AS}) /\secret({RNoph,UNoph,DSS 2’},sec 10,{DS,AS}) /\request(DS,AS,auth 5,{CiS 4,DSS 2}) %DS Creates data retrieval response /\TSds’:=new() /\DSS 4’:={H(Data)}_inv(KDSpu) /\DSS 4 tm’:=xor(DSS 4’,xor(DSS 1’,CiS 4’)) /\DSS 2 tm’:=xor(DSS 2’,xor(DSS 4’,xor(TSds’,DSS 1’))) /\CiS 4 tm’:=xor(CiS 4’,xor(DSS 1’,TSds’)) /\TSdstm’:=xor(TSds’,xor(SNas’,UNoph)) /\UNopn’:=xor(UNopl’,xor(DSS 2 tm’,TSdstm’)) %DS sends data retrieval response to AS /\SND(AS.DSS 2 tm’.DSS 4 tm’.UNopn’.TSdstm’.CiS 4 tm’.Data) /\ witness(DS,AS,auth 6,{SNas,DSS 1,RNoph,UNoph}) end role Figure A 4. DS role of PAX in HLPSL Figure A 3. AS role of PAX in HLPSL.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 33 of 36 Int. J. Environ. Res. Public Health 2019 , 16 , 5 31 of 34 role attributesServer(AS,CS,DS:agent,KASpu,KCSpu,KDSpu:public_key, Ssp,Sop:text,H:hash_func,SND,RCV:channel(dy)) played_by AS def= local State:nat, TSc,TScs,TSas,TSds,TSctm,TScstm,TSastm,TSdstm,Nc, Ncs,SNcs,SNas,SNcstm,SNastm:text, ASS 1,ASS 2,ASS 3,ASS 4,ASS 5, ASS 6,ASS 7,ASS 2 tm,ASS 3 tm,ASS 6 tm:text, CiS 4,CiS 4 tm,CiS 6 tm,CSS 2, CSS 3,CSS 2 tm,CSS 3 tm,DSS 2 tm,DSS 4 tm,DSS 4:text, SP,OP,URsp,UNsp,URop,UNop,RNsp,RNop:text, UNspl,UNspm,UNsph,UNopl,UNopm,UNoph:text, RNspl,RNspm,RNsph,RNopl,RNopm,RNoph:text, RNspn,RNopn,UNspn,UNopn:text, S_ID,O_ID,S_R,O_R:message,Ci:agent,SSs,MS,Data,Decision:text const Section~1,sec 3,sec 4,sec 5,sec 6,sec 7,sec 8,sec 9,sec 10,auth 3,auth 4 ,auth 5,auth 6:protocol_id init State := 0 transition %AS receives from CS 1.State = 0 /\ RCV(AS.CSS 2 tm’.RNspn’.UNspn’.Ncs’.TSctm’.TScstm’ .SNcstm’.CSS 3 tm’.RNopn’.UNopn’.CiS 4 tm’)=|> State’:= 1 /\RNspl’:=xor(RNspn’,xor(CSS 2 tm’,SNcstm’)) /\RNopl’:=xor(RNopn’,xor(CSS 3 tm’,SNcstm’)) /\UNspl’:=xor(UNspn’,xor(CSS 2 tm’,SNcstm’)) /\UNopl’:=xor(UNopn’,xor(CSS 3 tm’,SNcstm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNspm,xor(UNopm,CSS 3 tm’))) /\SNcs’:=xor(UNspm,xor(UNopm,xor(SNcstm’,xor(CiS 4’,CSS 2 tm’)))) /\TSc’:=xor(TSctm’,xor(SNcs’,xor(RNspm,UNspm))) /\TScs’:=xor(TScstm’,xor(SNcs’,xor(RNopm,UNopm))) /\Nc’:=xor(Ncs’,xor(TSc’,xor(TScs’,SNcs’))) /\ASS 1’:= {H(SNcs’)}_inv(KCSpu) /\CSS 2’:=xor(CSS 2 tm’,ASS 1’) /\CSS 3’:=xor(CSS 3 tm’,ASS 1’) /\ASS 2’:= {H(RNspm.UNspm.Nc’.TSc’)}_inv(KCSpu) /\ASS 3’:= {H(RNopm.UNopm.Nc’.TSc’)}_inv(KCSpu) /\ASS 4’:={H(RNoph.UNoph.TSc’)}_inv(KCSpu) /\SP’:=URsp.UNsp/\OP’:=URop.UNop /\secret({S_ID,O_ID,S_R,O_R},sec 1,{AS,Ci}) /\secret({ASS 2’,ASS 3’},sec 3,{AS,CS,Ci}) /\secret({RNspm,UNspm,RNopm,UNopm},sec 4,{AS,CS}) /\secret({OP’,CiS 4’},sec 5,{AS,DS,Ci}) /\secret({SP’,Ssp,MS,SSs},sec 6,{AS,Ci}) /\secret({SNcs’,ASS 1’,TScs’,Nc},sec 7,{AS,CS}) /\secret(Sop,sec 8,AS) %AS creates Shamir’s request /\TSas’:=new() /\ASS 2 tm’:=xor(ASS 2,xor(ASS 1,xor(SSs,xor(CiS 4’,Ssp)))) /\TSastm’:=xor(TSas’,xor(SNcs’,UNopm)) /\UNspn’:=xor(UNspl’,xor(ASS 2 tm’,TSastm’)) %AS sends Shamir’s request to CS /\SND(CS.ASS 2 tm’.UNspn’.TSastm’) %AS receives Shamir’s response from CS 2.State=1 /\ RCV(AS.CiS 6 tm’.UNspn’.TScstm’)=|> State’:= 2/\UNspl’:=xor(UNspn’,xor(CiS 6 tm’,TScstm’)) /\TScs’:=xor(TScstm’,xor(SNcs,UNopm)) /\MS’:=xor(CiS 6 tm’,xor(Ssp,ASS 1)) /\request(AS,CS,auth 3,{UNspm,UNopm,Nc,TSc,TSas}) %AS creates data retrieval request /\SNas’:=new()/\TSas’:=new() /\ASS 5’:={H(SNas’)}_inv(KASpu) /\ASS 6’:={H(RNopm.UNopm.SNas’.TSas’.CiS 4)}_inv(KASpu) /\RNopn’:=xor(RNopl,xor(TSas’,SNas’)) /\ASS 6 tm’:=xor(ASS 6’,xor(TSas’,ASS 5’)) /\TSctm’:=xor(TSc,xor(SNas’,UNoph)) /\TSastm’:=xor(TSas’,xor(SNas’,UNopm)) /\SNastm’:=xor(UNopm,xor(SNas’,xor(CiS 4,ASS 6 tm’))) /\CiS 4 tm’:=xor(CiS 4,xor(UNoph,xor(SNastm’,UNopm))) /\UNopn’:=xor(UNopl,xor(ASS 6 tm’,TSastm’)) /\secret({SNas’,ASS 5’,TSas’},sec 9,{AS,DS}) /\secret({RNoph,UNoph,ASS 6’},sec 10,{AS,DS}) %AS sends data retrieval request to DS /\SND(DS.ASS 6 tm’.RNopn’.UNopn’.SNastm’.TSctm’.TSastm’.CiS 4 tm’) /\ witness(AS,DS,auth 5,{CiS 4,ASS 6}) %AS receives data retrieval response from DS 3.State=2/\ RCV(AS.DS.DSS 2 tm’.DSS 4 tm’.UNopn’.TSdstm’ .CiS 4 tm’.Data) =|> State’:=3 /\UNopl’:=xor(UNopn’,xor(DSS 2 tm’,TSdstm’)) /\TSds’:=xor(TSdstm’,xor(SNas,UNoph)) /\CiS 4’:=xor(CiS 4 tm’,xor(ASS 5,TSds’)) /\DSS 4’:=xor(DSS 4 tm’,xor(ASS 5,CiS 4’)) /\ASS 6’:=xor(DSS 2 tm’,xor(DSS 4’,xor(TSds’,ASS 5))) /\ASS 7’:={H(Data)}_inv(KDSpu) /\request(AS,DS,auth 6,{SNas,ASS 5,RNoph,UNoph}) %AS creates decision & data response /\TSas’:=new() /\ASS 2 tm’:=xor(ASS 2,xor(ASS 1,xor(ASS 7,CiS 4))) /\ASS 3 tm’:=xor(ASS 3,xor(ASS 1,xor(ASS 7,CiS 4))) /\TSastm’:=xor(TSas’,xor(SNcs,UNopm)) /\UNspn’:=xor(UNspl,xor(ASS 2 tm’,TSastm’)) %AS sends data retrieval response (Data and Decision) to CS /\SND(CS.ASS 2 tm’.ASS 3 tm’.UNspn’.TSastm’.Decision.Data) /\witness(AS,CS,auth 4,{SNcs,ASS 1,CiS 4,TScs}) end role Figure A 3. AS role of PAX in HLPSL role dataServer(DS,AS:agent,KDSpu,KASpu:public_key, H:hash_func,SND,RCV:channel(dy)) played_by DS def= local State:nat, TSc,TSctm,TSas,TSastm,TSds,TSdstm,SNas,SNastm:text, OP,UNopl,UNopm,UNoph:text, RNopl,RNopm,RNoph,RNopn,UNopn:text, DSS 1,DSS 2,DSS 3,DSS 4:text, DSS 2 tm,DSS 4 tm,CiS 4,CiS 4 tm,ASS 6 tm:text, Ci:agent,Data:text const Section~5,sec 9,sec 10,auth 5,auth 6:protocol_id init State := 0 transition 1.State = 0 /\ RCV(DS.ASS 6 tm’.RNopn’.UNopn’.SNastm’ .TSctm’.TSastm’.CiS 4 tm’)=|>State’:=1 /\UNopl’:=xor(UNopn’,xor(ASS 6 tm’,TSastm’)) /\CiS 4’:=xor(CiS 4 tm’,xor(UNoph,xor(SNastm’,UNopm))) /\SNas’:= xor(UNopm,xor(SNastm’,xor(CiS 4’,ASS 6 tm’))) /\TSc’:=xor(TSctm’,xor(SNas’,UNoph)) /\TSas’:=xor(TSastm’,xor(SNas’,UNopm)) /\RNopl’:=xor(RNopn’,xor(TSas’,SNas’)) /\DSS 1’:={H(SNas’)}_inv(KASpu) /\DSS 2’:={H(RNopm.UNopm.SNas’.TSas’.CiS 4’)}_inv(KASpu) /\DSS 3’:={H(RNoph.UNoph.TSc’)}_inv(KASpu) /\secret({OP,CiS 4’},sec 5,{DS,AS,Ci}) /\secret({SNas’,DSS 1’,TSas’},sec 9,{DS,AS}) /\secret({RNoph,UNoph,DSS 2’},sec 10,{DS,AS}) /\request(DS,AS,auth 5,{CiS 4,DSS 2}) %DS Creates data retrieval response /\TSds’:=new() /\DSS 4’:={H(Data)}_inv(KDSpu) /\DSS 4 tm’:=xor(DSS 4’,xor(DSS 1’,CiS 4’)) /\DSS 2 tm’:=xor(DSS 2’,xor(DSS 4’,xor(TSds’,DSS 1’))) /\CiS 4 tm’:=xor(CiS 4’,xor(DSS 1’,TSds’)) /\TSdstm’:=xor(TSds’,xor(SNas’,UNoph)) /\UNopn’:=xor(UNopl’,xor(DSS 2 tm’,TSdstm’)) %DS sends data retrieval response to AS /\SND(AS.DSS 2 tm’.DSS 4 tm’.UNopn’.TSdstm’.CiS 4 tm’.Data) /\ witness(DS,AS,auth 6,{SNas,DSS 1,RNoph,UNoph}) end role Figure A 4. DS role of PAX in HLPSL Figure A 4. DS role of PAX in HLPSL Int. J. Environ. Res. Public Health 2019 , 16 , 5 32 of 34 role session(Ci,CS,AS,DS:agent, KCpu,KCSpu,KASpu,KDSpu:public_key,H:hash_func, S_ID,O_ID,S_R,O_R:message,Ssp,Sop:text) def= local SND 1,RCV 1,SND 2,RCV 2,SND 3,RCV 3,SND 4,RCV 4:channel(dy) composition clienti(Ci,CS,KCpu,KCSpu,H,S_ID,O_ID,S_R,O_R,SND 1,RCV 1) /\centralServer(CS,Ci,AS,KCSpu,KCpu,KASpu,H,SND 2,RCV 2) /\attributesServer(AS,CS,DS,KASpu,KCSpu,KDSpu,Ssp,Sop, H,SND 3,RCV 3) /\dataServer(DS,AS,KDSpu,KASpu,H,SND 4,RCV 4) end~role role environment() def= const ci,cs,as,ds,i:agent, kCpu,kCSpu,kASpu,kDSpu,ki:public_key, s_id,o_id,s_r,o_r:message,ssp,sop:text, h:hash_func,sec 1,sec 2,sec 3,sec 4,sec 5,sec 6,sec 7,sec 8,sec 9,sec 10, auth 1,auth 2,auth 3,auth 4,auth 5,auth 6,auth 7,auth 8:protocol_id intruder_knowledge={i,ci,cs,as,kCpu,kCSpu,kASpu,kDSpu,ki,inv(ki)} composition session(ci,cs,as,ds,kCpu,kCSpu,kASpu,kDSpu,h,s_id,o_id,s_r, o_r,ssp,sop) %Check replay attack /\session(ci,cs,as,ds,kCpu,kCSpu,kASpu,kDSpu,h,s_id,o_id,s_r, %o_r,ssp,sop) %Check MITM attack %/\session(cs,ci,as,ds,kCSpu,kCpu,kASpu,kDSpu,h,s_id,o_id,s_r, %o_r,ssp,sop) %Check impersonate Ci %/\session(i,cs,as,ds,ki,kCSpu,kASpu,kDSpu,h,s_id,o_id,s_r, %o_r,ssp,sop) %Check impersonate CS %/\session(ci,i,as,ds,kCpu,ki,kASpu,kDSpu,h,s_id,o_id,s_r, %o_r,ssp,sop) %Check impersonate AS %/\session(ci,cs,i,ds,kCpu,kCSpu,ki,kDSpu,h,s_id,o_id,s_r, %o_r,ssp,sop) %Check impersonate DS %/\session(ci,cs,as,i,kCpu,kCSpu,kASpu,ki,h,s_id,o_id,s_r, %o_r,ssp,sop) end~role goal secrecy_of Section~1,sec 2,sec 3,sec 4,sec 5,sec 6,sec 7,sec 8,sec 9,sec 10 authentication_on auth 1,auth 2,auth 3,auth 4,auth 5,auth 6,auth 7,auth 8 end goal environment() Figure A 5. Session, environment, and goal role of PAX in HLPSL References 1 Anjum, A., Choo, K.-K. R., Khan, A., Haroon, A., Khan, S., Khan, S. U., Ahmad, N., Raza, B. et al. (2018). An efficient privacy mechanism for electronic health records computers & security , 72 , 196–211 2 Gajanayake, R., Iannella, R., & Sahama, T. (2014). Privacy oriented access control for electronic health records Electronic Journal of Health Informatics , 8 , 15 3 Al-Zubaidie, M., Zhang, Z., & Zhang, J. (2019). Ramhu: A new robust lightweight scheme for mutual users authentication in healthcare applications Security and Communication Networks , 2019 , 1–26 4 Calvillo-Arbizu, J., Roman-Martinez, I., & Roa-Romero, L. M. (2014) Standardized access control mechanisms for protecting ISO 13606-based electronic health record systems. In Biomedical and Health Informatics (BHI), 2014 IEEE-EMBS International Conference on (pp. 539–542). IEEE 5 Alhaqbani, B., & Fidge, C. (2008). Privacy-preserving electronic health record linkage using pseudonym identifiers. In E-health Networking, Applications and Services, 2008. HealthCom 2008. 10 th International Conference on (pp. 108–117). IEEE 6 Riedl, B., Grascher, V., Fenz, S., & Neubauer, T. (2008). Pseudonymization for improving the privacy in e-health applications. In Hawaii International Conference on System Sciences, Proceedings of the 41 st Annual (pp 255–255). IEEE 7 Neubauer, T., & Heurix, J. (2011). A methodology for the pseudonymization of medical data International Journal of Medical Informatics , 80 , 190–204 8 Quantin, C., Jaquet-Chiffelle, D.-O., Coatrieux, G., Benzenine, E., & Allaert, F.-A. (2011). Medical record search engines, using pseudonymised patient identity: An alternative to centralised medical records International Journal of Medical Informatics , 80 , e 6–e 11 Figure A 5. Session, environment, and goal role of PAX in HLPSL.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 34 of 36 References 1 Anjum, A.; Choo, K.-K.R.; Khan, A.; Haroon, A.; Khan, S.; Khan, S.U.; Ahmad, N.; Raza, B. An efficient privacy mechanism for electronic health records Comput. Secur 2018 , 72 , 196–211. [ CrossRef ] 2 Gajanayake, R.; Iannella, R.; Sahama, T. Privacy oriented access control for electronic health records Electron. J. Health Inform 2014 , 8 , 15 3 Al-Zubaidie, M.; Zhang, Z.; Zhang, J. Ramhu: A new robust lightweight scheme for mutual users authentication in healthcare applications Secur. Commun. Netw 2019 , 2019 , 1–26. [ CrossRef ] 4 Calvillo-Arbizu, J.; Roman-Martinez, I.; Roa-Romero, L.M. Standardized access control mechanisms for protecting ISO 13606-based electronic health record systems. In Proceedings of the 2014 IEEE-EMBS International Conference on Biomedical and Health Informatics (BHI), Valencia, Spain, 1–4 June 2014; pp. 539–542 5 Alhaqbani, B.; Fidge, C. Privacy-preserving electronic health record linkage using pseudonym identifiers. In Proceedings of the 10 th International Conference on E-Health Networking, Applications and Services, Singapore, 7–9 July 2008; pp. 108–117 6 Riedl, B.; Grascher, V.; Fenz, S.; Neubauer, T. Pseudonymization for improving the privacy in e-health applications. In Proceedings of the 41 st Annual Hawaii International Conference on System Sciences, Waikoloa, HI, USA, 7–10 January 2008; p. 255 7 Neubauer, T.; Heurix, J. A methodology for the pseudonymization of medical data Int. J. Med. Inform 2011 , 80 , 190–204. [ CrossRef ] [ PubMed ] 8 Quantin, C.; Jaquet-Chiffelle, D.-O.; Coatrieux, G.; Benzenine, E.; Allaert, F.-A. Medical record search engines, using pseudonymised patient identity: An alternative to centralised medical records Int. J. Med. Inform 2011 , 80 , e 6–e 11. [ CrossRef ] 9 Sun, J.; Zhu, X.; Zhang, C.; Fang, Y. HCPP: Cryptography based secure EHR system for patient privacy and emergency healthcare. In Proceedings of the 2011 31 st International Conference on Distributed Computing Systems (ICDCS), Minneapolis, MN, USA, 20–24 June 2011; pp. 373–382 10. Riedl, B.; Grascher, V.; Neubauer, T. Applying a threshold scheme to the pseudonymization of health data In Proceedings of the 13 th Pacific Rim International Symposium on Dependable Computing, Melbourne, Australia, 17–19 December 2007; pp. 397–400 11. Rezaeibagha, F.; Win, K.T.; Susilo, W. A systematic literature review on security and privacy of electronic health record systems: Technical perspectives Health Inf. Manag. J 2015 , 44 , 23–38. [ CrossRef ] 12. Wimalasiri, J.S.; Ray, P.; Wilson, C. Security of electronic health records based on web services. In Proceedings of the 7 th International Workshop on Enterprise Networking and Computing in Healthcare Industry, Busan, Korea, 24–25 June 2005; pp. 91–95 13. Koczkodaj, W.W.; Mazurek, M.; Strzałka, D.; Wolny-Dominiak, A.; Woodbury-Smith, M. Electronic health record breaches as social indicators Soc. Indic. Res 2019 , 141 , 864–871. [ CrossRef ] 14. U.S. Department of Health and Human Services Breaches Affecting 500 or More Individuals. 2018. Available online: https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf# (accessed on 2 December 2018) 15. Fernández-Alemán, J.L.; Señor, I.C.; Lozoya, P.Á.O.; Toval, A. Security and privacy in electronic health records: A systematic literature review J. Biomed. Inform 2013 , 46 , 541–562. [ CrossRef ] [ PubMed ] 16. Chadwick, D.; Zhao, G.; Otenko, S.; Laborde, R.; Su, L.; Nguyen, T.A. Building a modular authorisation infrastructure. In The UK E-Science All Hands Meeting ; University of Kent: Canterbury, UK, 2006 17. Jo, S.-M.; Chung, K.-Y. Design of access control system for telemedicine secure XML documents Multimed Tools Appl 2015 , 74 , 2257–2271. [ CrossRef ] 18. Seol, K.; Kim, Y.-G.; Lee, E.; Seo, Y.-D.; Baik, D.-K. Privacy-preserving attribute-based access control model for xml-based electronic health record system IEEE Access 2018 , 6 , 9114–9128. [ CrossRef ] 19. Dolev, D.; Yao, A. On the security of public key protocols IEEE Trans. Inf. Theory 1983 , 29 , 198–208 [ CrossRef ] 20. Sánchez, Y.K.R.; Demurjian, S.A.; Baihan, M.S. Achieving rbac on restful apis for mobile apps using fhir. In Proceedings of the 2017 5 th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering (MobileCloud), San Francisco, CA, USA, 6–8 April 2017; pp. 139–144.

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 35 of 36 21. Alturki, M. Achieving a secured collaborative environment in e-sihi system users perspective on a framework to improve patients information. In Proceedings of the International Conference on Informatics, Health & Technology (ICIHT), Riyadh, Saudi Arabia, 21–23 February 2017; pp. 1–4 22. Jin, X.; Krishnan, R.; Sandhu, R.S. A unified attribute-based access control model covering DAC, MAC and RBAC DBSec 2012 , 12 , 41–55 23. Zhang, Y.; Zhang, B. A new testing method for xacml 3.0 policy based on abac and data flow. In Proceedings of the 2017 13 th IEEE International Conference on Control & Automation (ICCA), Ohrid, Macedonia, 3–6 July 2017; pp. 160–164 24. Brossard, D.; Gebel, G.; Berg, M. A systematic approach to implementing abac. In Proceedings of the 2 nd ACM Workshop on Attribute-Based Access Control, Scottsdale, AZ, USA, 24 March 2017; pp. 53–59 25. Lu, Y.; Sinnott, R.O. Semantic privacy-preserving framework for electronic health record linkage Telemat. Inform 2018 , 35 , 737–752. [ CrossRef ] 26. Grace, P.; Surridge, M. Towards a model of user-centered privacy preservation In Proceedings of the 12 th International Conference on Availability, Reliability and Security, Reggio Calabria, Italy, 29 August–1 September 2017; p. 91 27. Beltran, V.; Martinez, J.; Skarmeta, A. User-centric access control for efficient security in smart cities In Proceedings of the Global Internet of Things Summit (GIoTS), Geneva, Switzerland, 6–9 June 2017; pp. 1–6 28. Turkmen, F.; den Hartog, J.; Ranise, S.; Zannone, N. Formal analysis of xacml policies using smt Comput. Secur 2017 , 66 , 185–203. [ CrossRef ] 29. Deng, F.; Wang, S.; Zhang, L.; Wei, X.; Yu, J. Establishment of attribute bitmaps for efficient xacml policy evaluation Knowl. Based Syst 2018 , 143 , 93–101. [ CrossRef ] 30. Han, J.-H.; Kim, Y.-J.; Jun, S.-I.; Chung, K.-I.; Seo, C.-H. Implementation of ECC/ECDSA cryptography algorithms based on Java card. In Proceedings of the 22 nd International Conference on Distributed Computing Systems Workshops, Vienna, Austria, 2–5 July 2002; pp. 272–276 31. Rafik, M.B.O.; Mohammed, F. The impact of ECC’s scalar multiplication on wireless sensor networks In Proceedings of the 2013 11 th International Symposium on Programming and Systems (ISPS), Algiers, Algeria, 22–24 April 2013; pp. 17–23 32. Sghaier, A.; Zeghid, M.; Machhout, M. Fast hardware implementation of ecdsa signature scheme In Proceedings of the International Symposium on Signal, Image, Video and Communications (ISIVC), Tunis, Tunisia, 21–23 November 2016; pp. 343–348 33. Dikshit, P.; Singh, K. Efficient weighted threshold ecdsa for securing bitcoin wallet. In Proceedings of the Asia Security and Privacy (ISEASP), Surat, India, 29 January–1 February 2017; pp. 1–9 34. Sojka-Piotrowska, A.; Langendoerfer, P. Shortening the security parameters in lightweight wsn applications for iot-lessons learned. In Proceedings of the 2017 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), Kona, HI, USA, 13–17 March 2017; pp. 636–641 35. Dou, Y.; Weng, J.; Ma, C.; Wei, F. Secure and efficient ecc speeding up algorithms for wireless sensor networks Soft Comput 2017 , 21 , 5665–5673. [ CrossRef ] 36. Liu, Y.; Yang, C.; Wang, Y.; Zhu, L.; Ji, W. Cheating identifiable secret sharing scheme using symmetric bivariate polynomial Inf. Sci 2018 , 453 , 21–29. [ CrossRef ] 37. Ahmadian, Z.; Jamshidpour, S. Linear subspace cryptanalysis of harn’s secret sharing-based group authentication scheme IEEE Trans. Inf. Forensics Secur 2018 , 13 , 502–510. [ CrossRef ] 38. Stinson, D.R.; Wei, R. Combinatorial repairability for threshold schemes Des. Codes Cryptogr 2018 , 86 , 195–210 [ CrossRef ] 39. Zhou, J.; Cao, Z.; Dong, X.; Vasilakos, A.V. Security and privacy for cloud-based iot: Challenges IEEE Commun. Mag 2017 , 55 , 26–33. [ CrossRef ] 40. Vatsalan, D.; Sehili, Z.; Christen, P.; Rahm, E. Privacy-preserving record linkage for big data: Current approaches and research challenges. In Handbook of Big Data Technologies ; Springer: Berlin/Heidelberg, Germany, 2017; pp. 851–895 41. Yu, S. Big privacy: Challenges and opportunities of privacy study in the age of big data IEEE Access 2016 , 4 , 2751–2763. [ CrossRef ] 42. Bogos, S.; Gaspoz, J.; Vaudenay, S. Cryptanalysis of a homomorphic encryption scheme Cryptogr. Commun 2018 , 10 , 27–39. [ CrossRef ]

Int. J. Environ. Res. Public Health 2019 , 16 , 1490 36 of 36 43. Burrows, M.; Abadi, M.; Needham, R.M. A logic of authentication Proc. R. Soc. Lond. A 1989 , 426 , 233–271 [ CrossRef ] 44. Mahmood, K.; Chaudhry, S.A.; Naqvi, H.; Kumari, S.; Li, X.; Sangaiah, A.K. An elliptic curve cryptography based lightweight authentication scheme for smart grid communication Future Gener. Comput. Syst 2018 , 81 , 557–565. [ CrossRef ] 45. Amin, R.; Islam, S.H.; Biswas, G.; Khan, M.K.; Kumar, N. A robust and anonymous patient monitoring system using wireless medical sensor networks Future Gener. Comput. Syst 2018 , 80 , 483–495. [ CrossRef ] 46. Team, T.A. Avispa v 1.1 User Manual. 2006. Available online: http://www.avispa-project.org (accessed on 10 September 2018) 47. Iqbal, U.; Shafi, S. A provable and secure key exchange protocol based on the elliptical curve diffe–hellman for wsn. In Advances in Big Data and Cloud Computing ; Springer: Berlin/Heidelberg, Germany, 2019; pp. 363–372 48. Gupta, S.; Parne, B.L.; Chaudhari, N.S. An efficient handover aka protocol for wireless network using chameleon hash function. In Proceedings of the 2018 4 th International Conference on Recent Advances in Information Technology (RAIT), Dhanbad, India, 15–17 March 2018; pp. 1–7 49. Babu, K.R.; Padmanabhan, V. Automated validation of dnssec. In Progress in Computing, Analytics and Networking ; Springer: Berlin/Heidelberg, Germany, 2018; pp. 51–59 50. Xu, G.; Liu, J.; Lu, Y.; Zeng, X.; Zhang, Y.; Li, X. A novel efficient maka protocol with desynchronization for anonymous roaming service in global mobility networks J. Netw. Comput. Appl 2018 , 107 , 83–92. [ CrossRef ] 51. Dey, S.; Hossain, A. Session-key establishment and authentication in a smart home network using public key cryptography IEEE Sens. Lett 2019 . [ CrossRef ] 52. Das, A.K.; Sutrala, A.K.; Odelu, V.; Goswami, A. A secure smartcard-based anonymous user authentication scheme for healthcare applications using wireless medical sensor networks Wirel. Pers. Commun 2017 , 94 , 1899–1933. [ CrossRef ] © 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

Other Environmental Sciences Concepts:

[back to top]

Discover the significance of concepts within the article: ‘PAX’. Further sources in the context of Environmental Sciences might help you critically compare this page with similair documents:

Data, Ci, C, D, M, State, Service, Security, Request, Decision, Personal information, Pseudonym, Medical data, Healthcare system, Response, Real attributes, Sensitive patient information, AUDIT, Health information, Health problem, Patients' relatives, Anonymity, Security measures, Wireless Sensor Network, Theoretical analysis, Healthcare provider, Data integrity, Accuracy and reliability, Confidentiality, Data privacy, Health Institution, Access control, Electronic health record, Evaluation System, Collaborative environment, Health data, Sensitive data, Privacy, Data storage, Patient data, PRP, Ss, Essential role, Medical record, Theoretical investigation, Security and privacy, SP, OP, Electronic health, Medical records of patients, Policy implementation, Emergency doctor, Patient's privacy, Patient's consent, Patient's Data, Medical reports, Electronic health record system, Dataset, EHR, Healthcare user, Healthcare records, Unauthorised access, Supporting role, Patient record, EHR system, Asymmetric cryptography, Public key, Security analysis, Protected health information, Security threat, Encrypted data, Digital signature algorithm, Session key, Data access, Policy evaluation, Security policies, Pseudonymization, Denial of service, Security features, Security requirements, Authentication scheme, Security parameters, Threat model, Random nonce, BAN logic, Impersonation attacks, MitM attacks, Security goals, Simulation result, Access control mechanisms, Privacy preservation, Wireless network, Network model, Mobility Network, Traffic Analysis, Access control model, Role-based access control, Attribute-based access control, RBAC, ABAC, Replay attack, Healthcare application, User activities, Secure Communication, Public Key Cryptography, Cloud environment, Privacy-preserving framework, Emergency scenario, Security mechanism, Authorization system, Central Server, ECDSA signature, Internet security, User requests, Smart Grid Communication, Authentication Mechanism, Communications network, Policy Enforcement Point, Direct subjects, Indirect subjects, XACML, AVISPA tool, Traffic analysis attacks, Cryptographic mechanisms, Hash algorithm, Authorization process, CSS 3, Data response, Cryptographic operations, Message authentication, Privacy mechanism.