1.

INTRODUCTION
IoTs have emerged as a revolutionary technology capturing the world at a fast
pace. IoT combined with AI, blockchain and 5G are taking the world into the era of
contextual connectivity enhancing personalised human experience. The IoTs are the
epicentre of this revolution threatened by diversified attack vectors. Gartner has
projected the IoT security expenditures to hit $3.1 billion by 2021 . Being resource
constrained, IoTs rely on traditional security mechanisms like passwords that are
susceptible to a variety of attack vectors. As a result IoTs can be easily compromised
due to insecure remote access. Electronic healthcare refers to the monitoring,
maintenance and improvement of the health of a patient by the use of digital
technologies and telecommunications. The healthcare sector is rapidly adopting the
IoT technology and transforming the hospital centric healthcare services to home
centric healthcare services. Either way the modern healthcare services are dependent
on IoTs and trust is the foundation of security and privacy in healthcare. IoTs have the
weakest link when it comes to trust as these devices are interconnected and usually
dependent on traditional security mechanisms which usually imply a centralized
architecture which incompatible with IoTs.Blockchain is an emerging technology
which has many intrinsic features including decentralised applications (Dapps),
decentralised trust, transparency, immutability and provenance . Due to its property of
decentralised trust and immutability, blockchain has the potential of providing
foolproof security for IoTs specially in the healthcare environment .
The healthcare devices are service critical that record sensitive patient data for
smart diagnosis, AI driven disease profiling, vitals management etc. Any services
without a central server, third party reliance and avoiding password-based security
mechanisms. malfunctioning within the IoT devices can lead to severe consequences,
for instance, a smart ventilator machine’s failure can be instantly fatal for an ICU
patient. Recently a vulnerability was discovered in GE Aestiva and Aespire
anaesthesia devices that allowed a hacker to bypass the authentication mechanisms and
manipulate the drug levels causing serious health injuries to patients which could be
fatal .Similarly, there is a breach of trust when insiders compromise the sensitive
healthcare data of patients and sell it in the black

1
market for personal gains. To protect the privacy of the individual’s data, HIPAA a
GDPR
pose heavy fines on the organisations that mishandle or leak the data of the patients
without their prior consent . Furthermore, often the IoT device manufacturers do not
comply with the security standards while designing such healthcare devices and
security is usually an afterthought. This leads to the necessity of having adequate
security mechanisms in place which are diverse and comply with modern health
standards like HIPAA and GDPR. Access Control and Identity Management has been
an Achilles heel for IoTs due to their heterogeneous nature and scalability issues.
Ownership and identity relationships in the IoT are closely related to the authentication
and authorization of the devices and the individuals respectively. The owner of an IoT
device may change over time and may be asked for authentication. Moreover, the data
collected by a device needs proper authorization mechanisms in order to ensure privacy
and traceability. The conventional authentication mechanisms like passwords are no
more effective and most of the devices are compromised due to folk model
implementation of security in these devices by manufacturers. No standard security
protocol exists for IoTs, hence, a number of proposed authentication and authorization
protocols exist .

1.1. CONTRIBUTIONS
Contributions are made to the healthcare industry through this research: This work
addresses the authentication and trust issues in IoTs for healthcare through a novel
approach using blockchain enhancing security. It utilizes fuzzy logic for adaptive
authentication and authorization mechanism providing AAA services without a central
server, third party reliance and avoiding password-based security mechanisms.The
proposed system “RELIABLE MODELLING OF HAZY MEDICAL CARE USING
BLOCKCHAIN AND IoT’’ is implemented and a comprehensive security and
performance analysis is performed. RELIABLE MODELLING OF HAZY MEDICAL
CARE USING BLOCK CHAIN AND IoTis proven to be practical and security-wise
effective for IoT-based distributed architectures.

2
1.2. ORGANISATION
Related Research discusses the existing authentication protocols in healthcare
including the ones utilising blockchain by briefly discussing their pros and cons.In
Preliminaries of Proposed System related to blockchain-hyperledger and fuzzy logic
are presented to enhance the understanding of the proposed healthcare security
framework. Reliable modelling of Hazy Medicalcare Using Blockchain and IoT-
Adaptive Security Framework via a scenario that aids to formalise design goals.
Security Analysis discusses the threat model by highlighting the attack vectors and the
mitigation strategies that are put in place within the proposed framework. Comparitive
Analysis provides comparative analysis against the state-of-the-art. This section also
gives performance-based analysis for practical use cases. Conclusion and future work
is drawn towards the end .

1.3. BLOCKCHAIN TECHNOLOGY

Blockchain technology is a structure that stores transactional records, also known as
the block, of the public in several databases, known as the “chain,” in a network
connected through peer-to-peer nodes .Typically, this storage is referred to as a ‘digital
ledger. Every transaction in this ledger is authorised by the digital signature of the
owner, which authenticates the transaction and safeguards it from tampering. Hence,
the information the digital ledger contains is highly secure. In simpler words, the
digital ledger is like a Google spreadsheet shared among numerous computers in a
network, in which the transactional records are stored based on actual purchases. The
fascinating angle is that anybody can see the data, but they can’t corrupt it.

Fig 1.3.1 :-Internet of Things

3
 we focus mainly on developing and managing the trust among various
nodes while having a smooth interaction without human intervention. We provide a
trust mechanism that offers reliability, confidentiality, and integrity to nodes in the
system. Therefore, these nodes can securely interact with each other to exchange data.
To provide the fundamentals of trust and the technique used in the FTM-IoMT, we
have defined some concepts and related terms to the proposed mechanism. Term
definitions are given in the following subsections. It can reduce the risks and increase
the predictability of the system that helps the IoMT infrastructure to operate better and
abstain from malicious nodes and service failures. Due to its property of decentralised
trust and immutability, blockchain has the potential of providing foolproof security for
IoTs specially in the healthcare environment .

The healthcare devices are service critical that record sensitive patient data for smart
diagnosis, AI driven disease profiling, vitals management etc. Any services without a
central server, third party reliance and avoiding password-based security mechanisms.
Malfunctioning within the IoT devices can lead to severe consequences, for instance,
a smart ventilator machine’s failure can be instantly fatal for an ICU patient. Recently
a vulnerability was discovered in GE Aestiva and Aespire anaesthesia devices that
allowed a hacker to bypass the authentication mechanisms and manipulate the drug
levels causing serious health injuries to patients which could be fatal In the research
proceeding, we focus mainly on developing and managing the trust among various
nodes while having a smooth interaction without human intervention.

We provide a trust mechanism that offers reliability, confidentiality, and integrity to

nodes in the system. Therefore, these nodes can securely interact with each other to
exchange data. To provide the fundamentals of trust and the technique used in the
FTM-IoMT, we have defined some concepts and related terms to the proposed
mechanism. Term definitions are given in the following sub sections. It can reduce the
risks and increase the predictability of the system that helps the IoMT infrastructure to
operate better and abstain from malicious nodes and service.

4
2. EXISTING SYSTEM

• Internet of Things (IoT) is a system of interconnected devices that have the

ability to monitor and transfer data to peers without human intervention.

• Authentication, Authorization and Audit Logs (AAA) are prime features of

Network Security and easily attained in legacy systems, however, remains unachieved
in IoT.

Fig 2.1:-AAA Services in legacy systems

The IoTs require due security considerations as the conventional legacy systems are
mostly centralised and thus introduce a ssecurity mechanisms are not optimised for
such devices due to various aspects such as heterogeneity, resource constrained
processing, storage and multiple factors. Additionally, the single point of failure
Internet of Things (IoT) is System of interconnected devices, mechanical and digital
machines , objects , animals or people that are provided with unique identifiers and

5
ability to transfer data over the network without requiring human-to-human and
human-to-computer interconnection. The ‘thing’ in IoT could be a person with a heart
monitor or an automobile with built-in-sensors, i.e. objects that have been assigned an
IP address and have the ability to collect and transfer data over a network without
manual assistance or intervention.

Fig 2.2.:- Network Security

❖ SANS Institute defines Network Security as the preventative measures taken to

safeguard network infrastructure from unauthorised access, modification,
malfunction, misuse, improper disclosure or destruction of data.

❖ Internet commerce is exclusively tied to the financial institutions serving as the

trusted third party who process and mediate any electronic transaction. The role of
a trusted third party is to validate, safeguard and preserve transactions. A certain
percentage of fraud is unavoidable in online transactions and that needs mediation
by financial transactions. The role of a trusted third party is to validate, safeguard
and preserve transactions. A certain percentage of fraud is unavoidable in online
transactions and that needs mediation by financial transactions. The role of a trusted
third party is to validate, safeguard and preserve transactions. A certain percentage
of fraud is unavoidable in online transactions and that needs mediation by financial
transactions.

6
 Fig 2.3. :- Data & Security

Data privacy generally means the ability of a person to determine for themselves when,
how, and to what extent personal information about them is shared with or
communicated to others. This personal information can be one's name, location,
contact information, or online or real-world behaviour. The terms data protection and
data privacy are often used interchangeably, but there is an important difference
between the two. Data privacy defines who has access to data, while data protection
provides tools and policies to actually restrict access to the data. Compliance
regulations help ensure that user’s privacy requests are carried out by companies, and
companies are responsible to take measures to protect private user data.

• Data protection and privacy is typically applied to personal health information

• (PHI) and personally identifiable information (PII). It plays a vital role in

business operations, development, and finances. By protecting data, companies
can prevent data breaches, damage to reputation, and can better meet regulatory
requirements.

• Data protection solutions rely on technologies such as data loss prevention

(DLP), storage with built-in data protection, firewalls, encryption, and endpoint
protection. Data protection is a set of strategies and processes you can use to

7
 secure the privacy, availability, and integrity of your data. It is sometimes also
called data security.

• A data protection strategy is vital for any organisation that collects, handles, or
stores sensitive data. A successful strategy can help prevent data loss, theft, or
corruption and can help minimise damage caused in the event of a breach or
disaster.

• Data protection principles help protect data and make it available under any
circumstances. It covers operational data backup and business
continuity/disaster recovery (BCDR) and involves implementing aspects of
data management and data availability. Here are key data management aspects
relevant to data protection:

Data availability—ensuring users can access and use the data required to
perfor business even when this data is lost or damaged. Data.Lifecycle management
involves automating the perfor business. Information lifecycle management—involves
the valuation, 16 cataloguing, and protection of information assets from various
sources, including facility outages and disruptions, application and user errors,
machine failure, and malware and virus attacks.

2.1. Data Protection vs Data Privacy

Although both data protection and privacy are important and the two often come
together, these terms do not represent the same thing. One addresses policies, the other
mechanisms Data privacy is focused on defining who has access to data while data
protection focuses on applying those restrictions. Data privacy defines the policies that
data protection tools and processes employ.

8
3. PROPOSED SYSTEM
The proposed scheme is based on Hyperledger Fabric and Fuzzy logic. This section
explains the preliminaries for the understanding of Adaptive Security Framework.
Each term is explained briefly below:

3.1. BLOCKCHAIN ELEMENTS

The entities involved in Blockchain and their associated terminologies are

discussed below:

3.1.1. Client

Clients are the end users which are not directly involved in blockchain process but the
main entities involved in transactions In our case SP (Service Provider) and RE
(Requesting Entities) are clients in our case and they interact with blockchain through
Anchor peers which in case of SP is a gateway and in case of RE the device itself can
also be designated as a peer (Doctor, Nursing Staff, Administrator). The client is also
registered to the blockchain network, therefore he has a particular identity and
certificate issued by the CA. The clients submit their transactions to blockchain
through anchor peer and once a transaction is successful are responded by the same.
The client is also registered to the blockchain network, therefore he has a particular
identity and certificate issued by the CA. The clients once a transaction is successful
are responded by the same. Anchor peers which in case of SP is a gateway and in case
of RE the device itself can also be designated as a peer (Doctor, Nursing Staff,
Administrator). The client is also registered to the blockchain network, therefore he
has a particular identity and certificate issued by ca The clients submit their
transactions to blockchain through anchor peer and once a transaction is successful are
responded by the same. The client is also registered to the blockchain network,
therefore he has a particular identity and certificate.

9
 Fig 3.1.1:-Client

3.1.2 Anchor Peer

It is an entity which directly interacts with blockchain. It can be RE themselves or a
gateway in case of IoTs. It is an SDK client who submits actual transaction-invocation
to the endorsers and broadcasts transaction proposals to the ordering service.

Fig 3.2:-Anchor Peer

3.1.3. Peers
Peers are the nodes which are an active part of the blockchain network and they
perform one or many roles in the blockchain. These are the nodes which are responsible
for maintaining the ledger. Following are the types of peers in our blockchain

10
 Fig 3.3.:-Peers

Endorser
Endorser or endorsing peer is the one which simulates the transaction by running the
chaincodes (smart contracts in Hyperledger) related to a particular transaction before
it is committed to a block. Every chaincode specifies an endorsement policy which
defines all the necessary conditions for a transaction to be termed as valid.
Furthermore, the endorsers compare the generated Read Write (RW) sets with existing
ones in the ledger and validate individually. Every endorser verifies all the signatures
and identities associated with a transaction and each endorser forwards the signed
transaction to the anchor peer now called ‘‘Endorsed Transaction’’.

Fig 3.4.:- Endorser

11
Committing Peer
It is the peer specified or specified by the ordering service and initiates the
gossip protocol for ledger update by other peers of the channel. This peer can be elected
through consensus or may be assigned a specific role.

Fig 3.5.:-Committing peer

Ordering Service
Ordering service provides the communication channel to all the participants of
blockchain and guarantees deliveries. Ordering service can be implemented in a variety
of ways using different node fault models. It provides connectivity between clients and
peers through channels. Clients broadcast their transaction requests which are
broadcast to all peers. The channel supports atomic delivery of all messages.

Fig 3.6.:- Ordering Service

12
3.1.4. Channel
A channel is a mechanism for managing communication between entities participating
in the blockchain network. Channel logically behaves like a LAN where all the data
and transactions are private within the channel and no data is shared with outside peers.
In the healthcare environment data privacy is of utmost importance, therefore, each
department has a separate channel and a device or entity can be part of more than one
channel. For example, if a doctor has his duty in the medical department but also
performs duties in the Emergency ward, in that case he will have two separate datasets
for each channel, however his same identity will work across both channels. When a
new channel is created, a genesis block is formed which stores the configuration
information about the channel policies, members and anchor peers. When a new
member is added to an existing channel either the genesis block or a more recent
reconfiguration block, is shared with the new member.

A leading peer is also elected, which is the one which has the responsibility to
determine which peer communicates with the ordering service on behalf of the
member. If no leader has been designated, then a leader is chosen through
consensus..The ordering service orders transactions and delivers them to each leading
peer in the form of a block, which then distributes the block to its member peers, across
the channel, using the gossip protocol. The propagation of data includes transaction
information, ledger state and channel membership, and is restricted to only those peers
which have verifiable membership for the channel

Fig 3.7.:-Channel

13
3.1.5. Ledger
Ledger provides verifiable history of all successful and unsuccessful transactions
occurring over the blockchain. Ordering service is responsible for construction of
ledger by maintaining ordered hash chain of blocks of transactions. Hashchain imposes
the total selected by the Blockchain to commit the transaction to the Blockchain
network. The Leading peer as discussed above is usually the committing peer. This
peer commits the transaction to the block as order of blocks in a ledger, where each
block is an array of totally ordered transactions which formulates an entirely ordered
blockchain. All peers have ledgers and optionally orderer can also have a ledger which
is called ‘‘Order Ledger’’. All other peers have peer ledgers and they can replay the
history of transactions to update or reconstruct the ledger state.

Fig 3.8.:- Ledger

3.2. IDENTITY MANAGEMENT

Identity is an integral part of any IT system; it aids in mapping various actors in an
organisation to their roles in the system. These actors then verify their identity through
authentication mechanisms and are authorised to perform certain actions allowed by
the system. Without centralised identity management, it is a challenge for IT
professionals to manage authentication and authorization across a wide range of
devices. X.509 certificates in Hyperledger Fabric are responsible for provision of
detailed identity which is verifiable by the system administrators. In our blockchain-
based frame work two entities play vital role in identity management that are as
follows:

14
3.2.1. CERTIFICATE AUTHORITY (CA)
A Certificate Authority is an entity responsible to dispense certificates to various actors
in a network. These certificates bind the public key of the principal with various
associated attributes and are digitally signed by the CA. Consequently, if CA is a
trusted entity and its public key is known, then one can trust the specific principal as
he is having a valid certificate, and owns the included attributes and public key, by
validating the CA’s signature on the principal’s certificate. Three kinds of certificates
are issued: enrollment certificate, transaction certificate and TLS certificate. CA can
be of various types as shown in figure 1 e.g., Root CA, Department CA and local CA.
If an entity, for instance, a patient is issued an identity by Root CA his identity will be
available in every department. A Certificate Authority is an entity responsible to
dispense certificates to various actors in a network. These certificates bind the public
key of the principal with various associated attributes and are digitally signed by the
CA. his identity will be available in every department. A Certificate Authority is an
entity responsible to dispense certificates to various actors in a network. CA role
includes:

i)Registration of Identities
ii)Issuance of Certificates
iii)Certificate Renewal and Revocation

Fig 3.9. :-CA hierarchy

15
3.2.2. MEMBERSHIP SERVICE PROVIDER

Once an Identity is issued it must be verifiable. For this purpose, we require another
entity known as MSP (Membership Service Provider). Trust has been further
distributed in Realiable Modelling of Hazy Medicalcare Using Blockchain and IoT by
delegating the responsibility of verification to MSP instead of CA. MSP is also
responsible for managing identities once they have been created by the CA. The MSP
can also be deployed at any level and depends on the network size and security
requirements. A device itself can have an isolated MSP running within which it can
verify signatures belonging to other actors of the network. If the network is large,
several MSPs can be set up. For example, a channel MSP is responsible for verification
of all transactions occurring on that channel.

3.2.3. AUTHENTICATION FIS

The last function is Access control function. In this function the Trust and
Authentication linguistic values of previous functions is taken as input and Access
Control is given as an output as shown in figure 10. The Access Rights are
linguistically defined as {φ, Read, Read/Write, Read/Write/execute} and their
membership functions are shown in figure 11. The authentication input provides a
fresh behavior input of RE whereas the Trust function provides a feedback-based input
and this way the access control is adjusted according to device behavior. For example,
if trust is low and the device had authenticated through biometrics the output is No
Access as shown in figurre. three main Fuzzy Inference Systems.

(FIS)are used and their designs and logic are discussed in this section for understanding
of the architecture. The authentication mechanism is designed to achieve adaptivity
through risk assessment based on parameters usually available in the network packets
such as HTTP header. There will always initiate a transaction request in relation to the
context of healthcare. Thus, all transactions must contain a patient's ID along with RE
and SP ID. We define a Mamdani FIS for our authentication system as shown in figure.

16
 Fig 3.10.:- Authentication FIS

The parameters for our framework are IP address, MAC address, time of day,
Operating System and location. These parameters will be analysed in conjunction with
the history of transactions maintained by blockchain. Each parameter will be analysed
separately and frequency distribution for that particular parameter will be calculated.
This frequency distribution is normalised to get the membership functions for each
fuzzy set associated with the parameter

Fig 3.11. :- Membership functions of each device parameter is along the y-axis and
threshold value of each linguistic variable is along the x-axis.

17
3.2.4. TRUST EVALUATION FIS
The purpose of this function is to provide trust feedback based on previous transactions
as
input to the fuzzy logic of authorization transactions. The trust feedback along with
authentication provides sufficient proof for fuzzy logic to apply rules to assign the type
of access privileges the RE can have. The RE request is mapped to a particular access
right permission set accordingly with the trust feedback score. Trust of a device
constitutes of three main elements

Experience:

The transaction experience which is dependent on the previous transactions between

RE and SP. The experience REESP is calculated by eq (1) RESEP = 0 if P n = 0 n P
t=1 Et n t=1 |Et | if n 6= 0 (1) Here, range of REESP ∈[-1,1]. Et is +1 for successful
transactions and -1 for unsuccessful transactions. The membership functions and fuzzy
sets of REPS are shown in figure .
Knowledge:
kd is calculated in each transaction and if Kd provided by RE is different from the one
generated by SP then -1 or else 1 is given as value of Kd and aggregate value of KSP
is given by eq (2) REKSP = 0 P if n = 0 n P t=1 Kt n t=1 |Kt | if n 6= 0 (2) In eq 2
RECAP ∈[-1,1] and denotes the knowledge of RE with respect to SP. The membership
functions and fuzzy sets for REKSP are shown in figure

Fig 3.12. :-. FIS rules viewer.

18
 Fig 3.13. :-Membership function of authentication output

Fig 3.14. :- Membership functions of RE ESP

Fig 3.15. :-. Membership functions of REKSP .

Reputation:
The last is the Reputation calculated by blockchain based on the
experiences of all devices with pretext to RE. In this case the context is RE, thus
reputation is given by eq (3) RRE = Pn t=1 Esp P t n t=1 |Esp|t In eq 3 RRE ∈[-1,1]
and denotes the experience

19
 Fig 3.16. :-Membership functions of RRE .

Fig 3.17. :-Membership functions of Output ‘Trust’.

3.2.5. ACCESS CONTROL FIS

The last function is Access control function. In this function the Trust and
Authentication linguistic values of previous functions are taken as input and Access
Control is given as an output as shown in figure 10. The Access Rights are
linguistically defined as {φ, Read, Read/Write, Read/Write/execute} and their
membership functions are shown in figure 11. The authentication input provides a
fresh behaviour input of RE whereas the Trust function provides a feedback-based
input and this way the access control is adjusted according to device behaviour. For
example, if trust is low and the device has been authenticated

20
 Fig 3.18. :-Access control FIS.

Fig 3.19.: -Membership functions of output ‘access right’

Fig 3.20.:-. Rule viewer - access rights.

21
4. SECURITY FRAMEWORK

FBASHI-ADAPTIVE SECURITY FRAMEWORK

Hospital is the core organisation for testing and implementation of our framework.
Hyperledger channels are deployed at departmental level and are part of the main chain
run at Hospital level. Similarly, hospitals can be part of a consortium thus forming part
of a bigger blockchain. This way the network is layered in nature and scalable as well.
This point onwards,it is highly unlikely that a device is moved temporarily from one
department to another and if such is the case the device will be re-registered in the new
department..

Fig 4.1. :-Bird eye view of Medical department

4.1. TRANSACTION FLOW IN BLOCKCHAIN

To understand the transaction flow in semantic way a toy scenario is considered where
a doctor wants to get ECG readings of a patient from an ECG machine which we call
SPECG and the doctor is RED (Requesting Entity) in this case. The doctor can be
serving in multiple departments in a hospital, for example a heart specialist will have
emergency duty in the Medical Emergency department, thus in order to carry out the
transaction in focus which is in the medical department he has to interact with
blockchain using the id associated with this department. In the healthcare environment
patient’s privacy is primary

22
and is catered for by adding patient as context in every transaction. The transaction
flow in Hyperledger is shown in figure 14 and each phase of the transaction is
discussed below:

1) The RED initiates a request access transaction by sending transaction parameters

using the blockchain protocol of Hyperledger. The clients are connected through
anchor peers as already discussed. In this case the RED itself is an anchor peer and can
initiate transactions. The transaction packet contains following parameters TA =
{IDRE || IDP||IDSP||Access Type||NonceSP}.

Fig 4.2. :-Hyperledger transaction flow

2) The transaction parameters are verified by the Endorsing peers, in each case
depending on the group of devices interacting. A set of Endorsing peers are nominated
and these can be assigned weights or can use any pluggable consensus algorithm
supported by Hyperledger fabric. The Endorsing peers simulate the read, write set of
transaction meaning, they simulate the chaincodes and verify the inputs and outputs.

3)After the successful run of chaincode, endorsed peers send back endorsed
transactions (including their signatures) to Anchor peer.
4)The Anchor peer forwards the endorsed transaction to Orderer who verifies the
Endorsed transaction. All the validations of transactions involve a local MSP running
within each peer as a separate module and it is responsible for verifying all the
signatures of every transaction.

23
5) The Orderer after verifications assigns a block number to the transaction TR and
initiates gossip protocol.

4.2. TRANSACTION LOGIC

The main driving force of our adaptive security mechanism is the chaincode part of the
transaction. Here we try to utilise the computational power and rich features of
chaincode for maximum benefit of driving security in a distributed fashion. In order to
work efficiently the framework requires at least 50 transactions data stored on
blockchain.
Algorithm 1 Authentication

1: inferences = { {1, 1, 1, 1}, {1, 1, 1, 2}, {1, 1, 1, 3}, {1, 1, 2, 1}, {1, 1,
2, 2}, {1, 1, 2, 3}, };
2:function Authentication(crisp_input)
3:calculate AuthenticationAccess(crisp_input);
4: EndFunction
5:FunctioncalculateAuthenticationAccess(crisp_input)
6:output=fuzzyLogicResult(crisp_input,EntityIP,EntityMac,Entit
y System,EntityLocation,EntityOutputRequest, inferences);
7:RETURN output;
8: EndFunction.

Algorithm 2 Trust

1: inferences = { {1, 1, 1}, {1, 1, 2}, {1, 1, 3}, {1, 2, 1}, {1, 2, 2}, {1, 2,
3} };
2: FunctionTrust(crisp_input)
3:calculateTrustAccess(crisp_input);
4: EndFunction
5:FunctioncalculateTrustAccess(crisp_input)
6:output=fuzzyLogicResult(crisp_input,EntityEx,EntityKn,EntityRp,EntityOutputRe
quest, inferences);
7: RETURN output;
8: EndFunction. trust FIS and algorithm 3 sets out the access control FIS implemented
on Hyperledger F

24
5. SECURITY ANALYSIS
5.1. Security Analysis
The framework was designed in MATLAB and tested for different use cases. The
parameters were chosen at random to validate concept and analyse outputs of each
function. The surface view in figure 16 shows the input/output domain of Ip Address
and Mac Address. The frequency distribution of both inputs is directly proportional to
the Authentication mechanism in use. The MATLAB tested logic was then applied to
Hyperledger fabric for function validity. The architecture is validated and as the
number of transactions increases the Fuzzy Output gives more precise results. The
system was found scalable as every device communicates on channel basis and
transaction throughput is 10000 transactions per sec for Hyperledger Fabric. The threat
model is presented:

5.1.1. Attackers
whether insider or outsider mostly interact with the system as a user. In healthcare
monitoring systems the attacker can be an insider compromising EHR and selling them
on black market or it can be an outsider with ill intentions to malign hospital reputation
by disturbing the working mechanisms of medical devices. As recently, a vulnerability
was found in authentication of Anaesthesia devices of GE Aestiva and Aespire

Fig 5.1. :-Chaincode logic.

25
Algorithm 3 Access Logic

1: Function takeMaxOfArray(arr)
2: max ← a[0];
3: For j ← 1 to arr.length
4: If arr[j] > max
5: max ← arr[j];
6: Else
7: max ← max;
8:EndIf
9:EndFor
10:EndFunction
11:FunctioncalculateTrustAccess(crisp_input)
12: output ← fuzzyLogicResult(crisp_inputEntityEx, EntityKn,
EntityRp,EntityOutputRequest, inferences);
13:RETURN output;
14: EndFunction
15: FunctiontakeMaxOfArraySetset
16: For i ← set.length − 1 to 0
17: output[i] ← takeMaxOfArray(set[i]);
18: EndFor
19: EndFunction

Fig 5.2. :-Surface view- authentication with two input variables.

26
5.1.2. Assets
Hospitals provide healthcare services which are life critical and thus any
system or device dealing with any sort of healthcare data is treated as an asset. The
data is collected from sensors, synthesised by special servers into intelligent
information which can be translated to the patient’s health records for analysis and
treatment by Caregivers. This data is then stored on hospital databases or integrated
with cloud services for interoperability between various medical organisations,
government and services like insurance. The following assets evolve through the
proposed hospital monitoring system:
a)Medical IoTs
b)Caregivers
c)Patients Health records
d)Gateways, database servers involved in computations

5.1.3. Threats
Healthcare faces more imminent threats because of the high value of patient
information in black market and large volume of sensitive data easily available as least
importance is given to cyber security in healthcare. Protection against cyber threats in
compliance with HIPAA can be challenging and any oversights could easily cost a
breach or regulatory fine. Following are the threats identified in the healthcare
environment which are required to be mitigated by our suggested solution:
1)Unauthorized access to medical sensors and devices.
2)Tempering of recorded patient data.
3)Corruption of data by collisions of peers.
4)Leakage of information between various tiers (hospital, cloud servicesand other
organisations).
5)Accidental or deliberate loss of data by caregivers.
6)Unauthorised access to medical data by users in contrast to assignedroles and
responsibilities.
7)Manipulation of activities and audit logs.

5.1.4. Mitigation Strategies

Table 1 enumerates the mitigation strategies against most common threats achieved
through our framework to achieve security objectives for IoTs in healthcare.
27
5.2. Fuzzy Logic
Lotfi Zadeh, the founder of fuzzy logic, introduced the concept of Fuzzy Logic in the
1960s . Fuzzy logic works on fuzzy sets where fuzzy sets consist of group elements
that have the degree of membership value towards each element of the set. Fuzzy logic
is based on human reasoning and has some values, such as On/Off, True/False,
Good/Bad, and 0 and 1. Fuzzy logic plays a significant role to handle the values
between true/false, such as ”partially true and partially false values” . It takes the values
in the ranges of true, mostly true, half true, kind of true, false, etc. Fuzzy logic provides
facilities to computer systems and makes them able to think like a human in order to
make decisions in real life scenarios generically, fuzzy logic is a mapping between
input values and output values of a fuzzy system,which includes vector as input and
scalar as output values.
In real life applications, under some circumstances, fuzzy logic plays a vital role in
decision making that is difficult to make with traditional or classical theory. For
example, in traffic management, it is very difficult to handle overloaded traffic on the
highways. With the emergence of fuzzy logic, it is much easy to justify the alignment
of traffic on roads by mapping input variables with output variables, i.e., traffic flow,
road condition, weather condition, and many other variables it is much easy to justify
the alignment of traffic on roads by mapping input variables with output variables, i.e.,
traffic flow, road condition, weather condition, and many other variables.

5.3. Archietecture of FIS

FIS is the abbreviation of Fuzzy Inference System that is a linear mapping of input
values to the output values. FIS consists of membership functions, fuzzy operators, and
if-then rules.

28
5.3. Archietecture of FIS
FIS is the abbreviation of Fuzzy Inference System that is a linear mapping of input
values to the output values. FIS consists of membership functions, fuzzy operators, and
if-then rules. A complete suite of standard FIS is depicted in Figure 1.

5.3.1. Fuzzification
It is a procedure to gather crisp inputs and convert them into fuzzy inputs, by applying
fuzzy linguistic terms and membership functions. In the fuzzification process, a crisp
set is input and the fuzzy set is output.

5.3.2. Defuzzification
Defuzzification is the opposite process to fuzzification. It converts the fuzzy output
into
crisp output using the degree of its membership functions. In the process of
defuzzification, a fuzzy set is input and
crisp set is output of the process.

Fig 5.3. :-Elements of Fuzzy Inference System

Fig 5.4. :- Processing of the Model

29
5.3.3. Inference Engine
Inference engine provides a control to convert fuzzy input into fuzzy output
using if-then fuzzy rules . Basically, it is a fuzzy controller through which the fuzzy
process takes actions on the basis of some rules by converting crisp input to fuzzy
input or fuzzy output to crisp output using fuzzification and defuzzification
respectively.

5.3.4. Knowledge base

It is the combination of the rule base and the database. It defines a sequence of fuzzy
rules having format of if-then, and the associated membership functions used in the
fuzzy rules.

5.4. The working of proposed system

To manage trust between the server and the requesting node, the trust value is
computed using fuzzy logic processing, where fuzzy rules are applied on each
requesting node. Moreover, af ter fuzzy logic processing based on predefined trust
attributes, the server gets a final trust value of the requesting node. On the basis of final
trust value, the server decides either to provide services or to neglect the node. A
threshold TH value has also been set to eliminate malicious nodes. A fuzzy filter is
introduced in the FTM-IoMT, which consists of two algorithms with predefined
threshold values.The fuzzy filter evaluates the final trust value a second time by
comparing it with the predefined threshold value. The TH value may be dynamic,
which changes as per request for services. For highly sensitive devices, the threshold
value is higher, while for low sensitive devices, the threshold value is low.

Fig 5.5. :-Medical Department

30
is why? The straight answer is lack of monitoring patients. Tackling an emergency is
still a challenge. Remote patient monitoring can be possible with the collaboration of
IoT. Wearable devices with embedded sensors can monitor patient condition day long
and can notify the doctor. Wearable devices with embedded sensors can monitor
patient condition day long and can notify the doctor.

5.5. IoT in Healthcare: Interoperability

Fig 5.6. :-IoT in Healthcare

Different healthcare organizations started collecting a massive amount of data
produced by IoT devices. Collecting those data, IBM Watson and Teva began a new
IoT project that will be responsible for creating new methods of treatment and
prediction of chronic disease. Healthcare organizations use artificial intelligence and
natural language processing to organize this data. It’s a perfect example of data science
or big data in the healthcare system.

5.5.1. Insights of this application

Well, organized data will start a new era of forward-thinking technology. Historical
data will help doctors to find out the exact need of the patient. An IoT device sends
and receives data via cloud storage. As a result, the same data can be reachable by
multiple devices that are actually impossible with the current system.Data management
by IoT technology leads to better patient care. Each hospital management system could
be a research sector for

31
data science.Transaction latency depends on the transaction size. It is clear from the
figure that the Number of Transactions throughput of the system increases with the
time, which means that the throughput of the proposed model for Blockchain depends
on the number of transactions and frequency. Read latency is the time required to fetch
results and display them on the application interface.For analysis, initially, the read
latency for 100 transactions is recorded and then extrapolated to500 transactions.
The read latency and read throughput analysis for 500
transactions,respectively. The trend in the graph shows that the number of transactions
increases with time in seconds. With the increase in the number of transactions, the
time required to read data from each block also increases, and hence it generates the
linear curve.

Fig 5.7. :- Read latency analysis for 500 transactions in the Blockchain.

Fig 5.8. :-Read throughput analysis for 500 transactions in the Blockchain.

32
Transaction latency is the time required to confirm a transaction. It can be calculated
by subtracting the confirmation time from the submission time. Transaction latency
depends on the size of a transaction.Moreover, an increase in the size of a transaction
consumes more power and hencecauses more latency.Figures present results for
transaction latency and throughput analysis for 500 transactions,respectively.
Transaction latency depends on the transaction size. It is clear from the figure that the
throughput of the system increases with the time, which means that the throughput of
the proposed model for Blockchain depends on the number of transactions and
frequency.

Fig 5.9. :-Transaction latency analysis for 500 transactions in the Blockchain.

Fig 5.10. :-Throughput analysis for 500 transactions in the Blockchain

The general IoT healthcare model comprises of a device, cloud, and client layers. The
device layer comprises of several internet-enabled sensor nodes. Data acquisition and
communication protocols are used to send the data to storage for further analytics.
33
6. COMPARITIVE ANALYSIS
The main objective of our framework is to achieve adaptive security based on
user behaviour without depending on traditional security mechanisms like passwords
and tokens. Moreover, centralised architecture presents a single point of failure and
thus vulnerable to many attacks like DOS attacks, ransomware attacks etc. Most of the
research work in this domain relies on central architecture and very few have utilised
the true potential of blockchain technology. Furthermore, most of the work relies on a
single authentication mechanism which may be subverted by the adversaries thus our
system adapts by applying second factor authentication based on users’ attributes and
behaviour. Table 2 shows comparative analysis of our framework with existing
solutions.

6.1. USABILITY AND COMPARISONS WITH OTHER

BLOCKCHAINS
The permissionless or public blockchains face various challenges regarding
performance parameters. The public blockchains like Bitcoin and Ethereum are mostly
based on PoW consensus which is resource intensive involving high latency in order
to achieve security. Some of the public blockchains like Litecoin have reduced block
formation time of 2.5 minutes as compared to 10 minutes of Bitcoin. Consequently,
Litecoin uses a smaller number of hashes to verify the block as compared to Bitcoin.
This problem is absent in Hyperledger because the consensus is achieved through
PBFT (Practical Byzantine Fault Tolerance) depending on predefined endorsers and
trust is anchored by the governing body.
Thus, virtually there is no deliberate latency for achieving security and the
block is formed as soon being verified by the endorsers. The security and performance
can be achieved in a similar manner as in traditional networks by limiting the channel
users to the concerned parties as the concept of VLANs in traditional networks. This
enables privacy and scalability at the same time by segregating different parts of
networks from each other. Therefore, FBASHI was implemented on Hyperledger
blockchain to ascertain the practical feasibility in comparison to existing state of the
art and other blockchain based solutions. The performance is evaluated and compared
to other blockchains.

34
6.1.1. LATENCY
Transaction latency is the time transaction takes starting from the point it is submitted
to the network to the point it is committed by all peers to the ledger. Hence the
performance and throughput somehow rely on this parameter. Latency is the pivot
point for the performance of Hyperledger Fabric. As the blocksize increases the latency
reduces because Orderer has fewer transactions in the backlog when the transaction
rate is high. But as the smaller block size is suitable for lower transaction rates but as
in our case the higher block size is much more suitable to achieve high tps. Thus,
blocksize is a major tweaking parameter while configuring Hyperledger Fabric as per
the application’s demand.Thus, blocksize is a major tweaking parameter while
configuring Hyperledger Fabric as per the application’s demand, configuring
Hyperledger Fabric as per the application’s demand.

Fig 6.1. :-Transaction latency with varying block size of hyperledger fabric.

6.1.2. THROUGHPUT
Transaction throughput is the amount of time a valid transaction takes to get committed
to the blockchain. Many researchers and blockchain benchmarking sites use
throughput as the main performance parameter for Blockchain which is not true. The
throughput of public blockchains are inadequate and one of the root causes behind lack
of its adoption in modern banking systems where required throughput is somewhat
around 2000 tps on Hyperledger Fabric having better consensus algorithms and
segregation of power between different nodes based upon organisational
35
parameters.Consensus in Hyperledger Fabric is directly linked to endorsers, thus
impacting the throughput. As we increase the number of endorsing peers it takes more
time for a transaction to get committed to the blockchain after due endorsement of each
endorser. The performance can further degrade if we use endorsers from multiple
medical departments. This is the reason behind configuring a separate channel on
departmental basis and load balancing endorsement to achieve max performance for
proposed architecture. Clearly shows as we increase the number of endorsers the
throughput in terms of tps will increase but this is only valid when there is load
balancing between endorsers and they are not from multiple organisations. We achieve
this linearity by limiting the endorsers to departmental level thus reducing the lag. This
can get worse if all endorsers are included for the same task resulting in saturation,
consuming all the available CPU resources allocated to the container.

Table 6.1. :-Mitigation strategies.

36
 Table 6.2. Comparison of proposed framework with existing solutions

Fig 6.2.:-Impact of endorsers on transaction rate of hyperledger fabric

after due endorsement of each endorser. The performance can further degrade
if we use endorsers from multiple medical departments. This is the reason behind
configuring a separate channel on departmental basis and load balancing endorsement
to achieve max performance for proposed architecture. Clearly shows as we increase
the number of endorsers the throughput in terms of will increase but this is only valid
when their is load balancing between endorsers and they are not from multiple
organizations.

37
7. CONCLUSION AND FUTURE WORK

Over a period of time the device behaviour must remain consistent and a user using
a system in a hospital is most likely to use the same machine with the same IP, location
and device. Thus, this behaviour must fall within a specific range. This research
normalises device behaviour through FIS using Hyperledger Fabric to achieve
distributed trust, fuzziness and removing single point of failure from AAA services.
Patient endorsement through OTP improves security and privacy sufficing HIPAA and
GDPR compliance as the patient must be in full control of his data. Our framework
successfully detects malicious behaviour and thwarts various types of threats against
IoT in healthcare. In future, we intend to explore the AI capability of blockchain by
including more parameters and expanding this framework to other parts of the network
for foolproof security.

38
8. REFERENCES
[1] F. Paul. (Mar. 28, 2018). Network World. Accessed: Dec. 25, 2021. [Online].
Available:
https://www.networkworld.com/article/3267065/people-are-really-worri e d-about-
iot-data-privacy-andsecurityand-they-should-be.html#new-fsb
[2] F. Paul. (Jan. 14, 2019). Network World. Accessed: Dec. 29, 2021.[Online].
Available: https://www.networkworld.com/article/3332032/top10-iot-vulnerabilities
.html
[3] F. Dai, Y. Shi, N. Meng, L. Wei, and Z. Ye, ‘‘From bitcoin to cybersecurity: A
comparative study of blockchain application and security issues,’’ in Proc. 4th Int.
Conf. Syst. Informat. (ICSAI), Nov.2017, pp. 975–979.
[4] Journal, HIPAA. (Jul. 10, 2019). HIPAA JOURNAL. Accessed: Aug.1, 2021.
[Online].Available:https://www.hipaajournal.com/vulnerability-identified-in-ge-
aestiva-and aespire-anesthesia-machines/
[5] HIPAA. (2018). HIPAA Guide. Accessed: Aug. 1, 2021. [Online].Available:
https://www.hipaaguide.net/hipaa-for-dummies/

[6] HIPAA. (2018). HIPAA Guide. Accessed: Aug. 1, 2021. [Online]. Available:
https://www.hipaaguide.net/gdpr-for-dummies/

[7] J.-L. Hou and K.-H. Yeh, ‘‘Novel authentication schemes for IoT based
Healthcare systems,’’ Int. J. Distrib. Sensor Netw., vol. 2015, pp. 1–9, Nov. 2015.
[8] G. Manogaran, R. Varatharajan, D. Lopez, P. M. Kumar, R. Sundarasekar, and
C. Thota, ‘‘A new architecture of Internet of Things and big data ecosystem for secured
smart healthcare monitoring and alerting systems,’’ Future Gener. Comput. Syst., vol.
82, pp. 375–387, May 2018.
[9] Q. Jiang, J. Ma, C. Yang, X. Ma, J. Shen, and A. C. Shehzad,‘‘Efficient end-to-
end authentication protocol for wearable health monitoring systems,’’ Comput. Elect.
Eng., vol. 63, pp. 182–195, Oct. 2017.

39
[10] R. Amin, S. H. Islam, G. P. Biswas, M. K. Khan, and N. Kumar, ‘‘A robust and
anonymous patient monitoring system using wireless medical sensor networks,’’
Future Gener. Comput. Syst., vol. 80, pp. 483–495, Mar. 2018.
[11] M. A. Ferrag, L. A. Maglaras, H. Janicke, J. Jiang, and L. Shu, ‘‘Authentication
protocols for Internet of Things: A comprehensive survey,’’ Secur. Commun. Netw.,
vol. 2017, pp. 1–41, Nov. 2017.
[12] D. Rivera, L. Cruz-Piris, G. Lopez-Civera, E. de la Hoz, and I. Marsa-Maestre,
‘‘Applying an unified access control for IoT-based intelligent agent systems,’’ in Proc.
IEEE 8th Int. Conf. Service-Oriented Comput. Appl. (SOCA), Oct. 2015.

[13] H. Ning, H. Liu, and L. T. Yang, ‘‘Aggregated-proof based hierarchical

authentication scheme for the Internet of Things,’’ IEEE Trans. Parallel Distrib. Syst.,
vol. 26, no. 3, pp. 657–667, Mar. 2015.

[14] A. Singh and K. Chatterjee, ‘‘A secure multi-tier authentication scheme in cloud
computing environment,’’ in Proc. Int. Conf. Circuits, Power Comput. Technol.
(ICCPCT), Mar. 2015, pp. 1–7.

[15] C. Hu, J. Zhang, and Q. Wen, ‘‘An identity-based personal location system with
protected privacy in IoT,’’ in Proc. 4th IEEE Int. Conf. Broadband Network.
Multimedia Technol., Oct. 2011, pp. 192–195.

[16] J. H. Yang and P. Y. Lin, ‘‘An ID-based user authentication scheme for cloud
computing,’’ in Proc. 10th Int. Conf. Intell. Inf. Hiding Multimedia Signal Process.,
Aug. 2014, pp. 98–101.
[17] C. Lai, H. Li, X. Liang, R. Lu, K. Zhang, and X. Shen, ‘‘CPAL: A conditional
privacy-preserving authentication with access linkability for roaming service,’’ IEEE
Internet Things J., vol. 1, no. 1, pp. 46–57, Feb. 2014.
[18] M. Ali, M. ElTabakh, and C. Nita-Rotaru, ‘‘FT-RC4: A robust security
mechanism for data stream systems,’’ Purdue Univ., West Lafayette, IN, USA, Tech.
Rep. 05-024, 2005.

40