Local Control Service
ESP RainMaker offers a facility of controlling devices over local control as you can see here. Originally, the local network communication was based on plain text HTTP. However, recently we added some security on top of this using esp-idf's protocomm security 1. This offers Proof of Possession based access control and encrypted communication.
Specifications
Once Local control is enabled with security level 1, the following service gets added to the node configuration:
{
"name": "Local Control",
"params": [{
"data_type": "string",
"name": "POP",
"properties": [
"read"
],
"type": "esp.param.local_control_pop"
},
{
"data_type": "int",
"name": "Type",
"properties": [
"read"
],
"type": "esp.param.local_control_type"
}
],
"type": "esp.service.local_control"
}
The value of POP (Proof of Possession" and control type are available in node params as below
{
"Local Control": {
"POP": "a8d8e5ce",
"Type": 1
}
}
How does this work?
Whenever a node gets associated with any user, the clients (like mobile apps) can check if the node supports secure local control by looking for the "Local Control" service in the node config. If available, it gets the PoP from the node params. If that node is found on the local network using mDNS, this PoP is used to establish a secure session with the node and then communicate with it using esp-idf's local control feature.
Note that the PoP here is not the same as that for provisioning, but instead, is generated by the node itself. The reason for this is that the provisioning PoP is programmed at manufacturing time and stays the same throughout the lifetime of the node. However, it gets used only when the node is being set-up and so, there is not much risk associated with the code leaking. But, if the same code gets used for local control and gets leaked, anyone on the same network can access it, even if the node is reset and re-provisioned. Of course, in most cases, the clients on the same Wi-Fi network could be trusted clients, but it is a risk nevertheless.
The approach of having the PoP generated randomly and reported via node params has 2 benefits
- Since the PoP is generated and stored in NVS, it can be changed by resetting to factory. The service can also be extended to allow users to periodically change the PoP if required.
- PoP is available to all users with whom the node is shared.
Since local control gives faster experience and is also now secure, it is recommended to enable it in your projects by default. However, note that secure local control can currently work only with esp-idf release/v4.2 (later than release v4.2.2), release/v4.3 (release v4.3.2 onwards) and all the other newer release branches.