> Sapphire Project: Bringing security boundary to consumer edge

Sapphire Project: Bringing security boundary to consumer edge


August 30th, 2019

#secure gateway #5g


IoT devices such as smart TVs, IP cameras, WiFi thermostats, and Smart Light Bulbs are becoming cheap and popular. Many residential customers are buying these devices, creating a “smart home” environment. However, many of these devices are not secure: they may have limited security controls, unpatched vulnerabilities, or default passwords. Thus, customers are unwittingly opening up their home Intranet to attacks. Some of these devices are compromised and are recruited by botnets (e.g. Mirai botnet), while others are sitting in the open Internet waiting to be exploited.

Internet service providers have limited visibility into home networks, which makes it challenging for them to assist customers whose home network components have been attacked. With the Sapphire project, we aim to design and develop a system that provides security capabilities inside the home network by using a security gateway device that dynamically deploys containers and/or virtual machines to extend gateway functionality as needed. This proposed approach allows the service provider to develop advanced security analytics and deploy them in containers on the customer residential gateway from a central location.

Proposed Idea

An ISP typically has little visibility into a home network due to technologies such as Network Address Translation (NAT), which makes customer traffic look as if it is all coming from a single device. We propose integrating with an existing gateway to extend the customer’s security boundary. In this way, we are able to segregate end-point devices into intranet zones based on risk-levels. We can capture the relevant data from each home device and enable advanced data analytics that use more efficient and effective algorithms. By protecting the customer LAN, we also protect the carrier network from attacks originating from residential networks that generate unwanted traffic (DDoS, Scanning, Brute-forcing, etc.), or that could compromise other customers. At the same time, we can provide a higher level of security and convenience to customers, who will not have to call the provider in case the service is degraded or inaccessible.

Figure 1. Typical IoT home network setup.

Figure 1 shows a typical home network setup with several smart devices connected to the Sapphire secure gateway. The security gateway could be connected to the customer modem and serve as an access point (AP) for LAN or WiFi, or could be connected to another AP and provide connectivity only to devices that it will protect. Notably, the traffic from home devices to the Internet passes through the gateway, which enables the ability to apply security controls and analysis there, in the format of security containers or functions.

There is a second aspect of security that must be handled carefully: the Sapphire gateway is itself an IoT device. Our implementation must therefore avoid the common IoT security problems existing today: default passwords for devices, exploitability of unnecessary open ports/services, inability to update residential gateway devices, no inventory of devices, and/or dependency on vendors to address security vulnerabilities and updates.

Figure 2. Core Sapphire Architecture

To handle security for the gateway itself, we use the architecture depicted in Figure 2. On the left in blue is the Sapphire cloud back end, and on the right in orange is the Sapphire gateway in the home. The main function of the gateway is just routing: it provides wired and WiFi LAN for the customer. We establish a VPN between the gateway and back end to segregate administrative traffic from home traffic (avoiding open ports, etc.). One of the most important services we provide is software updating of the gateway itself; for this we rely on Ostree, an open-source atomic update system that can be remotely invoked and which permits rollback in case of failure. Access to the gateway is mediated by a certificate-based authentication system (not passwords). We can deploy security services to the gateway on demand via a job management system based on Docker containers; VMs are also supported.

Figure 3. Current deployment architecture of a small-scaled prototype.

Figure 3 shows, at high level, the components of a prototype of the proposed system. The left side of the figure represents the central back end of the system with three servers. The central back end connects to each secure gateway via a secure VPN connection in order to allow for management, deployment and configuration of security functions. The right side shows possible connections from the secure gateway to the residential network via LAN or WiFi. Inside the secure gateway device, the security functions are executed via Docker containers. At the start of each execution, the containers are downloaded from a central managed repository that keeps track of the latest version of each security function. In this manner, on each secure gateway, the system performs an automatic update for all devices with each new version of the security function deployed.

Figure 4. Current deployment architecture of a small-scaled prototype.

Figure 4 shows several example containers with their associated security functions that are deployed on the Secure Gateway in the prototype. One container for traffic capture function, one for data storage and anomaly detection, one for device scanning and discovery, and another container running a local user dashboard showing the current state of security for the devices connected to the gateway. As the system evolves, we expect to deploy many other security functions, some of which address fundamental security concerns, while others address immediate security issues aimed to block an attack at the source.


There are several key benefits to this method:

  • The system will protect the carrier network as well as the customer LAN by extending the network protection boundary to the consumer edge
  • Allows the carrier to apply the security policy at the individual device level
  • Allows identification, visibility, characterization and reclassification of devices
  • Protects devices connected to the secure gateway as well as the gateway itself
  • Containers/VMs can be managed remotely and collectively (e.g. deployment from a central location and updates could be applied in the same time to all RGs)
  • Containers/VMs can isolate admin and consumer functions
  • Containers/VMs enable rapid development and deployment of security functions