# Internet of Things and Blockchain Integration: Security, Privacy, Technical, and Design Challenges
## 3 RQ 1 and RQ 2--Current Challenges and Recommendations to Enhance BIoT Integration
### BC-Based Security Issues
#### 3.1.1 Confidentiality  
Cryptography and encryption technologies are commonly used in private BC to ensure confidentiality. Allowing any network member to access, write, audit, and maintain the blocks is a standard approach to ensure availability in public BC. Only preselected nodes can read or write in private BC. Transactions can only be performed by participants or preselected nodes who hold the private keys for authentication [113]. Furthermore, the devices that will be used as nodes may present a confidentiality challenge. These node devices may vary in terms of security policies implemented due to limitations in specifications, capabilities, manufacturer restrictions, or challenges in the configurations and programming [63; 154]. Multichain enables integrated management of user permissions to ensure that only selected participants may access transactions, restrict the types of transactions that are authorized (authorization ensures that the user has permission to conduct a certain activity), and mine new blocks safely without the need for PoW and associated expenses. BCs of the private and consortium types aid in the solution of this problem, but they restrict user access and limit the degree of decentralization. As a result, for certain use-cases, an optimal tradeoff should be implemented [44].  
Because transaction pattern analysis may be used to establish the identities of users or devices secured by public keys, it is difficult to reveal an IoT private transaction history in a public BC. Entities must completely grasp their privacy demands to evaluate if a private or hybrid BC is best suited to their needs [86]. A BC technique known as Mimblewimble should also be discussed, which is a method of organizing and storing transactions in such a way that all transactions appear to an outsider to be random data. Only the participants  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Category** & **Challenge** & **Best Practice** \\ \hline \multirow{6}{*}{Security} & Confidentiality [26; 44; 86] & \(\bullet\) & Tradeoff between decentralization and authorization \\  & & \(\bullet\) & Mixing techniques (e.g., private and public platforms) \\  & & \(\bullet\) & MW technique \\ \hline \multirow{2}{*}{Integrity [76; 87]} & \(\bullet\) & Hierarchical BC design \\  & & \(\bullet\) & Message identification and authentication \\ \hline \multirow{2}{*}{Availability [76]} & \(\bullet\) & All countermeasures should be examined \\  & & \(\bullet\) & Data storage, theft, cleaning, and destruction techniques \\ \hline \multirow{3}{*}{Security} & \multirow{3}{*}{Authentication [57; 75; 76]} & \(\bullet\) & Combining smart contracts with lightweight encryption methods \\  & & \(\bullet\) & SSI and DID techniques \\  & & \(\bullet\) & Message identification and authentication \\ \hline \multirow{3}{*}{Vulnerabilities [10; 88; 89]} & \(\bullet\) & Elliptic Curve Encryption, attribute-based signatures, digital \\  & & certificates, timestamps for uniqueness, cryptographic key sizes \\ \cline{1-1}  & & \(\bullet\) & Secure channels, separation of transactions, low priority to newcomers \\ \cline{1-1}  & & \(\bullet\) & Multi-chaincode access control on a hierarchical BC \\ \hline \multirow{2}{*}{Trust [27; 66]} & \(\bullet\) & Globally consistent reputation assessment model \\ \cline{1-1}  & & \(\bullet\) & BC digitization \\ \hline \hline \end{tabular}
\end{table}
Table 6: Recommendations for reducing the negative impact of security challenges.  
in the transaction have access to the data. As a result, Mimblewimble is also associated with the notion of confidential transactions [26].