WO2022258131A1

WO2022258131A1 - Method and system for managing identity and access of iot devices

Info

Publication number: WO2022258131A1
Application number: PCT/EP2021/065104
Authority: WO
Inventors: Sandeep TAMRAKAR; Pekka Laitinen; Arto NIEMI; Sampo Sovio; Gang LIAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-06-07
Filing date: 2021-06-07
Publication date: 2022-12-15

Abstract

Provided is a method for managing identity and access of an IoT device (202, 302, 402, 506, 602). The method includes pre-provisioning an IoT device with a core token (204, 604) from a base authority (206, 606); requesting, by the IoT device, to join a base ecosystem (208, 608); allowing, by the base authority, the IoT device to join the base ecosystem based on the core token; provisioning the IoT device with base level tokens to access a service within and/or outside the base ecosystem, or to request to join a first level ecosystem (212, 612); requesting, by the IoT device, to join the first level ecosystem using a base level token; allowing, by a first level authority (210, 610), the IoT device to join to the first level ecosystem; and provisioning, by the first level authority, the IoT device with first level tokens to access a service.

Description

METHOD AND SYSTEM FOR MANAGING IDENTITY AND ACCESS OF IoT

DEVICES

TECHNICAL FIELD

The disclosure relates to networked devices, IoT devices, and more particularly to a method and a system of managing identity and access of an Internet of Things, IoT, device.

BACKGROUND

Generally, Small Office/Home, SOHO, network includes a small number of users (usually around 10) and few devices connected to the network. Recent growth in consumer- grade Internet of Things (IoT) devices has penetrated SOHO network, where the number of users is still small, but the number of devices connected to the network has grown from a few to few tens. These IoT devices use wireless technologies such as Bluetooth and Wi-Fi to connect to the SOHO network.

Consumer IoT devices (also called accessories) range from simple sensors and actuators to more complex devices such as network-connected smart printers. Users operate these devices from a resourceful device such as a smartphone (termed as a controller) via. an application. Before an accessory can be used, it needs to be configured to be operational. The process of changing an accessory from not operational mode to operational mode is called bootstrapping. Accessories in the SOHO network are usually from different manufacturers and may follow different bootstrapping and communication protocols. Therefore, users are required to install manufacturer- specific applications on their user device/controller to bootstrap and operate these accessories.

Presently, some companies provide a single stop proprietary solution or an ecosystem where a single application on the user device/controller allows users to control various accessories, from different manufacturers, that join the ecosystem under users’ accounts. To be able to join such ecosystems, accessories need to obtain a license. The accessory manufacturers may enroll into a license agreement with the ecosystem provider before enabling their accessories to join the ecosystem. Once the manufacturer is enrolled, their accessories are provisioned with credentials that acts as licenses. FIG. 1 depicts a generalized scenario of accessory activation into an ecosystem. A credential server 102, operated by an ecosystem provider, generates a credential (at step l.A) and provisions the credential (at step l.B) to an accessory 106 prior to the bootstrapping through an accessory manufacturer server 104. The credential allows the accessory 106 to prove that it is a licensed device approved by the ecosystem provider to operate within the ecosystem. During bootstrapping, a controller 108 associated with a user’s account requests the credential from the accessory 106. Upon receiving the credential, the controller 108 forwards the credential to the credential server 102 for device authentication (at step 2.A). The credential server 102 validates the credential (Step 2.B) and returns the validation status to the controller 108 (at step 2.C). On the other hand, the controller 108 may itself perform the device authentication provided that it is capable of doing the device authentication. After the authentication, the controller 108 activates the accessory 106 (at step 3) in the ecosystem under the user’s account and allows the controller 108 to operate on the accessory 106.

These ecosystems preferably use two types of credentials, such as a device certificate and a software-based on-time token, for the device authentication. Here, the device certificate is a public key certificate either unique to an accessory or a class of accessory that can be used to authenticate the device to the ecosystems while joining. The device certificate is pre-provisioned in a factory and is used to attest that the accessory is a licensed device approved by the ecosystem operator. After the device authentication, an identity provider of the ecosystem provides ecosystem-specific operational credentials to the accessory for securing future communication within the ecosystem. Though, the operational credentials are ecosystem-specific, they however do not allow all devices within a single ecosystem to communicate. Rather, the operational credentials are used to secure communication among devices and a backend server associated with users’ account.

On the contrary, the software -based one-time token can only be used to join the ecosystem once. An accessory is provisioned with a one-time token either at the factory or on-field using a manufacturer- specific mechanism. During bootstrapping, the token is sent to the authenticator of the ecosystem which validates the token, activates the device into the ecosystem, and re-issue a new token for future authentication. Thus, the one-time token can only be used for a single purpose i.e. for device authentication before they can access the SOHO network. Beyond such activation of the device, it cannot be used to access other servers elsewhere.

According to the existing systems, the credentials allow an accessory to prove that the accessory is a licensed device approved by the ecosystem provider, that can be used within its ecosystem, and activate the accessory to access services within the ecosystem. However, the credentials used by the solutions do not allow accessories to authenticate to third-party services beyond the ecosystem or to join a secondary ecosystem. For example, a third party service provider may offer remote computation and analysis services only to a certain subset of licensed accessory from an ecosystem, where the accessories may offload data for analysis. These services may provide various machine learning computation services where accessory can offload data for such complex computation.

Therefore, there arises a need to address the aforementioned technical drawbacks in known techniques or technologies in allowing accessories to join multiple ecosystems simultaneously.

SUMMARY

It is an object of the disclosure to provide a method and a system of managing identity and access of an Internet of Things, IoT, device while avoiding one or more disadvantages of prior art approaches.

This object is achieved by the features of the independent claims. Further, implementation forms are apparent from the dependent claims, the description, and the figures.

The disclosure provides a method and a system of managing identity and access of an Internet of Things, IoT, device.

According to a first aspect, there is provided a method of managing identity and access of an Internet of Things, IoT, device. The method includes pre -provisioning an IoT device with a core token from a base authority. The core token bears a unique token identity. The method includes requesting, by the IoT device, to join a base ecosystem controlled by the base authority, using the core token as an authentication token. The method includes allowing, by the base authority, the IoT device to join to the base ecosystem in response to the unique token identity being authenticated by the base authority based on the core token. The method includes provisioning, by the base authority, the IoT device with base level tokens configured to access a service within and/or outside the base ecosystem. The IoT device can also request to join a first level ecosystem controlled by a first level authority which has a trust relationship with the base ecosystem. The method includes requesting, by the IoT device, to join the first level ecosystem, using a base level token as an authentication token. The method includes allowing, by the first level authority, the IoT device to join to the first level ecosystem in response to the base level token being authenticated by the first level authority. The method includes provisioning, by the first level authority, the IoT device with first level tokens configured to access a service within and/or outside the first level ecosystem or to request to join a second level ecosystem controlled by a second level authority which has a trust relationship with the first level ecosystem.

Thus, the token structure herein includes a hierarchical pattern, where the tokens are placed at different levels of authentication and can be used directly as access tokens to access services either within the ecosystem and/or outside the ecosystem, or used to authenticate the IoT device to a third-party ecosystem and receive other access tokens. Thus, the tokens can be used by anyone to access services vouched in the tokens by their issuer. Further, if the token is compromised, the IoT device can contact the parent ecosystem to regain access to the service or ecosystem. Moreover, the authentication token used to join the ecosystem can be designed to be a one-time token to reduce the chances of token misuse.

Optionally, the method includes accessing, by the IoT device, a first service within the base ecosystem using a base level token as an access token. The method also includes accessing, by the IoT device, a second service outside the base ecosystem using a base level token as an access token.

Optionally, the method includes requesting, by the IoT device, to join the second level ecosystem using a first level token as an authentication token. Optionally, the method includes allowing, by the second level authority, the IoT device to join to the second level ecosystem in response to the first level token being authenticated by the second level authority. The method includes provisioning, by the second level authority, the IoT device with second level tokens configured to access a service within and/or outside the second level ecosystem or to request to join a next level ecosystem controlled by a next level authority which has a trust relationship with the second level ecosystem.

Optionally, one or more of the core token, the base level tokens, the first level tokens, and the second level tokens are one-time tokens or tokens with a time window of validity.

Optionally, the base ecosystem, the first level ecosystem, and the second level ecosystem are part of a hierarchy of ecosystems. The base ecosystem is a root of the hierarchy, each level of the hierarchy comprises one or more ecosystems, and each ecosystem of the hierarchy is controlled by an authority which has a trust relationship with an ecosystem on a preceding level of the hierarchy. Optionally, the method further includes requesting, by the IoT device, to join a level ecosystem on a level of the hierarchy, using a preceding level token, provisioned by an authority on the preceding level of hierarchy, as an authentication token. Optionally, the method further includes allowing, by a level authority controlling the level ecosystem, the IoT device to join to the level ecosystem in response to the preceding level token being authenticated by the level authority. Optionally, the method further includes provisioning, by the level authority, the IoT device with level tokens configured to access a service within and/or outside the level ecosystem or to request to join an ecosystem on the next level of the hierarchy.

Optionally, one or more of the level tokens provisioned on the level of the hierarchy are one-time tokens or tokens with a time window of validity.

According to a second aspect, there is provided a system for managing identity and access of an Internet of Things, IoT, device. The system comprises an IoT device pre provisioned with a core token from a base authority. The core token bears a unique token identity and is being configured for using as an authentication token to request joining a base ecosystem controlled by the base authority. The base authority is configured for allowing the IoT device to join the base ecosystem in response to a join request of the IoT device and the unique token identity being authenticated by the base authority based on the core token. The base authority is configured for provisioning the IoT device with base level tokens configured to access a service within and/or outside the base ecosystem or to request to join a first level ecosystem controlled by a first level authority which has a trust relationship with the base ecosystem. The first level authority is configured for allowing the IoT device to join the first level ecosystem in response to a join request of the IoT device and a base level token being authenticated by the first level authority. The first level authority is configured for provisioning the IoT device with first level tokens configured to access a service within and/or outside the first level ecosystem or to request to join a second level ecosystem controlled by a second level authority which has a trust relationship with the first ecosystem.

By this way, the system allows the IoT device to authenticate to third-party service providers for service access. As the token hierarchy is scalable, i.e., the levels of the token hierarchy can theoretically grow indefinitely with multiple tokens at each levels, the authorities of ecosystems may issue access tokens to access services, and/or issue authentication tokens that can be used to bootstrap a child ecosystem. Further, the system enables the IoT device to join multiple ecosystems simultaneously and allow to access services within the ecosystems or outside the ecosystem.

Optionally, the second level authority is configured for allowing the IoT device to join the second level ecosystem in response to a join request of the IoT device and a first level token being authenticated by the second level authority. The second level authority may be configured for provisioning the IoT device with second level tokens configured to access a service within and/or outside the second level ecosystem or to request to join a next level ecosystem controlled by a next level authority which has a trust relationship with the second level ecosystem.

Optionally, one or more of the core token, the base level tokens, the first level tokens and the second level tokens are one-time tokens or tokens with a time window of validity.

Optionally, the base ecosystem, the first level ecosystem, and the second level ecosystem are part of a hierarchy of ecosystems. The base ecosystem may be a root of the hierarchy, each level of the hierarchy comprises one or more ecosystems, and each ecosystem of the hierarchy is controlled by an authority which has a trust relationship with an ecosystem on a preceding level of the hierarchy. A level authority controlling a level ecosystem on a level of the hierarchy is configured for allowing the IoT device to join the level ecosystem in response to a join request of the IoT device and a preceding level token, provisioned by an authority on the preceding level of hierarchy, being authenticated by the level authority. The level authority controlling the level ecosystem on the level of the hierarchy is configured for provisioning the IoT device with level tokens configured to access a service within and/or outside the level ecosystem or to request to join an ecosystem on the next level of the hierarchy.

A technical problem in the prior art is resolved, where the technical problem concerns indefinitely allowing accessories/devices to join multiple ecosystems to access services simultaneously without the need for having a trust relationship between multiple ecosystems.

Therefore, in contradistinction to the prior art, according to the method and the system for managing identity and access of an Internet of Things, IoT, device, the token hierarchy is scalable, i.e. the levels of the token hierarchy can theoretically grow indefinitely with multiple tokens at each level. The authorities of ecosystems may issue access tokens to access services, and/or issue authentication tokens that can be used to bootstrap a child ecosystem.

The tokens that is specific for a service allow fine-grain access control for service access and provide anonymity to the users and their accessory (e.g. the IoT device) while accessing the service. Further, the disclosure reduces token misuse by breaking lower- level tokens to gain only specific service accesses. Further, the service- specific tokens are time-bound which reduces the attack window.

Further, the IoT devices are allowed to join multiple ecosystems simultaneously and allow to access services within the ecosystems or outside the ecosystem. The system has been designed primarily for low-cost accessories/ IoT devices that do not include a secure storage for securing device credentials. Tokens are treated as bearer tokens, which mean that anyone can use them to access services vouched in the tokens by their issuer. An attacker who obtains a token from an accessory/ IoT device affects only a single accessory/ IoT device. If the attacker can obtain a level 0 token, the attacker can affect the operation of the accessory/ the attacker all together. However, if lower-level tokens are compromised, the attacker only gains certain services or the hierarchy of ecosystems below the compromised token. Further, if a token is compromised, the accessory/ IoT device can contact the parent ecosystem to regain access to the service or ecosystem. Moreover, authentication tokens used to join the ecosystem can be designed to be a one time token to reduce the chances of token misuse.

These and other aspects of the disclosure will be apparent from and the implementation(s) described below.

BRIEF DESCRIPTION OF DRAWINGS

Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram that illustrates a scenario of accessory activation into an IoT ecosystem, in accordance with a prior art;

FIG. 2 is a block diagram of a system for managing identity and access of an Internet of Things, IoT, device in accordance with an implementation of the disclosure;

FIG. 3 is an exemplary interaction diagram that illustrates a method of managing identity and access control management of an IoT device in accordance with an implementation of the disclosure;

FIG. 4 is an exemplary interaction diagram that illustrates a method of allowing multi layer access management for OAuth tokens in accordance with an implementation of the disclosure;

FIG. 5 is an exemplary illustration of a hierarchical token structure in accordance with an implementation of the disclosure;

FIG. 6 is an exemplary interaction diagram that illustrates a method of managing access of an IoT device by sending a flow initialization message in accordance with an implementation of the disclosure; and FIGS. 7A-7C are flow diagrams that illustrate a method of managing an identity and access of an IoT device in an ecosystem in accordance with an implementation of the disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

Implementations of the disclosure provide a method and a system of managing identity and access of an Internet of Things, IoT, device.

To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

Terms such as "a first", "a second", "a third", and "a fourth" (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms "include" and "have" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

FIG. 2 is a block diagram of a system 200 for managing identity and access of an Internet of Things, IoT, device 202 in accordance with an implementation of the disclosure. The system 200 includes an IoT device 202 pre-provisioned with a core token 204, a base authority 206, a base ecosystem 208, a first level authority 210, a first level ecosystem 212, a second level authority 214, and a second level ecosystem 216. The core token 204 bears a unique token identity and is being configured for using as an authentication token to request joining the base ecosystem 208 controlled by the base authority 206. The base authority 206 is configured for allowing the IoT device 202 to join the base ecosystem 208 in response to a join request of the IoT device 202. The unique token identity being authenticated by the base authority 206 based on the core token 204. The base authority 206 is configured for provisioning the IoT device 202 with base level tokens configured to access a service within and/or outside the base ecosystem 208 or to request to join the first level ecosystem 212 controlled by the first level authority 210 which has a trust relationship with the base ecosystem 208. The first level authority 210 is configured for allowing the IoT device 202 to join the first level ecosystem 212 in response to a join request of the IoT device 202 and a base level token being authenticated by the first level authority 210. The first level authority 210 is configured for provisioning the IoT device 202 with first level tokens configured to access a service within and/or outside the first level ecosystem 212 or to request to join the second level ecosystem 216 controlled by the second level authority 214 which has a trust relationship with the first level ecosystem 212.

The system 200 allows the IoT device 202 to authenticate to third-party service providers for service access. As the token hierarchy is scalable, i.e., the levels of the token hierarchy can theoretically grow indefinitely with multiple tokens at each level, the authorities of ecosystems may issue access tokens to access services, and/or issue authentication tokens that can be used to bootstrap a child ecosystem. Further, the system 200 enables the IoT device 202 to join multiple ecosystems simultaneously and allow to access services within the ecosystems or outside the ecosystem.

FIG. 3 is an exemplary interaction diagram that illustrates a method of managing identity and access control management of an IoT device 302 in accordance with an implementation of the disclosure. At a step 312, the IoT device 302 is pre-provisioned with a level 0 token by a token server 306. The IoT device 302 may be an accessory. Optionally, the level 0 token is a one-time token that is provisioned either at a factory or on-the field prior to the IoT device bootstrapping into an IoT network framework. Hereinafter, the IoT network framework refers to a network of IoT devices, which operates in a user’s local network, that is facilitated by an ecosystem provider to access various services offered by the ecosystem depending upon the access control policies associated with the user’s account. The level 0 token can be bound to an accessory identity. At a step 314, a token request is sent by a controller 304 to the IoT device 302 to use the level 0 token. At a step 316, the level 0 token is used by the controller 304 to authenticate at the token server 306. Optionally, the token server 306 is operated by a Small Office/Home, SOHO, provider. At a step 318, the level 0 token is validated and renewed by the token server 306. At a step 320, the renewed token is updated at the IoT device 302 by the token server 306. Optionally, once the level 0 token is used by the controller 304, the IoT device 302 receives a next level token, e.g. a level 1 token. The level 0 token is used to (i) authenticate the IoT device 302, (ii) activate the IoT device 302 in an IoT network framework and (iii) fetch level 1 tokens. At a step 322, the level 1 token is issued by the token server 306 to the IoT device 302. Optionally, the level 1 token includes certain claims vouched by the token server 306 (e.g. an IoT network framework provider). The level 1 token may be valid for a certain time period (e.g. days to weeks). The level 1 token is used to authenticate the IoT device 302 and its user and fetch a level 2 token. At a step 324, the IoT device 302 is activated by the controller 304. At a step 326, the IoT device 302 requests a level 2 token to a service- specific token issuer 308. The service- specific token issuer 308 may be operated by the Small Office/Home, SOHO, provider or a third-party. At a step 328, the level 1 token is validated by the service- specific token issuer 308. At a step 330, a level 2 token is issued to the IoT device 302 by the service-specific token issuer 308. At a step 332, a service access request is sent by the IoT device 302 using the level 2 token to services 310. Optionally, the level 2 token anonymously authenticates the IoT device 302 (not bound to the real identity of the IoT device 302) to access specific remote services. The level 2 token may be valid for a short time period. The services 310 may be operated by the Small Office/Home, SOHO, provider or the third-party. At a step 334, the level 2 token is validated and the service access request is granted by the services 310. At a step 336, the services 310 is accessed by the IoT device 302.

FIG. 4 is an exemplary interaction diagram that illustrates a method of allowing multi layer access management for OAuth tokens in accordance with an implementation of the disclosure. At a step 412, an IoT device 402 is pre -provisioned with a level 0 token by a token server 406. The IoT device 402 may be an accessory. Optionally, the level 0 token is a one-time token. The level 0 token may use as OAuth 2.0 refresh tokens to request an Access token. The level 0 token may be pre-provisioned before IoT device onboarding. At a step 414, a token request is sent by a controller 404 to the IoT device 402 to use the level 0 token. At a step 416, an IoT device authentication request is sent by the IoT device 402 via an OAuth 2.0 token request to the token server 406, where the OAuth 2.0 token request includes a parameter authorization grant type represented as grant_type. Here, grant_type is represented as grant_type = referesh, refresh_token = Level_0_Token. The parameter grant_type = refresh indicates that the authorization grant type is a refresh token that the server could use to authenticate the request and the binary representation of level 0 token is used as refresh_token value. Here, grant_type and refresh_token are parameters to the OAuth 2.0 token request.

At a step 418, the level 0 token is validated and renewed by the token server 406. At a step 420, an OAuth 2.0 access token with a refresh token is issued by the token server 406 to the IoT device 402. At a step 422, the OAuth 2.0 access token issued by the token server 406 is used as a level 1 token to the IoT device 402. The level 1 token is the access token received at the step 420 along with the reference token, where level 1 token is used as an authentication token rather than OAuth 2.0 access token. At a step 424, the IoT device 402 is activated by the controller 404. At a step 426, a token request for a defined service is sent with a new (user defined) grant type as the authorization grant type parameter defined according to the extension grant type by the IoT device 402 to an authenticator 408. The token request for the defined service is sent with the new authorization grant type parameter defined according to the extension grant type, and is represented as grant_type = urn:ietf:params:oauth:grant-type:auth_token, auth_token = level l_l_token. Here, the extension grant type is a method of extending grant_type parameter beyond what is specified in OAuth 2.0 specification. The authenticator 408 may be operated by the Small Office/Home, SOHO provider or a third-party. At a step 428, the level 1 token is validated by the authenticator 408. At a step 430, a level 2 token is issued to the IoT device 402 by the authenticator 408. The level 2 token is service- specific access tokens. The level 2 token may be the OAuth 2.0 access token. The level 2 token fetches using extension grant type (user defined) i.e. by specifying an absolute URI (defined by an authorization server) as the value of the "grant_type" parameter and by adding any additional parameters necessary. The grant_type is defined as um:ietf:params:oauth:grant-type:auth_token. At a step 432, a service access request is sent by the IoT device 402 using the level 2 token to services 410. Optionally, the level 2 token anonymously authenticates the IoT device 402 (not bound to the real identity of the IoT device 402) to access specific remote services. The level 2 token may be valid for a short time period. The services 410 may be operated by the Small Office/Home, SOHO, provider or the third-party. At a step 434, the level 2 token is validated and the service access request is granted by the services 410. At a step 436, the services 410 is accessed by the IoT device 402.

FIG. 5 is an illustration of an architectural overview of a hierarchical token structure in accordance with an exemplary implementation of the disclosure. A root token i.e. a level 0 token 508 can be used to join an ecosystem A 510 of an Authority A 502 and further request lower level tokens. The level 0 token 508 is supposedly issued by or recognized by the Authority A 502. Optionally, tokens are used as either authentication tokens or as access tokens. The authentication tokens may be used to join the ecosystem A 510. The access tokens may be used to access services. Optionally, the tokens are treated as bearer tokens that enable that any entity that holds the tokens can use them to access the services vouched in the tokens by their issuer.

According to the hierarchical token structure of FIG. 5, At a step 538, an IoT device 506 is pre-provisioned with the level 0 token 508 i.e. Token 0A either at a factory or via some other device manufacturer 504 specific mechanisms prior to joining the ecosystem A 510 controlled by the Authority A 502.

The ecosystem A 510 is a primary ecosystem that the IoT device 506 can join to begin with. At a step 540, a request to join the ecosystem A 510 is sent by the IoT device 506 using the token 0A as authentication token to the Authority A 502. The Authority A 502 verifies the authentication token and decides to allow the IoT device 506 to join the ecosystem A 510. At a step 542, the level 0 token 508 is updated by the Authority A 502 for future authentication. At a step 544, the IoT device 506 is granted by the Authority A 502 to join the ecosystem A 510 and delivers level 1 tokens: token 1A 512A, token IB 512B, token 1C 512C and token IX 512X. At a step 546, token IX 512X is used as access token by the IoT device 506 to access third-party services from a service provider X 514 outside the ecosystem A 510. At a step 548, Token 1A 512A is used as access token by the IoT device 506 to access services from a service provider 516 within the ecosystem A 510. At a step 550, the token IB 512B is used as authentication token by the IoT device 506 to request an Authority B 518 to join an ecosystem B 522 controlled by the Authority B 518. At a step 552, the token 1C 512C is used as authentication token by the IoT device 506 uses request an Authority C 520 to join an ecosystem C 528 controlled by the Authority C 520. At a step 554, the IoT device 506 is granted by the Authority B 518 to access the ecosystem B 522 and a Level 2 token, Token 2B 524 are issued by the Authority B 518. At a step 556, the token 2B 524 is used by the IoT device 506 to access services from Service Provider 526 within the ecosystem B 522. At a step 558, the IoT device 506 is granted by the Authority C 520 to access the ecosystem C 528 and Level 2 token, token 2C 530 are issued by the Authority C 520. At a step 560, the token 2C 530 is used as authentication token to request an Authority D 532 to access an ecosystem D 534. At a step 562, the IoT device 506 is granted by the Authority D 532 access to the ecosystem D 534 and further Level 3 token, token 3D 536 are issued by the Authority D 532.

However, the architecture allows the hierarchy to scale indefinitely allowing accessories to join multiple ecosystem to access services simultaneously. The disclosure can be used to bootstrap hierarchy of independent ecosystem where a child ecosystem can operate independently from parent ecosystem. For example, there is no need to have a direct trust relationship between the ecosystem A 510 and the ecosystem B 522 or the ecosystem D 534.

FIG. 6 is an exemplary interaction diagram that illustrates a method of managing access of an IoT device 602 by sending a flow initialization message in accordance with an implementation of the disclosure. At a step 618, the IoT device 602 is pre-provisioned with a core token 604 from a base authority 606. The core token 604 bears a unique token identity. The IoT device 602 requests to join a base ecosystem 608 controlled by the base authority 606, using the core token 604 as an authentication token, at a step 620. At a step 622, the base authority 606 allows the IoT device 602 to join the base ecosystem 608 in response to the unique token identity being authenticated by the base authority 606 based on the core token 604. At the same step 622, the base authority 606 provisions the IoT device 602 with base level tokens configured to access a service within and/or outside the base ecosystem 608 or to request to join a first level ecosystem 612 controlled by a first level authority 610 which has a trust relationship with the base ecosystem 608. At a step 624, the IoT device 602 requests the first level authority 610 to join the first level ecosystem 612, using a base level token as an authentication token. At a step 626, the IoT device 602 is allowed by the first level authority 610 to join the first level ecosystem 612, in response to the base level token being authenticated by the first level authority 610. At the same step 626, the first level authority 610 provisions the IoT device 602 with first level tokens configured to access a service within and/or outside the first level ecosystem 612, or to request to join a second level ecosystem 616 controlled by a second level authority 614 which has a trust relationship with the first level ecosystem 612. Similarly to the step 624, at a step 628 the IoT device 602 requests the second level authority 614 to join the second level ecosystem 616, using a first level token as an authentication token. At a step 630, the IoT device 602 is allowed by the second level authority 614 to join the second level ecosystem 616, in response to the first level token being authenticated by the second level authority 614. At the same step, the second level authority 614 can provision the IoT device 602 with second level tokens configured to access a service within and/or outside the second level ecosystem 616, or to request to join a next level ecosystem controlled by a next level authority (not shown) which has a trust relationship with the second level ecosystem 616.

FIGS. 7A-7C are flow diagrams that illustrate a method of managing identity and access of an IoT device in an ecosystem in accordance with an implementation of the disclosure. At a step 702, an IoT device is pre -provisioned with a core token from a base authority. The core token bears a unique token identity. At a step 704, the IoT device requests to join a base ecosystem controlled by the base authority, using the core token as an authentication token. At a step 706, the IoT device is allowed to join to the base ecosystem in response to the unique token identity being authenticated by the base authority based on the core token. At a step 708, the IoT device is provisioned, by the base authority, with base level tokens configured to access a service within and/or outside the base ecosystem, or to request to join a first level ecosystem controlled by a first level authority which has a trust relationship with the base ecosystem. At a step 710, the IoT device requests to join the first level ecosystem, using a base level token as an authentication token. At a step 712, the IoT device is allowed by the first level authority to join to the first level ecosystem in response to the base level token being authenticated by the first level authority. At a step 714, the first level authority provisions the IoT device with first level tokens configured to access a service within and/or outside the first level ecosystem or to request to join a second level ecosystem controlled by a second level authority which has a trust relationship with the first level ecosystem.

Thus, the token structure includes a hierarchical pattern, where the tokens are placed at different levels of authentication and can be used directly as access tokens to access services either within the ecosystem and/or outside the ecosystem, or used to authenticate the IoT device to a third-party ecosystem and receive other access tokens. Thus, the tokens can be used by anyone to access services vouched in the tokens by their issuer. Further, if the token is compromised, the IoT device can contact the parent ecosystem to regain access to the service or ecosystem. Moreover, the authentication token used to join the ecosystem can be designed to be a one-time token to reduce the chances of token misuse.

Optionally the method includes accessing, by the IoT device, a first service within the base ecosystem using a base level token as an access token, and/or accessing a second service outside the base ecosystem using a base level token as an access token.

Optionally, the method includes, (i) requesting, by the IoT device, to join the second level ecosystem using a first level token as an authentication token, (ii) allowing the IoT device to join to the second level ecosystem in response to the first level token being authenticated by the second level authority and (iii) provisioning, by the second level authority, the IoT device with second level tokens configured to access a service within and/or outside the second level ecosystem or to request to join a next level ecosystem controlled by a next level authority which has a trust relationship with the second level ecosystem.

Optionally, the base ecosystem, the first level ecosystem and the second level ecosystem are part of a hierarchy of ecosystems. The base ecosystem is a root of the hierarchy, each level of the hierarchy comprises one or more ecosystems, and each ecosystem of the hierarchy is controlled by an authority which has a trust relationship with an ecosystem on a preceding level of the hierarchy. Optionally, the method includes requesting, by the IoT device, to join a level ecosystem on a level of the hierarchy, using a preceding level token, provisioned by an authority on the preceding level of hierarchy, as an authentication token. Optionally, the method further includes allowing, by a level authority controlling the level ecosystem, the IoT device to join to the level ecosystem in response to the preceding level token being authenticated by the level authority. Optionally, the method further includes provisioning, by the level authority, the IoT device with level tokens configured to access a service within and/or outside the level ecosystem or to request to join an ecosystem on the next level of the hierarchy.

The core of the disclosure herein is the hierarchical token structure that begins with a level 0 token. This token is security critical as this token forms a root of the token hierarchy. The implementation of the disclosure on the accessory platform with a secure storage can use their secure storage to protect tokens against theft. Further, an implementation of the disclosure on the accessory/IoT device platform with a device- specific/class key pair protected using security modules can directly use the device- specific/class key pair as a device authentication mechanism similar to level 0 tokens. The level 0 tokens may be issued to the IoT device’ s/accessories in such a way that the tokens are bound to the device specific key pairs which prohibits attackers from using tokens. To further protect the token hierarchy, the primary ecosystem authority may issue for each tokens a key pair whose public key is bound to the token. The token and the key pair are encrypted with the device public key of the accessory to ensure that only the correct IoT device is able to decrypt the values. The key pairs may further be used in similar fashion while obtaining next level of tokens.

Optionally, the hierarchical token structure is designed with focus on low-cost IoT device’ s/accessories that do not include a secure storage or security module. Such low- cost IoT device’ s/accessories are incapable of protecting tokens to the degree that is offered by the more secure IoT device’s. However, the method reduces the chances of misusing level 0 tokens. In an implementation of the disclosure on the IoT device/accessory platform without a secure storage or security module, the authentication tokens can be designed as a single-use tokens. Once used, a new token must be obtained.

Additionally, the implementation of the disclosure is designed in such a way that the level 0 tokens are always re-issued immediately after authenticating the IoT device with the token during bootstrapping. However, new authentication tokens at lower levels can be obtained from authority of their parent ecosystems. Moreover, the implementation of the disclosure binds the IoT device's identity such as serial number to the level 0 token so that in case of token theft, the legitimate IoT device may prove its identity to the token issuer and obtain new token. For example, a user may submit currently available token on the IoT device together with the device serial number to the token issuer's portal for token recovery. In such case, the token issuer may invalidate tokens that has been previously issued to the IoT device and reissue a fresh token.

It should be understood that the arrangement of components illustrated in the figures described are exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Claims

1. A method of managing identity and access of an Internet of Things, IoT, device (202, 302, 402, 506, 602), comprising: pre-provisioning an IoT device (202, 302, 402, 506, 602) with a core token (204, 604) from a base authority (206, 606), the core token (204, 604) bearing a unique token identity, requesting, by the IoT device (202, 302, 402, 506, 602), to join a base ecosystem (208, 608) controlled by the base authority (206, 606), using the core token (204, 604) as an authentication token, allowing, by the base authority (206, 606), the IoT device (202, 302, 402, 506, 602) to join to the base ecosystem (208, 608) in response to the unique token identity being authenticated by the base authority (206, 606) based on the core token (204, 604), provisioning, by the base authority (206, 606), the IoT device (202, 302, 402, 506, 602) with base level tokens configured to access a service within and/or outside the base ecosystem (208, 608), or to request to join a first level ecosystem (212, 612) controlled by a first level authority (210, 610) which has a trust relationship with the base ecosystem (208, 608), requesting, by the IoT device (202, 302, 402, 506, 602), to join the first level ecosystem (212, 612), using a base level token as an authentication token, allowing, by the first level authority (210, 610), the IoT device (202, 302, 402, 506, 602) to join to the first level ecosystem (212, 612) in response to the base level token being authenticated by the first level authority (210, 610), and provisioning, by the first level authority (210, 610), the IoT device (202, 302, 402, 506, 602) with first level tokens configured to access a service within and/or outside the first level ecosystem (212, 612) or to request to join a second level ecosystem (216, 616) controlled by a second level authority (214, 614) which has a trust relationship with the first level ecosystem (212, 612).

2. The method of claim 1, further comprising: accessing by the IoT device (202, 302, 402, 506, 602), a first service within the base ecosystem (208, 608) using a base level token as an access token, and/or accessing by the IoT device (202, 302, 402, 506, 602) a second service outside the base ecosystem (208, 608) using a base level token as an access token.

3. The method of claim 1, further comprising: requesting, by the IoT device (202, 302, 402, 506, 602), to join the second level ecosystem (216, 616) using a first level token as an authentication token, allowing, by the second level authority (214, 614), the IoT device (202, 302, 402, 506, 602) to join to the second level ecosystem (216, 616) in response to the first level token being authenticated by the second level authority (214, 614), and provisioning, by the second level authority (214, 614), the IoT device (202, 302, 402, 506, 602) with second level tokens configured to access a service within and/or outside the second level ecosystem (216, 616) or to request to join a next level ecosystem controlled by a next level authority which has a trust relationship with the second level ecosystem (216, 616).

4. The method of any of claims 1 to 3, wherein one or more of the core token (204, 604), the base level tokens, the first level tokens and the second level tokens are one-time tokens or tokens with a time window of validity.

5. The method of any of claims 1 to 4, wherein the base ecosystem (208, 608), the first level ecosystem (212, 612) and the second level ecosystem (216, 616) are part of a hierarchy of ecosystems, wherein the base ecosystem (208, 608) is a root of the hierarchy, each level of the hierarchy comprises one or more ecosystems, and each ecosystem of the hierarchy is controlled by an authority which has a trust relationship with an ecosystem on a preceding level of the hierarchy, the method further comprising: requesting, by the IoT device (202, 302, 402, 506, 602), to join a level ecosystem on a level of the hierarchy, using a preceding level token, provisioned by an authority on the preceding level of hierarchy, as an authentication token, allowing, by a level authority controlling the level ecosystem, the IoT device (202, 302, 402, 506, 602) to join to the level ecosystem in response to the preceding level token being authenticated by the level authority, and provisioning, by the level authority, the IoT device (202, 302, 402, 506, 602) with level tokens configured to access a service within and/or outside the level ecosystem or to request to join an ecosystem on the next level of the hierarchy.

6. The method of claim 5, wherein one or more of the level tokens provisioned on the level of the hierarchy are one-time tokens or tokens with a time window of validity.

7. A system (200) for managing identity and access of an Internet of Things, IoT, device (202, 302, 402, 506, 602), comprising: an IoT device (202, 302, 402, 506, 602) pre-provisioned with a core token (204, 604) from a base authority (206, 606), the core token (204, 604) bearing a unique token identity and being configured for using as an authentication token to request joining a base ecosystem (208, 608) controlled by the base authority (206, 606), and wherein the base authority (206, 606) is configured for: allowing the IoT device (202, 302, 402, 506, 602) to join the base ecosystem (208, 608) in response to a join request of the IoT device (202, 302, 402, 506, 602) and the unique token identity being authenticated by the base authority (206, 606) based on the core token (204, 604), and provisioning the IoT device (202, 302, 402, 506, 602) with base level tokens configured to access a service within and/or outside the base ecosystem (208, 608) or to request to join a first level ecosystem (212, 612) controlled by a first level authority (210, 610) which has a trust relationship with the base ecosystem (208, 608), wherein the first level authority (210, 610) is configured for: allowing the IoT device (202, 302, 402, 506, 602) to join the first level ecosystem (212, 612) in response to a join request of the IoT device (202, 302, 402, 506, 602) and a base level token being authenticated by the first level authority (210, 610), and provisioning the IoT device (202, 302, 402, 506, 602) with first level tokens configured to access a service within and/or outside the first level ecosystem (212, 612) or to request to join a second level ecosystem (216, 616) controlled by a second level authority (214, 614) which has a trust relationship with the first level ecosystem (212, 612).

8. The system (200) of claim 7, wherein the second level authority (214, 614) is configured for allowing the IoT (202, 302, 402, 506, 602) device to join the second level ecosystem (216, 616) in response to a join request of the IoT device (202, 302, 402, 506, 602) and a first level token being authenticated by the second level authority (214, 614), and provisioning the IoT device (202, 302, 402, 506, 602) with second level tokens configured to access a service within and/or outside the second level ecosystem (216, 616) or to request to join a next level ecosystem controlled by a next level authority which has a trust relationship with the second level ecosystem (216, 616).

9. The system (200) of any of claims 7 or 8, wherein one or more of the core token (204, 604), the base level tokens, the first level tokens and the second level tokens are one-time tokens or tokens with a time window of validity.

10. The system (200) of any of claims 7 to 9, wherein the base ecosystem (208, 608), the first level ecosystem (212, 612) and the second level ecosystem (216, 616) are part of a hierarchy of ecosystems, wherein the base ecosystem (208, 608) is a root of the hierarchy, each level of the hierarchy comprises one or more ecosystems, and each ecosystem of the hierarchy is controlled by an authority which has a trust relationship with an ecosystem on a preceding level of the hierarchy, wherein a level authority controlling a level ecosystem on a level of the hierarchy is configured for: allowing the IoT device (202, 302, 402, 506, 602) to join the level ecosystem in response to a join request of the IoT device (202, 302, 402, 506, 602) and a preceding level token, provisioned by an authority on the preceding level of hierarchy, being authenticated by the level authority, and provisioning the IoT device (202, 302, 402, 506, 602) with level tokens configured to access a service within and/or outside the level ecosystem or to request to join an ecosystem on the next level of the hierarchy.

11. The system (200) of claim 10, wherein one or more of the level tokens provisioned on the level of the hierarchy are one-time tokens or tokens with a time window of validity.