security in onem2m release 2 - directory listing / in onem2m release 2 wolfgang granzow* and phil...
Post on 23-May-2018
229 Views
Preview:
TRANSCRIPT
Security in oneM2M Release 2
Wolfgang Granzow* and Phil Hawkes*Senior Director Technology at Qualcomm Germany
oneM2M Security Working Group member< wgranzow@qti.qualcomm.com >
Recap on the oneM2M Architecture• Hierarchical topology of M2M Nodes
– Nodes comprised of Common Services Entities (CSE) and Application Entities (AE)– Field Domain: Middle Nodes, Application Dedicated Nodes, Application Service Nodes – Infrastructure Domain: Infrastructure Node
2
Infrastructure Domain
Field Domain
ASP Operations Support System (OSS)
Data Centre
e.g. M2M/HomeGateway
e.g. SmartMeter
e.g. temperatureSensor
Security Challenges and Solutions
3
Challenge Solution
Huge variety of deployment scenariosvulnerabilities depend on environmentw/o infrastructure for credential mgmt.Intermediate nodes trustedIntermediate nodes not trusted
Secure Communications content confidentiality, integrityvariety of authentication scenarios
Secure comm. between adjacent nodesSecure end-to-end communicationsSecure Environment API (in progress)
Any IoT device in any deploymentOff-the-shelf vs. configurable devicesOn-boarded by professionals vs. unskilled users
Interoperable Remote provisioningA variety of underlying credentials.Provisioning symmetric keysProvisioning certificates (in progress)
Data privacyM2M Device cannot make autonomous judgement calls
Access ControlAccess Control PoliciesAuthorization services, including
Token-based Access ControlRole-based Access Control
Privacy policy management
oneM2M Security Frameworks• Tie together credential management, configuration parameters, establishing
security session (e.g. TLS/DTLS handshake) and protecting the messages or data Security Association Establishment Framework (SAEF): Adjacent entitiesEnd-to-End Security of Primitive (ESPrim): Originator ↔ Hosting CSEEnd-to-End Security of Data (ESData): Data producer to data consumer
4
ADN-AESA2SA1
IN-AESA3
MN-CSE IN-CSE
ESPrim MN cannot see or alter messages
CRUDN CRUDN
Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
MN-CSE can see and alter message. What if it is not
trusted?
oneM2M Security Frameworks
5
ADN-AESA2SA1
IN-AESA3
MN-CSE IN-CSE
(opt) ESPrimMN cannot see or alter messages
Protect using ESData
Protected using ESData.
IN-CSE cannot see or alter app data
IN-AE usesusing ESData to extract app data
What if IN-CSE is not trusted with
this app data?
CRUDNCRUDN
Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
• Tie together credential management, configuration parameters, establishing security session (e.g. TLS/DTLS handshake) and protecting the messages or data Security Association Establishment Framework (SAEF): between adjacent entitiesEnd-to-End Security of Primitive (ESPrim): Originator ↔ Hosting CSEEnd-to-End Security of Data (ESData): Data producer to data consumer
Message Security between adjacent devices
• Uses (Datagram) Transport Layer Security Protocols, TLS/DTLS Version 1.2• Several Security Association Establishment Frameworks are supported:
1) Authentication and session key establishment using symmetric keys shared by devices 2) Authentication and session key establishment using Certificates provisioned to devices 3) Authentication facilitated by an M2M Authentication Function (MAF) hosted by M2M-
SP or third-party• The MAF authenticates the end-points (PSK or certificates) and facilitates establishing a symmetric key
6
ADN MN IN
SA2SA1Legend:SA Security AssociationADN Application Dedicated NodeMN Middle NodeIN Infrastructure Node
ADN/ASN/MN IN
SA
IN
SA
MAF
ADN/ASN/MN
(D)TLS
Remote Security Provisioning Frameworks (RSPF)
• M2M device is preconfigured with credentials to establish SA with a remote provisioning server (M2M Enrolment Function, MEF)– MEF is operated by trusted 3rd party (device manufacturer, underlying network
operator) or M2M Service Provider– MEF can be the Bootstrapping Server Function (BSF) of 3GPP Generic
Bootstrapping Architecture (GBA)• MEF can provision symmetric keys or (work in progress) certificates
7
Node 2SA
MAF
Node 1
MEF RSPFMAF-based SAEFSAEF
E2E Protection of primitives (“ESPrim”)
• Interoperable framework for securing oneM2M primitives – CSEs (forwarding the primitive) do not need to be trusted – ESPrim provides mutual authentication, confidentiality, integrity protection
and a freshness guarantee (bounding the age of ESPrim Objects).– Protocol: JSON Web Encryption (JWE) using a symmetric key
• Symmetric key can be established by pre-provisioning (using MEF), End-to-end Certificate-based Key Establishment (ESCertKE), or central authentication server (MAF)
8
EntityA
SA2SA1Entity
B
SA3
MN MN/IN
ESPrim, using JWE
MEF orMAF
E2E Protection of selected data (“ESData”)• interoperable framework for protecting a selected data portion of a primitive
– data to be protected is called the ESData Payload. – transited CSEs do not need to be trusted with that data. – ESData payload could typically compose all or part of an attribute value (e.g. content
attribute value of a <contentInstance> resource) or a primitive parameter (e.g. a signed, self-contained access token communicated in a request primitive to obtain dynamic authorization).
– Protocol: JSON Web Encryption/Signature (JWE/JWS) or XML Encryption/Signature
9
EntityA
MN MN/IN
SA2SA1
EntityB
SA3
protected data
MEF orMAF
Authorization using Access Control Lists
• Access control rules define who can do what under whichcircumstances
10
Dynamic Authorization• Dynamic Authorization: Originator or Hosting CSE requesting authorization of Originator –
provided by a Dynamic Authorization System (DAS) Server
– Direct Dynamic Authorisation: Hosting CSE submits request to DAS, Originator is not involved
– Indirect Dynamic Authorisation: Originator submits request to DAS Server using info provided by Hosting CSE. Similar to OAuth. See figure below.
– DAS has multiple options for authorizing: Issue/update access control rules, assign Role(s) to the Originator, issue JSON Web Tokens (JWT)
11
HostingCSE
OriginatorAE or CSE
1. Request2. Response (‘no privilege’)
DASServer
3. Request for Token4. Response (Token or Token ID)
5. Request (Token or Token ID) 8. Response (‘success’)
6. Request (with parameters from step 5)
7. Response(with Token or
dynamicACPInfo)
Req/resp: steps 1,2,5,8Direct DA: steps 6,7Indirect DA: steps 2-5 & (opt) 6,7
Privacy Policy Manager• Manages access to Personally Identifiable Information (PII) on behalf of users • Uses a “Terms and Condition’s Mark-up language”
12
CSE (hosting PII)
Privacy Policy Manager(operated by M2M SP or trusted 3rd party)
Application Service Provider (ASP)
User
1. User privacy preferences
2. ASP privacy policy
7. ASP’s AE requests PII
4. Customized privacy policy
3. Creates user-friendly customized ASP privacy policy for User
8. ACPs or dynamic authorization
5. Accept/decline
6. Creates access control policies (ACPs)
9. PII
KEYWhen User and ASP Register w/ PPMWhen User subscribes for ASP serviceWhen ASP requests PII
M2M Device (source of PII)
AE
top related