IoT/M2M Security
1 like932 views
The document discusses distributed capability-based access control (CapBAC) as a security solution for the Internet of Things (IoT), highlighting its benefits in terms of scalability and end-to-end security compared to centralized approaches. It describes the processes involved in CapBAC, including the issuance and validation of capability tokens, and evaluates its implementation using experimental results from a testbed. Additionally, it contrasts CapBAC with centralized solutions like OM2M and AllJoyn, emphasizing the importance of local decision-making for enhanced security.
![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](https://image.slidesharecdn.com/iotsecurity-170531074858/85/IoT-M2M-Security-40-320.jpg)
![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/](https://image.slidesharecdn.com/iotsecurity-170531074858/85/IoT-M2M-Security-41-320.jpg)
IoT/M2M Security
- 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 José L. Hernández-Ramos, Antonio J. Jara, Leandro Maŕı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
- 8. 8
- 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
- 11. 11
- 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
- 18. 17
- 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
- 36. Security 35
- 37. Security 2.0 36
- 38. 37
- 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