Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Capability Based Network Access Control for Smart Home Devices

Capability Based Network Access Control for Smart Home Devices

PerFlow'22 Session 2 (March 21, 2022)

松本直樹

March 21, 2022
Tweet

More Decks by 松本直樹

Other Decks in Research

Transcript

  1. Capability Based Network Access Control
    for Smart Home Devices
    PerFlow’22 Session 2 (March 21, 2022)
    Naoki MATSUMOTO, Daisuke KOTANI, Yasuo OKABE
    (Kyoto University)
    1

    View Slide

  2. Background
    Many smart devices are connected to a home network
    • These devices are managed and operated remotely
    Some malicious devices can also be connected to the network
    • Devices can be attacked easily because of the network topology
    Home Network
    Malicious
    Operation
    Malicious
    Devices
    Smart Devices
    Unintended
    Communication 2

    View Slide

  3. Problems of Previous Research
    Access Control Architectures
    • Considering better architectures for ordinary users
    • Does not refer to the methods to apply them in a real network
    Network Access Control Methods
    • Proposing Software Defined Network(SDN) based access control
    • Does not consider user friendly management systems
    The gap between Access Control Architecture and Network Access Control exists
    3

    View Slide

  4. Proposed Methods
    Filling the gap shown in previous slide.
    Proposal1: Capability based Authorization Architecture
    • Designed architecture relying on guidelines for access control in a home
    • Designed Automatic Authorization and Manual Authorization
    Proposal2: Network Access Control Method
    • Providing more fine-grained network access control
    (flow-based, payload-based and proxy-based control)
    • Designed twin device to apply our methods to existing devices
    4

    View Slide

  5. Proposed Methods
    5

    View Slide

  6. Proposed Methods
    Our methods enable users to control communications with one click
    6
    Home Network
    Malicious
    Operation
    Malicious
    Devices
    Smart Devices
    Unintended
    Communication

    View Slide

  7. Our Contributions
    Our contributions are
    • Proposing integrated access control method for home network
    • Implementing prototype system based on proposed methods
    • Showing that
    proposed methods can control a real protocol for smart devices
    7

    View Slide

  8. Related Works
    Network access control in a home network methods are two types
    • Outsourcing the management of networks
    • Configuring and managing networks by users
    Each method usually uses OpenFlow to control network
    • The granularity of control is restricted to “flow”
    8

    View Slide

  9. Related Works (outsourcing)
    Outsourcing methods do not bother users
    • Feamster[1] proposed spam detection by outsourcing the
    management of home network.
    • Osman[2] proposed automatic network segmentation
    by analyzing home network and controlling with cloud-based system
    Outsourcing methods have Privacy and Availability problems
    • Service providers know what communications are done in a home
    • Service down means that home network is also unavailable
    9
    [1] N. Feamster, “Outsourcing home network security,” in Proceedings of the 2010 ACM SIGCOMM Workshop on Home Networks, ACM, 2010, p. 37–42.
    [2] A. Osman, A. Wasicek, S. Kopsell, and T. Strufe, “Transparent microsegmentation in smart home iot networks,” in HotEdge ’20. USENIX, Jun. 2020, pp. 1–6.

    View Slide

  10. Related Works (by users)
    Management by users solves previous problems
    • Mortier[3] proposed OpenFlow based device management system.
    • Bakhshi[4] proposed management using profiles.
    • Lear[5] proposed Manufacturer Description Usage(MUD).
    A problem that not considering usability
    • Access control research results considering usability are not utilized
    10
    [3] R. Mortier, T. Rodden, T. Lodge, D. McAuley, C. Rotsos, A. Moore, A. Koliousis, and J. Sventek,
    “Control and understanding: Owning your home network,” in COMSNETS 2012, pp. 1–10.
    [4] T. Bakhshi and B. Ghita, “User-centric traffic optimization in residential software defined networks,” in ICT 2016, pp. 1–6.
    [5] Lear, R. Droms, and D. Romascanu, “Manufacturer Usage Description Specification,” RFC 8520, Mar. 2019.

    View Slide

  11. Proposal1: Capability based Authorization Architecture
    Authorization architecture based on Capability Model
    • Relying on guidelines for access control in home
    • Authorization per communication
    Every communication has a corresponding Capability
    11
    Capability
    Provider
    Smart Device A Smart Device B
    Allowed to communicate
    with device A!
    Cap(GetTEMP)
    Requesting Cap(GetTEMP)
    Capability: Get Temperature
    Protocol: UDP
    Port: 8000
    Cap(GetTEMP)
    Issuing Capability

    View Slide

  12. Capability Model
    Capability Model is one of the access control models
    • Capability is bound to each operation
    • Simply issuing a capability if a user authorizes operation
    • An entity allows the operation if the corresponding capability is presented
    12
    Entity 2
    Operation A
    Operation B
    Cap(Operation A) Allow Operation A because of
    having Cap(Operation A)
    Deny Operation B because of
    not having Cap(Operation B)
    Entity 1
    Issue
    Cap(Operation A)
    Allow Operation A

    View Slide

  13. Requirements for Access Control in Home
    Guidelines [8] for access control systems aimed at home users
    1. Allow fine-grained control
    2. Plan for lending devices
    3. Include reactive policy creation
    4. Include logs
    5. Reduce or eliminate up-front complexity
    6. Support iterative policy specification
    13
    [8] M. L. Mazurek, J. P. Arsenault, J. Bresee, N. Gupta, I. Ion, C. Johns, D. Lee, Y. Liang, J. Olsen, B. Salmon, R. Shay, K. Vaniea, L. Bauer, L. F.
    Cranor, G. R. Ganger, and M. K. Reiter, Access Control for Home Data Sharing: Attitudes, Needs and Practices. ACM, 2010, p. 645–654.

    View Slide

  14. Authorization Architecture
    Users authorize capabilities for communication
    Mechanism to reduce the burden operations for authorization
    • Automatic Authorization
    • Manual Authorization
    14
    Capability
    Provider
    Smart Device B
    Cap(GetTEMP)
    Requesting Cap(GetTEMP)
    Capability: Get Temperature
    Protocol: UDP
    Port: 8000
    Cap(GetTEMP)
    Smart Device A
    Managing all capabilities
    Issuing Capability
    Delegating Cap(GetTEMP)

    View Slide

  15. Automatic Authorization
    Automatic Authorization with authorization policy
    • The authorization policy is embedded in capability
    Authorization policy is designed for cooperation in the same vendor
    • Device ID or Vendor ID are used in condition by default
    • Expanding policy is a future task
    15
    Capability
    Provider
    Vendor α’s
    Smart Device B
    Allowed to communicate
    with device A!
    Cap(GetTEMP)
    2.Requesting Cap(GetTEMP)
    Capability: Get Temperature
    Protocol: UDP
    Port: 8000
    Condition: Vendor
    Allowed Vendor: Vender α
    Cap(GetTEMP)
    Smart Device A
    4. Issuing Capability
    1.Delegating Cap(GetTEMP)
    3. Checking and
    authorizing automatically

    View Slide

  16. Manual Authorization
    Manual Authorization is used to authorize capabilities by a user
    Capabilities are delegated to a user and
    a user authorize it.
    16
    Vendor β’s
    Smart Device B
    Authorize!
    Cap(GetTEMP)
    2.Requesting Cap(GetTEMP)
    Capability: Get Temperature
    Protocol: UDP
    Port: 8000
    Condition: Vendor
    Allowed Vendor: Vender α
    Cap(GetTEMP)
    Smart Device A
    Cap(GetTEMP)
    Capability
    Provider
    4.Issuing Capability
    1.Delegating Cap(GetTEMP)
    3.Delegating
    Cap(GetTEMP)

    View Slide

  17. Comparison with Policy based Control
    Capability based access control is more suitable
    than policy based one in a home network
    17
    Requirements Policy based Capability based
    (1) Fine-grained control ✕(difficult for small
    number and many kinds)
    ✔(Control per cap)
    (2) Lending device ✕ ✕
    (3) Reactive policy creation (Out of consideration) ✔
    (4) Logs ✔ ✔
    (5) Reduce complexity ✕(Describing policy) ✔(only issuing)
    (6) Iterative policy specification ✕(Policy Management) ✔(Management per cap)

    View Slide

  18. Proposal2: Network Access Control Method
    All communications are controlled by Policy Enforcement Point(PEP)
    • PEP checks the capability corresponding to communication is presented
    • Flow-based, Payload-based and Proxy-based control with OpenFlow and
    Twin devices
    18
    OpenFlow
    Twin Devices
    Cap(GetTEMP)
    Smart Device A Smart Device B
    Allow Communication
    between Smart Device A and B
    Communication to
    get temperature
    The other
    communications
    Policy Enforcement Point (PEP)

    View Slide

  19. Inside of PEP Network
    PEP works with OpenFlow switch or wireless AP
    19

    View Slide

  20. Twin Device
    Twin device fills in the missing functions in physical devices
    • Handling capabilities and
    providing payload-based and proxy-based access control
    • Network is separated from host using network namespace
    20
    OVS for access control
    Twin device (separated with network namespace)
    Payload-based
    and
    Proxy-based
    control
    Capability
    related
    processing
    To Capability Provider
    Packets are forwarded and checked

    View Slide

  21. Flow-based Access Control
    Flow-based access control is mainly used for
    • Rough network separation
    • High throughput or low latency communication
    Flow-based access control works with OpenFlow
    21
    Physical Device
    A
    Physical Device
    B
    OpenFlow
    Switch or Wireless AP
    Controller
    Matching:
    - eth_src: 00:11:22:33:44:55
    - eth_dst: FF:FF:FF:FF:FF:FF
    - ip_src: 192.168.1.2
    - ip_dst: 192.168.1.255
    - udp_dst: 8000
    Action: OUTPUT(port:2)
    MAC Addr: 00:11:22:33:44:55
    IPv4 Addr: 192.168.1.2/24
    MAC Addr: 00:11:33:44:55:66
    IPv4 Addr: 192.168.1.3/24

    View Slide

  22. Payload-based Access Control
    Payload-based access control is mainly used for UDP packets
    • Some protocols use a UDP packet to search network and discover devices
    Payload-based access control uses
    • OpenFlow to forward packets to twin device
    • A twin device to inspect packet payload
    22
    Physical Device
    A
    Physical Device
    B
    OpenFlow
    Switch or Wireless AP
    PEP
    Twin Device B
    Twin Device A
    OVS
    Forwarding packets
    Inspect and forward or drop packets
    Condition:
    - payload[0] == 0x14 && payload[1] == 0xA4

    View Slide

  23. Proxy-based Access Control
    Proxy-based access control is mainly used for stream messages
    • HTTP cannot be controlled with previous 2 methods.
    • Other protocols using TCP streams are also target.
    Proxy-based access control is based on a Transparent Proxy
    • Achieved by rewriting packets’ IP address with OVS
    23
    Physical Device
    A
    Physical Device
    B
    OpenFlow
    Switch or Wireless AP
    PEP
    Twin Device B
    TCP Proxy forwards or discards messages
    Condition:
    - Message Format: HTTP
    - Method: GET
    - Request URI : device/status
    TCP Proxy
    simply calling
    recv(2) and send(2)
    OVS
    Rewriting packets' header

    View Slide

  24. Implementation and Experiments
    Implemented a prototype system and experimented
    • Performance evaluation
    • Controlling real protocol (DIAL protocol)
    An experiment environment
    • PEP host: ThinkPad X260 (Intel Core i5-6200U)
    • Physical smart device: Raspberry Pi 4 x 2
    • OpenFlow Wireless AP: Allied Telesis AT-TQ4600, Aruba AP11(OpenWrt)
    24

    View Slide

  25. Experiment Environment
    Two Raspberry Pi s are connected to wireless AP
    • The firmware of Aruba AP11 is rewritten to OpenWrt to support OpenFlow
    In performance evaluation, we measured
    • Throughput with iperf3
    • RTT(round trip time) with ping
    25
    PEP
    CP
    Smart Device A
    (Raspberry Pi)
    Smart Device B
    (Raspberry Pi) OpenFlow
    Wireless AP
    Linux Host
    (ThinkPad X260)

    View Slide

  26. Performance Evaluation
    26
    Results show that
    Flow-based: for large data transfer or latency-aware applications
    Payload-based: for controlling UDP packets like neighbor discovery
    Proxy-based: for controlling stream messages like HTTP

    View Slide

  27. Controlling DIAL Protocol
    DIAL(DIscovery And Launch) protocol is used to
    launch applications like Netflix in a smart TV from a smartphone in our hand
    DIAL protocol consists of two protocols
    • SSDP(Simple Service Discovery Protocol): for discovering devices
    • DIAL REST Service: for controlling devices via HTTP REST API
    27

    View Slide

  28. Controlling DIAL Protocol
    Controlling DIAL protocol
    • Assigned a capability to each operation like Cap(NetflixStart)
    • Separating network roughly with flow-based access control
    • Controlling SSDP with payload-based access control
    • SSDP sends and receives UDP packet for device discovery
    • Controlling DIAL REST Service with proxy-based access control
    • REST API is served over HTTP
    We confirmed our proposed methods can control DIAL protocol
    • Methods using only flow-based control cannot provide such fine-grained access control
    • Payload-based and proxy-based methods enable access control.
    28

    View Slide

  29. Demonstration
    Simple Web UI in the prototype system
    30
    Devices requesting capability
    Devices requested capability
    Requesting Capability
    Buttons to grant capability

    View Slide

  30. Demonstration
    Users can control communications with one click
    → Easier than configuring policy!
    31
    Capability
    Provider
    Device B
    Device A
    PEP
    Twin Device B
    Twin Device A
    Twin Device B
    Twin Device A
    Capabilities
    Configuring OpenFlow switch
    OpenFlow switch
    Configuring
    twin devices

    View Slide

  31. Demonstration
    32

    View Slide

  32. Conclusion
    Proposal1: Capability based Authorization Architecture
    • Designed architecture relying on guidelines for access control in home
    • Designed Automatic Authorization and Manual Authorization
    Proposal2: Network Access Control Method
    • Achieved more fine-grained control
    with flow-based, payload-based and proxy-based control
    • Designed twin device to apply our proposals to existing devices
    Experiments: Performance Evaluation and PoC in a DIAL protocol
    33

    View Slide