Chair of Network Architectures and Services Department of Informatics Technical University of Munich Mutual Authentication and Authorization for Interconnecting Home Automation Systems Master Thesis – Final talk Karthik Mathiazhagan Advisor(s): Dr. Marc-Oliver Pahl, Stefan Liebald Supervisor: Prof. Dr.-Ing. Georg Carle Technical University of Munich (TUM) Department of Informatics Chair of Network Architectures and Services Garching, 19. March 2017 (Cooperation with) Philips Lighting B.V. Eindhoven, NL Supervisors: Dr. Sandeep S. Kumar, Sahil Sharma BF_Research Professional Spaces Philips Lighting B.V. HTC 7, Eindhoven, NL
Agenda • Goal • Analysis • State-of-the-art • Related Works • Design • Implementation • Protocol Models • Evaluation • Conclusion and Future work • Demo Karthik Mathiazhagan 2
Goal - Connected Smart Home Home Network Intern et Bridge Home Lighting Lighting System System Lightin Services Services g Syste m Trigger Lights in case of Fire Home Safety Safety Safety System System Syste Services Services m Smoke Detector Goal • Secure Interaction of devices across different home automation systems. • Device Identity - Authentication • Device Access Control - Authorization Karthik Mathiazhagan 3
Analysis - Challenges Authorization- Authorization- Domain 2 Domain 1 Lighting System Safety System Services Services Authorizat Authorizati ion on (AS (CAS Server Server ) ) Smoke Bridge Detector Inter domain interaction Clien Resource t Server Lighting Safety Challenges System System • Mutual Authentication across domains. Devices need to identify other devices across domains. • Mutual Authorization across domains. Devices are authorized for only certain interactions with other devices. • IoT Protocols (lightweigth, less packet size). To pertain to industry standards. CoAP, CBOR, DTLS, CWT, COSE Karthik Mathiazhagan 4
State-of-the-Art – OAuth 2.0 Client Credentials Grant • Why OAuth ? Most widely used Authorization Framework on Internet. • Enables Authorization for clients to access an HTTP resource on a server. 1. Intra domain communication AS AS RS C POST /token HTTP/1.1 { Grant Type = client credentials Client id = Device ID Client Secret = Device Secret } HTTP 200 OK 3. Internet TLS Client { "access_token":"2YotnFZFEjr1zCsicMWpAA" Protocols Authentication } HTTP /GET "access_token":"2YotnFZFEjr1zCsicMWp Client AA" Authorization 2. Only client Authorization Karthik Mathiazhagan 5
Related Works • Authentication using CERT & Authorization using tickets • Inter Domain Communication • Tickets bound to cryptographic keys (PoP tokens) • Authentication and Authorization using Session Keys • Flat Authorization (Authenticated equals Authorized) • Introduces new entity (KDC) Based on Centralized Authorization Based on Local Authorization Entities [Source] - L. Peng, Z. Rui, and L. Sizuo, [Source] - K. Hokeun, W. Armin, B. M., and L. A New Model for Authentication and Edward A., A Secure Network Architecture for Authorization across Heterogeneous the Internet of Things Based on Local Trust-Domain . IEEE, Dec. 2008. Authorization Entities . IEEE, Aug. 2016. Karthik Mathiazhagan 6
Design – Device Provisioning Lighting System Security System Services Services Trust CA AS S Device Id Device Id Operational Operatio Device Device Certifjcate nal Secret Secret Certifjcat e Inter domain interaction Clien Resource t Server Lighting Security System System Design Requirements • Asymmetric interdomain interaction • Symmetric interdomain interaction • Inter domain interaction using IoT protocols (CoAP, DTLS, CWT, CBOR, COSE). Karthik Mathiazhagan 7
Design - Models 1. Asymmetric Model When device is provisioned with Operational CERT 2. Symmetric Model When device is provisioned with Device ID & Secret Assumption : CAS – AS have prior trust relationship by exchange of root manufacture certificates (out of scope of this thesis). Design - Steps Step 1 – only once. AS AS CAS CAS Step 2 and 3 – Less frequent. 2. RS 3. Client Authorization Authorization Step 4 – More frequently executed 1. Discovery of RS 4. Resource Access Resource Server Client Karthik Mathiazhagan 8
Implementation • Application layer Protocol • CoAP • Concise Binary Object Representation (CBOR – payloads) • Transport layer Security Why ? • DTLS Best fit for using IoT • X509 Certificates Standard Protocols • Raw Public Keys • Symmetric Keys • Access control using CBOR Web Tokens (CWT) • CWT protection using COSE Karthik Mathiazhagan 9
Asymmetric Model 1. Discovery of RS 1. Discovery of RS RS AS CAS C [ CoAP Discovery ./well-known/CORE/] [ RS_ID, AS_ID,Scopes] [ Message ] : CoAP Message. X_ID : Unique ID for X S X : Scope of X Karthik Mathiazhagan 10
Asymmetric Model Authz Domain 2 Authz Domain 1 ACCESS_Toke C RS AS CAS n { Issuer [ QUERY_REQ (aud : RS, authz : AS, Audience Scopes ) ] DTLS {OP_CERT C , CERT CAS } Subject Scope 2. RS 2. RS Issued At Authorization [ { ID_Token C } SIG CAS , ROOT_CERT RS , S RS ] Authorization Valid Till SKey DTLS {OP_CERT C , CERT CAS } [ TOKEN_REQ (aud : RS),{ ID_Token C } SIG CAS , S RS ] } DTLS {OP_CERT C , CERT AS } ID_Token { Issuer 3. Client 3. Client Audience [ TOKEN_RESP { ACCESS_Token } SIG AS , S RS ] Authorization Authorization Subject DTLS {OP_CERT C , CERT AS } Auth Type Issued At [ UPDATE Valid Till {ROOT_CERT C ] } DTLS {OP_CERT RS , OP_CERT AS } Less Frequent [ Message ] : CoAP Message. DTLS {CERT X } : DTLS, Authentication of X using Digital Certifjcates. [ Resource Access_REQ, DTLS {OP_CERT X { ACCESS_Token } SIG AS ] , OP_CERT Y } : DTLS, Mutual Authentication of X, Y using DTLS {OP_CERT C , OP_CERT RS } Operational Certifjcates. {Message} SIG X : Message [ Resource signed with private key of X. Validate S X : Scope of X Access_RESP ] 4. Resource Access 4. Resource Access ACCESS_T oken ROOT_CERT X – Root DTLS {OP_CERT C Certifjcate of X , OP_CERT RS } More Frequent Karthik Mathiazhagan 11
Symmetric Model Authz Domain 2 Authz Domain 1 C RS AS ACCESS_Toke CAS n { Issuer [ QUERY_REQ (aud : RS, authz : Audience AS, Subject Scopes ),C_ID, C_Secret ] DTLS Scope 2. RS [ { ID_Token } SIG CAS , ROOT_CERT RS , S RS ] 2. RS Issued At {CERT CAS } Authorization Valid Till Authorization DTLS {CERT CAS } SKey } [ TOKEN_REQ (aud : RS),{ ID_Token } SIG CAS , Skey C-RS , ID_Token { S C ] DTLS {CERT AS } Issuer Audience 3. Client 3. Client Subject [ TOKEN_RESP { ACCESS_Token } I AS-RS , Skey C-RS ,S C ] Authorization Authorization Auth Type DTLS {CERT AS } Issued At Valid Till Get Skey C-RS [ AUTHZINFO_REQ, } { ACCESS_Token } I AS- [ Message ] : CoAP RS ] Message. Validate & Get Skey C-RS DTLS {CERT X } : DTLS, Less Frequent [ AUTHZINFO_RESP ] Authentication of X using From ACCESS_T oken Digital Certifjcates. DTLS {OP_CERT X , OP_CERT Y } : DTLS, Mutual Authentication of X, Y using Operational Certifjcates. {Message} SIG X : Message [ Resource Access_REQ ] signed with private key of X. {Message} I X-Y : Encrypted DTLS {Skey C-RS } & Integrity protected message using shared key between X-Y . [ Resource S X : Scope of X 4. Resource Access 4. Resource Access Access_RESP ] ROOT_CERT X – Root DTLS {Skey C-RS } Certifjcate of X More Frequent
Evaluation Packet Sizes Karthik Mathiazhagan 13
Evaluation – Keys Storage Karthik Mathiazhagan 14
Conclusion Asymmetric Model Symmetric Model Mutual Authentication Mutual Authorization IoT Protocols Asymmetric Model: • Less Frequent interactions between client and resource server. • Operational Certificates. Symmetric Model: • More Frequent interactions between client and resource server. • Symmetric Credentials. Karthik Mathiazhagan 15
Future Work Home Network Lighting System Safety System Services Services Authorizati Authorizat on (CAS ion (AS Server ) Server ) Lighting Safety System System Clien Resource t Server Smoke Detector Bridge • Currently CAS and AS are considered to be in the cloud (outside home network). • In future, Bring CAS and AS inside the home network. Run them as a service on the smart home device itself. Every interaction between (C -> CAS, C -> AS , C -> RS) devices can be symmetric. Karthik Mathiazhagan 16
Demo - Topology Karthik Mathiazhagan 17
Questions? Karthik Mathiazhagan 18
Recommend
More recommend
