SpiderCloud E-RAN Security Overview Excerpt for SpiderCloud Wireless, Inc. 408 East Plumeria Drive San Jose, CA 95134 USA -hereafter called SpiderCloud- Page 1 of 7
Table of Contents 1 Executive Summary...5 2 Testing History...6 3 Architectural Overview...7 4 Security Overview...8 4.1 Handset...8 4.2 Radio Node...8 4.3 Service Node...8 Page 2 of 7
Terms and Definitions Term IP IPSec UMTS VLAN VPN Internet Protocol Definition Internet Protocol Security Universal Mobile Telecommunications System Virtual LAN (as defined in IEEE 802.1Q) Virtual Private Network Page 3 of 7
1 Executive Summary conducted testing and reviews of the security of the E-RAN system and components between 2011 and 2012. The review considered potential hardware, software and network threats to the physical components, handset traffic and network traffic between the Enterprise and Telecommunication network. Testing focused on the UMTS and cellular versions of the SpiderCloud E-RAN system. The design of the hardware and software for Radio Nodes and Service Nodes protect against hardware-based attacks and analysis. Traffic between Radio Nodes and Service Nodes, and Services Nodes to the telecommunication network, are protected by the use of IPSec tunnels. These components have strict IP filtering rules that restrict configuration of components to protocols behind IPSec tunnels. These measures help protect components from network-based attacks. The handset is itself protected from radio-based interception by UMTS encryption utilized between handset and Radio Node. Handset traffic, as with all other E-RAN traffic, only transverses the network through the IPSec tunnels, thereby protecting the handset from network-based interception. Traffic from handsets use UMTS encapsulation protocols that are only decapsulated to voice and data/ip traffic on the Telco network. This should provide protection to the Enterprise network from the handset itself as the Enterprise IP network is never exposed directly to the handset. The verification of the traffic encapsulation and decapsulation was only performed as a document review and was not part of the testing in security assessments. Management of the system is conducted from the Telco network. To protect the Enterprise from unnecessary access by the Telco, the Service Node provides a restricted configuration interface, that exposes only essential instructions. Further protection against a software-based attack against the Service Node from the Telco is provided through the use of common security coding practices by SpiderCloud. Finally, the entire E-RAN system can be placed on a separate network segment for additional abstraction and separation. Page 4 of 7
2 Testing History All testing was conducted on the E-RAN system, that provides UMTS services. The E-RAN architecture, that combines UMTS and Wi-Fi availability, was out of scope at the time period of testing. 2011 Network, hardware, software and design review and testing of SCSN/SCRN for revisions: 1.5.0.013 1.5.0.314 1.5.1.2 1.6.0.75 1.7.0.2 The end-to-end testing was conducted within an emulated telecommunication network. 2012 Network, hardware, software and design review and testing of SCSN/SCRN for revisions: 1.7.0.3 2.0.0 2.0.1 2.0.5.0 2.0.5.0.DevBld-201208271750 2.1.0.84 This test cycle included testing of SpiderCloud E-RAN system on a real end-to-end telecommunication network. Page 5 of 7
3 Architectural Overview The SpiderCloud E-RAN system extends cellular coverage throughout Enterprise buildings and infrastructure. Radio Nodes the size of common wireless routers provide cellular connectivity to handsets. These nodes connect to a central server, the Service Node, that manages authentication, filtering and the connection to the telecommunication provider's core network. Figure 1: Encapsulation and tunneling Radio Nodes provide UMTS radio services to handsets. Handset voice and data traffic is encrypted with UMTS standard encryption layers, such as KASUMI, and is decrypted by the Radio Node. The Radio Node passes the data over an IPSec tunnel to the Service Node. The Service Node connects to the Telecommunication Network's Internet facing Security Gateway and builds a VPN tunnel using IPSec to that network. Over this channel, the Service Node builds the necessary connections to data and voice end-points in the Telco's core network. These channels (Iu-CS, Iu- PS, Iu-H) are used to pass voice and data from the handsets. Page 6 of 7
4 Security Overview 4.1 Handset Voice and data traffic from handsets are protected from unlawful interception using standard UMTS encryption between the handset and Radio Node. Traffic is transported with UMTS encapsulation protocols. The E-RAN system passes the encapsulated traffic to the Telco network. From the point of view of a handset, IP network data is only decapsulated within the Telco's network. This helps to protect the Enterprise network from a handset. Not shown in Figure 1 is an additional network that sits between the Telco's core network and the Enterprise E-RAN Service Node called the HNB-GW. Tests did not find any means to transverse from the Telco's network, through the HNB-GW and then back into the Enterprise from a handset. This of course heavily depends on the integration design and configuration plans of the core network at the customer side. 4.2 Radio Node All communication to and from Radio Nodes is conducted over the IPSec tunnel between the Radio Node and Service Node. This tunnel supports asymmetric keys and common practice certificate authority schemes. The Radio Node does not expose any network services outside of this tunnel and the firmware is further hardened by only containing the most essential software components. The Radio Node is further protected by strong hardware security measures including signed firmware and removal of any unnecessary debug interfaces on the device. Measures were also taken to prevent analysis of the firmware. 4.3 Service Node The Service Node is protected by strong hardware security measures including signed firmware and removal of unnecessary debug interfaces on the device. The majority of configuration happens over the IPSec tunnel to the Telco network. SpiderCloud has utilized common security coding practicing for essential configuration and management services to protect firmware and software from attacks and analysis. After the initial installation, configuration of the Service Node (and therefore its Radio Nodes) is restricted to a configuration interface exposed to the Telco over the IPsec tunnel. The entire system can be sequestered to a separate network or VLANs within the Enterprise, but in case that no segmentation is deployed by the customer, the Service Nodes configuration interface has been restricted to only provide basic functionality required for configuration. Only instructions and configuration details essential for configuration and testing are exposed to the Telco. This prevents the Telco from using the Service Node to access or explore the Enterprise network. The configuration interface has also been tested for common security coding and hardening practices. Other measures were taken to add additional layers of protection to prevent modification of the configuration interface or execution of any software not signed by SpiderCloud. Page 7 of 7