Close

February 2015: Demystifying the small-cell security challenge

In recent years, mobile service providers have been deploying small-cells to address network capacity and coverage demands. These small-cells are being deployed in several theatres, including residential homes, enterprises and public areas where there is high traffic demand.

Small-cells commonly use insecure backhaul connections that pass over the public Internet. This contrasts macro-cells, which are generally deployed in secure locations with private backhaul connectivity. In recent years, the vulnerabilities of small-cells have been demonstrated by high-profile hackers, to the embarrassment of several well-known Tier 1 service providers and their technology vendors. Several notable security vulnerabilities include the following:

  • Snooping on unencrypted backhaul traffic.
  • Using exposed OA&M ports and SQL injection techniques to erase subscriber records and bring down the mobile services.
  • Capitalizing on open X2 interfaces and “flat” LTE architectures to deploy distributed denial of service (DDoS) attacks, and;
  • Compromising small-cell software to launch man-in-the-middle (MITM) attacks to enable a variety of vulnerabilities including, traffic re-routing, device cloning and malware distribution, to name a few.

The mobile industry has developed solutions to address small-cell security vulnerabilities, with the support of standardization bodies including the 3GPP, ETSI and the Broadband Forum. These solutions are focused primarily towards:

  • Strategies to protect subscribers and service providers’ core networks from attack vectors that emanate from small-cells.
  • Solutions to protect the hardware and software integrity of small-cells, and;
  • Ensuring the robustness of the security and small-cell management solutions that are used, such as TLS/SSL, TR069 and IPsec.

Exhibit 1 illustrates the primary components for a secure small-cell network implementation. In this implementation, User Equipment (UE) connect over 2G/3G, 4G or Wi-Fi wireless links to (e)Node-B small-cells. The small-cells commonly connect to core networks via untrusted environments, such as residential and commercial broadband networks. Since these untrusted environments are vulnerable to intrusion, small-cells connections and interfaces must be secured using security gateways. Furthermore, large scale small-cell deployments fundamentally change network architectures and create the potential for core network element failures as a consequence of excessive signaling traffic. This signaling traffic might be created maliciously, such as via a distributed denial of service (DDoS) attack, or without malicious intent in cases where small-cells generate excessive signaling traffic in their normal operations, such as for mobility management, location update requests and authentication.

To be effective, small-cell security gateways must fulfill several roles, which include the following:

  • Encryption and authentication techniques to protect the integrity and privacy of connections amongst small-cells (i.e. the X2 interfaces in LTE), between small-cells and service providers’ core networks, for operations and maintenance (OA&M) functions, and for other local IP interfaces from the small-cells. This is commonly achieved using IPsec. When IPsec is used, the content is encrypted. Security gateways that are deployed at the edge of mobile core networks terminate the IPsec tunnels and provide protection between the small-cells and a service provider’s core network. and;
  • Deep packet inspection techniques to protect signaling interfaces from overload and distributed storm (or denial of service) attacks. These DPI techniques protect vulnerable interfaces, such as those connecting to Mobility Management Entities (MME) and DIAMETER/RADIUS platforms for access, mobility and subscription management.

When service providers implement IPsec, they must pay careful attention to ensure that it meets their security objectives, without creating excessive network latency and poor network performance. Although IPsec has a variety of flavors, the most common configuration for small-cell backhaul connections is IPsec (ESP) in tunnel mode with IKEv2 D-H key exchange and 128 bit AES symmetric key encryption.

In some cases, small-cells support remote OA&M functionality for provisioning and configuration management. This might involve connecting to the small-cell directly or over a wireless connection, such as Bluetooth, or via a physical port on the small-cell. Remote access security on these OA&M connections is crucial in protecting small-cells and more importantly to mitigate core network vulnerabilities.

Exhibit 1 Secure small-cell architecture illustration

Source: Tolaga Research, 2015

In the past, small-cells and particularly femto-cells have suffered from a variety of security vulnerabilities that have emanated from the interrogation and tampering of the small cell software and hardware, with devastating effect. Several approaches have been used to overcome these challenges, with varying degrees of success. In particular some small-cell vendors have used:

  • Hardware tamper-detection technologies. However, many of the solutions that have been developed can be bypassed with relative ease once the configuration of the alarming system is understood by the hacker.
  • Solutions for secure small-cell provisioning and configuration management. The TR069 standard has been widely adopted for this purpose. This standard is touted as being secure, however recently hackers have demonstrated that while TR069 has the capabilities of being secure, it is not always the case. In particular, while TR069 supports TLS/SSL encryption, it is not mandated and when implemented it has the risk of being compromised due to poor certificate authority (CA) management. In addition, earlier versions of TR069, such as TR069-amendment 2 use SSL 3.0/TLS 1.0, which are no longer regarded as sufficiently secure. The TR069- Amendment 5, which was published in November 2013, recommends TLS1.2, or a later version.
  • Software code-signing to ensure the integrity of small-cell software loads. To achieve this, the small-cell software code is signed with a cryptographic hash, such as MD5 (which is not recommended), SHA-1 or SHA-2 and encrypted using public key cryptography, such as RSA. The TR069 standard has an optional feature for code signing software using SHA-1 (32 bit) with RSA based content encryption.
  • Protected boot software. A common trick that is used for malicious attacks is to access and manipulate the boot-software on small-cell devices. This can have the effect of bypassing other security mechanisms to create numerous potential attack vectors. To mitigate this threat, small-cells must operate their boot software from within trusted environments.
  • Small-cell physical location monitoring. Small-cells are vulnerable to being relocated without service provider permission. This is particularly the case for residential femto-cells, and can create a variety of challenges, such as negatively impacting frequency planning and emergency services such as E911, and compromising special service offers such as home-zone rates. This threat can be mitigated by a location locking mechanism, such as binding the small-cell’s geo-location with its crypto-graphically based identity.

Small-cell security is of paramount importance to mobile service providers, particularly as hackers target the network vulnerabilities that small-cells create. Even with the best available security technologies, small-cell security efforts are commonly foiled by non-compliance on the part of service providers. Several notable areas of non-compliance include the following:

  • Insecure backhaul and interface connections.
  • Weak passwords and poor certificate authorization regimes.
  • Insecure OA&M interfaces, and;
  • Obsolete TR069 implementations, which in many cases lack the security features that are optional in the TR069 standards.

Continuous vigilance is needed on the part of service providers to ensure that their small-cell implementations are compliant with the intended security standards and the underlying security algorithms and techniques have not been compromised.

;