Linux Founda+on Collabora+on Summit: OIC Security Ned Smith Intel 1
IoT A Metaphor for Pelagic Compu+ng What do I mean by pelagic compu;ng? Other Controller Larval slipper lobster riding on salp chain* Actuator Ctenophore* Sensor Venus Girdle* Real simple structures that can connect to other structures to form more complex structures that are autonomous or semi- autonomous *SRC: www.jacksdivinglocker.com 2
IoT is also about Clouds Cloud Compu;ng Analy;cs Monitoring Informing 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 3 Pelagic Compu;ng Security objective: Enable intended pelagic interactions while preventing unintended interactions
OIC Terminology 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 OIC Device OIC Client Actions Resource Access Request OIC Device OIC Server Access Control Resources Sensor Controller Actuator OIC Server OIC Client OIC Server Access Control Actions Access Control Resources Resources Intermediary is a role that combines client & server 4
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 Clients OIC Servers Containerization (e.g. JSON) COAP E2E Protection (e.g. DTLS) OIC Resource Layer OIC Resources OIC Exchange Layer Message Protection Other Message Exchange... OIC Network Abstraction Layer OIC Intermediaries Other E2E Protection... UDP/IP BLE 802.15... Network Layer 5
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: Device1 Example Resources Device2 schema: { "$schema": "hyp://json- schema.org/schema", #%RAML 0.8 +tle: OIC Light "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 } } /Light01: type: oic.light get: responses: applica+on/json: schema: Light example: { on": True", } } Informs Example ACL OIC Server acl0 Device1 /oic/light01 Read 6
Access Control Model Responding Device Local Resource(s) /oic/d /oic/light/3... acl(s) service(s) cred(s) Subject(s) DeviceID CredID Resource(s) SvcType SubjectID Permission LocalCred RoleID Period RemoteCred CredType Recurrence PublicData PrivateData Allow Access Access Control Layer DTLS Layer Network Abstraction Layer Request Access End Point DTLS Session 3 Requesting Device 1 2 7
Device and Group Level Access Pair- wise keys enable device level access DTLS Device Client IP/UDP/CoAP Insecure port=def 5683 Device Server Device_ID_1 Secure port=def 5684 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_2 8
Mediated Creden+al Provisioning Device 1 Device 2 Credential Provisioning Service 1. Discover Provisioning service (optional) (oic.sec.cps) 2. Open DTLS w/ oic.sec.cps PSK 3. Discover Provisioning service (optional) 4. Open DTLS w/ oic.sec.cps PSK 5. GET/oic/sec/cred [{ device2 : cred2...}] 7. GET/oic/sec/cred [{ device1 : cred1...}] 6. Generate keys for Devices 1 and 2 8. POST /oic/sec/cred [{ device1 : cred1...}] 9. POST /oic/sec/cred [{ device2 : cred2...}] 10. RSP 2.01 11. RSP 2.01 9
Ad- hoc Pair- wise Creden+al Nego+a+on Device 1 Device 2 Device 3 Registration Service 1. Ad-hoc Discovery (optional) 2. Mediated Discovery (optional) 3. Open DTLS w/ Diffie-Hellman 5. Instantiate d1.cred2; cred.type = 1 (PSK) 6. Instantiate d2.cred1; cred.type = 1 (PSK) 4. DH session keys used as pair-wise PSK for Devices 1 and 2. 7. POST /oic/sec/cred [{ device2 : cred2...}] 8.Verify d1.cred2 = cred2 9. RSP 2.01 10. POST /oic/sec/cred [{ device1 : cred1...}] 12. RSP 2.01 11.Verify d2.cred1 = cred1 10
ACL Resource An ACL is a resource with the following defini;on Subject Resource Permission Period Recurrence UUID (Device or Group), Role Example ACL policies URI Path C,R,W,E,D Start- Stop Time (RFC5545) Recurrence PaVern (RFC5545) Subject Resource Permission Period Recurrence UUID1, UUID2 /oic/sh/light/3 0h001F (C,R,W,E,D) 19970101T180000Z/ 19970102T070000Z RRULE:FREQ=WEEKL Y;UNTIL=19970131 T070000Z UUID3 /oic/d 0h0001 (R) - - oic.sec.role.admin /oic/sec/acl/0 0h001F - - 11
OIC Client DevID_1 GET /oic/d OIC Device DevID_2 PUT /oic/light/1 RSP 2.04 (DevID_1) OIC Stack (DevID_2) Resource Access Example acl0 DevID_1 /oic/d Read acl1 DevID_2, _3 OIC Server [{ /oic/d, Model, T, Mfg Date, 1/1/2015 }] /oic/light/1 Read, Write 9-5 Daily /oic/d AVributes Model Mfg Date [{ /oic/light/1, On- Off, Off, DimLevel, 80 }] /oic/light/0 AVributes On-Off DimLevel /oic/light/1 AVributes On-Off DimLevel 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) 12
AYribute Access Example Example Resource Defini;ons: {"$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 } Single Attribute... Resource can definitions : { have ACL Policy oic.rsrcatt-1 : { type : object, properties : { Attribute-1 { type : type1 } }... oic.rsrcatt-2 : { type : object, properties : { Attribute-2 { type : type2 } }... OIC Server acl0 DevID_1 /oic/rsrcatt-1 Read acl1 DevID_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 13
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 PIN Pre-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/ 14
Device Owner Transfer with Signed Diffie- Hellman Device (A) Device (B) CoAP g a GID DTLS Embedded Key A [g b Cert B Sig B (g b g a )] SMK SigRL Cer;ficate Key B SMK SK MK = KDF(g ab ) Handshake Layer [g a GID AVesta;onID Sig A (g a g b )] SMK (SK, MK) session key Record Layer Network Abstrac;on Layer UDP/IP... 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 15
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 16
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 17
Ques+ons? 18
Overview of EPID EPID pub-key Message Message, EPID Signature Sign Verify pvt-key 1 pvt-key 2 pvt-key n EPID Signature True / False 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 19