# Utilizing Blockchain for IoT Privacy through Enhanced ECIES with Secure Hash Function
## 3 Modified ECIES with Secure Hash Function
Hence, the use of the hash function protects the value of the key being detected even if the hash function is known. As a result, private and public keys are secured and provide resistance to several security attacks enhancing user privacy protection. **Request Control**--Once access request is published, new public and private keys are produced to avoid replay attack and profiling [14], where the uniquely generated hash is used to compute the private key instead of a randomly chosen key. The transaction to access the data is constructed and signed using the GSign algorithm. Request transaction data are then encrypted and verified using different keys. Since the randomly generated points on the elliptic curve can be detected by any attacker as multiple keys to encrypt the transmitted message, the proposed solution uses a KDF algorithm [37] to derive multiple keys from one secured master key. KDF follows an iterative process to derive multiple keys and ensure that an attacker is not able to identify origin of the master key [32]. After keys are generated, request transaction data are encrypted using the Enc. algorithm of CEIES and is authenticated using the MAC algorithm, where the encryption process is given by:  
\[C_{P}=Encrypt(T_{r},\delta_{P}),\]  
and \(C_{P}\) represents the encrypted access request transaction data that is then uploaded to the blockchain network. **State Delivery**--In this phase, consensus nodes in the blockchain network monitor the access request, checking the transaction verification using a signature verification algorithm. If the transaction is verified, it is decrypted using the Dec algorithm of CEIES and private key [14; 30], which provides target device information and control orders, given by:  
\[(D_{i},C)=Decrypt(C_{P},\delta_{R}),\]  
and \(D_{i}\) and \(C\) represent the target device and control information, respectively. The consensus node of the blockchain network formats the data request to ensure the data access request is received from a valid requestor. The information access request to the user and response from the user is encrypted and authenticated. The authentication tag is recomputed to ensure the response is received from a valid user. If the authentication tag matches, only then the response from the user is decrypted to obtain response information about the request. **Chain Transaction**--The transactions are retrieved in the smart contract of the blockchain network, where signatures are verified to check the validity of the transaction. If the transaction is valid, they are collected, and the block is formed. The consensus nodes use the Practical Byzantine Fault Tolerance consensus mechanism to chain the blocks [38]. The user access policy is then updated, which helps in managing consents set by the user. **Dispute Handling**--The unusual transactions are traced by detecting abnormal and unusual behavior, where GTrace algorithm is executed to reveal the real identity in the unusual transactions. It helps to prevent impersonation attacks by identifying unusual behavior and showing the real identity of the attacker. The flow of the modified ECIES is shown in Figure 2, whereas the steps of the proposed scheme are shown in Algorithm 1. ```
0: Security parameter \(\lambda^{n}\) and Transactional Request Data \(T_{r}\)
0: Response Data
1:Generate \(\sigma^{n}\leftarrow\lambda^{n}\)
2:Compute \(h(m)\gets m\)
3:Compute \(\delta_{R}\gets h(m)\)
4:Compute \(\delta_{P}\leftarrow\delta_{R}*(E_{x},E_{y})\)
5:Construct \(T\leftarrow\delta_{P}\)
6:Encryption \(C_{P}\gets Encrypt(T_{r},\delta_{P})\)
7:Authentication Check ifTagsMatch \((D_{i},C)\gets Decrypt(C_{P},\delta_{R})\) elseReject \(C_{P}\)

**Algorithm 1** Proposed ECIES with Secure Hash Utilization. Figure 2: Flowchart of the Proposed Elliptic Curve Integrated Encryption Scheme with SHF.