Femtocell access points [H(e)NBs] are close-range, limited-capacity base stations that utilize residential broadband connections to connect to carrier networks. The use of such distributed base station architecture improves reception and allows the operators to deliver fast, seamless, high-bandwidth cellular coverage into the homes and offices of their end customers.
The deployment of Femtocell solutions is attractive to mobile network operators as they successfully address coverage and mobile data bandwidth requirements by leveraging widely available broadband connections without the additional cost associated with the alternative macro-cell deployment.
Security is the most challenging area and critical aspect to prevent unauthorized access to important resources in any wireless communication network. Like all communications technologies, Femtocells also require robust security. To maintain the level of security that is expected of the telecommunications networks, Femtocell systems require that the authenticity of the communicating peers (access points and gateways) and the privacy and integrity of the data exchanged are guaranteed.
This article summarizes various security concerns/threats on H(e)NB, mitigation of these security threats, security architecture and various security aspects to take care of the associated security issues.
The threat model consists of attack threats from third parties that try to compromise the security of the communication links and from hosting parties that attack the H(e)NB devices themselves. The general security concerns/threats for any wireless network (node/device) and are also valid here for H(e)NB are listed below:
The credentials used for securing the communication between H(e)NB and network can be compromised if the authentication algorithm/credentials used is weak which can be cracked by brute force attack OR through physical intrusion where H(e)NB authentication data is not stored in protected domain and can be read by the attacker through illegal means. Other possibility is if someone clones the authentication credentials and uses the same in illegal node (H(e)NB). This type of the attacks are avoided by using strong authentication algorithms/credentials (Refer mutual authentication section) and storing authentication credentials/security data inside the secure domain (Refer Storage Environment section where security data is stored in trusted environment TrE and Hosting party module)
The man-in- the-middle attack is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.
This kind of attack can happen when H(e)NB makes a first contact to the operator’s network. During this contact, operator’s endpoint cannot reliably identify the peer. An attacker on the internet can intercept all traffic from H(e)NB and later get access to all private information, impersonate the H(e)NB. These types of the attacks are avoided by using authentication credentials during the first point of contact with the network and these credentials shall be recognized by the operator. USIM or vendor certificates are used for this (Refer section Mutual authentication section where certificate based device authentication and AKA based hosting party authentication is done to mitigate this risk).
In this kind of attack, a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out by the attacker who intercepts the data and retransmits it. This is possible if the originator (H(e)NB) does not use unique authentication data and a session id which shall be incremented in every message communication with the peer. This kind of attacks are avoided by sending a incremental session id in the message/data communication so that receiver can know if this replayed or not (Refer Mutual Authentication section wherein the message exchange during device authentication or EAP-AKA based hosting party authentication involves the usage of incremental session id to avoid the replay attacks)
This kind of attack is used by the attacker to deny the services to the genuine users. Attacker in this case keep on sending fake requests or data towards the destination forcing it to break down the link or to temporarily stop the service seeing the attack being planned. This kind of attack is avoided at H(e)NB by allowing only IKE negotiations and ESP-encrypted traffic using IKEv2 (Refer Mutual authentication section involving usage of IKEv2 protocol which is robust against the DoS attacks).
In case unprotected user data leaves the secure domain, this data is available for eavesdropping for the attacker. The same is the case of H(e)NB.
In this kind of attack, the attacker is able to configure the illegal H(e)NB such that users of a given CSG join it. The attacker buys an H(e)NB and configures it similar to that of an H(e)NB of a CSG. Having done that the attacker changes the setting in the H(e)NB to no encryption and integrity level or has access to the user keys in the H(e)NB. The attacker can do this by connecting the H(e)NB to the wired backbone of the H(e)NB provisioning company or use multi-hop solution to connect the H(e)NB to the valid one connected to the wired network. This kind of attack is avoided by hiding the CSG setting and other configuration. There should be binding between H(e)NBs and the users it can serve that should also be known by the network. The H(e)NB must be authenticated by the network.
The security concerns that are discussed in the previous section put certain requirements on the H(e)NB to mitigate the possible threats. These requirements can be summarized as below:
The various security aspects that will be used at H(e)NB or on the interface between H(e)NB and SeGW/H(e)MS to take care of the security requirements listed above are:
The H(e)NB and TrE performs a device integrity checkup on booting and before connecting to the core network and/or to the H(e)MS. The device integrity check is performed based on one or more trusted reference value(s) and the TrE. The TrE should boot securely. The integrity of a component is verified by comparing the result of a measurement (typically a cryptographic hash) of the component to the trusted reference value. If these values agree, the component is successfully verified and can be started. For each of the component integrity checks, the TrE retrieves the corresponding trusted reference value from secure memory.
The integrity of the device is verified if all components necessary for trusted operation of the device are verified. If the device integrity check according to failed, the TrE does not give access to the sensitive functions using the private key needed for H(e)NB device authentication with the SeGW.
H(e)NB and SeGW are mutually authenticated before H(e)NB is allowed the network access. Two types of authentications are executed: mandatory device authentication and/or optional hosting party authentication
The mutual device authentication is mandatory for H(e)NB wherein H(e)NB and SeGW both need to authenticate each other. Device mutual authentication is performed using IKEv2 with public key signature based authentication with certificates (Refer Reference 2). The H(e)NB’s credentials and critical security functions for device authentication need to be protected inside a TrE.
The H(e)NB is provisioned with a device certificate. This device certificate allows the authentication of the H(e)NB by the SeGW (and thus the operator network).The device certificate is provided by the operator, manufacturer, vendor of the H(e)NB, or by another party trusted by the operator.
The SeGW is also configured with a certificate. This certificate allows the authentication of the SeGW by H(e)NB. Again SeGW certificate is provided by an operator trusted CA.
A Fully Qualified Domain Name (FQDN) formatted identifier is used for certificate based authentication of the H(e)NB and of the SeGW. For the H(e)NB this FQDN needs to be globally unique. If no DNS is available for resolution of the FQDN of the SeGW, then the IP address of SeGW shall be used as identifier.
The H(e)NB may check the revocation status of certificates using OCSP (Refer Reference 7). The SeGW may check the revocation status of certificates using CRLs or OCSP .
The H(e)NB’s TrE is used to provide the following critical security functions supporting the IKEv2 and certificate processes:.
The SeGW need to process H(e)NB certificate in similar way as H(e)NB does. The SeGW checks the certificate revocation status if configured by local policy.
The hosting party mutual authentication is optionally performed by the operator’s network following successful device mutual authentication. An EAP AKA based method is used for hosting party authentication. When Hosting Party Authentication is used, both device and hosting party authentication must be completed successfully before a secure tunnel to the operator network can be established. The authentication of the hosting party is based on credentials contained in a separate Hosting Party Module (HPM) in H(e)NB, and in the MNOHLR/HSS. An AKA credential is stored in HPM enabling to use EAP AKA. EAP authentication executes between H(e)NB and AAA server and the SeGW acts as EAP authenticator and forwards the EAP protocol messages to the AAA server to retrieve an authentication vector from AuC via HSS/HLR. A globally unique identifier in the format of an IMSI is used for EAP AKA based authentication.
These IMSIs are marked in HLR/HSS as used for H(e)NBs, e.g. by allocating dedicated ranges or by adding specific attributes to avoid misuse of these IMSIs for ordinary UEs .
The H(e)NB uses IKEv2 protocol to set up atleast one IPsec tunnel to protect the traffic with SeGW, i.e., a pair of unidirectional SAs (Security Associations) between H(e)NB and SeGW. All signaling, user and management plane traffic over the interface between H(e)NB and SeGW is sent through an IPsec ESP tunnel (with NAT-T UDP encapsulation as necessary) that is established as a result of the authentication procedure.
The H(e)NB initiates the creation of the SA i.e. it acts as initiator in the Traffic Selector negotiation. Upon H(e)NB’s request, the SeGW allocates IP address to the H(e)NB after successful authentication. The H(e)NB and SeGW uses the IKEv2 mechanisms for detection of NAT, UDP encapsulation for NAT Traversal, H(e)NB initiated NAT keep-alive, IKEv2 SA and IPsec SA rekeying, and Dead Peer Detection (DPD).
During setup of the tunnel, the H(e)NB includes a list of supported ESP authentication transforms and ESP Encryption transforms as part of the IKEv2 signaling. The SeGW selects an ESP authentication transform and an ESP encryption transform and signal this to the H(e)NB. .
In case that the H(e)MS is accessible on MNO Intranet, H(e)MS traffic can be protected through the support of one of the two security mechanisms determined by the Network Operator’s Security Policies:
In case that the H(e)MS is accessible on the public Internet, the H(e)MS is exposed to attackers located in insecure network. H(e)MS traffic is protected by TLS tunnel established between H(e)NB and H(e)MS. In this case, mutual authentication between H(e)NB and H(e)MS will be based on device certificate for the H(e)NB and network certificate for the H(e)MS. The H(e)NB verifies the H(e)MS identity by checking the subjectAltName field of the H(e)MS certificate against the name of the H(e)MS. The H(e)NB may check the revocation status of the H(e)MS certificate using OCSP. Support for OCSP is optional for the operator network. The H(e)NB should support OCSP
For the management of the H(e)NB by the H(e)MS, the CPE WAN Management Protocol TR-069 is used. H(e)NB utilizes this TR-069 method to download software from H(e)MS or a server.
The usage of security mechanisms including usage of Trusted Environment (to store all critical security related data), device integrity check, mutual authentication between H(e)NB and SeGW (certificate based using IKEv2 for device authentication and EAP-AKA based mutual hosting party authentication), mutual authentication between H(e)NB and H(e)MS (certificate based using TLS) and creation of secure IPSec based tunnel between H(e)NB and SeGW for transforming backhaul traffic has mitigated/avoided various security concerns /threats discussed in this article.
These cookies are necessary for the website to function and cannot be switched off.
These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.
These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Do you have an upcoming project and wantus
to help speed up your time to market?