1. INTRODUCTION:

Mobile phones are the best way of communicating with one person to other worldwide. A vast amount of call and data session is being used by the home and office user. But a good mobile coverage in these indoor places is a challenge which every network operator is facing these mojor problem. In order to deal with the bandwidth and quality of coverage demanded by today's more than 2.7 billion cellular telephone users, mobile operators are moving towards femtocell systems. Femtocells are close range, limited capacity base stations that uses residential broadband connections for connecting to the networks. This type of base station improves reception and allows the operators to give fast, high-bandwidth cellular coverage into the homes and offices of their users.

The exploitation of femtocell solutions for enhancing existing mobile networking capabilities is amazingly remarkable to service providers as it is a cost affective and cheapest solution as compared to the macro cell. Running a macro cell for a normal mobile network is expensive. The base station devices themselves are costly, as is their maintenance, and its constructing cost is too much. Macro cell base stations also need dedicated connections, adding further to the overall cost of deployment.

1. THE NEED OF MOBILE BROADBAND:

To think how to make mobile broadband demand cost effectively, it is important to understand the requirement of it. Mobile service was basically about services to mobile users those travelling between homes and offices via public or private transport, where communication services are not available. On the other hand, the most important and biggest components of mobile requirements are services delivered to mobile devices, yet stationary users. mobile equipments are increasingly personal and are used by individuals when they are not on the move, within some buildings, including both the home and the workplace. One-third of all cellular traffic today is at home even though networks are not typically being planned to provide a solid home service. Another third is in the workplace, with the remaining third being the ‘traditional' traffic generated on the move. It is expected that

Figure : Forecast global mobile data revenues and traffic. Reproduced by permission of Informa

Telecoms and Media Ltd

In the above figure future forecast has been predicted from a survey by Informa Telecoms and Media Ltd., these proportions represents the overall data volumes grow, due to the need for users to be looking at a screen when using most high bandwidth data services like web browsing or mobile video by the users see Figure 1.2.

Studies of these traffic patterns show that in Europe 57% of mobile minutes are used at home or work. With in the building traffic on 3G networks is expected to grow to 78% of the total by 2011. Unted Kingdom is a well developed market with over 94% population coverage for 3G and far higher for 2G. A complete study of mobile users in the UK showed that 19% of mobile phone owners regularly faces coverage problems in thier home.54% of those users complains for poor service in their house, while the remainder reports the coverage problems in selected rooms. Below are the factors involve in it.

Figure Increasing proportions of traffic generated indoors

  • Service take-up often starts at home and then spreads to the enterprise: witness the way in which Wi-Fi, although originally intended as an enterprise technology, only reached a mass market via usage in homes before being adopted in corporate environments.
  • Voice minutes are increasingly moving from fixed line to mobile, as an increasing proportion of users come to rely upon their mobile as their main - or even only - telephone.
  • Operators (not only mobile ones) are increasingly offering ‘quadplay' and other bundled flat rate tariffs, which include large quantities of mobile service along with fixed line, Internet and television services.

Any and all of these services point towards the need for operators to deliver a high-quality service to users at home and at work, including steadfast coverage and high data rates, while dropping the cost per bit for delivery.

1.1. WHAT IS FEMTOCELL?

A femtocell is a low power device similar to a router, based on mobile technology, providing wireless voice and broadband services to customers in the home or office. As shown in Figure 1.3, the femtocell connects to the mobile operator's network via broadband connection, including ADSL, cable or fibre. Data is carried out via the internet for the mobile.

Single femtocell can handle four users in the home simultaneously, it can allow many users to connects or register with it. Multiple users will receive data via Femtocells, typically at the full tip rate supported by the relevant air interface technology, currently several megabits per second and increasing to tens and hundreds of megabits per second in the upcoming years. Data from multiple Femtocells are concentrated together in a gateway, managed by the mobile operator, and find their way back to the operator core network along with the data from the operators macro cell network. The operator core network also contains a management system which provides services to the femtocell, making possible that the services experienced by the user are protected, of high quality and can coexist with the signals from other Femtocells and the other network. Femtocell may be a stand alone gadget, which connects into the customer's existing broadband router which incorporates the router and other technologies, such as a broadband modem, Internet router and Wi-Fi access point into a single integrated device. Examples of both types are illustrated in Figure 1.4.

Figure : Some stand-alone and integrated femtocells.

1.1.1. FEMTOCELLS STANDARDS:

Most of the air interfaces included in the global ITU-R IMT family have active programmes to develop standards for Femtocells. These standards include:

  • 3GPP standards for Femtocell, which is a WCDMA femtocell. Both FDD and TDD options are likely and a TD SCDMA alternative is also considered.
  • 3GPP standards for Femtocell, which is an LTE femtocell. Both FDD and TDD options were considered.

In all cases femtocell standards will support deployments in all of the existing licensed spectrum bands in which macro cells operate.

1.1.2. TYPES OF FEMTOCELLS :

Femtocells are likely to come in different hardware types. Although individual standards vary in their definitions, femtocell can be determined in various classes and they can be defined as :

  • Class 1. This is the first class of Femtocell which is known as best among all classes. Femtocells in this class deliver a similar transmit power and deployment view to Wi Fi access points for residential or enterprise application. Femtocell delivers simultaneously 4 voice channels plus data services, supporting closed or open access installed by the user.
  • Class 2. Somewhat higher power (typically up to 24 dBm of radiated power), perhaps to support longer range or more users (say 8-16). Supports closed or open access. May be installed by the end-user or the operator. May be viewed as an evolution of picocell technology.
  • Class 3. Still higher power for longer range or more users (e.g. 16 or greater). Typically carrier deployed and may well be open access. Could be deployed indoors (e.g. in public buildings) for localised capacity, outdoors in built-up areas to deliver distributed capacity or in rural areas for specific coverage needs

1.2. WHERE FEMTOCELLS ARE USED:

Femtocells started as a means of delivering services to residential environments. This remains a core application for femtocells and it enables femtocell technology to be produced in large volumes and low costs. However, femtocells are not limited to this application and early deployments for other purposes are anticipated. Current applications include:

Residential - Femtocells are installed indoors within the home by the end user and may be stand-alone devices or integrated with other technology such as residential gateways. Access to the residential femtocell will often be closed - restricted to a specified group of users but may also be open to all registered users in some cases. Typically these application needs will be met using class 1 femtocells.

Enterprise - Enterprise femtocell deployments may be in small-office, home-office situations, in branch offices or in large enterprise buildings. Femtocells for this purpose are usually of class 1 or class 2 and will typically support additional functionality compared with residential devices such as handover between femtocells, integration with PBX and local call routing.Will primarily be used indoors, but could also be used to serve a corporate campus. Installation will probably be managed by the carrier, but may be achieved by the enterprise itself or its IT subcontractors. Access may be closed or open.

Operator - This class encompasses a wide variety of applications where operators use femtocells to solve specific coverage, capacity or service issues in both indoor and outdoor environments. These could be composed of class 1, 2 or 3 devices and will usually be open access. They will be installed by the operator or by third parties under the operator's direction.

Others - These application classes are not exclusive and it is expected that other innovative ideas for the application of femtocells will emerge, for example on aircraft, trains or passenger ferries. In all cases the essential attributes of femtocells described earlier will be observed, enabling full compliance with relevant local customer, operator and regulatory requirements.

4 System architecture

4.1 General

On the architecture we assume that

  1. A kind of access concentrator function (e.g. Gateway) maybe the first contact in the core network (i.e. within a secured domain) for the H(e)NB.
  2. Home access point (like H(e)NB are normally connected to the Internet via some access device (e.g. ADSL, cable modem). In these cases, such access device could be integrated with the H(e)NB, or be in a separate box.
  3. A software distribution centre or O&M centre is supposed to be located in a secured domain.

H(e)NB terminology:

Regarding the UP encryption, three cases have to be differentiated:

  1. HNB: UMTS case where UP encryption does not terminate in HNB
  2. HNB: UMTS case where UP encryption terminates inside HNB
  3. HeNB: LTE case

Where applicable the difference in consequences will be described.

Authentication scheme and terminology

Different solutions are possible for authentication of H(e)NB towards the core network. We distinguish these solutions by

  1. the device authentication scheme
  2. type of secure credential storage.

NOTE 1: This does not exclude combinations of the above solutions: Example, a removable token combined with an onboard certificate.

NOTE 2: The threats section uses the term ‘authentication token' to denote the collection of the above cases. Where needed a certain property of the authentication token (e.g. row, column above) may be under attack in the threat analysis.

4.2 System architecture of HNB

Figure 1: System Architecture of HNB

Description of proposed system architecture:

  • Air interface between UE and HNB should be backwards compatible air interface in UTRAN;
  • HNB access operator's core network via a Security Gateway. The backhaul between HNB and SeGW may be insecure.
  • Security Gateway represent operator's core network to perform mutual authentication with HNB. Mutual authentication may need support of authentication server or PKI. SeGW and HNB GW are logically separate entities within operator's network.
  • Security tunnel is established between HNB and Security Gateway to protect information transmitted in backhaul link.
  • HNB-GW performs the access control for the non-CSG capable UE attempting to access the HNB. SeGW may be integrated into HNB GW. If the SeGW and the HNB GW are not integrated, then the interface between the HNB-GW and the SeGW may be protected using NDS/IP [18].
  • Secure communication is required to Operation, Administration and Maintenance (OAM). This becomes even more important if OAM is placed outside the operator's network.

Editor's Note: The security implications of collapsing certain Core networks related functionality (e.g. SGSN or GGSN) in the HNB should be studied

NOTE: There may be a Home Gateway in the architecture at the customer premise. If such a Home Gateway is a physically and logically separate entity than the HNB, such a Home Gateway should not be present in the architecture since the security of the HNB should not rely on the security of the Home Gateway. However, if such a Home Gateway is physically or logically integrated with a HNB, it should be studied if security aspects (e.g. device security) of the Home Gateway may impact that of the HNB. In addition, the existence of any Home Gateway (integrated or separated) may imply restriction on the selection of backhaul security solutions, e.g. to allow NAT traversal.

4.3 System architecture of HeNB

Figure 2: System Architecture of HeNB

Description of proposed system architecture:

  • Air interface between UE and HeNB should be backwards compatible with air interface in E-UTRAN;
  • HeNB access operator's core network via a Security Gateway. The backhaul between HeNB and SeGW may be insecure.
  • Security Gateway represent operator's core network to perform mutual authentication with HeNB. Mutual authentication may need support of authentication server or PKI.
  • Security tunnel is established between HeNB and Security Gateway to protect information transmitted in backhaul link.
  • HeNB GW is optional to deploy. If HeNB is deployed, then SeGW may be integrated into HeNB GW. If the SeGW and the HeNB GW are not integrated, then the interface between the HeNB-GW and the SeGW may be protected using NDS/IP [18].
  • Secure communication is required to Operation, Administration and Maintenance (OAM). This becomes even more important if OAM is placed outside the operator's network.

Editor's Note: The security implications of collapsing certain Core networks related functionality (e.g. Serving GW) in the HeNB should be studied

NOTE: There may be a Home Gateway in the architecture at the customer premise. If such a Home Gateway is a physically and logically separate entity than the HNB, such a Home Gateway should not be present in the architecture since the security of the HNB should not rely on the security of the Home Gateway. However, if such a Home Gateway is physically or logically integrated with a HNB, it should be studied if security aspects (e.g. device security) of the Home Gateway may impact that of the HNB. In addition, the existence of any Home Gateway (integrated or separated) may imply restriction on the selection of backhaul security solutions, e.g. to allow NAT traversal.

4.4 Overview of Security Architecture

Figure3 gives an overview of the complete security architecture of H(e)NB.

Figure3: Overview of the H(e)NB security architecture

Five security feature groups are defined. Each of these feature groups meets certain threats and accomplishes certain security objectives:

  • H(e)NB access security (I): the set of security features which include the mutual authentication between H(e)NB and network, security tunnel establishment between H(e)NB and SeGW, authorisation mechanisms and location locking mechanisms of H(e)NB. SeGW should interact with entities (AAA/HLR or H(e)NB device identity server) located in CN for performing mutual authentication and authorization.
  • Network domain security (II): the set of security features which include security communication and security communication between SeGW and CN.
  • H(e)NB service domain security (III): the set of security features which include security communication between H(e)NB and entities located in CN. For working properly, H(e)NB should interact with an OAM server or a device management server located in CN to download software or update configuration data. Communication between H(e)NB and these entities should be secured.
  • UE access control domain security (IV): the set of security features which include UE access control mechanisms. These security features only apply to legacy UEs. For Rel-8 compliant UEs, the access control of the UE is based on the allowed CSG list and accomplished on the terminal and CN, H(e)NB will not perform access control for the Rel-8 compliant UEs.
  • UE access security domain (V): the set of security features that provide UEs with secure access to mobile communication system. Since the introduction of the H(e)NB should have no influence on the UE, the security features of this domain is as same as the security features defined in the corresponding mobile communication system specifications and consequently out of scope of current specification.

Threats analysis

NOTE 1: A reference to certain implementation platform mentioned in this TR is for illustrative purposes only. Such examples are by no means exhaustive and are not to be construed as threat-mitigating solutions.

5.1 Common threats to H(e)NB

In this section threats common to Femtocells are presented. The section starts with a list of threats that are then grouped in different categories. Details of each threat is also given in this section together with the impact of each threat on different assets and the risk level they belong to.

5.1.1 Threats List

Threats identified in this TR are listed below. These threats are detailed in Section 5.1.3.

  1. Compromise of H(e)NB authentication token by a brute force attack via a weak authentication algorithm.
  2. Compromise of H(e)NB authentication token by local physical intrusion.
  3. Inserting valid authentication token into a manipulated H(e)NB.
  4. User cloning the H(e)NB authentication Token.
  5. Man-in-the-middle attacks on H(e)NB first network access.
  6. Booting H(e)NB with fraudulent software (“re-flashing”).
  7. Fraudulent software update / configuration changes.
  8. Physical tampering with H(e)NB.
  9. Eavesdropping of the other user's UTRAN or E-UTRAN user data.
  10. Masquerade as other users.
  11. Changing of the H(e)NB location without reporting.
  12. Software simulation of H(e)NB.
  13. Traffic tunnelling between H(e)NBs.
  14. Misconfiguration of the firewall in the modem/router.
  15. Denial of service attacks against H(e)NB.
  16. Denial of service attacks against core network.
  17. Compromise ofan H(e)NB by exploiting weaknesses of active network services
  18. User's network ID revealed to H(e)NodeB owner
  19. Mis-configuration of H(e)NB
  20. Mis-configuration of access control list (ACL) or compromise of the access control list
  21. Radio resource management tampering
  22. Masquerade as a valid H(e)NB
  23. Provide radio access service over a CSG
  24. H(e)NB announcing incorrect location to the network
  25. Manipulation of external time source
  26. Environmental/side channel attacks against H(e)NB
  27. Attack on OAM and its traffic
  28. Threat of H(e)NB connectivity to network access
  29. Handover to CSG H(e)NB.

5.1.2 Grouping of Threats

The threats of Section 5.1.1 can be grouped in 6 different categories as given in this below.

The above threat maybe grouped together as the following:

Compromise of H(e)NB Credentials

  1. Compromise of H(e)NB authentication token by a brute force attack via a weak authentication algorithm.
  2. Compromise of H(e)NB authentication token by local physical intrusion.
  3. User cloning the H(e)NB authentication Token.

Physical attacks on a H(e)NB

  1. Inserting valid authentication token into a manipulated H(e)NB.
  2. Booting H(e)NB with fraudulent software (“re-flashing”).
  3. Physical tampering with H(e)NB.
  4. Environmental/side channel attacks against H(e)NB

Configuration attacks on a H(e)NB

  1. Fraudulent software update / configuration changes.
  2. Mis-configuration of H(e)NB
  3. Mis-configuration of access control list (ACL) or compromise of the access control list

Protocol attacks on a H(e)NB

  1. Man-in-the-middle attacks on H(e)NB first network access.
  2. Denial of service attacks against H(e)NB.
  3. Compromise ofan H(e)NB by exploiting weaknesses of active network services
  4. Manipulation of external time source
  5. Attack on OAM and its traffic
  6. Threat of H(e)NB network access

Attacks on the core network, including H(e)NB location-based attacks

  1. Changing of the H(e)NB location without reporting.
  2. Software simulation of H(e)NB.
  3. Traffic tunnelling between H(e)NBs.
  4. Misconfiguration of the firewall in the modem/router.
  5. Denial of service attacks against core network.
  6. H(e)NB announcing incorrect location to the network

User Data and identity privacy attacks

  1. Eavesdropping of the other user's UTRAN or E-UTRAN user data.
  2. Masquerade as other users.
  3. User's network ID revealed to Home (e)NodeB owner
  4. Masquerade as a valid H(e)NB
  5. Provide radio access service over a CSG

Attacks on Radio resources and management

  1. Radio resource management tampering

5.1.3 Threats

Threats listed in Section 5.1.1 are detailed in the following. Each threat starts with a title same as that given in the list of Section 5.1.1 followed by prerequisites to perform the attack, a description of the threat, probability of the threat, extent of impact the threat can have, assets that are affected by the threat and potential means to mitigate the threat.

1) Compromise of H(e)NB authentication token by a brute force attack via a weak authentication algorithm.

Prerequisites: Token with weak authentication algorithm is used for H(e)NB authentication to the operator's network. This threat refers to a specific usage of shared secrets for H(e)NB authentication i.e. the cases 1 and 3 of Table 1: Different authentication token variants.

Description: An example for a token using a weak authentication algorithm is GSM SIM with COMP128-1, which is known to be possible to crack by brute force. In an H(e)NB setting such attacks could be launched from spoofed network access concentrator on internet if initial communication with access concentrator is not adequately secured.

Probability: Possible.

Impact: Harmful, but only if combined with other attacks.

Threats to assets:

  1. H(e)NB: An attacker gain unauthorized access to H(e)NB with above mentioned weak token
  2. User: Compromised token can be used to masquerade H(e)NB to User and mount further attacks towards user.
  3. Operators Network: An attacker could use the obtained authorization to try to mount further attacks towards the core network.

Mitigation: Any authentication token with a weak algorithm like GSM SIM with COMP128-1 should not be used for H(e)NB authentication. Backhaul link protection mechanism should be strong enough.

NOTE 1: In S3-070614 SA3 answers suggests that for initial authentication S1-based authentication should be used. “Authentication of Home NodeB to the Serving Network, as well as Serving Network to the Home NodeB is needed and required to ensure overall security of the 3GPP system. As far as authentication when first connected, the security will need to be maintained, perhaps by maintaining a security context between Home NodeB and rest of network. SA3 is currently specifying security mechanisms for S1 interface, which may be applicable to Home NodeB. However, SA3 would also like to add that these answers are not limited to LTE-based Home NodeB's.”

NOTE 2: SA3 have decided to use certificates based authentication on S1 and X2 interfaces in the case of macro eNB.

2) Compromise of H(e)NB authentication token by local physical intrusion

Description: An attacker reads authentication credentials from the wires of the H(e)NB and takes a copy. After that, any other device can use it and impersonate the H(e)NB.

Probability: Depends on the implementation. If the H(e)NB authentication data is not stored in a protected domain, such as a TPM module or a UICC, the probability of such compromise is high. Otherwise, low.

Impact: Harmful. Threats assets are the same as in the previous case.

Mitigation: Authentication credentials of the H(e)NB shall be stored inside a secure domain i.e. from which outsider cannot retrieve the credentials.

3) Inserting a valid authentication token into a manipulated H(e)NB.

Prerequisites: H(e)NB authenticates to the network with a removable token (e.g. a UICC) or an embedded UICC or TPM that can be physically removed (i.e. case 3 and 4).

Description: User inserts/installs valid authentication token into a fake H(e)NB.

Impact: A device (manipulated H(e)NB) with some other functionality (re-flashed H(e)NB, or an H(e)eNB from another, incompatible manufacturer), can identify itself to the operator using a valid credential, and proceed with any kind of security violation. The consequences on the unknowing user are due to manipulations of the H(e)NB.

Threats to assets:

  1. Threats to H(e)NB: Introduce malicious configuration changes
  2. Threats to user: eavesdropping, impersonation of legitimate user due to H(e)NB manipulation.
  3. Threats to operator: Attacks to the infrastructure (radio, core), misuse of user channels, changed signalling.

Mitigation: A non-removable authentication token is helpful to mitigate the risk. Also new users could be required to explicitly confirm their acceptance before being joined to an H(e)NB. This way an H(e)NB owner could only perform eavesdropping/masquerade attacks against those who join the H(e)NB. This approach relies on additional access control being enforced in core network, not just only at the H(e)NB.

It is possible that introducing device authentication or binding removable token to certain H(e)NB can also mitigate the risk, which may need a combination of a removable token and an onboard token.

4) User cloning the H(e)NB authentication Token.

Prerequisites: The token used to authenticate H(e)NB can be cloned and is inserted in a genuine H(e)NB.

Description: Attacker clones authentication credentials of legitimate H(e)NB and installs credentials into another H(e)NB. The cloned H(e)NB is activated near the legitimate H(e)NB. The difference to Threat 3 is that the attack is mounted using an unmodified, legal H(e)NB.

Impact: very harmful.

Threats to assets:

  1. Threats to H(e)NB: --
  2. Threats to user: Ability to eavesdrop/spoof GSM/3G/LTE calls would have serious and wide-ranging impacts. If the H(e)NB works in an open mode and UP ciphering terminates inside H(e)NB, the impact of the attack is worse since the attacker could eavesdrop or spoof any mobile terminal, not just those authorized to use the cloned H(e)NB.
  3. Threats to operator: Issues appear in case a bill would be related to the H(e)NB owner based on H(e)NB identity. H(e)NB owner may be billed for attacker's calls which is routed by cloned H(e)NB.

Mitigation: the authentication credentials of the H(e)NB should be difficult to clone. Also new users could be required to explicitly confirm their acceptance before being joined to an H(e)NB. This way an H(e)NB owner can only perform eavesdropping/masquerade attacks against those who join the H(e)NB. This approach relies on additional access control being enforced in core network, not just at the H(e)NB. Multiple instances of the same H(e)NB should not be allowed simultaneous access to the core network. Some forms of location locking (e.g. to DSL line) may also help to mitigate this threat.

5) Man-in-the-middle attacks on H(e)NB first network access

Prerequisites: H(e)NB does not have unique authentication credentials, pre-installed at the factory or inserted into the H(e)NB.

Description: 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 and so on. If the authentication data is not unique to the H(e)NB, a replay attack can be possible.

Probability: Possible.

Impact: Very Harmful.

Threats to assets:

  1. Threats to H(e)NB: --
  2. Threats to user: Such attack allows for eavesdropping of all the data, passing between the H(e)NB and the network, and also for sending any data on behalf of any party.
  3. Threats to operator: If the attacker get in the possession of non-unique initial contact credentials then an attacker may try to obtains network access for whatever H(e)NBs..

Mitigation: H(e)NB shall have authentication credentials already during the very first contact with the network. These credentials shall be recognized at the operator's side. Un-authenticated traffic should not be accepted even at the “first-contact” phase. Either USIM on a UICC, or vendor certificates could be used for this. The logistical consequences could be different. UICC could be inserted in the H(e)NB by the point of sales or customer. Vendor certificate has to be inserted in the H(e)NB at stage of manufacture.

For certificate based solution, mutual authentication is performed between first contact node (i.e. Security GW) and H(e)NB.

For UICC-based solutions, mutual authentication is between HSS and UICC. Certificate of first contact node (i.e. security GW) may be used to authenticate itself toward H(e)NB if necessary.

6) Booting H(e)NB with fraudulent software (“re-flashing”)

Description: Boot software at the H(e)NB is modified by the attacker.

Probability: Very likely if a user-accessible boot code update method is used. For example, re-flashing of mobile phones to avoid various restrictions is a common practice in some parts of the world.

Impact: up to disastrous. Possibility to use any software can mean any violation of the security:

Threats to assets:

  1. Threats to H(e)NB: Adding non-official software may cause non-optimized functioning of the H(e)NB.
  2. Threats to user: eavesdropping on communication, impersonation towards the network.
  3. Threats to operator: attack on the radio interface (jamming), denial of service possibilities.

Mitigation: Booting process shall be secured by the cryptographic means, for example using a TPM module. Additional security measures may be needed in case of USIM-based H(e)NB authentication towards the network.

7) Fraudulent software update / configuration changes

Description: H(e)NB should naturally accept software updates from the network. If the software distribution center is compromised, a huge number of access points may receive and install malicious software.

Probability: Possible. A compromise of the SW distribution center / O&M facility is required first. The software distribution centre / O&M facility is supposed to be located in a secured network domain. However possibility of a malicious insider / disgruntled employee should not be discounted.

Impact: Extremely harmful. Possibility of very powerful distributed attacks if many H(e)NB are impacted.

Threats to assets:

  1. Threats to H(e)NB: Adding non-official software may cause non-optimized functioning of the H(e)NB.
  2. Threats to user: eavesdropping, impersonation
  3. Threats to operator: attacks on the radio interface, service costs: all compromised access points must be manually re-flashed. Denial of service attacks to the network could mounted.

Mitigation: All software updates and configuration changes shall be cryptographically signed, and H(e)NB shall have means to verify the signature.

8) Physical tampering with H(e)NB

Description: H(e)NB components could be modified or replaced.

Probability: Possible. A user (attacker) could change components in his H(e)NB, e.g. to extend coverage

Impact: Harmful.

Threats to assets:

  1. Threats to H(e)NB: Physical tampering may introduce some degradation of H(e)NB lifetime.
  2. Threats to users of H(e)NB: Malicious HW configuration may imply health risks. Modified RF components may interfere with other wireless devices in the environment of the user and cause them to malfunction.
  3. Threats to operator: an H(e)NB with modified RF components could have adverse affects on surrounding macro network.

Mitigation: H(e)NB shall be physically secured to a moderate extent to prevent easy replacement of components. Trusted computing techniques could be used to detect when critical components are modified or replaced..

9) Eavesdropping of the other user's UTRAN or E-UTRAN user data

Prerequisites: H(e)NB leaves user traffic unprotected in some part of the H(e)NB; this refers in particular to the HeNB and HNB where UP ciphering terminates inside HNB.

Description: an attacker purchases H(e)NB, installs it, and configures to the open access mode. Data, which is neither available unprotected on air-interface, nor with IP-interface security, is read (for example, by inserting a card in the bus of the H(e)NB, where that data flows). Victim is using normal air interface, but camps to this H(e)NB without knowledge. All data, flowing between the victim and the network, could be read.

Probability: Possible. First, reading data from wires (e.g. memory bus) is still difficult. Second, manufacturers are strongly recommended (or even requested) to run the processing inside one chip. If a manufacturer cannot provide this, then at least some obfuscation or encryption with a secret key would be applied to the open data.

Impact: (very) harmful, dependent on sensitivity and value of communicated data.

Threats to assets:

  1. Threats to H(e)NB: The threats of physical tampering are described in Threat 8.
  2. Threats to users of H(e)NB: Privacy of users can be seriously harmed without them ever knowing about it. Such H(e)NB can be used as a “general air interface sniffing device”, unless users, concerned about their privacy and suspecting that they are eavesdropped, choose to select network manually on their devices. If the H(e)NB works in an open mode, the impact of the attack is worse since the attacker could eavesdrop any mobile terminal, not just those authorized to use the H(e)NB.
  3. Threats to operator: --.

Mitigation: Unprotected user data should never leave a secure domain inside H(e)NB. The user could be notified when the UE camps on a closed or open type H(e)NB. User could be notified (or give his/her explicit acceptance) when he/she is added to the access list of a closed type H(e)NB.

NOTE 1: The H(e)NB can work in open access mode, closed access mode and hybrid access mode.

NOTE 2: The threat not only applies to open mode, but to closed mode as well. See following scenario: Suppose members of the same family, who once added their numbers to the access list. Later, Marc installs a sniffing device, and records everything what Bernhard is talking with his friends. This is not acceptable. And explicit adding does not help: Bernhard still expects that his calls are private.

10) Masquerade as other users

Prerequisites: H(e)NB leaves user traffic unprotected in some part of the H(e)NB; this refers in particular to the HeNB and HNB where UP ciphering terminates inside HNB.

Description: an attacker purchases H(e)NB, installs it, and configures it to the open access mode. Victim is using normal air interface network, but camps to this H(e)NB without knowledge. All data, flowing between the victim and the network, could be read. The difference with Threat 9 is that that in 9 the ‘attacker' only listens, while in threat 10 attacker also injects spoofed traffic.

Threats to assets:

  1. Threats to H(e)NB: The threats of physical tampering are described in Threat 8.
  2. Threats to user: Attacker can eavesdrop the victim's data or spoof calls from H(e)NB towards core network masquerading as victim without his/her knowledge. In LTE spoofing calls might be difficult due to NAS security between UE and MME, but spoofed calls would be possible in 3G if encryption function has been collapsed into HBTS/HNB. Even if spoofed connection set ups are not possible in LTE, then packet injection type attacks would still be possible even with NAS security in place.
  3. Threats to operator: --.

Probability: Possible, but probably more difficult than eavesdropping threat.

Impact: (very) harmful. Ability to spoof 3G/LTE calls would have serious and wide-ranging impacts. If the H(e)NB works in an open mode, the impact of the attack is worse since the attacker could eavesdrop any mobile terminal, not just those authorized to use the H(e)NB.

Mitigation: Unprotected user data should never leave a secure domain inside H(e)NB. The user could be notified when the UE camps on a closed or open type H(e)NB. User could be notified (or give his/her explicit acceptance) when he/she is added to the access list of a closed H(e)NB.

NOTE: The H(e)NB can work in open access mode, closed access mode and hybrid access mode.

11) Changing of the H(e)NB location without reporting

Description: Customers may relocate the H(e)NB and make the provisioned location information invalid.

Probability: Very likely.

Impact: Harmful.

Threats to assets:

  1. Threats to H(e)NB: None
  2. Threats to user: Emergency call from such H(e)NB cannot be reliably located, or routed to correct emergency centre. This also violates governmental requirements in some counties.
  3. Threats to operator:
  • Frequency planning of other operators may be affected in the new place. In some countries, operators are mandated to report all emitters at certain frequencies to authorities.
  • o Lawful interception position reporting becomes impossible.
  • o Revenue leakage as customer may get preferential call rates even when outside their authorized home/office zone. The would especially be a problem if H(e)NB is taken to another country.

Mitigation: Location locking mechanism shall be designed and implemented. If a removable token-based approach is used for authenticating the H(e)NB (case 3 or 4), it may be easier for an attacker to benefit from a weak or non-existent location locking mechanism.

12) Software simulation of H(e)NB

Description: The communication of the H(e)NB with the core network is simulated by a software application running on a computer connected to the home network, with or without the user's consent.

Probability: Probably low, depending on the strength of the authentication of the H(e)NB with the Core network and on the measures to prevent removal/cloning of the authentication token, but if the token is removable, even by hardware manipulation, a legitimate H(e)NB owner could deliberately perform this attack.

Impact: Very harmful.

Threats to assets:

  1. Threats to H(e)NB: Operator could bar misbehaving simulator potentially also affecting the genuine H(e)NB.
  2. Threats to user: If H(e)NB simulation software runs without the users' consent, the internet connection of the user could maliciously abused by an attacker.
  3. Threats to operator: (if fraudulent user runs the simulation intentionally)
  • Simulated H(e)NBs can easily be cloned or carried to other locations. Lawful interception position reporting becomes impossible.
  • o Revenue leakage as customer may get preferential call rates even when outside their authorized home/office zone.
  • Denial of service attacks could be carried out.

Mitigation: As software simulation cannot be prevented, is it necessary to enforce strong H(e)NB access authentication and to prevent removal/cloning of the authentication token..

13) Traffic tunnelling between H(e)NBs

Description: A H(e)NB is used at a legal location but with (additional) traffic from one ore more different, not legal locations. The illegal additional traffic is tunnelled via internet to the legal H(e)NB.

Probability: Unclear.

Impact: Very harmful.

Threats to assets:

  1. Threats to H(e)NB: Overload conditions may appear
  2. Threats to user: If traffic tunnelling takes place without the users' consent, the H(e)NB of the user could be maliciously abused by an attacker.
  3. Threats to operator:
  • Calls or data traffic can originate from any location. Lawful interception position reporting becomes impossible.
  • Revenue leakage as customer may get preferential call rates even when outside their authorized home/office zone.

Mitigation: H(e)NB should be able to detect traffic that does not originate from locally connected UE. One countermeasure is to enforce that only authenticated UE is allowed to be used with the H(e)NB.

14) Misconfiguration of the firewall in the modem

Description: Home access point (like H(e)NB) are normally connected to the Internet via some wired access (e.g. ADSL, cable modem). In these cases, a modem/router could be integrated with the H(e)NB, or be in a separate box. Firewall in the modem/router normally is controlled by the user via some web interface. But the H(e)NB requires defined network services (such as TCP or UDP ports) to communicate with a GW of the core network. These services being closed prevent the H(e)NB from connecting to the operator's network. If the modem is not integrated with the H(e)NB, user shall configure it properly, which is error-prone.

Probability: Possible.

Impact: Annoying, mainly service reliability and usability degradation.

Threats to assets:

  1. Threats to H(e)NB: --
  2. Threats to user: Denial of service. If emergency calls are prohibited, the impact could be life-threatening.
  3. Threats to operator: --

Mitigation: In case when the modem/router is integrated with the H(e)NB, it shall have pre-defined and not changeable configuration of the H(e)NB access channel. In case when the modem is a separate box, its correct configuration shall be enforced. One possible approach may be using uPnP mechanism. An additional firewall within the H(e)NB would also be useful.

NOTE: It should be clarified under which conditions emergency calls are allowed via close/open H(e)NBs (SA1).

15) Denial of service attacks against H(e)NB

Description: attacker organizes (probably distributed) denial of service attacks against H(e)NB.

These attacks can fall into three categories:

  1. Layer 1-3 attacks (e.g. ARP, IP related)
  2. Layer 4 attacks (e.g. TCP, IGMP, UDP)
  3. Layer 5-7 attacks (e.g. Any application layer protocol supported by the H(e)NB).

Probability: Possible.

Impact: Annoying. H(e)NB is not vulnerable to denial of service attacks more than any IP device on the Internet. When the IP-level cryptographic protection of the S1/Iu-link is used, DoS traffic (which is assumed to be unauthenticated) is filtered out already at the authentication phase.

Threats to assets:

  1. Threats to H(e)NB: ---
  2. Threats to user: denial of service
  3. Threats to Operator: ---

Mitigation: H(e)NB is partially relieved from the processing load if a firewall at the modem is present, and configured to pass only IKE negotiations and ESP-encrypted traffic to the H(e)NB. We note that IKEv2 (when used on e.g. S1 or X2) is more robust against DoS attacks than IKEv1.

16) Denial of service attacks against core network

Description: attacker organizes (probably distributed) attacks against elements in the core network from (multiple) H(e)NB(s) or from the backhaul link. The types of threats at all layers are described in threat #15 above. In addition, there are following two categories of threats that can be directed to the core network that would not get directed at the H(e)NB:

1. IKEv2 attacks that can be mounted against initial establishment of the IKEv2 tunnel between the H(e)NB and the Security Gateway. These types of attacks can include:

  • IKE_SA_INIT flood attack
  • IKE_AUTH attack
  • Flood of legitimate tunnels attack (exhausting resources on the Security Gateway)
  • Malformed IKE_SA packets
  • Malformed authentication credentials

2. Layer 5-7 volume attacks and IKEv2 volume attacks in situations during which a high volume of signaling traffic or IKEv2 tunnel setup traffic overwhelms the infrastructure within the H(e)NB network. Some of the different events that may cause these spikes in traffic volume include:

  • power outages and brownouts
  • misconfigurations of core layer 2 and 3 network devices
  • mass calling events as a result of activities such as interactive Media Events, or natural disasters
  • H(e)NB software upgrades that contained signaling bugs such as more frequent registrations or additional security tunnel setup attempts (even a small percentage of H(e)NB software upgrades with bugs could affect an entire H(e)NB population)

These types of legitimate traffic spikes could induce the following resultant behavior (dependent on particular solution which is chosen finally):

  • IPsec tunnel terminator signaling overload: too high rate of IKEv2 signaling packets
  • AAA server overload: too high rate of requests from the IPsec tunnel terminator in case USIM based H(e)NB authentication would be chosen.

Probability: Possible: Very likely for a compromised H(e)NB, unlikely otherwise.

Impact: From annoying to extremely harmful. The operator's service can be disrupted across a large number of H(e)NBs. Note that when the IP-level cryptographic protection of the S1-link is used, DoS traffic from unauthenticated hosts is filtered out already after the authentication phase. Only compromised H(e)NBs with valid authentication credentials can start acting as DDoS bots.

Threats to assets:

  1. Threats to H(e)NB: --
  2. Threats to user: DoS as consequences of operators networks DoS
  3. Threats to operator: denial of service and loss of revenue

Mitigation: Core network elements that shall be secured include:

  • Security gateway as first context point in the core network (assume that HNB gateway for Iu concentration architecture coincides cfr RAN3)

The core network elements shall be protected against mentioned security threats.

? For layer 3-7 volume attacks, the Security Gateway shall be remain available in the event that a high rate of IPsec IKEv2 signaling messages are handled by the Security Gateway. The Security Gateway shall protect the upstream network from overload and overflow conditions.

17) Compromise ofan H(e)NB by exploiting weaknesses of active network services.

Description: H(e)NBwill usually have several network services (protocol handlers) listening on its network interface(s). Theseservices may be required for operation (e.g. DHCP, IKE, IPsec, PPPoE), or they may belistening due to the device's design (e.g. RPC portmapper).Specifically crafted attack traffic injected via the backhaul network or the local connection may cause protocol handlers to fail, and subsequently compromise the whole H(e)NB.

Probability: Possible.This is the most prevalent type of remote attack in IP networks.

Impact: Extremely harmful. Possibility of very powerful distributed attacks if many H(e)NB are impacted.

Threats to assets:

  1. Threats to H(e)NB: Adding non-official software may cause non-optimized functioning of the H(e)NB.
  2. Threats to user: eavesdropping on communication, impersonation towards the network.
  3. Threats to operator: attack on the radio interface (jamming), denial of service possibilities. Attacks directed against the Core Network or Management Centres.

Mitigation:Minimised network services (disabled or firewalled), robustness testing for functional protocol handlers, intrusion detection looking for abnormal H(e)NB behaviour, regular reset to a securely verified system state.

18) User's network ID revealed to H (e)NB owner

Prerequisites: The owner of a H(e)NB is able to add / delete users to / from the to the H(e)NB related Closed Subscriber Group (CSG).

Description: IMSI may be revealed to the owner of the H(e)NB during CSG management.

Probability: High

Impact: Breaking users privacy

Threats to assets:

  1. H(e)NB: none
  2. Users: Privacy issue
  3. Operator network: none (tracking of subscribers may be possible)

Mitigation: A link between IMSI and owner given user ID is stored in the network or secure stored in H(e)NB.

Editor's Note: The users privacy solutions should not interfere with the identity confidentiality mechanisms provided by the core network.

19) Mis-configuration of H(e)NB

Prerequisites: The attacker has access to the H(e)NB configuration. Access can be both wired or wireless.

Description: Having access to the H(e)NB configuration the attacker can either get hold of the complete H(e)NB or can make some configuration changes that will impact the service being provided by the H(e)NB. Possible attacks and their impact are dependent on the amount of configuration possible at the H(e)NB thus many things are possible, e.g., traffic forwarding.

Probability: Depending on implementation and deployment

Impact: Irritating to harmful

Threats to assets:

  1. H(e)NB: Modification of the configuration leading to different issues including malfunctioning and denial of service.
  2. Users: From privacy and confidentiality issues to DoS attacks
  3. Operator network: If the attacker succeeds in traffic forwarding then it could potentially also cause some form of DoS attack on the network.

Mitigation: Secure access to configuration of H(e)NB is needed.

20) Mis-configuration of access control list (ACL) or compromise of the access control list

Prerequisites: The attacker has access the ACL (which includes CSG list). This can be either by knowing the administrators password or by physical access to the H(e)NB.

Description: The attacker modifies the ACL thus allowing devices that should not have access to the network. Attacker could also remove devices that should have access and possibly change the level of access for different devices.

Probability: Depending on implementation and deployment

Impact: Irritating to harmful

Threats to assets:

  1. H(e)NB: Modification of the ACL..
  2. Users: Potential DoS attack or change in access rights
  3. Operator network: Free service could be provided to some users if the billing is H(e)NB based.

Mitigation: Secure means of creation, maintenance and storage of ACL is required.

21) Radio resource management tampering

Prerequisites: The attacker has access to the H(e)NB and can modify the resource management aspects of the H(e)NB, at least the attacker should be able to tamper with the power control part of the H(e)NB. Changes could be made by configuration of the H(e)NB or by external means, e.g., increasing the interference or noise.

Description: The H(e)NB gives radio resource information that is incorrect thus leading to issues like increased handover, handover of all mobiles in the vicinity to the H(e)NB or forced handover of all devices from H(e)NB to other (e)NBs. The radio resource information could be simply in the form of the transmit power level. The attacker could perform simple modification like range extension adding signal booster to antennas leading to increased interference, increase in range in which cheap rate applies etc.

Probability: Possible

Impact: Potentially harmful

Threats to assets:

  1. H(e)NB: Modification in H(e)NB radio behaviour
  2. User: Potential denial of service
  3. Operator network: Could lead to frequent handover (ping-pong). Provisioning of service increased area than planned leading to monetary loss. Potential disruption of H(e)NB services.

Mitigation: There should be no means to control the radio resource related parameters by a user. The configuration interface of the H(e)NB must have adequate security. It will be difficult to provide protection against range extension.

22) Masquerade as a valid H(e)NB

Prerequisites: The attacker should have a H(e)NB and be able to configure the H(e)NB such that users of a given CSG will join it.

Description: The attacker buys a H(e)NB and configures it similar to that of a H(e)NB of a CSG. Having done that the attacker (1) changes the setting in the H(e)NB to no encryption and integrity level or (2) 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.

Probability: Depending on implementation and deployment

Impact: Very harmful

Threats to assets:

  1. H(e)NB: none
  2. User: Privacy issues, confidentiality issues, monetary issues and DoS
  3. Operator network: Having the user keys the attacker can perform different attacks one of them could lead to mis-charging of the user.

Mitigation: CSG setting and other configuration should be hidden. 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 case of key leakage requires that the keys in a H(e)NB is stored in a secure location.

23) Provide radio access service over a CSG

Prerequisites: The attacker has a H(e)NB and valid connectivity to a CSG.

Description: There can be different ways in which the attacker can work (1) connect the H(e)NB to one of the H(e)NB in the CSG using Ethernet cable (2) the attacker has a UE (mobile or data card) connected to its H(e)NB belonging to the CSG that by some means is connected to the attackers H(e)NB (or other radio like 802.11 access point). This can be easily achieved by the attacker connecting a UE and an access point to a laptop. The attacker can then do several attacks some of them similar to that described in attack “Masquerade as a valid H(e)NB” and other being the provisioning of free service over the H(e)NB belonging to a CSG.

Probability: Depending on implementation and deployment

Impact: Depending on implementation and deployment

Threats to assets: Same as “Masquerade as a valid H(e)NB”.

Mitigation: Radio layer forwarding is difficult to mitigate. They might require RF fingerprinting. Network layer forwarding attacks require similar mitigation as the following threat.

24) H(e)NB announcing incorrect location to the network

Prerequisites: The intruder is in position to modify the H(e)NB or to mis-inform the H(e)NB regarding its location. Further the H(e)NB is expected to work only at a given location.

Description: The attacker either changes the location information of a H(e)NB or is in position to mis-inform H(e)NB regarding its location. Thus a stolen H(e)NB could be used in unwanted place.

Probability: Possible

Impact: Harmful especially for emergency call services.

Threats to assets'

  1. H(e)NB: Manipulation in the form of mis-informing the location
  2. User: Users might have no service in primarily expected location. Emergency calls might be routed to the wrong location.
  3. Operator network: Provisioning of services meant for different location with potential impact on revenue.

Mitigation: Secure location solution is needed.

Requirement: It should not possible to manipulate location information of a H(e)NB. Secure location functions which are supported in the H(e)NB could be preserved by the Trusted Environment.

25) Manipulation of external time source

Prerequisites: H(e)NB shall perform time synchronization based on an external time source. The time source is either a surrounding macro cell from the same or alternative trusted network and/or a clock server located in an independent network and accessed via the Security Gateway. It should be noticed that a clock server located in an independent trusted network is needed anyway since the H(e)NB may be deployed outside of a macro cell coverage area.

Description: An attacker can tamper with the procedures for time synchronization of the H(e)NB in order to make the H(e)NB perform incorrectly. An attacker can install a false macro cell near the victim H(e)NB and force it to perform time synchronization based on the false macro cell. The attacker can also perform an attack on the insecure link between the H(e)NB and the clock server located in the fixed network.

Attacker can mount an attack on clock function in the H(e)NB directly or indirectly via insecure link between H(e)NB and clock server. The effect of the attack is prevention of timing functions from performing correctly and mis-synchronization that may in turn cause other ill effects.

Probability: Unlikely

Impact: Harmful

Threats to assets:

  1. Threats to H(e)NB: H(e)NB can not work without clock information. Wrong clock information will incorrectly set the timing of the H(e)NB and which may force it to perform operations, e.g. handover operations or use of expired/revoked digital certificates used for authentication..
  2. Threats to user: UE camped on H(e)NB with wrong clock information will experience a low quality of service. e.g. timing synchronization or handover operations.
  3. Threats to operator: Low quality service is provided to the user. A clock server suffering attack will affect macro cells or H(e)NBs which perform time synchronization based on it.

Mitigation: H(e)NB should be notified about information of macro cells from which the H(e)NB can obtain clock information so that it can perform time synchronization based on particular macro cell. A trusted clock server should be located behind the security gateway and communication between the clock server and H(e)NB should have adequate protection. Secure clock synchronization and maintenance functions which are supported in the H(e)NB could be executed within the Trusted Environment.

26) Environmental/side channel attacks against H(e)NB

Prerequisites: The attacker is able to change environmental influences like power supply, temperature or communication link of a H(e)NB.

Description: H(e)NB security mechanism may be circumvented or security lowered

Probability: Possible

Impact: harmful

Threats to assets:

  1. H(e)NB: Environmental attacks may introduce some degradation of H(e)NB lifetime
  2. Users: Confidentiality and privacy issues
  3. Operator network: Integrity and confidentiality issues

Mitigation: Environmental attacks robust Implementation; monitoring of power supply, temperature, data connection

27) Threat: Attack on OAM and its traffic

Prerequisites: The intruder has access to the OAM - H(e)NB communication link.

Description: The operator can decide to connect the OAM to the H(e)NB via the SeGW or directly.

If OAM is inside the operator network then the issues and solutions for the link between H(e)NB and SeGW will be the same as for any communication and is already discussed in this TR. There could be other threats instead (a) there would be possibility of insider attacks on the path from the SeGW to OAM, where management protocols are unprotected and (b) here we have a protocol implementation related issue: OAM interfaces usually do not rely on a single function. They usually bring 4-10 different protocols inside the box: for fault management, command line, web GUI, configuration management, firmware download, SW license checking, some 3rd party interfaces. Even if all of them would be cryptographically secure, there would still be the issue of implementation robustness. Even (cryptographically) “secure” protocols will have flaws that can compromise the system. The more of them are accessible (aka "open ports") via the backhaul network, the higher the risk.

When the H(e)NB is directly connected to the OAM then the intruder can have access to the communication link between the OAM and H(e)NB thus it can perform different attacks like (a) sniffing the traffic, (b) man-in-the-middle attack (c) mis-configuration of the H(e)NB etc.

Impact: very harmful.

Threats to assets:

  1. Threats to H(e)NB: Potential denial of service or modification of configuration
  2. Threats to user: Depending on attack on the H(e)NB itself, different threats are possible on the user.
  3. Threats to operator: OAM could be attacked by the intruder that itself could be a major issue. H(e)NB service failure is also a threat for the operator.

Mitigation: The communication between the H(e)NB and the OAM should be secured.

28) Threat of H(e)NB network access

Prerequisites:

The H(e)NB SeGW or other network entity in the core network has no or can't obtain the profile information, e.g. access control information of the service domain for H(e)NB, or the state information of the H(e)NB, to check whether the H(e)NB can access the network.

Description:

Whether a H(e)NB can access the network will depend on the acquired status information of enable or disable the H(e)NB from the network entity (e.g OAM Server). But for a rouge H(e)NB, it can attempt connect to the network even if the status information of the H(e)NB is set to disable. If there is no such information (e.g. access control information of the service domain for H(e)NB, or the state information of the H(e)NB) in H(e)NB GW or other network entity to check the access right of the H(e)NB, the rouge H(e)NB can gain the network accessibility.

Impact: Harmful

Threats to assets:

  1. Threats to H(e)NB: --
  2. Threats to user:
  • the attacker could eavesdrop or spoof any mobile terminal that camped on the H(e)NB.

Editor's note: The threat to user needs to be verified.

3) Threats to operator:

  • Free service could be provided to the users camped on the H(e)NB if the billing is H(e)NB based.
  • An attacker could use the obtained authorization to try to mount further attacks towards the core network.

Mitigation: H(e)NB SeGW or other network entity in CN should have or can obtain the related profile information, e.g. access control information for H(e)NB, or the status information of the H(e)NB, to check whether a H(e)NB can access the network when it attempts to access the network.

Editor note: Detail of mitigation should be added.

29) Handover to CSG H(e)NBs

Prerequisites:

User can change the Allowed CSG List stored in the UE.

Description:

Handover decision is taken by the radio network while the Allowed CSG List is stored in the UE and access control is done in the core network or the H(e)NB Gateway. Thus it is possible for a rogue UE to perform handover to a H(e)NB with a given CSG ID, to which it does not belong to, by simply modifying the Allowed CSG list. This can be an issue particularly for the case where the handover has to happen for an on-going session because for such case access control might not be performed.

Probability: High

Impact: Harmful.

Threats to assets:

  1. Threats to H(e)NB: None
  2. Threats to user: The H(e)NB owner might end-up paying the charges for the rogue user.
  3. Threats to operator: Such usage could mean that the operator cannot charge anyone for the service used.

Mitigation: Even on handover the network should check whether the given UE is allowed to access the target H(e)NB.

6 Security Requirements

6.1 Common Requirements for Femtocell

Based on this threat analysis, the security requirements for Femtocell can be summarized as follows:

  1. Only strong authentication algorithms shall be used for (Threats 1, 12).
  2. Link protection mechanism between the Security Gateway and the Femtocell shall be of adequate cryptographic strength. All traffic shall be integrity protected and should be confidentiality protected. (Threat 1, 5).
  3. Femtocell authentication credentials shall be stored inside a secure domain i.e. from which outsider cannot retrieve or clone the credentials (Threats 2, 3, 4, 12).
  4. The UE should indicate to the user when it camps on Femtocell. User should be notified (or give his/her explicit acceptance) when he/she is added to the access list of a closed Femtocell (Threats 3, 4, 9, 10).
  5. Femtocell and the Security Gateway shall mutually authenticate each other, including the first initial contact (Threat 1, 5, 12).
  6. The booting process of the Femtocell shall be additionally secured by cryptographic means (Threat 6).
  7. Software updates and configuration changes for the Femtocell shall be cryptographically signed (by operator or Femtocell supplier) and verified configuration changes shall be authorized by Femtocell operator or supplier (Threat 7).
  8. Unprotected sensitive data should never leave a secure domain inside Femtocell (Threats 8, 9, 10).
  9. It shall be possible for the operator to lock the Femtocell service to a specific geographical location. It shall be possible to disable the Femtocell if it has been detected to be located at an unauthorized location. (Threat 4, 11)
  10. UE's shall, unless performing an emergency call, be authenticated and authorized by the user home network before receiving service from the Femtocell (Threat 5, 13).
  11. The security solution shall be compatible withcommon network address and port translationvariations, as well as support firewall traversal (Threat 14).
  12. Unauthorized traffic shall be filtered out on the links between the Security Gateway and the Femtocell (Threats 15, 16).
  13. Femtocell should be run with minimised network services (disabled or firewalled), and test regular for a securely verifiable system state (Threat 17)
  14. Access to Femtocell remote management interface by the operator, shall require authentication and authorization and shall not allow modification to user controlled information unless the user gives their permission (Threat 19).
  15. ACL (Access Control lists) should be created and modified by authorized party only (Threat 20).
  16. The operator shall have means to control the CSG configuration (Threat 22).
  17. It shall not be possible to override the operator's policy at a Femtocell (Threat 23)
  18. It shall not be possible to manipulate location information of a Femtocell (Threat 24).
  19. The authentication credential(s) of each Femtocell shall be unique (Threat 5).
  20. A mechanism shall be provided to restrict the number of simultaneous connections between a specific Femtocell identity and the Femtocell home Network. (Threat 4)
  21. Only authorized end-users shall be able to request modifications to membership of the Closed Subscriber Group. Operator checks those requests and implements changes if accepted. Only the Femtocell operator shall be able to enable “open mode” (if supported). (Threat 3, 4, 9, 10)
  22. Enforcement of Femtocell access to Closed Subscriber Group members shall not rely solely on access control methods implemented within the Femtocell itself. Instead the core network shall be able to check that only mobile users in the relevant Closed Subscriber Group can access services via a specific Femtocell. (Threat 12)
  23. Access to Femtocell local management interface by the Femtocell owner if allowed by the operator, shall require authentication and authorization and shall not allow modification to operator controlled information, e.g. Femtocell licensed radio interface parameters. If the operator allows local management access by the Femtocell owner, The Femtocell owner shall be able to select the authorization password. (Threat 6, 7, 21)
  24. Femtocell enclosure should provide indication of physical tampering (e.g. visual or audible). (Threat 8)
  25. IMSI of users connected to Femtocell connected users must not be revealed to the Hosting party of the Femtocell (Threat 18)
  26. a. Communication between time server and Femtocell should be provided adequate protection. (Threat 25)
    b. The TrE should be able to verify both freshness and integrity of time information from the network. (Threat 25)
    Editors Note: Addition of requirement 26b is FFS. This requirement needs to be revisited once the TrE definition is agreed.
  27. The implementation of a Femtocell must be robust against Environmental attacks (Threat 26)
  28. Confidentiality and integrity protection shall be provided to OAM traffic between Femtocell and the OAM Server in the operator network (Threat 27).
  29. OAM server and/or operator network should be able to assess the trustworthiness of the Femtocell's state and its capabilities for secure communication with OAM (Threat 27).
  30. IMSI request over the air in clear (without encryption) should only be performed when no other means are available to fetch UE identity (Threat 18).
  31. The Femtocell SeGW or other network entity in CN should obtain the related profile information to check whether the Femtocell can access the network. (Threat 28)
  32. Access control should be performed even during handover. (Threat 29)

6.2 Specific Requirements for HeNB

3GPP TS 33.401[15] introduces in clause 5.3 general security requirements for all types of eNBs. These are basic requirements which shall be fulfilled by all types of eNBs. Thus this document has to consider all requirements given in that clause and more detailed in clauses 11, 12 and 13 of [15] for eNB security. leaves it explicitly to other documents to specify more stringent requirements, if seen appropriate there. Thus this reference to [15] does not restrict the current document, as long as all requirements of [15] are still kept.

NOTE: To avoid duplication of text from [15] in this document, the detailed requirements of [15] are not repeated here.

6.3 Countermeasures for Femtocell

Based on these requirements, the countermeasures can fulfil the requirements can be summarized as follows:

  1. Mutual authentication and Security tunnel establishment mechanisms
  2. TrE of Femtocell
  3. Access Control mechanisms
  4. Location Locking mechanisms
  5. Clock Synchronization Security mechanisms
  6. Security mechanisms for OAM
  7. Protections mechanisms for Environmental Security of Femtocell
  8. User authentication mechanism
  9. HPM authentication (If used)