Security and Privacy

Your data are private

Smart-Home data are sensitive. They say a lot about your habits, life style and private life.

We have taken great care to protect your data and we explain here how. This relies on three principles:

  • Ensuring that only you and no one else can access the sensor.

  • SSL encryption for any data leaving your home towards our cloud.

  • Giving you the possibility to avoid using our cloud and have your data stored in local infrastructure.

Ownership

Creating a Unique User ID

Your unique user ID is created at the time of your inscription on our cloud. This is the only time when you are required to use our service. Once you have created an account, it is associated with a Unique User ID or UUID. The UUID is the key that opens all your sensors. You will need it only if you wish to communicate with your sensor from your own python code for instance. Never trust it to any one or any other services. If any online services or other App need to access your data, for instance because you have subscribed to a service, the authorization will be handled by our cloud.

_images/gettingUDID.png

Then during the pairing, the UUID will be passed to the module by our App through an encrypted channel.

_images/storingUUID.png

The UUID will remain there, never communicated. The only way to alter it is through a factory reset that will delete it, making the module ready for a new pairing.

Obtaining your Unique User ID

You will need to obtain your UUID only if you want to develop your own control program. Apart from this case, you should never retrieve it.

The UUID can be obtained on our web site, in your user profile. Log in there and navigate to your user profile. You will find a section where your UUID is accessible.

Accessing your sensor

The MD5 secret phrase

When communicating your sensor through HTTP request, you will need to generate a md5 secret phrase. For instance, when you want to change the color of the LED, you need to POST a JSON payload to the module through an HTTP request.

The JSON payload is in the form of

{
        "udid": "10000fb38278",
        "secret": "549a82f8c22db1113106a9d246b8e67c",
        "setColor": {
                "ledColorName":"blinkingBlue",
                "duration":10
        }
}

The LED will then blink blue during 10 seconds.

The secret is the MD5 secret phrase.

Let’s assume that your sensor has the IP address 192.168.0.17 (you can get the address from your WiFi server, from our App, or by other methods we describe here).

In any web browser, enter the address http://192.168.0.17. This performs a simple HTTP request on the sensor. You will get the following reply:

{
        "type": "Ambient16",
        "version": "d07e9e98y",
        "udid": "10000fb38278",
        "deviceType": "1000",
        "token": "uulroqkt"
}

The sensor provides a token, here uulroqkt. This token changes every hour. It is required for the generation of the MD5 secret phrase.

1 - Obtain your UUID from our web site the first time. Let’s assume it has the value

40b3c94c9dd033351a296bc3d008e9e6

2 - Create a string by adding the token in front your UUID, a simple string concatenation. You will obtain the string

uulroqkt40b3c94c9dd033351a296bc3d008e9e6

3 - Use a MD5 function. There is one available in every programming environment (python, PHP, Java, C++ … ). The result of the MD5 hashing function will be

261f189efa04c376817bddef0b86477b

This is the MD5 secret phrase needed to communicate with the sensor. You will add it to the JSON payload under the key secret.

{
        "udid": "10000fb38278",
        "secret": "261f189efa04c376817bddef0b86477b",
        "setColor": {
                "ledColorName":"orange",
                "duration":30
        }
}

How this works: the shared secret method

In cryptography, a shared secret is a piece of data, known only to the parties involved, in a secure communication. In our case, the shared secret the the UUID. It is both secret to you and to the module.

1 - Both the sensor and its owner know the UUID as a shared secret.

_images/skStep1.png

2 - The owner makes a simple HTTP request, the sensor generate a token and sends it back. This token is public and can be known by everyone.

_images/skStep2.png

3 - The owner adds the token to the secret phrase. The sensor does the same on its side.

_images/skStep3.png

4 - Both perform an MD5 hash on this string addition. The hash scrambles the content of the string. No one can reverse it (or let’s say, the efforts needed to do that are probably not worth your data).

_images/skStep4.png

5 - The owner performs a HTTP request with a JSON containing this secret phrase.

_images/skStep5.png

6 - The sensor compare the secret phase it has received with the one it has computed. If both match, the sensor shall reply.

_images/skStep6.png

At no point in this transaction the secret phrase has been exchanged, but a scrambled version of it. As the token changes regularly, if a hacker catches the MD5 secret phrase in the WiFi transmission, he will have only a very temporary access as the token changes regularly.

SSL encryption

SSL encryption is used between the sensor and our cloud when its data are stored there. SSL is also used during the initial pairing with the App. However, the encryption requires a lot of memory and computing power. So, by design, it is mainly used when transmitting data and MQTT events outside the security bubble of your wifi network.

A user can still set the HTTP server of the sensor such that is answers HTTPS (SSL) request. This would be for limited period only. SSL require a lot of computing power and this high resource usage has an impact on sensing.

Also, when accessing the sensor in SSL mode, data storage in the cloud – that uses SSL too – is temporarilly suspended.

When in SSL mode, and if no requests are passed to the sensor, it will automatically return to non encrypted mode for HTTP request. SSL will then be used again for cloud data storage.