Proposal for sensors authentication

[Fernando Jiménez Moreno]

Hello folks,

after having a brief IRC chat with Fabrice the other day about how we could protect the data that we send from the sensors, I spent a few minutes drawing this diagram [1] with the flow that I have in mind for that.

For the use cases that we have I don't think we need to encrypt the data that we get from the devices (apart from the obvious encryption that the TLS channel provides), in the end, this is an open data platform :P. We just need a way to verify that the data that we get from the sensors really comes from a known sensor and has not been modified in its way to the server.

One way to do this is to sign this data with something known about the sensor.

I think we could use Hawk [2][3] for that. The main reason to choose Hawk over anything else is that it provides protection against replay attacks, which seems to me like something that we want to have. We used this auth scheme in the past in other Mozilla projects, like Loop or the Firefox Sync key server, so we have some experience with it.

The basic flow would be something like:

0. The first thing the user needs to do is to authenticate herself with the 3rd party identity provider (IdP) that we choose to support. This can be Firefox Accounts, Google, Facebook... whatever we want. The SensorWeb client will need to trigger the auth flow defined by the chosen IdP, which will most likely be an OAuth flow.

1. Once the IdP auth flow is done, the result will likely be an auth token.

2. After that, the user is able to start the sensor setup process from the client app providing the obtained auth token.

3. When the sensor runs for the first time (or after a reset), it should generate a device identifier.

4. As part of the setup process, the sensor will register itself with the SensorWeb server, providing its device identifier and the user's auth token. This request needs to be authenticated with Hawk using the device ID as Hawk ID and a shared secret (known by the server and common to all sensors) as the Hawk key.

5. The server will need to verify the request's Hawk auth header and also verify the user's auth token against the IdP.

6. Depending on the IdP that we choose, we'll get an user identifier (before or) after the verification. In case that we use FxA, this will happen as result of the verification request.

7. Once the server knows the user is real (at least for that IdP) and it has verified the signature of the registration request, it can register the sensor ID associated to that user ID. During this registration process a new secret is generated and stored along the device ID. This secret will be used as Hawk key for subsequent sensor requests. The response of this process should be a Hawk token that results of wrapping the device ID (Hawk ID) and device secret (Hawk key).

Please, let me know if this makes sense to you.

Cheers,

/ Fernando

[1] https://www.gliffy.com/go/publish/11083803
[2] https://github.com/hueniverse/hawk
[3] http://alexbilbie.com/2012/11/hawk-a-new-http-authentication-scheme/

[Marcus Cavanaugh]

Does something here prevent the user from modifying the software and sending fabricated data anyway?

It sounds like this places firmware requirements on the sensor(s?) itself. Is that something accessible to us, in the sense that we can implement this without special hardware support?

I believe that this is too much, too soon, adding unnecessary complexity and constraints when we should be thinking lean. I think we should rely on TLS and discard obviously-misbehaving sensor data server-side, if it comes to that. I don't see forged data as a problem we should be investing time in right now.

_______________________________________________
mozilla-dev-sensorweb mailing list
mozilla-de...@lists.mozilla.org
https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb

[Fabrice Desré]

On 09/02/2016 12:34 PM, Fernando Jiménez Moreno wrote:

> 4. As part of the setup process, the sensor will register itself with
> the SensorWeb server, providing its device identifier and the user's
> auth token. This request needs to be authenticated with Hawk using the
> device ID as Hawk ID and a shared secret (known by the server and common
> to all sensors) as the Hawk key.

Does that mean that we will provision the device's image with a
symmetric key tied to the production server? If so, that prevents 3rd
party devs to hook up homegrown devices to our network, and will also
impact the way we can ship updates to not leak this key.

--
Fabrice Desré
Connected Devices
Mozilla Corporation

[Fabrice Desré]

On 09/02/2016 03:00 PM, Marcus Cavanaugh wrote:
> Does something here prevent the user from modifying the software and
> sending fabricated data anyway?

The goal is more to be able to easily revoke data from a known bad
sensor/user.

> It sounds like this places firmware requirements on the sensor(s?)
> itself. Is that something accessible to us, in the sense that we can
> implement this without special hardware support?

The shared secret seems problematic to me, yes.

> I believe that this is too much, too soon, adding unnecessary complexity
> and constraints when we should be thinking lean. I think we should rely
> on TLS and discard obviously-misbehaving sensor data server-side, if it
> comes to that. I don't see forged data as a problem we should be
> investing time in right now.

TLS doesn't help us here. And I'm not sure how you can even detect
obviously-misbehaving sensor data. If someone starts faking data for a
location where there's few or no other sources, how would you know that
you are being spammed? I reached out to the MozStumbler team to learn
more about how they deal with this kind of issue in MLS.

[Marcus Cavanaugh]

A schizophrenic datapoint doesn't matter. Sensors may go bad, we may find bugs in our code, users may connect custom sensors and upload it improperly... there are a number of reasons why a specific sensor may be incorrect even if we cryptographically do our best.

The point of a sensor network is to be able to read and interpret the data in aggregate.

I don't think it's a good use of our time to try to address this until after V1 at least.

[Fabrice Desré]

On 09/02/2016 03:23 PM, Marcus Cavanaugh wrote:
> A schizophrenic datapoint doesn't matter. Sensors may go bad, we may
> find bugs in our code, users may connect custom sensors and upload it
> improperly... there are a number of reasons why a specific sensor may be
> incorrect even if we cryptographically do our best.

Sure you don't have full control over the quality of the data you're
getting, and this is not the goal here. It's only to be sure we can be
confident in which device is sending what, in a way that can't be
spoofed at a too low cost.

> The point of a sensor network is to be able to read and interpret the
> data in aggregate.
>
> I don't think it's a good use of our time to try to address this until
> after V1 at least.

This is more a product question, and I don't know what the v1 scope
exactly is.

I'm also curious to know how other platforms deal with that (eg. the
netatmo one https://www.netatmo.com/weathermap).

[Fernando Jiménez Moreno]

On Sat, Sep 3, 2016 at 12:00 AM, Marcus Cavanaugh <m...@mcav.com> wrote:

Does something here prevent the user from modifying the software and sending fabricated data anyway?

[ferjm] No, it doesn't. Protecting the hardware from firmware modifications looks like something the hardware itself should be in charge of.

 

It sounds like this places firmware requirements on the sensor(s?) itself. Is that something accessible to us, in the sense that we can implement this without special hardware support?

[ferjm] Sorry, I'm not sure that I fully understand what you mean, but if you mean that the proposal suggests that we have to modify the sensor's firmware in any way, the answer is no. Where I say "sensor" I meant the entire device we are trying to build, not only the sensor module. I should have used "sensor station" instead. Sorry about that.

 

I believe that this is too much, too soon, adding unnecessary complexity and constraints when we should be thinking lean. I think we should rely on TLS and discard obviously-misbehaving sensor data server-side, if it comes to that. I don't see forged data as a problem we should be investing time in right now.

[ferjm] Fair enough. I guess that's up to the product team to decide if data integrity is something we should invest time in at this stage.

On Fri, Sep 2, 2016 at 2:47 PM Fernando Jiménez Moreno <fmo...@mozilla.com> wrote:

Hello folks,

after having a brief IRC chat with Fabrice the other day about how we could protect the data that we send from the sensors, I spent a few minutes drawing this diagram [1] with the flow that I have in mind for that.

For the use cases that we have I don't think we need to encrypt the data that we get from the devices (apart from the obvious encryption that the TLS channel provides), in the end, this is an open data platform :P. We just need a way to verify that the data that we get from the sensors really comes from a known sensor and has not been modified in its way to the server.

One way to do this is to sign this data with something known about the sensor.

I think we could use Hawk [2][3] for that. The main reason to choose Hawk over anything else is that it provides protection against replay attacks, which seems to me like something that we want to have. We used this auth scheme in the past in other Mozilla projects, like Loop or the Firefox Sync key server, so we have some experience with it.

The basic flow would be something like:

0. The first thing the user needs to do is to authenticate herself with the 3rd party identity provider (IdP) that we choose to support. This can be Firefox Accounts, Google, Facebook... whatever we want. The SensorWeb client will need to trigger the auth flow defined by the chosen IdP, which will most likely be an OAuth flow.

1. Once the IdP auth flow is done, the result will likely be an auth token.

2. After that, the user is able to start the sensor setup process from the client app providing the obtained auth token.

3. When the sensor runs for the first time (or after a reset), it should generate a device identifier.

4. As part of the setup process, the sensor will register itself with the SensorWeb server, providing its device identifier and the user's auth token. This request needs to be authenticated with Hawk using the device ID as Hawk ID and a shared secret (known by the server and common to all sensors) as the Hawk key.

5. The server will need to verify the request's Hawk auth header and also verify the user's auth token against the IdP.

6. Depending on the IdP that we choose, we'll get an user identifier (before or) after the verification. In case that we use FxA, this will happen as result of the verification request.

7. Once the server knows the user is real (at least for that IdP) and it has verified the signature of the registration request, it can register the sensor ID associated to that user ID. During this registration process a new secret is generated and stored along the device ID. This secret will be used as Hawk key for subsequent sensor requests. The response of this process should be a Hawk token that results of wrapping the device ID (Hawk ID) and device secret (Hawk key).

Please, let me know if this makes sense to you.

Cheers,

/ Fernando

[1] https://www.gliffy.com/go/publish/11083803
[2] https://github.com/hueniverse/hawk
[3] http://alexbilbie.com/2012/11/hawk-a-new-http-authentication-scheme/

_______________________________________________
mozilla-dev-sensorweb mailing list
mozilla-de...@lists.mozilla.org
https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb

[Fernando Jiménez Moreno]

(and now replying to the list :\ ...)

On Sat, Sep 3, 2016 at 12:13 AM, Fabrice Desré <fab...@mozilla.com> wrote:

On 09/02/2016 12:34 PM, Fernando Jiménez Moreno wrote:

4. As part of the setup process, the sensor will register itself with
the SensorWeb server, providing its device identifier and the user's
auth token. This request needs to be authenticated with Hawk using the
device ID as Hawk ID and a shared secret (known by the server and common
to all sensors) as the Hawk key.

Does that mean that we will provision the device's image with a symmetric key tied to the production server? If so, that prevents 3rd party devs to hook up homegrown devices to our network, and will also impact the way we can ship updates to not leak this key.

[ferjm] Yes. If allowing 3rd party devs to hook up to our network is a requirement, we can use an API key and API secret pair instead of just a shared and common secret.

Protecting the secret on the client side is indeed a challenge. Even if this data goes obfuscated in the binary, it's still not entirely secure. Having a single API key and secret per device increases the security as it limits the attack surface in case of a leaked key/secret pair, but it also increases a little bit the complexity of the production process, which is still easily automatable though.

 

--
Fabrice Desré
Connected Devices
Mozilla Corporation

[Natalia Martinez-Winter]

not sure if that's related, but I found this :

https://www.opensensors.io/ (where every device gets a unique ID)

might be interesting to talk to those folks?

this is what has been discussed this week-end at the Open hardware User group Camp 2016 ,found this especially interesting:

Scaling IoT with Open Data

In this talk, Yodit will make the case that Open Data is the best practical way to make IoT in work within the 'Smart Cities' context. She will talk about examples of community sensing projects from all over the world from air quality to water quality. The digitisation of public spaces means that sensors are deployed in a number of contexts from environmental to traffic, practically this data is useful to lots of people and reuse is vital.

Yodit Stanton is a data nerd and machine learning developer who runs OpenSensors.io. OpenSensors provides data infrastructure for the Internet of Things enabling anyone to publish real time open data from sensor networks. OpenSensors came out of my her own frustration at not being able to find real time information about the world and we are fixing that... As the physical world becomes digitised making sure people and not just businesses understand the data within their own context is especially important for IoT to succeed.

On 03/09/16 00:17, Fabrice Desré wrote:

On 09/02/2016 03:00 PM, Marcus Cavanaugh wrote:

Does something here prevent the user from modifying the software and
sending fabricated data anyway?

The goal is more to be able to easily revoke data from a known bad sensor/user.

It sounds like this places firmware requirements on the sensor(s?)
itself. Is that something accessible to us, in the sense that we can
implement this without special hardware support?

The shared secret seems problematic to me, yes.

I believe that this is too much, too soon, adding unnecessary complexity
and constraints when we should be thinking lean. I think we should rely
on TLS and discard obviously-misbehaving sensor data server-side, if it
comes to that. I don't see forged data as a problem we should be
investing time in right now.

TLS doesn't help us here. And I'm not sure how you can even detect obviously-misbehaving sensor data. If someone starts faking data for a location where there's few or no other sources, how would you know that you are being spammed? I reached out to the MozStumbler team to learn more about how they deal with this kind of issue in MLS.

--

Natalia Martinez-Winter natalia...@skype.com twitter : @martinezwinter

[Fabrice Desré]

Thanks Natalia,

On 09/05/2016 07:44 AM, Natalia Martinez-Winter wrote:
> not sure if that's related, but I found this :
>
> https://www.opensensors.io/ (where every device gets a unique ID)
>
> might be interesting to talk to those folks?

Looks like this is very close to what we would have to do as a backend.
It's not open source though.

> this is what has been discussed this week-end at the Open hardware User

> group Camp 2016 <http://oshug.org/event/oshcamp2016> ,found this
> especially interesting:

I also found https://www.thethingsnetwork.org/ interesting.

[Fernando Jiménez Moreno]

On Mon, Sep 5, 2016 at 8:14 PM, Fabrice Desré <fab...@mozilla.com> wrote:

Thanks Natalia,

On 09/05/2016 07:44 AM, Natalia Martinez-Winter wrote:

not sure if that's related, but I found this :

https://www.opensensors.io/ (where every device gets a unique ID)

might be interesting to talk to those folks?

Looks like this is very close to what we would have to do as a backend. It's not open source though.

It seems that they have some code at https://github.com/OpenSensorsIO and https://github.com/squaremo/azondi

As Natalia mentioned, they seem to use a unique ID (associated to a username) and unique password per device. No signed payload on client-server requests though.

this is what has been discussed this week-end at the Open hardware User
group Camp 2016 <http://oshug.org/event/oshcamp2016> ,found this
especially interesting:

I also found https://www.thethingsnetwork.org/ interesting.

--
Fabrice Desré
Connected Devices
Mozilla Corporation

[Dave Hylands]

Many microcontrollers (i.e. the stm32 family, and the Freescale K series) have a unique id available on the MCU. These are typically 96-128 bits in length.

_______________________________________________
mozilla-dev-sensorweb mailing list
mozilla-dev-sensorweb@lists.mozilla.org
https://lists.mozilla.org/listinfo/mozilla-dev-sensorweb