@GlobalPlatform_

www.linkedin.com/company/globalplatform GlobalPlatformTV

GP Confidential

1

GlobalPlatform and oneM2M InterworkingSebastian Hans (Oracle)Sophia Antipolis 9 Dezember 2015

GlobalPlatform Positioning

Across several market sectors and in converging sectors

GlobalPlatform is the standard for managing applications on secure chip technology

TrustedExecution

Environment

Secure Element

AND

PremiumContent

GlobalPlatform MembersTM

New

Our Collaborative Industry Partners

Milestones 1 Reached Beginning this Year

5

15 billion of SE’s

Milestones 2 Reached this Summer

6

150 Qualified Products

GlobalPlatform Now Provides a Complete Solution

7

Security Requirements of an IoT Device

Secure ManagementProvisioningApp Deployment

Device to device comms: secure Device identification

Send message securely to cloud service (integrity, authenticated, confidential)

IoT – Security Adopting Existing Security Technologies

• Some will adopt GlobalPlatform technologies (Secure Element) for security purposes

– Smart Meters– Medical Equipment– Wearables

9

Taking a step Back

• One issue we discussed for some time in the GP IoT TF is the management of secure components in Gateways and Things deployed in an IoT infrastructure

• In IoT we have multiple wireless protocols– Some are standardized and some are promoted by companies– For a non exhaustive list http://www.eejournal.com/archives/articles/20150907-lpwa/

• We also have multiple messaging protocols– MQTT, CoAP, HTTP, HTTP 2.0, XMPP, ALLJoyn ...– With different security layer protocols like TLS, DTLS, IPsec …

• We first discussed to adopt our existing remote administration protocol which is based on HTTP over TLS to CoAP over DTLS

– But this would also only target a “niche” of the IoT market

• In the IoT-TF we think we are not able to support as GP organisation all of the above protocols and maybe even more

– In case of TLS/DTLS and CoAP , HTTP we talk about moving targets, what makes it even more complicated

10

New and Enhanced Collaborations for IoT

11

oneM2M

GSMA

Why a strong collaboration with oneM2M

• From a standardization point of view the most advanced group– They have a set of REL-1 specifications covering the basics of a Service Architecture– Supporting secure components (SE, eSE, TEE)– Referencing already existing GlobalPlatform and ETSI specification for remote

management of secure components– They are working on REL-2, which will be closed in 2016– Cooperation with ITU, IEEE, ALLjoyn, OIC, 3GPP,….– Presence from GP members in oneM2M– Implementation of oneM2M elements are available in the open source– Commercial implementation are also available – Interoperability testing is on their agenda, Plugtests, Interop events

12

GlobalPlatform and oneM2M

• Since February this year GlobalPlatform 2015 is partner type 2 of oneM2M

• Together with the SEC WG we identified two possible points for collaboration– oneM2M has a WI for an “Abstract Secure Environment API”

• We decided to follow this WI and provide direct input to oneM2M – Part of the oneM2M architecture is the „Interworking Proxy“

• Enables the interworking with external systems

• It is used today to provide interworking between oneM2M and OMA LWM2M, Alljoyn, OIC

• We are analyzing this architecture and plan to develop a GlobalPlatform – oneM2M interworking

to solve the problem of SE management in complex IoT deployments

13

oneM2M release 2 features

Industrial domainenablement (at least 1 normative feature)

• Time series, etc.• In conjunction with the TR

oneM2MBeyond

initial releaseSemanticinteroperability

• base ontology• semantic discovery• semantic descriptions

Security• Enhancement for authorization•Abstract SE API • privacy support• e2e security (?)

oneM2M interworking framework

• Generic interworking• AllJoyn/AllSeen and/or• OIC and/or• OMA LightWeight M2M (OMA LWM2M)•3GPP Rel.13 Interworking

Home domainenablement (at least 1 normative feature)

• Home appliance information models

APP identifiers and registryservices

Advanced protocol binding• WebSocket (?)• Efficient content representations (?)

Abstract Secure Environment API

• Goal is to define an abstract API that fits into the oneM2M architecture and into the oneM2M way of communications

• We plan to provide input to oneM2M that helps them to map their API to the architecture and protocols provided by GP

15

oneM2M node

AECSE

SE abstract API

SE TEE

oneM2M interworking for management

Management Dimension in the GP Architecture

Tx Axraw data

Cx

selected/aggregateddata

saved data

Agent Interface

Endpoint Interface

Thing Gateway

Tx Mx

Cx Ex

managementdata

Managementcommands

Management Interface

Management Interface

Thing Gateway

Functional View Management View

activators

commands

Ex

Management as a Service I

• The typical IoT architecture are based on multiple hops (Gateways) between the Thing and an Endpoint in the Cloud

– Gateways translate between different protocols stacks e.g. • HTTP/TLS/TCP to CoAP/DTLS/UDP

• We finally concluded that the management of secure components in Gateways and Things should be defined as a service deployed in the IoT System

18

Management as a Service II

• We propose to leverage an existing Service Architecture like oneM2M to define a management scheme for devices in the IoT/M2M world

• An architecture that already defines how to deal with intermediate device between the backend and the end-device

• Supports multiple protocols (HTTP, CoAP, MQTT, Websockets)

• And defines how messages can travel through such a network

• An architecture that can integrate with non oneM2M System through Integration Proxies

• A mechanism that is currently adopted by other IoT ArchitecturesLWM2M, ALLJoyn, OIC

• This potentially allows us to integrate with systems like ALLJoyn, OIC …

• We can integrate existing management System with the oneM2M system

19

High level Requirements

• We need end-to-end security for the “GP management object” from the management server to the Secure Component in the Thing

• Every hop in between is transparent and should also see the information to pass the object to the next hop

• We need security on the “GP management object” level

• This enables the management object to travel via multiple protocol stacks

• It must be possible to encapsulate the “GP management object” in a system specific object

• The Thing with the Secure Component needs to be registered to the IoTSystem

– This registration needs to be known by the GP Management “Service” to address the device

• The GP Management Service must be able to push management objects to the Thing

– Ideally the System Architecture provides network agnostic way of pushing objects to a Thing

20

Proposed mapping between GP and oneM2M architecture

Component in GobalPlatform Entity in „oneM2M“

Cx CSE in the Field Domain

Ax AE in the Field Domain

Ex CSE in the Infrastructure Domain

Endpoint Interface AE in the Infrastructure Domain

Thing AE, CSE in the same physical device in the Field Domain (NSE can be also present in a Thing for e.g. location services)

Gateway AE, CSE and NSE in the same physical device in the Field Domain

Cx to Ex communication Mcc reference point

Ax to Cx communication Mca reference point

Is not present in the GP architecture, basically covered as additional function of the Cx

NSE

Mx AE especially for management purpose

Ex to Mx communication Mca reference point

Does not exist in GP the communication in our model will go via the Mcc and Mca reference point

Mca reference point

21

oneM2M Interworking architecture

22

• An interesting aspect of the oneM2M architecture is the „Interworking Proxy“ which is defined in TS-0001

– It enables the integration between oneM2M systems and non-oneM2M system

• The task of the „Interworking-Proxy“ is to perform a full semantic translation of messages between the two systems it connects, or to pass data transparently between the two systems in a <container>

• The “Interworking Proxy” from oneM2M is currently already used by other organization (e.g. Alljoyn, OIC) to integrate their system with a oneM2M system

oneM2M interworking and other organisation

23

oneM2M systems

AE

CSE

AE

CSE

IPE IPE

IPE

• The Interworking Proxy is an element of the oneM2M architecture

– Specification is evolving in REL-6– Leveraged by a growing number of organisations

Work assumptions

• We are talking here about oneM2M “compliant” devices that have a secure component which is compliant with existing GP specifications ((e)SE, TEE)

– The device can host an Application Entity (AE) and this AE can talk to the secure component and exchange the specific message format with such a component

– The AE and the CSE in the device can communicate via a “Abstract SE API” with the secure component

• A GP management server is an external entity for the oneM2M system. It connects via an Integration Proxy to the oneM2M system

• The messages exchanged between the GP management server and the secure component are secured end-to-end and transported transparently through the oneM2M system

– A <container> is used to transport the secured management messages and responses between the management server and the secure component

– The content of the container is defined by GP and secured by mechanism defined by GP

• There is an Admin Agent deployed as AE to the end-device that receives the container and can forward the encapsulated management operation to the secure component, receive the response and send it back via the oneM2M system to the management server

24

Proposal

• We start on a technical document in IoT TF because we missed the opportunity to start a new WI in oneM2M for REL-2

– Write a dedicated technical document describing from the GP point of view the interworking

• Easier to reference from the outside and to be kept in sync with the yearly release cycle of oneM2M

– Analyzing the different interworking scenarios– We communicate with oneM2M about this based on GlobalPlatform input – We plan to coordinate with the development in SEC for the Abstract Secure

Environment API WI to get access to the Secure Environment in the oneM2M device

25

OneM2M architecture main components

09.12.15Title26

Thing

AE

CSE

Field DomainInfrastructure Domain

oneM2M systems

AE

CSE

AE

CSE

Non‐oneM2Msystems

GP RAM

ITE SE

Integration option #1

– ITE is a “Proxy” entity that makes the bridge between the non-oneM2M world and the oneM2M world

• Why not making the IPE look like an Admin Agent on non-oneM2M world side and let GP RAM server talk to it using the standard SC RAM over HTTP?

• IPE would then take the ownership of the data transformation and transport up to the SE on oneM2M side

Drawback: ITE shall simulate millions of SE (e.g. millions of polling to GP RAM…)

27

ThingoneM2M systems

CSE

GP RAM

ITE SESC RAM

over HTTPHTTP

Web

Socket

CSE

Simulates AA behavior

Integration option #2

– SC RAM is made to support several transport protocol• Why not considering oneM2M as a new supported transport?• Data type and Session messages are kept; they are “sent” to the SE though the IPE

• IPE then takes the ownership of the data transformation and transport up to the SE on oneM2M side

28

ThingoneM2M systems

CSE

GP RAM

IPE SE

Send/receiveSC RAM

messages

HTTP

Web

Socket

CSE

API for message exchanges

HTTP

Conclusion

• GlobalPlatform has more then 15 year of experience in developing standard and compliance programs for Secure Elements and their management

• We have always done that in close cooperation with other organisations– For mobile communication, NFC service, ID cards, Payments cards

• To enable the deployment and management of secure components in all kinds of IoT devices for all possible IoT market we have to work together with new partners

• We thing only with a close cooperation between all the standardization and industry organizations the IoT market will be a success

• The interworking architecture of oneM2M is a very good example of enabling such cooperation on the technical level

29

30

http://www.globalplatform.org

Thank you!