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

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

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

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

Proposed Methods 5

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

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

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

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.

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.

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

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

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.

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)

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

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)

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)

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)

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

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

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

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

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

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

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)

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

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

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

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

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

Demonstration 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