Securing IOT devices

In the last story Mitigating Code Interception Attack Using PKCE we had a deep dive on native devices who have got capability to spin up the browser , to be specific they use either of WebView or System Browser in order to achieve Oauth specific login flow.

But now we are living in times where even the electric bulbs are smart devices and can ingest some data for IOT analysis. With more and more smart devices like smart TV , smart speakers, printers, smart cars coming in the ecosystem securing them has become a new challenge. Infact smart homes and smart cities are really becoming reality, which further emphasizes on Device Security.

IETF OAuth working Group has a standard way of addressing this by RFC 8628 https://datatracker.ietf.org/doc/html/rfc8628 they call this as OAuth 2.0 Device Authorization Grant.

But before going to the implementation , Please check whether you device has these capabilities or not :-

a) Device can connect to internet, and have access to Auth Server.

b) Device can make outbound HTTP requests.

c) Device has a display or share by any means a URI or a code sequence.

Note :- I have seen that some devices don’t have displays but have some Android/iOS apps which can establish the Bluetooth connection and can show this value to user.

Lets understand the implementation of the same by a business scenario:-

Smart LED Device eligible for device authorization

Lets say you want to track the electricity consumption of each and every room on your home/office(which you can extend for each and every device also) and you purchase from market some smart LED lights , which are configurable. This LED lights are programmed to ingest the usage data on to any of the platform, for further analysis.

Also consider every room belongs to some different family member , and all the LEDs places in that room will be sending the data in behalf of the room owner.

The smart device that we have referred here is not having any display so it can have one iOS app or Android app , so it can broadcast the device_code, user_code and verification_url via bluetooth.

Conceptual Flow

Lets get in to details for each call:-

1. Somebody installs the device and shares the relevant app to room owners. While teh device boots up , it makes a call to Auth server for getting device_code ,user_code and verification_url

Request :-

POST /device_authorize
{“client_id” = “Smart-d435679cf”}

Response :-

{
“device_code”: “device-rx1004”,
“user_code”: “56tgMFGT”,
“verification_uri”: “https://datarepo.com/device",
“verification_uri_complete”: “https://datarepo.com/device?user_code =56tgMFGT”,
“expires_in”: 3600,
“interval”: 10
}

2. The moment device is plugged in , it send the details to user on the pre configured app

3. User follows the verification_url and confirms his identity.

4. One interesting mechanism these devices have is, they keep on polling the token endpoint in context of the dynamically generated device code.

Request:-

POST /token HTTP/1.1
Host : datarepo.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=device-rx1004&client_id=Smart-d435679cf

Note:- Device keeps on pooling the token endpoint , and the moment user does the verification , Auth server in the next call from device releases the access token.

Note:- Important point to focus here is grant_type which is “urn:ietf:params:oauth:grant-type:device_code”

5. Device gets the access token which has sub claim as “user-id” of the room owner.

6. Device ingests its usage data to through api call. It can keep on ingesting the data till the token expires and once it has expired it acquires the new access token using the refresh token grant type.

Using this mechanism we can easily establish the Oauth flow for IOT devices with relevant capabilities and this also allows us to kick start the data ingestion from these edge devices , in a secure way.

Is this really that simple to onboard any device on a platform?

Obviously not , if you are onboarding your device to any enterprise platform there are several other processes around it , and this comes under Asset Onboarding. But once you have onboarded device as per the defined guidelines of the enterprise platform ,with all due diligence , device Authorization Flow helps to start communicating in a elegant and secure way.