[OpenTRV-dev] Anti-tamper data from sensors
Damon Hart-Davis
dhd at exnet.com
Fri Jun 12 20:43:09 BST 2015
Thanks: I have captured this initial exchange here:
http://www.earth.org.uk/note-on-IoT-security.html#app5
Rgds
Damon
> On 12 Jun 2015, at 18:28, Bruno Girin <brunogirin at gmail.com> wrote:
>
> That's a good start. I would suggest the following for specialised use cases (where people are possibly happy to pay more):
>
> 3) Have some sort of movement detection so that the sensor can send an event if it is moved. This can be essential for sensors in industrial environments where it is essential to ensure that once the sensor is installed it is not moved. The typical example we've seen is industrial cold storage where sensors are installed to prove that the temperature in the fridge is always within legal limits. One typical tampering in such cases is to move the sensor from one "problematic" fridge to a less problematic one.
>
> 4) Have a way to keep the device powered for a few seconds when batteries are removed so that a "battery removed" event can be sent before dying altogether. The concentrator itself could auto-detect sensors that stop sending data but when that happens it can be for a number of reasons, some of them completely legit.
>
> In addition, the following metrics could help a concentrator / data platform identify sensors that need attention before something bad happens:
> - battery voltage: can then be used to predict when replacement is needed,
> - data link quality: can then be used to identify sensors with weak connections that are at risk of disconnection.
>
> Bruno
>
>
> On 12 June 2015 at 08:50, Damon Hart-Davis <dhd at exnet.com> wrote:
> Hi,
>
> My current thought, where we need to verify at some future point that sensor data points have not been tampered with, that we do the following:
>
> 1) Use the authentication mechanism between leaf/sensor and concentrator to confirm that data got to the concentrator intact.
>
> 2) Have the concentrator by default sign with a private key (for which the public part is retained) any incoming data that it has authenticated as above.
>
> So the leaf does not have to support keys good enough for long-term use for example.
>
> Rgds
>
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
More information about the OpenTRV-dev
mailing list