Sesame-Server

Server code for the Sesameproject. The server acts as a relay for messages between the device (ESP32) and the client (iOS App), by providing a DNS entry to which both devices can reliably connect. The device is permanently connected to the server through a web socket, so that the server can push new requests to the device. The client performs simple POST and GET requests to the server to upload keys and retrieve device responses.

Operation

The server provides APIs for the device and the iOS client. The API for the device consists of a single entry point to establish a web socket connection for bidirectional communication. The device authenticates with a pre-shared key to prevent other actors from replacing the device.

The client API has multiple routes to inquire about device status and reponses, and to send a key to the device.

Access

The server is configured to listen on port 10000.

Security

The system does not rely on any cryptographic algorithms, which are difficult to execute and verify on resource-constrained devices. The system relies instead on pre-shared one-time keys, which are hardcoded into the device when flashing the software. The same codes are stored within the iOS App.

Protection against attacks

One-time keys are only vulnerable to attacks where they are somehow observed prior to use. Within this system, this can occur on the embedded device, the client App, the programming hardware, and during transmission of the codes over the network.

The device itself is secured against physical attacks by being inside the house which it opens. An attacker with physical access to the device has already succeeded in bypassing the system.

The iOS device is secured by the mechanisms deployed by Apple against unwanted access to app data. These protections are deemed sufficient for this application, and would be difficult to further improve within this project.

The programming hardware is also protected by similar mechanisms, and the codes only reside on this system when initially programming the device, and are afterwards securely deleted.

The one-time codes are vulnerable when being transmitted over the network, including being observed or tampered with on the server. To prevent this, each key is associated with an id, and keys are expected to be used in the correct sequence. Using a key with a higher id invalidates all keys with lower ids. This prevents cases where an attacker blocks the use of a key to use it at a later time.

For the case where an attacker blocks all keys from being used, then all keys must be invalidated manually be uploading new keys to the device.

The device itself may be vulnerable to attacks due to errors in the software stack, including WiFi and other features. The device is isolated from the global network through the routers firewall, and only exposes the web socket connection, which is secured by SSL.