## 4 A Privacy-Aware and Secure Decentralized Framework
### Decentralized Privacy-Aware Data Storage  
As demonstrated in previous work [68], the limitations of blockchain make it necessary to combine it with other technologies to enable fully decentralized storage and at the same time allow for data modifications. In this section, we show a decentralized data storage solution that provides different security levels and privacy protection.  
Indeed, data privacy requires addressing the diversity of actors and their roles to provide fine-grained data access and, sometimes, anonymity when disclosing particular data pieces, for example, public statistics about a building. To answer these requirements, we propose a pipeline that combines blockchain with a Distributed Hash Table (DHT), a Role-based Access Control model (RBAC), encryption mechanisms, and a ring signature to manage data access.  
Our solution stores metadata and DHT hash keys on the blockchain, while corresponding encrypted data are stored on the DHT that allows the data owners to modify their data.  
Figure 3: The figure shows the onion message traveling through the network and updating the DM model at sensor nodes in the message path. The onion head and onion body color change at each message processing to indicate the encryption operation.  
We propose a metadata structure that includes the date and time of data entry, user ID, DHT key, previous pointer, and data schema URI. We use the RBAC model to verify the actors' permissions to read and write data. In RBAC, a role represents a user's rights to perform actions according to their given permissions. A permission is an authorization to access multi-level data within a domain [69]. RBAC is suitable for our scenario as it allows us to define different roles, such as a building manager, room occupant, or scientist. Each actor has different permission to access the data depending on their role. For instance, with RBAC, we can define that the room occupant can access the fully detailed data values for the room but not others, while for the building manager, only the averages suitable to maintain and operate the building. The scientist could access all values without identification of which room in the building they correspond to.  
To complement RBAC, our framework provides different types of encryption mechanisms to secure the data in a decentralized fashion. An authorized actor can choose between asymmetric encryption or symmetric encryption to write and read data. Symmetric encryption is more suitable when a large quantity of data needs to be stored and is expected to be shared with many users, so it is stored encrypted together with the key, and when the data are requested, only the key needs to be decrypted and then encrypted with the requester's public key. Likewise, direct asymmetric encryption is more suitable for small quantities of data that are not expected to be shared with many other users. Please note that in both cases, asymmetric encryption is needed to ensure users' identities, symmetric encryption being an optimization for specific cases.  
We use ring signature to hide the actor's identity when sending data. This is useful, for example, when we would like to send data from one sensor within a building without revealing which sensor it is. To sign data, an actor uses their private key and the public keys of other actors. Therefore, no one can identify who signed this data, and it helps to maintain the actor's anonymity within the group. The ring signature is used to ensure the actor's identity privacy. Then, the data requester reads the data and validates the signature to verify that data are coming from an authentic source.