In a smart city, we assume that all aspects of life are observed and guided by a network of sensors and smart gadgets. The suggested network model is built on HF technology as a programming platform that is coupled with IoT data to offer security, identity management, and authentication. The data flow security framework is shown in Fig. 2.
Transaction deployment accepts a chaincode as an argument. It represents a smart contract that is written in Go. The chaincode performs the transaction. It can read and write entries in its state as needed and indicates whether it succeeded or failed. Each chaincode can have its permanent state elements.
Over the completed transactions and the ensuing permanent state, the blockchain's hash chain is generated. The duplicated execution of the chaincode validates transactions and gives the fault assumption underpinning Byzantine Fault Tolerance (BFT) consensus. Chaincode transactions must be predictable while executing on top of Practical Byzantine Fault Tolerance (PBFT) consensus. If not, the peers' states could change (Saleh, 2021).
4.1 Access Control
The access control mechanism evaluates access requests using a mathematical model, applying a set of guidelines and restrictions based on the access control policies. Overall, this proposed access control mechanism represents a significant contribution to the field, offering a powerful and flexible means of controlling access to sensitive medical data stored on a blockchainThe algorithm used by the access control mechanism is as follows:
Input:
-
Access Request: a list of properties that the user has requested.
-
User Attributes: a group of characteristics that the user is given.
-
Resource Attributes: a collection of attributes associated with a resource.
-
Access Control Policy: a collection of rules that indicate whether access should be permitted or refused depending on the user and resource attributes.
Output:
Algorithm
1. Define the access control policy as a set of characteristics and a Boolean function that returns true or false based on whether the attributes are consistent with the policy:
policy = {(attr_1, attr_2, ..., attr_n), Boolean function}
2. Assign users and resources attributes:
user_attributes = {(attr_1, attr_2, ..., attr_n)} resource_attributes = {(attr_1, attr_2, ..., attr_n)}
3. Evaluate the access request based on the attributes specified in the access control policy:
access_decision = policy[1](user_attributes, resource_attributes, access_request)
4. If the access decision is true, grant access to the resource. Otherwise, deny access:
if access_decision = = True: grant_access()
else: deny_access()
5. Monitor and audit the user's access to the resource:
while access_granted(): monitor_user_actions()
Overall, the Attribute-Based Access Control (ABAC) algorithm provides a flexible and adaptable way to regulate access to resources based on attributes assigned to users and resources. By defining an access control policy and evaluating access requests based on this policy, the ABAC algorithm can help secure sensitive data and prevent unauthorized access to resources.
4.2 Transaction Validation
The proposed system uses smart contracts to verify every transaction on the network and confirm that it complies with the access control rules. Practical Byzantine Fault Tolerance (PBFT) works in multiple rounds, with each round consisting of three phases: pre-prepare, prepare, and commit.
Input:
-
A collection of nodes involved in consensus: N = {n1, n2, ..., nn}
-
A request for a new transaction to be added to the blockchain: tx
Output:
Algorithm
- A leader is selected from the set of nodes to propose a new transaction to be added to the blockchain: l ∈ N.
-
The network's leader communicates the proposed transaction to all other nodes: ∀ ni ∈ N, ni receives tx.
-
Each node receives the transaction proposal and validates it to ensure it is a valid transaction: ∀ ni ∈ N, ni verifies tx.
-
Each node sends a message to all other nodes indicating whether they agree or disagree with the proposed transaction: ∀ ni ∈ N, ni sends mi to all other nodes where mi = {ni, tx, v}, v = verify(tx).
-
The leader waits for responses from all other nodes in the network: ∀ ni ∈ N, l keeps waiting for 2f + 1 messages, where f is the number of problematic nodes.
-
If the leader receives a response from a quorum of nodes (i.e., 2f + 1 nodes), it proceeds to add the transaction to the blockchain: if ∃ mi1, mi2, ..., mi2f + 1 such that mi1.n = mi2.n = ... = mi2f + 1.n and verify(mi1.tx) = verify(mi2.tx) = ... = verify(mi2f + 1.tx), then add(tx) to the blockchain.
-
If the leader does not receive a response from a quorum of nodes within a specified time, it cancels the transaction: if ∀ ni ∈ N, l does not receive 2f + 1 messages within a timeout period, cancel(tx).
-
If a node receives messages from a quorum of nodes agreeing on a transaction, it incorporates the transaction into its local copy of the blockchain: if ∃ mi1, mi2, ..., mi2f + 1 such that verify(mi1.tx) = verify(mi2.tx) = ... = verify(mi2f + 1.tx), then add(tx) to the blockchain.
-
If a node receives messages from a quorum of nodes disagreeing on a transaction, it rejects the transaction and informs the other nodes in the network: if ∃ mi1, mi2, ..., mik and mj1, mj2, ..., mjl such that k + l ≥ 2f + 1, mi1.n = mi2.n = ... = mik.n and mj1.n = mj2.n = ... = mjl.n, and verify(mi1.tx) = verify(mi2.tx) = ... = verify(mik.tx) and verify(mj1.tx) ≠ verify(mj2.tx) ≠ ... ≠ verify(mjl.tx), then reject(tx) and broadcast mj1 to all other nodes.
-
The nodes repeat the process for each new transaction that is proposed.
-
The nodes periodically exchange their local copies of the blockchain to ensure consistency across the network: ∀ ni ∈ N, ni exchanges its blockchain with all other nodes periodically.
Overall, the PBFT algorithm provides a way to achieve consensus among a distributed set of nodes even if some of them are faulty or malicious. By relying on a quorum of nodes to validate each transaction, PBFT ensures that the blockchain remains secure and consistent even in the face of adversarial attacks or node failures.
4.3 Data Encryption
We suggest utilizing a data encryption approach based on the Advanced Encryption Standard (AES) algorithm and implementing using Hyperledger Fabric's encryption capabilities to ensure that sensitive data is only available to authorized users. We specifically adopt the Galois Counter Mode (GCM) mathematical model because it combines the AES approach with a mode of operation for permitted data encryption. AES is a popular symmetric-key encryption technique that protects data using a key of a predetermined length. GCM provides both confidentiality and integrity of the data being transmitted, which prevents unauthorized tampering or alteration during transmission. AES encryption algorithm is a widely recognized method to encrypt and decrypt data securely. Here are the mathematical equations and steps involved in the AES algorithm:
Input:
-
Plaintext message (M)
-
Secret key (K)
Output:
Steps:
-
Key Expansion: To produce the round keys, a key schedule is made by expanding the secret key (K). When encrypting and decrypting data, round keys are employed. The key schedule is created by performing a series of operations on the secret key (K). The number of round keys generated depends on the key size.
-
Initial Round: The first round key is XORed with the plaintext message (M). Mix column operation (M-box) is applied to the output of this operation to construct the ciphertext for the first round.
-
Rounds: The following round key is XORed with the previous round's ciphertext to create the final product. The result of this operation is passed through the S-box, P-box, and M-box operations to produce the ciphertext of the current round. This process is repeated for all the rounds.
-
Final Round: The last round key is XORed with the ciphertext created in the previous round. The final ciphertext (C) is the outcome of this process.
Mathematical Equations:
1. Key Expansion:
2. Initial Round:
-
C0 = M XOR K0
-
C1 = SubBytes(C0)
-
C2 = ShiftRows(C1)
-
C3 = MixColumns(C2)
-
C4 = C3 XOR K1
3. Rounds:
-
C5 = SubBytes(C4)
-
C6 = ShiftRows(C5)
-
C7 = MixColumns(C6)
-
C8 = C7 XOR K2
4. Final Round:
-
C9 = SubBytes(C8)
-
C10 = ShiftRows(C9)
-
C11 = C10 XOR K3
Where:
-
M: Plaintext message
-
K: Secret key
-
C: Encrypted message
-
K0, K1, K2, K3: Round keys
-
SubBytes(): S-box operation
-
ShiftRows(): P-box operation
-
MixColumns(): M-box operation
-
XOR: Bitwise XOR operation.
Additionally, the authors propose a key management system using Hyperledger Fabric and AES/GCM encryption. It adds an extra degree of security by guaranteeing that the encryption keys are only accessible to authorized individuals.
4.4 Data Integrity
To secure data integrity, the network's integrity component employs digital signatures and hashing. The auditing and logging component records access and modification activities and provides an audit trail. The proposed auditing and logging mechanism uses the Hashed Message Authentication Code (HMAC) algorithm. The steps for the HMAC algorithm are as follows:
Inputs:
-
Message (M)
-
Secret key (K)
Outputs:
Steps:
1. Select a secure hash algorithm H.
2. Hash the secret key K and use the resulting hash value as the new secret key if its length exceeds the block size of the hash function H.
3. If the length of the secret key K is less than the block size of the hash function H, pad it with zeros to make it equal to the block size of H.
4. Define two constants, ipad and opad, as follows:
5. Put the secret key K, the iPad constant, and the message M together. The concatenation is then subjected to the inner hash function.
6. After adding the secret key K and the opad constant together, step 5's outcome is hashed using the outer hash function:
7. The result of step 6 is the HMAC, which can be used for data integrity and authentication purposes.
In addition to the HMAC technique, we also recommend using a logging system based on the Hyperledger Fabric blockchain. This mechanism provides a tamper-proof record of all messages transmitted between devices, ensuring that any attempts to tamper with or alter the messages can be detected and traced.
The network includes a security architecture for authentication and authorization to implement a permission ledger. Public-key certificates support enrollment and transaction authorization. Each peer must receive an enrollment certificate from an enrollment CA (Chen et al., 2020). A transaction CA provides transaction certificates, allowing pseudonymous authorization for the peers (Singh & Kim, 2018). Numerous transaction certificates issued to the same peer can not be connected (Tools et al., 2021). States use a blockchain-specific key accessible to all peers possessing a blockchain enrollment certificate (C. Li et al., 2021).
The fabric network class is the most significant. It allows an application to connect the channels for notifications using identities, wallets, and gateways. When we set up the network, we made an admin account called 'admin'. The essential application dependencies indicated in package.json are installed during this procedure. Using the enroll.js application, we produce the private and public keys for admin. A Certificate Signing Request (CSR) is used in this procedure (J. Li et al., 2019). The admin enrollment utilizes a CSR to enroll 'user1'.
A query is used to read data from the ledger by applications. The application begins by bringing two important fabric-network module classes FileSystemWallet and Gateway (Chang & Ramachandran, n.d.). An application is connected to the network via this code by establishing a new gateway. A network can be divided into several channels, and this code connects the application to the network channel'mychannel' (Suhail et al., 2021). An application receives the notice that the transaction was successful once validated and committed.
The primary aspect that distinguishes HF from other blockchain systems is that the blockchain ledger in Hyperledger comprises a database such as CouchDB or LevelDB to keep track of the ledger states (Yaqoob et al., 2020). The ordering service is in charge of organizing network transactions. It produces blocks comprising transactions in a well-defined sequence coming from all of the network's linked applications.
The proposed data security architecture for smart cities using smart contracts and Hyperledger Fabric has several advantages over existing models, including:
-
Decentralization: The proposed architecture provides a decentralized and distributed system that ensures secure and tamper-proof data sharing among smart city stakeholders. This is in contrast to existing models that are often centralized and do not provide a distributed approach for ensuring data privacy and security.
-
Smart Contracts: Data access rules can be enforced and data-sharing policies can be followed as a result of smart contracts in the proposed architecture. This is a significant improvement over existing models that rely on manual enforcement of data access rules, which can be prone to errors and inconsistencies.
-
Scalability: Hyperledger Fabric, the underlying blockchain platform used in the proposed architecture, is designed to be scalable, permissions, and secure. This makes it well-suited for implementing the proposed architecture in large-scale smart city deployments. In contrast, existing models often lack the scalability required to handle the volume of data generated in smart cities.
-
Integration: This is an improvement over existing models that cannot often integrate different applications and services, leading to data silos and security vulnerabilities.
-
Performance: This presents a quantitative comparison of the proposed model to existing models and proves the practicality of the proposed architecture in real-world smart city deployments.