DSMAC: Privacy-Aware Decentralized Self-Management of Data Access Control Based on Blockchain for Health Data

In recent years, the interest in using wireless communication technologies and mobile devices in the healthcare environment has increased. However, despite increased attention to the security of electronic health records, patient privacy is still at risk for data breaches. Thus, it is quite a challenge to involve an access control system especially if the patient’s medical data are accessible by users who have diverse privileges in different situations. Blockchain is a new technology that can be adopted for decentralized access control management issues. Nevertheless, different scalability, security, and privacy challenges affect this technology. To address these issues, we suggest a novel Decentralized Self-Management of data Access Control (DSMAC) system using a blockchain-based Self-Sovereign Identity (SSI) model for privacy-preserving medical data, empowering patients with mechanisms to preserve control over their personal information and allowing them to self-grant access rights to their medical data. DSMAC leverages smart contracts to conduct Role-based Access Control policies and adopts the implementation of decentralized identifiers and verifiable credentials to describe advanced access control techniques for emergency cases. Finally, by evaluating performance and comparing analyses with other schemes, DSMAC can satisfy the privacy requirements of medical systems in terms of privacy, scalability, and sustainability, and offers a new approach for emergency cases.

Patients are increasingly exploiting mobile devices for 27 their medical needs to promote the availability of their med-28 ical data and to help avoid repeated examinations. However, 29 the sharing and privacy of medical data represent major 30 technological, legal, and operational challenges [3]. Like-31 wise, the identification of the patient is of critical impor-32 tance for performing transactions with different healthcare 33 organizations [4]. But by using different identifiers, patients 34 find themselves having to maintain or memorize many com-35 binations of accounts, and they may get interoperability 36 issues, identity loss/theft, and privacy issues. To improve 37 the user identity model, we are considering the concept of 38 cases in which the patient is unable to grant access to doctors. 85 To address these issues, the combination of blockchain and 86 SSI technologies will lead to good effects. 87 Therefore, this paper proposes a novel Decentralized Self- 88 Management of data Access Control (DSMAC) system using 89 a blockchain-based Self-Sovereign Identity (SSI) model for 90 privacy-preserving medical data, empowering patients with 91 mechanisms to preserve control over their personal informa-92 tion and allowing them to self-grant access rights to their 93 medical data. 94 DSMAC is distinct from the works discussed in the litera-95 ture by integrating a hybrid level of the decentralized access 96 control model which considers both the ''role'' concept and 97 the ''attributes'' as important topics. By utilizing the smart 98 contract, we integrate RBAC model into blockchain which 99 is a better fit for IoMT than other access control systems. 100 Additionally, ABAC is a model that can provide expressive 101 fine-grained access control in an emergency case. 102 In the experiments, we use the hyperledger indy [17], 103 an open-source version of permissioned blockchain, to create 104 and evaluate our decentralized access control mechanism. 105 Experimental results based on low-latency, and privacy-106 preserving medical records demonstrate the effectiveness of 107 the DSMAC scheme. 108 In brief, our main contributions are as follows: 109 1. We implement a decentralized access control model based 110 on role and attribute models. 111 2. We use smart contract functionalities to issue or modify 112 the role-based access control policies. 113 3. An SSI-based decentralized access control system is inte-114 grated to preserve data privacy. 115 4. We formulate an attribute-based access control mecha-116 nism by using DID document. 117 5. Protect patients' medical data via encryption security 118 algorithms.

119
6. The simulation results show that our proposed scheme 120 gives better results in execution time as well as transaction 121 throughput and latency.

122
The remainder of this paper is organized as follows: 123 In Section 2, we review and discuss existing techniques 124 to address the problem of decentralized access control for 125 healthcare systems. In Section 3, we provide background 126 knowledge. We formally define the models and security 127 requirements in Section 4, followed by our proposed decen-128 tralized access control scheme in Section 5. We report and 129 discuss evaluation results in Section 6. Security and privacy 130 analysis are described in Section 7. Finally, we conclude the 131 paper. 133 In this section, we have introduced a brief review related 134 to decentralized access control systems in the healthcare 135 environment. Further, these works have been divided into two 136 sections. The first one represents blockchain-based access 137 control research in the healthcare environment. The second 138 one highlights a few works in decentralized access control 139 management-based SSI systems.  and an access control scheme [23] to successfully monitor 204 data usage and revoke access to offending entities when 205 permissions on data are violated. 206 Rajput et al. [24] presented a permissioned blockchain-207 based emergency access control management system 208 (EACMS) built on and powered by smart contracts. However, 209 the privacy and authentication processes are not defined. 210 Although, there is not any information about data storage if 211 the medical data will be kept off-chain.

212
B. SSI-BASED ACCESS CONTROL 213 Self-sovereign identity, SSI, is a novel digital identity model, 214 it helps to prove who we are to establish trusted relationships 215 to access information [6]. Belchior et al.
[25] proposed a Self-216 Sovereign Identity Based Access Control system (SSIBAC) 217 for managing identities across organizations. SSIBAC offers 218 decentralized authentication and centralized authorization 219 using a traditional access control architecture with blockchain 220 technology. 221 Lagutin et al. [26], presented an OAuth-based method for 222 delegating the access policy management to the authorization 223 server, allowing systems with limited IoT devices to bene-224 fit from Decentralized ID (DID) and Verifiable Credentials 225 (VCs). However, to determine whether DIDs are the right 226 approach for the IoMT devices, a complete threat analysis 227 must be performed before using DIDs for IoMT. 228 Jung [27] proposed a decentralized access control system 229 based on DID and explained how the proposed approach 230 grants access privileges without a centralized authority. How-231 ever, this may not be an ideal proposition against hacking as 232 with other centralized systems. 233 Kim et al.
[28] present a DID-based ABAC to address 234 the issue of ABAC's privacy exposure and implement it on 235 a power transaction platform. Additionally, the privacy of 236 the users can be preserved by using a verifiable credential 237 verification process.

238
The main objective of the aforementioned articles is to 239 establish access control systems for medical records and 240 provide patients control over their medical data. However, 241 the majority of the solutions cannot overcome the emergency 242 cases issue. To address these limitations, we propose in this 243 paper an efficient privacy-preserving decentralized access 244 control scheme using both blockchain and self-sovereign 245 identity (SSI) systems to provide better management of 246 access control policies and resolve issues of emergencies. Our 247 framework differs from the works reviewed in the literature 248 by proposing the hybrid level of the decentralized access con-249 trol model which considers both the ''role'' concept and the 250 ''attributes'' as important topics. As a consequence, security 251 and privacy with efficient access control policies remain a 252 pivotal issue, and this is what we attempt to address in this 253 study.

255
In this section, we discuss the necessary background of our 256 proposed system. First, we discuss the Self-sovereign identity 257 VOLUME 10, 2022  database that records the history of all the transactions. This 310 database is distributed and safe; it is accessed by various 311 users, without intermediaries, enabling everyone to check the 312 validity of the chain [38]. Peers in blockchain connect the 313 blocks chronologically into a specific data structure in a chain 314 manner [39]. The blockchain has been involved due to its 315 decentralization, immutability, as well as persistence proper-316 ties in the distributed peer-to-peer (P2P) network. It utilizes 317 asymmetric cryptography to ensure transactions are done 318 safely [38].  The blocks are used to store data permanently. A block 326 contains many transactions that should not be included in 327 another block and it uses a hash of the referenced block to 328 refer to the previous block [38]. Smart contracts are programs stored on a blockchain that run 331 when determined conditions are met. They are used to define 332 more complex transactions with a flexible and programmable 333 method [39]. Once a smart contract is published in the 334 blockchain network, its contents are almost unchangeable, 335 because each node in the network has the same copy of the 336 smart contract. The blockchain stores and uses the execution 337 record of the contract as a transaction. A smart contract can 338 be called to start a transaction that links to its address [10].   344 Goldwasser, Micali, and Rackoff [40] proposed Zero-345 knowledge proof (ZKP) in 1989. ZKP is a cryptographic 346 method where one party, termed prover, can prove to another 347 party, termed verifier, that they know a certain value without 348 revealing the actual value [41]. ZKP helps in making true 349 and authorized claims by adding multiple layers to data 350 security [41]. 352 We discuss the Decentralized Self-Management Access Con-

365
This layer is used to sense, collect, encrypt and upload med-366 ical data to F2C computing [42], [43], including wireless 367 sensors, smart bracelets, and digital wallet.

368
The sensed data are sent to the digital wallet for aggrega-369 tion and encryption purposes.

370
Then, the data will be transmitted to the F2C layer for 371 processing and storage purposes [43]. Digital wallets are 372 portable and secure digital repositories that allow users to 373 store and manage identifiers and verifiable credentials, and 374 also encrypt and share medical data with others [29]. 375 2) USER LAYER 376 In our system, each user is identified by a DID, and he 377 has a set of VCs issued by trusted issuers. DSMAC allows 378 individuals to use their mobile wallets to manage their DID 379 and give access to their health data. Different levels of users 380 can participate in our system, such as:

381
• DO (Data Owner): plays a vital role in our system. He is 382 an entity (e.g., a patient) that owns the data to be shared. 383 He can manage his digital wallet or delegate permissions 384 to other users to manage his mobile wallet on behalf of a 385 DID owner. For example, an elderly parent might delegate 386 VOLUME 10,2022 to an adult the authority to manage the parent's medical account. Also, the DO performs data encryption, sets the access policies, and uploads ciphertext of the shared data to 389 the F2C.

390
• AR (Access Requester): is an entity that wants to access 391 data shared by DO. An AR has different privileges in diverse 392 situations such as a doctor, nurse, pharmacist, and researcher.

393
Each AR must create his DID using the digital wallet, then 394 register in the system using his DID. Upon successful regis-395 tration, a corresponding DID is resolved to DID Document 396 (DDO) and stored in the blockchain.

397
The AR initiates a data access request, obtains authoriza-  is detailed in our previous work [43].  However, health data are neither stored nor processed 410 on-chain to avoid potential high loads, it will be stored tem-411 porarily at the fog layer to have real-time medical data access 412 with minimal latency. Fog will send periodic data to cloud 413 computing for permanent storage [61].  In this part, we will improve the reliability, security as well 437 as privacy-preserving medical data. We suggest some secu-438 rity assumptions to satisfy the goal of preserving privacy 439 and resisting attacks threatening access authorization. Then, 440 we describe some attacks aimed at obtaining access autho-441 rization to medical data generated by the IoMT devices and 442 forwarded to the fog storage node. 443 We assume that the end-users might be honest but curious 444 about the health records and potentially interested to get more 445 data than what their access privileges allow. For example, 446 a pharmacist can be interested in obtaining patient prescrip-447 tions and learning different doctors' prescription patterns 448 which could be useful for marketing purposes. In addition, 449 we assume that the fog's nodes are honest but curious. They 450 can legitimately do their assigned tasks, but are also curious 451 about the privacy of the IoMT devices which are usually 452 exposed to malicious attacks. Therefore, attackers may reside 453 between the IoMT devices and the fog storage node. They try 454 to establish a channel through which different components 455 seem to communicate directly. They will also try to satisfy 456 the access policies by obtaining or using attributes illegally. 457 They can control, monitor, and modify all the data, tamper 458 with the message, drop some packets and even replace the 459 original message. Furthermore, all the data transmitted to the 460 fog storage and the blockchain through the digital wallet can 461 be intercepted and analyzed by the adversary.

462
In our model, the main aim of attackers is to gain access 463 privileges from the data owner. Thus, we are interested only 464 in attacks threatening the access process such as: An attacker can observe and record some encrypted data 467 during the transmission and reply to them in another request 468 using the user's signature. This can be accomplished by either 469 (i) network monitoring, or (ii) reading the blockchain. The 470 attacker can act as a user and actively interact with the system 471 to get the messages, or he can be a passive observer who 472 collects the messages at the network level [44]. Therefore, 473 this attack can help to get illegal authorization in the DSMAC 474 framework. 475 2) SPOOFING ATTACK 476 Spoofing is an unethical process where the unauthorized user 477 intrudes and promotes himself as an authorized user to access 478 the system [45]. This is also known as the masquerading 479 attack, it is the act of disguising an identity so that it appears 480 to be associated with a trusted and authorized user. Therefore, 481 the spoofing purpose is to gain access to health records using 482 another user's credentials and steal the personal information 483 related to the authorized user [45]. Therefore, the adversary 484 forges the credentials of the data owner and tries to commu-485 nicate with the system.

486
During this attack, we have considered the case where an 487 attacker spoofs a user DID to gain access to medical data. 488 Furthermore, he may change the identity of the data owner. 489

490
To get access to a system, attackers exploit lists of compro-491 mised user credentials. The attack is based on the assumption 492 that many users reuse their usernames and passwords across 493 constraints. This means that our security model reuses con-532 cepts and mechanisms of Role-based access control (RBAC) 533 [9] and Attribute-based access control (ABAC) [10], giving 534 the owner the right to self-manage his principal policies. 535 Hence, in a regular case, our system is instantiated with the

1) ROLE-BASED DECENTRALIZED ACCESS CONTROL (RDAC) 546
Role-based access control (RBAC) is a security technique that 547 allows and limits system access to different users based on 548 their role(s). It provides secure and flexible access control 549 policies to ensure the security and privacy of data, autho-550 rize users to access the data to fulfill their job require-551 ments, and minimize the risk of unauthorized access [9]. 552 RBAC can define how a user interacts with data, allowing 553 read-only or read/write access to certain roles. In DSMAC 554 framework, we propose the Role-based Decentralized Access 555 Control (RDAC) model that combines the RBAC model with 556 Blockchain. The key idea behind the RDAC approach is that 557 users are assigned roles based on their VCs, then define 558 the policies which contain the rules that must be followed 559 by AR while accessing or updating medical data. Finally, 560 we publish all access control policies according to the user-561 role assignments in a smart contract deployed on blockchain. 562 Each user can be assigned to one or multiple roles. Roles are 563 associated with default permissions (DP). Thus, the default 564 permissions are granted to users, and they are defined by the 565 policy decision smart contract (PDC).

566
Definition 1 Default Permissions (DP) represent the reg-567 ular basic permissions (RP) that are defined explicitly by a 568 smart contract based on the user's role (R).
The default permissions include the patient's DID, the off-571 chain URL medical data stored in the F2C computing, AR's 572 role, and authorized operation (Read, Write, and Update). One of the most popular access control methods is attribute-576 based access control (ABAC) [10], but it poses a serious threat 577 to privacy because it defines access control policies based on 578 user attribute values [48]. Whereas, DID is emerging as a 579 new alternative for preserving user privacy. In the DSMAC 580 framework, we propose the Attribute-based Decentralized 581 Access Control (ADAC) model that combines the ABAC with 582 DID model to solve the problem of ABAC's privacy and 583 apply it to emergency cases. Therefore, we implement the 584 access control policies based on DID Document (DDO) to 585 provide a level of adaptive security that would meet the DO 586 needs while taking into consideration the emergency cases. 587 The access rights are granted to users through any type of 588 attributes such as subject's attributes, object's attributes, and 589 environment attributes [10]. The DO can enforce the default 590 permissions (DP) by configuring adaptive permissions (AP) 591 based on DO's attributes, AR's attributes, and certain con-592 textual attributes which must satisfy specific requirements to 593 perform a specific operation. A contextual attribute defines 594 a specific environmental characteristic whose real value 595 changes dynamically such as date, time, location, and health 596 status (emergency case, critical crisis, normal, etc.). Hence, 597 AP is introduced to make and adjust decisions locally for 598 emergency and unanticipated situations.  The method name that identifies DID in our system is 659 ''dac'' (Decentralized Access Control). This produces a string 660 identifier of the form ''did:dac:namespace''. All DID must 661 begin with the following prefix: ''did:dac:''. The remainder 662 of the DID, after the prefix, is the Method-Specific Identifier 663 (MSI) [31].

664
In the DSMAC system, each user has a minimum one of 665 digital wallet with his DID, VCs, and private key used to sign 666 transactions and access requests. However, the public key will 667 be recorded in the blockchain to be accessible.

668
In summary, a digital wallet performs the following 669 functions:      In general, the AR must authenticate with his DID before 678 submitting an access request to medical data. He must prove 679 his identity and his role to access patient data using the VCs. 680 The VCs issuance process proceeds as follows: the AR sends 681 a signed request for issuing a new credential. When the issuer 682 (hospital) receives the request, he checks the validity of the 683 request by verifying the AR's signature. Once the verification 684 is completed, the issuer agrees to the credential request and 685 issues VC. The VC will be stored in the AR's wallet. 686 Now, when the AR requests authentication using his DID, 687 the AN, which acts as a verifier, sends him a proof request 688 to verify his identity. The AR processes the proof request 689 and determines the necessary credentials to satisfy the proof 690 based on ZKP [41], then he sends the response to the AN. 691 After, the AN uses the issuer's DID and the credential defi-692 nition specified in the proof response to verify the response. 693 If the response is validated, then, token-based authentication 694 is submitted to the AR.

695
The flowchart shown in Fig. 3 describes the interactions 696 between entities, including the information exchanged with 697 the blockchain, corresponding to the SSI's phases.

721
Following the Self-Sovereign paradigm, the digital identity of 722 the user is kept in a digital and private wallet. To this end, the 723 DSMAC framework includes a component which is a mobile 724 app through which the user can manage the wallet and at the 725 same time he can interact with the security of medical data 726 using an encryption scheme and the user's SSI wallet [59]. 727 For this purpose, a Zero Knowledge Encryption technique 728 is adopted to address specific requirements focusing on data 729 privacy. Zero Knowledge Encryption means that encryption 730 will only be carried out using keys that are held by the owner. 731 As a result, the data will be encrypted using a mobile app 732 before being sent, and the attackers will only gain access 733 to the encrypted data which is useless without the keys to 734 decrypt it. In the DSMAC framework, blockchain is used to store the 738 users' public key, decentralized policies, and the user's proof 739 to verify the credentials with minimum time and cost [11]. 740 It is operated on the fog layer to provide low latency for 741 decentralized access control functions [43]. Moreover, SSI 742 is used to facilitate user authentication and authorization in 743 regular and emergency cases. The main idea of the RDAC-based smart contract is to lever-747 age the features of the smart contract to set, manage, and 748 store default permission policies (DP) into the blockchain net-749 work. To reach these goals, a policy decision smart contract 750 (PDC) was developed. PDC is designed to assign user-role 751 along with role permission, then publish the details on the 752 blockchain.

753
The main features of the PDC are: i) allow the hospital 754 to verify the role of the user (by checking their credentials). 755 ii) allow the patient to permit users to access medical data 756 based on their associated roles and credentials. iii) allow the 757 hospital to maintain the information stored in SC. Therefore, 758 PDC implements several functions to make the user-role 759 assignment efficient, effective, and secure.

760
As well, we define the AMN as the agent who has the 761 right to manage access transactions and interact with PDC 762 by sending a Request Access transaction.

763
The Request Access transaction sequence can be processed 764 as follows, as shown in Fig. 5.     To specify the user's name and role to which we would 834 like to give access rights, the DDO policies are based 835 on hierarchically-named attributes, where 'u' means user, 836 'r' means the role, and 't' means type, and attributes are 837 separated by the ':' character. For example, the attribute 838 alice_u:doctor_r:cardiologist_t means that the user Alice 839 must be a doctor with a cardiologist specialty.

840
To proceed to the DDO permissions, AMN sends an autho-841 rization request to the blockchain once receiving an alert mes-842 sage from the patient's wallet. So, according to the patient's 843 DID included in the authorization request, blockchain returns 844 the corresponding authorizations managed by the patient's 845 DDO. Then, AMN sends an access token to users mentioned 846 in the Membership service if and only if they fulfill the 847 conditions.  in Fig. 6(a). Once all containers are started, we can view the 862 von network and ledger by visiting the following web page: 863 http://localhost:9000, as shown in Fig 6(b). Then, all involved 864 entities (issuers, holders, and verifiers) must be registered 865 in Hyperledger Indy and provided a DID. To generate DID 866 for our agents, we can use the ledger browser as shown 867 in Fig 6(b). Then, we use the default option ''Register from 868 FIGURE 6. a. Starting Von Network, b. VON network: management page and DID registration, c. Creating a public DID for the patient agent. seed'' in the ''Authenticate a New DID'' section, and put 869 ''EmatiSaidi00000000000000000000002022'' as the value 870 in the ''wallet seed'' field. Once successful, detailed infor-871 mation such as Seed, DID and Verkey will be shown below 872 the ''Register DID'' button, as illustrated in Fig 6(c).    Fig. 10(a,b,c,d) show all 903 4 transactions in action.

904
In addition, our framework proposes a procedure for inte-

912
The Aries infrastructure offers: (i) a blockchain interface 913 layer, (ii) libraries to implement cryptographic wallets for 914 secure storage of cryptographic secrets and other information, 915 (iii) an implementation of ZKP-capable W3C verifiable cre-916 dentials using the ZKP primitives found [59].

917
The initial idea was to create a front-end tool that uses 918 an API to interact with ACA-Py without the need for its 919 database. ACA-Py has support for maintaining and querying 920 lists of schemas, credentials, connections, etc. ACA-Py main-921 tains its keys and requires the controller application to cre-922 ate schemas, credential definitions, and revocation registries, 923 as illustrated in Fig. 10 [59].

924
Also, the ACA-PY provides a queue to hold messages until 925 the mobile agent requests them because the mobile wallets are 926 not online at all times, and are not constantly polling to see if 927 they have any incoming messages (that consumes resources, 928 particularly data and battery, on the phone) [59].  As shown in Fig. 12, we compared the transaction through-995 put of ADAC with RDAC. Likewise, the query transaction 996 throughput of ADAC is higher than RDAC. The latency measures the time of a transaction from sub-999 mission by the user until it is processed and written into the 1000 ledger.

1001
First, all the nodes of our system are deployed in fog 1002 computing for the low latency purpose [43]. Latency values 1003 for each experiment are shown in Fig. 13 using 500 users.

1004
FIGURE 13. Transaction latency of RDAC and ADAC models. It is noticed that there is a continuous growth in the average latency as the number of users is increasing for both experiments. However, the average latency of the ADAC model is lower than the RDAC model. VOLUME 10, 2022 latency as the number of users is increasing for both experi-1006 ments. However, the average latency of the ADAC model is 1007 lower than the RDAC model. It is important to mention that 1008 the higher level of security, the lower the latency.    In the DSMAC framework, scalability is analyzed through 1031 transaction latency and throughput. If the throughput remains 1032 constant or increases with the increase in the number of users, 1033 then the framework is scalable. In another way, if the latency 1034 remains constant or increases with the rise in users, then also 1035 it is considered a scalable framework that can maintain stable 1036 latency in a large-scale environment. The goal of the DID specification is to ensure sustainability 1039 and interoperability across different healthcare organizations. 1040 DSMAC framework brings a sustainable decentralized access 1041 control model without the involvement of the central entity 1042 based on sustainable DID solutions. The DID technique can 1043 increase patients' ability to contribute to building long-term 1044 sustainability. Thus, achieving sustainability in health care 1045 is essential to improving the identification of health sys-1046 tem functions. Enhancing sustainability, through DID assign-1047 ment, and managing resources efficiently, will deliver better 1048 outcomes for patients, and provide economic benefits.

1050
After explaining the process of the DSMAC model, 1051 we present the security and privacy analysis. We theoretically 1052 analyze how DSMAC can efficiently resist the attacks pro-1053 posed in the adversary model (Section 4.2). Since the main 1054 goal of an attacker is to gain authorization to access the health 1055 data.   In DSMAC system, the honest but curious model is adopted.

1091
The end-users are honest since all of them need access con-1092 trol policies to perform their assigned tasks. However, some 1093 of them are curious since they continuously can view and 1094 store patients' information. In our framework, the RDAC 1095 approach based on smart contracts is used to solve the prob-1096 lem of who has access to health records. Additional mech-1097 anisms are included for emergency cases such as an ADAC 1098 approach [37]. This approach is more precise in restricting 1099 access based on the DID document and blockchain. There-1100 fore, the immutability and integrity features of blockchain 1101 make it impossible for any entity to manipulate, replace, 1102 or falsify access control policies stored on the blockchain. 1103 In addition, each block of information contains a hash for 1104 itself and for the previous block to verify that the access 1105 control policies are not modified illegally [52]. Thus, smart 1106 contracts [60] and SSI technologies support securing the sys-1107 tem against various security concerns such as authorization 1108 and privacy-preserving data. The advantage of eliminating 1109 the trusted third party makes the decentralized access policy 1110 scheme suitable for user privacy-oriented scenarios.

1112
The security of DSMAC framework is also evaluated by 1113 different attacks. Therefore, the attacker could not inter-1114 cept or update or retrieve the medical data in unauthorized 1115 access since our decentralized access control system plays a 1116 vital role to protect health data against unauthorized access. 1117 VOLUME 10, 2022 As proof, we present the resistance of some attacks threatening the access process such as replay attacks, spoofing 1119 attacks, and credential-stuffing attacks. tively. It is based on blockchain to provide better access 1123 control mechanisms. In this way, no one can alter its contents. 1124 We note that blockchain defends against transaction replay 1125 since every single transaction is embedded with nonce value 1126 and timestamps [4]. This will provide the system with a 1127 protection mechanism against replay attacks. And even each   VCs of the user, and each user gets a public key which is 1167 stored in blockchain. In this way, the attacker will not be able 1168 to provide a physical authentication method. This makes it 1169 harder for the attacker, which makes the credential stuffing 1170 attack not possible.

1172
In this paper, DSMAC, a decentralized access control system 1173 for health data based on the combination of blockchain, 1174 RBAC, ABAC, DIDs, and VC was proposed by adopting 1175 smart contract and self-sovereign identity (SSI) technology. 1176 The framework is implemented in a decentralized and trust-1177 less way to share medical records and preserve security and 1178 privacy at the same time.

1179
The choice of the SSI model allows users to own and 1180 manage their identities. This makes our framework more suit-1181 able for high privacy requirements. Deploying the authoriza-1182 tion and verification processes with smart contracts allows 1183 a decentralized access control system for users. Therefore, 1184 access control policies can be remotely updated by updating 1185 a smart contract.

1186
DSMAC is based on different contributions aimed to pro-1187 vide benefits in the areas of privacy/security, scalability, and 1188 sustainability in the medical environment. Likewise, we com-1189 pared DSMAC with some typical access control models and 1190 implemented a prototype of the proposed framework in reg-1191 ular and emergency cases. The results of the performance 1192 evaluation demonstrate that the proposed approach is highly 1193 scalable and efficient in terms of submission and execution 1194 time, throughput, cryptographic computations and latency. 1195 For future work, we are interested in integrating machine 1196 learning algorithms to manage EHR. Also, we can integrate 1197 the differential privacy algorithm with the DSMAC system to 1198 provide better data protection and preserve user privacy. 1199 healthcare system using blockchain and enhanced bell-LaPadula model,'' identifiers for entity authentication in electronic health records,'' Cogent