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 full-size 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 full-size 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 full-size 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 full-size slide

  5. Proposed Methods
    5

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size slide

  31. Demonstration
    32

    View full-size 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 full-size slide