Blockchain-Based Community Safety Security System with IoT Secure Devices

Abstract

Humans frequently need to construct a huge number of buildings for occupants in large cities to work or live in a highly developed civilization; people who live in the same building or same area are defined as a community. A thief stealing items, a burglary, fire hazards, flood hazards, earthquakes, emergency aid, abnormal gas leakage, strange behavior, falling in a building, fainting in a building, and other incidents all threaten the community’s safety. Therefore, we proposed a blockchain-based community safety security system that is combined with IoT devices. In the proposed scheme, we designed multiple phases to process the alarm triggered by IoT devices. IoT devices can be set up in two types areas: private and public areas. Both types of IoT devices’ alarms have different process flow for the response and records checking phase. All records are saved in the Blockchain Center to assure the data can be verified and cannot be forged. During the communication between sender and receiver, we implemented some security methods to prevent message repudiation, prevent transmission intercept, prevent replay attacks, and ensure data integrity. We also implemented a clarifying mechanism to ensure that all system participants can have confidence in the system’s processing methods. The proposed scheme can be used in communities to improve community safety and prevent unnecessary conflicts.

1. Introduction

1.1. Background

In a highly developed society, people often need to build a lot of buildings to allow employees or occupants in large cities to work or live; those people in the same building become a community in the city. Generally, working or living in a community is often inseparable from the problem of safety. Recently, there have been serious fire incidents in Taiwan [1,2], causing many injuries and deaths. After the investigation, the building did not have fully functional security sensors or systems, and when a fire broke out, it did not notify the community’s occupants, which resulted in the tragedy. Many incidents can harm the safety of the community, including thieves stealing things, burglary, fire hazards, flood hazards, earthquake, emergency help, abnormal gas leakage, abnormal behavior, falling in building, fainting in building, etc.

The above-mentioned unsafe concerns are common in community buildings. The community should construct a community safety system to prevent such problems. Furthermore, more people started to deploy private security guards services in their communities, and these have become hot topics to discuss [3,4,5,6].

Some of the communities deploy smart building or smart home technologies to solve the community safety problem; most of these technologies are related to various types of

Internet of Things (IoT) devices (e.g., sensors or surveillance cameras) to achieve the function, such as fire detection, gas leaked detection, motion detection, abnormal detection, human intruder detection, access control, fall detection, earthquake detection, etc. According to a smart buildings market report [7], the research company shows the market is projected to grow from $66.3 billion in 2020 to $108.9 billion in 2025. In addition, due to improvements in medical science and technology, life expectancy has grown rapidly over the world in recent years. Humans are living longer lives, resulting in a fast increase in the number of old people in the population. Around 727 million persons over the age of 65 were recorded globally in 2020, with the number predicted to be 1.5 billion in 2050 [8].

As a result, a safety device or system is one of the community’s required components to guarantee that the community’s occupants have a safer living or working environment.

1.2. Related Works

Several related works are surveyed as follows. Dutta et al. proposed a system called “enhanced security system for smart building using IoT (ES3B) [9]. The authors proposed an IoT device with Arduino, RFID, and Bluetooth for access control. An exception to avoid non-resident going into the building, the guest information also can be built by a resident with an RFID owner. Except for the access control, another author Prasetyo et al. proposed an IoT device with multiple sensors (e.g., metal sensor, fire sensor, vibrator sensor, PIR Sensor, etc.) and a Raspberry Pi camera to detect the threats in the office [10]. The device can detect threats as follows: dangerous objects made from metals, fires, earthquakes, intruders, or theft.

Moreover, Saad et al. designed a fire detection system to prevent fire hazards [11]. The system proposed by the authors is implemented with ZigBee technology as a protocol to receive the data from multiple sensors, such as smoke sensor, gas sensor, heat sensor, and UI/IV sensor. Then, the system processes the data with Raspberry Pi to identify fire. Furthermore, Taryudi et al. proposed a home security and monitoring system with various types of sensors and integrated with a microcontroller [12]. The system can be monitored and controlled remotely with the smartphone application. To allow building security guards to monitor all the building status more effectively, Al-Hudhud et al. proposed a security guard system with an infrared biosensor and augmented reality device to monitor the IoT status [13].

The above-mentioned authors proposed safety systems with IoT, but some security issues will cause the IoT system to disable. Ray et al. pointed out the security issues and challenges in the smart home system [14]: what is important is that the network between routers or gateway to IoT will be the vulnerabilities of the system. Except for the physical network equipment that should be improved, more researchers are implementing the IoT system with blockchain technology in recent years. Khan et al. proposed a data verification system for surveillance cameras with blockchain [15]. Rahman et al. proposed a distributed IoT Software-Defined Network(IoT-SDN) model to ensure the security and privacy of condominium networks [16]. Furthermore, Khalid et al. also designed an authentication mechanism for IoT systems with blockchain [17]. Unfortunately, the authors did not analyze their system security to prove that their proposed scheme is feasible.

As evident in the above-mentioned research, not all research can provide complete system architecture and system security analysis. The research gap has been addressed as follows: (1) Although many researchers proposed IoT applications in smart cities or smart buildings, fewer established a decentralized or blockchain-based system. (2) Less research exists that shows the completed architecture for a community safety application in a blockchain system. (3) There seems to be no scheme to protect the device or system against threats (such as message repudiation, data integrity, cyberattacks, and so on), and there is no security analysis for the proposed scheme. (4) If a dispute occurs, there is a lack of discussion in reading the historical record in encrypted data for clarification process.

In recent years, more and more scholars or industries have begun to use blockchain as the basis of system architecture to execute or store records because of the advantages of blockchain, such as decentralization, unforgeable data, traceability, and clarifiable illegal records. The type of blockchain can be separated into public, private, hybrid blockchain [18,19]. The public blockchain is a high decentralized blockchain, permissionless, with high power consumption, and low throughput for executing smart contracts. Conversely, the private blockchain is a low decentralized blockchain, access controlled, low power consumption, and high throughput. The representative private blockchain today is Hyperledger Fabric [20]. There are more and more applications implemented based on the Hyperledger Fabric, such as hospital information system [21], access control system [22], supply chain management [23], etc. In addition, Chen et al. have also proposed blockchain-based schemes in brand clothing industries [24] and insurance industrial [25].

As a consequence, we proposed a more secure IoT safety security system that applies IoT and blockchain technologies. We proposed a system with the HyperledgerFabric-based [20] blockchain. HyperledgerFabric-based blockchain’s characteristics make it suitable to be used in the community safety system, and it is utilized to improve the system’s security.

The outline of the remaining sections is as follows. Section 2 introduces the technologies that are used in our research. Section 3 proposes our architecture and research method. Then, the security issues analysis and some performance discussion are given in Section 4 and Section 5. Lastly, we conclude this paper in Section 6.

2. Preliminary

2.1. Internet of Things (IoT) Devices

Internet of Things (IoT) is an electronic “thing” that can connect to the internet. Scholars have also made a clear definition of IoT: “the pervasive presence around us of a variety of “things” or “objects”, such as RFID, sensors, actuators, mobile phones, which, through unique addressing schemes, are able to interact with each other and cooperate with their neighboring “smart” components to reach common goals” [26]. In this generation, IoT is continuously implemented and applied around us; our lives are gradually inseparable from IoT. The IoTs are widely used in agriculture, retailers, smart manufacturing, smart home, smart building, smart transportation, smart city, and so on.

In this research, we apply the IoT on the application in building safety. According to the research we found, it can be found that various types of IoT devices are proposed to apply to building safety applications, such as:

• Fire detection: device with detection sensor, smoke detection sensor to prevent a fire hazard [27,28].
• Poison gas alert: device with a variety of gas sensors to prevent gas leaks, such as methane, carbon monoxide, smoke, nitrogen dioxide, and propane [29,30,31].
• Motion detection: device with infrared sensor or camera to detect motion in an area [32,33,34].
• Abnormal detection: smart surveillance system implemented by Artificial Intelligence (AI) that can detect some abnormal situation in the images [35,36,37,38].
• Human intruder detection: detect humans by analyzing ground vibrations [39].
• Fall detection: detect with cameras or 3-axis sensors to prevent human falls in the building [40,41,42,43,44].
• Smart door: authentication with face recognition, fingerprint, smartphone, or pin code to unlock the door without keys [45,46,47].
• Earthquake detection: microelectromechanical systems accelerometer detects vibration of an area [48,49,50].

From the above IoT device application, we can know that IoT technology is already a very mature technology. Therefore, these functional IoT devices or algorithms can be applied or integrated into our proposed safety security system.

2.2. Blockchain-Based Smart Contract

The smart contract is an execution program that is full of transaction logic, which comes from the transformation of a traditional contract in the real world. In today’s era, we can meet smart contracts all around the world, such as vending machines and online shopping platforms. Many smart contracts require cash, credit card, or digital currency to process the transactions, but with the rapid development of blockchain and cryptocurrency, many smart contract applications have begun to be deployed on the blockchain network.

Szabo has developed a concept of decentralized digital assets called “Bit Gold”. It is considered a pioneer before the advent of Bitcoin [51,52]. The technology of Bitcoin was carried forward by Nakamoto [53], who proposed and announced Bitcoin in a mysterious fashion. Bitcoin is a blockchain-based cryptocurrency technology. All transaction records of Bitcoin must be verified by most hosts before they can be synchronized to all participant hosts to avoid problems such as tampering and forgery.

In addition to Bitcoin, the most popular cryptocurrency on the market is Ethereum [54]. Ethereum provides faster and more stable transaction capabilities than Bitcoin. It also provides the function of deploying smart contracts to the public blockchain. With the characteristics of Ethereum, more commercial frameworks of blockchain systems have been developed, such as Hyperledger Fabric [20], Corda [55], and Azure Blockchain [56].

In particular, Hyperledger Fabric is an open-source licensed blockchain framework. It is a blockchain framework that was proposed by IBM in 2018 [57]. It adopts a modular universal framework, unique identity management, access control functions, and channels to transfer data. Those features are suitable for various industrial applications, such as supply chain tracking [58,59], financial management [60], insurance financial [61], healthcare records [62,63], etc. The advantages of the blockchain’s characteristics are listed as follows:

• Decentralization: The operating mode of the blockchain is a technology composed of multiple decentralized peers. All ledger data will be synchronized to all participating peers.
• Authentication: All participants need to be registered on the blockchain’s Certificate Authority (CA); the participant receives the authentication certificates from the CA. Then, the participants’ transactions can be updated to the ledger after authentication.
• Privacy and anonymity: Unlike the other public blockchains like Ethereum, Fabric-based blockchains have a feature that allows peer-to-peer transactions privately in the channel. Except for the transaction, any log of transactions saved in the ledger is kept secret and anonymous.
• Unforgeable data: Every peer is storing the same content of the ledger in the blockchain. All the transactions invoked by participants need to be saved as logs in the ledger, the data are chaining between block to block. Every block also records the previous block’s hash value as a link between blocks, so it is hard to forge data.
• Traceability: Because of the unforgeable data characteristics of the blockchain mentioned above, this also makes the modification record of the data traceable.
• Clarifying illegal records: All change records will be synced in the blockchain peer’s ledger. There are signatures or timestamp data to provide evidence to protect the rights of the community’s occupants if any conflicts arise in the future.

Therefore, the characteristics of HyperledgerFabric-based blockchain with the smart contract are much more suitable to implement in our safety security system.

2.3. Threat Model

Furthermore, we have sorted out the threat that must be addressed, such as system security vulnerabilities and attacks from third parties. The related threats are described as follows:

• Message repudiation issues: In the general safety security system, some issues should be solved. Message repudiation is one of the issues, and we must ensure that the message sent to the receiver was indeed sent by the sender [64].
• Data integrity issues: Sometimes a network or attacker will damage the data during transfer, which makes the data come to non-integrity. Moreover, data integrity must be maintained in the database so that there are no inconsistencies when security records are traced later [64,65].
• Transmission intercept: The message that is transmitted in the network is easily intercepted by the attackers, for example, man-in-the-middle attacks. The action makes the message sent between sender and receiver become disclosed [66,67].
• Replay attacks: When attackers intercept an original message sent in the network, the attacker can resend the same message to pretend the attacker is the original sender [68,69].

3. Proposed Architecture and Methods

We proposed a community safety security system with IoT and blockchain technologies. The proposed system architecture is presented in Figure 1. The proposed system is constituted of the following parties: blockchain center, occupants, security guards, log server, and IoT devices (including cameras and sensors).

3.1. System Architecture

Firstly, all the involved parties in this system are introduced as follows in detail:

• Blockchain Center (BC): A blockchain center composed of multiple device nodes that are storing all the records from IoT. All the involved parties must register in the blockchain center. The monitoring records of the community are saved in the blockchain center. The records in the blockchain center are unforgeable and verifiable. When the parties request to view the specified record in detail, the blockchain center will send votes to other occupants. If more than half of the votes are agreed, the parties can view with the security guard.
• Community (CM): We separate the community type into three types: residential, commercial, and mixed. It is a physical structure in which occupants live or work. Inside the community is installed with several public or private domain IoT devices, variance age or type of occupants, and at least one security guard.
• Occupants (OP): The occupants who live or work in the residential/commercial/mixed community. All occupants involved in this system are given the option to choose whether to install the IoT devices in their private spaces to ensure the safety of their property. Every occupant must have a mobile phone with a decentralized application (dAPP). The dAPP in the mobile phone is an application that connects to the blockchain center. The application needs to registers and login with the blockchain center. The occupants have the right to give the security guard permission to view the monitoring records from his/her private domain IoT.
• Security Guard (SG): The security guard hired by the community’s management administrator. The SG must monitor the condition of the community at all times. If a dangerous incident occurs, the SG must deal with it immediately to ensure the safety of the community. To view any public or private domain IoT record, SG must request the blockchain center to read the records.
• Supervisor (SP): The security guards’ supervisor is in charge of the responsibility of managing security guards. The supervisor is hired by the community’s management administrator. The security guards who are on duty need the supervisor’s permission to check for the public domain history record.
• Internet of Things devices (IoT): The IoT included the security sensor, for example, cameras and sensors. The cameras take images from the corners of the community and detect suspicious events, e.g., burglary and abnormal behaviors.
  • The cameras in the community can be categorized into two types: public domain cameras and private domain cameras. Public domain cameras are installed at the public corner of the community, the installation of the private domain cameras can be chosen by occupants, and they can choose how many cameras and which position they need to install.
  • The sensors in the community can be smoke detectors, motion detectors, emergency buttons, or more devices that can help to notice dangerous moments.
• Log Server (LS): Every video record and event from the camera and sensors in the community are saved to the server. The server can be a physical device in a community or a cloud service on the internet. SG needs access to the log server to read the records.

Figure 1 shows the overall system architecture, and the detailed process flow with numbered is description is as follows:

Step 1.

Every participant must register and get a private key and public key from BC.

Step 2.

An alarm event triggered by an IoT device.

Step 3.

The IoT device updates the event information and status to LS and updates the information via chaincode to BC.

Step 4.

If the triggered IoT device is the public domain device, it will send the event information to SG in the next step (step 5), otherwise, the information will be sent to the relevant occupant in step 8.

Step 5.

The event information sends to the security guard in the community, the security guard received the event in a surveillance system on the LS.

Step 6.

SG receive the event information and check for the video record immediately to verify the situation.

Step 7.

When the situation is checked, SG starts to resolve the alarm event and update the resolved information as a remark to LS and update the information to BC via chaincode.

Step 8.

If the IoT device is a private domain, the alarm event information will be sent to the related occupant’s mobile phone application.

Step 9.

The occupant checks the situation with his/her application on the mobile phone.

Step 10.

The occupant responds and updates the event information to BC. If the occupant needs SG to resolve the situation of the alarm event, then go to step 4. SG will be notified, and SG will help to deal with it. Every action chosen from OP will update to BC via invoking chaincode.

3.2. Notations

The notations used in the following sections are described as shown in

Table 1. The description of the notations.

Notations	Description
$I{D}_X$	X is the identity of the participant (such as IoT devices and occupants), issued by the blockchain center.
$I{D}_E$	The event ID that generated by IoT devices, included the ID of IoT and User. The format is [UserID + IoTID + timestamp]
$q$	A k-bit of prime number
$GF(q)$	Finite group of $q$
$E$	The elliptic curve defined on finite group
$G$	A generating point based on the elliptic curve $E$
$k_i$	The ith random value on the elliptic curve
$(r_{X_{\mathrm{i}}},s_{X_i})$	Elliptic curve signature value of X
$(x_{X_i},y_{X_i})$	The ECDSA signature value of X
$d_X$	The ECDSA’s private key of participant X
$Q_X$	The ECDSA’s public key of participant X
$Pu{k}_X$	The public key of party X, issued by the BC’s CA
$Pr{k}_X$	The private key of party X, issued by the BC’s CA
$C_{X_i}$	The ith ciphertext of X
$H(M)$	One way hash function
$h_{X_i}$	The ith hash value of X
$T_i$	The ith timestamp
$\tau$	The threshold for checking the validity of a timestamp
$M_i$	The ith message from a sender
$E_{Pu{k}_X}(M)/D_{Prk{x}_X}(M)$	Encrypt or decrypt message M with a public key or private key of participant X

.

3.3. Initialization and Registration Phase

All participants that want to be a part of the system need to register with BC’s certificate authority (CA). CA generates the public key and private key pair and sends it to the participant. Figure 2 and Figure 3 show the chaincode’s data structures and types of information of a user, IoT, and event information. Note that the “chaincode” is a “smart contract” that is defined in Hyperledger Fabric. It is almost the same function as the “smart contract” we mentioned before, which can execute the code in the blockchain.

Figure 4 shows the process of the registration phase between the new participant (X) and the blockchain center’s certificate authority (CA). The steps are described as follows:

Step 1.

Participant X sends the information of registration to CA.

Step 2.

CA generates a set of a private key $d_X$ and a public key $Q_X$ of the Elliptic Curve Digital Signature Algorithm (ECDSA) [70]. The $Q_X$ is generated by the follows equation:

$$Q_X=d_{X}G$$

(1)

Next, CA invokes the chaincode function “Registration” in Algorithm 1 to generate participant X’s user $I{D}_X$. The chaincode also updates the user’s information to the BC ledger.

Step 3.

Participant X gets and saves the unique parameters $I{D}_X$, $Q_X$, and $d_X$ for future transactions.

Algorithm 1. Chaincode function of registration and add IoT.

var UserList []User_Information func Registration (var user User_Information) (User_ID string) {    User_ID = GenerateUniqueID()    user.User_ID = User_ID    UserList = append (UserList, user)    return User_ID } func Add_IoT(User_ID string, IoT IoT_Information) (IoT_ID string, d string, Q string) {    index: = SearchUID(User_ID)    IoT.IoT_ID = GenerateUniqueIoTID()    UserList[index].IoTs = append(UserList[index].IoTs, IoT)    d = GenerateECDSAPrivateKey()    Q = d * G    return (IoT.IoT_ID, d, Q) }

Furthermore, every IoT device in the CM must also register with CA. The registration flow of adding a new IoT is shown in Figure 5. The details are as follows:

Step 1.

Firstly, user X generates a random number $k_1$, then generates the message with a sender ID, receiver ID, IoT’s information, and timestamp.

$$M_1=(I{D}_X|\left|I{D}_{CA}\right||<IoT\_Information>||T_1)$$

(2)

A hash value $h_{X_1}$ is calculated by a hash function.

$$h_{X_1}=H(M_1)$$

(3)

Then, X executes the “Sign” function with parameters in Algorithm 2 to get a set of ECDSA signatures $(r_{X_1},s_{X_1})$. The detailed calculation is described in the authentication phase.

$$(r_{X_1},s_{X_1})=Sign(h_{X_1},k_1,d_X)$$

(4)

Next, user X encrypts the message $M_1$ into a cipher message $C_{X_1}$. Then, user X sends cipher messages with signatures $(I{D}_X,I{D}_{CA},C_{X_1},(r_{X_1},s_{X_1}))$ to CA.

$$C_{X_1}=E_{Pu{k}_{CA}}(M_1)$$

(5)

Step 2.

After CA receives the message from X, CA decrypts the cipher message with its private key and gets the decrypted messages.

$$M_1=D_{Pr{k}_{CA}}(C_{X_1})$$

(6)

CA also check the validity of the message’s timestamp.

$$\mathrm{Check} (T_2-T_1)\stackrel{?}{\le }\tau$$

(7)

Then, CA calculates the hash value $h_{X_2}{}^{\prime }$ from the message $M_1$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures. The “Verify” function is described in the next subsection “authentication phase”.

$$h_{X_2}{}^{\prime }=H(M_3)$$

(8)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{X_1}{}^{\prime },r_{X_1},s_{X_1})$$

(9)

If the signatures are valid, CA invokes a chaincode function “Add_IoT” in Algorithm 1 to update the IoT device’s information into BC. Then, CA sends a response message to user X. Firstly, CA generates a random number $k_2$ and a response message with the IoT’s ID $I{D}_{IoT}$ and ECDSA parameters $d_{IoT}$ and $Q_{IoT}$.

$$M_2=(I{D}_{CA}|\left|I{D}_X\right|\left|I{D}_{IoT}\right|\left|d_{IoT}\right|\left|Q_{IoT}\right||T_3)$$

(10)

Then, CA calculates signatures with the hash value $h_{C{A}_1}$. The signatures are calculated by calling the “Sign” function in Algorithm 2, then returning the signatures $(r_{C{A}_1},s_{C{A}_1})$.

$$h_{C{A}_1}=H(M_2)$$

(11)

$$(r_{C{A}_1},s_{C{A}_1})=Sign(h_{C{A}_1},k_2,d_{CA})$$

(12)

Next, CA encrypts the message to cipher message by using user X’s public key.

$$C_{C{A}_1}=E_{Pu{k}_X}(M_2)$$

(13)

Step 3.

User X receives the response message from CA. Then, user X decrypts the cipher message with his/her private key and gets the decrypted messages.

$$M_2=D_{Pr{k}_X}(C_{C{A}_1})$$

(14)

User X checks the message’s timestamp is valid or not:

$$\mathrm{Check} (T_4-T_3)\stackrel{?}{\le }\tau$$

(15)

Then, user Y calculates the hash value $h_{C{A}_1}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures by the following equations.

$$h_{C{A}_1}{}^{\prime }=H(M_2)$$

(16)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{C{A}_1}{}^{\prime },r_{C{A}_1},s_{C{A}_1})$$

(17)

The function returns “valid” if the signatures sent from user Y are valid. Then the IoT device saves parameters $(I{D}_{IoT},d_{IoT},Q_{IoT})$ to its configurations for future communication in the system.

3.4. Authentication Phase

In the authentication phase, we assigned user X as a sender and user Y as a receiver. As shown in Figure 6, every sender and receiver need to sign and verify their message by invoking the “Sign” and “Verify” function in Algorithm 2. The following are the steps in detail.

Step 1.

User X generates a random number $k_3$ and generates a message with a timestamp, sender ID, and receiver ID.

$$M_3=(I{D}_X|\left|I{D}_Y\right||T_5)$$

(18)

Then, a hash value $h_{X_2}$ is calculated by a hash function

$$h_{X_2}=H(M_3)$$

(19)

Then, X executes the “Sign” function with parameters in Algorithm 2 to return a set of ECDSA signatures $(r_{X_2},s_{X_2})$. The details are described in the following equations.

$$(x_{X_2},y_{X_2})=k_{3}G$$

(20)

$$r_{X_2}=x_{X_2}\mathrm{mod}n$$

(21)

$$s_{X_2}=x_{X_2}{}^{-1}(h_{X_2}+r_{X_2}{d}_X)\mathrm{mod}n$$

(22)

Next, user X encrypts the message $M_3$ into a cipher message $C_{X_2}$. Then, user X sends cipher messages with signatures $(I{D}_X,I{D}_Y,C_{X_2},(r_{X_2},s_{X_2}))$ to user Y:

$$C_{X_2}=E_{Pu{k}_Y}(M_3)$$

(23)

Step 2.

User Y receives the message from user X. Then, user Y decrypts the cipher message with his/her private key and gets the decrypted messages.

$$M_3=D_{Pr{k}_Y}(C_{X_2})$$

(24)

Then, user Y checks whether the message’s timestamp is valid or not.

$$T_6-T_5\stackrel{?}{\le }\tau$$

(25)

Then, user Y calculates the hash value $h_{X_2}{}^{\prime }$ from the message $M_3$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{X_2}{}^{\prime }=H(M_3)$$

(26)

$$u_1=h_2{}^{\prime }{s}_{X_2}{}^{-1}\mathrm{mod}n$$

(27)

$$u_2=r_{X_2}{s}_{X_2}{}^{-1}\mathrm{mod}n$$

(28)

$$(x_{X_2}{}^{\prime },y_{X_2}{}^{\prime })=u_{1}G+u_2{Q}_X$$

(29)

$$\mathrm{Check} x_{X_2}{}^{\prime }\stackrel{?}{=}{r}_{X_2}\mathrm{mod}n$$

(30)

If the signatures are valid, then user Y sends a response message to user X. Firstly, user Y generates a random number $k_4$ and a response message with a timestamp.

$$M_4=(I{D}_Y|\left|I{D}_X\right||T_7)$$

(31)

Then, user Y calculates signatures with the hash value $h_{Y_1}$. The signatures are calculated by calling the “Sign” function in Algorithm 2, and the function returns the signatures $(r_{Y_1},s_{Y_1})$ after the following calculations.

$$h_{Y_1}=H(M_4)$$

(32)

$$(x_{Y_1},y_{Y_1})=k_{4}G$$

(33)

$$r_{Y_1}=x_{Y_1}\mathrm{mod}n$$

(34)

$$s_{Y_1}=x_{Y_1}{}^{-1}(h_{Y_1}+r_{Y_1}{d}_Y)\mathrm{mod}n$$

(35)

Then, user Y encrypts the message to cipher message with user X’s public key.

$$C_{Y_1}=E_{Pu{k}_X}(M_4)$$

(36)

Step 3.

User X receives the response message from Y. Then, user X decrypts the cipher message with his/her private key and gets the decrypted messages.

$$M_4=D_{Pr{k}_X}(C_{Y_1})$$

(37)

Then, user X check whether the message’s timestamp is valid or not:

$$\mathrm{Check} (T_8-T_7)\stackrel{?}{\le }\tau$$

(38)

Then, user Y calculates the hash value $h_{Y_1}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures by the following equations.

$$h_{Y_1}{}^{\prime }=H(M_4)$$

(39)

$$u_1=h_{Y_1}{}^{\prime }{s}_{Y_1}{}^{-1}\mathrm{mod}n$$

(40)

$$u_2=r_{Y_1}{s}_{Y_1}{}^{-1}\mathrm{mod}n$$

(41)

$$(x_{Y_1}{}^{\prime },y_{Y_1}{}^{\prime })=u_{1}G+u_2{Q}_Y$$

(42)

$$\mathrm{Check} x_{Y_1}{}^{\prime }\stackrel{?}{=}{r}_{Y_1}\mathrm{mod}n$$

(43)

The function return is valid if the signatures sent from user Y are legal.

Algorithm 2. The function of authentication with the sign and verify.

func Sign (h string, k string, d string) (r string, s string) {    (x, y) = k * G;    r = x % n    s = (h + r * d)/x % n    return r, s } func Verify (h string, r string, s string) (result string) {    u1 = h/s % n    u2 = r/s % n    (x, y) = u1 * G + u2 * Q    if x = r {     return “valid”    }else{     return “invalid” }                }

3.5. Alarm Triggered Phase

When an IoT device detects an abnormal occurrence, it must trigger and send information to the LS immediately. The flow of the alarm triggered phase is provided in Figure 7, and the descriptions are as follows.

Step 1.

IoT generates a random number $k_5$, then invokes the chaincode function “Event_Trigger” as shown in Algorithm 3. This will send a transaction and update the information to the BC’s ledger. The function also returns an event’s ID, and the IoT generates a message and adds with the event’s ID and a timestamp.

$$M_5=(I{D}_{IoT}|\left|I{D}_{LS}\right|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_9)$$

(44)

A hash value $h_{Io{T}_1}$ is calculated by a hash function.

$$h_{Io{T}_1}=H(M_5)$$

(45)

Then, IoT executes the “Sign” function with parameters in Algorithm 2 to generate a set of ECDSA signatures $(r_{Io{T}_1},s_{Io{T}_1})$.

$$(r_{Io{T}_1},s_{Io{T}_1})=Sign(h_{Io{T}_1},k_5,d_{IoT})$$

(46)

Next, IoT encrypts the message $M_5$ into a cipher message $C_{Io{T}_1}$ with LS’s public key. Then, IoT sends cipher messages with signatures $(I{D}_{IoT},I{D}_{LS},C_{Io{T}_1},(r_{Io{T}_1},s_{Io{T}_1}))$ to LS.

$$C_{Io{T}_1}=E_{Pu{k}_{LS}}(M_5)$$

(47)

Step 2.

After LS receives the message from IoT, LS decrypts the cipher message with its private key and gets the decrypted messages.

$$M_5=D_{Pr{k}_{LS}}(C_{Io{T}_1})$$

(48)

Then, LS checks the interval of the message’s timestamp.

$$\mathrm{Check} (T_{10}-T_9)\stackrel{?}{\le }\tau$$

(49)

Next, LS calculates the hash value $h_{Io{T}_1}{}^{\prime }$ from the message $M_5$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{Io{T}_1}{}^{\prime }=H(M_5)$$

(50)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{Io{T}_1}{}^{\prime },r_{Io{T}_1},s_{Io{T}_1})$$

(51)

If the signatures are valid, the LS invokes the chaincode function “Event_Received_LS” as shown in Algorithm 3 which updates the LS’s received timestamp and signature of the event to BC. After that, LS generates a random number $k_6$ and a response message $M_6$, then transmits the message to IoT later.

$$M_6=(I{D}_{LS}|\left|I{D}_{IoT}\right||T_{11})$$

(52)

Then, CA calculates signatures with the hash value $h_{L{S}_1}$. The signatures are calculated by calling the “Sign” function in Algorithm 2, then the function returns the signatures $(r_{L{S}_1},s_{L{S}_1})$.

$$h_{L{S}_1}=H(M_6)$$

(53)

$$(r_{L{S}_1},s_{L{S}_1})=Sign(h_{L{S}_1},k_6,d_{LS})$$

(54)

LS encrypts the message to cipher message with IoT’s public key and sends the message to IoT.

$$C_{L{S}_1}=E_{Pu{k}_{IoT}}(M_6)$$

(55)

Step 3.

IoT receives the response message from LS. Then, IoT decrypts the cipher message with its private key and gets the decrypted messages.

$$M_6=D_{Pr{k}_{IoT}}(C_{L{S}_1})$$

(56)

Then, IoT checks whether the message’s timestamp is valid or not:

$$\mathrm{Check} (T_{12}-T_{11})\stackrel{?}{\le }\tau$$

(57)

Next, IoT calculates the hash value $h_{L{S}_1}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures by the following equations.

$$h_{L{S}_1}{}^{\prime }=H(M_6)$$

(58)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{L{S}_1}{}^{\prime },r_{L{S}_1},s_{L{S}_1})$$

(59)

Algorithm 3. Chaincode function of alarm triggered phase.

var EventLog []Event_Information func Event_Trigger (OPID string, IoTID string, type IoTType, signature string) (EventID string) {    EventID = GenerateUniqueEventID()    EventLog = append (EventLog, new Event_Information{      Event_ID:EventID,      IoT_ID: IoTID,      User_ID: OPID,      IoT_Type: type,      Triggered_Datetime: time.Now(),      IoT_Triggered_Signature: signature    })    return EventID } func Event_Received_LS (Event_ID string, signature string) {    index: = SearchEventID(Event_ID)    EventLog[index].LS_Received_Datetime = time.Now()    EventLog[index].LS_Received_Signature = signature }

3.6. Notification Phase

When an IoT device detects an abnormal occurrence, the IoT must alert relevant personnel at the same time. If the IoT is set to the public domain, the notice will be delivered to SG; otherwise, if the IoT is set to the private domain, the notification will be sent to OP. The flow of the notification phase is depicted in Figure 8, the descriptions are as follows.

Step 1.

Firstly, IoT generates a random number $k_7$ and a message with IoT’s ID, security guard/occupant’s ID, IoT occupant’s ID, event’s ID, and send timestamp.

$$M_7=(I{D}_{IoT}|\left|I{D}_{SO}\right|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_{13})$$

(60)

A hash value $h_{Io{T}_2}$ is calculated by a hash function.

$$h_{Io{T}_2}=H(M_7)$$

(61)

Then, IoT executes the “Sign” function with parameters in Algorithm 2 to generate a set of signatures $(r_{Io{T}_2},s_{Io{T}_2})$.

$$(r_{Io{T}_2},s_{Io{T}_2})=Sign(h_{Io{T}_2},k_7,d_{IoT})$$

(62)

Next, IoT encrypts the message $M_7$ into a cipher message $C_{Io{T}_2}$.

$$C_{Io{T}_2}=E_{Pu{k}_{SO}}(M_7)$$

(63)

A chaincode function “Event_Update_Notification” as shown in Algorithm 4 is invoked by IoT to update the IoT notification timestamp and signature of the event to BC. Then, IoT sends cipher messages with signatures $(I{D}_{IoT},I{D}_{SO},C_{Io{T}_2},(r_{Io{T}_2},s_{Io{T}_2}))$ to the security guard or occupant depending on the IoT type. We abbreviate the security guard or occupant to SO.

Step 2.

After SO receives the message from IoT, SO decrypts the cipher message with his/her private key and gets the decrypted messages.

$$M_7=D_{Pr{k}_{SO}}(C_{Io{T}_2})$$

(64)

Then, SO checks the interval of the message’s timestamp.

$$\mathrm{Check} (T_{14}-T_{13})\stackrel{?}{\le }\tau$$

(65)

Next, LS calculates the hash value $h_{Io{T}_2}{}^{\prime }$ from the message $M_7$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{Io{T}_2}{}^{\prime }=H(M_7)$$

(66)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{Io{T}_2}{}^{\prime },r_{Io{T}_2},s_{Io{T}_2})$$

(67)

If the signatures are valid, the SO invokes the chaincode function “Event_Received_User” as shown in Algorithm 4 which updates the SO’s received timestamp and signature to BC. After that, SO generates a random number $k_8$ and a response message $M_8$.

$$M_8=(I{D}_{SO}|\left|I{D}_{IoT}\right||T_{15})$$

(68)

Then, SO calculates signatures with the hash value $h_{S{O}_1}$. The signatures are calculated by executing the “Sign” function in Algorithm 2, then the function returns the signatures $(r_{S{O}_1},s_{S{O}_1})$.

$$h_{S{O}_1}=H(M_8)$$

(69)

$$(r_{S{O}_1},s_{S{O}_1})=Sign(h_{S{O}_1},k_8,d_{SO})$$

(70)

Then, SO encrypts the message to cipher message with IoT’s public key, then SO sends the message to IoT.

$$C_{S{O}_1}=E_{Pu{k}_{IoT}}(M_8)$$

(71)

Step 3.

IoT receives the response message from SO. Then, IoT decrypts the cipher message with its private key and gets the decrypted messages.

$$M_8=D_{Pr{k}_{IoT}}(C_{S{O}_1})$$

(72)

Then, IoT checks whether the message’s timestamp is valid or not:

$$\mathrm{Check} (T_{16}-T_{15})\stackrel{?}{\le }\tau$$

(73)

Next, IoT calculates the hash value $h_{S{O}_1}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures by the following equations.

$$h_{S{O}_1}{}^{\prime }=H(M_8)$$

(74)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{S{O}_1}{}^{\prime },r_{S{O}_1},s_{S{O}_1})$$

(75)

The real situation must be verified or checked by SO. The response message should be sent to LS in the next phase after being checked or solved.

Algorithm 4. Chaincode function of notification phase.

func Event_Update_Notification (Event_ID string) {    index := SearchEventID(Event_ID)    EventLog[index].Notify_Datetime = time.Now() } func Event_Received_User (Event_ID string, signature string) {    index := SearchEventID(Event_ID)    EventLog[index].User_Received_Datetime = time.Now()    EventLog[index].User_Received_Signature = signature }

3.7. Response Phase (Security Guard with Public Domain IoT)

The security guard must report the results back to LS once the public IoT alarm has been investigated or solved by the security guard. Figure 9 shows the flow of the response phase with public domain IoT, and the details of the steps are as follows.

Step 1.

Initially, SG generates a random number $k_9$ and a message with the event’s ID and a timestamp.

$$M_9=(I{D}_{SG}|\left|I{D}_{LS}\right|\left|I{D}_E\right||T_{17})$$

(76)

A hash value $h_{S{G}_1}$ is calculated by a hash function.

$$h_{S{G}_1}=H(M_9)$$

(77)

Next, SG executes the “Sign” function with parameters in Algorithm 2 to generate a set of signatures $(r_{S{G}_1},s_{S{G}_1})$.

$$(r_{S{G}_1},s_{S{G}_1})=Sign(h_{S{G}_1},k_9,d_{SG})$$

(78)

Then, SG encrypts the message $M_9$ into a cipher message $C_{S{G}_1}$ with LS’s public key.

$$C_{S{G}_1}=E_{Pu{k}_{LS}}(M_9)$$

(79)

SG invokes a chaincode function “Event_Update_Response” in Algorithm 5 to update the SG’s response message, timestamp, and signature of the event to BC. Then, SG sends cipher messages with signatures $(I{D}_{SG},I{D}_{LS},C_{S{G}_1},(r_{S{G}_1},s_{S{G}_1}))$ to the LS.

Step 2.

LS receives the message from SG and decrypts the cipher message with its private key and gets the decrypted messages.

$$M_9=D_{Pr{k}_{LS}}(C_{S{G}_1})$$

(80)

Then, LS checks the interval of the message’s timestamp.

$$\mathrm{Check} (T_{18}-T_{17})\stackrel{?}{\le }\tau$$

(81)

Next, LS calculates the hash value $h_{S{G}_1}{}^{\prime }$ from the message $M_9$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{S{G}_1}{}^{\prime }=H(M_9)$$

(82)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{S{G}_1}{}^{\prime },r_{S{G}_1},s_{S{G}_1})$$

(83)

If the signatures are valid, the LS invokes the chaincode function “Event_Received_Response” in Algorithm 5 to update the LS’s received timestamp and signature to BC. Afterward, LS generates a random number $k_{10}$ and a response message $M_{10}$.

$$M_{10}=(I{D}_{LS}|\left|I{D}_{SG}\right||T_{19})$$

(84)

LS calculates signatures with the hash value $h_{L{S}_2}$. The signatures $(r_{L{S}_2},s_{L{S}_2})$ are calculated by executing the “Sign” function in Algorithm 2.

$$h_{L{S}_2}=H(M_{10})$$

(85)

$$(r_{L{S}_2},s_{L{S}_2})=Sign(h_{L{S}_2},k_{10},d_{LS})$$

(86)

Then, LS encrypts the message to cipher message with SG’s public key, then sends the message to SG.

$$C_{L{S}_2}=E_{Pu{k}_{SG}}(M_{10})$$

(87)

Step 3.

SG receives the message from LS. Then, SG decrypts the cipher message with his/her private key and gets the decrypted messages.

$$M_{10}=D_{Pr{k}_{SG}}(C_{L{S}_2})$$

(88)

After that, SG checks whether the message’s timestamp is valid or not.

$$\mathrm{Check} (T_{20}-T_{19})\stackrel{?}{\le }\tau$$

(89)

Next, SG calculates the hash value $h_{L{S}_2}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{L{S}_2}{}^{\prime }=H(M_{10})$$

(90)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{L{S}_2}{}^{\prime },r_{L{S}_2},s_{L{S}_2})$$

(91)

Algorithm 5. Chaincode function of response phase from security guard.

func Event_Update_Response (Event_ID string, signature string, message string) {    index: = SearchEventID(Event_ID)    EventLog[index].User_Response_Datetime = time.Now()    EventLog[index].User_Response_Signature = signature    EventLog[index].ResponseMessage = message } func Event_Received_Response (Event_ID string, signature string) {    index: = SearchEventID(Event_ID)    EventLog[index].LS_Received_Datetime = time.Now()    EventLog[index].LS_Received_Signature = signature }

3.8. Response Phase (Occupant with Private Domain IoT)

If the IoT is in the private domain, the occupant has the alternative of resolving it himself/herself or authorizing the security guard to solve the alarm situation. Figure 10 shows the flow of the response phase with private domain IoT. The details of the steps are as follows.

Step 1.

Firstly, OP generates a random number $k_{11}$ and a message with the event’s ID, a timestamp, and the option of self or permitting guard to solve $<Self/Guard>$.

$$M_{11}=(I{D}_{OP}|\left|I{D}_{LS}\right|\left|I{D}_E\right|\left|T_{21}\right||<Self/Guard>)$$

(92)

A hash value $h_{O{P}_1}$ is calculated by a hash function.

$$h_{O{P}_1}=H(M_{11})$$

(93)

Next, OP executes the “Sign” function with parameters in Algorithm 2 to generate a set of signatures $(r_{O{P}_1},s_{O{P}_1})$.

$$(r_{O{P}_1},s_{O{P}_1})=Sign(h_{O{P}_1},k_{11},d_{OP})$$

(94)

Then, OP encrypts the message $M_{11}$ into a cipher message $C_{O{P}_1}$ with LS’s public key.

$$C_{O{P}_1}=E_{Pu{k}_{LS}}(M_{11})$$

(95)

OP invokes a chaincode function “Event_Update_Response” in Algorithm 6. The function updates the OP’s response message, timestamp, and signature to BC. Then, OP sends cipher messages with signatures $(I{D}_{OP},I{D}_{LS},C_{O{P}_1},(r_{O{P}_1},s_{O{P}_1}))$ to the LS.

Step 2.

LS receives the message from OP. LS decrypts the cipher message with its private key and gets the decrypted messages.

$$M_{11}=D_{Pr{k}_{LS}}(C_{O{P}_1})$$

(96)

Then, LS checks the interval of the message’s timestamp.

$$\mathrm{Check} (T_{22}-T_{21})\stackrel{?}{\le }\tau$$

(97)

Next, LS calculates the hash value $h_{O{P}_1}{}^{\prime }$ from the message $M_{11}$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{O{P}_1}{}^{\prime }=H(M_{11})$$

(98)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{O{P}_1}{}^{\prime },r_{O{P}_1},s_{O{P}_1})$$

(99)

If the signatures are valid, the LS invokes the chaincode function “Event_Received_Response” in Algorithm 6 to update the LS’s received timestamp and signature to BC. Afterward, LS generates a random number $k_{12}$ and a response message $M_{12}$.

$$M_{12}=(I{D}_{LS}|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_{23})$$

(100)

LS calculates signatures with the hash value $h_{L{S}_3}$. The signatures $(r_{L{S}_3},s_{L{S}_3})$ are calculated by executing the “Sign” function in Algorithm 2.

$$h_{L{S}_3}=H(M_{12})$$

(101)

$$(r_{L{S}_3},s_{L{S}_3})=Sign(h_{L{S}_3},k_{12},d_{LS})$$

(102)

Then, LS encrypts the message to cipher message with OP’s public key, then sends the message $(I{D}_{LS},I{D}_{OP},C_{L{S}_3},(r_{L{S}_3},s_{L{S}_3}))$ to OP.

$$C_{L{S}_3}=E_{Pu{k}_{OP}}(M_{12})$$

(103)

Step 3.

OP receives the message from LS. Then, OP decrypts the cipher message with his/her private key.

$$M_{12}=D_{Pr{k}_{OP}}(C_{L{S}_3})$$

(104)

After that, OP check whether the message’s timestamp is valid or not.

$$\mathrm{Check} (T_{24}-T_{23})\stackrel{?}{\le }\tau$$

(105)

Next, OP calculates the hash value $h_{L{S}_3}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{L{S}_3}{}^{\prime }=H(M_{12})$$

(106)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{L{S}_3}{}^{\prime },r_{L{S}_3},s_{L{S}_3})$$

(107)

Step 1.

If the OP permits the security guard in the community to solve the situation, then LS will send the notification to the security guard as provided in the following step. LS generates a random number $k_{13}$ and a response message $M_{13}$.

$$M_{13}=(I{D}_{LS}|\left|I{D}_{SG}\right|\left|I{D}_E\right||T_{25})$$

(108)

LS calculates signatures with the hash value $h_{L{S}_4}$. The signatures $(r_{L{S}_4},s_{L{S}_4})$ are calculated by executing the “Sign” function in Algorithm 2.

$$h_{L{S}_4}=H(M_{13})$$

(109)

$$(r_{L{S}_4},s_{L{S}_4})=Sign(h_{L{S}_4},k_{13},d_{LS})$$

(110)

Then, LS encrypts the message to cipher message with SG’s public key, then sends the message $(I{D}_{LS},I{D}_{SG},C_{L{S}_4},(r_{L{S}_4},s_{L{S}_4}))$ to SG.

$$C_{L{S}_4}=E_{Pu{k}_{SG}}(M_{13})$$

(111)

Step 2.

SG received the message from LS. Then, SG decrypts the cipher message with his/her private key.

$$M_{13}=D_{Pr{k}_{SG}}(C_{L{S}_4})$$

(112)

After that, SG checks the validity of the message’s timestamp.

$$\mathrm{Check} (T_{26}-T_{25})\stackrel{?}{\le }\tau$$

(113)

Next, SG calculates the hash value $h_{L{S}_4}{}^{\prime }$ from the message and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{L{S}_4}{}^{\prime }=H(M_{13})$$

(114)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{L{S}_4}{}^{\prime },r_{L{S}_4},s_{L{S}_4})$$

(115)

SG invokes a chaincode function “Event_Update_Received_SG” in Algorithm 6. The function updates the SG response message, timestamp, and signature of the event to BC. Afterward, SG generates a random number $k_{14}$ and a response message $M_{14}$.

$$M_{14}=(I{D}_{SG}|\left|I{D}_{LS}\right|\left|I{D}_E\right||T_{27})$$

(116)

SG calculates signatures with the hash value $h_{S{G}_2}$. The signatures $(r_{S{G}_2},s_{S{G}_2})$ are calculated by executing the “Sign” function in Algorithm 2.

$$h_{S{G}_2}=H(M_{14})$$

(117)

$$(r_{S{G}_2},s_{S{G}_2})=Sign(h_{S{G}_2},k_{14},d_{SG})$$

(118)

Then, SG encrypts the message to cipher message with LS’s public key, then sends the cipher message to SG.

$$C_{S{G}_2}=E_{Pu{k}_{LS}}(M_{14})$$

(119)

Then, SG sends cipher messages with signatures $(I{D}_{SG},I{D}_{LS},C_{S{G}_2},(r_{S{G}_2},s_{S{G}_2}))$ to LS.

Step 3.

LS receives the message from SG, LS decrypts the cipher message with its private key and gets the decrypted messages.

$$M_{14}=D_{Pr{k}_{LS}}(C_{S{G}_2})$$

(120)

Then, LS checks the interval of the message’s timestamp.

$$\mathrm{Check} (T_{28}-T_{27})\stackrel{?}{\le }\tau$$

(121)

Next, LS calculates the hash value $h_{S{G}_2}{}^{\prime }$ from the message $M_{14}$ and invokes the “Verify” function in Algorithm 2 to check the validity of signatures.

$$h_{S{G}_2}{}^{\prime }=H(M_{14})$$

(122)

$$(\mathrm{valid}/\mathrm{invalid})=Verify(h_{S{G}_2}{}^{\prime },r_{S{G}_2},s_{S{G}_2})$$

(123)

If the signatures are valid, the LS invokes the chaincode function “Event_Received_Response_SG” in Algorithm 6 to update the LS’s received timestamp and signature to BC.

Algorithm 6. Chaincode function of response phase from an occupant.

func Event_Update_Response (Event_ID string, signature string, message string) {    index: = SearchEventID(Event_ID)    EventLog[index].User_Response_Datetime = time.Now()    EventLog[index].User_Response_Signature = signature    EventLog[index].ResponseMessage = message } func Event_Received_Response (Event_ID string, signature string) {    index: = SearchEventID(Event_ID)    EventLog[index].LS_Received_Datetime = time.Now()    EventLog[index].LS_Received_Signature = signature } func Event_Update_Recieved_SG (Event_ID string, signature string) {    index: = SearchEventID(Event_ID)    EventLog[index].SG_Received_Datetime = time.Now()    EventLog[index].SG_Received_Signature = signature } func Event_Received_Response_SG (Event_ID string, signature string) {    index: = SearchEventID(Event_ID)    EventLog[index].SG_Response_Datetime = time.Now()    EventLog[index].SG_Response_Signature = signature }

3.9. Check for History Records Phase

In this stage, the system is designed in two ways to obtain history videos or records. It is divided into the private and public domain. Figure 11 shows how OP viewing for the public records through SG. The detailed step is as follows:

Step 1.

OP requests for viewing the private domain IoT devices videos or records from SG face to face.

Step 2.

The SG sends his/her encryption key and request information (such as start date and time, end date and time, and name or ID of private domain IoT device(s)) to LS. Then, the LS sends that information to BC for verification.

Step 3.

BC notifies the related occupant’s mobile device and asks for permission to let SG and OP view the related records.

Step 4.

The related occupant replies to the permission request back to BC by mobile device.

Step 5.

If the related occupant accepts the request, then BC shows the history videos or records in the security system. Otherwise, BC responds to the SG and OP that the request is not permitted.

Furthermore, the SG can also request for viewing the private domain IoT devices videos or records himself/herself without OP; the authorization of the relevant occupant is also required. On the other hand, SG needs SP to authorize to view the public records, as shown in Figure 12. The major steps of obtaining authorization are the same, the difference is only the step of notifying and asking permission from SG’s supervisor SP, who is not related to OP. The detailed step is described as follows:

Step 1.

SG requests for viewing the public domain IoT devices’ videos or records. The SG sends his/her encryption key and request information (such as start date and time, end date and time, and name or ID of private domain IoT device(s)) to LS.

Step 2.

Then, the LS sends that information to BC for verification.

Step 3.

BC notifies SG’s supervisor (SP) and asks for permission to let SG view the related records.

Step 4.

The SP replies to the permission request back to BC by mobile device.

Step 5.

If the related occupant accepts the request, then BC shows the history videos or records in the security system to SG. Otherwise, BC responds to the SG that request is not permitted.

3.10. Clarification Phase

When any party’s participating role determines that there is a problem with the secure record, it can request a third-party impartial unit or person to verify it. Figure 13 shows the flow of clarifying the information of safety security system logs. The explanation is as follows:

Step 1.

The participant (such as security guard or occupant, SO) sends a clarifying request with the specified event ID and signatures to a third party (TP).

Step 2.

TP sends the request message and his/her signature to BC.

Step 3.

The signatures are checked by the BC, then the event’s information are sent to TP.

Step 4.

The TP checks the validity of every signature in the event’s information.

• Check if the event is triggered from a public domain IoT: go to step 4b if it is “no”, else go to step 4d.
• If the SG response signature is not valid, then the information is forged by LS.
• If the SG received signature is not valid, then the information is forged by SG.
• If the LS response signature is not valid, then the information is forged by LS.
• If the SO response signature is not valid, then the information is forged by SO.
• If the SO received signature is not valid, then the information is forged by SO.
• If the LS received signature is not valid, then the information is forged by LS.
• If the IoT triggered signature is not valid, then the information is forged by IoT.
• The specified event information is valid if all the signatures are legal.

4. Security Analysis

In this research, we have done some important security analyses to prevent the system’s vulnerabilities or attacks from the proposed scheme. The analyses are explained in the following subsections, such as the data integrity, non-repudiation of the message, unforgeable data, traceability of records, man-in-the-middle attack, and replay attack.

4.1. Data Integrity

Firstly, we analyzed the integrity of the message in this subsection. The hash function with the ECDSA algorithm is used to ensure the integrity of the message. Every sender must calculate a hash value from the message and generate a set of signatures, and the receiver needs to verify the validation of the message in hash value and signatures by the “Verify” function in Algorithm 2.

For example, in the phase of registration of IoT, the sender X sends the message $M_1$ to the receiver CA. The sender needs to generate $h_{X_1}$ and calculate $(r_{X_1},s_{X_1})$ with the “Sign” function in Algorithm 2. Next sender sends $M_1$ in cipher message with a signature $(r_{X_1},s_{X_1})$ to the receiver, then the receiver decrypts and generates hash value $h_{X_1}{}^{\prime }$ by the message $M_1$. Lastly, the hash value $h_{X_1}{}^{\prime }$ with the signature $(r_{X_1},s_{X_1})$ is verified in the “Verify” function of Algorithm 2. All detailed messages in every phase are listed in

Table 2. Verification of data integrity of the proposed scheme.

Phase	Party		Message	Hash Value	Verification
	Sender	Receiver
Registration of IoT	X	CA	$M_1=(I{D}_X|\left|I{D}_{CA}\right||<IoT\_Information>||T_1)$	$h_{X_1}=H(M_1)$	$Verify(h_{X_1}{}^{\prime },r_{X_1},s_{X_1})$
	CA	X	$M_2=(I{D}_{CA}|\left|I{D}_X\right|\left|I{D}_{IoT}\right|\left|d_{IoT}\right|\left|Q_{IoT}\right||T_3)$	$h_{C{A}_1}=H(M_2)$	$Verify(h_{C{A}_1}{}^{\prime },r_{C{A}_1},s_{C{A}_1})$
Authentication	X	Y	$M_3=(I{D}_X|\left|I{D}_Y\right||T_5)$	$h_{X_2}=H(M_3)$	$Verify(h_{X_1}{}^{\prime },r_{X_1},s_{X_1})$
	Y	X	$M_4=(I{D}_Y|\left|I{D}_X\right||T_7)$	$h_{Y_1}=H(M_4)$	$Verify(h_{Y_1}{}^{\prime },r_{Y_1},s_{Y_1})$
Alarm triggered	IoT	LS	$M_5=(I{D}_{IoT}|\left|I{D}_{LS}\right|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_9)$	$h_{Io{T}_1}=H(M_5)$	$Verify(h_{Io{T}_1}{}^{\prime },r_{Io{T}_1},s_{Io{T}_1})$
	LS	IoT	$M_6=(I{D}_{LS}|\left|I{D}_{IoT}\right||T_{11})$	$h_{L{S}_1}=H(M_6)$	$Verify(h_{L{S}_1}{}^{\prime },r_{L{S}_1},s_{L{S}_1})$
Notification	IoT	SG/OP	$M_7=(I{D}_{IoT}|\left|I{D}_{SO}\right|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_{13})$	$h_{Io{T}_2}=H(M_7)$	$Verify(h_{Io{T}_2}{}^{\prime },r_{Io{T}_2},s_{Io{T}_2})$
	SG/OP	IoT	$M_8=(I{D}_{SO}|\left|I{D}_{IoT}\right||T_{15})$	$h_{S{O}_1}=H(M_8)$	$Verify(h_{S{O}_1}{}^{\prime },r_{S{O}_1},s_{S{O}_1})$
Response (Public IoT)	SG	LS	$M_9=(I{D}_{SG}|\left|I{D}_{LS}\right|\left|I{D}_E\right||T_{17})$	$h_{S{G}_1}=H(M_9)$	$Verify(h_{S{G}_1}{}^{\prime },r_{S{G}_1},s_{S{G}_1})$
	LS	SG	$M_{10}=(I{D}_{LS}|\left|I{D}_{SG}\right||T_{19})$	$h_{L{S}_2}=H(M_{10})$	$Verify(h_{L{S}_2}{}^{\prime },r_{L{S}_2},s_{L{S}_2})$
Response (Private IoT)	OP	LS	$M_{11}=(I{D}_{OP}|\left|I{D}_{LS}\right|\left|I{D}_E\right||T_{21})$	$h_{O{P}_1}=H(M_{11})$	$Verify(h_{O{P}_1}{}^{\prime },r_{O{P}_1},s_{O{P}_1})$
	LS	OP	$M_{12}=(I{D}_{LS}|\left|I{D}_{OP}\right|\left|I{D}_E\right||T_{23})$	$h_{L{S}_3}=H(M_{12})$	$Verify(h_{L{S}_3}{}^{\prime },r_{L{S}_3},s_{L{S}_3})$
	LS	SG	$M_{13}=(I{D}_{LS}|\left|I{D}_{SG}\right|\left|I{D}_E\right||T_{25})$	$h_{L{S}_4}=H(M_{13})$	$Verify(h_{L{S}_4}{}^{\prime },r_{L{S}_4},s_{L{S}_4})$
	SG	LS	$M_{14}=(I{D}_{SG}|\left|I{D}_{LS}\right|\left|I{D}_E\right||T_{27})$	$h_{S{G}_2}=H(M_{14})$	$Verify(h_{S{G}_2}{}^{\prime },r_{S{G}_2},s_{S{G}_2})$

respectively.

4.2. Non-Repudiation

Furthermore, we also analyzed the non-repudiation of the message in this subsection. The sign function with the ECDSA algorithm is used to ensure the signature is from the sender. Every sender must generate the signature from the message, and the receiver needs to verify the signatures by the “Verify” function in Algorithm 2.

For example in the phase of registration of IoT, the sender X generates $(r_{X_1},s_{X_1})$ with the ECDSA “Sign” function in Algorithm 2 by multiple parameters, such as hash value $h_{X_1}$, random number $k_1$, and its ECDSA parameter $d_X$. Then, the receiver generates a hash value $h_{X_1}{}^{\prime }$ by the received message. The hash value $h_{X_1}{}^{\prime }$ and signature $(r_{X_1},s_{X_1})$ are verified in the ECDSA “Verify” function in Algorithm 2. The signature is signed by the sender if the verification return is valid. All the signatures and verification in every phase are listed in

Table 3. Verify non-repudiation of the proposed scheme.

Phase	Party		Signature	Verification
	Sender	Receiver
Registration of IoT	X	CA	$(r_{X_1},s_{X_1})=Sign(h_{X_1},k_1,d_X)$	$Verify(h_{X_1}{}^{\prime },r_{X_1},s_{X_1})$
	CA	X	$(r_{C{A}_1},s_{C{A}_1})=Sign(h_{C{A}_1},k_2,d_{CA})$	$Verify(h_{C{A}_1}{}^{\prime },r_{C{A}_1},s_{C{A}_1})$
Authentication	X	Y	$(r_{X_2},s_{X_2})=Sign(h_{X_2},k_3,d_X)$	$Verify(h_{X_1}{}^{\prime },r_{X_1},s_{X_1})$
	Y	X	$(r_{Y_1},s_{Y_1})=Sign(h_{Y_1},k_4,d_Y)$	$Verify(h_{Y_1}{}^{\prime },r_{Y_1},s_{Y_1})$
Alarm triggered	IoT	LS	$(r_{Io{T}_1},s_{Io{T}_1})=Sign(h_{Io{T}_1},k_5,d_{IoT})$	$Verify(h_{Io{T}_1}{}^{\prime },r_{Io{T}_1},s_{Io{T}_1})$
	LS	IoT	$(r_{L{S}_1},s_{L{S}_1})=Sign(h_{L{S}_1},k_6,d_{LS})$	$Verify(h_{L{S}_1}{}^{\prime },r_{L{S}_1},s_{L{S}_1})$
Notification	IoT	SG/OP	$(r_{Io{T}_2},s_{Io{T}_2})=Sign(h_{Io{T}_2},k_7,d_{IoT})$	$Verify(h_{Io{T}_2}{}^{\prime },r_{Io{T}_2},s_{Io{T}_2})$
	SG/OP	IoT	$(r_{S{O}_1},s_{S{O}_1})=Sign(h_{S{O}_1},k_8,d_{SO})$	$Verify(h_{S{O}_1}{}^{\prime },r_{S{O}_1},s_{S{O}_1})$
Response (Public IoT)	SG	LS	$(r_{S{G}_1},s_{S{G}_1})=Sign(h_{S{G}_1},k_9,d_{SG})$	$Verify(h_{S{G}_1}{}^{\prime },r_{S{G}_1},s_{S{G}_1})$
	LS	SG	$(r_{L{S}_2},s_{L{S}_2})=Sign(h_{L{S}_2},k_{10},d_{LS})$	$Verify(h_{L{S}_2}{}^{\prime },r_{L{S}_2},s_{L{S}_2})$
Response (Private IoT)	OP	LS	$(r_{O{P}_1},s_{O{P}_1})=Sign(h_{O{P}_1},k_{11},d_{OP})$	$Verify(h_{O{P}_1}{}^{\prime },r_{O{P}_1},s_{O{P}_1})$
	LS	OP	$(r_{L{S}_3},s_{L{S}_3})=Sign(h_{L{S}_3},k_{12},d_{LS})$	$Verify(h_{L{S}_3}{}^{\prime },r_{L{S}_3},s_{L{S}_3})$
	LS	SG	$(r_{L{S}_4},s_{L{S}_4})=Sign(h_{L{S}_4},k_{13},d_{LS})$	$Verify(h_{L{S}_4}{}^{\prime },r_{L{S}_4},s_{L{S}_4})$
	SG	LS	$(r_{S{G}_2},s_{S{G}_2})=Sign(h_{S{G}_2},k_{14},d_{SG})$	$Verify(h_{S{G}_2}{}^{\prime },r_{S{G}_2},s_{S{G}_2})$

.

All the important signatures and received timestamps will be sent via chaincode in the alarm triggered phase, notification phase, and response phase. When there is a dispute that has to be resolved, Section 3.10 offers a clarification phase to determine whether there are any signature issues.

4.3. Unforgeable Data and Traceability

In the proposed system we applied HyperledgerFabric-based blockchain technology in the proposed scheme. It is hard to forge any data stored in the BC compared to the traditional database storing scheme. In every phase we designed in the system, every participant must invoke the chaincode function and update the related information to BC, especially updating the signature and timestamp when processing the IoT’s triggered alarm.

Figure 14 shows how the data are updated in the BC. When a participant invokes a chaincode function, the chaincode mechanism will be proposed to every peer (the peer could be more than 1, we demonstrated 3 peers in the scheme) in the blockchain center. Every peer sign and response after the transaction is proofed. After that, the ledger will be updated to every peer via an ordering peer (OP) after sending those endorsed signs and the transaction.

Because of the chaincode mechanism, it is impossible to forge data in the blockchain center; every transaction and ledger are duplicated in all the peers in BC, and the only way to update the data in the ledger is from pre-designed chaincode.

According to the characteristics of the blockchain, every transaction record will be chained and stored in the ledger of every peer. Therefore, the records can be traced in the ledger, and they are also unforgeable. In addition, we designed a clarification phase in Section 3.10. The section can help participants to clarify the record in the blockchain with the third party. If any signatures cannot be verified in the phase of clarifying, it means some signatures are being forged during executing chaincode in other phases.

4.4. Man-in-the-Middle Attack

We implemented asymmetric encryption and decryption in every communication message to defend from the man-in-the-middle attack. Every message that sends from the sender must encrypt with the receiver’s public key. After the receiver received the encrypted cipher message, the receiver uses its private key to decrypt the message.

Table 4. Encryption and decryption to prevent man-in-the-middle attack.

Phase	Party		Encryption	Decryption
	Sender	Receiver
Registration of IoT	X	CA	$C_{X_1}=E_{Pu{k}_{CA}}(M_1)$	$M_1=D_{Pr{k}_{CA}}(C_{X_1})$
	CA	X	$C_{C{A}_1}=E_{Pu{k}_X}(M_2)$	$M_2=D_{Pr{k}_X}(C_{C{A}_1})$
Authentication	X	Y	$C_{X_2}=E_{Pu{k}_Y}(M_3)$	$M_3=D_{Pr{k}_Y}(C_{X_2})$
	Y	X	$C_{Y_1}=E_{Pu{k}_X}(M_4)$	$M_4=D_{Pr{k}_X}(C_{Y_1})$
Alarm triggered	IoT	LS	$C_{Io{T}_1}=E_{Pu{k}_{LS}}(M_5)$	$M_5=D_{Pr{k}_{LS}}(C_{Io{T}_1})$
	LS	IoT	$C_{L{S}_1}=E_{Pu{k}_{IoT}}(M_6)$	$M_6=D_{Pr{k}_{IoT}}(C_{L{S}_1})$
Notification	IoT	SG/OP	$C_{Io{T}_2}=E_{Pu{k}_{SO}}(M_7)$	$M_7=D_{Pr{k}_{SO}}(C_{Io{T}_2})$
	SG/OP	IoT	$C_{S{O}_1}=E_{Pu{k}_{IoT}}(M_8)$	$M_8=D_{Pr{k}_{IoT}}(C_{S{O}_1})$
Response (Public IoT)	SG	LS	$C_{S{G}_1}=E_{Pu{k}_{LS}}(M_9)$	$M_9=D_{Pr{k}_{LS}}(C_{S{G}_1})$
	LS	SG	$C_{L{S}_2}=E_{Pu{k}_{SG}}(M_{10})$	$M_{10}=D_{Pr{k}_{SG}}(C_{L{S}_2})$
Response (Private IoT)	OP	LS	$C_{O{P}_1}=E_{Pu{k}_{LS}}(M_{11})$	$M_{11}=D_{Pr{k}_{LS}}(C_{O{P}_1})$
	LS	OP	$C_{L{S}_3}=E_{Pu{k}_{OP}}(M_{12})$	$M_{12}=D_{Pr{k}_{OP}}(C_{L{S}_3})$
	LS	SG	$C_{S{G}_2}=E_{Pu{k}_{LS}}(M_{13})$	$M_{13}=D_{Pr{k}_{LS}}(C_{S{G}_2})$
	SG	LS	$C_{L{S}_4}=E_{Pu{k}_{SG}}(M_{14})$	$M_{14}=D_{Pr{k}_{SG}}(C_{L{S}_4})$

shows all the asymmetric encryption and decryption in every phase.

For example, in the phase of registration of IoT, X sends a message $M_1$ encrypted by CA’s public key $E_{Pu{k}_{CA}}(M_1)$, then generates a cipher message $C_{X_1}$. Next, X sends the cipher message $C_{X_1}$ to CA, and CA decrypts the cipher message $C_{X_1}$ by his/her private key $D_{Pr{k}_{CA}}(C_{X_1})$ = $M_1$ to get the original message $M_1$. Consequently, the attacker is not able to decrypt the message without having a private key of the receiver.

4.5. Replay Attack

To prevent the replay attack, we added a timestamp in every message sent from the sender. The receiver needs to calculate the difference of the timestamp when receiving the message. If the interval of two timestamps is over a threshold value, it means the message is being replayed.

Table 5. Timestamp validation to prevent man-in-the-middle attack.

Phase	Party		Send Time	Receive Time	Validation
	Sender	Receiver
Registration of IoT	X	CA	$T_1$	$T_2$	$\mathrm{Check} (T_2-T_1)\stackrel{?}{\le }\tau$
	CA	X	$T_3$	$T_4$	$\mathrm{Check} (T_4-T_3)\stackrel{?}{\le }\tau$
Authentication	X	Y	$T_5$	$T_6$	$\mathrm{Check} (T_6-T_5)\stackrel{?}{\le }\tau$
	Y	X	$T_7$	$T_8$	$\mathrm{Check} (T_8-T_7)\stackrel{?}{\le }\tau$
Alarm triggered	IoT	LS	$T_9$	$T_{10}$	$\mathrm{Check} (T_{10}-T_9)\stackrel{?}{\le }\tau$
	LS	IoT	$T_{11}$	$T_{12}$	$\mathrm{Check} (T_{12}-T_{11})\stackrel{?}{\le }\tau$
Notification	IoT	SG/OP	$T_{13}$	$T_{14}$	$\mathrm{Check} (T_{14}-T_{13})\stackrel{?}{\le }\tau$
	SG/OP	IoT	$T_{15}$	$T_{16}$	$\mathrm{Check} (T_{16}-T_{15})\stackrel{?}{\le }\tau$
Response (Public IoT)	SG	LS	$T_{17}$	$T_{18}$	$\mathrm{Check} (T_{18}-T_{17})\stackrel{?}{\le }\tau$
	LS	SG	$T_{19}$	$T_{20}$	$\mathrm{Check} (T_{20}-T_{19})\stackrel{?}{\le }\tau$
Response (Private IoT)	OP	LS	$T_{21}$	$T_{22}$	$\mathrm{Check} (T_{22}-T_{21})\stackrel{?}{\le }\tau$
	LS	OP	$T_{23}$	$T_{24}$	$\mathrm{Check} (T_{24}-T_{23})\stackrel{?}{\le }\tau$
	LS	SG	$T_{25}$	$T_{26}$	$\mathrm{Check} (T_{26}-T_{25})\stackrel{?}{\le }\tau$
	SG	LS	$T_{27}$	$T_{28}$	$\mathrm{Check} (T_{28}-T_{27})\stackrel{?}{\le }\tau$

shows all timestamp validation in every phase.

5. Discussion

5.1. Computation Cost

In this subsection, we calculated the computation costs as shown in

Table 6. Computation costs of the proposed scheme.

Phase	Participant 1	Participant 2
Registration of IoT	User X: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Certificate Authority: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
Authentication	User X: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	User Y: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
Alarm triggered	Internet of Things: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Log Server: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
Notification	Internet of Things: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Security Guard/Occupant: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
Response (Public IoT)	Security Guard: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Log Server: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
Response (Private IoT)	Occupant: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Log Server: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy
	Log Server: 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv + 2Tasy	Security Guard: 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv + 2Tasy

Notes: T_h: a hash operation; T_add: an additional operation; T_sub: a subtraction operation; T_mul: a multiplication operation; T_div: a division operation; T_asy: asymmetrical encryption/decryption.

. We consider all computational costs in all phases of communication protocol. The costs included hash operation, additional operation, subtraction operation, multiplication operation, division operation, and asymmetrical encryption/decryption.

5.2. Communication Cost

In this subsection, we calculated the communication costs as shown in

Table 7. Communication costs of the proposed scheme.

Phase	Message Length	4G (100 Mbps)	5G (20 Gbps)
Registration of IoT	3648 bits	35 ms	0.17 ms
Authentication	3648 bits	35 ms	0.17 ms
Alarm triggered	3648 bits	35 ms	0.17 ms
Notification	3648 bits	35 ms	0.17 ms
Response (Public IoT)	3648 bits	35 ms	0.17 ms
Response (Private IoT)	7296 bits	70 ms	0.34 ms

Notes: L_ID: an ID (144 bits); L_m: a cipher message (512 bits); L_sig: signature parameters (1024 bits).

. We calculated the total message length transmitted in every phase with 4G and 5G networks. The maximum speed is 100 Mbps (Megabit Per Second) in the 4G network and 20 Gbps in the 5G network. We assume that the length of an ID (L_ID) is 144 bits, the length of a cipher message (L_m) is 512 bits, and the length of a set of signatures (L_sig) is 1024 bits in the transmission message. For example, in the phase of registration of IoT, the calculation of message length is 4 × L_ID + 2 × L_m + 2 × L_sig = 4 × 144 bits + 2 × 512 bits + 2 × 1024 bits = 3648 bits. Therefore, the communication cost in the 4G network is 3648 bits/100 Mbps = 35 ms, and the communication cost in the 5G network is 3648 bits/20 Gbps = 0.17 ms.

5.3. Comparison

Table 8. Comparison with surveyed related works.

Authors	Year	Objective	Technologies	1	2	3	4	5	6
Dutta et al. [9]	2018	IoT security system	IoT, Arduino	Y	N	Y	N	N	N
Prasetyo et al. [10]	2018	Smart office system with threat detection	IoT, Arduino, Raspberry Pi	Y	N	Y	Y	N	N
Saeed et al. [11]	2018	Smart home environment for fire prevention	ZigBee	Y	N	Y	N	Y	N
Taryudi et al. [12]	2018	Home security and monitoring system with various types of sensor, such as PIR, DHT-22, rain, fire, LDR sensors.	Arduino-nano, NodeMCU ESP8266	Y	N	Y	N	N	N
Al-Hudhud et al. [13]	2019	Security guard system with augmented reality to monitor IoT status	Infrared biosensor, google glass	Y	N	Y	Y	Y	N
Ray et al. [14]	2020	The security issues of smart home network	Information security, networking	Y	N	Y	Y	Y	N
Khan et al. [15]	2020	Data verification system for surveillance cameras	Blockchain, IoT	Y	Y	Y	Y	Y	N
Rahman et al. [16]	2020	Distributed IoT-SDN Model for condominium	Blockchain, IoT-SDN	Y	Y	Y	N	Y	N
Khairuddin et al. [71]	2021	Smart building system with face detection and recognition	Image processing, Raspberry Pi	Y	N	Y	Y	Y	N
Our proposed method	2021	A Blockchain-based community safety security system with IoT secure devices	Blockchain, IoT	Y	Y	Y	Y	Y	Y

Notes: 1: Application for community or building safety, 2: Blockchain-based architecture, 3: Internet of Things (IoT), 4: Surveillance Camera, 5: Complete architecture or framework, 6: Security analysis, Y: Yes, N: No.

shows the comparison with the previous researches we surveyed. In this research, we proposed a more secure IoT system with blockchain technology. Our research also provides a complete system architecture and scheme, then the security issues of the proposed method are proven in the security analysis section.

5.4. Limitations

The legal effect of the privacy issues for installing the IoT to surveillance will depend on the legal provisions in various countries. In the proposed scheme, before using the system, every participant must register with the blockchain center and have their relevant data filled in during the registration process; other relevant information is also required. After successful registration, they need to obtain the public key and private key pair of the elliptic curve signature before they participate in this system.

The most important thing is that all communities must have basic and stable electricity and networks to operate IoT devices and safety security systems. The establishment of a backup power supply in the building or community can also prevent the proposed approach from failing due to power problems. Alternatively, if the community does not have a stable Internet access network, a local network safety security system can be realized with the same architecture of the proposed scheme. Concerning the notification phase or response phase, it would be a better solution to use a more traditional Short Message Service (SMS) to send messages to related occupant or security guard mobile phones instead of network transmission.

Overall, there are some limitations to the proposed system. The proposed scheme in this article is focused on applying blockchain technology to solve security and clarification issues. Therefore, the unpopularity or the slow speed of the Internet environment will be potential issues.

6. Conclusions

Working or living in a community is frequently inextricably linked to the issue of safety. To solve the problem of community safety, we proposed a community security system based on blockchain and IoT security devices. Our research proposes a complete system architecture and provides a communication flow for multiple phases after the alarm is triggered. Security mechanisms are also integrated into the communication flow to prevent the system from being attacked.

First, all participants and IoT devices must register with BC for future communication authentication. When an IoT device triggers an alarm in the community, the message will be sent to the LS to record the alarm message, and the relevant personnel (occupier or security guard) will be notified that there is a possibility of an unsafe situation in the community. Relevant personnel must confirm and respond to LS to record. In the process of all status updates of the phase, all senders and receivers must update their signatures to BC by invoking a chaincode we provide. The chaincode execution updates all the peers’ ledgers in the BC.

We have also devised different methods for managing both private and public IoT devices. Any participant that needs to check for the history records must obtain the right from the IoT’s owner. The private IoT devices should be permitted by the occupant, and the public IoT should be permitted by the SG’s supervisor to ensure the privacy of the occupants. Furthermore, when a participant in this system raises a dispute, the participant can raise questions about the community safety handling process with a third party in the clarification phase. The third-party can obtain the signature and timestamp data through the BC by the IoT trigger alarm ID specified by the participant. Then the third party confirms the legality of the process by verifying the validity of the signature.

With the proposed method, we achieved the following features in the safety security system:

(1)

Blockchain decentralization and authentication to ensure the privacy and anonymity of participants.

(2)

Unforgeable and traceability of data by the blockchain characteristic.

(3)

The privacy protection when grabbing a history records from Log Server.

(4)

Designed a clarifying phase for clarifying the safety system process.

(5)

Signature mechanism to ensure message repudiation during communication.

(6)

Asymmetrical encryption/decryption to ensure data integrity during communication.

(7)

Transmission intercept prevention, prevent replay attacks from cyberattacks.

(8)

Multiple security analyses have also been presented to prove the system’s security.

(9)

The features of other works and our proposed scheme are also compared and concluded in Table 8.

Finally, we expect that the system can be applied to various communities to strengthen the safety of the community and avoid unnecessary disputes and tragedies.