8.2.1 Cyber‐attacks

The term ‘cyber‐attack’ is very broad and may include all kinds of security breaches. There are thus many definitions for the topic such as the Tallinn Manual on the International Law Applicable to Cyber Warfare which describes one of the key statements for a cyber operation so that it is reasonably expected to cause injury or death to persons or damage or destruction to objects [27]. Furthermore, Ref. [27] states that the broad spectrum of cyber‐attacks could include intrusion, surveillance, recording of data, espionage, extraction, destruction and manipulation of data, theft of intellectual property, control of devices and systems, kinetic effect through control of devices, destruction of devices, property and critical infrastructure, individual lethal effect and operations with national impact.

The cyber‐attack can be categorized into three elements: intelligence (for gaining access, executing a cyber payload, and understanding the target environment); cyber weapons (typically target‐specific and activated under specially planned conditions); and calculated human decision. The combination of these elements form a cyber force.

From the human point of view, there are two types of consequences from the cyber‐attack: those that are nonviolent yet impact on the functions of the information society (so‐called virtual destruction and disruption); and those that lead to physical death and destruction. As an example of a cyber‐attack from 2010, the Stuxnet virus infected targeted nuclear centrifuges resulting in them accelerating and self‐destructing. This case is a concrete example about the attacks that destruct information storages permanently. Ref. [27] summarizes the cyber‐attack as a deliberate projection of cyber force resulting in kinetic or non‐kinetic consequences that threaten or otherwise destabilize national security; harm economic interests; create political or cultural instability; or hurt individuals, devices or systems.

As NATO has reasoned, there are three dimensions to cyber threats: confidentiality, integrity and availability of data. Confidentiality refers to the aim of protecting sensitive data. Confidentiality breaches are assumed to be the most common form of cyber‐attack. There are many examples about stolen secret data in the defence force domain, which impacts on the strategic side as information about plans and equipment is discovered, and facilitates the opposing side to upgrade their own equivalent solutions [30].

As the role of wireless systems is increasing, cyber‐attacks can be expected to concentrate increasingly on the radio access networks such as mobile communications and wireless local area networks, as well as on the low‐protection, cheap IoT devices that are the most attractive targets since they are typically innocent‐looking, small objects that may open important security holes, not only in the home and company environment but also in highly strategic locations.

8.2.2 Radio Jammers and RF Attacks

The old method for destruction of radio communications is based on deliberate interference, e.g., in the form of radio jammers. A simple variant of this category is any radio transmission which is set to function on the same radio frequency as the targeted communications or functionality. The directive antennas can be used to focus the transmission and/or reception – the basic principle being that a sufficiently high interference level (I) compared to the useful carrier signal (C) lowers the ‘readability’ of the contents as the system‐dependent C/I ratio is pushed under the functional limit. An example for the still functional C/I for the full‐rate voice codec of the GSM is +9 dB while the widespread CDMA signal, functional under the noise level, is more tolerant against narrow‐band interference sources.

Historically there have been practical cases about radio communications used for interference, both for destruction as well as for protection purposes. A fascinating example of the latter is from the era of the Continuation War in the city region of Vyborg where the Finns learned that the radio‐controlled mines equipped with battery‐powered receivers were the reason for mystical explosions in 1941. The reverse engineering of an unexploded sample indicated that the mines were designed to activate as soon as the accompanied receiver captured a three‐note chord broadcast on the pre‐defined radio frequency which resulted in three individually designed tuning forks to resonate and trigger the explosion. Once the experts resolved the principle of the mines, the Finnish national radio broadcasting company started to transmit spectrum‐rich contents in the form of Säkkijärvi polka by Viljo Vesterinen at the same operational frequencies of the mines, aiming to deliberately interfere the activation procedure. This continuous transmitting of the RF interference functioned as a protection mechanism to prevent the resonating and further explosions, until the rest of the mines were found and deactivated [28,31].

At the other extreme, the interference can be based on a high power RF pulse that effectively destroys part of the electronics, the chips being highly vulnerable, and thus damaging the communication and other equipment. Modern chips may be especially sensitive to these EMP attacks [29]. The EMP can be very directive within a broad spectrum. In addition to the strong RF emission, the pulse can also be caused by a nuclear explosion close to the targeted electronic devices, the most severe damage happening above the area. Not only on Earth (e.g., via nuclear missiles) but also the EMP can take place, e.g., between satellite equipment causing wide damage over the wireless and fixed communications networks relying on the satellite component. Satellite communications as such may be encrypted depending on the environment, and the protection level depends on the strength of the respective algorithms [22].

RF and EMP threats are relevant not only to the highly specialized environments as described above but also the interferences may be present in daily wireless networks, often unintentionally. A typical example of this is the utilization of various devices in unlicensed frequency bands, the signalling and communication devices generating inter‐system and intra‐system load and thus incrementing the respective interference level.

8.2.3 Attacks against SEs

In addition to SW‐based attacks, there are physical means that aim to reveal the contents and functions of the HW such as memory elements and SEs. The methods can be based on the analysis of the data responses and respective electrical behaviour at chip level by observing the behaviour of the equipment with an electron microscope, or by executing a power consumption analysis. These may expose some internal crypto‐processor’s internal results for injected input data which might help in revealing the embedded and protected data such as user keys. Respective protection mechanisms have been designed, e.g., for the SIM/UICC environment to minimize the exposure of the internal card’s signalling to such intentions.

8.2.4 IP Breaches

There are plenty of ‘traditional’ IP network breaches like viruses and malware familiar from the fixed Internet but relevant also in the wireless environment. The security breaches and attack types are comparable to the overall Internet security vulnerabilities, but the interfaces, devices and interfaces are also related to the mobile communications – both in radio interface and in the core and transmission networks. One trend, along with the enhanced network and system security of the mobile communications networks, is that the attacks are focusing increasingly on the application level of the user devices. Thus, even if the wireless device’s application delivery ecosystem includes security protection mechanisms with security assessment and in‐depth testing, there have been examples of hidden security holes that have been utilized against the user equipment. The topic is complicated as the applications may request wide privileges to access user data even if the nature of the functionality of the applications might not benefit from those as such – it is thus largely up to the end‐users to consider how much data is exposed to the apps.

8.2.5 UICC Module

Regardless of the relatively long age of the SIM card and its enhanced variants, it still serves as a functional base for the protection of mobile communications for voice calls, signalling and data transfer, as well as for respective data storage, authentication, authorization and other procedures used in the mobile networks. The additional benefit of the UICC is that it provides an existing platform for multiple applications that can be managed and used via the same single user interface which nowadays is typically a smart device or some other variant of advanced equipment.

The most concrete threat against the UICC is the physical HW attack in order to reveal the contents of the card, like user data and keys that are permanently stored on the card. Some examples of such intentions include attacks against network elements, core network interfaces and applications. Especially for the latter, along with the growth of smartphones and the popularity of applications, the intentions for malicious SW increases.

There are also electromagnetic methods as well as localized, embedded eavesdropping smartcard methods like the one discussed in Ref. [32] which presents a combined attack tampering principle with the APDU buffer. The secure channel concept provided by the GlobalPlatform ensures the confidentiality and integrity of the communications between the terminal and card through cryptographic mechanisms. Nevertheless, the described attack results in accessing the APDU buffer array based on the fact that the APDU buffer is not meant only for the communication channel between the card and the terminal. More specifically, Ref. [32] details that the specifically developed re‐startable task works as a tool for breaking the secure channel by knowing the initialization of a secure channel which is based on APDU commands INIT UPDATE and EXT AUTHENTICATE, and specific CLA and INS bytes. Ref. [32] claims that the eavesdropping may be focused by detecting the beginning of the secure channel session based on these commands. The deciphering (ciphering) and MAC checking (computing) of an incoming (outgoing) APDU is operated thanks to a call to a known method of the secure channel interface. If this method is called with the APDU buffer array as parameter, the attacker owning the re‐startable task is now able to both eavesdrop and corrupt the communication.

As can be reasoned from the above description, this method requires physical access to the smartcard. Furthermore, the exposure of IoT devices will be much wider for potential hacking attack intentions, the eUICC also provides a security benefit due to its fixed installation. As Ref. [8] states, the eUICC delivered to the end‐user is embedded onto the device, and for this reason the end‐user does not have a direct interface to it. Ref. [8] has also identified a variety of security risks against the eUICC and respective protection mechanisms. As a summary, Ref. [8] concludes that an off‐card actor or on‐card application may try to compromise the eUICC by trying to perform unauthorized profile management, e.g., by altering profile data before or after installation, or unauthorized platform management, e.g., by aiming to disable an enabled profile. Ref. [8] defines a protection profile which covers these threats by defining security domains (SDs) so that the data and capabilities associated to an SD are accessible only to its legitimate owner. There are also various other threats identified, including physical tampering and cloning intentions as well as potential network algorithm flaws, to which the protection profile provides adequate shielding. The protection profile also tackles the known physical attacks such as side‐channel analysis to leak the protected keys and fault injection to alter the behaviour of the target evaluation. The protection profile includes security objectives for the underlying IC, which ensures protection against physical attacks. More details about the GlobalPlatform’s identified threats and shielding can be found in Ref. [8].

8.3.1 Potential Security Weaknesses of GSM

When the GSM system specifications were developed in the late 1980s and the first commercial networks were launched as early as 1991, the security threats were not seen as too significant. Thus, the enhanced security that GSM provided compared to the already existing fixed network was more than sufficient at that time [7].

Nevertheless, novelty attack methods have been developed during the course of time. Even if GSM authentication and authorization are still highly secure especially with the most updated radio interface encryption algorithm A5/4, there is a potential threat that someone may create a false BTS close to the GSM user [4]. If the network ID selected is identical to the one used by the user’s home operator, and if the spoof BTS radio signal level is sufficiently high, the fraudulent BTS may capture the calls in the initial phase of the call in such a way that the encryption is forced off – as it is the network that decides the selection of the algorithm, the user may only see a symbol on the display indicating that the encoding is not utilized. If the user continues with the call initiation, the actual delivery of the contents may be relative straightforward by applying a proper relying solution for reaching out to the originally intended receiving party (B‐subscriber) while the fraudulent BTS operator can eavesdrop the communications of that compromised connection.

The GSM provides a good level of security for the access network especially with modern encryption algorithms. Nevertheless, while the radio interface is encrypted, the communications path between the base station and the rest of the fixed network is not protected by default. The original assumption of the GSM system is that the end‐to‐end communication is at least as secure as the fixed telephony network (which is not protected as it is assumed to be isolated from external attacks). The radio encryption equipment is located at BTS sites, which means that the communication may be possible to eavesdrop, e.g., via unprotected radio links within the GSM network as long as the eavesdropper finds the link and can apply the respective protocols for revealing the contents. Also, the old‐fashioned signalling system of the core network may be vulnerable exposing possibly authentication and encryption‐related information.

The deployment of the first GPRS networks during the early 2000s was a significant step towards an all‐IP concept that helped overcome issues of the ‘old‐fashioned’ circuit‐switched (CS) data service. The CS data communications were well protected because of the highly isolated environment and as the connectivity was based on point‐to‐point communications. Then, the GPRS exposed the network to the public Internet. For that reason, a totally new planning of prevention methods was needed against the security threats familiar from the fixed Internet. As an example, unlike in CS communications, firewalls between the GPRS core and outside world were now needed with new methods for analysing suspicious utilization. Not only the eavesdropping of the data connections but also other aspects were noted to be at least equally important to tackle, including protection against DoS attacks and monetary frauds. An example of a simple DoS method is sending a big amount of GPRS PDP Context Activation requests from the Internet to the GPRS network by using imaginary mobile subscriptions of the receiving parties. Prior to the PDP context activation, the GGSN requests information about the location of the B‐subscriber to direct the connection to the correct SGSN. As the user does not exist, the signalling results in a failed connection. By repeating these false call requests, the Internet user might cause register signalling overload and prevent the delivery of other traffic. Thus, this type of activity needs to be analysed in real time by the GPRS operator at the GGSN level in order to block attempts prior to the extra signalling.

Other potential GMS security threats relate to the data integrity, which was not provided in the initial GSM networks. The altering of IMEI code might also be possible in practice, although the specifications aim to protect it. It is worth noting that the home network does not have the means to know about the principles the connected roaming networks have for their authentication and encryption. The protection for these potential security threat aspects has been enhanced in the UMTS specification.

8.3.1.1 Altering IMEI

The IMEI identifies of the HW of the mobile equipment. It is thus an integral part of the mobile device and it explicitly identifies the device and its type. Nevertheless, the IMEI does not have a direct connection with the subscriber numbering like the MSISDN or IMSI because the removable SIM cards store all the relevant subscriber information. If the mobile equipment authentication is activated in the network, the call is allowed only if the IMEI is noted to be permitted.

The IMEI code is utilized for the identification of fraudulent or stolen equipment via the EIR. The register contains white, grey and black lists. The white list contains the permitted equipment types while the grey list is used for provisionally allowed equipment. The black list contains the IMEI codes that are not allowed to be used in the network. If the equipment is found in the black list, no communication or signalling is permitted. The one exception is the emergency call which functions regardless of the black list contents.

The IMEI contains 15 digits and includes fields for the Type Approval Code (TAC) of six digits, the Final Approval Code (FAC) of two digits, the Serial Number (SNR) of six digits and the Spare Number (SP) of one digit (which is always set to 0 if the MS sends it). Furthermore, there is the IMEI Software Version (IMEISV) number, which contains the TAC, FAC and SNR fields as well as a two‐digit Software Version Number (SVN). Because the IMEI code explicitly reveals the type and commercial mark of the handset, it can be used as a basis for statistics collection by different stakeholders such as MNOs and resellers.

The IMEI is stored in each mobile equipment as well as in the EIR of the home operator. The EIR has a signalling connection with the Mobile services Switching Centre (MSC) to provide the network with the means for verifying that the mobile equipment is legitimate and allowed to communicate in the respective network. The EIR may contain a list of, e.g., non‐approved (faulty) model types, stolen or tracked devices.

The EIR is not mandatory in mobile networks. It merely provides additional means for the operators to manage the permissions of individual devices and device types in the network. As for stolen devices, the EIR may have an impact on lowering crime levels. The EIR is s only used sometimeat the national level, or it is not deployed at all in certain areas. So, even if the stolen device can be blocked in the home operator’s country, the device may work in other networks by swapping the SIM card if there is no active exchange of the list information between operators.

There also is an international version of the EIR called the Central EIR (CEIR). It collects the lists of operators connected to it via the internal packet network. It keeps the connected EIR elements updated and prevents the utilization of the stolen device in all these networks. Figure 8.1 depicts the procedure of the CEIR communications. The CEIR is maintained by the GSMA under the term IMEI Database to which the cooperating operators have access for updating and retrieving data.

The network may check the IMEI in the initial signalling as well as upon handovers and location area update procedures. The EIR is connected to the MSC via the F interface which is defined in ETSI 09.02. According to the 3GPP specifications, the IMEI should be protected against users’ means for modifications. Nevertheless, there have been cases indicating that the IMEI can be altered. Furthermore, there may be devices on the market that do not comply with the standard requirement for the unaltered IMEI, instead, they might generate random IMEIs on a call‐by‐call basis.

Despite the good intentions, the CEIR does not connect all the operator, although some operators may have direct agreements to change the black lists. What is the impact of altering the IMEI? As the name indicates, it relates to the mobile device and is able to identify explicitly the individual equipment HW. In addition to the EIR and CEIR black list functions which prevent the use of devices with non‐allowed IMEI, the operator is able to collect statistics about the IMEI distribution in the network in order to understand the share of different mobile device models as a function of region. If the IMEI of, say, a stolen device is altered, the user of such a device may try to use it regardless of the operator blocking the original IMEI. Naturally, if a certain operator does not have the EIR deployed, the device can be utilized in those areas regardless of the IMEI being on any other black lists. Nevertheless, the IMSI and respective MSISDN implicitly identify the user so there is no way of hiding the user’s identity by altering the IMEI unless the IMSI/MSISDN have been obtained anonymously, e.g., by purchasing a pre‐paid subscription without physical proof of identity or with an altered ID card.

8.3.1.3 Spoof GSM Base Station

The deployment of a spoof GSM BTS may be possible since the protocol stack of the GSM system is publicly available in the ETSI/3GPP specifications, as presented in Figure 8.2. It can thus be implemented as a simplified variant of the base station equipment by, e.g., creating a pure SW‐based emulator that is combined with a low‐power GMSK transceiver and portable antenna system. The emulator may contain only the minimum functionality for establishing the call as presented in Figure 8.3.

The BTS emulator can therefore create a local, small coverage area of a single cell which can produce higher received power levels for the mobile stations compared to the legal cells in that area. The GSM devices in the area receive the pilot signalling via the Broadcast Control Channel (BCCH) so the task is to send a copy of some of the legal network IDs (Mobile Country/Network Code, MCC/MNC) with the intention of making the GSM user device camp into that specific cell. As soon as the device has the fraudulent BCCH in the first position in the list of the strongest received cells, and when the user initiates the call, the device has no means of ensuring that the BTS is legitimate. So the device initiates the signalling by assuming that the cell is either of the home operator or a legitimate roaming cell. As an additional trick to ease the camping, it is possible to block other BCCH frequencies via radio jammers.

This trick is based on the fact that the GSM BTS does not need to encrypt the radio interface, and basically all the standard mobile devices must therefore accept the initiation of the initiated call by utilizing the A5/0 if the BTS so dictates. In this way, the spoof BTS does not need to know the Ki key of the user. Instead, the spoof BTS can behave like a real base station, acting as a simple repeater for the voice calls by intercepting the B‐number from the signalling of the A‐subscriber which is the victim, and by dialling to the B‐subscriber’s number via any known means such as Wi‐Fi VoIP or pre‐paid mobile subscription that is not attached to the identity of the spoof BTS operator. The easiest way to further hide the spoof BTS is to bar the display of the calling number for the B‐subscriber which then sees an unknown number calling. As soon as the B‐subscriber answers, the spoof BTS is able to intercept all the communications. In addition, the spoof BTS is able to intercept the normally protected A‐subscriber’s IMSI from the initial signalling, which why these type of devices are referred to as IMSI catchers.

The emulated, low‐power GSM BTS can fit into a small space as it does not require much processing power. By utilizing a directional antenna, the coverage area of such spoof BTS can be highly focused, and thus a targeted spying can be practiced, e.g., by directing the antenna towards the victim from the other side of the street – which causes additional challenges to find the illegal BTSs as the signal level is weak at street level.

According to the ETSI/3GPP specifications, the GSM device should be able to indicate the lack of an encryption algorithm. A more specific way for displaying it is left open for the device manufacturers. In practice, when only the A5/0 is used for active communications, the device might show, e.g., an open lock symbol – unfortunately the meaning of this symbol might not be too clear for the users. On the other hand, the symbol is not shown at all if the display functionality is deactivated from the internal SIM card settings. Especially in the smart device category, there are also non‐compliant models that do not support the display in practice regardless of the SIM settings. Ref. [18] summarizes an example listing of such devices.

The spoof BTS is thus one of the most concrete security threats of the GSM networks as the users may not be able to interpret the warning signs of its presence [14]. Furthermore, it can be used in highly selective ways regarding its location and time to minimize its visibility. As an example, Ref. [2] indicates the probable utilization of such solutions in Oslo during 2014. That specific incidence might be related to the relaying of voice calls via an IMSI catcher.

Regardless of the packet‐switched GPRS service’s security being deeper within the GSM infrastructure, as the radio interface encryption algorithm is located at the SGSN element, it may be possible to emulate the whole GPRS protocol stacks in a similar fashion as for the spoof GSM BTS for the voice connections, so the relaying and illegal interception of the whole data traffic of the victim who initiates the PDP context might be equally possible [5].

Protection against such relaying threat is possible, e.g., via a separate, application layer protection mechanism like VPN for the GPRS connections or an application layer voice scrambling solution. In its basic form, sending short messages is trickier via such spoof GSM BTS. Also, if the spoof BTS manages to capture the call of the A‐subscriber, it is not able to hand over the connection to legitimate base stations as the BSC of the legal network would not be aware of such a call – which means that when the user moves away from the spoof BTS’s coverage area, the call breaks down. Nevertheless, as the emulated base station has more control over the RRM, which normally would be taken care of by the BSC, it means that the transmitting power level of the device can be commanded to be higher, up to the maximum specified. In GSM 900, is 2 W (33 dBm) while other variants support maximum power levels between 1–2 W (30–33 dBm). By increasing the power of the device as well as the base station itself, it is possible to extend the coverage area before the victim drifts too far away from the spoof BTS’s field.

The spoof GSM BTS as described above functions only for capturing the communications that the subscriber initiates via the spoof BTS. The received call, instead, would be initiated via the legal radio network as it sends the initial signalling via the BCCH of all the base stations of the location area where the B‐subscriber is registered, and forces the security algorithm to be switched on (except for the rare cases of a network not utilizing the encryption) in the one that is selected for the communications. Handover for the spoof BTS would no longer work as the BSC is now in control of the whole communications.

Even if the existence of the spoof GSM BTSs is assumingly not common, it can be speculated that the potential danger could increase near strategically important locations. In such places, a simple way to check the potential illegal routing is to send a short message by both parties on the active call to each other. If one of the subscribers is not able to receive the message, there might be a chance that one of the users is attached to a spoof GSM BTS as it is not able to deliver the messages at the same time as the legitimate network.

It is possible to reveal the potential spoof GSM BTSs by executing radio drive tests, and to correlate the BCCH frequencies found in the field with the known locations of the operator’s own BTSs. Furthermore, the potential jammer transmitters blocking other legal BCCH frequencies can be located. If the user suspects the presence of such spoof BTSs, the local operator might be able to perform such tests.

8.3.2 Potential Security Weaknesses of 3G

8.4.1 LTE Security

The security design of LTE/SAE includes feature development according to the best knowledge about the current and future methods for the attacks together with their technical and business impacts on the network. For instance, security threats like a DoS attack can slow down, or in the worst case, paralyze a large part of the network and cause limited availability of services, which leads to loss of revenue and increases the chances of customer churn. One way of developing up‐to‐date measures against these security threats is to create a security process.

The first step in the security planning is to identify the security threats. Based on the security risk analysis of this phase, the LTE/SAE system is designed and updated accordingly in order to create all the possible counter‐measures against the imaginable security risks. This leads to the list of security requirements, and to the specification of the security architecture layout at the system level.

The next step is to take into account the threats in the SW level, securing the safety of the code as much as possible in the SW development processes. The safety threats may be intentional, or they may be a result of accidentally left open backdoors etc. in the production of the code.

At the end of the security design process, a comprehensive security testing is needed, by taking into account the imaginable attack types in the normal operations of the network, as well as in the unstable conditions that are created either intentionally or accidentally.

This example of the security process is logically an iterative activity for the participating stakeholders. This means that as the technologies develop and new methods and ideas for attacks arise, they should be identified and taken into account at the earliest convenience so that the network protection can be updated accordingly to shield against the new threat types. As one part of the new security threat identification, a network fraud monitoring process should be implemented. This provides information about the possible new security threats to be taken into account in the security process.

In addition to the security process, it is recommended to execute security audits in the operator networks. This is an important task as the end‐to‐end chain of typical mobile networks tend to include a huge amount of different combinations of network elements with different versions and security levels. Both HW and SW can be audited in cooperation with the network vendors and operator. If any vulnerabilities are detected, the issues can be corrected by enhancing updated security threat counter‐measures. Figure 8.4 summarizes key aspects of the security chain.

8.4.2 Network Attack Types in LTE/SAE

The LTE/SAE architecture has some special characteristics that should be taken into account in the enhanced security planning. The important fact is that LTE/SAE is based on a flat architecture, which means that all radio access protocols terminate to the eNB elements. Furthermore, the IP protocols are also visible at the eNB.

The challenges arise from the architectural realization of LTE/SAE because it is now possible to place eNB elements at more accessible locations exposing the HW to potential hacking intentions. Furthermore, the LTE/SAE network interworks with legacy and non‐3GPP networks that might open unpredictable security holes even if their normal mode of operation does not expose special issues. There are also new business environments with networks whose trustfulness is not necessarily completely known. Comparing the purely IP‐based LTE/SAE architecture with the previous 2G/3G principles, LTE/SAE requires extended authentication and key agreement methods to cope with modern IT attacks. This means that the key hierarchy as well as the interworking security are inevitably more complex. It also means that the eNB element has additional security functionality compared to the previous 2G base transceiver stations and 3G NB elements [24,25].

Identification of the potential network attack types in the LTE/SAE environment is one of the most essential preventive tasks. As the Home eNB concept basically means that the customer can try to access physically the HW and Sw of the element, it is one of the most potential avenues for fraudulent activities. Some possibilities are:

• Cloning of the Home eNB credentials.
• Physical attacks on the Home eNB, e.g., in the form of tampering.
• Configuration attacks on the Home eNB, e.g., fraudulent SW updates.
• Protocol attacks on the Home eNB, e.g., man‐in‐the‐middle attacks.
• Attacks against the core network, e.g., DoS.
• Attacks against user data and identity privacy, e.g., by eavesdropping.
• Attacks against radio resources and management.

8.4.3 Preparation for the Attacks

A more detailed list of LTE/SAE security‐related items to be taken into account in the security process include the following:

• Air‐link security (U‐plane and C‐plane security). This includes the definition and description of the ciphering algorithm for the U‐plane and C‐plane, definition and description of the integrity protection algorithm for the C‐plane, and description of the access stratum security signalling (including key distribution).
• Transport security. This item includes the definition and description of ciphering and integrity algorithms for the transport network, and description of the transport security signalling (including key distribution).
• Certificate management. This includes the definition of public key and key management concepts.
• Operations, Administration and Management (OAM) security (M‐plane security). This includes the management plane security.
• Timing over Packet (ToP). This includes the synchronization plane security for IEEE v2 packets for frequency and time/phase synchronization.
• eNB requirement. This includes the definition of secure environment, requirement definition for eNB and secure key and file storage.
• Intra LTE and inter system mobility. This includes the definition of security aspects in handover cases (including key distribution).

It should be noted that different planes differentiate the traffic types, and this should be taken into account in the security planning. The planes in the LTE/SAE environment are: U‐plane for the delivery of the user data; C‐plane for the delivery of the control data; M‐plane for the delivery of the management data; and S‐plane for the frequency and time/phase synchronization information. Figures 8.5–8.8 identify the security‐related aspects of these planes.

As will be described in the next sections, IPSec is the 3GPP standardized solution for security on several LTE interfaces. These are S1‐MME and X2 control planes as well as S1 and X2 user planes. Security for the management plane is not standardized but the use of IPSec or transport security is one possible option. In addition, use of IPSec in combination with certificates makes it very difficult for any unauthorized person to gain access to the core network or eavesdrop the traffic between the eNBs and the core network. In this way integrity and confidentiality of data can be ensured.

An integral part of the preparation plan against security attacks include network security audits which can be an operator’s own activity or an external managed service. The main aim of this activity is to check the adequate configuration of the network element settings, and ensure the potential security holes are identified and protected. Other techniques include network and security breach monitoring of the traffic, typically relying on DPI. It can be combined with information about historical behaviour and deviations to capacity, performance, traffic type, etc. Logically, the traditional methods such as virus protection are still applicable if provided as a real‐time network service.

8.5.1 Equipment Ordering

As a general rule of thumb, equipment investment should not be done too early because of the warehouse storing costs, danger of the expiration of warranties, possible increasing of damaged units when stored, and potential existence of early version bugs which can jeopardize the security of the device. Nevertheless, if the investment is done too late, it might impact seriously on the deployment as the time schedules for the ordering might vary and it might not be possible to align the schedules with the actual deployment at the last moment. In practice, there are sometimes issues with component availability, logistics chain and the physical delivery of the equipment to the final sites.

Some operators may want to test the new equipment via special stress procedures which are sometimes only possible after the end‐to‐end chain is upgraded to an adequate level. This type of Inter‐Operability Testing (IOT) is typically requested to ensure that the element is compatible with the operator’s infrastructure. The potential problems require time to correct, with possible escalation efforts, which also should be taken into account in the time required for equipment order management.

The correct timing is thus essential to ensure that the delivery chain is aligned with the LTE/LTE‐A deployment. This is one of the key optimization tasks of the operator apart from the actual network planning optimization efforts.

As Figure 8.9 indicates, there is an impact on the Return on Investment (RoI) related to the timing of the physical equipment ordering. If the equipment is ordered too early, the number of elements might not have the correct HW/SW level as the final deployment plan might change due to unexpected challenges, e.g., due to difficulties obtaining physical sites. If the equipment cannot be installed straight away, warehouse costs increase, and the equipment might be even become outdated and its warranty expire. Nevertheless, there should always be an optimal buffer for spare parts that assures the fast replacement of faulty modules. Another important aspect is the spare stock of the equipment. The size of the stock needs to be sufficiently complete for potential HW and outdated security protection problems of the equipment in the field.

On the other hand, if the equipment is ordered too late, there might be hard‐to‐estimate challenges in the production line schedules. If the line is saturated, the order might take a much longer time than average, which delays the new equipment installation. In addition to the HW readiness, the aligning of the SW level is also important. It does not make sense to order equipment with pre‐loaded SW if the roadmap indicates that the SW needs to be soon upgraded.

For the overall equipment logistics, a good tool for optimal equipment ordering is an inventory management SW. It gives the possibility to track efficiently the logistics chain, and to assure the equipment arrives at the correct location on time.

8.5.2 Early Testing

Testing new network element functionalities early enough is one of the essential tasks of the operators and equipment providers for successful network deployment. It should be noted that this principle applies to all the network elements as well as the UE. In fact, the lifecycle and the introduction of new smartphone models to the markets is accelerating in such a fast way that there is a great potential to fail in the assurance of some performance targets or functionalities – including the assurance of an adequate security level. This is especially important in cases where the operator has ordered an exclusive model from the OEM. The functionality against the operator’s own requirements is done by the OEM as deeply as the risk analysis indicates, but there may be remaining issues during the final acceptance testing of the operator, or even in the commercial phase after the launch of the device, e.g., due to the failure in quality processes of third parties. The late noting of the failures presents the worst‐case scenario as it jeopardizes the public image of the operator and the OEM, and the corrective measures may lead to high expenses.

As the time schedules are typically very tight from the initial phase of equipment research, continuing into the development phase, and during the actual manufacturing, this means that the testing of previously correctly functioning items might be minimized in the faith that there would be no issues in new variants, either. This might lead to vast problems, as the new UE functionalities, the additional new RF bands, new MIMO and CA configurations, multi‐mode operation, and chip‐level architectural changes might cause hard‐to‐predict issues. As an example, the previously well‐behaved GSM RF performance of the UE might suffer from additional LTE bands due to different filter adjustments, making the RF performance unacceptable in parts of the GSM RF bands. If the OEM does not perform (repeat) all the essential RF performance measurements in all the bands and systems, it means there will be unpredictable risks in the acceptance phase of the device – and in the worst case, it might result in non‐optimal functioning of the device, which is only noted in the commercial phase of the device, in operational networks.

Along with the development of the digital cellular networks and devices since the 1990s, there are many examples about devices not working according to the specifications in certain situations, which was not recognized before the devices were utilized in the commercial markets. The operator has basically only a few options in these situations: (1) to accept a lower quality for the users of the faulty device which may even decrease the quality of the another user; (2) to modify the functionality of the network so that the faulty behaved device causes minimal problems; (3) to upgrade the device. Upgrading might be possible to execute via an OTA SW upgrade procedure, or in the most costly case, by collecting the faulty devices physically from the customers and upgrading them or replacing the devices completely. This is obviously so expensive that the business case for that device may turn out to be negative, especially in the case of devices with tight margins. The modification of the network functionality for supporting faulty devices is also sometimes utilized, if possible, to minimize replacement costs. The drawback of this solution is that the operator needs to ensure the adjusted network functionality in the longer run, e.g., when there are general SW upgrades or new releases. This obviously increases the complexity of the network management. So, early testing is the best solution for both operator and OEM in order to minimize later costs.

The introduction of LTE/LTE‐A increases even more the probability of remaining faults in the network elements and user devices as a result of new, advanced technologies, functionalities and high performance requirements. Figure 8.10 presents an ideal high‐level process for the new equipment manufacturing. This refers to any LTE/LTE‐A network element as well as to user devices which contain new functionalities or enhanced performance, i.e., to equipment which has modifications or new HW and SW. In the real life, errors might only be revealed in the late phase of the testing, relatively close to the planned launch date of the equipment which, in the worst case, may lead to delays for market entry, as indicated in Figure 8.11.

As much pre‐testing as reasonably possible is recommended for the equipment manufacturing, prior to the deadline of the equipment manufacturing phase, yet balancing the expense. Figure 8.12 clarifies the early testing concept. This emphasis on early testing is due to the fact that new functionalities might have interfering effects on the equipment that was perhaps not an issue in earlier models.

Also, there might be some operator‐specific demands and important requirements that need additional testing. If any issues related to such operator‐specific functionalities are noted late in the field test phase, it might be much more challenging to get corrections on time. This is especially relevant for errors that are related to the operational system or chip‐sets. In order to assure the capturing of potential problems, it is recommended to execute operator‐specific field tests (trials, pilots, friendly operator’s lab tests) during the development phase so that the fault management can react early enough for the requests for corrective actions internally and for the third parties. Corrections of equipment faults is typically done by opening a request for a fix, i.e., issue a ticket via an established process, as presented in Figure 8.13.

It should be noted that the principal threat in the device HW and embedded OEM SW is not because of faults in the trust chain – although this cannot be excluded completely, e.g., due to any untrustworthy individuals who might alter the device in the planning or manufacturing phase. It can be assumed that the potential security holes on devices – whether they are network elements like cellular base stations, Wi‐Fi access points or core elements like routers, bridges, gateways etc. – are due to unintentional failures in the design or assembly line. Whatever the root cause for potential security vulnerabilities, the sufficiently thorough and early testing of the equipment for the functionality and performance but especially for the level of security are of the utmost importance to identify and correct any weaknesses. One important part for ensuring the HW functionality in the critical areas such as payment solutions require certification which is often time consuming but well worth the effort. As soon as the HW is approved and deployed, the tailored, periodic security audits are of great help in order to guarantee that the protection mechanisms as well as the potential, internal HW flaws are not exposed to the external world before proper correction takes place.

The same principles apply to accompanying components of the end‐to‐end chain, including the thorough security testing and audits of the expected functionality and interoperability of the SIM/UICC in the subscription management including OTA provisioning and advanced remote access methods.

8.6.1 Principle

Self‐Organizing Network (SON) is a new technique being introduced within LTE/SAE as part of the next generation mobile broadband network technology, and is endorsed by the NGMN Alliance as a key requirement for future networks. The objective is to automate the configuration and optimization of base station parameters to maintain best performance and efficiency. In fact, the SON concept is not only highly useful in network planning and optimization, it also tackles potential security breaches by ensuring the correct setting of parameters.

Previously a drive test team would go out into the live network and take a ‘snapshot’ of the performance, then bring this back to the lab and analyse it to improve the settings. More snapshots provide more statistically significant data and hence a better base for the optimization, but this drive test based data acquisition process is expensive, difficult and not repeatable. In addition, this is a reactive method to solve problems after they have occurred, and it does not help to improve customer experience if the issue is already visible. A drive test is also heavily used at the start of a network deployment to measure cell coverage and set initial parameters for cell powers, frequencies etc. in order to control interference and maximize capacity.

SON should enable network operators to automate these processes using the measurements and data generated in the base station during normal operation. By reducing the need for specific drive test data, this technique should reduce operating costs. By using real‐time data generated in the network, and reacting in real time at the network element level, this should enhance customer experience by responding more dynamically to changes and problems in the network much earlier so that users are less affected.

SON can simplify an operator’s processes to install new cell sites, reducing the cost, time and complexity. SON gives an obvious benefit if deploying femto cells, as the operator is not strictly in control of the cell site and needs to rely on automated processes to correctly configure the cell into the network. In addition, the running costs of the site are reduced, as drive test optimization is reduced and site visits for fault investigation and repair can be reduced. All of this leads to OPEX savings for the network by using automated technology to replace manual operations. For the customers on the network, SON will lead to better customer satisfaction as coverage and QoS are driven and optimized by actual customer usage, and there should be reduced downtime or faulty cells. The OSS monitoring systems and SON should work together to automatically detect usage trends and failures and automatically take action in real time to correct errors.

SON is the top level description of the concept for more automated (or fully automated) control and management of networks, where the network operator has only to focus on policy control (admission control, subscribed services, billing etc.) and high level configuration/planning of the network. All low level implementation of network design and settings is made automatically by the network elements. The self‐organizing philosophy can then be broken down into three generic areas relating to the actual deployment of the network, these are configuration (planning and preparation before the cell goes live), optimization (getting the best performance from the live cell) and healing (detection and repair of fault conditions and equipment failures). Each of these is further explained below.

8.6.2 Self‐configuration

This is the first stage of network deployment, and covers the process of going from a ‘need’ (e.g., improve coverage, improve capacity, fill a hole in coverage) to having a cell site ‘live’ on the network and providing service. The stages involved here are roughly:

• Planning for location, capacity and coverage of the eNB.
• Setting of the eNB parameters (radio, transport, routing and neighbours).
• Installation, commissioning and testing.

The self‐configuring network should allow the operator to focus on selecting location, capacity and coverage needs, and then SON should automatically set the eNB parameters to enable the site to operate correctly when powered on. This will in turn minimize the installation and commissioning process, and enable a simple ‘final test’ at the site to confirm that the new site is up and running. This will include the optimum setting for power levels, the choice of Cell ID, and correctly identifying the Cell ID of neighbour cells. The neighbour Cell ID must then be used by the eNB to negotiate with these neighbours using the Inter Cell Interference Control (ICIC) algorithms on the S2 interface. This is critical to prevent interference where the coverage of two cells is overlapping.

8.6.3 Self‐optimizing

Once a site is live and running, there are often optimization tasks to be made that are more of a ‘routine maintenance’ activity. As the geography of the area changes (e.g., buildings constructed or demolished), the radio spectrum changes (e.g., new cells added by the operator or by other operators, or other RF transmitters in the same area or at the same tower), then the neighbour cell lists, interference levels and handover parameters must be adjusted to ensure smooth coverage and handovers. Currently, the impact of such issues can be detected using an OSS monitoring solution, but the solution requires a team to go out into the field and make measurements to characterize the new environment and then go back to the office and determine optimum new settings. SON will automate this process by using the UE in the network to make the required measurements in the field, and the SON function will report them automatically back to the network. From these reports, new settings can be determined. This will remove the need for drive test teams to make such measurements. This concept can also be extended to managing QoS and load balancing by using quality reports to optimize the scheduling algorithms in the eNB.

8.6.4 Self‐healing

When a site is fully operational and active then it is generating revenue and satisfying customers. If there are any problems with the site and it fails to provide a service or coverage then revenue and/or customers are lost, and so the site must be brought back up to full capacity as soon as possible. The third element of SON is to automatically detect when a cell has a fault (e.g., by monitoring both the built‐in self‐test, and also the neighbour cell reports made by the UE that are/should be detecting the cell). If the SON reports indicate a cell has a failure then there are two necessary actions: to indicate the nature of the fault so the appropriately equipped repair team can be sent to the site;, and then to re‐route users to another cell if possible and to re‐configure neighbour cells to provide coverage in this area while the repair is underway. After the repair, SON should also take care of the site re‐start in a similar process to the site commissioning and testing. The self‐healing functionality under the SON concept thus refers to the automatized fault management and correction.

8.6.5 Technical Issues and Impact on Network Planning

To deploy SON in a multi‐vendor RAN environment requires standardization of parameters for reporting and decision making. The eNB will need to take the measurement reports from the UE and also from other eNBs and report them back into the Operations and Maintenance (O&M) system to enable optimization and parameter setting. Where there is multiple vendor equipment involved then this must be in a standardized format so that the SON solution is not dependent on a particular vendor’s implementation.

The equipment vendors who are implementing SON will need to develop new algorithms to set eNB parameters such as power levels, interference management (e.g., selection of sub‐carriers) and handover thresholds. These algorithms will need to take into account the required input data (i.e., what is available from the network) and the required outcomes (including cooperation with neighbour cells).

Furthermore, as SON is also implemented into the core network (Evolved Packet Subsystem, EPS), there needs to be standards on the type and format of data sent into the core. Inside the core network, new algorithms will be required to measure and optimize the volume/type of traffic flowing taking into account the QoS and service type (e.g., voice, video, streaming, browsing). This is required to enable the operator to optimize the type and capacity of the core network, and adjust parameters such as IP routing e.g., in a Multiprotocol Label Switching (MPLS) network, traffic grooming, and so on.

8.6.6 Effects on Network Installation, Commissioning and Optimization

Equipment vendors have the opportunity to develop algorithms that link eNB configuration to customer experience, allowing fast adaptation to customer needs. Here the customer experience is exactly that which is measured by their UE in the network. The challenge is to link RF planning and customer ‘quality of experience’ closer together at a low level technical implementation. The benefit is that the network can adapt to meet the user needs in the cell without additional cost of optimization teams constantly being in the field. The network planners’ simulation environment will now need to take into account the SON operation of the eNB when making simulations of capacity/coverage for the network. As the operator may not directly control/configure the eNB, the simulation environment will need to predict the behaviour of the network vendors’ SON function in the network.

An operator/installer’s site test must verify that all parameters are correctly set and working in line with the initial simulation and modelling. This will ensure that the expected coverage and performance is provided by the eNB. The SON function will then self‐optimize the node to ensure that this performance is maintained during different operating conditions (e.g., traffic load, interference). This should reduce the amount of drive tests required for configuration and optimization (in theory reduced to zero), so that a drive test is only needed for fault finding (where SON is not able to self‐heal the problem). We will see in the later section on live network testing, that a comprehensive suite of RF OTA tests can be made at the time of site installation, so that the SON can be correctly configured and verified. It is generally expected that SON will be able to reduce the level of drive tests needed to initially configure the network, but will not be able to replace the initial site commissioning/acceptance tests. So the preferred test strategy is to use the initial site tests to further strengthen the SON parameters setting.

The potential disadvantage of running SON in the network is that it requires the UE to make the measurements, and relies on enough data being available. The eNB is able to command the UE to make measurements and report them, but doing this on a regular basis will have an impact on the battery life of the UE. On current generation smartphones the battery life is already a limitation, so extra SON measurements should not significantly reduce the battery life further.

8.6.7 SON and Security

Although the SON concept was principally developed to ensure proper network functionality and performance, it could also be used as a feasible base for ensuring the security. Some ideas for the applied SON functionalities may include the automatized and repeatable security audits via controlled (isolated) stress testing in pre‐commercial and commercial networks.