How to empower a Smart Home owner with a novel Blockchain architecture?
Part Two of a series on Blockchain & Smart Home: Ali Dorri
Empowering privacy-concerned users to control their data is key to drive Smart Home adoption. In this article, I would like to present a research paper I came across when trying to find a solution to privacy concerns in current Smart Home systems. Together with his colleagues from the University of New South Wales, Ali Dorri, Salil S. Kanhere, and Raja Jurdak published a paper called “Blockchain in Internet of Things: Challenges and Solutions” in 2016.
In their paper they outline a novel Blockchain architecture for a decentralized Smart Home system. Figure 1 presents an overview of this architecture. It consists of three parts: The Smart Home, the Overlay Network, and the Cloud Storage.
1. The Smart Home
Within the Smart Home all devices — smart thermostats/light bulbs, IP cameras, and other sensors — connect to a common Smart Hub or home computer. This hub gathers the device data and stores all related actions, such as a data transfer to some external party, in a local Blockchain (BC). Only the hub has access to this local BC and acts as its only ‘miner’ (although no Proof-of-Work is required).
As depicted in figure 2, a block in this local BC consists of a Block Header, a Policy Header, and all transactions related to sensor data.
In the Policy Header the user can granularly define access control rights for each device. He can for example, allow a third party service provider to access his thermostat data, but not his home camera data. That way, the user truly becomes the owner of his Smart Home data.
Now, how does a single Smart Home connect to others?
2. Overlay network
In order to connect to other Smart Homes and external service providers, the Hub connects to other Hubs through a peer-to-peer overlay network akin to the Bitcoin network. By using Tor to connect to this overlay network, an additional privacy layer is added.
In order to reduce network overhead and delay, not every node is required to store the information of other nodes. Rather, nodes are grouped into clusters and choose a so called “Cluster Head” (CH). Each CH maintains:
- Private Keys (PKs) of requesters: a list of PKs (e.g. from service providers) that are allowed to access data for the smart homes connected to this cluster
- PKs of requestees: a list of PKs of smart homes connected to this cluster that are allowed to be accessed
- Forward list: a list of transactions to be send to other CHs in the network
By storing these records the CH is able to forward incoming access requests from service providers to Smart Homes in his cluster. He would only forward such a request to a Smart Home in his cluster if the service provider is listed in the PK list of requesters and if the Smart Home is listed in the PK list of requestees. By choosing not to be listed, a Smart Home owner can prevent access to his home’s data.
Now, if granted access to a Smart Home, how could a requester — such as a third party service provider — connect the network and receive the actual data?
3. Cloud Storage
If a Smart Home owner wants to make user of services provided by a third party service provider, he can decide to store some of his device data in a cloud storage and then allow access for the service provider to a particular data set in that storage. The Smart Home owner defines both of these policies in the Policy Header of his local BC.
After data has been stored to the cloud, a service provider can request access to device data to provide a service to the Smart Home owner (Figure 3). For instance, he can require access to thermostat data to provide energy-efficient automatic heating services.
In that case, the service provider would ask a Cluster Head for access to a specific Smart Home device. When the Cluster Head finds both the private key of the service provider and the private key of the Smart Home in his lists, he forwards the request to the peers in the cluster. If he cannot find the private keys, he forwards the request to other Cluster Heads in the network. Eventually the request will reach the desired Smart Home’s Hub.
The Hub that has been requested to share data, the requestee, then checks in its local Policy Header whether the device is allowed to share the data with the service provider. If so, the Hub requests the data from the cloud storage, encrypts it with the service provider’s private key and sends it to the service provider. The hub finally records the send-transaction in the overlay blockchain network to prove it has transmitted the data to the service provider.
Conclusion
The architecture proposed by Dorri et al. ensures that a Smart Home owner stays in full control of his data. If he decides to make use of third-party Smart Home services, he can granularly choose to share data with a particular service provider.
This mechanism opens up new opportunities for privacy-concerned Smart Home owners that wish to enjoy the same Smart Home benefits as less privacy-concerned owners do today.
Please keep in mind that this article briefly summarized key concepts from Dorri et al.’s Smart Home architecture. To keep it digestible, certain aspects had to be left out. Thus, for a complete picture see the full research paper here.
