# Privacy-Preserving Data Mining on Blockchain-Based WSNs
## 3 Architecture
### Role-Based Access Control and Secure Data Mining with Smart Contract  
The smart contract enabling our architecture supports the following functionalities:  
* _Authentication_: allows sensor node authentication and stores the sensor node public key in the _KeyStore_;
* _Role-Based Access Control (RBAC)_: verifies user permissions. The smart contract contains the roles assigned to the public keys of authorized users. Roles enforce the set of DM algorithms that a user can execute on nodes of the WSN;
* _Query Submission_: authenticates the user with RBAC and writes the message authentication material in the _MessageStore_;
* _Message Authentication_: a view function called by sensor nodes to verify the message origin and permissions using the message authentication material;
* _Result Submission_: allows authenticated sensor nodes to submit the message result and remove the corresponding message authentication material from the _MessageStore_.  
The outlined architecture allows for the management of user roles with RBAC functionalities. A user entrusted with a specific role is allowed to construct a message made of the layered object and the payload, as is described in Section 3.1. The payload content is constrained by the user role, as defined by the RBAC.  
The user interrogates the _KeyStore_ to learn sensor node addresses for message construction. After message construction, the user calls the _query submission_ functionality providing the message authentication material. The message authentication material consists of a Merkle proof [36] constructed from the layered object layers, and the signature of the Merkle proof produced using the user's private key. The user then feeds the constructed message to the WSN.  
Each sensor node receiving a message performs the following tasks. The layer of the layered object that is dedicated to this specific node is deciphered, and the message is authenticated by calling the _Message Authentication_ function. The message authentication is performed by verifying the hash of the layered object's content against the Merkle proof in the _MessageStore_. The user's role and permission for DM model execution are also verified; this is conducted using the signature attached to the Merkle proof.  
The penultimate layer of the layered object holds a flag signaling its position. The sensor node detecting this flag calls the _Result Submission_ function and stores the message result. For simplicity, we assume that the message result is stored on the blockchain; however,  
Figure 2: A message of the privacy-preserving protocol described in [35], adapted for DM model processing. The layers of the layered object, containing pairs of symmetric encryption keys, include distinct keys. The first key is used for payload decryption, and the second key for payload encryption after DM model processing. Please note that encryption key pairs are chained through layers of the layered object.  
the result could be stored in a separate data store, submitting on-chain only the message authentication material, the hash of the result, and the resource locator.  
The user that issued the request tracks the chain for results associated with the message authentication material of the query submission. The obtained message result consists of the last layer of the layered object and the accompanying payload enclosing the DM model. Next, the user decrypts the layered object with its private key, revealing the symmetric encryption key that gives access to the payload content.  
Please note that problems related to Byzantine faults are out of the scope of our work, so we assume in this paper that the nodes collect the data properly, and execute exactly the tasks assigned to them.