*The NEM team would like to thank Nikhil Jha (Telegram @ReverseCold) for contributing this project.*
The Internet of Things (IoT) is a massive developing category with a lot of potential applications. Unfortunately, many IoT implementations today rely on a centralized server to stay operational. Alongside the IoT movement, we have the blockchain movement, which provides distributed, secure computer systems to use. Let's combine the two categories into one using our very own NEM blockchain!
## Video
[](https://youtu.be/_dHvYuB6dsA)
## What We Can Do
1. Facilitate the ownership of one or a group of IoT devices of any kind on-chain.
2. Control, manage, and secure the daily use of IoT devices off chain (fee free and secure).
3. Allow IoT devices to communicate with others through the chain if necessary.
The third point is not discussed in this blog post, but here are a few scenarios where it could be useful.
An IoT device breaks and needs a replacement part. The IoT device sends a message to the user's phone with an order for the replacement part as well as labor costs to fix it. The user approves of the order, and the IoT device is fixed.
An IoT solar panel produces extra energy that the owner does not need. Other IoT devices want cheaper energy than the normal on-grid provider, so then they make an off-grid bid for that electricity and the IoT solar panel sells it to the highest bidder. This can be done either with approval from the user or without in the case it is automated with an [off-chain smart contract](https://nem.io/project/xemsign/).
## The Basics
There are a few NEM concepts that are central to this project. In this section, I will give a quick overview of a few of them.
With [Apostille](https://nem.io/project/apostille/), you can notarize a file on the blockchain. The notarization process creates a new account which is "colored" with that file.
In NEM, accounts can own other accounts, so one can make it such that they own the account that was colored with the file. The account colored with the file is now useless without the private key of the owning account. Additionally, the ownership of other accounts can be transferred by the owning account. These multisigged accounts essentially act as colored accounts that are updatable, can hold memos, and are transferable.
## Overview
What if we created a file that represents a group of IoT devices? For example, we could create a file for a house. It would be a plain text file containing the address, description, permissions for that certificate, a random string, and any other relevant information all in plain English. It doesn't matter what the file is at all, since the actual action occurs on the blockchain.
Once the file is notarized by Apostille, we have a private key account that can be owned by other accounts. Going into NanoWallet and converting it into a multisignature account with a single owner does exactly this.
At this point, the owned account and its private key can be given to the IoT device. This enables an application to make a signed and encrypted request to the IoT device (for example, switch fan to speed 3).
It is here that we run into a problem. In order for an IoT device to determine what account owns it, the device needs to make a request to an NIS. Unfortunately, it is possible for a 3rd party NIS to relay back malicious or incorrect information. The simple solution here is to run a node on every IoT device. Unfortunately, that can not happen due to space and processing constraints.
This issue can be resolved by storing a list of 30-40 supernodes and picking a few at random to check from and verify the answer.
Now that the IoT device has the public key for the account that owns it, the device is able to verify the signature, complete whatever action was sent to it, and send a signed/dated response to the sending application.
## Implementation
Whew, that was a lot of information. Let's look at how we would actually implement this in an IoT device. Due to the current fragmented nature of IoT, there is no one platform to build on that would support this method. As such, here's everything you need to implement this system in your own devices. The author of this article has a homemade IoT system secured by NEM on a Raspberry Pi, which will be shown in the video at the beginning of this post.
### Key Generation
First of all, an owned account must be created. This can be done by an end user through NanoWallet on any major desktop platform. Alternatively, a business could create a plain text file containing the company name and serial number of the device along with a random string and give it to the user to put into Apostille. The IoT device can then ask the user for the Apostille zip on setup and retrieve the relevant keys from there.
An even easier solution for the end user is if the IoT device itself creates an account and securely transmits the private key of the account that owns it. The user can then remove the temporary account from ownership and replace it with their own account.
The private key, even though it is temporary, should **not** be sent over the internet unless absolutely necessary (more on this in the next paragraph). The key can instead be displayed through any display the device has or locally using any other available method.
If the private key were to be sent insecurely over wifi, an attacker could take the key and bind it to their own account. This would disable the IoT device, as the user can no longer bind the given address to their own. This means that while an attacker can not actually take over an IoT device without the user's knowledge, it is still best practice to show the key locally. In a future update to NEM, codenamed Catapult, upgrades to NEM's multisig and multiple txs in one called "aggregate transactions" will offer elegant solutions to this problem.
### Commands
Commands can be sent to the device in whatever format is desired as long as they meet the following criteria:
1. Timestamped with a reasonable amount of accuracy and precision.
2. Signed with the key of the owning account.
3. Encrypted with the public key of the device.
It is also recommended to pad the commands with some random data to potentially reduce any unforeseen attack vectors with a specific vendor crypto implementation.
The demo later in this video simply encrypts messages in the following format (before signing and encryption).
```
UNIX_EPOCH/DEVICE_ID/{on | off}/RANDOM_BYTES
```
## Sample Implementation
Let's take a look at a sample implementation! If you would like to try this yourself, you will either need to have devices that are controllable by making web requests, or you can modify the code yourself to be anything you would like. This *can* be done with IFTTT if you would just like to see a demo, but note that using IFTTT doesn't give you the same security guarantees as a local, finalized version.
### IoT Controller / Hub Code
For demo purposes, this can be run on any computer. In a final application, it would be run on an IoT hub. Alternatively, in a future where every device is its own hub, similar code could be run on each device.
### Controlling Application Code
For demo purposes, this code needs to be run on a computer. Again, in any final vendor implementation, this would probably be a mobile application
Additionally, no effort is made to do device discovery. The "IoT Hub" network address must be input manually. This is already implemented in nearly all IoT devices, and reimplementing it is complex as well as outside the scope of this demo.
### How to Use
Apostille a picture of your house or an "IoT" device.
Clone the hub and app from git. Edit `app.js` in your favorite text editor and replace the variables at the top with relevant variables.
Do `npm install` to get dependencies.
First, start the server with `node hub.js` and then run the client with `node app.js`.
For more details (or an updated version of the instructions), please visit the Gitlab page: https://gitlab.com/nikhiljha/ionem.
3 Likes