IoT/M2M Security

Research presentation for IoT/M2M security

- Paper: Distributed Capability-based Access Control for the Internet of Things
- Security solution in open source IoT platform (OM2M, AllJoyn)

Transcript

1. IoT/M2M Security Yu-Hsin Hung, Chun-Kuei Huang 1
2. Outline • Background • Paper: Distributed Capability-based Access Control for the Internet of Things • Security solution in open source IoT platform • OM2M • AllJoyn • Discussion 2
3. Background • More connected devices mean more attack vectors and more possibilities for hackers to target us • e.g. Internet-connected cars • Huge data with privacy information recorded by IoT devices • e.g. health data from health tracker 3
4. Distributed Capability-based Access Control for the Internet of Things Jose ́ L. Herna ́ndez-Ramos, Antonio J. Jara, Leandro Mar ́ın, and Antonio F. Skarmeta Department of Information and Communications Engineering
 Computer Science Faculty University of Murcia, 30100 Murcia, Spain 4
5. Introduction • Previous works • centralized approaches • Access control mechanism • Role-Based Access Control (RBAC) • Attribute-Based Access Control (ABAC) 5
6. Introduction • This work • capability-based access control • principle of least privilege • greater adaptation • distributed approach • public-key cryptography (optimized ECDSA) 6
7. Access Control architectures for IoT • Centralized approach • central PDP (Policy Decision Point) is responsible for filtering access requests based on their authorization policies • end-devices play a role limited to as information providers 7
9. Centralized approach • Pros • access control logic is located in an entity without constraints of resources • SAML, HTTPS for secure transportation; XACML for complex access control policies • modifications in the end-devices are not required • Cons • access control decisions are not based on contextual information related to the end-device itself • end-to-end security is compromised • single point of failure 9
10. Access Control architectures for IoT • Centralized and Contextual approach • hybrid approach • end devices participate partially in the access control decisions • e-health case: medical emergency 10
12. Centralized and Contextual approach • Pros • use standard technologies to perform the authorization process • Cons • trust relationship is assumed between the devices and the central entity • delay of contextual information • end-to-end security can not be achieved 12
13. Access Control architectures for IoT • Distributed approach • all the access control logic is embedded into the end devices 13
14. Distributed approach • Pros • end-devices are no longer passive entities • devices are able to send information just when necessary • end-to-end security • scalability, interoperability and context-awareness • Cons • RBAC and ABAC may need high computational cost • symmetric-key cryptography does not satisfy the principle of scalability for IoT scenarios 14
15. Design • Capability-based access control (CapBAC) • capability: ”token, ticket, or key that gives the possessor permission to access an entity or object in a computer system” • tamper-proof and unequivocally identified • send a token together the request • the entity that receives the capability already knows the right level (i.e., permissions) 15
16. Capability token • Identifier (ID) • Issued-time (II) • Issuer (IS) • Subject (SU) • Device (DE) • Signature (SI) • Access Rights (AR) • Not Before (NB) • Not After (NA) 16
17. Capability token • Identifier (ID) • Issued-time (II) • Issuer (IS) • Subject (SU) • Device (DE) • Signature (SI) • Access Rights (AR) • Not Before (NB) • Not After (NA) • Access Rights (AR) • Action (AC) • Resource (RE) • Condition flag (F) • 0 for AND, 1 for OR • Conditions (CO) • Condition Type (T) • Condition Value (V) • Condition Unit (U) 16
19. Distributed CapBAC operation • Four steps • Issue Capability Token • Access Request • Get Authorization Decision • Return Authorization Decision 18
20. Step 1. Issue Capability Token • Issuer issues a token to Subject • sign the token using ECDSA algorithm 19
21. Step 2. Access Request • Subject generates a CoAP request • sign the request using ECDSA algorithm • 6LBR only has basic routing functionalities 20
22. Step 3. Get Authorization Decision • Check that the token is valid: II, NB, NB • Check that the action is granted: AC, RE • Check that the conditions are fulfilled: F, CO • Check that the signature is valid: SI • Check that the user is legitimate: SU 21
23. Step 3. Get Authorization Decision • Check that the token is valid: II, NB, NB • Check that the action is granted: AC, RE • Check that the conditions are fulfilled: F, CO • Check that the signature is valid: SI • Check that the user is legitimate: SU 22
24. Step 3. Get Authorization Decision • Check that the token is valid: II, NB, NB • Check that the action is granted: AC, RE • Check that the conditions are fulfilled: F, CO • Check that the signature is valid: SI • Check that the user is legitimate: SU 23
25. Step 3. Get Authorization Decision • Check that the token is valid: II, NB, NB • Check that the action is granted: AC, RE • Check that the conditions are fulfilled: F, CO • Check that the signature is valid: SI • Check that the user is legitimate: SU Using Issuer’s public key 24
26. Step 3. Get Authorization Decision • Check that the token is valid: II, NB, NB • Check that the action is granted: AC, RE • Check that the conditions are fulfilled: F, CO • Check that the signature is valid: SI • Check that the user is legitimate: SU Using Subject’s public key 25
27. Step 4. Return Authorization Decision • generate CoAP response • Unauthorized 4.01 response 26
28. Evaluation • Test bed • JN5139 MCU with Contiki OS • low power, low cost, suitable for IEEE802.15.4 • 96KB RAM, 192KB ROM • Subject written in Java on a common computer • 6LBR for forwarding the access requests 27
29. Evaluation • Experimental results Stage Time (ms) A, B, C 52.39 D 213.93 E 214.64 Total 480.96 capability token validation CoAP request validation parsing JSON, obtain decision 28
30. Conclusion • CapBAC with distributed approach • scalability • end-to-end security • optimized ECDSA implementation for constrained devices based on shifting primes • requires the definition of a model for dynamic and context-based management of the conditions in order to reach a real market 29
31. Security solution in open source IoT platform 30
32. OM2M • Centralized approach • Devices report data to GSCL, act as passive units • DSCL is not released yet • Basic access control implemented on GSCL/NSCL • End-to-end security is not achieved 31
33. AllJoyn • Qualcomm lead the development, with 200+ partners • The AllJoyn framework runs on the local network • AllJoyn Apps and AllJoyn Routers • Apps can only communicate with other Apps by going through a Router 32
34. Network Architecture 33
35. Software Architecture 34
36. Security 35
37. Security 2.0 36
39. Summary • ACL model • distributed, end-to-end security • policies stored on device end, decisions are made locally 38
40. Discussion • [paper] access rights on token • flexible but difficult to manage • private key leakage • [AllJoyn] access rights on device • limitation on constrained device • easy to manage • [OM2M] access rights on GSCL/NSCL • centralized approach 39
41. Reference • Why IoT Security Is So Critical, TechCrunch • Distributed Capability-based Access Control for the Internet of Things [2013] • A decentralized approach for Security and Privacy challenges in the Internet of Things [2014] • OM2M, http://www.eclipse.org/om2m/ • AllJoyn, https://allseenalliance.org/
42. Thank you 41