Garbage in, garbage out
By: Steven Pu
Tags: Blockchain, IoT, Auditing, Blockchain 101, Taraxa

A Practical Approach

Identity

To ensure that a data-generating device’s identity is protected, a set of public / private keys could be embedded into the device, and making the public key known plus making available onsite inspections of the actual hardware’s output are practical and practiced ways to ensure that the hardware is what it says it is. But that’s the easy part.

The tricky part is how do you make sure that this identity cannot be stolen and is known only to the device? You can use something called a secure element (SE), which is a piece of hardware that can generate public/private key pairs within the chip and is highly tamper resistant. A SE typically just does one thing: to sign messages, which is a fancy way of saying to provide proof of identity. If you’ve ever owned a credit card or a modern smart phone, you’ve benefited from the functionalities of a secure element.

Processing & Transmission

To protect that the data processing & transmission logic is secure, we make use of a microcontroller (MCU) with secure boot (SB). You can think of a microcontroller as a very simple computer.

SB ensures that only an entity with the right private key is able to load applications into the MCU. The application logic and associated checksums could be shared ahead of time with relevant stakeholders or simply open-sourced so they could be verified post loading.

What’s more critical next is that once the application has been thoroughly tested, we need to disable all modification functionalities from application and the MCU, including firmware upgrades. This is to ensure that the application logic is now absolutely immutable, not even changeable by the manufacturer at this point.

This creates obvious disadvantages, such as the fact that the application can no longer be upgraded. But in return, we have gained true device independence (in conjunction with the SE) from outside interference, with perfectly deterministic and unalterable behavior that could be trusted.

Digital / Analog Interface

This problem is tricky, and cannot be solved using hardware embedded on the data collection and relay device. Often creative mechanisms must be devised to ensure that the interface is not disrupted, but it is highly application-specific. Let’s use an example.

Suppose you have a refrigeration truck that’s part of a fleet from a cold chain logistics company, tasked with delivering fresh fish to local supermarkets. To ensure quality, the fish must remain within a certain temperature range. If the temperature is too high, the fish could spoil. If the temperature is too low, the fish could end up with inferior taste and texture. To ensure that the logistics company adheres to the contractual temperature range, the supermarket puts a temperature sensor in the truck.

But what if, the truck driver takes the sensor and puts it inside an ice cooler in front of the truck, while he dials up the temperature in the refrigeration unit to save energy costs? The sensor has no idea it has been moved, and keeps collecting and reporting data that’s within the contractually-agreed upon temperature range. The sensor has been duped.

One way to mitigate this risk is to hard wire the sensor into the refrigeration unit so it is nearly impossible to remove. But maybe this method could still be circumvented by say, wrapping a bag of ice around the sensor while keeping the rest of the truck above the contractual temperature range.

Another, potentially better (but far more expensive) way is to put a tamper-resistant seal on each package of fish, with separate a temperature sensor in every package. So if the driver tries take out the temperature sensor, they would need to break the seal, something that’s easily detectable and likely to break key terms of the contract.

As aforementioned, to resolve the problem of the digital / analog interface takes a lot of creativity, and the solutions tend to be highly application specific.