Back in March 2015, the Federal Communications Commission (FCC) – a government agency tasked with regulating interstate communications in the United States – issued a security document that included a series of provisions related to the use of wireless devices that operate in the U-NII radio bands.
In essence, the FCC wanted the manufacturers of routers and other networking equipment to provide tightly defined access paths to all wireless transmission devices. Unfortunately, the FCC proposal is likely to result in OEMs locking down the whole firmware of their routers and thus preventing consumers from installing the open source operating system or software of their choice (e.g. OpenWrt or DD-WRT.)
Many developers in the open source community oppose this move, demanding that the FCC would not restrict the free use of the operating system and associated software running on their networking devices.
In order to offer a compromise, one solution would be to virtually separate the radio from the base software. This approach allows only authorized entities (e.g. the operators) to make the necessary changes and updates to the critical radio settings specified by the FCC.
Over the last year, the prpl Foundation has been working hard to provide this viable solution that allows networking devices to run open firmware while still complying with the FCC guidelines on Wi-Fi usage.
The demonstration below comes courtesy of the prpl Security Working Group – an initiative created by the prpl Foundation to address the next-generation security requirements of future connected devices (you can find out more about the group’s security recommendations from this whitepaper).
The result of their work is prplSecurity, an open framework that takes advantage of the hardware virtualization technologies embedded in MIPS Warrior CPUs to create multiple trusted environments where software can run in secure containers.
To illustrate how this works in practice, we’ve created a working WLAN router built using an evaluation board from Baikal Electronics designed specifically for networking and embedded applications.
The evaluation kit features the following specifications:
- Processor: a dual-core MIPS P5600 CPU clocked at 1 GHz
- Communications: a MIPS-based Realtek RTL8192 Wi-Fi adapter plugged in via the USB port and an Ethernet port for WAN access
- Additional I/Os: an UART serial connection to the Linux debugging console.
The router demo runs OpenWrt; the image below shows how we can reach the OpenWrt WebUI via the WAN connection or the WLAN side using an https connection.
The demo makes use of a unique feature of MIPS Warrior CPUs: multi-domain, secure hardware virtualization. This technology allows developers to create system-wide, hardware-enforced trusted environments that are much harder to break compared to current solutions. In a related demonstration from last year, we’ve shown how this feature can be used for microcontrollers targeting IoT and embedded applications to provide better security and stability.
Today we’re focusing on the MIPS Warrior P-class and application processors designed for networking chipsets. The platform above runs three virtual machines (VMs) on a high-end MIPS P-class CPU; the diagram below briefly describes the software architecture:
- The open source L4Re hypervisor developed and maintained by Kernkonzept: the L4Re system comprises an L4 microkernel that can run trusted native applications and act as a trusted hypervisor for operating systems.
- An open VM for OpenWrt: This virtual machine runs OpenWrt and provides the main interface to the router facilities
- An isolated VM for the Wi-Fi driver: The second virtual machine runs the Wi-Fi driver; there is no direct access to the driver from other VMs, except through the virtual network connection. In our particular example, this connection is established using three ports: 85 for http, 449 for https or 29 for ssh
- A dedicated VM for third party applications: This third virtual machine acts as a sandbox for running third party applications that provide additional functionality (e.g. smart home automation)
The demo system is accessible from a terminal (e.g. a desktop PC) via the UART connection. For this demonstration, we’ve created an unprotected access path (although this can be easily changed for production setups). A console multiplexer is running on the UART interface and allows to us to access the (virtual) serial interfaces for all of the three VMs.
In the video below, we’ve intentionally crashed the third party VM to show how the other VMs can continue to run (i.e. the WLAN and router still work).