Below are a few examples and possible use cases for using microcontrollers, such as those used in Arduino and general IoT devices, in conjunction with EOSIO blockchain.
Some microcontrollers are able to generate ECC signatures for arbitrary data. There’s also an open-source library that works on a range of processors. Also Sparkfun is producing an HSM board which is able to generate private keys securely and sign data.
Microcontrollers are sometimes limited in connectivity, or the environment limits their network access, so signing full EOSIO transactions is not always practical. It may require significant resources, and a valid transaction needs a reference to a valid block ID, which is not older than approximately 9 hours.
Secure data logging
Arduino data loggers have been in use for quite a while, but so far I haven’t found any open standard that solves two important problems in data logging:
- authenticity: the origin of data needs to be provable and verifiable;
- integrity: the recipient of data needs to be sure that nothing was added or removed from the dataset.
There needs to be an open standard and open-source reference software, so that the data is compatible across different solutions and verifiable by third-party software.
Also there needs to be an open standard for transmitting such data, especially over slow and unreliable media, such as LoRaWAN, Bluetooth Low Energy, or UART.
Once the data reaches a host that is connected to a blockchain, the host can push the data to a smart contract for verification and processing. There can be a number of purposes for doing that. Also EOSIO is performing well with hundreds of writing endpoints, so it can simplify processing of real-time input from thousands of sensors or data sources.
If your microchip is controlling something important, like a power plant turbine or a bank safe, you want all commands to be signed, verifiable, and chained in a strict sequence.
A blockchain can facilitate in securing such data and transmitting it to multiple remote locations synchronously.
Again, an open protocol will help in establishing interoperability and compatibility between software solutions.
Suppose you have a remote facility that is not always connected, or even disconnected completely. There might be a short window of connectivity (for example, via a LoRaWAN satellite that is flying over only once a day).
A management system can issue digital certificates, confirming which public keys are allowed to access the facility. These certificates are placed on people’s devices, such as smartphones or smart cards. So, a person can come up to the facility, and the microprocessor can validate the certificate, and send a challenge to the user device to sign with the private key.
After the authentication procedure is done, the microcontroller would open a door or trigger other actions on the location. The act of authentication will be logged and eventually transmitted to the blockchain.
The visitor’s smartphone can also replace the global connectivity for the on-site controller: it can deliver updates to the software and trusted certificates, and take away the accounting log for further uploading to the blockchain.
I opened a Telegram group for further discussions on this matter: https://t.me/microchips4eosio