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

[Bruno Girin]

On 23 September 2015 at 18:51, Damon Hart-Davis <dhd at exnet.com> wrote:

> Hi,
>
> In the case of (legally) important IoT data, such as food store
> temperatures, in Launchpad we’d like to be able to posit some mechanisms to
> make it hard to tamper with or repudiate the data in the sensor and all the
> way to the data store and afterwards.
>
> (Such entries might be a unique sensor ID, timestamp, temperature and some
> other sensor data and metadata, generated every few minutes by (say) 1–100
> devices in a building.)
>

We are talking to potential customers who have exactly this requirement.
The generic use case is industrial fridges that store perishable good and
where the owners have a legal requirement to 1) keep the fridges within a
certain temperature range and 2) demonstrate this is the case when they get
audited. The 3 specific use cases are:
- bakery
- butchers
- school canteens

>From a business perspective, the detailed requirements are:
1. Reliable data: the equipment needs to be calibrated and proved correct
within a certain error range;
2. Current data: they need to know as soon as any of the equipment fails;
3. Proof that the sensor measures data in the expected equipment:
3.1: at installation: prove that the meter planned for fridge A was
actually installed in fridge A and not B,
3.2: post-installation: make sure that the sensor that was in fridge A
wasn't moved to fridge B;
4. The data displayed is the one that was read by the sensor and not
tampered with in transit or at rest.

#1 and #2 are your classic sensor and data quality problem so nothing
really new there.

#3 is where additional sensors for positioning and movement can be useful,
although some of it can be manual too (e.g. take a picture of the install
and attach it to the meter info for #3.1). The implication is that there's
also a need to ensure #1 and #2 for all additional sensors that are used to
detect tampering.

#4 is about securing the whole chain and where it gets complicated because
you need some level of signing on the sensors themselves. So I assume this
is the part of the problem that blockchain could help solve.



> In a chat with Viv today (helping us with out business plan, but also a
> blockchain whiz) the possibility of using a blockchain mechanism to provide
> at least these two features in the long-term data store came up.
>

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.

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?

Even assuming you could have a lightweight ledger that is suitable for
concentrators, I'm not sure how that would work as OpenTRV is designed to
work in a star topology where you have a single concentrator for a bunch of
sensors, in which case you don't benefit from the distributed aspect of the
blockchain ledger and could go with a simpler solution. On the other hand,
that could work with a mesh network topology where you would have multiple
concentrators.

All this to say that I don't understand how blockchain would help and I'm
probably missing something important. Do you have the details of how Viv
envisaged this working?





> We’ve thought of some pros and cons, but I’m very interested in the views
> of our hive mind here!
>

I'm not sure whether my ramblings above make sense so please tell me if
they don't.

Cheers,

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150928/053b376b/attachment.html>