Local Control Service

ESP RainMaker offers a facility for controlling devices over local control, as demonstrated in the Local Control documentation. Originally, the local network communication was established using plain text HTTP. However, enhancements have been made by implementing security measures using ESP-IDF's protocomm_security1. This offers Proof of Possession (PoP) 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 parameters as below:

{
    "Local Control": {
        "POP": "a8d8e5ce",
        "Type": 1
    }
}

How Does This Work?

Whenever a node gets associated with a user, clients such as mobile apps can check if the node supports secure local control by searching for the local control service in the node configuration. If available, it gets the PoP from the node parameters. In cases where the node is detected on the local network through 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. In this context, it is generated by the node itself. This approach is taken because the provisioning PoP is programmed during manufacturing and stays the same throughout the lifetime of the node. However, it gets used only when the node is being set up, thus minimizing the 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 this situation still poses a potential risk.

The approach of having the PoP generated randomly and reported via node parameters has two benefits:

1. Since the PoP is generated and stored in NVS, it can be changed by performing a factory reset. The service can also be extended to allow users to periodically change the PoP if required.
2. PoP is available to all users with whom the node is shared.

Given that local control not only provides a swifter experience but is now also secure, it is advisable to enable it as the default setting in your projects. 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.