Securing The Backhaul

The FAP and the network must be able to mutually authenticate each other for the FAP to become part of the carrier’s network. For this process to occur, the FAP, the FGW, and the security gateway that sits between the public Internet and the mobile operator’s core network must be able to establish a secure means of bi-directional communication—a secure tunnel.

Both sides must be able to verify the peer. The system also needs to be flexible to leverage the existing authentication back ends and infrastructure employed by carriers, including remote authentication dial-in user service (RADIUS) servers, home location registers (HLRs), and the various forms of subscriber identity module (SIM) cards employed today.

Standardized by the Internet Engineering Task Force (IETF), IKEv2 has been prescribed for the FAP and FGW authentication requirements of addresses. It is a flexible protocol that supports many actual authentication methods. The authentication within IKEv2 can be performed with Public Key Infrastructure (PKI) certificates, shared keys, or even SIM cards.

IKEv2 also supports the Extentensible Authentication Protocol (EAP), which is a key feature in applying the IKEv2 protocol in many existing authentication schemes or systems. After successful negotiation, identification, and authentication of all parties, IKEv2 generates the keys and establishes the connection for further secure communication.

While IKEv2 is used to authenticate the access points and gateways for each other, the actual secure communication channel is realized with IPsec. This is another IETF standardized protocol for securing Internet communications. The support for the IPsec protocol is a requirement for protecting the IP backhaul of the femtocell system.

IPsec protects the IP traffic as it travels over the broadband connection back to the carrier’s core network. It is a flexible and efficient method of providing data integrity and confidentiality. While IPsec is a complex suite of many protocols, backhaul security within femtocell networks focuses specifically on one variant, the Encapsulating Tunnel Payload (ESP) tunnel variant (Fig. 2).

The strong cryptography involved in this security protocol makes it somewhat computationally intensive. In most application scenarios, the platform CPE bears the computational cost, which may not be practical in the case of the FAPs. Since the entire femtocell business model relies on the affordability of the access points, it implies that high-performance (and therefore expensive) CPE is not a viable option.

For packet encryption and decryption to be efficiently managed, FAPs and FGWs must rely on cryptographic hardware for offloading the workload. The market of cryptographic hardware accelerators provides several options available to device, equipment, and system-on-a-chip (SoC) vendors. Two of the most viable options for femtocell networking are standalone cryptographic cores and packet engines.

Standalone crypto cores deal with crypto offload only, leaving all other protocol operations to be done on the host CPE. Aside from cryptography, which is expensive, there are many other operations that need to be done for each packet.

Packet engine-type accelerators deal with entire packets to offload even more of the security overhead to the accelerator hardware. Packet engines are more complex designs but offer superior offloading capabilities and better performance than the more simplistic offload methods.

Tamper-Resistant FAPs

FAPs are gateways to the carrier core IP network and the carrier’s radio network. Femtocells are prone to attacks by curious engineers and malicious criminals due to this connection and because they are part of the CPE. Regardless of the motives of the attack, though, the FAPs need to be tamper-proof.

The standards for FAPs call for the configuration data for the radio, radio configuration data, encryption keys, identity material, and operational statistics to be stored within the access point itself. This data is sensitive and must not be available to any party but the carrier. To achieve this, the data must be stored in a robustly protected “cryptographic safe” within the device.

Consumer-permitted devices have a long history of being compromised. To prevent FAPs from falling victim to the same fate, several precautions must be taken:

• Secure boot functionality: The device must only boot software images or accept data endorsed or signed by the manufacturer.
• Runtime integrity protection: While the device is running, the software images that it executes must not be alterable. Attackers must not be able to change the software while it is running.
• Secure storage: Carrier assets within the device need to be protected through storage within a “cryptographic safe” that is only accessible to the operator.

Achieving Femtocell Security

While observations of the threat model may seem overtly pessimistic, the picture isn’t bleak. Threats can be identified, and the technology and expertise to counter the threats is available. The key to a secure and robust system lies in expertise and experience, combined with the best technology. For example, SafeNet provides a complete, carrier-grade femtocell security solution for providing the peer authentication, data privacy, and device integrity demanded by the telecom industry for femtocell networking environments.

Femtocell SoC vendors can implement platform security features such as secure boot, secure storage, and runtime integrity monitoring. Complementary software (or “security middleware”) can give customer software applications seamless access to the platform security features of the device.

Available products from SafeNet include the QuickSec/IPsec toolkit and SafeNet’s SafeXcel IP Packet Engine. These hardware/software products provide system integrators with a complete and proven, easy-to-integrate security offering that reduces development cost and minimizes time-to-market.