Security is a big part of Iota, something I consider a critical component.
Iota is about more than sensors spread throughout your house, it can also control things and the last thing you want is for your neighbour to ‘accidentally’ control the lights in your home at 3am in the morning!
Iota also allows complex rules to be established, such as “if the room temperature drops below X after 8pm, turn my electric blanket on”.
With complex rules possible, all parts of the system need to be secured, otherwise an attacker could control things by sending fake temperature readings.
Security - Hard to get right
One of the strong motivators for including security measures into Iota, is that security is a hard thing to get right.
An attacker only needs to find one hole in the system, while the person writing the code has to try and fix all holes in the security.
By including security in Iota from the beginning, everyone benefits from the shared code and fixes made against it.
We won’t get everything right from the start, but as it is improved and strengthened, everyone benefits.
There are three main parts of Iota’s security design:
- Message IDs
- Key exchange
As Iota sends messages over a radio link, anyone with compatible radio modules, or even a Software Defined Radio can listen in to the messages sent, resend them, or modify and resend them.
Encryption hides the contents of the message using a mathematical algorithm and a secret key that should only be known by the communicating nodes.
This prevents attackers from reading and modifying the messages sent and received.
Iota uses the AES encryption standard, which is quite strong whilst still being simple enough that it can be done on an 8-bit micro controller.
Encryption alone is not enough though.
If you send the same message repeatedly, it will look the same each time.
The attacker might not be able to read the contents, but they could copy and replay the message, and still influence your system.
This is known as a replay attack.
By simply adding an increasing number (the message id) to each message the encrypted message changes significantly each time, even if the rest of it is unchanged.
The receiving node knows what message ids it has already seen, and rejects repeated message ids, preventing a replay attack.
The last challenge is how to ensure the communicating nodes have the same key without an attacker getting a copy.
If you send the key over the radio link, it will have to be unencrypted, and during that time an attacker might be listening.
A better option is to send the key “out of band”, which means through a different mechanism.
Iota does this through a physical connection (such as wires).
When you want to add a new node to your Iota system, you connect it to the hub node.
The hub generates a new random key and sends it over the wired connection to the node and keeps a copy.
This prevents an attacker from listening in to the key, keeping it safe.