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.

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

34. Network Architecture
33

35. Software Architecture
34

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