5.1 Introduction

As defined in oneM2M TS-0003 [1], a Secure Environment (SE) provides protected sensitive functions and sensitive data to entities within the M2M system via the Mcs reference point. It serves the purpose of protecting secret or sensitive information (code or data) at rest and in use (i.e. while being used in computing processes). An SE is either implemented on a dedicated hardware component or on a trusted logical entity represented by a set of software functions on the supporting M2M node. An SE shall provide process isolation with respect to code and data residing outside of the SE.

In most M2M ecosystems, multiple stakeholders that do not necessarily trust each other (e.g. Underlying network operator, M2M Service Provider, M2M application provider and end user) need to protect their own sensitive data and functions, M2M nodes should therefore support multiple secure environments that shall provide process isolation between each other. Depending on deployment models, secure environments may be either pre-provisioned before deployment, or created dynamically during the enrolment phase, relying on SE management functionalities provided by the SE Abstraction Layer specified in the present document.

Depending on risk assessment specific to the use case and its associated security requirements several different integration scenarios are possible. They are described within this clause.

Regardless of the underlying instantiation(s) of secure environments implemented on an M2M node, the capability to create, personalize and manage secure environment areas shall be exposed by the local CSE to local AEs via the SE Abstraction Layer, as detailed in the present document. Furthermore, the local CSE itself shall use the locally available secure environment capabilities to protect sensitive information (see oneM2M TS-0003 [1]).

In general the following high level architecture as depicted in figure 5.1-1 applies. However AEs and CSEs may be spread between different processing environments within a node, including security sensitive parts running in local secure environments. The SE Abstraction Layer exposes over Mcs a common security interface to AEs and CSEs components within devices, facilitating independent deployment and management of such components in heterogeneous scenarios.

When an Mcs upstream API is exposed to a oneM2M entity, the CSE components shall rely on secure environment capabilities exposed over Mcs to implement their security services: The Mcs API enables a CSE to implement high level security services exposed on Mcc or Mca by relying on lower level services exposed to the SE Abstraction Layer by locally available secure environment implementations. Bindings of the Mcs functionalities to specific SE implementations can be specified by other organizations or provided as annex to the current document.

Additionally, CSEs may rely on CSE_sec components running inside the secure environment to expose additional optional capabilities through the Mcs layer, to expose further domain specific functionalities over Mca or Mcc. Such extensions are not specified in the present document.

Similarly, AEs may rely on AE_sec components running inside the secure environment to expose additional application specific capabilities to the Mcs layer. Such services are application specific and therefore not specified by oneM2M.

Figure 5.1-1: Secure Environment interworking on Field Domain Node