Identity Management in the IoT

par | Déc 17, 2014 | Gestion des Identités, IoT, Sécurité

Identity Management in the IoT (Internet of  things). IoT is more like an umbrella term that encompasses different architectures where for example things can talk to each other, talk to a computer sitting at home or in the cloud, to a proxy or mobile phone or even to a cloud service  either directly or through a mobile app or gateway. Depending on the distribution of functionality and capabilities of the elements in the architecture, analysts have defined for example thing-centric, cloud-centric, gateway-centric, smartphone-centric and enterprise centric architectures for the IoT.

Source : https://forgerock.org/2014/12/irm-iot/  thanks Victor Ake,

Regardless of the architecture, the important thing here is that in many cases the data that things sense and send over should have an owner. For example the temperature sensed at your home, the speed at which you are driving your car, your blood pressure and heart rate, should be yours and yours only and you should be the one deciding with whom you want to share this data. But the question is how do you attach an ownership tag to the data sent by a device, how do you ensure the data ends up at the correct location, how can the end user share the access to the data with whom he/she deems necessary and how all of this can be done in a secure and reliable way?

What is needed
To answer the questions planted above, we need an IoT system capable of:

  1. Verify authenticity of the device: You want to be sure that the device sending data is an authentic device built by an original manufacturer and not made in Cloneland. This ensures the quality of the sensed data and gives you an idea that the manufacturer has also taken care of the quality and authenticity of the firmware (signed firmware for example) mitigating the risk of leaking information.
  2. Ensure the device has a unique identifier: Each device should have a unique identity, the identity can be for example the serial number of the device. There should be a certainty that the identity of the device is authentic and not faked.
  3. Register the authentic and unique identifiable device over a secure channel: The identity of the device need to be provisioned into the service that it would send data and it has to be done over a secure channel. The registration process should verify the authenticity of the device.
  4. Authenticate the device: Once the device has been registered, get it authenticated before exchanging any data. This has to be done as well  over a secure channel.
  5. Create an association or relationship between the user and the device: Once a device and a user have been registered, then a user can prove that it owns and posses the device. Once proof of ownership has been given, then a relationship user-device can be created.
  6. Ensure the device can send data on behalf of the user: Once a relationship user-device has been made, then the device should be able to send data on behalf of the user. For this a token can be provisioned back into the device and should be sent together with the data.
  7. Ensure the channel is securely encrypted: All the operations described above should be done over a secure and encrypted channel. One scenario here is to use TLSv1.2 to encrypt the channel and at the same time do mutual authentication between the client and the server. Perfect Forward Secrecy configuration would be ideal to minimize the possibilities of getting affected with issues like the heartbleed bug.
  8. Implement an Authorization system that can be handled by the end user. Yes, we are talking UMA (User Managed Access) here.

How to implement

There might be several ways to implement a system fulfilling the requirements mentioned above, here one way to do it:

  1. Provisioning a key-pair in a Secure Element that is placed in the device at the manufacturer plant.  The key-pair can be used for:
    1. Prove Authenticity of the device
    2. Provide a Serial Number of the device as part of the Certificate
    3. Use the Serial Number contained in the certificate to provision the identity of the verified device
    4. Authenticate the device with the certificate
  2. Prove ownership of the device by using an OTP generated in the cloud server and displayed in the small screen of the device. The owner should provide the OTP in the server to “pair” the device with his/her account. There are many ways to do prove ownership, but this is just one option.
  3. Once the device-user relationship has been created, an OAuth2 token can be created to allow access to the cloud service on behalf of the user. The OAuth2 token can then be provisioned back into the device and the device can use the token to access the cloud service when sending data.
  4. If a user wants to prevent the device to keep sending data on his/her behalf, the user can revoke the token.
  5. The service allowing read access to the data collected in the cloud service can be protected using UMA. The user can then share and revoke access  to with whoever he/she wants.

Demo
We have created a demo where a fictitious device does what is described here, the device is emulated with a little program, but it uses an actual library that we created and that can be embedded in devices/things. The demo uses ForgeRock products to provision the device, the user, create a relationship between device-user and provision back an OAuth2 token into the device.  All the technology used is standards-based.

The demo uses a key-pair generated using Elliptic Curve and uses TLSv1.2 protocol with ECDHE-ECDSA-AES128-GCM-SHA256 cipher to create a secure channel. It performs mutual client-server authentication and all the data is exchange over the secure channel.

To send data, the demo uses a Secure Websocket connection that during the handshake uses TLSv1.2 to authenticate the device, it then verifies the presence of the OAuth2 token, verify the validity of the OAuth2 token and if everything is correct then opens the Websocket. After the websocket is opened, then the device sends data that is attributed to the user for which the OAuth2 token was issued. Notice that if the device is not authenticated and verified or no valid token is present  then no data can be sent.

As fictitious requirements we have assumed the device doesn’t have a keyboard so we can not type anything on the device to prove ownership, but it has a small display. The device should not need a smartphone to be provisioned/on-boarded or talk to the cloud service.

Take a look to the video embedded here, or watch it in youtube and let us know what you think.

janua
Les derniers articles par janua (tout voir)