linux&founda+on& collaboraonsummit: oicsecurity& · 2017. 12. 14. ·...

1 1

Linux Founda+on Collabora+on Summit:

OIC Security Ned Smith

Intel

2 2 Open Source Technology Center

IoT – A Metaphor for “Pelagic” Compu+ng

• What do I mean by pelagic compu;ng?

Larval slipper lobster riding on salp chain*

*SRC: www.jacksdivinglocker.com

Venus Girdle*

Ctenophore*

Real simple structures that can connect to other structures to form more complex structures that are autonomous or semi-‐autonomous

Sensor

Actuator

Controller

Other


IoT is also about Clouds

• Cloud compu;ng essen;ally means – Unlimited storage, compute power and availability

• Pelagic + Cloud compu;ng implies –  Pelagic behaviors may be monitored and analyzed over long periods and

– Cloud analy;cs may inform pelagic controllers making them smarter

Security objective: Enable intended pelagic interactions while preventing

unintended interactions

Cloud Compu;ng

Monitoring Informing

Analy;cs

Pelagic Compu;ng


Controller

OIC Terminology

•  Intermediary is a role that combines client & server

OIC Client

Actions

OIC Server

Resources

Access Control

OIC Device

OIC Client

Actions

OIC Server

OIC Device

Resources

Access Control

Resource Access Request

Actuator Sensor

OIC Server

Resources

Access Control

• A Device is an OIC stack instance • Devices implement Client & Server roles

• Devices have Resources and perform Ac;ons

•  Resources have AVributes, Proper;es and Interfaces


Security Significance of OIC Layering

• Security seman;cs are managed at OIC Resource layer

• Resource level access is enforced at the Resource layer

• Device level access is enforced at the OIC Exchange layer – Keys reside at the Resource layer

• Device ownership may be derived using network layer or other hardware – May be vendor specific!

OIC Resource Layer

OIC Clients OIC Servers

Containerization (e.g. JSON)

OIC Exchange Layer

COAP

Message Protection

Other Message Exchange ...

E2E Protection (e.g. DTLS)

OIC Resources

OIC Network Abstraction Layer

UDP/IP BLE 802.15 ...

OIC Intermediaries

Other E2E Protection ...

Network Layer


How To Dis+nguish Intended vs. Unintended? •  Access control granularity has four scoping levels

–  Group, Device, Resource and AVribute •  OIC scripts specify interac;on paVerns

–  Peer-‐peer, Observer, Subscribe-‐no;fy, etc... •  Authoring tools are privileged

–  They specify intended mul;-‐device interac;ons

#%RAML 0.8 +tle: OIC Light set /Collec+on01: type: oic.collec+on get: responses: applica+on/json: schema: | { "$schema": "hYp://json-‐schema.org/schema", "rt": { "type": "string", "required":true }, "if": { "type": "string", "required":true }, "resourceref": { "link": { "type": ”URI" } } } example: | { "rt": "oic.collec+on", "if": "oic.if.b", "resourcelinks": { ”href": ”Device2/oic/Light01", ”href": ”Device3/oic/Light02” } }

Example ACL

#%RAML 0.8 +tle: OIC Light /Light01: type: oic.light get: responses: applica+on/json: schema: Light example: | { ”on": ”True", } }

Example Resources

acl0

Device1

/oic/Light01

Read

Device1

Device2

OIC Server

Informs


Responding Device

Access Control Model

acl(s) service(s) cred(s)Local Resource(s)

LocalCred

SvcType

DeviceIDSubjectID

CredID

RoleID

CredTypePublicDataPrivateData

/oic/d

/oic/light/3

...

Resource(s)

Permission

Period

Recurrence

Subject(s)

RemoteCred

Access Control Layer

Network Abstraction Layer

DTLS Layer

Requesting Device

Request Access

Allow Access

End Point

DTLS Session

1 2 3


Device and Group Level Access

• Pair-‐wise keys enable device level access – DTLS

DeviceServer

Secure port=def 5684

Insecure port=def 5683DeviceClient

IP/UDP/CoAP

• Shared group key enables group level access • /oic/sec/cred structure may contain pairwise and group keys

–  Pairwise keys may be used to provision group key –  e.g. dra\-‐keoh-‐tls-‐mul;cast-‐security-‐00

Device_ID_1 Device_ID_2


Mediated Creden+al Provisioning

Device 1 Device 2 Credential Provisioning

Service

3. Discover Provisioning service (optional)

6. Generatekeys for Devices 1 and 2

8. POST /oic/sec/cred [{“device1”:”cred1”...}]

(oic.sec.cps)


11. RSP 2.01

4. Open DTLS w/ oic.sec.cps PSK

7. GET/oic/sec/cred [{“device1”:”cred1”...}]

1. Discover Provisioning service (optional)

2. Open DTLS w/ oic.sec.cps PSK

5. GET/oic/sec/cred [{“device2”:”cred2”...}]

10. RSP 2.01


Ad-‐hoc Pair-‐wise Creden+al Nego+a+on Device 1 Device 2

Registration Service

Device 3

2. Mediated Discovery (optional)

4. DH session keys used as pair-wise PSK for Devices 1 and 2.



9. RSP 2.01

3. Open DTLS w/ Diffie-Hellman

1. Ad-hoc Discovery (optional)

12. RSP 2.01

5. Instantiate d1.cred2; cred.type = 1 (PSK)

8.Verify d1.cred2 = cred2

6. Instantiate d2.cred1; cred.type = 1 (PSK)

11.Verify d2.cred1 = cred1


ACL Resource • An ACL is a resource with the following defini;on

Subject Resource Permission Period Recurrence

UUID (Device or Group), Role

URI Path C,R,W,E,D Start-‐Stop Time (RFC5545)

Recurrence PaVern (RFC5545)

• Example ACL policies Subject Resource Permission Period RecurrenceUUID1, UUID2 /oic/sh/light/3 0h001F

(C,R,W,E,D)19970101T180000Z/19970102T070000Z

RRULE:FREQ=WEEKLY;UNTIL=19970131T070000Z

UUID3 /oic/d 0h0001 (R) - -

oic.sec.role.admin /oic/sec/acl/0 0h001F - -


Resource Access Example

•  Access is blocked if no ACL present •  Device level access evaluated before evalua;ng resource access •  Resource level access applies to resource named in ACL

–  Resource references may be fully qualified (e.g. <deviceID>/oic/light/1)

/oic/d

Model

Mfg Date

OIC ServerOIC Client

GET /oic/d

DevID_1

OIC Device

AVributes

acl1

DevID_2, _3

acl0

DevID_1

/oic/d

Read

/oic/light/1

On-Off

DimLevel

AVributes

OIC Stack

(DevID_1) /oic/light/0

On-Off

DimLevel

AVributes

DevID_2

PUT /oic/light/1

(DevID_2)

/oic/light/1

Read, Write

9 - 5

Daily

[{“/oic/d”, “Model”, “T”, “Mfg Date”, “1/1/2015”}]

[{“/oic/light/1”, “On-‐Off”, “Off”, “DimLevel”, “80”}]

RSP 2.04


AYribute Access Example

acl0

DevID_1

/oic/RsrcAtt-1

Read

OIC Server

acl1DevID_1

/oic/RsrcAtt-2

Write

• AVributes are opaque to OIC stack • AVribute level access can be achieve using collec;ons

– Where a resource is created containing a single aVribute

• ACL policy can be created for the new resource

{"$schema": "http://json-schemas.org/schema#", "id": "http://openinterconnect.org oic.thing#", "definitions": { "oic.thing": { "type": "object", "properties": { “Attribute-1” {“type”: “type1”} “Attribute-2” {“type”: “type2”} ... } } }}

Opaque to OIC Stack

{"$schema": "http://json-... ... "type": ”collection", ”resources": { “Attribute-1”, “Attribute-2”} ... definitions”: { “oic.RsrcAtt-1”: { “type”: “object”, “properties”: { “Attribute-1” {“type”: “type1”} } ... “oic.RsrcAtt-2”: { “type”: “object”, “properties”: { “Attribute-2” {“type”: “type2”} } ...

Example Resource Defini;ons:

Single Attribute Resource can

have ACL Policy


Establishing Device Ownership

• Device ownership determines how / if the device is provisioned • Taking / transferring ownership securely requires device manufacturer support Just Works Mode Switch Random PIN Pre-provisioned

PINPre-provisioned Credential

• OIC members are working to standardize methods for establishing device ownership

*Source: hVp://blog.atmel.com/2014/08/12/the-‐abcs-‐of-‐ecdsa-‐part-‐2/

*


•  Can establish device owner over-‐the-‐air •  Can be implemented in DTLS ciphersuites •  Can be privacy preserving (e.g. TPM EK / DAA) •  Can aVest device trust proper;es •  Provably secure against iden;ty misbinding aVacks •  Resul;ng symmetric keys are good for performance

Device Owner Transfer with Signed Diffie-‐Hellman

... UDP/IP

DTLS

Handshake Layer

CoAP

Record Layer

Network Abstrac;on Layer

Device (A) Device (B)

ga || GID

[gb || CertB || SigB(gb || ga)]SMK || SigRL

[ga || GID || AVesta;onID || SigA(ga || gb)]SMK (SK, MK) session key

Embedded Key A

SMK || SK || MK = KDF(gab) Cer;ficate Key B


Conclusion

• OIC security mechanisms support “pelagic” compu;ng models – Autonomous and semi-‐autonomous opera;on – Ad-‐hoc device interac;ons –  Fric;onless access control for intended device interac;ons

–  Added fric;on when device interac;ons are unintended – An;cipates device grouping and composi;on – Aligned key management with IoT use models


Call to Ac+on

• OIC is working to deliver interoperable security for IoT • Membership in OIC will ensure your IoT solu;ons benefit from interoperability goal

• Your contribu;ons to IOTIVITY will help realize secure IoT solu;ons quicker


Ques+ons?


Overview of EPID

•  EPID can be seen as a privacy preserving signature scheme –  One group public key corresponds to mul;ple private keys –  Each private key can be used to generate a signature –  Signatures can be verified using the group public key –  EPID is standardized in ISO/IEC 20009-‐2 –  Scalable manufacturing in high volume circuits

EPID pub-key

pvt-key 1

Sign

Message

EPID Signature

Verify

Message, EPID Signature

True / False pvt-key n pvt-key 2

…

linux&founda+on& collaboraonsummit: oicsecurity& · 2017. 12. 14. ·...

Documents