Identity Relationship Management in the 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.

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.

8 Comments

Comments are closed.

  1. David G. Simmons 4 years ago

    I like the demo. Well done! I’d love to get the library you used to try out on some of the small devices I have here to play with. As I said the IoT forums, I have an IoT device here that I might even run the server on.

    The only drawback here is the assumption that the device has a display of some sort. I’ve been working on IoT devices for nearly 10 years, and so far, have not actually built one that had a display. While displays are needed for *some* IoT applications — wearables, some home-automation, etc. — the vast majority of deployments over the next 10 years will likely not include displays. Most truly embedded IoT devices, and industrial, M2M devices, won;t include any sort of display as it is just not cost effective.

    That being said, we did actually do a demo system using OAuth for an IoT device to send encrypted data (also using ECC / SSH) back in ’06 but we didn’t have a way to do central provisioning, authentication, etc. So the ForgeRock stack would have been helpful there.

    It would be really helpful to IoT developers like myself if there were a publicly-available instance of the ForgeRock stack such that we didn’t have to install and configure it all ourselves for testing devices.

  2. Aron Kozak 4 years ago

    Thanks David. I’ve made a note here to see what we can do about some sort of sandbox environment for testing. No promises, but it’s something I’ll explore.

  3. David G. Simmons 4 years ago

    Thanks Aron! It would be a huge win for Makers. And for ForgeRock. What developers use to prototype is often what they continue to use later. URL: Ubiquity, Revenue Later. (h/t Scott McNealy)

  4. Author
    Victor Ake 4 years ago

    Hi David, thanks for the feedback. As i mentioned, the example is for a wearable that will show you health information, hence this example needs of a display, but it might not be needed for other cases. There are many ways to prove ownership, and there is a dependency also on the nature of the information you are sending. If the info is very sensitive, like health information, then you want to be sure that the proof of ownership is very secure and very reliable, for other things there might be other mechanisms to prove ownership.
    Cheers

  5. Author
    Victor Ake 4 years ago

    Agree David on Ubiquity, we are working on that, but as Aron mentioned no promises yet :-)

  6. Katie_Gonzalez 4 years ago

    Thanks for the demo, looks great!

    I am excited for #8 and the integration of UMA :)

  7. David G. Simmons 4 years ago

    I was actually looking at incorporating something like this: https://www.sparkfun.com/products/11551 which is basically an Atmel ATSHA204 which, aside from being able to keys/passwords also comes with a 72-bit unique serial number and has build-in crypto functions.

    Using a chip like this, a device could uniquely ID itself to IRM system and ask for configuration data, etc. This is a scenario for non-display devices.

  8. Author
    Victor Ake 4 years ago

    Hi Katie,
    Good to see you here. Im glad you like the demo. UMA is coming to our products pretty soon, and it is definitely a strong requirement to take care of privacy when things send data that belongs to a user(s). This is specially important in the IoT for wearables, cars, health industry, etc.

©2019 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?