12.35 Access Control using several tokens

12.35.1 Description

In order prevent some hacker attacks when an access is allowed from not protected networks, M2M nodes is enhaced to to expose only non-sensitive resources and to protect sensitive resources (e.g. Firwmare update, sensitive data retrieval). This is based on a request parameter indicating the role of the originator in the access or management of the requested resource. This will allow requests from an originator to be treated differently based on the role specified.

In order to allow this access control dynamically, the usecase requires that management of the access is provided by a DAS (Dynamic Authorisation Server) via tokens.

12.35.2 Source

RDM-2019-0080R02-Access_Control_Using_several_tokens

12.35.3 Actors

• Managed Device (for example Air Conditionners)
• Maintainer (M) who manages the device resources remotely (e.g. maintenance of Air Conditioners is subcontracted to a maintainer (M) who manages the device resources remotely : humidity level, temperature, on/off, power consumption, firmware version,....)
• Owner (O) is also able to manage the device remotely (humidity level, temperature,...)
• Dynamic Authorisation Server Owner (DAS_O) managing authroisations for Owner resources
• Dynamic Authorisation Server Maintainer (DAS_M) managaing authorisations for Maintainer resources
• Management Hub which can be a gateway to which devices are connected

12.35.4 Pre-conditions

• Devices (like Air Conditionners) are installed as part of Smart Office and connected via Mangement Hub.
• Each actor is associated to a role
• Management Hub manages the resources exposure based on actors role . And validates all tokens used for device management.
• DAS_O (Dynamic Authorisation Server - Owner) provides token(s) based on the permissions/settings controlled by the Owner
• DAS_M (Dynamic Authorisation Server - Maintainer) provides token(s) based on the permissions/settings controlled by the Maintainer

12.35.5 Triggers

The administrator from Maintainer (M) wants to modify the firmware (sensitive device resource).

12.35.6 Normal Flow

Figure 12.35.6-1 illustrates the high-level flows of a use case showing how Maintainer process to update a Firmware of the devices which consists of the following steps:

• Maintainer requests firmware update (via remote access tool)
  • 1.1 Devices Management Hub detects that this request requires authorization from DAS_M (Dynamic Authorisation Server - Maintainer)
• Devices Management Hub rejects the request cause token is required
• Maintaner requests token from DAS_M
  • 3.1 DAS_M detects that this kind of operation requires the second token request from DAS_O (DAS_M needs to know whether a DAS_O token is needed or not. DAS_O can communicate this information through a security policy, documentation or a specific API)
  • 3.2 DAS_M requests a second token from DAS_O
  • 3.3 DAS_O provides a second token to DAS_M
  • 3.4 DAS_M sends both tokens as a list to Maintainer
• Maintaner sends a request for Firmware Update including both tokens
• Devices Menagement Hub performs the following:
  • 4.1 verifies token provided by DAS_M, extracts Owner token
  • 4.2 verifies token provided by DAS_O
  • 4.3 performs Firware Update on Devices
  • 4.4 confirms Firmware Udate request has been proceeded

Figure 12.35.6-1 Normal flow of access control using several tokens

12.35-7 Alternative Flow

None

12.35.8 Post-conditions

None

12.35.9 High Level Illustration

Figure 12.35.9-1: High level illustration

12.35.10 Potential requirements

The M2M System shall support access control methods using validation of more than one token from different servers for a single operation.