1. Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: 2015-09-28 Agenda Item: Security API

2. Introduction New reference point(s?) should be introduced to oneM2M Architecture. This contribution aims to share the interpretation of required functionalities, and to clarify missing parts for security domain in Rel-1 architecture.

3. New functionalities in Rel-2 Dynamic Authorization – Issue token allowing third-party access – Authorize access for token holder (=M2M App) (Controlling) Secure Environment – Enable/Disable SE functions – Get status of SE function End-to-End privacy – Provide secure communication channel between Applications Field Device Configuration – Install AE credential to registrar CSE

4. Dynamic Authorization IN-CSE AE (Authorizer) AE (3 rd -Party) Hosting CSE 1.Requet for access permission 6.Revoke permission (optional) 3.Issue token 2. Provision token with access rule 5. Access with token 4. Share token (offline ?) Web Portal Browser M2M Platform Service App 1. Send Web page asking user permission 2. Send a form data to authorize 3.Request to setup Access permission 4. Issue token 5. Forward token 7. Access granted 6.Request access to Resource with token Use case for web application (service portal) Possible call flow for use case

5. End-to-end privacy M2M Platform 1.Request to setup secured container 2. Send resource URI with paired key Possible solution for E2E privacy (secured container) Paired App Owner App 4. Access to the secured container 3. Notify paired key for the URI

6. Field Device Configuration IN-CSE Admin App AE (3 rd -Party) Registrar CSE 1.Requet to setup account 3. Receive configurat ion data 2. Provision account setting for AE 5. Registration 4. Configure device with received setting (offline ?) Web Portal Browser M2M Platform Registrar CSE 1.Request for enrollment 5.Forward configuration data 2.Request to setup new account (=AE) for device 4. Send configuration data 3. Provision account settings and credential for incoming device Use case for web application (service portal) Possible call flow for use case AE 6. Install config. (offline ?) 7. Registration Request to Registrar

7. Field domain node Interpretation of SE (TBD) remote CSE Protection Level Description 0 No protection. The data are exposed even without active attacks. 1 Low protection, data are protected from passive observers but could be exposed by active attacks, be they local or remote. E.g. software solutions exist that rely on general purpose processing hardware of the supporting equipment. 2 Medium protection, protection of the data from remote attacks is addressed, but local attacks, especially physical attacks, remain possible, ie. Medium protection provides countermeasures against software attacks only E.g. Software solutions to protect data and sensitive functions rely on specific processing providing enforced isolation and enables sensitive code and data to be kept away from an unprotected operating environment, software and memory. The code running in the protected environment is cryptographically verified for integrity assurance. 3 High protection, addressing both remote and local attacks to access the data, including attacks involving physical access. This includes strong counter measures against software and hardware attacks, such as detection of abnormal operating conditions and scrambling plus hardware masking of the memory and side channel analysis of operations involving sensitive data. Table 6.3.1-1: Classification of Protection levels (Description in TS-0003) The security sensitive data and security functions contained in M2M field domain nodes shall be protected from unauthorized access or alteration, as determined by risk analysis. Sensitive data and functions include security credentials and algorithms that manipulate them. The purpose of the Secure Environment is to provide the required protection level (see Table 6.3.1-1) and isolation of security sensitive data and functions within an M2M node. This is especially critical for M2M Nodes that can be remotely or physically accessed by potential attackers. Secure Environment local AE local CSE Secure Storage Secured functions SE Agent (TBD) IN-CSE remote AE Remote control Control Mcs Mca Mcc Mca Mcs ?

8. Gap Analysis Authorization – Rel-1 does not support authorization setting other than identity(e.g. AE-ID) based access control Authentication – Rel-1 only supports AE authentication by registrar CSE, and it does not specify how credential can be shared with AE and registrar CSE. Accounting – Accounting event is specified by activities on network API usage, but not for API calls (e.g. operation on hosted resource) – It is not specified how the third party access should be handled. Communication (?) – There are no specification to configure MN-CSEs for security settings – Rel-1 does not accommodate key-sharing for End-to-end privacy

9. Proposed functionalities Token management – Issue token for permission (‘who’ can do ‘what’ for ‘which resource’) – Configure Hosting CSE to accept request with token (issued from IN- CSE) Authentication – Authentication request for connecting AE to IN-CSE – Add authentication setting on Registrar CSE Accounting – Record and/or signing on resource op-call event by Hosting CSE – Record access by AE-ID and/or token-id Communication – Add or remove credential to authenticate AE/CSE – Request to pairing shared key (using public cryptgraphic technique)

10. Way forward Identify the gap on Rel-1 specification Add new functionalities on TS-0004 as V.2.x Define integrated reference point for controlling security functions on remote CSE