BlendSPS: A BLockchain-ENabled Decentralized Smart Public Safety System

: Due to the recent advancements in the Internet of Things (IoT) and Edge-Fog-Cloud Computing technologies, Smart Public Safety (SPS) system has become a more realistic solution for seamless public safety services that are enabled by integrating machine learning (ML) into heterogeneous edge computing networks. While SPS facilitates convenient exchanges of surveillance data streams among device owners and third-party applications, the existing monolithic service oriented architecture (SOA) architecture is unable to provide scalable and extensible services in a large-scale heterogeneous network environment. Moreover, traditional security solutions rely on centralized trusted third-party authority, which not only can be a performance bottleneck or the single point of failure, but it also incurs privacy concerns on improperly use of private information. Inspired by blockchain and microservices technologies, this paper proposed a BLockchain-ENabled Decentralized Smart Public Safety (BlendSPS) system. Leveraging hybrid blockchain fabrics, a microservices based security mechanism is implemented to enable decentralized security architecture, and it supports immutability, auditability and traceability for secured data sharing and operations among participants of the SPS system. An extensive experimental study verified the feasibility of the proposed BlendSPS that possesses security and privacy proprieties with limited overhead on IoT based edge networks. and loose-coupling, BlendSPS decouples the functionality into multiple containerized microservices. Those computationally affordable microservices can be deployed and run on the resource-constrained IoT devices with limited overhead. A hybrid blockchain fabric is designed as a fundamental security infrastructure to enable a decentralized architecture, and support immutability, auditability and traceability for data sharing given a trustless distributed IoT network environment.


Introduction
Advancement in artificial intelligence (AI) and Internet of Things (IoT) technology makes the concept of Smart Cities become realistic, and these IoT based smart applications have greatly improved the citizen's quality of live and build a safe and sustainable urban environment. However, it brings multiple new concerns as the IoT is widely adopted in smart communities and smart cities. The resource constraint IoT devices need a lightweight application mechanism to perform service tasks, while distributed and heterogeneous network requires a scalable and flexible system infrastructure to support complicated and cooperative operations among participants in smart cities. To enhance the adoption of the IoT in smart communities and smart cities, researchers have been looking into lightweight IoT based solutions to provide seamless services though integrating heterogeneous computing devices and different types of networks [1,2].
Being considered among the top concerns in the development of smart cities, smart public safety (SPS) facilitates the easy exchanges of surveillance data streams among data owners and third-party service providers. However, it also brings new challenges in architecture, performance and security. The SPS relies on a distributed network environment consisting of a large number of IoT devices, design rational, key components and security features. Section 5 illustrates the blockchain-based security mechanism including microservices framework and hybrid network fabric. The prototype implementation and evaluation are discussed in Section 6. Finally, Section 7 concludes this paper with ongoing efforts and future directions.

Smart Surveillance Systems
With the constant increase in the number of cameras deployed for surveillance purposes, the surveillance community has noticed the demand for human resources to process video-stream data to make decisions timely [6,7]. The conventional solutions rely on a cloud computing platform for the pervasive deployment of networked cameras, either static or mobile, which create a huge amount of surveillance data and atomize the video processing [8,9]. Object detection using machine learning (ML) [10] and statistical analysis [11] approaches are of main interest in recent years. Owning to the onerous computation requirement of big data and contextual ML tasks, smart safety surveillance applications are implemented at the powerful server side.
To minimize the role of the human-agents, the second generation of surveillance solutions aim to implement various intelligent ML algorithms in decision-making tasks, like object detection [12] and abnormal behavior detection [13] at the centralized cloud. The centralized architecture that needs to merge raw frames from cameras back to the cloud brings a heavy burden on the communication network. To reduce the overhead on the communication channels, context information [14] or query languages [15] has been investigated to promote operators' awareness. Researchers have also proposed to improve the efficiency and throughput of the communication networks with better detection rates, such as re-configuring the networked cameras [16], utilizing event-driven visualization [17], and mapping conventional real-time images to 3D camera images [18].
However, relying on a centralized architecture inevitably brings uncertain latency and scalability challenges. Decentralized surveillance systems are promising to address aforementioned challenges like limited network access, and more capable to handle mission-critical, delay sensitive tasks. Advancements in edge-fog-cloud hierarchical architecture enables real-time surveillance [19]. To support the delay-sensitive, mission-critical tasks that often depend on efficient information fusion, quick decision making and situation awareness, an urban speeding traffic monitoring system using Fog Computing paradigm was proposed [12]. Merging raw surveillance data streams from drones on near-site fog computing devices can reduce the network traffic created by sending the video to a remote cloud.
To support object assessment method for a SPS system, an Instant Suspicious Activity identiFication at the Edge (I-SAFE) framework was designed leveraging the edge-fog-cloud hierarchy to detect loitering [20]. In I-SAFE, raw frames from surveillance cameras are feed to an edge device where low-level features are abstracted. The fog computing nodes collect features from edge side and perform intermediate-level tasks, including movements recognition, behavior understanding, and anomaly detection [21]. Finally, the cloud focuses on high level tasks of SPS, such as algorithm fine tuning, historical pattern analysis, and global statistical analysis.

Microservices in IoT
The traditional IoT based service-oriented architecture (SOA) utilizes a monolithic architecture, in which service and application software are developed as a single solution deployed on the cloud server. In monolithic application, the service features are developed as distinguishable functionalities. Those functions are module independent and interconnected by the same back-end with a dedicate/set of technology stack, like database. As a result, those earlier monolithic IoT-based applications are low re-usable and scalable owing to the manners of tightly coupled dependence among functions and components. Therefore, adopting monolithic framework in a distributed IoT-based network inevitably brings new challenges in terms of scalability, service extensibility, data privacy, and cross-platform interoperability [22].
Considering as an extension of SOA, microservices architecture only encapsulate a minimal functional software module as a fine-grained and independently executable unit, which is self-containment and loose-coupled from remaining system. Unlike monolithic architecture in which communication between service units relies on inter process communication (IPC), those microservices units are geographically scattered across the network, so that they communicate with each others through a remote procedure call (RPC) manner, such as HTTP RESTful API. Finally, multiple distributed microservices nodes cooperate with each others to perform the complex functionalities of whole system. Microservices architecture achieves fine granularity by properly implementing a single dedicated function with minimal development resources. As those fine grained microservices units are independent of each others' developing technologies, microservices architecture is loose coupling and flexible to enable continuous development, efficient deployment and easy maintenance.
Thanks to the advanced properties, like scalability, re-usability, extensibility and easy-maintenance, etc., the microservices architecture has been adopted by many smart application developments to improve the scalability and security requirements in distributed IoT-based system. From the perspective of architecture performance and security, the IoT-based applications are advancing from "things"-oriented and centralized ecosystem to a widely and finely distributed microservices-oriented-ecosystem [22]. To enable efficient and security video surveillance services at the edge network including large volumes of distributed IoT devices, a robust smart surveillance systems was proposed by integrating microservices architecture and blockchain technology [1,2,23]. The experimental results verify the feasibility of prototype design to provide a decentralized and fine-grained access control solution for public safety scenario. A similar design is also implemented by BlendSM-DDM [24] to provides lightweight and decentralized security architecture in IoT-based data marketing systems.

Blockchain and Smart Contract
As a form of DLT, Blockchain initially was implemented as an enabling technology of Bitcoin [5]. Bitcoin aims to provide a cryptocurrency to record and verify commercial transactions among trustless entities without relying on any centralized third-party trust authority, such as financial institutes or government agencies. Blockchain relies on a decentralized architecture, where all participants use a Peer-to-Peer (P2P) network to distributively store and verify data on distributed ledger. To maintain integrity, consistence and total order of data on distributed ledger, a consensus protocol is executed among a large amount of distributed nodes, called miners or validators. The transactions are collected by miners who can record those valid transactions in a time-stamped block given consensus algorithm. Finally, all transactions on blockchain is organized as a verifiable, append-only chained structure of public ledger, in which a new block is identified by a cryptographic hash and chained to a preceding block in a chronological order. Thanks to the consensus protocol, participants can access and verify data on public ledger that is distributively stored and maintained by "miner-accountants", as opposed to having to establish and maintain trust relationship with a transaction counter-party or a third-party intermediary [25].
Emerging from the intelligent property, smart contract (SC) introduces programmability into blockchain to support variety of customized transaction logic rather than simple cash transactions. A SC can be considered as a self-executing procedure stored on blockchain, so that users can achieve pre-defined agreements among trustless parties through a blockchain network. Thanks to cryptographic and security mechanisms, a SC combines protocols with user interfaces to formalize and secure relationships over computer networks [26]. Contract developer can use programming language to encapsulate transaction logic and data types into a SC, which is saved at a specific address of blockchain. Through exposing a set of public functions or application binary interfaces (ABIs), a SC can be invoked as receiving a contract-invoking request from users. Finally, data in SC is updated given predefined transaction logic or contract agreement. Owing to proprieties, like decentralization, autonomy and self-sufficiency, SC is an ideal solution to provide decentralized application (DApp) in distributed IoT network.
To enabled decentralized security mechanism for distributed IoT-based applications, leveraging blockchain and smart contract has been a hot topic in academic and industrial communities. Some efforts have been reported recently, for example, smart surveillance system [2,23,27], social credit system [28,29], decentralized data marketing [24], space situation awareness [30], multi-domain avionic system [31], biomedical imaging data processing [32], and access control strategy [33,34]. Given aforementioned works, blockchain and smart contract are promising to enable a completely decentralized mechanism to secure data sharing and accessing for distributed IoT-based SPS systems.

Threat Model and Security Goals
In this section, we first discuss threats to SPS systems, and then provide security goals that BlendSPS aims to a tackle these threats. Figure 1 illustrates several potential threats to normal operations in an SPS. The players are defined as four roles: camera, edge device, fog server and human user. The camera generates real-time video streams and transfers them to on-site/near-site edge devices. The edge devices extract lower level features from raw frames, and then send features to a more powerful fog layer for aggregation. The fog server uses collected features to perform higher level analytic tasks, like human behavior analysis and anomalous event detection. The user can query privacy-preserving information from surveillance visualization services based on his/her granted privileges. Note, an edge device can be a single board computer (SBC) that is mounted on the camera, which generates the video streams. Threat 1: False Frame Injection Attacks.
The smart surveillance relies on the authenticity of raw video streams from camera to fulfill features extraction and decision-making tasks. However, adversary can launch the visual layer attacks to pose a potential threat to safety and security of the infrastructure [35]. Through false frame injection, attacker can feed fake frames on edge to generate incorrect features. During decision-making time, the attacker can also replace original frames with duplicate ones in decision-making process to reduce detection accuracy, as shown by Figure 1.

Security Goal 1: False frame detection and verification.
To design an online frame duplication attack detection for SPS system, an environmental fingerprint-based detection technique by using Electrical Network Frequency (ENF) was proposed [36]. ENF is the power supply frequency with a nominal frequency of 50/60Hz depending on the geographical location. The fluctuations in the ENF is caused by the power supply-demand and has similar throughout as an electrical grid. The ENF is embedded in both audio and video recordings that are generated by devices running on the power grid. As the similarity of two ENF signals can be measured using a correlation coefficient factor, and it could be used as a fingerprint to detect frame duplication attack. This paper mainly focuses on false frame verification based on blockchain technology. During false frame detection process, edge nodes not only execute a online ENF-based false frame detection, it also claim ENF fingerprint of frames through transactions that will be recorded in the distributed ledger. Those ENF fingerprints are saved on an immutable distributed ledger that is available to participants in the blockchain network. Therefore, the fog nodes or surveillance visualization service can verify those checkpoint frames during decision-making process. Threat 2: Extracted Features Data Tampering.
In distributed SPS settings, lower level video processing functions are deployed on edge devices, and only extracted features are sent back to the fog nodes for further processing for decision-making. By maliciously tampering with the feature data exchanged between edge and fog, an adversary can distort feature contextualization or change the behaviors in the anomalous event detection. Security Goal 2: Immutability, Traceability and Auditability for Data Sharing.
During the video processing, edge devices not only send back extracted features as computation results, but also claim correctness proofs of feature data through transactions that will be recorded in the distributed ledger. The consensus protocol guarantees the immutability and integrity of data in the ledger. The fog node will verify the received features before using them in contextualization and decision-making tasks.

Threat 3: Privacy Violation in Surveillance.
The surveillance visualization provides a spectrum of advanced services, like monitoring traffic flows or deterring crime, etc.. However, it also causes people to grow more concerned about the invasion of their privacy as performing mass-surveillance indiscriminately irrespective of the individual's private information [37]. The adversary can breach individual's privacy by unauthorized accessing videos or improperly data usage without permission. Security Goal 3: Decentralized privacy-preserving mechanism.
To protect privacy-sensitive attributes that reveal a lot of information about individuals, like faces, a novel minor privacy protection was proposed by using a face object detector to process collected video streams in real-time at the edge [38,39]. The localized regions of frame will be reversibly scrambled though a lightweight scrambling algorithm. We design a decentralized privacy-preserving mechanism by integrating blockchain with existing sensitive privacy detection and scrambling solution. The privileges definition and access control rules are encapsulated into separate smart contracts, which are deployed on blockchain network. The surveillance service providers can grant service requests without relying on third-party authority, and only authorized users are allowed to access the privacy-preserving information without violating the privacy of individuals.

BlendSPS: Rationale and System Design
Leveraging containerized microservices framework and decentralized blockchain network architecture, our BlendSPS aims to enable efficient, privacy-preserving and secure data sharing and operations in heterogeneous SPS system. Figure 2 illustrates the BlendSPS architecture that consists of (1) a hierarchical SPS system framework that relies on an edge-fog computing network to support a distributed smart surveillance as an edge service, (2) a blockchain-enabled security service layer that enables lightweight and decentralized security policies, and (3) a hybrid blockchain fabric that ensures decentralization and security properties in SPS system. The rationale behind the design of the BlendSPS is described as follows: • Hierarchical SPS framework is considered as the upper-level applications layer that provides SPS services on a heterogeneous network environment, like smart video surveillance, visual layer attack protection and privacy-preserving video stream accessing, etc.. • Blockchain-enabled security service layer functions as the intermediate level infrastructure that integrates containerized microservices with blockchain to support a scalable, flexible and lightweight security mechanism. As a lightweight virtualization technology, containers have features, like platform independence, resource abstraction and OS-level isolation. Therefore, containerized microservices architecture is an ideal design for heterogeneous IoT-based SPS systems. • Hybrid blockchain fabric provides a fundamental networking and security infrastructure to ensure decentralized security enforcement for the SPS system. Leveraging hybrid consensus mechanism and secure public distributed ledger, blockchain fabric brings security features, like immutability, auditability and traceability, to efficiently enhance the security issues of existing SPS systems.

Hierarchical SPS Framework
The left top part of Figure 2 demonstrates an user scenario of a SPS which includes three key elements: smart video surveillance, visual layer attack protection and video stream privacy preservation. Video streams are collected by cameras and transmitted to microservices in real-time on edge devices for feature extraction. The lower level features are extracted by edge devices and are transferred to more powerful fog nodes where data aggregation and higher level analytic services, such as human behavior analysis and anomalous even detection, are conducted. To prevent visual layer attacks on raw video streams, ENF-based false frame detection microservices are responsible for authenticating on-line video stream. Moreover, extracted environmental fingerprint of frame is securely recorded into immutable distributed ledger for decentralized off-line verification. The privacy-conserving surveillance visualization ensure that only authorized user could access sensitive information, and video frames containing user's privacy, such as faces or living areas, are marked and hidden from the public according to the predefined privacy policies.

Smart Video Surveillance
Unlike most conventional Deep Neural Networks (DNN) based smart video surveillance solutions that are implemented in a monolithic architecture, we break the surveillance process into multiple smaller sub-tasks that can be deployed and executed independent of the rest of the system. The classification of the human behavior is divided into two steps: extracting features for each individual from raw video streams, and then making a decision based on the handpicked features. Figure 3 shows the microservices based architecture adopted by our video surveillance on a edge-fog computation hierarchy model.
The lower level tasks, like video processing and object features detection, are performed on the edge side. Figure 3(a) shows the connection of the microservices implemented on the edge node, along with their connections to the fog device for video processing. The raw frame is fed to a microservice that detects the objects of interest and extracts the location of each of them. Then another tracking algorithm, optimized for accuracy and speed, is executed to track the aforementioned detected object in frames of video stream. Given individual's tracking data, the edge node extracts a set of features to identify a pattern of individual's movement based on the object position history. The extracted pattern features are then sent to the corresponding fog node for classification. To mitigate attacks on extracted features during prorogation and sharing process among edge and fog, the edge device also generates an authenticator of features and records it on the blockchain. The fog server can verify the received features by querying authenticator from blockchain, then use the valid ones in decision-making.
The decision-making microservices are deployed on the more powerful fog side, which is responsible for the feature contextualization and target behavior classification, as shown by Figure 3(b). Contextualization helps to have better feature representation when two sets of features have similar values. For example, in a campus environment it is considered normal to detect people in the hall ways, while it is highly suspicious to detect anyone staying in the same hallway for hours. Thus, time may be a very valuable indicator to help interpret the features. Training a classifier to detect human behavior requires huge amount of data, and the detection accuracy highly depends on the quality of the training set [20]. To reduce the need for a complete training data set, we use a fuzzy model to make a decision based on the walking pattern for each of the individuals' information sent by the edge node. Readers interested in details of study on CNN based objects tracking and fuzzy decision making for suspicious activity identification are referred to papers [20,21].

ENF-based False Frame Detection
To protect against visual layer attacks in video surveillance, an ENF-based false frame detection method is design to detect false frame injection during online video stream generation time at camera Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 28 July 2020 Peer-reviewed version available at Smart Cities 2020, 3, 47; doi:10.3390/smartcities3030047 side. The presence of ENF fluctuation traces in multimedia recordings comes from the source of ENF signal by power system. Thus, comparing the ENF signals between power and multimedia recordings can authenticate original digital video or audio sources. Figure 4 illustrates the difference of the ENF fluctuation traces from original video stream, power grid, and the attacked video recording.
The estimated signal from both the power recordings and the audio recordings from the surveillance system are compared using correlation coefficient [40]. We adopt a sliding window-based mechanism to achieve an efficient online detection task. For each window, a 30-sec recording is used for ENF estimation, and upon correlation comparison, a step of five seconds is used with an overlap of 25 seconds. The sliding window approach can reduce the delay in detection of the replay attack and consumes less computational power. As Figure 4 shows, the ENF of duplicated recordings is mismatched with the ENF of power recordings as sliding window comes, the correlation coefficient for duplicated recordings will drop and the false frame injection attack is detected. Readers interested in a detailed study of ENF application in digital media forensic analysis are referred to the cited paper [36].
Because ENF is considered as an environmental fingerprint, the estimated ENF signals from multimedia recordings can also be used as an authenticator for offline verification on surveillance data, like video or audio streams. In case of the false frame detection, a section of recordings can be used as checkpoints, as Figure 4 shows. Then ENF signals extracted from the checkpoint are saved on the blockchain. Other users, like fog server or surveillance visualization, can verify these recordings before using them.

Privacy Preserving for Video Stream
To enable surveillance visualization without violating the privacy of individual person captured in the videos, a privacy preserving mechanism is designed by integrating lightweight sensitive privacy-attributes detection methods, scrambling technique and blockchain technology. The non-compute intensive object detection algorithm is responsible for classifying and localizing the those objects on video frames which are deemed sensitive. Then, the scrambling technique reversibly masks those sensitive objects or regions detected by the object detection scheme. Figure 5 presents an example of children privacy protection. Figure 5(a) shows that children faces are accurately detected and bounded through a face-detection algorithm. In Figure 5(b), the faces of the two children are enciphered following the scrambling process to hide their identity in case of unwarranted disclose. Readers interested in a detailed study of face identification and scrambling technologies for privacy protection are referred to the cited paper [39].
To access video or analytic results from surveillance visualization, users must provide proof to the blockchain-enabled security services that they have the right approbation, as Figure 2 shows. The data Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 28 July 2020 Peer-reviewed version available at Smart Cities 2020, 3, 47; doi:10.3390/smartcities3030047 owners or service providers deploy smart contracts that define privileges and privacy preserving rules on blockchain. These decentralized security services ensure that only authorized users can successfully access privacy-preserving information given their access right and privacy specification.

Blockchain-based Security Mechanism
The blockchain-based security mechanism leverages lightweight microservices architecture and hybrid blockchain fabric to ensure decentralization, security and privacy proprieties for the BlendSPS system. This section provides detail explanations on two parts: upper layered microservices-enabled security service architecture and the underlying hybrid blockchain fabric.

Microservices-enabled Security Service
The microservices-enabled security services layer functions as a fundamental microservices oriented network fabric to support the decentralized security and privacy proprieties in the BlendSPS system, as shown by the left bottom part of Figure 2. The key design ideas and operations are described below.

Video Stream Fingerprint
The ENF-based false frame detection uses a sliding window-based method to obtain and estimate the ENF fingerprint from video records online. This real-time detection mechanism ensures that raw data from camera are authenticated. However, insecure communication channel or modification by other service providers also jeopardize the integrity of original data. Based on the blockchain network, a decentralized video stream data audition strategy is design to protect against false frame injection in the BlendSPS system. By recording extracted ENF fingerprint data into distributed ledger, a lightweight consensus protocol, like Byzantine Fault Tolerant (BFT), is executed among a small scale of distributed validators to ensure the sanctity of the data stored on the ledger. Therefore, any participant can verify the immutable ENF data without relying on a centralized third-party trust authority.
The video stream fingerprint audition procedures are presented in Algorithm 1. As two functions used in real-time false frame detection, the extract_ENF_signal() at line 2 is responsible for extracting ENF signal given input of frames data, and the correlation_ENF_signa() at line 8 outputs the similarity coef_ENF_fingerprint by using a correlation coefficient between the two sampled signals. The ENF fingerprint recording and verification procedures use a set of RPC interfaces exposed by validators to interact with distributed ledger. In record_ENF_fingerprint(frames), video stream owner firstly calls extract_ENF_signal() to get ENF signal by feeding checkpoint frames. Then, he/she launches a transaction (tx) request by calling transaction_commit() RPC to record ENF_fingerprint_tx into distributed ENF_fingerprint_tx ← extract_ENF_signal(frames) 3: tx_result ← transaction_commit(ENF_fingerprint_tx) 4: return tx_result 5: procedure: verify_ENF_fingerprint(frames) 6: ENF_fingerprint_tx ← extract_ENF_signal(frames) 7: query_ENF_fingerprint_tx ← transaction_query(ENF_fingerprint_tx['id']) 8: coef_ENF_fingerprint ← correlation_ENF_signal(ENF_fingerprint_tx, query_ENF_fingerprint_tx) 9: if coef_ENF_fingerprint < coef_threshold then 10: veri f y_ENF ← True 11: else 12: veri f y_ENF ← False 13: end if 14: return verify_ENF ledger. Finally, tx_result will be returned to notify the feature owner as long as ENF_ f ingerprint_tx has been recorded and confirmed in a new block.
The users who utilize video stream in their task will execute verify_ENF_fingerprint(frames) to verify these checkpoint frames. Simply by calling transaction_query(), the user can fetch recorded query_ENF_fingerprint_tx from the distributed ledger for further verification process. Given comparison between coef_threshold and coef_ENF_fingerprint which is evaluated by calling correlation_ENF_signal function, the user can verify whether or not the checkpoint frames are generated by original owner. The false frame injection attacks can be detected.

Data Integrity
As feature data extracted at edge devices is transferred to fog nodes, it is necessary to ensure data integrity for decision-making. Relying on the blockchain network, a data integrity scheme based on hashed features authentication is designed to enable a decentralized and secured features sharing among participants in the BlendSPS system. The distributed ledger is ideal to enable an immutable and traceable storage. However, directly putting a huge amount of features data into a transaction brings more communication and computation cost by transaction propagation and verification. In addition, larger transaction size means fewer committed transactions per block, it also reduces transactions rate given fixed block size.
To ensure efficient data recording, access and verification, only a fixed length string of hashed features is saved on the distributed ledger instead of the raw data. For a set of features F i , the string of hashed features is calculated as hash_F i = H(F i ), where H(·) is a pre-defined collision-resistant hash function that outputs a binary hash string h ∈ {0, 1} λ with the length λ. The hash_F i will be put into a transaction that is recorded on the distributed ledger. Any participants can query hash_F i from the distributed ledger as an authenticator for verification process.
The hashed features authentication procedures are presented by Algorithm 2. The hash_ f eature() function is responsible for computing hash string given the input of f eatures_set. First, all parameter vectors of each feature line are converted to the string format and combined as a string_ f eatures, as shown from line 3 to line 6. Then, line 7 converts a string_ f eatures to a binary string bytes_ f eatures. Finally, a cryptographic one-way hash function outputs a fix length of the hash string f eature_hash given input of bytes_ f eatures, and a dictionary { f eature_id : f eature_hash} will be returned.
The veri f y_hashed_model() procedure is performed by entities who utilize these features data, like fog layer service in the contextualization and decision-making processes. Through executing hash_ f eature( f eatures_set), f eature_tx of currently verifying f eatures_set is calculated as the key index for querying data in the distribute ledger. User simply calls transaction_query() RPC to fetch the recorded query_tx as proof in verification. Given a comparison between query_ f eature_tx and f eature_tx, the user can verify whether or not the f eatures_set is authenticated.

Identity Verification and Access Control
As each blockchain account is uniquely indexed by its address, which is derived from the public key, thus, the blockchain account address is ideal for identity authentication needed by other security microservices, like data integrity and access control. Identity authentication relies on a virtual trust zone that is ensured by a blockchain network, and each entity records its account address into the blockchain as a virtual identity (VID) for identity verification.
The identity verification procedure is presented in Algorithm 3. The identity verification is triggered as a host receives a service request from the client, like access control or privacy policies services. The host calls RPC function get_VNodeInfo() to query the recorded Virtual Node (VNode) information from the smart contract. Then it checks if client has the same VZoneID as the host does and returns the identity verification results verify_ID. Readers interested in a detailed study of VID based identity authentication are referred to the cited paper [30].
To enable a decentralized access authorization and verification, a decentralized capability-based access control mechanism is integrated [34]. Data owners can implement access control models and policies as a SC based access control (AC) microservices entity. In initial, an user must send an access authorization request to the AC microservices to get a capability token before requesting services or resources at SPS service providers. Given pre-defined access authorization policies, AC microservices put authorized access right into capability token which is saved in the smart contract.

22:
end if 23: end for 24: access to service or data is permitted 25: return True The access control verification procedure is explained from line 11 to 24 in Algorithm 3. Once a service request in received from a user, the service provider calls get_AccessToken() to fetch the user's access token, then check if the AC token json_access_data satisfies the valid conditions. If the AC token is valid, the service provider verifies whether user's access request is permitted through comparing every access right saved in the AC token. Otherwise, verification process will be aborted and the service request is denied. If the access rights are authorized, access_control_verification() outputs True, and then the service provider grants the user's access to data or service. Otherwise, service request is denied.

Privacy Policies
The privacy-preserving microservices is applied mostly for privacy-sensitive data management. Therefore, the privacy-sensitive data is not accessible or even not visible to unauthorized entities. Data integrity service ensures that only hash strings of sensitive data are recorded on the blockchain for authenticity checking, while raw date is encrypted and stored off the chain. Hence, data privacy is protected during the transmission and storage time. In addition, AC service programs access control rules as smart contracts, and therefore the access authorization and verification can be executed automatically. The decentralized AC service can effectively prevent unauthorized access to sensitive data. Furthermore, the privacy policies can be securely stored on the blockchain, according to which a data or service requester is aware of his/her privileges to access the sensitive data.
With above mechanism, the data owners are allowed to adjust their access control and privacy policies flexibly. Only authorized users are assigned access to surveillance services without violating the privacy of individuals. The privacy policies service relies on existing security services, like AC and identity verification, to enabled a decentralized privacy-preserving surveillance visualization. As Figure 2 shows, the surveillance visualization firstly interacts with privacy policies microservices, which could query privacy rules based on user's identity. Then, the user can fetch the surveillance service data, like video streams or detection results, according to user's permissions defined by AC services. Finally, given user's privacy policies, the scrambling contents and objects in video steams are visualized to users without revealing information pertinent to individuals' privacy.

Hybrid Blockchain Network Architecture
The BlendSPS utilizes a hierarchical edge-fog computing paradigm, where each layer has different performance, security and privacy requirements. The cameras and edge devices are deployed on the synchronous and permissioned edge network that is managed by a domain administrator. Therefore, lightweight and high throughput become key matrices as running consensus protocol. However, decision-making tasks and surveillance services are deployed on the fog computing layer, which requires data sharing and operations across domain boundaries and relies on an asynchronous network environment. Thus, scalability and security become key matrices as choosing consensus algorithm. It is hard to optimize the trade-offs among performance, scalability and security by integrating a single consensus mechanism into the BlendSPS system.
To handle aforementioned issues as performing consensus algorithms in a distributed BlendSPS network that is highly heterogeneous and dynamical, the hybrid blockchain fabric adopts a two-level consensus mechanism: intra-domain consensus and inter-domain consensus, as the right part of Figure 2 shows. Considering a local domain that includes a small number of cameras and edge devices, a lightweight and efficient intra-committee consensus protocol is executed among specified committee members to validate transactions within domain and maintain a local distributed ledger. For multi-domain operations, like recording hashed features and updating access token, a scalable and security inter-domain consensus protocol is responsible to finalize those inter-domain transactions on a global distributed ledger. The design rationale and workflows are explained as follows.
• Permissioned network: The SPS system is a permissioned network, where every entity must register its unique identity information to system administrator, hence, only authorized nodes can join the network. As permissioned network can provide basic security primitives, like public key infrastructure (PKI) and digital signature, etc., it enhances security proprieties of blockchain from network infrastructure prospective. For a local domain, domain owner chooses a subset of the nodes as an intra-domain committee, and only validators from committee can execute consensus intra-domain protocol, launch transactions and maintain the shared local ledger in private blockchain network. To securely record those cross-domain transactions in SPS system, a consortium blockchain network is used by participants from different domains. Unlike private blockchain network adopted by local domain, any registered entities in SPS system can send transactions and access data on global ledger, however, only authorized nodes can work as miners to execute inter-domain consensus protocol. • Intra-domain consensus: Given private blockchain network managed by local domain owner, a BFT [41] based consensus protocol is executed by validators of intra-domain committee. As BFT consensus protocol can achieve high throughput in a small scale consensus network, and it introduces low computation overhead as executing consensus algorithm on host. Therefore, BFT-based consensus protocol is suitable for intra-domain committee at distributed edge network. For recording data on local ledger, user sends data transactions to a validator within the intra-domain committee. Then, validator verifies received transactions and broadcasts valid ones to other validators. Each validator collects valid transactions, and records them in a new block given block generation algorithm. If proposed block is verified and confirmed by no less than 2/3 of validators, the consensus agreement is achieved by finalizing recorded data in block on distributed ledger. As intra-domain consensus protocol is only executed among a small scale of committee members, thus, communication cost incurred by messages propagation is reduced. • Inter-domain consensus: Inter-domain operations relies on a consortium blockchain network, and it inevitably runs into critical issues in open-access and asynchronous network environment. The inter-domain consensus protocol adopts scalable Proof-of-Work (PoW) mechanism to enable probabilistic finality on inter-domain transactions. Every node follows a message gossiping rule to multicast valid transactions and blocks to peers rather than the whole network. Through exhaustively querying a cryptographic hash function, each miner attempts to gain a hashcode as a work proof for new block generation. If the hashcode of a candidate block satisfies a pre-defined difficult condition parameter, miner broadcast block to peers and append it on the local chain. All honest nodes only accepted valid blocks and always extend blocks on the longest chain that they have ever synchronized from network. Such longest chain rule can effectively mitigate fork issues in an asynchronous network, and ensure that all honest miners are working on a common main chain. The security of the inter-domain consensus is ensured if majority (51%) of the miners are honest and correctly execute the consensus protocol.

Experimental Results
To verify the feasibility of the BlendSPS scheme, a proof-of-concept prototype is built and tested in a real physical network environment. We use the Docker to develop microservices framework, and those containerized microservices units can be deployed both on the edge (Raspberry Pi) devices and fog (desktop) server. The security services are implemented in Python with Flask [42] as web-service framework. For the blockchain network, Ethereum [43] is used as inter-domain blockchain network, while Tendermint [44] is used as intra-domain blockchain network. The Solidity [45], which is a contract-oriented and high-level language, is used for developing smart contracts. We use RSA for asymmetry cryptography, like digital signature, and SHA-256 for hash function, which are developed using standard python lib: cryptography [46].

Experimental Setup
As prototype implementation and test cases design are mainly to verify performance and security proprieties provided by BlendSPS, the experimental setup focus on security functions related configuration. Table 1 shows configurations of devices used for the experimental study. For private Ethereum network, six miners are deployed on six separate desktops, and all nodes use Go-Ethereum [47] as the client application to interact with Ethereum network. The Tendermint are running on a 20-validators test network, where each validator is hosted on a Raspberry Pi (RPi) device. All desktops and RPi devices are connected through a local area network (LAN). In security service simulation test, Redbarn HPC acts as a system oracle that provides security basics, like PKI and registration for network management. The oracle can only manage permissioned network by adding and removing participants. The validators can only update and verify data and transactions on the distributed ledger rather than changing the permissioned network configuration. All desktops can work as fog computing nodes, and RPi devices run as edge computing nodes. The security microservices are deployed both on edge and fog layers for experimental test.

Performance Evaluation
To evaluate the performance of operating microservices-based security schemes, a set of experiments is conducted on our prototype blockchain private networks by simulating service transactions, like access right token generation and identity verification, etc.. The cost of message encryption and decryption are not considered during the test.

Microservices Overhead: Computation Overhead and Network Latency
A service request experiment, which includes five Raspberry PIs and four desktops, is designed to evaluate the overhead incurred by the security microservices on the host machines. Four types of microservices are deployed on four RPi devices and four desktops separately, and each machine only runs a single microservices node. One RPI device functions as a client that sends service request to these security service providers. 100 test runs have been done in total based on the proposed test scenario, where a client initiates the connection by sending a request for service to the server side for an access permission.  Figure 6 shows the computation overhead for hosting individual microservices node on edge and fog platforms. The results reveal that computation overhead increases as the complexity of the tasks grows. As video stream fingerprint relies on a lightweight Tendermint to record and verify the ENF fingerprint data, it needs less processing time than other security services , which require more computational resource by SC operations. Unlike data integrity, identity verification and AC microservices need more cryptographic computations and authentication operations. Therefore, they require higher processing time both on the RPi device and the desktop. Due to multiple SC interactivity, identity verification microservice takes largest processing time for querying the data in blockchain.
The end-to-end delay is evaluated based on the test case that a client sends multiple service transactions per second (TPS) and waits until that all responses are received. Figure 7 shows network latency of running security microservices as send transaction rate varies from 1 to 100 TPS. In terms of the bandwidth of network and capacity of the server side, the time latency of sending transactions and receiving all acknowledgements is almost linear scale to the transaction rate. Considering the same networking environment and transaction data size, the influence of communication cost is almost negligible. Therefore, the computation cost on the server side becomes dominant as scaling multiple transactions during single microservices node scenario.

Throughput Evaluation: Microservices vs. Monolithic Framework
To evaluate the network delay influence between microservices and monolithic framework as scaling multiple transactions, a set of comparative experiment is conducted on two service demo applications: Micro_App and Mono_App. Micro_App uses microservices framework in which five containerized security microservices are deployed on five RPi devices separately. While Mono_App relies on a monolithic framework by encapsulating all security functions into one container that is  deployed on a RPi device. A RPi device works as a client to send service transactions to Micro_App and Mono_App service providers that are deployed on a desktop. Figure 8 shows network latency of launching multiple identity verification requests on microservices and monolithic frameworks. On receiving transactions from client, Micro_App service provider can even distribute service workload into subgroups that are assigned to microservices nodes in the network. Therefore, total network delay is reduced to improve the quality of service (QoS) in terms of response time. As the bottom line in Figure 8 shows, the Micro_App with full microservices capacity achieves lower network delay than other scenarios, and it is amount to 23% of that Mono_App does when TPS is 100. Compared to Mono_App, certain fraction of microservices node dropout does not disturb the service access. However, the network delay increases significantly as fraction of dropout increases, as Figure 8 shows. Figure 9 presents the transaction throughput that Micro_App and Mono_App can achieve as TPS increases. The transaction throughput is greatly influenced by network communication capacity and service processing capability that a security microservices host machine can provide. As Mono_App uses a single monolithic application node to handle all security service transactions, transaction throughput is easier to become saturate than Micro_App as TPS increases. Figure 9 shows that transaction throughput ascent of Micro_App with 0% dropout becomes flat when TPS is about 60, however, Mono_App cannot dramatically increase transaction throughput as TPS is larger than 20. Figure 9 also indicates that transaction throughput of Micro_App is greatly impacted by microservices dropout rate. Since each microservices node has limited service processing capacity, so that service access overload to dropout nodes is transferred to other working nodes. As a result, the transaction throughput of Micro_App declines owning to the decreased system capacity by dropout nodes. Micro_App can tolerant certain fraction of microservices nodes dropout, and it is more robust than Mono_App, which is vulnerable to performance bottleneck. Moreover, through properly deploying security microservices nodes, Micro_App is more scalable and flexible than Mono_App on dynamic and heterogeneous IoT-based networks.

Blockchain Fabric Performance: Tendermint vs. Ethereum
The security microservices utilizes a set of transaction_commit() RPC functions to save data to the distributed ledger, and consensus protocol is responsible to guarantee the security of recorded data on the distributed ledger. Thus, executing consensus protocol and recording data into distributed ledger inevitably introduce extra delays besides normal service operation. 100 testing runs have been carried out based on the proposed test scenario, in which a video stream fingerprint microservices node save ENF fingerprint into Tendermint and a AC microservices node updates access token SC on Ethereum. Figure 10 shows the time delay, that a node launches a blockchain transaction (bc_tx) and waits until it has been committed on the distributed ledger. The bc_tx committed time is closely related to the block confirmation time that is defined by the consensus algorithm. Tendermint utilizes a BFT consensus protocol to achieve a deterministic finality on a new block for each voting round, so that bc_tx committed time is almost stable (about 2.9 s), as showb by Figure 10. However, Ethereum relies on a random block generation mechanism defined by the PoW consensus protocol, and it achieves a probabilistic finality on committed data on the distributed ledger. Therefore, the bc_tx committed time of Ethereum is greatly varying owing to variable block confirmation time as illustrated by Figure 10. Table 2 provides a comprehensive performance of running intra-domain (Tendermint) and inter-domain consensus (Ethereum) protocols regarding several key performance matrices. The bc_tx committed time is calculated by averaging 100 test results in Figure 10. Ethereum achieves a 4.6 sec latency by committing a transaction on distributed ledger, which is 28% longer than Tendermint does. The SC-based security services are generally used by either non-time-sensitive operations, like verify access token, or offline tasks, like checking integrity of contextual features. Thus, 4.6-sec latency  for updating a SC data meets service requirements in SPS applications. The ENF-based false frame detection relies on a minimal 5-sec sliding window to obtain a constant correlation coefficient for dissimilar ENF signal estimations. Thus, 3.6-sec bc_tx committed time is enough for finalizing an ENF fingerprint data on the distributed ledger within one detection cycle. Considering resource consumption in term of CPU and memory usage, Tendermint demonstrates advantages over Ethereum. Ethereum uses a computation intensive PoW consensus algorithm, and mining process almost occupies the full CPU capacity and consumes about 1.2 GB memory. Therefore, it is not feasible to deploy miners on resource constrained IoT devices. However, Ethereum can be deployed as a light node on RPi devices, which only synchronizes and validates blockchain data instead of mining new blocks. Table 2 shows that a Ethereum node only needs 5% CPU capacity and 45 MB memory to support data recording and querying on SC. Tendermint uses a lightweight BFT consensus algorithm to achieve efficiency in CPU and memory usage, so that it is suitable for deploying validators on resource-constraint IoT devices.
In an Ethereum network, transaction commitment requires gas that is used to pay for miners. The average gas fee for each transaction is 0.001 Ether, which amounts to $2.3 given the Ether price in the public Ethereum market ($236.23/Ether at July 20, 2020). Compared to Ethereum, Tendermint does not require transaction fee. Therefore, it is more suitable for inter-domain scenario, which requires large volume of data transactions without introducing additional financial cost.

Discussions
Our experimental results verified the feasibility of the proposed BlendSPS solution. It has the potential to enable a practical IoT-based SPS system featured as a decentralized, secure and privacy preserving service. Compared to centralized security solutions implemented by monolithic framework, the BlendSPS has the following advantages: 1. Decentralized network architecture: The BlendSPS system leverages the blockchain and smart contract technology to provide decentralized security services. Hence, geographical scattered data owners and service providers maintain control on their own resources and securely share information without relying on a centralized third authority to ensure a trust relationship. It can improve system performance and reduce the risk of single point of failure; 2. Flexible and fine-grained SOA framework: BlendSPS uses fine-grained and loose-coupling microservices to enable flexible and robust service architecture. As the whole system can be decoupled into multiple fine-grained microservices units, each microservices unit is only responsible for a dedicated task according to domain related performance and security requirements. Moreover, running microservices units is independent of remaining parts of system. Therefore, user and service providers can increase or decrease serving microservices nodes to achieve expected QoS without disturbing system; and 3. Security proprieties: Given a partial synchronous network environment of SPS settings, persistence and termination are two security proprieties provided by the hybrid blockchain fabric to enable a robust distributed ledger. The persistence ensures that those finalized hashed model strings are immutable and traceable, and can be audited by other participants. Termination ensures aliveness so that all valid hashed model transactions by honest nodes are finalized in distributed ledger after a sufficient amount of time.

Conclusions
This paper introduces BlendSPS, a blockchain-enabled decentralized smart public safety system, to enhance security and privacy-preserving proprieties in distributed SPS network. Leveraging lightweight microservices-based SOA framework and hybrid blockchain fabric, BlendSPS supports a decentralized, secure and efficient data sharing and multi-domain operations in SPS settings. Moreover, BlendSPS brings low computation and communication cost on edge network, making it ideal for IoT-based SPS applications While the experimental results on the prototype are encouraging, there are still open questions to answer before deploying a practical solution on real-world SPS scenarios. As integrating blockchain with heterogeneous IoT based SPS network, a hybrid blockchain fabric is promising to address trade-offs caused by consensus mechanisms, like scalability, efficiency and security. However, it also brings new performance and security concerns during cross-chain transactions. In addition, the transparency of the distributed ledger may exacerbate the privacy problem when users record sensitive data on blockchain. Furthermore, each node needs a full replica of the public ledger to join the blockchain network, hence, it inevitably increases bootstrapping time for new participant and incurs huge storage space consumption on host machine. Part of our on-going effort is focused on further exploration of the efficient and privacy-preserving blockchain protocol, which can be executed at the edge networks with lower communication, computation and storage overhead.

Abbreviations
The following abbreviations are used in this manuscript: