We develop a protocol for computer remote control of a certain kind of toy. It's basically a sensor and actor network that is usually connected to the user PC via serial port or USB. Now some users wish to connect via Ethernet, and we want to design some kind of gateway in an embedded device.
It is expected to be used only in home LANs (e.g. from mobile devices through a WiFi router), but those shouldn't be considered secure and there's always a chance of being exposed to the internet. The risks involved are manifold:
- those toys are expensive and could be destroyed through abuse
- the environment might be harmed by messing with the actor power supplies
- the devices are capable of (unsecured) firmware updates and could be taken over or bricked
- generic disturbance of service operation
- eavesdropping on private data
The embedded gateway device would expose some kind of server that accepts connections - which need to be limited to authorised ones. How to do this?
After the initial idea of wrapping our serial protocol in UDP packets (for low latency and low overhead), we considered TCP to avoid dealing with packet loss in wireless networks. TLS is the next logical step, which provides encryption1. But how to do the authentication and authorisation?
Is TLS applicable at all, when used in a non-web context? We don't necessarily have host names, or even internet access, and I don't know how to validate the certificates. We cannot use a CA, so our PKI would look different and I don't know what security holes are introduced by manually managing certificates. It's probably already enough of an issue to get each server - each device - its own randomly generated certificate. (I also found these two questions dealing with similar issues)
Would some kind of pairing process (similar to Bluetooth or WPS) solve the issue with unvalidated certificates? The embedded device would be equipped with one simple push-button to accept a client2, and the client would remember ("pin"?) the server certificate. This first connection would be susceptible to a MITM-attack, but subsequent connections would not. Does that sound viable and secure? I'm doubtful about home-brewed schemes.
An alternative to the pairing I considered would be a password authorisation scheme, where the client sends a password to the server to gain access.3 However, users tend to choose weak passwords, and also I have no idea how (i.e. which protocol to use) to send the password over the unsecured connection - still not having validated any certificates -, avoiding MITM or replay attacks.
Please help me find a good solution - either by answering the above questions or by suggesting a completely different approach that I missed entirely. Our main objectives/restrictions are:
- good usability even for non-technical users - without any administrative maintenance
- simple implementation with widely available libraries for many programming languages
- high level of security (if necessary ignoring setup phase where it might be impossible)
1: As long as used with the right settings, I gathered.
2: I guess we must not forget a way to remove clients
3: With the initial password randomly assigned to each device and printed on the bottom