Securly connecting IoT-Devices to the Internet

Securly connecting IoT-Devices to the Internet

Internet-enabled devices, as the name suggests, must be connected to the Internet. The connection to the Internet is often established directly via the WiFi router, as in the case of Amazon Echo, for example. To do this, the user must provide the device with access credentials. In many cases, the devices do not have touch screens or other direct input options. The connection to the WiFi network is then established via another device, usually the mobile phone. This is also often the case with IoT devices. But how can this initialization be performed in a secure manner?

Trust between device and user

When initialising using a mobile app via Bluetooth or a WiFi access point, the following points must be ensured:

  • The connection between the device and the mobile phone must be encrypted, otherwise the WiFi access data could be intercepted.
  • The user must be certain that he is really connected to the device, that he wants to connect to the internet. Otherwise, a eavesdropper can pretend to be the device and then intercept the WiFi access data.
  • The device must ensure that it is also connected to the actual owner. This is especially important for devices that deliver sensitive data (e.g. a camera). An attacker could otherwise hijack the device, even if only temporarily.
1.) Mobile app establishes connection and device authenticates itself. 2) App checks the authentication. 3.) App transmits access data. 4.) User proves ownership. 5.) Device establishes connection to backend.

A secure connection between user and device

Since there is a radio connection between the user’s mobile phone and the device, it is basically eavesdropable. WiFi access data or other sensitive information shall only be transmitted via a tap-proof connection.

A typical stack for initialization looks like this:
The device first creates a WiFi access point. It should only be open as long as necessary for the initialization process. The mobile phone connects via this access point using a mobile app. The app then communicates with the device via a lightweight HTTP server running on the device.

The WiFi connection must be secured by a secure standard such as WPA2-PSK. In this special application, the HTTP connection between the device and the mobile phone can be left unencrypted. HTTPS encryption is only necessary if an attacker can eavesdrop on the transmission of data between client and server. In this case, however, there is a direct connection between the mobile phone and the device that is already encrypted via WPA2. However, the prerequisite is that the user and the device identify each other before the data exchange (see below).

Lack of standards for the initialization of IoT devices

Unencrypted HTTP connections can only be established using workarounds, for many available clients. However, it is also not easy to establish an HTTPS connection. There are no valid certificates for IoT devices. The devices have no unique names that can be used for certificates. IP addresses as a subject in certificates are also possible, but are not supported by all HTTP clients. Self-signed certificates only work with a deactivated certificate validation on the client side. Although device initialization is a very common use case, there seems to be no standardization efforts to date. On the contrary: It is more likely that mobile HTTP clients will become more restrictive in the future. It is even conceivable that common HTTP clients will completely prevent unencrypted HTTP connections in the future.

Device need to have an identity

A potential attacker could wait for new access points for initialization and then pretend to be the access point itself. He would then be able to steal the WiFI credentials.

It is therefore absolutely necessary that the device authenticates itself to the users (or the mobile app). For this purpose, the device is assigned a device identity as part of the production process. The identity consists of either a public-private keypair or a symmetric key that only the device and an authentication service in the back-end share. The mobile app then uses this service to ensure that it is actually connected to the correct device.

However, realizing a secure device identity on the device side is a challenge in practice. The devices usually have neither much computing power nor much RAM available. Secure algorithms for authentication are often resource-intensive. Read more about this in one of our other blog posts.

Proof of ownership

Not only must the device authenticate itself to the owner, but the owner should also identify himself as the owner. If he does not, an attacker could try to hijack the device as soon as the initialization is started. This poses a risk, especially for devices that can provide sensitive data. For example, an attacker could hijack a smart home camera to spy on the inside of a home.

Compared to other attacks, however, the consequences are less serious. Usually only the owner has physical access to the device and can switch it off in an emergency. The user is informed by the app that the device has already been assigned to another user and can react accordingly.

Since device manufacturers often do not know the final owner, the owner must have a way to distinguish himself from the attacker:

  • Physical proximity to the device. For example, authentication via NFC is only possible when you are close to the device.
  • Einen Authentifizierungs-Code (z.B. QR-Code) der dem Gerät beiliegt.

Both are quite burdensome for the user. If temporarily hijacking the devicedoes not pose a great risk, this additional security can be omitted. For example, it is not a great concern if a home temperature sensor is read by an attacker. The app already notices during initialization that the sensor was linked to another account. The owner can then be prompted for a reset.

In general, however, the linking of a device to its owner should take place as early as possible. An example are Amazon devices that are linked to an account at the time of purchase.

Initialization procedure

As described above, the initialization flow looks like this (see also the sketch above)

  1. The mobile app connects to the access point of the device. The device transmits proof of its identity
  2. The mobile app checks the validity of the device identity via an authentication service
  3. The mobile app transmits the necessary data for initialization, especially the WiFi access data
  4. (Optional): Before the device establishes a connection and transmits data, it requires the user to provide “proof of ownership”, e.g. via a QR code
  5. The device establishes a connection with the WiFi router and connects to the backend

Conclusion

Although it is a common use case, there are neither standards nor libraries for initializing IoT devices so far. Initialization is a security-critical process. Time and again, IoT devices are hacked where the initialization flow was not 100% well thought out. We have looked at three points that need to be considered.

OneIoT offers a secure initialization solution, with individual solutions for these aspects. The development for this was complex and we hope that standards will be developed in the future. This would help to avoid errors during initialization and significantly reduce the workload for device manufacturers.

Christof Tinnes

Christof Tinnes

Co-Founder

Leave a Reply