SLIDE 1
2 Karthik Mathiazhagan
Agenda
- Goal
- Analysis
- State-of-the-art
- Related Works
- Design
- Implementation
- Protocol Models
- Evaluation
- Conclusion and Future work
- Demo
Mutual Authentication and Authorization for Interconnecting Home - - PowerPoint PPT Presentation
Mutual Authentication and Authorization for Interconnecting Home - - PowerPoint PPT Presentation
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
SLIDE 2
SLIDE 3
3 Karthik Mathiazhagan
Goal
- Secure Interaction of devices across different home automation systems.
- Device Identity
- Authentication
- Device Access Control - Authorization
Goal - Connected Smart Home
Lighting System Services Lighting System Services
Intern et Home Lightin g Syste m Home Safety Syste m Home Network
Safety System Services Safety System Services
Smoke Detector Bridge Trigger Lights in case of Fire
SLIDE 4
4 Karthik Mathiazhagan
Analysis - Challenges
Safety System Services Lighting System Services Inter domain interaction Smoke Detector Bridge Safety System Lighting System Authorization- Domain 1 Authorization- Domain 2 Clien t Resource Server (AS ) Authorizati
- n
Server (CAS ) Authorizat ion Server Challenges
- 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
SLIDE 5
5 Karthik Mathiazhagan
State-of-the-Art – OAuth 2.0 Client Credentials Grant
POST /token HTTP/1.1 { Grant Type = client credentials Client id = Device ID Client Secret = Device Secret }
Client Authentication
HTTP 200 OK
{ "access_token":"2YotnFZFEjr1zCsicMWpAA" } HTTP /GET "access_token":"2YotnFZFEjr1zCsicMWp AA"
C RS AS AS
TLS
- 1. Intra domain communication
- 2. Only client
Authorization
- 3. Internet
Protocols
- Why OAuth ? Most widely used Authorization Framework on Internet.
- Enables Authorization for clients to access an HTTP resource on a server.
Client Authorization
SLIDE 6
6 Karthik Mathiazhagan
Related Works
Based on Centralized Authorization Based on Local Authorization Entities
[Source] - K. Hokeun, W. Armin, B. M., and L. Edward A., A Secure Network Architecture for the Internet of Things Based on Local Authorization Entities. IEEE, Aug. 2016. [Source] - L. Peng, Z. Rui, and L. Sizuo, A New Model for Authentication and Authorization across Heterogeneous Trust-Domain. IEEE, Dec. 2008.
- Authentication using CERT & Authorization using tickets
- Tickets bound to cryptographic keys (PoP tokens)
- Inter Domain Communication
- Authentication and Authorization using Session Keys
- Introduces new entity (KDC)
- Flat Authorization (Authenticated equals Authorized)
SLIDE 7
7 Karthik Mathiazhagan
Design – Device Provisioning
Security System Services Lighting System Services
Design Requirements
- Asymmetric interdomain interaction
- Symmetric interdomain interaction
- Inter domain interaction using IoT protocols (CoAP, DTLS, CWT, CBOR, COSE).
Security System Lighting System Clien t Resource Server AS CA S Device Id Device Secret Device Id Device Secret Operational Certifjcate Operatio nal Certifjcat e Inter domain interaction Trust
SLIDE 8
8 Karthik Mathiazhagan
Design - Models
- 1. Asymmetric Model
- 2. Symmetric Model
Design - Steps
When device is provisioned with Operational CERT When device is provisioned with Device ID & Secret
CAS CAS AS AS
Client Resource Server
- 2. RS
Authorization
- 4. Resource Access
- 3. Client Authorization
1. Discovery
- f RS
Assumption : CAS – AS have prior trust relationship by exchange of root manufacture certificates (out of scope of this thesis). Step 1 – only once. Step 2 and 3 – Less frequent. Step 4 – More frequently executed
SLIDE 9
9 Karthik Mathiazhagan
Implementation
- Application layer Protocol
- CoAP
- Concise Binary Object
Representation (CBOR – payloads)
- Transport layer Security
- DTLS
- X509 Certificates
- Raw Public Keys
- Symmetric Keys
- Access control using CBOR Web
Tokens (CWT)
- CWT protection using COSE
Why ? Best fit for using IoT Standard Protocols
SLIDE 10
10 Karthik Mathiazhagan CAS C RS AS
[ CoAP Discovery ./well-known/CORE/] [ RS_ID, AS_ID,Scopes]
[ Message ] : CoAP Message. X_ID : Unique ID for X SX : Scope of X
- 1. Discovery of RS
- 1. Discovery of RS
Asymmetric Model
SLIDE 11
11 Karthik Mathiazhagan CAS C RS AS
[ QUERY_REQ (aud : RS, authz : AS, Scopes )] DTLS {OP_CERTC , CERTCAS} [ {ID_TokenC} SIGCAS , ROOT_CERTRS , SRS ] DTLS {OP_CERTC , CERTCAS} [ TOKEN_REQ (aud : RS),{ID_TokenC} SIGCAS , SRS ] DTLS {OP_CERTC , CERTAS} [ TOKEN_RESP {ACCESS_Token} SIGAS , SRS ] DTLS {OP_CERTC , CERTAS} [ Resource Access_REQ, {ACCESS_Token} SIGAS ] DTLS {OP_CERTC ,OP_CERTRS} [ Resource Access_RESP] DTLS {OP_CERTC
,OP_CERTRS}
Validate ACCESS_T
- ken
Authz Domain 1 Authz Domain 2
[UPDATE {ROOT_CERTC] DTLS {OP_CERTRS
,OP_CERTAS}
[ Message ] : CoAP Message. DTLS {CERTX} : DTLS, Authentication of X using Digital Certifjcates. DTLS {OP_CERTX
,OP_CERTY} : DTLS, Mutual
Authentication of X, Y using Operational Certifjcates. {Message} SIGX : Message signed with private key of X. SX : Scope of X ROOT_CERTX – Root Certifjcate of X ID_Token { Issuer Audience Subject Auth Type Issued At Valid Till } ACCESS_Toke n { Issuer Audience Subject Scope Issued At Valid Till SKey }
- 2. RS
Authorization
- 2. RS
Authorization
- 3. Client
Authorization
- 3. Client
Authorization
- 4. Resource Access
- 4. Resource Access
Asymmetric Model
More Frequent Less Frequent
SLIDE 12
CAS C RS AS
[ Resource Access_REQ ] DTLS {SkeyC-RS} [ Resource Access_RESP] DTLS {SkeyC-RS} Validate & Get SkeyC-RS From ACCESS_T
- ken
[ AUTHZINFO_REQ, {ACCESS_Token} IAS-
RS ]
[ AUTHZINFO_RESP ] [ QUERY_REQ (aud : RS, authz : AS, Scopes ),C_ID, C_Secret] DTLS {CERTCAS} [ {ID_Token} SIGCAS , ROOT_CERTRS , SRS ] DTLS {CERTCAS} [ TOKEN_REQ (aud : RS),{ID_Token} SIGCAS , SkeyC-RS , SC ] DTLS {CERTAS} [ TOKEN_RESP {ACCESS_Token} IAS-RS , SkeyC-RS ,SC ] DTLS {CERTAS} Get SkeyC-RS
Authz Domain 1 Authz Domain 2
[ Message ] : CoAP Message. DTLS {CERTX} : DTLS, Authentication of X using Digital Certifjcates. DTLS {OP_CERTX
,OP_CERTY} : DTLS, Mutual
Authentication of X, Y using Operational Certifjcates. {Message} SIGX : Message signed with private key of X. {Message} IX-Y : Encrypted & Integrity protected message using shared key between X-Y . SX : Scope of X ROOT_CERTX – Root Certifjcate of X ID_Token { Issuer Audience Subject Auth Type Issued At Valid Till } ACCESS_Toke n { Issuer Audience Subject Scope Issued At Valid Till SKey }
- 2. RS
Authorization
- 2. RS
Authorization
- 4. Resource Access
- 4. Resource Access
- 3. Client
Authorization
- 3. Client
Authorization
Symmetric Model
More Frequent Less Frequent
SLIDE 13
13 Karthik Mathiazhagan
Evaluation Packet Sizes
SLIDE 14
14 Karthik Mathiazhagan
Evaluation – Keys Storage
SLIDE 15
15 Karthik Mathiazhagan
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.
SLIDE 16
16 Karthik Mathiazhagan
Future Work
- 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.
Safety System Services Lighting System Services Smoke Detector Bridge Safety System Lighting System Clien t Resource Server (AS ) Authorizati
- n
Server (CAS ) Authorizat ion Server
Home Network
SLIDE 17
17 Karthik Mathiazhagan
Demo - Topology
SLIDE 18