Provisioning 2.0

[Stijnwingens]

Provisioning 2.0

The provisioning process needs to be revised to address two main issues listed below

What

• Improve bruteforce protection on the PoP code.
• Remove the need for a 'device-create' step in provisioning.

Why

• The PoP code can easily be bruteforced with a powerfull enough machine. This means the encryption on the connection between device and phone can be decrypted during provisioning; the provisioning process will become vulnerable to a MITM attack.
• The PoP is equal to the device activation token in the api. This token can also easily be extracted from the api by bruteforce (, which we highlighted previously,) in the same manner as with the qr-code, meaning an attacker can steal activation tokens from the api. With this activation token, an attacker can register devices as his own, or use it to decrypt the provisioning communication from the start, since the PoP code (=activation token) is known by the attacker before the users begins the process. This hugely increases the ease with which an attacker can break into the provisioning process and wreak havoc.
• The device create step requires a huge amount of manual work during device preparation. This is detrimental to the organisation's desire for scalability and ease of use. The removal of all this manual work is a high priority for the organisation, as long as security is not weakened.

How

• The qr-code will be displayed on a screen with the M5CoreInk's display.
• The PoP code in the qr-code will be adjusted so the entropy is increased dramatically.
• The PoP code will no longer represent the activation token in the database. This will allow for the removal of the device create step. The provisioning process will from here on out rely on the verified account that is present in the app. More on this below.
• The qr-code will be dynamic: every x seconds, the PoP code (and thus the qr-code) will change. This will make replay attacks more difficult.

Details

Currently, a device is registered during device preparation. The device-name, device-type and device activation token are manually entered in a request to the API. This will allow the device to be activated with THAT specific activation token. This presents a number of issues already:

• The manual request requires a lot of manual labor that should not be needed.
• When the device is activated, the device activation token is deleted from the database, so it can no longer be used as valid device activation token. This is preventing a device from being re-provisioned when for example a WiFi passphrase changes.

After the device is created, a qr-code with the correct information, including PoP, is printed and stuck onto the back of the device. This means anyone with vision on the qr-code has access to a static, extremely important token. This token is the PoP token used to encrypt the connection during provisioning, but also the activation token used to activate the device. By making this token change every x seconds (or minutes), we can prevent the attacker from knowing the PoP used at the time of provisioning. This presents a clear issue however: how do we know that an actual device is being activated?

How do we know that an actual device is being activated? Simply put: we need to trust our users. This is of course not preferable, but unfortunately, neccessary. Let's explore why. A user must always have an account to be able to activate devices. This means we manually gave this user an account. They are logged in with this account in the Warmtewachter app. This app is the only way to activate devices the correct way. A device added with this account is therefore a device we must have sent them, meaning: if a user scans a device, we trust that the user is not tampering with the qr-code and/or connections. This leaves the door open for several risks:

• The user makes a photo of the qr-code currently displayed. They would be able to scan that qr-code again. This means they can theoretically add an unlimited number of devices and send data from these fake devices, thus destroying the integrity of the entire dataset.
• The user is not using the app. The user was able to steal their own or someone else's account session token from the app and use it to manually send requests from a different client. This means they can theoretically add an unlimited number of devices and send data from these fake devices, thus destroying the integrity of the entire dataset.

The first risk is easily addressable. We can program the app to only create a device with the api if it is able to establish a connection with the device with that PoP. This means a device following Unified Provisioning Protocol with THAT PoP and device name must be present. It is very unlikely that someone is able to simulate this or even deploy a real device like this. It is certainly not possible on a larger scale. Therefor we should accept any risk that remains from this scenario.

The second risk is more complicated. First off, we estimate the chances of a account session token to be stolen from the app or otherwise leaked very small. Of course, the implications of this secret leaking are very large. Unfortunately, we are unable to include a solution for this risk in the current timewindow. A solution that could be used to solve this issue and build a much stronger bond of trust between devices and the phone is by implementing a form of remote device attestation. Simply put, remote device attestation is the term for a device proving its identity/validity to a different entity via a remote connection. There are ways to do this, but they all take much more time than we have right now, or simply do not apply to our devices/services. More on this at Future versions.

Future versions

In the future, remote device attestation should be added in some way. This is a too big topic to fully cover in this issue, so to keep it simple: with our devices, only software-based remote device attestation can be used. This is a complex topic and is a solution that is still not completely water tight. Therefor, more research and a lot more development time seems neccessary.

Considerations

• It is clear that the current solution is insufficient. The solution proposed is also not watertight, but definitely an improvement. We have to accept that it is not possible to improve the security of the provisioning any further in the extremely short time left. A future project, dedicated to remote device attestation, is most definitely needed.