[OpenTRV-dev] Blockchain for anti-tamper and non-repudiatiot of valuable IoT data

Damon Hart-Davis damon at opentrv.uk
Mon Sep 28 10:29:13 BST 2015

> > I've been trying to understand blockchain to see if we could use it for our own purposes and I can't see how it would be used for that particular use case. If I understand things correctly, blockchain is a distributed ledger where every transaction is signed and all nodes have a full copy of the ledger. I think there are also variations to allow some nodes to only have a partial copy of the ledger.
> The data would be authenticated from node to concentrator and then signed there.
> OK, that makes sense. That said, is there a risk of MitM attack between the node and concentrator that could circumvent that or should that be dealt with by the authentication mechanism?

That’s absolutely the job of the authentication mechanism; one of the reasons for using AES-GCM.

> > I'm not sure where this ledger would go: it can't be stored on the sensors nodes as they don't have the capacity for it and even concentrators would be hard pressed to deal with it. That leaves a data platform but doesn't that go against the OpenTRV principle of having something that can work without that data platform?
> The long-term data store would be blockchain.  One copy with the factory/canteen/etc, one with auditors and one with (say) the H&SE.
> This has various neat features about soft real-time alerts, multiple copies off-site and un-tamperable.
> There are some issues of the speed of blockchain operations but there are possible solutions to that such as some simple batching.
> OK so that raises other issues about data privacy and differentiated data access. Considering use cases like this:
> 1. Customer has buildings in multiple jurisdictions with multiple H&S enforcement agencies,
> 2. Customer changes auditors at some point in time,
> 3. Some of the data gathered should not be shared with external parties,
> 4. Customer leaves one location and moves to another one (they need to have access to historical data at the old location until the date they left for some time after that date, and access to historical and live data at the new location the date they move in).
> This means that you need to make it possible to share different parts of the blockchain with different entities. How would that work?

The scenario I gave was only an example.

There are ways of encoding parts of the data with different keys to allow selective access to data in a public/shared database.

The customer could arrange to work with certified ‘escrow’ type organisations and segregate data by jurisdiction, ie there can be more than one blockchain.  Banks have to deal with this sort of issue already of course.

Let’s have some other ideas in the pot for these technical and legal issues.



More information about the OpenTRV-dev mailing list