Future Generation Computer Systems 142 (2023) 195–211

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

A novel system for medical equipment supply chain traceability based

on alliance chain and attribute and role access control
∗
Jiatao Li a , Dezhi Han a , Zhongdai Wu b,c , Junxiang Wang c , Kuan-Ching Li d , ,
Arcangelo Castiglione e
a
College of Information Engineering, Shanghai Maritime University, China
b
Shanghai Ship and Shipping Research Institute Co. Ltd., China
c
COSCO Shipping Technology Co. Ltd., China
d
Department of Computer Science and Information Engineering, Providence University, Taiwan
e
Dipartimento di Informatica, University of Salerno, Italy

article info a b s t r a c t

Article history: With the increasing sales of the medical device market, the medical incidents caused by passive
Received 15 June 2022 medical devices are increasing, which needs to be solved from the medical device supply chain. In
Received in revised form 4 December 2022 addition, there are complex rights retrieval and assignment problems in the medical device supply
Accepted 22 December 2022
chain system, and the traditional Role-based Access Control (RBAC) model is no longer suitable for the
Available online 31 December 2022
actual application environment of the supply chain.
Keywords: This article combines the traditional RBAC model and the Attribute-based Access Control (ABAC)
Hyperledger fabric model for access control management in the medical device supply chain to overcome the limitations
ABAC model abovementioned, taking advantage of the ABAC model’s flexibility to achieve granular and dynamic
RBAC model management of permissions, as also the RBAC model to simplify the permissions management of the
Smart contract
entire system. Blockchain technology’s traceability, non-tampering, and decentralization features are
Supply chain
essential to eliminate passive and inferior medical equipment sales activities, solving the problem of
Medical field
mutual mistrust and ‘Information Silo’ between the two sides of medical device transactions. The access
control model is implemented in the blockchain’s smart contract, providing granular and dynamic
authority management for the medical equipment supply chain and guaranteeing the security and
privacy of medical device information in the supply chain. Three smart contracts on Hyperledger Fabric
are designed for device management information, storage of implemented access control models, and
implementation of access control policies. Experimental results show that the entire system is stable,
ensuring high throughput and high security and promising.
© 2022 Elsevier B.V. All rights reserved.

1. Introduction adverse event reports in 2020. Such several reports represent an

In recent years, benefited from the development of the econ-
omy, people’s health needs are increasing, and the world medical
device market has ushered in a huge development opportunity,
with the market scale highly expanding. As an essential part of
medical equipment management, the medical equipment supply
chain has a vital role in ensuring the quality of medical equip-
ment. A vulnerable healthcare supply chain is risky as it can lead
to many failures in healthcare delivery, directly impacting patient
safety and health outcomes [1–3]. According to the ‘‘Annual Re-
port on Monitoring of Medical Device Adverse Events in China
(2020)’’ [4], the National Medical Device Adverse Event Monitor-
ing Information System received a total of 536,055 medical device
∗ Corresponding author.
E-mail address: kuancli@pu.edu.tw (K.-C. Li).
increase of 35.25% over the previous year, as shown in Fig. 1.
However, due to the lack of trust among most participants in
a supply chain transaction, both parties may conceal or misreport
accurate product information. Trust in any supply chain is a
complex issue challenging to measure and achieve [5,6]. This pre-
vents the smooth cooperation of all parties in the devices’ supply
chain and enables some criminals to quickly bring counterfeit and
shoddy products into the market. In addition, if the server storing
information on the supply chain encounters data tampering, it
will lead to information asymmetry among users in the supply
chain, and information cannot be fully shared [7,8]. Because med-
ical devices have not yet formed a unified and complete chain
of custody, it is difficult for regulatory authorities to supervise
and recover substandard medical devices promptly and accu-
rately. Additionally, it is difficult for equipment manufacturers to
provide after-sales maintenance for repeatedly transferred equip-
ment. The abovementioned reasons have caused risk factors such

https://doi.org/10.1016/j.future.2022.12.037
0167-739X/© 2022 Elsevier B.V. All rights reserved.
J. Li, D. Han, Z. Wu et al.
Fig. 1. Number of medical devices adverse event reports in China during the period 2016∼2020.
as information asymmetry, imperfection, and untrustworthiness
in the current medical equipment supply chain.
Fortunately, in recent years, the rise of blockchain technol-
ogy has brought new solutions for secure information stored
in the medical device supply chain. Blockchain technology is
widely used in education [9,10], smart finance [11,12], Internet
of Vehicles [13–15] and other fields. As a decentralized ledger,
the data on the blockchain is tamper-proof and traceable. As a
result, blockchain technology is frequently used to address the
problem of mutual distrust among customers in a multi-user
environment [16]. Indeed, due to the decentralized characteristic
of blockchain technology, the records of each transaction and
maintenance of devices can be updated to the blockchain’s ledger
automatically and timely through smart contracts [17,18]. This
way, information leakage and tampering caused by third-party
intervention are avoided. In addition, with the immutability of
records in the blockchain ledger, the authenticity of historical
operation information in the supply chain can be guaranteed.
Moreover, due to the traceability of blockchain technology, when
medical devices have sudden quality problems, the regulatory
authorities can monitor them on time, and manufacturers can
effectively recycle the equipment. In summary, using blockchain
technology for the medical equipment supply chain not only
can trace the entire flow of medical equipment, thus eliminating
the occurrence of poor quality counterfeit medical accidents, but
also provide the history and maintenance records of medical
equipment for both sides of the transaction, solving the problem
of ‘‘Information Silo’’ in the process of multiple transactions of
medical devices.
It is essential to realize information sharing in the medical
device supply chain. However, to ensure the security and privacy
of device information, we only allow users with permission to
access device-related information. Therefore, we implement the
access control model into the smart contract in the blockchain to
ensure that users can access it safely and efficiently.
Based on the medical device supply chain characteristics, we
propose a medical device traceability system based on attribute
and role access control and Hyperledger Fabric alliance chain, a
medical device trading platform with high throughput and a
more realistic trading system. The device trading system provides
granular and dynamic authority management for the medical
device supply chain and guarantees the traceability of medical
device resale transactions.
From the abovementioned discussions, the main contributions
of this article are as follows:
196
Future Generation Computer Systems 142 (2023) 195–211
• To combine the traditional RBAC and ABAC models for
managing access policies in the supply chain. In this way,
we can use the flexibility of ABAC to realize the granular
and dynamic management of permissions and the advan-
tages of RBAC to simplify the management of permissions
of the whole system. The combination of RBAC and ABAC
models absorbs the advantages of the two access control
models and makes up for the shortcomings of the two
access control models.
• To implement the access control methods into the smart
contract. When a user accesses the data in the supply
chain system, the smart contract can automatically judge
this user’s access rights. Then the blockchain can be op-
erated immediately according to the judgment result. In
this work, three intelligent contracts are designed on Hy-
perledger Fabric, used for device information management,
storage of policies for implementing the access control
model, and access control for implementing policies. Ex-
perimental results show that the throughput of the smart
contract designed in this paper is stable, and the entire
blockchain system has good performance and high security.
The remainder of this article is structured as follows. In
Section 2 we provide an overview of the literature, highlighting
the main works related to the contribution we propose, and
defining the advantages and disadvantages of each of them. In
Section 3 we provide the background necessary to follow and
properly understand our proposed work. In Section 4 we define
and show the proposed work, highlighting its architectural and
functional features and then providing details on each of its
components and the way how they interact. In Section 5 we
show the results of the experimental evaluation, contextualizing
and comparing the results obtained for the state-of-the-art, and
finally, in Section 6, we provide concluding remarks and draw
future research directions.
2. Related work
In this section, we survey the blockchain-based supply chain
traceability platform in Section 2.1 and the application of access
control on the supply chain traceability platform in Section 2.2.
2.1. Blockchain-based supply chain traceability platform
Blockchain technology has received much attention from ex-
perts and scholars for research on the traceability of the
J. Li, D. Han, Z. Wu et al.
supply chain, and many traceable supply chain platforms based
on blockchain technology have been proposed globally.
Ahmadi et al. [19] divided the whole drug supply chain into
four levels: raw material suppliers, drug manufacturers, drug
distributors, pharmacies, and drugstores. In addition, the pos-
sible problems at each level were analyzed in this paper. Fi-
nally, blockchain technology was combined with the pharma-
ceutical supply chain to enhance the traceability and visibility
of medicines moving along the supply chain. Patel combined
blockchain technology with medical images to solve the problem
of sharing such type of data [20]. The advantage of the decen-
tralized and immutability of the blockchain technology was used
in [20] to ensure users’ privacy. Musamih et al. [21] proposed
a tamper-proof scheme based on blockchain technology for the
current counterfeit drug phenomenon in the medical drug supply
chain. In addition, intelligent contracts were written based on
Ethereum to ensure that the events of all participants in the
supply chain could be automatically recorded. Huang et al. [22]
proposed a scheme based on Bitcoin, which guarantees the au-
thenticity and privacy of drug traceability data while ensuring
service delivery. Latif et al. [23] proposed a commodity tracing
system based on blockchain that uses smart contracts. This sys-
tem uses the traceability of blockchain to establish a commodity
traceability network. The proposed system could provide trace-
ability services for retail commodities and allows customers to
access it through the QR scan code. Dasaklis et al. [24] introduced
a pioneering quality control system for the green composite wind
turbine blade supply chain based on blockchain technology. The
introduced system ensures product quality by allowing various
parties in the supply chain to verify quality-related data. Ud-
din et al. [25] proposed a drug traceability system based on
Hyperledger Fabric, taking into consideration the characteris-
tics of blockchain, to eliminate the phenomenon of counterfeit
drugs currently on the market. Wu et al. [26] first analyzed the
existing problems in traditional supply chain management. For-
tunately, blockchain’s immutability, transparency, and decentral-
ization features can solve the pain points of current supply chain
management systems. However, there are still potential technical
challenges in supply chain management based on blockchain. This
paper summarized and discussed the critical technical challenges
of current blockchain-based supply chain management systems
from four aspects: scalability, throughput, access control, data
retrieval, and review.
2.2. The application of access control on the supply chain traceability
platform
However, applying blockchain technology to the medical de-
vice supply chain is not enough. Many platforms implement
access control into the blockchain to ensure the security and
privacy of device data in the supply chain.
Figueroa et al. [27] proposed a healthcare supply chain model
based on blockchain and ABAC model. In order to ensure the
security and traceability of medical equipment asset records in
hospitals, the authors introduced a solution based on blockchain
and RFID. RFID tags were used to ensure that hospitals’ relevant
surgical instruments and assets can only be accessed in distinct
areas. In contrast, blockchain technology was used to record the
flow of medical equipment in hospitals (including the disinfection
department, operating room, laboratory, and other locations) to
ensure the safety and traceability of medical equipment. Again,
the ABAC model is applied in this article to dynamically manage
permissions more flexibly and granularly. This model is more
suitable for practical applications than the current mainstream
RBAC model. Jamil et al. [28] proposed a system based on Hy-
perledger Fabric to guarantee the traceability of drugs in the
197
Future Generation Computer Systems 142 (2023) 195–211
supply chain. Again, this article analyzed the security of decen-
tralized and distributed storage of blockchain technology, where
smart contracts enabled users to interact with blockchain ledgers.
Finally, the Access Control List (ACL) model was used for ac-
cess control. Li et al. [29] proposed a supply chain finance(SCF)
management system based on blockchain, which realized secure
data storage and auditable access control. Compared with tradi-
tional SCF management solutions that mostly used third-party
platforms and centralized designs, this system achieved more
reliable secure storage and fine-grained access control. More-
over, this system used the ABAC access control model to ensure
that privacy-sensitive data can only be accessed by authorized
users, enhancing the entire system’s security. Sun et al. [30] pro-
posed a healthcare information security storage solution based
on Hyperledger Fabric and ABAC model. This solution stored
medical information in the ledger of the blockchain, realizing the
tamper-proof of medical information. Moreover, this solution im-
plemented the ABAC model into smart contracts, enabling secure
access to private data. Finally, this solution used IPFS technology
to store the primary information in the blockchain into IPFS,
which eased the storage capacity of the blockchain.
Based on the related works mentioned above, most of the
current blockchain research in the supply chain either does not
discuss access control when maintaining the blockchain ledger or
uses the RBAC model. When the goods in the supply chain are
resold multiple times, such a good is accompanied by the creation
and deletion of roles, as also the removal and redistribution of
access rights. This process will lead to an increase in the workload
of all parties and the leakage of private data, thus reducing the
throughput and information security of the whole blockchain
system.
3. Preliminaries
This section provides the background to follow and under-
stand our proposal. In particular, we introduce some necessary
concepts such as Hyperledger Fabric, ABAC and RBAC models, and
smart contracts.
3.1. Hyperledger Fabric
Compared with a traditional database, blockchain technol-
ogy can solve the problem of untrustworthy third parties in
the database. However, conventional blockchain technology is
still affected by shortcomings, such as low throughput, Proof of
Work (PoW) consensus technology consuming huge computing
resources, privacy issues, and others. Hyperledger Fabric is an
open-source enterprise-level development platform introduced
by IBM. Unlike Bitcoin and Ethereum, Hyperledger Fabric is an
alliance chain that enables network access only to the users who
have permission to join the network. Furthermore, since there
is a channel mechanism in the Hyperledger Fabric, only users
with the same channel can access each other’s account ledger,
ensuring users’ sensitive information private. In addition, there
is a smart contract mechanism in Hyperledger Fabric, which is
also called chaincode. Each participant of the blockchain network
need to negotiate smart contracts in advance according to the
actual situation. In addition, each node on the blockchain net-
work conducts trusted transactions and maintains the ledger of
blockchain accurately according to the rules of the smart contract
without the need for third-party operations. The mechanism of
the smart contract ensures the accuracy of data and improves
the transaction processing speed [31]. Hyperledger Fabric also
provides a Kafka cluster consensus mechanism. We remark that
compared with the PoW consensus mechanism in Ethereum and
Bitcoin, the Kafka message queue mechanism can quickly reach
J. Li, D. Han, Z. Wu et al.
Table 1
Comparison of common blockchain technologies.
Name Consensus mechanism
Bitcoin Pow
Ethereum Pow,Pos
Hyperledger Fabric Solo,Kafka, etc.
consensus in large-scale application scenarios [32–34], which
dramatically improves the throughput of the entire system. A
thorough comparison of standard blockchain technology features
is shown in Table 1.
Each node in Hyperledger Fabric can be roughly divided into
three categories according to its functions: Client, Peer, and Or-
derer. The Client is mainly responsible for calling, executing the
chaincode, and initiating transactions. The Orderer is mainly re-
sponsible for sorting all the transactions sent to the network,
sorting them into blocks according to the agreement in the con-
figuration, and submitting them to the confirmation node for
processing. Again, the Peer can be divided into two categories
depending on the business logic: the Endorser peer and the Com-
mitter peer. The Endorser peer checks and endorses transaction
proposals and calculates the results of transaction execution. The
Committer peer rechecks the legitimacy before accepting the
transaction result, accepting the modification of the legal trans-
action reconciliation ledger, and finally writing the transaction
result into the ledger. When a transaction is processed in Hy-
perledger Fabric, the Client sends the transaction to the Endorser
peer, and the Endorser peer verifies the received transaction
proposal request. When the Client collects enough messages and
endorsement signatures, it constructs a legal transaction request.
It broadcasts the transaction request to the Orderer, which sorts
them and creates a transaction block. Finally, the Client broad-
casts the transaction block to all Committer peers. Once all Com-
mitter peers are correct, the transaction record is updated to the
ledger in the blockchain.
3.2. ABAC and RBAC models
In this subsection, we introduce the two access control mod-
els used in this design. And the advantages and disadvantages
of these two control models are analyzed according to their
respective characteristics.
3.2.1. ABAC model
The Attribute-based Access Control model (ABAC) is a flexible
authorization model that checks whether a user has the right
to operate on the object through the entity’s attribute, oper-
ation type, and related environment. Unlike the RBAC model,
ABAC assigns permissions based on the existing attributes of
users and access objects rather than manually assigning per-
missions [35]. Therefore, the assignment performed by ABAC is
highly dynamic and flexible. In particular, in maintaining complex
relationships with many parties involved, using the RBAC model
requires maintaining numerous roles and authorization relation-
ships. Conversely, using the ABAC model is more flexible and
more secure, as it can combine the current attributes of roles and
entities to achieve fine-grained access control [36]. Attributes in
the ABAC model are composed of four partial elements (parts):
user entity, object entity, permission operation, and environment
entity.
The user entity attributes represent the attributes of the users,
including their ID number, name, position, and others. The object
entity attributes represent the attributes of the accessed object,
including the number of the accessed object, resource type, and
others. The permission operation attribute represents the oper-
ation performed by the user on the object, including viewing,
198
Future Generation Computer Systems 142 (2023) 195–211
Smart contract Type TPS
No Public chain Low
Yes Public chain Low
Yes Alliance chain high
updating, deleting, and others. The environment entity attributes
represent the environment information when a user initiates an
access request, including geographic location, time, and others.
The abovementioned parts are combined to form an access
rule. According to this access rule, the administrator assigns spe-
cific values to these four parts, forming a specific access pol-
icy. When users want to access, they submit the corresponding
verification information according to the access rules and then
compare it with the existing access policy. According to the
comparison result, the system decides whether to allow users to
perform the relevant operations.
However, there is always the phenomenon of partial permis-
sion duplication in the actual application scenarios. If the ABAC
mode is still strictly adopted for access control, it will bring
additional storage overhead and increase the complexity of policy
management.
3.2.2. RBAC model
The RBAC model’s basic idea is that the user’s operation per-
missions assignment is not directly granted to the users. How-
ever, one or more operations are packaged into a role, and then
the role is granted to users. Once a user has been assigned the
appropriate role, the user has all the operation permissions of this
role. There are two main advantages to using this model:
• When a class of users needs to perform multiple identical
actions, it can significantly save the overhead of duplicate
policy storage and simplify the management of permissions
in the system [37].
• When several new users join the system, the administra-
tors do not need to assign their rights individually. Instead,
the administrator can directly assign the appropriate role
to each user.
However, the RBAC model has two limitations. Firstly, the
inability to granularly divide permissions in complex application
scenarios often makes this model ineffective [38,39]. For example,
a person with the identity of a ‘‘consignee’’ in the supply chain
can pick up his or her goods, but when this person goes to
pick up the goods, the system cannot use this identity directly.
Moreover, the system needs a more fine-grained division of this
person to pick up which goods, and this person cannot take other
people’s goods. Secondly, the distribution of permissions is not
dynamic and is still an example in the supply chain. In order to
protect the privacy of users, the forwarder can only inquire about
transshipped goods in the area for which he or she is accountable.
The forwarder has no right to inquire about the goods once they
have been securely taken away. Again, the forwarder’s identity
authorization must be revoked at this time. However, the fre-
quent creation and deletion of identities in a supply chain system
with high liquidity is prone to security problems.
The essential characteristics of ABAC and RBAC are compared,
and this comparison is shown in Table 2.
In this work, the ABAC model is combined with the RBAC
model. The RBAC model does rough work, and the ABAC model
supplements it with finer filtering. Please refer to Section 4.2
for the detailed design of the access control model. Finally, we
remark that there are other access control models based on the
hierarchical assignment of cryptographic keys [40–44].
J. Li, D. Han, Z. Wu et al.
Table 2
Comparison of ABAC and RBAC models.
Characteristic RBAC ABAC
Granularity Low High
Dynamic No Yes
Scalability No Yes
Flexibility For small and Works with almost any
medium-sized organizations organizations
3.3. Smart contracts
The smart contract is a script embedded in the blockchain and
can be automatically executed. The administrator has to design
the smart contracts and install them on the blockchain before the
blockchain network is launched. Once a particular transaction in
the blockchain meets the conditions triggered by the smart con-
tract, the smart contract will be automatically executed, resulting
in new transaction data and events [45,46].
For the traditional transaction model, a reliable third-party
intermediary is generally required to ensure the smooth progress
of the transaction. However, this mode often needs more time
and cost and may even cause a single point of failure [47–50].
On the other hand, blockchain replaces the traditional interme-
diary mode through a distributed consensus mechanism. At the
same time, the whole system is embedded with pre-specified
smart contracts. The smart contracts stored in the blockchain
are automatically triggered decentralized. This decentralization
improves the efficiency of the whole business process. It avoids
the single point of failure caused by the tripartite intermediary,
thus improving the whole system’s security [51–54].
A typical smart contract workflow is as follows [55]:
Step1 The administrator designs the smart contract according
to the rules established in advance.
Step2 The administrator uploads and stores the smart contract
into the blockchain system and then installs the smart contract
on each node inside the blockchain.
Step3 Smart contract transactions will be automatically ex-
ecuted when the user interacts with the blockchain. After the
transaction is executed, the transaction result will be uploaded
to other nodes in the network, waiting for verification.
Step4 The blockchain network verifies the transaction through
the consensus mechanism. After the verification is passed, the
transaction record is kept in the block, and the status of the smart
contract will be updated simultaneously.
4. System model design
In this section, we mainly introduce the architecture of the
medical supply chain management system based on blockchain
and access control. In particular, we first detail the system archi-
tecture of our proposal in Section 4.1. Then, in Section 4.2, we
describe the rationale behind the access control model and smart
contract design underlying such a proposal. Finally, we show the
system flow characterizing our proposed work in Section 4.3.
4.1. System architecture
In this subsection, we describe the architecture of our entire
system, the specific entity use cases, and the permission design
we will describe in detail in Sections 4.2 and 4.3.
The underlying architecture of our proposed work is composed
of two main components: user and blockchain network. After a
user completes the registration, the Certificate Authority (CA) will
generate an identity certificate for the user. Only the user who has
obtained the certificate can access the blockchain by calling the
199
Future Generation Computer Systems 142 (2023) 195–211
relevant API. When the user’s access information is transmitted
to the blockchain, the blockchain will invoke the smart contract
to analyze the access information, check if it has the right to
perform related operations, and then complete the corresponding
operations. The overall architecture of the proposed system is
shown in Fig. 2.
The user includes manufacturers, repairers, suppliers, own-
ers, and temporary visitors. The manufacturer is responsible for
uploading the qualified products to the blockchain. Moreover,
when there is a quality failure in the issued product, the avail-
able label of the product should be modified in time, and the
regulatory department will contact its owner and recycle it. The
repairer is responsible for repairing the device that has passed
the verification and adding repair records. Users and suppliers
are the current owners of devices and can view their device’s
historical maintenance and transaction information. In addition,
product owners have the right to create visitor status for others
to view information about their devices for a limited time. Once
the time has passed, the access rights of temporary visitors will
be automatically revoked. Finally, the product owner can resell
the product. Once the resale is successful, the ownership of the
product will change, and the original owner will not have the
right to perform any operations on the product.
The blockchain part is based on Hyperledger Fabric and mainly
implements the following two functions:
• The Certificate Authority (CA) is responsible for providing
digital certificate-based identity information digital certifi-
cates for all users in the Fabric. Only users who have ob-
tained certificates can join the network and invoke relevant
interfaces to operate on blockchain data.
• Smart contracts deployed on the blockchain are responsible
for controlling the upload of data to the database in the
blockchain after each operation. It also controls access to
user requests based on access control rules and manages
the access control policy in the ledger of blockchain-based
on updates to the access control policy.
4.2. Access control model design
In the supply chain of medical devices, it is necessary to divide
multi-granularity permissions and realize dynamic processing of
such permissions. Therefore, in this paper, we adopt the ABAC
model as the overall architecture to define AS (user entity), AO
(object entity), AE (environment entity), and AP (authority oper-
ation). However, in AS, as a user entity, there are a lot of repeated
operations among different users, so we propose the RBAC strat-
egy to package all associated operations into Role and take the
Role as an attribute of AS in the ABAC model. The advantage of this
design is that it not only satisfies the granularity and dynamicity
of the complicated authority management in the supply chain
of medical devices but also takes advantage of the RBAC model
to eliminate the redundancy of policy storage caused by the
repetitive operation of users, thus diminishing the complexity of
the ABAC model.
4.2.1. RBAC model design
In this section, we introduce all user entities in this system.
The user’s Role represents the current user’s identity information
about the device. There are three kinds of identity information
designed in this paper: Owner, Repairer, and Visitor. Users with
different identities have different permissions to operate on the
device.
Owner: the user is the owner of the current device. A device
can only be owned by one user, but one can own multiple de-
vices simultaneously. The owner has permission to perform the
following operations on the device he or she owns.
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 2. System architecture of the proposed system.

Table 3 Table 4
Attribute definition of AS. Attribute definition of AO.
Name Definition Name Definition
UserId Unique number for each user DevID Unique number for each device
Role Identification of user identity docType Brand of device
Producer Producer of device
ProDate Warranty period of device
EnableTag Qualification identification of device
(1) Create a temporary user identity, i.e., Visitor for the user. HisTra Historical transactions of device
HisRep Historical maintenance record of device
Before the transaction, the user can authorize the prospec-
tive buyers to view the relevant information about the
equipment, including maintenance information and histor-
ical transaction information, within a certain period. The AO represents the attributes of the device on the supply chain,
device owner needs to know the identity number of the and the detailed attribute definitions are shown in Table 4.
temporary user to be authorized and set a time limit for the The DevID represents the unique number of each device, which
temporary user to access the device only within a specified is used to index the device uniquely. EnableTag represents the
period. qualified identification of the equipment. Only qualified equip-
(2) Query the information of all devices owned by the user, in- ment can be circulated in the market. If the device sold by the
cluding historical transaction records, maintenance manufacturer is unqualified, the manufacturer has the right to set
records, equipment models, manufacturers, warranty pe- this identification as unqualified and recall the device.
riod, and others. AE represents environmental information. In this paper, the
(3) Transfer a device owned by the user. After the transaction attribute of AE denotes the reasonable access time AllowedTime
is complete, the original owner has no permission to per- of the device for temporary users. If the temporary user requests
form any operation on the device. The new owner of the longer than the validity period of the permission, the user’s
device inherits all the permissions of the original owner. operation will be denied.
As shown in Eq. (1), AP represents the access control policy of
Visitor: It represents the temporary user identity. The owner the current entity. If it is True, it can be accessed, and if it is False,
of the device creates a temporary user identity. The user with the it will deny access.
Visitor identity can only query part of the information about the
True, allow
{
specified device within a specified time. The partial information AP = (1)
only includes the device’s historical transaction and maintenance False, deny
records. ASAO: ASAO represents the mapping relationship between
Repairer: It represents the identity of the maintainer of the users and devices. In order to achieve fine-grained permission
device. The manufacturer of the device specifies the identity of division, we use ASAO as an index when storing access control
the Repairer. The user with Repairer identity can repair the equip- policies in the ledger of the blockchain. In this paper, the ASAO
ment and add corresponding maintenance records. In addition, is mainly composed of AS.UserID, AO.DeviceId, and AS.Role, which
only the user with the identity of the Repairer has the authority ensures a one-to-one correspondence between different identi-
to manage the maintenance records of the device, and even the ties of users and devices. Moreover, to ensure the uniqueness and
owner of the device cannot change the maintenance records. security of the mapping index, the SHA-256 cryptographic hash
function is used to transform ASAO to obtain Index as the index of
4.2.2. ABAC model design the access control policy stored in the database of the blockchain.
According to the actual situation of the medical device supply The ASAO is computed according to the formula shown in Eq. (2).
chain, we define each attribute AS, AO, AE, AP in the ABAC model
as follows: AS represents the definition of the user entity in the sha256
system, and its attributes are shown in Table 3. − {AS .UserId, AO.Dev iceId, AS .Role}
Index ←−−− ASAO ← (2)
The UserId is the unique identifier of a user. The Role repre-
ABAC policy (Policy) stores the attributes related to access
sents the identity of each user, and each identity corresponds to
control. It consists of AE, AS, AO, and AP.
a different set of operation permissions. The Role has been defined
in the RBAC model above. Policy = {AS , AE , AO, AP } (3)
200
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

The ABAC policy in this paper is stored in the blockchain’s pol- As per Eqs. ((6)∼(9)), the number of parameters of Ac-
icy ledger with the ASAO index and Policy as detailed information. cessAvg can only be 2, 3 or 4. Therefore, to improve the
into AC’s processing efficiency, before verifying the policy of the
PutState(Index, Policy) −→ {Ledger , SDB} (4) access request, the number of parameters should be judged
and directly return an error to the input that does not meet
4.3. Smart Contract design the number of parameters.
⎧
In addition to realizing the access control in the above design, ⎪
⎪ 2 continue
⎪
smart contracts are also related to the storage of medical equip- ⎪
⎨ 3 continue
ment, so they are the core of the solution. Three smart contracts len(AccessAv g) = (10)
have been designed for the implementation of the traceability ⎪
⎪
⎪ 4 continue
system for the medical equipment supply chain based on access
⎪
⎩
other returnError
control: Access Contract (AC), Device Contract (DC), and Policy
Contract (PC). According to the input ASAO mapping relationship as the
key value, invoke the PC to the blockchain database to
(1) Access Contract (AC): AC mainly realizes the access query the policy. If no relevant policy is found, the policy
control of the blockchain network to the user’s request. It verification fails, and access is denied.
verifies the permission of the user’s operation through the
PC .QueryPolicy(Index)
request submitted by the user and the user’s attributes. Policy ←−−−−−−−−−−− {Ledger , SDB} (11)
from
The AC provides an interface for user access. The request
operations sent by the user are all initiated toward the Next, the access identifier AP in the policy should be
AC. After the AC performs the corresponding authentication, detected. The access can be allowed only when the AP is
other related contracts are invoked for specific operations. true; otherwise, the access will be denied.
The Access Contract is mainly composed of the following
True, allow
{
methods:
Policy.AP = (12)
CheckAccess(): This method represents the core function False, deny
of AC. It is responsible for verifying the access information
sent by users and performing specific operations based on After the policy verification is passed, the user needs
specific requests. CheckAccess()’s workflow can be divided to be authenticated. That is, check whether the identity
into input parameter confirmation, access control policy in the policy matches the user’s access operation. If the
authentication, and execution instructions. user’s operation does not match the user’s identity, the
First, when the user submits an operation request to the authentication fails, and the access is denied.
blockchain, the user needs to input the access parameter
< Owner , querHis >
⎧
(AccessAvg). As shown in Eq. (5), the AccessAvg consists of ⎪
⎪
⎨< Owner , creVisit >
⎪
ASAO, operation name (Operation), and operation content
⎪
⎪
(OperationContent). / < Ow ner , transPc >
{ASAO.Role, Operation} ∈ → Access Denied
−
⎪ < Visitor , querHis >
⎪
AccessAv g ←
− {ASAO, Operation, OperationContent }
⎪
(5) ⎪
⎪
< Repair , addRep >
⎩
The Operation includes querying the historical informa-
tion of the device (querHis), creating temporary access user (13)
identity (creVisit), transferring transaction rights (transPc),
After the user passes the identity verification, the system
and adding equipment maintenance records (addRep). More-
will also verify the remaining ABAC attributes based on the
over, the OperationContent that needs to be input is also
user’s identity and operation and then automatically invoke
different with different operations.
the relative smart contract to perform the relevant operation
For the querHis method, there is no need to enter ad-
after passing the verification. Different operations require
ditional operation content because the device number that
different ABAC attribute authentication, and different smart
needs to be accessed is already included in the ASAO, and the
contracts are invoked. For the detailed smart contract design
AccessAvg at this time is shown in Eq. (6). For the creVisit
method, the user also needs to input the user’s ID of the of related operations, please refer to Algorithm 1.
authorized person, and the AccessAvg at this time is shown
in Eq. (7). For the transPc method, in order to correctly Algorithm 1 Part of CheckAccess(): The Specific Process of
transfer the device permissions to the buyer, the user needs Handling User Operations
to input the buyer’s ID additionally, and the AccessAvg at this Require: Args
time is shown in Eq. (8). For the addRep method, to trace Ensure: Response or Error
the historical maintenance information more accurately, the 1: if Operation == querHis then
maintenance provider needs to input the maintenance loca- 2: if len(Args)! = 2 then
tion and content as OperationContent, as shown in Eq. (9). 3: return Error : Args Inv alid
4: end if
AccessAv g ←
− {ASAO, querHis} (6) 5: if AS .Role ∈<
/ Owner , Visitor > then
6: return Error : Identity Inv alid
7: end if
AccessAv g ←
− {ASAO, creVisit , VisiterId} (7)
8: if AS .Role == Visitor then
9: if Policy.AE .EndTime > Uinux.Now Time then
AccessAv g ←
− {ASAO, transPc , TransId} (8) 10: return Error : Permission Has Expired
11: end if
AccessAv g ←
− {ASAO, addRep, RepairPlace, RepairStation} (9) 12: end if
201
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

13: MaDev ice ← Inv okeChaincode(PC , FindByDev Id, the device number, the repair site, and the warranty period.
AO.DId) The number of a device is a unique index, and there are no
14: < Dev ice, Error >← UnMamarshal(MaDev ice) two devices with the same number.
15: if Dev ice == Null or Error ! = Null then FindByDevId(): This function looks up the device based
16: return Error : No Find Dev ice on the device number passed in and returns all information
17: end if about the device.
18: return Dev ice.HisRep AddRepair(): This function adds the current mainte-
19: end if nance record for the equipment, including maintenance
20: if Operation == addRep then time, maintenance content, maintenance station, and other
21: if len(Args)! = 4 then information.
22: return Error : Args Inv alid AddTras(): It is used to add the current transaction infor-
23: end if mation to the device after it is completed. The transaction
24: if AS .Role! = Repair then information includes the information of the two parties and
25: return Error : Identity Inv alid the transaction time.
26: end if (3) Policy Contract (PC): The PC is mainly responsible for
27: Reponse ← Inv okeChaincode(DC , AddRepair , AO.DId, managing the access control policy in the entire system.
Args.RepairContent) When the user invokes the AC to initiate an operation re-
28: return Reponse quest to the device on the blockchain, the system will auto-
29: end if matically invoke the PC to query and return the user’s access
30: if Operation == creVisit then control policy for the AC to authenticate. Moreover, when
31: if len(Args)! = 4 then the access control policy changes after a user invoke func-
32: return Error : Args Inv alid tions related to the AC, the system automatically invokes
33: end if functions related to the PC to update the access policies. Like
34: if AS .Role! = Ow ner then the DC, the PC is not directly open to users but only provides
35: return Error : Identity Inv alid an interface for the AC operated by users.
36: end if AddPolicy(): This function is used to upload permission
37: New AS ←< Args.VisiterId, New AS .Role = Visiter > policy information. The policy comprises AS, AO, AE, AP.
38: New AE ←< Args.VisitTime > The policy is stored in the blockchain with the hash value
39: New ABACPolicy ←< New AS , AO, AP , New AE > of ASAO as the index and policy information as the value.
40: Reponse ← Inv okeChaincode(PC , AddPolicy, When uploading a policy, first query the blockchain with the
New ABACPolicy) policy’s index. If it already exists, it cannot be inserted again.
41: return Reponse The detailed process of AddPolicy() is outlined by Algorithm
42: end if 2.
43: if Operation == transPc then QueryPolicy(): Any operation performed by the user in
44: if len(Args)! = 3 then the system must first pass the permission verification. This
45: return Error : Args Inv alid function returns the user’s access policy on the blockchain
46: end if for the AC to verify the user’s access. According to the
47: if AS .Role! = Ow ner then input policy index, search the blockchain and return the
48: return Error : Identity Inv alid corresponding search results. Please refer to Algorithm 3 for
49: end if details.
50: New AS ←< Args.NewOwnerId, NewAS .Role = UpdatePolicy(): This method does not support invocations
Ow ner > by an external client, nor does it provide interfaces for
51: New ABACPolicy ←< New AS , AO, AP , AE > external client invocations. When part of a user’s operation
52: Inv okeChaincode(PC , DeletePolicy, PolicyId) involves a change in the user’s access control policy, the
53: Reponse ← Inv okeChaincode(PC , AddPolicy, smart contract automatically invokes this method to up-
New ABACPolicy) date and maintain the access control policy ledger in the
54: return Reponse blockchain.
55: end if
Algorithm 2 AddPolicy(): Add Access Policy
(2) Device Contract (DC): The DC is mainly responsible Require: Args
for dealing with device information management on the Ensure: True or Error
blockchain. In particular, it is responsible for uploading the 1: < AS , AO, AE , AP >← Args
device’s relevant information, modifying the device’s rele- 2: PolicyId ← sha256(AS .UserId + AO.Dev iceId + AS .Role)
vant information on the blockchain, and querying and re- 3: ExistPolicy ← Inv okeChaincode(Pc , QueryPolicy, PolicyId)
turning the device information on the blockchain. The DC 4: if ExistPolicy! = False then
generally does not directly open operations to customers. 5: return Error : Policy Hav eAlreadyExisted
The AC verifies the user’s request for querying or modifying 6: end if
the device based on access control rules, and the system au- 7: < MaPolicy, err >← Marshal(AS , AO, AP , AE)
tomatically invokes the DC to update or return the modified 8: if err ! = True then
data. The DC has the following main functions: 9: return Error
AddDevP(): This function is used to upload device infor- 10: end if
mation on the blockchain. When the manufacturer produces 11: err ← APIstub.PutState(PolicyId, MaPolicy)
a qualified product and puts it on the market, the device 12: if err ! = True then
needs to be uploaded to the blockchain. When uploading 13: return Error Failed To Add Policy
devices, it is necessary to import essential information such 14: end if
as the manufacturer of the device, the model of the device, 15: return True

202
J. Li, D. Han, Z. Wu et al.
Fig. 3. The flow chart of all transactions in the system.
Algorithm 3 QueryPolicy(): Query Access Policy
Require: Args
Ensure: Reponse or Error
1: < AS , AO >← Args
2: PolicyId ← sha256(AS .UserId + AO.Dev iceId + AS .Role)
3: < Response, err >← APIstub.GetState(PolicyId)
4: if err ! = True then
5: return Error
6: end if
7: return Response
4.4. Workflow
The workflow of the entire system is shown in Fig. 3, and
composed of four parts. The first part of this figure shows the
initialization of the blockchain network and the installation and
initialization of smart contracts. The second part shows the pro-
cess for the device manufacturer to upload the device to the
blockchain. The first and third subsections of the third part show
the system workflow when a user with an Owner identity queries
a device on the blockchain and is a transaction device. The sec-
ond subsection of the third part shows the workflow of tempo-
rary users obtaining Visitor identity and querying devices on the
blockchain within a limited time. The access rights are revoked
after the time limit is exceeded. Finally, the fourth part shows
the repairer’s workflow to update the equipment repair record to
the blockchain.
203
Future Generation Computer Systems 142 (2023) 195–211
5. Experimental results
This section shows the results achieved through the experi-
mental evaluation of our proposal. More precisely, we first outline
the testing environment. Then we outline the testing design
and methodology. Finally, we evaluate our proposed work from
various points of view, such as security and performance.
5.1. Testing environment
For the experimental evaluation of our proposal, we use Hy-
perledger Fabric as the development platform. The Hyperledger
Fabric version, related software, hardware information, and
docker node details are shown in Tables 5 and 6.
Before conducting smart contract testing, preparing the envi-
ronment for this activity is necessary. Fabric tools first generate
identity certificates for each node, including peer, order, and user
nodes. Certificates include the organization’s MSP and TLS cer-
tificates for TLS-based protected communications. Second, create
the initial block with Fabric tools, create the channel, add the
peer node to the channel, update the anchor node, and finish the
Hyperledger Fabric deployment. Finally, Install the chaincode to
peer nodes and initialize the chaincode. After completing all the
preceding steps, the Hyperledger Fabric environment is deployed,
and the experiment can begin immediately.
5.2. Experimental design and function display
To verify the characteristics of the proposed system, the ex-
periment is designed to have two devices, D1 and D2, numbered
‘‘D100010001’’ and ‘‘D100010002’’, respectively. There are four
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 4. D1 is successfully uploaded to the blockchain.

Table 5 DC. The U1 tries to add a maintenance record for D1, but the
Experimental environment. operation authority does not match, and U1’s operation will be
Experimental environment rejected, as shown in Fig. 8. U1 queries the relevant information
CPU Intel core i5-7300 of D1 again, and it can be seen that the maintenance record just
Memory 8 GB added can be found, as shown in Fig. 9.
Docker v19.03.2
The U1 trades the device D1 to U2, and the transaction oper-
Docker-compose v1.24.1
Node v12.12.0 ation in the CheckAccess() method of the AC is used. When the
Golang v1.13.5 system executes the CheckAccess() function, besides to automat-
Hyperledger Fabric v1.4.3 ically invoking the DC and PC for permission verification, it also
invokes the DeletePolicy() and AddPolicy() functions of the PC after
the transaction is successful in updating the access policy ledger.
Table 6
Nodes and number of docker.
The transaction record is updated to the D1 device information
in the blockchain. The successful transaction result is shown in
Name Number
Fig. 10. After the transaction is successful, U1’s request to query
Couchdb 4
D1’s device information will be rejected, because the access con-
Ca 2
Peer 4 trol policy has been updated. U2 successfully queries the device
Order 1 information of D1 and can find the previous transaction record in
Fabric-tools 1 the query result, as shown in Fig. 11.
AC node 4 The U2 creates a Visitor identity to D1 for U4, which experi-
DC 4
mental results are depicted in Fig. 12. The U4 inquires about the
PC 4
D1 within a limited time, and the system successfully returns
related information about D1, including historical maintenance
records and historical transaction records, as shown in Fig. 13.
users U1, U2, U3, U4, and their ID numbers are ‘‘19991112’’, When the limited time expires, the D1 device query operation
‘‘19991113’’, ‘‘1999114’’, and ‘‘19991115’’, respectively. Initially, initiated by U4 to the system again is rejected, as per Fig. 14.
user U1 has the Owner identity for device D1, and user U4 has the
Owner identity for device D2. The U3 has the Repairer identity for 5.3. Analysis
devices D1 and D2.
First, the manufacturer uploads qualified devices D1 and D2 In this subsection, we analyze the experimental results of the
and the related information to the blockchain ledger. Here, the previous part and verify the feasibility of our entire system from
three perspectives: security, dynamic, and fine-grained access
AddDevP() function in DC is invoked. Fig. 4 shows successfully
control policy.
uploading the D1 device to the blockchain.
The U1 queries the device information of D1. Here, the user
5.3.1. Security analysis
uses the CheckAccess() function of the AC. However, when the sys-
In the proposed system, the security of device data is guar-
tem uses the CheckAccess() method, it also automatically invokes anteed. To ensure the privacy of device information, only users
the QueryPolicy() function of the PC and the FindByDevId() method who have obtained the corresponding permissions can access
of the DC to perform access control authorization verification their own devices, and access to other devices is denied, as
and device information search, respectively. As shown in Fig. 5, shown in Figs. 5 and 6. In order to ensure the authenticity and
the information of D1 has been returned to U1. The U2 and credibility of maintenance records, only authorized maintenance
U3 query the device information of D1 and invoke the Check- providers can manage the maintenance records of equipment,
Access() method of AC. However, because the U2 and U3 have as depicted in Figs. 7 and 8 in the abovementioned experiment.
insufficient access rights, the system will deny their access Furthermore, to ensure the device’s security after the transaction,
operations, as shown in Fig. 6. we design a smart contract to update device permissions after
The U3 repairs D1 and uploads the repair record to the the transaction automatically. Once the transaction is completed,
blockchain ledger, as shown in Fig. 7. The maintenance record the system automatically modifies the permission relationship
operation is used in the CheckAccess() method of the AC. However, between the user and the device, updating the access control
the system also automatically invokes the QueryPolicy() method policy and the transaction record, as shown in Figs. 10 and 11
of the PC and the FindByDevId() and AddRepair() methods of the in the abovementioned experiment.
204
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 5. U1 has successfully queried the information of D1.

Fig. 6. U2 and U3 operations to query the information of D2 are rejected.

Fig. 7. U3 with the identity of Repair successfully adds the repair information for D1.

Fig. 8. U1 with Owner identity has no right to change the maintenance record of D1.

205
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 9. Maintenance records are added to the information of D1 on the blockchain.

Fig. 10. U1 successfully trades with U2 and updates the access control policy.

Fig. 11. After the transaction, U1 as the original Owner has no right to access the D1, and U2 successfully queries D1.

206
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 12. U2 with Owner identity successfully create Visitor identity of D1 for U4.

Fig. 13. U4 with Visitor identity can access D1 within the specified time.

Fig. 14. U4 with Visitor identity cannot access D1 after timeout.

5.3.2. Dynamic analysis 5.3.3. Analysis of fine-grained access control policy

A user who has a Visitor identity on a device can access
the device within a limited time. Once the specified period is
exceeded, the access operation issued by the user with identity
Visitor will be denied. In the above experiment, the U2 can query
the device information within a limited time, and once the valid
time is exceeded, it will not be able to re-access it. Here, the smart
contract is not invoked to modify the access policy. However, the
AE attribute verification in the ABAC model is used to realize the
dynamic management of the access policy.
On the other hand, we have implemented autonomous man-
agement of access control policies in smart contracts. When a
transaction occurs in the supply chain, the smart contract auto-
matically modifies the permissions of both parties to the trans-
action and maintains the access control policy in the blockchain’s
ledger without the need for additional permissions assignment by
the administrator.
207
There is a specific mapping relationship between each device,
user, and identity in this system. Not all owners with the Owner
identity have the right to operate on all devices. Users with the
Owner identity can only operate on their own devices. They are
not authorized to operate on devices owned by others. As shown
in Fig. 14, although both U2 and U4 have the Owner identity, the
U4 can only access device D2. Nevertheless, U4 using the Owner
identity to access the D1 would be denied.
5.4. Performance testing
In this part, we set up three groups of experiments to verify
and analyze three factors that may affect the performance of the
system. Furthermore, set up multiple experiments to simulate the
system’s concurrency, transaction time, and throughput under
actual usage conditions.
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

Fig. 15. Throughput of the proposed system under different MaxMessageCount. Fig. 16. Throughput of DC under different concurrent requests.

5.4.1. Experiments with packing block policy

Three main factors (i.e., parameters) affect the Fabric packag-
ing block: MaxMessageCount, PreferredMaxBytes, and
AbsoluteMaxBytes. MaxMessageCount represents the maximum
number of transactions included in a block. When a new trans-
action arrives, the block will be packaged if the number of
transactions in the cache reaches this condition (MaxMessage-
Count). The PreferredMaxBytes is used to limit the size of a block.
A block’s total transaction data size should be less than or equal to
this parameter. The AbsoluteMaxBytes parameter represents the
maximum size of a block. No block is allowed to exceed this size
under any circumstances. If transaction data exceeds this size, it
will be returned directly. In the first set of experiments, we tested
the impact of the MaxMessageCount in each block on the system
throughput under the premise that each block size was sufficient.
We set the MaxMessageCount parameter to 50, 100, 200, 250, and Fig. 17. Throughput of PC under different concurrent requests.
500 to repeatedly test the system throughput when the number
of concurrent transactions is 1000. The experimental results are
shown in Fig. 15. The experimental results show that when the
block size in Fabric is large enough, as the maximum number of
transactions in each block increases, the throughput of the entire
system also increases and finally stabilizes. Therefore, we can set
the block size and the MaxMessageCount according to the actual
environment, increasing the system throughput and avoiding the
waste of resources.

5.4.2. Experiments with throughput of smart contracts

In the second set of experiments, we test the impact on the
system throughput of the different operations performed by the
smart contract proposed in this paper, assuming that the maxi-
mum number of transactions allowed in each block is 50. On this
basis, we repeatedly set the number of concurrent transactions
to 50, 100, 200, 400, 500, and 800 to test each smart contract
operation’s throughput. The experimental results are shown in
(Figs. 16–19). Fig. 18. Throughput of AC under different concurrent requests.
According to the experimental results, we can draw the fol-
lowing conclusions:
(3) The throughput of the operations in AC is lower than in DC
(1) Whether AC, DC, or PC, the throughput of write operations
in smart contracts is always lower than reading operations and PC. Indeed, given those operations in AC often need to
in the same smart contract. invoke the operations in DC and PC, the complexity of the
(2) The throughput of each smart contract operation gradually operations in the AC is higher than in DC and PC.
increases with the concurrent increase in the number of
concurrent transactions and finally stabilizes. This stabi-
lization happens because when the number of connec- 5.4.3. Experiments with consensus algorithm
tions in the connection pool of the blockchain network We use different consensus algorithms in the third set of
has reached the upper limit, the throughput of the system experiments to test the system’s throughput. In particular, we
tends to be stable. use the two consensus algorithms of Kafka and Solo in Fabric
208
J. Li, D. Han, Z. Wu et al. Future Generation Computer Systems 142 (2023) 195–211

the access control model, while the access control model of the
system design in Jamil et al. [28] is based on ACL. However,
many users and resources exist in practical application scenarios,
and managing the access control list becomes burdensome. To
overcome the above limitations, we combine the advantages of
ABAC and RBAC models to achieve flexibility in the granular and
dynamic management of permissions and simplify the manage-
ment of permissions in the entire system. At the same time, we
implement the access control model in the blockchain’s smart
contract, ensuring the real-time data on the chain and improving
the entire system’s security.

6. Conclusions and future work

In this article, we combine the access control models of RBAC

and ABAC to bring the advantages of these two access control
Fig. 19. Comparison of Throughput between AC, PC and DC. models to one single access control policy management in the
medical device supply chain. In addition, we realize the access
control model through the smart contract on the blockchain,
providing fine-grained and dynamic access control strategy man-
agement for the flow of medical equipment in the supply chain.
Furthermore, solutions to ‘‘Information Silo’’ problems and com-
plicated authority management in the traditional medical device
supply chain are tackled. Also, a traceable and immutable medical
supply chain system is designed to ensure that the source of
medical equipment in the supply chain is transparent and that
the occurrence of medical accidents caused by untrusted medi-
cal equipment is prevented. In summary, the proposed research
enables both parties involved in the transaction to trust the
authenticity of the product information. Experimental evaluations
show that the entire stream of the blockchain system proposed
and designed is stable, has good throughput and security, and is
promising.
In future directions, we envision using electronic tag technolo-
Fig. 20. Throughput of the proposed system under different consensus. gies like RFID and QR codes as the only hardware identification
of medical equipment. Combining the electronic tag technology
Table 7 with the system designed will simplify the user’s operation and
Comparison of this experiment with other articles. strengthen the connection between equipment hardware and
paper Access control Smart contract Blockchain platform blockchain, thus improving the security of the complete supply
Paper [27] ABAC Yes Ethereum chain system. Furthermore, as the data in the blockchain con-
Paper [21] NO Yes Ethereum tinues to increase, the burden on the blockchain system will
Paper [28] ACL Yes Hyperledger fabric gradually increase. Therefore, we intend to utilize secure cloud
Paper [22] NO No Bitcoin storage technology to store the data on the blockchain in the
This paper ABAC&RBAC Yes Hyperledger fabric
cloud, and only the index of the cloud data will be stored in the
blockchain. In this way, we can reduce the blockchain’s storage
burden without affecting the complete system’s security.
to test the system throughput under the different number of
requests. The experimental results are shown in Fig. 20. According CRediT authorship contribution statement
to the experimental results, we can find that the Kafka consensus
mechanism is higher than the Solo consensus mechanism. Fur- Jiatao Li: Conceived and designed the analysis, Collected the
thermore, Solo is a single-node model that is not applicable to the data, Writing – original draft. Dezhi Han: Conceived and designed
actual scenario of supply chain management. Meanwhile, Kafka is the analysis, Performed the analysis, Financial support. Zhongdai
fault-tolerant and can ensure the reliability of the proposed sys- Wu: Collected the data, Contributed data or analysis tools. Junxi-
tem at high throughput. Therefore, Kafka’s high throughput can ang Wang: Collected the data, Contributed data or analysis tools.
meet the system requirements under supply chain management Kuan-Ching Li: Conceived and designed the analysis, Writing
proposed in this paper. – original draft. Arcangelo Castiglione: Performed the analysis,
Writing – original draft.
5.4.4. Literature comparison
The proposed system is compared with other related systems, Declaration of competing interest
as shown in Table 7. Figueroa et al. [27] propose a medical device
supply chain model based on blockchain and attribute access The authors declare the following financial interests/personal
control. However, the model presented in [27] is developed based relationships which may be considered as potential competing
on the public chain, which means that any node can join it, interests: Dezhi Han reports financial support was provided by
increasing the burden of the entire blockchain system and also National Natural Science Foundation of China. Dezhi Han reports
adding security risks to this system. The system design proposed financial support was provided by Natural Science Foundation of
by Musamih et al. [21], and Huang et al. [22] do not over-design Shanghai.
209
J. Li, D. Han, Z. Wu et al.
Data availability
Data will be made available on request.
Acknowledgments
Authors Jiatao Li and Dezhi Han contributed equally to this
work and are considered co-first authors. Author Kuan-Ching
Li is the corresponding author. This research is supported by
the National Key Research and Development Program of China
under Grant 2021YFC2801001, the Natural Science Foundation of
Shanghai, China under Grant 21ZR1426500, and the Top-notch In-
novative Talent Training Program for Graduate students of Shang-
hai Maritime University, China (No. 2021YBR008).
References
[1] R. Kumar, R. Tripathi, Traceability of counterfeit medicine supply chain
through Blockchain, in: 2019 11th International Conference on Communi-
cation Systems & Networks (COMSNETS), 2019, pp. 568–570, http://dx.doi.
org/10.1109/COMSNETS.2019.8711418.
[2] K.A. Clauson, E.A. Breeden, C. Davidson, T.K. Mackey, Leveraging blockchain
technology to enhance supply chain management in healthcare:: An
exploration of challenges and opportunities in the health supply chain,
Blockchain Healthc. Today 1 (2018) http://dx.doi.org/10.30953/bhty.v1.20.
[3] Y. Yue, X. Fu, Research on medical equipment supply chain management
method based on blockchain technology, in: 2020 International Conference
on Service Science (ICSS), 2020, pp. 143–148, http://dx.doi.org/10.1109/
ICSS50103.2020.00030.
[4] Annual Eport On Monitoring Of Medical Device Adverse Events in
China (2020), 2020, https://www.nmpa.gov.cn/xxgk/fgwj/gzwj/gzwjylqx/
20210329170305102.
[5] N. Kshetri, J. Voas, Supply chain trust, IT Prof. 21 (2) (2019) 6–10, http:
//dx.doi.org/10.1109/MITP.2019.2895423.
[6] H. Li, D. Han, M. Tang, A privacy-preserving storage scheme for logistics
data with assistance of blockchain, IEEE Internet Things J. 9 (6) (2022)
4704–4720, http://dx.doi.org/10.1109/JIOT.2021.3107846.
[7] S. Cai, D. Han, D. Li, A feedback semi-supervised learning with meta-
gradient for intrusion detection, IEEE Syst. J. (2022) 1–12, http://dx.doi.
org/10.1109/JSYST.2022.3197447.
[8] Q. Tian, D. Han, et al., An intrusion detection approach based on improved
deep belief network, Appl. Intell. 50 (10) (2020) 3162–3178, http://dx.doi.
org/10.1007/s10489-020-01694-4.
[9] D. Li, D. Han, Z. Zheng, T.-H. Weng, H. Li, H. Liu, A. Castiglione, K.-C.
Li, MOOCsChain: A blockchain-based secure storage and sharing scheme
for MOOCs learning, Comput. Stand. Interfaces 81 (2022) 103597, http:
//dx.doi.org/10.1016/j.csi.2021.103597.
[10] H. Li, D. Han, EduRSS: A blockchain-based educational records secure
storage and sharing scheme, IEEE Access 7 (2019) 179273–179289, http:
//dx.doi.org/10.1109/ACCESS.2019.2956157.
[11] D. Li, D. Han, H. Liu, Fabric-chain & chain: a blockchain-based electronic
document system for supply chain finance, in: International Conference on
Blockchain and Trustworthy Systems, Vol. 14, Springer, Singapore, 2020,
pp. 601–608, http://dx.doi.org/10.3390/rs14174343,
[12] D. Li, D. Han, N. Crespi, R. Minerva, K.-C. Li, A blockchain-based secure stor-
age and access control scheme for supply chain finance, J. Supercomput.
(2022) 1–30.
[13] H. Liu, D. Han, D. Li, Blockchain based trust management in vehicular
networks, in: International Conference on Blockchain and Trustworthy
Systems, Springer Singapore, Singapore, 2020, pp. 333–346.
[14] H. Chai, S. Leng, Y. Chen, K. Zhang, A hierarchical blockchain-enabled
federated learning algorithm for knowledge sharing in internet of vehicles,
IEEE Trans. Intell. Transp. Syst. 22 (7) (2021) 3975–3986, http://dx.doi.org/
10.1109/TITS.2020.3002712.
[15] H. Liu, D. Han, D. Li, Behavior analysis and blockchain based trust
management in VANETs, J. Parallel Distrib. Comput. 151 (2021) 61–69,
http://dx.doi.org/10.1016/j.jpdc.2021.02.011.
[16] H. Liu, D. Han, D. Li, Fabric-Iot: A blockchain-based access control system in
IoT, IEEE Access 8 (2020) 18207–18218, http://dx.doi.org/10.1109/ACCESS.
2020.2968492.
[17] W. Liang, D. Zhang, et al., Circuit copyright blockchain: Blockchain-based
homomorphic encryption for IP circuit protection, IEEE Trans. Emerg.
Top. Comput. 9 (3) (2021) 1410–1420, http://dx.doi.org/10.1109/TETC.2020.
2993032.
[18] F. Ullah, F. Al-Turjman, A conceptual framework for blockchain smart
contract adoption to manage real estate deals in smart cities, Neural
Comput. Appl. http://dx.doi.org/10.1007/s00521021058006.
210
Future Generation Computer Systems 142 (2023) 195–211
[19] V. Ahmadi, S. Benjelloun, M. El Kik, T. Sharma, H. Chi, W. Zhou, Drug
Governance: IoT-based Blockchain Implementation in the Pharmaceutical
Supply Chain, in: 2020 Sixth International Conference on Mobile and
Secure Services (MobiSecServ), IEEE, Miami Beach, FL, USA, 2020, pp. 1–8,
http://dx.doi.org/10.1109/MobiSecServ48690.2020.9042950.
[20] V. Patel, A framework for secure and decentralized sharing of medical
imaging data via blockchain consensus, Health Inform. J. 25 (4) (2019)
1398–1411, http://dx.doi.org/10.1177/1460458218769699.
[21] A. Musamih, K. Salah, R. Jayaraman, J. Arshad, M. Debe, Y. Al-Hammadi, S.
Ellahham, A blockchain-based approach for drug traceability in healthcare
supply chain, IEEE ACCESS 9 (2021) 9728–9743, http://dx.doi.org/10.1109/
ACCESS.2021.3049920.
[22] Y. Li, W. Liang, et al., Predicting drug-target interactions via dual-
stream graph neural network, in: IEEE/ACM Transactions on Computational
Biology and Bioinformatics.
[23] R.M.A. Latif, M. Farhan, O. Rizwan, M. Hussain, S. Jabbar, S. Khalid, Retail
level Blockchain transformation for product supply chain using truffle
development platform, Cluster Comput. 24 (1) (2021) 1–16, http://dx.doi.
org/10.1007/s10586020031654.
[24] T.K. Dasaklis, T.G. Voutsinas, G.T. Tsoulfas, F. Casino, A systematic literature
review of blockchain-enabled supply chain traceability implementations,
Sustainability 14 (4) (2022) 2439, http://dx.doi.org/10.3390/su14042439.
[25] M. Uddin, Blockchain Medledger: Hyperledger fabric enabled drug trace-
ability system for counterfeit drugs in pharmaceutical industry, Int.
J. Pharm. 597 (2021) 120235, http://dx.doi.org/10.1016/j.ijpharm.2021.
120235.
[26] H. Wu, J. Cao, Y. Yang, C.L. Tung, S. Jiang, B. Tang, Y. Liu, X. Wang, Y.
Deng, Data management in supply chain using blockchain: Challenges
and a case study, in: 2019 28th International Conference on Computer
Communication and Networks (ICCCN), 2019, pp. 1–8, http://dx.doi.org/
10.1109/ICCCN.2019.8846964.
[27] Figueroa, Añorga, Arrizabalaga, An attribute-based access control model in
RFID systems based on blockchain decentralized applications for health-
care environments, Computers 8 (3) (2019) 57, http://dx.doi.org/10.3390/
computers8030057.
[28] F. Jamil, L. Hang, K. Kim, D. Kim, A novel medical blockchain model for
drug supply chain integrity management in a smart hospital, Electronics
8 (5) (2019) http://dx.doi.org/10.3390/electronics8050505.
[29] D. Li, D. Han, N. Crespi, R. Minerva, Z. Sun, Fabric-SCF: a blockchain-based
secure storage and access control scheme for supply chain finance, 2021,
arXiv preprint arXiv:2111.13538.
[30] Z. Sun, D. Han, D. Li, X. Wang, C.-C. Chang, Z. Wu, A blockchain-based
secure storage scheme for medical information, EURASIP J. Wireless Com-
mun. Networking 2022 (1) (2022) 40, http://dx.doi.org/10.1186/s13638-
022-02122-6.
[31] S. Wang, L. Ouyang, Y. Yuan, X. Ni, X. Han, F.-Y. Wang, Blockchain-enabled
smart contracts: Architecture, applications, and future trends, IEEE Trans.
Syst. Man Cybern.: Syst. 49 (11) (2019) 2266–2277, http://dx.doi.org/10.
1109/TSMC.2019.2895123.
[32] H. Honar Pajooh, M. Rashid, F. Alam, S. Demidenko, Hyperledger fabric
blockchain for securing the edge internet of things, Sensors 21 (2) (2021)
359, URL 10.3390/s21020359.
[33] M. Cui, D. Han, J. Wang, An efficient and safe road condition monitoring
authentication scheme based on fog computing, IEEE Internet Things J. 6
(5) (2019) 9076–9084, http://dx.doi.org/10.1109/JIOT.2019.2927497.
[34] C.N. Nguyen, S. Hwang, J.-S. Kim, Making a case for the on-demand
multiple distributed message queue system in a Hadoop cluster, Cluster
Comput.-J. Netw. Softw. Tools Appl. 20 (3) (2017) 2095–2106, http://dx.
doi.org/10.1007/s1058601710310.
[35] D. Servos, S.L. Osborn, Current research and open problems in attribute-
based access control, Acm Comput. Surv. 49 (4) (2017) 65, http://dx.doi.
org/10.1145/3007204.
[36] Y. Zhu, R. Yu, D. Ma, W.C.-C. Chu, Cryptographic attribute-based access
control (ABAC) for secure decision making of dynamic policy with mul-
tiauthority attribute tokens, Ieee Trans. Reliab. 68 (4) (2019) 1330–1346,
http://dx.doi.org/10.1109/TR.2019.2948713.
[37] S. Bhatt, T.K. Pham, M. Gupta, J. Benson, J. Park, R. Sandhu, Attribute-based
access control for AWS internet of things and secure industries of the
future, IEEE Access : Pract. Innov. Open Solut. 9 (2021) 107200–107223,
http://dx.doi.org/10.1109/ACCESS.2021.3101218.
[38] G. Fragkos, J. Johnson, E.E. Tsiropoulou, Dynamic role-based access control
policy for smart grid applications: an offline deep reinforcement learning
approach, IEEE Trans. Hum.-Mach. Syst. (2022) 1–13, http://dx.doi.org/10.
1109/THMS.2022.3163185.
[39] W. Liang, Y. Yang, et al., PDPChain: A consortium blockchain-based privacy
protection scheme for personal data, IEEE Trans. Reliab. http://dx.doi.org/
10.1109/TR.2022.3190932.
[40] P.K. Roy, A.K. Tripathy, et al., Securing social platform from misinformation
using deep learning, Comput. Stand. Interfaces 84 (2022) 103674, http:
//dx.doi.org/10.1016/j.csi.2022.103674.
J. Li, D. Han, Z. Wu et al.
[41] W. Liang, L. Xiao, et al., Data fusion approach for collaborative anomaly
intrusion detection in blockchain-based systems, IEEE Internet Things J. 9
(16) (2022) 14741–14751, http://dx.doi.org/10.1109/JIOT.2021.3053842.
[42] A. Castiglione, A. De Santis, B. Masucci, F. Palmieri, A. Castiglione, X.
Huang, Cryptographic hierarchical access control for dynamic structures,
IEEE Trans. Inf. Forensics Secur. 11 (10) (2016) 2349–2364, http://dx.doi.
org/10.1109/TIFS.2016.2581147.
[43] A. Castiglione, A. De Santis, B. Masucci, F. Palmieri, X. Huang, A. Castiglione,
Supporting dynamic updates in storage clouds with the Akl–Taylor scheme,
Inform. Sci. 387 (2017) 56–74, http://dx.doi.org/10.1016/j.ins.2016.08.093.
[44] D. Han, N. Pan, K.-C. Li, A traceable and revocable ciphertext-policy
attribute-based encryption scheme based on privacy protection, IEEE Trans.
Dependable Secure Comput. 19 (1) (2022) 316–327, http://dx.doi.org/10.
1109/TDSC.2020.2977646.
[45] T. Hewa, M. Ylianttila, M. Liyanage, Survey on blockchain based smart
contracts: Applications, opportunities and challenges, J. Netw. Comput.
Appl. 177 (2021) 102857, http://dx.doi.org/10.1016/j.jnca.2020.102857.
[46] L. Ante, Smart contracts on the blockchain – A bibliometric analysis and
review, Telemat. Inform. 57 (2021) 101519, http://dx.doi.org/10.1016/j.tele.
2020.101519.
[47] D. Macrinici, C. Cartofeanu, S. Gao, Smart contract applications within
blockchain technology: A systematic mapping study, Telemat. Inform. 35
(8) (2018) 2337–2354, http://dx.doi.org/10.1016/j.tele.2018.10.004.
[48] D. Han, Y. Zhu, D. Li, W. Liang, A. Souri, K.-C. Li, A blockchain-based
auditable access control system for private data in service-centric IoT
environments, IEEE Trans. Ind. Inform. 18 (5) (2022) 3530–3540, http:
//dx.doi.org/10.1109/TII.2021.3114621.
[49] H. Liu, D. Han, D. Li, Blockchain based trust management in vehicular
networks, in: blockchain and trustworthy systems, Springer, Singapore,
2020, pp. 333–346, http://dx.doi.org/10.1007/9789811592133_26.
[50] H. Li, D. Han, M. Tang, A privacy-preserving charging scheme for electric
vehicles using blockchain and fog computing, IEEE Syst. J. 15 (3) (2021)
3189–3200, http://dx.doi.org/10.1109/JSYST.2020.3009447.
[51] Z. Zheng, S. Xie, H.-N. Dai, W. Chen, X. Chen, J. Weng, M. Imran, An
overview on smart contracts: Challenges, advances and platforms, Future
Gener. Comput. Syst.-Int. J. Esci. 105 (2020) 475–491, http://dx.doi.org/10.
1016/j.future.2019.12.019.
[52] M. Cui, D. Han, J. Wang, K.-C. Li, C.-C. Chang, ARFV: An efficient shared
data auditing scheme supporting revocation for fog-assisted vehicular Ad-
Hoc networks, IEEE Trans. Veh. Technol. 69 (12) (2020) 15815–15827,
http://dx.doi.org/10.1109/TVT.2020.3036631.
[53] W. Liang, Y. Yang, et al., PDPChain: A consortium blockchain-based privacy
protection scheme for personal data, IEEE Trans. Reliab. http://dx.doi.org/
10.1109/TR.2022.3190932.
[54] T.F.B. Marie, Y. Bin, H. Dezhi, A. Bowen, A hybrid model integrating MPSE
and IGNN for events recognition along submarine cables, IEEE Trans.
Instrum. Meas. (2022) 1, http://dx.doi.org/10.1109/TIM.2022.3198749.
[55] T. Talukdar, G. Batra, J. Vaidya, V. Atluri, S. Sural, Efficient bottom-
up mining of attribute based access control policies, in: 2017 IEEE 3rd
International Conference on Collaboration and Internet Computing (CIC),
IEEE, San Jose, CA, 2017, pp. 339–348, http://dx.doi.org/10.1109/CIC.2017.
00051.
Jiatao Li received the B.E. degree in internet of
things engineering from Hubei University of Educa-
tion,Wuhan, China, in 2021. He is currently working
toward the M.S. degree in computer science and tech-
nology with Shanghai Maritime University, Shanghai,
China. His main research interests include Blockchain,
loT, and distributed computing.
211
Future Generation Computer Systems 142 (2023) 195–211
Dezhi Han received the BS degree from Hefei Univer-
sity of Technology, Hefei, China, the MS degree and
Ph.D. degree from Huazhong University of Science and
Technology, Wuhan, China. He is currently a professor
of computer science and engineering at Shanghai Mar-
itime University. His specific interests include storage
architecture, blockchain technology, cloud computing
security and cloud storage security technology.
Zhongdai Wu received a bachelor’s degree in man-
agement information systems from Dalian Maritime
University, China, M.B.A. degree from Tongji Univer-
sity, China. and Ph.D. degree in business management
from Tongji University. Currently, he is working at
COSCO SHIPPING TECHNOLOGY CO.,LTD., as Vice Gen-
eral Manager & CIO and also at Shanghai Institute
of Navigation as vice president. His main research
specialized in cloud computing, information system
security, big data, Marine satellite communications and
navigation, machine learning and blockchain.
Junxiang Wang received a bachelor’s degree in Com-
puter Science and Technology from the East China
Normal University, China. He is currently working at
COSCO SHIPPING TECHNOLOGY CO., LTD., as a senior
technical manager and mainly engaging in the con-
struction of Enterprise Cloud Computing. He specialized
in cloud computing, DevOps, microservices, information
system security, big data and automated operation and
maintenance.
Kuan-Ching Li received a Ph.D. degree from the Uni-
versity of São Paulo, Brazil in 1994, 1996, and 2001. He
received distinguished and Chair Professorships from
universities in several countries and received awards
and funding support from several agencies and high-
tech companies. Besides publishing numerous research
papers and articles, he is co-author or co-editor of
more than 40 technical professional books published by
CRC Press/Taylor & Francis, Springer, and McGraw-Hill.
His research interests include parallel and distributed
processing, Big Data, and emerging technologies. He is
a fellow of the IET and a senior member of the IEEE.
Arcangelo Castiglione received the M.S. and Ph.D.
degrees in Computer Science from the University of
Salerno, Italy. Currently, he is an Associate Professor
at the Department of Computer Science, University of
Salerno. He is an Associate Editor for the IET Cyber–
Physical Systems: Theory & Applications (IET), Journal
of HighSpeed Networks (IOS Press), and International
Journal of Embedded Systems (Inderscience Publishers),
also has been a guest editor for Special Issues and
volume editor for Lecture Notes series. His research
mainly focuses on Cryptography, Information Security,
Computer Security, and Digital Watermarking.