7.1.1 5G Security Drivers

There is broad consensus that a Fifth Generation (5G) network must be secure, in the sense that it protects the privacy of its users and the confidentiality and integrity of the traffic it transports, but also in the sense that it is protected against any kind of cyberattack that may affect the availability and integrity of the network or the confidentiality of the data it stores. This chapter outlines the 5G security drivers and requirements, and presents a 5G security vision as well as an architecture, building on material from [1]. It gives a description of the 5G security features specified by Third Generation Partnership Project (3GPP) for the 5G System, with a focus on showing the differences to Evolved Packet System (EPS). Finally, it provides a closer look at security issues that are currently not very much in the focus of 3GPP, but highly relevant for 5G networks: Secure Software Defined Networking (SDN), building on material from [29], and secure Network Function Virtualization (NFV).

Inherently, wireless communication is vulnerable and needs specific protection against interception and tampering. Consequently, since the second generation of mobile networks, Global System for Mobile communication (GSM), encryption is used on the radio interface to secure the user communication. In the next two generations of mobile networks, Universal Mobile Telecommunications System (UMTS) and Long Term Evolution (LTE), the security architecture was significantly enhanced. Besides encryption of user traffic, UMTS and LTE also provide mutual authentication between mobile terminals and the network, as well as integrity protection and encryption for the control traffic. It is common practice in modern mobile networks to secure network management communication between network element and management system, using protocols such as Secure Shell (SSH) [27] or Transport Layer Security (TLS) [13]. The security features of UMTS and LTE not only ensure a high level of security and privacy for the subscribers, but, very importantly, also make such networks robust against various forms of attacks against the integrity and availability of the services they provide.

Specified nearly 10 years ago, the EPS security concepts have not shown any major flaws, leading to the question why new security concepts may be required at all for the next mobile network generation. As a short answer, it is the support of a variety of new use cases on the one hand, and the adoption of new networking paradigms on the other hand that make it necessary to reconsider some elements of the current security approach.

While EPS was designed primarily to support the mobile broadband use case (i.e. broadband access to the Internet), 5G targets a variety of additional use cases with a variety of specific requirements. Some use cases, such as vehicular traffic or factory control, place the highest demands on the dependability of the network. Human lives may depend on the availability and integrity of the network service used by such applications.

To support each use case in an optimal way, security concepts will need to be more flexible. For example, security mechanisms used for ultra‐low latency, mission‐critical applications may not be suitable in massive Internet of Things (IoTs) deployments where mobile devices are inexpensive sensors that have a very limited energy budget and transmit data only occasionally.

To efficiently support new levels of performance and flexibility required for 5G networks, it is understood that new networking paradigms must be adopted, such as SDN and NFV. At the same time, these new techniques also bring new threats. For example, when applying NFV, the integrity of virtual network functions (VNFs) and the confidentiality of their data may depend to a large degree on the isolation properties of a hypervisor, or more generally, on the integrity and correctness of the whole cloud software stack. Vulnerabilities in such software components have surfaced quite often in the past. In fact, it remains a major challenge to provide a fully dependable, secure NFV environment. SDN, for its part, bears the threat that control applications may wreak havoc on a large scale by erroneously or maliciously interacting with a central network controller.

Another driver for 5G security is the changing ecosystem. Current networks are dominated by large monolithic deployments, each controlled by a single network operator owning the network infrastructure while also providing all network services. By contrast, 5G networks may see many specialized stakeholders providing end‐user network services, as illustrated in Figure 7.1.

There may be dedicated infrastructure providers (InPs) decoupled from telco service providers that host several service providers as tenants on a shared infrastructure. Telco service providers in turn may not only offer end‐user communication services, but may also provide complete virtual networks or network slices specialized for specific applications, such as industrial IoT applications. These network slices may be operated by verticals, i.e. non‐telco enterprises like logistics enterprises or manufacturing companies. A manufacturing company could run a virtual mobile network specialized for industrial IoT applications on its own plants. The security aspect here is the building and maintenance of new trust relationships between the various stakeholders to ensure trusted and trouble‐free interaction, resulting in secure end user services.

7.1.2 5G Security Requirements

When specifying a security concept, typically one of the first steps is to define the security requirements. This section does not aim at assembling a complete list of security requirements, but rather highlights some high‐level requirements and their sources.

A major source of 5G requirements is the Next Generation Mobile Networks (NGMN) Alliance's 5G White Paper [2]. This paper emphasizes that in 5G networks, the “enhanced performance is expected to be provided along with the capability to control a highly heterogeneous environment, and capability to, among others, ensure security and trust, identity, and privacy.” So, on the one hand, the security mechanisms need to comply with the overall 5G requirements, including extremely fast control plane procedures, extremely low user plane latency, and highest energy efficiency. On the other hand, [2] explicitly requires many security improvements compared to today's networks, for example:

• ‘Improve resilience and availability of the network against signaling based threats’;
• ‘Improve system robustness against smart jamming attacks of the radio signals and channels’; and
• ‘Improve security of 5G small cell nodes.’

Subsequently, the NGMN Alliance has driven a working group on 5G security which has delivered three dedicated documents (called “packages”) [3] with 5G security recommendations. These relate to topics such as potential security improvements of the access network, Denial of Service (DoS) protection, network slicing, mobile edge computing, low latency and consistent user experience.

Clearly, the EPS security concepts are a starting point as well as a benchmark for 5G security, with respect to the mobile broadband use case which will remain of major importance. 5G must obviously be able to provide at least the same level of protection where needed as EPS, thus EPS security features are a natural security baseline for 5G networks. On top of this, it is rewarding to revisit security features that have been discussed but were not adopted for EPS. This discussion is captured in [5] and comprises features such as International Mobile Subscriber Identity (IMSI) catching protection, user plane integrity protection, or ensuring non‐repudiation of service requests. IMSI catching means to trick mobiles into revealing the identity of the subscriber, the IMSI, by carrying out an active attack involving usage of a faked base station. Non‐repudiation of service requests means that users cannot reasonably deny that they made a service request, as the request origin can be proven, typically by use of digital signatures.

Since Release 15, 3GPP SA1 specifies the service requirements for the 5G system in [6], with a dedicated section on security. There are various security requirements listed that extend what has been required for previous mobile network generations. For example, it is now required to be able protecting the subscriber identity against active attacks, i.e. prevent IMSI catching. Further, it is required that the 5G system supports an access independent security framework and includes a mechanism for the operator to authorize subscribers of other networks to receive temporary service (e.g. for mission critical services), even without access to their home network.

With respect to authentication for User Equipments (UEs) attaching via Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E‐UTRAN), EPS only supports EPS AKA (EPS Authentication and Key Agreement). For 5G, it is a requirement that alternative authentication methods with different types of credentials are supported, aiming at IoT devices in isolated deployment scenarios, e.g. on factory plants. Moreover, the network is required to support a resource efficient mechanism for authenticating groups of IoT devices.

Document [6] also covers the area of network slicing, and requires slice isolation, in the sense that traffic as well as management operations within one slice have no significant impact on other slices. In this context, [6] also considers the involvement of third parties, and requires the network to support slice management (creation, modification, deletion) by such third parties. Moreover, in private 5G networks, the use of identities, credentials and authentication methods controlled by a third party must be supported.

As mentioned earlier, by the adoption of NFV, new security threats arise and need to be mitigated. Respective security requirements can be found in specifications provided by the European Telecommunications Standards Institute (ETSI) Industry Specification Group (ISG) NFV. As early as 2013, [7] included a list of security requirements, with the intention to address the new NFV threats. Among others, this list mentions protection measures against security vulnerabilities in the virtualization layer, protection for data stored on shared storage or transmitted via shared networking resources, protection of the new interfaces exposed by adopting the ETSI NFV architecture, including the management and orchestration components, and mechanisms to isolate different sets of VNFs running on the same NFV infrastructure.

Subsequently, specifications of the ETSI NFV's security group further elaborated on threats and respective security requirements. For example, [8] lists “potential areas of concern,” which include validation and enforcement of the topology (of the graph consisting of the NFVs and their interconnections), a secure boot of the NFV platforms, AAA (Authentication, Authorization and Accounting) mechanisms for NFV users (tenants), private keys in cloned VNF images, or backdoors via virtualized test and monitoring functions. Another specification, [9], provides “security and trust guidance” and lists the high‐level NFV security and trust goals.

A very comprehensive list of security requirements is given by [10], specifying what is required to allow the secure execution of sensitive VNF components in an NFV environment. A basic requirement is the implementation of a tamper‐resistant, tamper‐evident Hardware‐Based Root of Trust (HBRT), like a Trusted Platform Module (TPM), see [11]. The HBRT is meant to support a secure boot as well as a highly secure management of cryptographic keys (key generation, key storage) and execution of crypto operations making use of the securely stored keys. Various other requirements are specified, including authentication of users of the NFV environment, attribute‐based access control as specified in [12], communication security by means of TLS [13], verification of the provenance and integrity of all software components before installing and executing them, secure logging, and many more.

The brief overview on security requirements given in this section focuses on the NGMN Alliance, 3GPP SA1 and ETSI NFV as sources of requirements, and it clearly shows that there is already a significant body of diverse and somewhat challenging 5G security requirements. This body will be further increased by security requirements relating to the variety of additional mechanisms and protocols specified by other organizations, such as the Internet Engineering Task Force (IETF), that are expected to become relevant for future 5G networks.

7.1.3 5G Security Vision

Considering the 5G security drivers and requirements, three main characteristics of “what 5G security should be” emerge: Supreme built‐in security, flexibility, and automation, as visualized in Figure 7.2.

7.2.1 Security Between Mobile Devices and the Network

Security features relating to the interface between mobile devices and network are subject to standardization in 3GPP's Working Group SA3. Section 7.3 describes what is expected to be specified by 3GPP for 5G Phase 1 at the time of writing this book, while this section provides a more general overview, considering also mechanisms for future standardization.

Security between mobile devices and (radio and core) network includes authentication, and thus includes the types of identities (for subscriptions, devices or human users), the credentials that can be used, as well as the options available to store them on mobile devices. The current approach with the Universal Subscriber Identity Module (USIM) application on a Universal Integrated Circuit Card (UICC), commonly called a “Subscriber Identity Module (SIM) card,” will continue to play a major role, particularly for the mobile broadband use case. In addition, other types of tamper‐resistant hardware platforms for secure storage of identities and credentials and for secure execution of algorithms may be added to optimally support use cases such as massive IoT deployments.

To support more flexibility in the security setup, the security negotiation between the mobile device and network must be flexible enough to allow, for example, a mobile device to “opt out” of network terminated user plane traffic security. More flexibility may also be required with respect to crypto‐algorithms. While the algorithms used in EPS are still very sound and not endangered by known attacks, new algorithms may need to be added, particularly so‐called lightweight crypto algorithms. These refer to algorithms that minimize energy consumption for crypto operations without sacrificing the security. They are very important in the context of IoT devices. Other reasons for revisiting the selection of crypto algorithms may be the emerging of new computational techniques, such as quantum computing, or the detection of new attacks or more effective crypto analysis methods for the selected algorithms.

For control traffic, cryptographic integrity protection is vital to prevent spoofing, connection hijacking or impersonation attacks. Encryption is also important in this case to protect private user information transmitted in the control plane. The control plane protocols must be designed and implemented to anticipate all kinds of malicious behavior of mobiles – even of those that have been successfully authenticated as legal subscriber devices. It is no option to rely on standard‐conformant behavior of mobile devices, as these, often without knowledge of their owners, can be corrupted by malware and may attack the network.

Like in EPS, security on the radio interface will rely on crypto protocols located rather at the top of the layer 2 protocol stack. It is an interesting field of research to investigate to what degree physical layer security mechanisms could enhance the security architecture, for example by providing additional security for communication on the lowest layers, where in current mobile networks no cryptographic protection is available. In EPS for example, this communication comprises control messages on the Media Access Control (MAC) layer, by which mobile devices inform the base station about the amount of data they want to transmit at a given time, and by which base stations inform mobile devices which radio resource blocks they must use to transmit the data. The individual physical properties of a transmission channel between a base station and an authenticated mobile device may be monitored to detect when an incoming unprotected lower layer message was sent by some attacking device instead of the legal, authenticated mobile device.

7.2.2 Security in the Telco Cloud

As most NFs are expected to run in NFV environments, NFV security mechanisms will play a key role in the 5G mobile network security architecture. They are discussed in Section 7.5. Connectivity within and between data centers is expected to be controlled via SDN, calling for a sound SDN security approach. SDN‐specific security mechanisms are explained in Section 7.4. In the context of network slicing, security mechanisms must ensure a strict isolation between different network slices running on shared infrastructure. This is necessary to prevent virtual machines in one slice from impacting those in other slices. It is also required to prevent information from leaking between slices on side channels, e.g. via physical memory sequentially used by different slices, where information stored by one slice may not properly be wiped out when another slice gets access to the memory. More details on network slicing security can be found in Section 7.6.

When NFs are no longer bound to specific hardware but may be instantiated on different hardware platforms, it might be more difficult to ensure their proper, secure operation. In this sense, NFV may have a significant impact on security assurance methods that will need to take this dynamic allocation of software functions to different hardware infrastructures into account.

An automated holistic security orchestration and management will become crucial in large, cloud‐based 5G mobile network deployments. There will be many different security functions, including virtualized or physical firewalls and intrusion detection systems, and security functions within hypervisors or other elements of the virtualization software. All these must be configured consistently, with all individual policies meaningfully contributing to the overall defense concept, and must be dynamically adapted to changes of the network topology, like migration of VNFs onto other physical resources.

Finally, there will be unpredictable threats that try to exploit weaknesses that may be present despite the care involved in designing and implementing the network. Moreover, DoS attacks may be carried out even in the absence of specific vulnerabilities, by simply flooding network elements or the overall network with traffic. Such attacks are not of a theoretical nature. Mobile botnets pose a very real threat to mobile networks. A botnet is a potentially large set of corrupted devices controlled by an attacker that can carry out large scale attacks against specific servers or networking services. To cope with such new threats, smart, automatic and self‐adapting security controls are required. By closely monitoring what is happening within the network, i.e. analyzing the traffic flows and the behavior of mobile devices and network nodes, and, in a machine learning approach, considering which kind of anomalies preceded past security incidents, smart security controls will be able to detect malicious activities – even previously unknown ones – at an early stage and trigger mechanisms to mitigate such threats and maintain the integrity and availability of the network.

7.3.1 Security Between UE and Network

7.3.1.1 EAP‐Based Authentication

A major change compared to EPS is the introduction of the Extensible Authentication Protocol (EAP, see [20]) framework for mutual Authentication and Key Agreement (AKA) between UE and network. EAP is extensible in the sense that different authentication methods can be used within this framework. In EPS, EAP with the authentication method EAP‐AKA′ [21] is specified for non‐3GPP access only. Aiming at access independence, in 5G it can be used over any kind of access. EAP‐AKA′ is the EAP authentication method that is mandatory to be supported in 5G, but other methods, such as EAP‐TLS, may also be implemented for some scenarios, e.g. in private networks.

On the network side, EAP is processed by the Security Anchor Function (SEAF), acting as EAP authenticator in the serving network (which can be the visited or home network depending whether the terminal is roaming or not), and the Authentication Server Function (AUSF), acting as authentication server, in the home network (see Chapter 4 for a detailed discussion of the 5G network architecture). In 5G phase 1, the SEAF is assumed to be collocated with the Access and Mobility Management Function (AMF). The AUSF communicates with the Authentication Credential Repository and Processing Function (ARPF) inside the Unified Data Management (UDM) that holds the long‐term authentication credentials of the UE and performs all processing that requires access to these credentials. It is the UDM/ARPF which decides on the authentication procedure (EAP‐AKA′ versus 5G AKA), and depending on this decision, suitable authentication material is produced and sent to the AUSF. In case of EAP‐AKA′, this is an Authentication Vector (AV) including keys called Cyphering Key (CK′) and Integrity Key (IK′) that are derived from the long‐term credential.

The authentication exchange is depicted in Figure 7.4.

During the EAP processing, UE and home network, represented by the AUSF, authenticate each other and derive a common key, called EMSK (Extended Master Session Key), in a way that the key remains hidden to any intermediate nodes. From EMSK, the AUSF derives a key called K_AUSF and from this key another key called K_SEAF which is passed from the AUSF in the home network to the SEAF in the serving network. This key is bound to the serving network identity, by including the Serving Network Identifier (SN id) into the input of the key derivation algorithm. Moreover, a constant “5G:” is part of the input, binding the key to an EAP‐AKA′ run in a 5G system (as opposed, e.g. to an EPS AKA run). In case of EAP‐AKA′, the serving network identity is also considered when deriving the keys CK′ and IK′ in the ARPF. The AUSF receives these keys before starting the authentication process. The SEAF derives from K_SEAF a key K_AMF and passes it to the AMF. From K_AMF, keys K_NASenc and K_NASint for encryption and integrity protection of Non‐Access Stratum (NAS) signaling traffic are subsequently derived.

The UE is also aware of the SN id and that this is a 5G authentication run, and it uses the same derivations as the network to generate K_SEAF, K_AMF, K_NASenc and K_NASint. When the UE can successfully check the integrity of a message from the network protected by K_NASint, the UE obtains assurance from the home network that the UE shares K_SEAF, K_AMF, K_NASenc and K_NASint with the specific serving network whose identifier was used as input to the derivation of K_SEAF.

It should be noted that the UE always authenticates with its home network in the EAP authentication run, as opposed to EPS AKA, where authentication is done between UE and serving network, based on authentication material the home network provides to the serving network.

Moreover, EAP between UE and AUSF in the home network allows UE and AUSF to retain a key shared only between UE and AUSF but not known to the visited network. Although currently not specified by 3GPP, such a key may be used to establish security associations directly between UE and home network.

EAP‐AKA′ based authentication must be supported in the UE and in serving network entities (i.e. AMF/SEAF), but not necessarily in Home Public Land Mobile Network (HPLMN) entities such as AUSF and ARPF/UDM. So, an operator not using EAP‐AKA′ for its own subscribers does not have to implement it in AUSF and ARPF/UDM. Still, foreign subscribers roaming in this operator's network will not be prevented from using EAP‐AKA′, based on the mandatory support in the AMF/SEAF.

7.3.1.2 5G AKA

Besides EAP, also an enhanced version of EPS AKA, called 5G AKA, must be supported by the UE and serving network entities. Different to EPS AKA, 5G AKA can be used over 3GPP as well as non‐3GPP access. The part of the Mobility Management Entity (MME) and the Home Subscriber Server (HSS) in EPS‐AKA are taken by the SEAF/AMF and the AUSF/ARPF/UDM in 5G AKA. Like in EAP based 5G authentication, 5G AKA binds the key it generates to the serving network identity and to the constant “5G:.” Different to EPS AKA, the expected result (called XRES*) on the AKA challenge is not part of the Authentication Vector passed from the home network to the serving network, but only a one‐way hash of it, called HXRES*. This is sufficient for the visited network to verify whether a UE provided the correct answer (called RES*) on the AKA challenge, because the serving network can apply the same hash to RES* and compare the result to HXRES*. 5G AKA specifies an authentication confirmation message, in which the serving network passes RES* as received from the UE to the home network. This proves to the home network that the UE is indeed present in the serving network, as the serving network is not able to calculate RES* itself. Depending on its policies, a home network may not acknowledge that the UE is present in the serving network without successful authentication confirmation. For example, it may reject registration requests from the UE in a serving network, if no sufficiently recent confirmed authentication via the serving network has happened. This is an advantage compared to EPS AKA, where a fraudulent serving network can falsely claim a UE is connecting to it and possibly charge the home network, by first requesting an authentication vector and then sending an Update Location request.

The 5G AKA authentication exchange is visualized by Figure 7.5.

After passing the Authentication Vectors to the SEAF, 5G AKA requires an additional roundtrip between SEAF/AMF and AUSF. The reason for this is that in 5G, the serving network only receives the unconcealed subscription identifier (see section on Subscription Identity Privacy) after successful authentication confirmation by the home network, and it needs this identifier in deriving the key K_AMF.

7.3.1.4 Key Hierarchy and Crypto Algorithms

An overview of the 5G key hierarchy is given by Figure 7.6.

In the first step, keys called CK and IK are derived from the long‐term key K, in the network and on the USIM. 5G AKA and EAP‐AKA′ use different ways to derive K_AUSF from CK and IK. The subsequent derivations are common to both methods. On the UE side, CK and IK are passed from the USIM to the ME (Mobile Equipment) part of the UE, where the subsequent derivations are carried out.

For both NAS and AS security, 5G phase 1 specifies the same three pairs of crypto algorithms as in EPS (each pair consisting of an encryption and an integrity protection algorithm), i.e. the three pairs of algorithms based on the three crypto algorithms AES (Advanced Encryption Standard), SNOW 3G and ZUC, where AES and SNOW 3G are mandatory to support. In future, it may be reasonable to add further algorithms, for example lightweight crypto algorithms, as mentioned already in Section 7.2, or algorithms with keys longer than 128 bits. The specification allows for easy inclusion of new algorithms once this is required.

7.3.2 Security for Network Interfaces

7.3.3 Summary and Outlook

The 3GPP 5G security architecture builds strongly on the well‐proven EPS security architecture, but also introduces many new features such as:

• Introduction of EAP as an access independent authentication framework;
• Introduction of integrity protection for the user plane between UE and network (mandatory to support, optional to use);
• “IMSI‐catching” prevention by use of an encrypted subscription identity;
• Security for the SBA;
• Improved support for inter‐PLMN security.

Additional 5G security enhancements have already been discussed during the 3GPP 5G security study work [19]. Future enhancements may include the option to terminate user plane security between UE and network not in the RAN, but in a UPF within the core, aiming at scenarios where different core network slices may be operated by different parties sharing the RAN, in this case, user plane security terminated in an individual core slice would not be affected by attacks on the shared RAN. More security features related to network slicing scenarios involving multiple third parties may also need to be specified. Another area for enhancements is optimized security for new use cases, such as massive IoT and Ultra‐Reliable Low Latency Communication (URLLC) applications. This may include new lightweight crypto algorithms, new authentication methods, and new ways to store subscription credentials on mobile devices.

7.4.1 Separation of Forwarding and Control Plane

Due to the separation of forwarding and control plane, SDN introduces an interface between SDN controller and SDN switch. This interface increases the attack surface of the overall system. It could allow attacks on the integrity and confidentiality of the controller to switch communication, DoS attacks, or attacks aiming to get control over switches and controllers by exploiting vulnerabilities in the protocol software or the interface configuration. However, securing such an interface is a well‐known task and suitable means are readily available, such as usage of TLS [13] to perform mutual authentication and protect cryptographically the legal communication, thus protecting against any interception and excluding all communication faked by malicious third parties.

7.4.2 Centralized Control

The separation of forwarding and control plane allows to (logically) centralize the control of a network. While centralized control can contribute to unifying security policies and thus improve the overall network security, centralized control will also increase the impact of certain attacks, namely attacks that succeed in crashing or compromising such central controllers. Therefore, secure design and implementation minimizing the risk of vulnerabilities is essential for controllers.

7.4.3 Controllers Running in Cloud Environments

SDN allows to implement controllers on virtual machines in cloud environments. In this case, controllers will be exposed to threats present in such an environment and may be compromised via this environment. See Section 7.5 for a detailed discussion of NFV security. On the positive side, cloud environments can help to overcome DoS attacks by dynamically allocating additional resources to controllers.

7.4.4 Agile and Fine Granular Control

SDN allows an agile and fine granular control of the flows in a network. This facilitates the deployment of security solutions that may apply dynamic policies to flows, such as diversion, rate limiting or blocking. Care must be taken that fine granular policies do not introduce unnecessary complexity and the potential for errors into the network configuration.

7.4.5 Network Programmability via the Northbound Controller Interface

SDN introduces the so‐called northbound interface, where applications have access to SDN controllers. This allows implementation of new security solutions that make use of the possibility to execute central, and at the same time fine granular and agile control over the network via an SDN controller.

On the other hand, the concept of possibly several different applications, including third party applications (that may not be under the full control of the network operator) executing control over a network raises security issues, including authentication of applications, authorization of requests and resolving conflicting requests. These issues are certainly resolvable, but solutions must be designed and implemented with great care to avoid erroneous behavior caused by multi‐party network control.

As discussed in the context of centralized control, secure design and implementation is essential for SDN controllers. This applies to the northbound interface, to prevent malicious applications being able to compromise a controller via this interface and subsequently to exhibit unauthorized control over network resources.

Figure 7.7 visualizes the recommended SDN security measures. Of these, the most essential one is an SDN controller that is robust against overload and attacks, and implements sound authentication and authorization mechanisms at its northbound interface. An additional firewall around the controller may be used to fend off typical attacks that can happen in TCP/IP networks, for example so‐called TCP SYN flood attacks, where an attacker in the network tries to exhaust certain networking resources of a victim, here the SDN controller. Robust implementation and overload control also applies to the nodes that implement the data layer, the SDN switches. Traffic between applications and the controller and between the controller and the switches can be cryptographically protected by state‐of‐the‐art techniques such as TLS. While the actual effort for applying the cryptographic protocols may be negligible in this context, it must be noted that a key management solution is also required, which comprises the creation, distribution and maintenance of long‐term keying material – private/public key pairs and certificates in case of TLS. However, such a key management solution may be required independently of the use of SDN, for securing the management of network elements.

To summarize, SDN brings new security challenges to networks, when multiple, diverse applications are admitted to “program the network,” i.e. control network resources via northbound interfaces. However, SDN may enable more flexible and efficient deployment of security solutions, if those solutions can be implemented as software applications making use of SDN controllers without relying on traditional security devices. Building on this, SDN has the potential to make networks more secure.

7.5.1 Providing Highly Secure Cloud Software

It is therefore imperative that the virtualization layer, e.g. the hypervisor, is implemented with the highest care to minimize the likelihood of vulnerabilities. Likewise, all the virtualization software (sometimes called the cloud stack) must be sound and robust, and anticipate erroneous or even malicious behavior of all application software that may access cloud software application programming interfaces. The result must be a highly secure NFV platform.

Like the software of non‐virtualized network elements, VNFs must be designed and implemented with security in mind, following product creation processes that comprise steps such as a threat analysis for the respective function, the specification of a security concept, secure coding, hardening, security testing and auditing. Such steps will not guarantee error‐freeness, but they are supposed to drastically reduce the number of potentially exploitable errors. They also can give network operators a degree of assurance that the system will be secure against compromises by attackers. This so‐called security assurance clearly must consider the split between NFV platform and application software, and consider that VNFs may run on different hardware and/or software platforms.

7.5.2 Assuring NFV System Integrity

Relying on a sophisticated and well‐implemented security‐aware creation process may not be sufficient for NFV‐based 5G deployments – stronger trust in the integrity of a concrete deployment may need to be established. Based on a TPM (see [11]) acting as HBRT, integrity of the NFV platform can be ensured at boot time. Later, e.g. before launching a certain VNF, platform integrity may be verified by remote attestation mechanisms. Clearly, VNF images also need to be verified – an attacker may have been able to tamper with an image before the VNF is launched. Further, it must be ensured that a VNF can be bound to the verified platform (or set of verified platforms) – otherwise it may be migrated to a compromised one that may successfully attack the VNF, e.g. read out the VNF's confidential data. Means are available to achieve this goal. The interested reader is referred to [17].

7.5.3 VNF and Traffic Separation

Natively, a secure cloud provides separation of VNFs, but in a shared infrastructure, it is a logical separation only. There may be cases where a specific VNF or set of VNFs is considered so sensitive, that any side‐channel attacks, e.g. via a vulnerable hypervisor must be excluded. In this case, dedicated physical resources may be assigned to a VNF or a set of VNFs, not shared by other VNFs. This comes at the cost of reduced resource efficiency. It may be acceptable in large central data centers with abundant resources. When it comes however to small, distributed edge cloud deployments, resources may be so scarce that setting aside specific hardware resources for use by a specific application is not a valid option.

Complex networks normally use traffic separation as a security mechanism. For example, Operation and Maintenance (O&M) traffic may be fully separated from user plane traffic, using different virtual networks. Thus, malicious user plane traffic cannot disturb O&M of the network. This concept is fully applicable to NFV‐based networks. Hypervisors can support different virtual switches within a single hypervisor instance, dedicated to different traffic types. Virtual and physical switches can support different Virtual Local Area Networks (VLANs), and Virtual Private Networks (VPNs) can be created in wide area transport networks, thus allowing the creation of fully separated end‐to‐end networks for different traffic types such as user plane traffic, control plane traffic and O&M traffic.

7.5.4 Security Zones

Another well‐known network security measure is perimeter security and network‐internal traffic filtering to create different security zones within a network. For example, one zone may contain all network elements that need to communicate with peers outside the network, and another zone may comprise nodes with only network‐internal communication relationships. This concept can be transferred into NFV environments. Instead of physical firewall devices, virtualized firewalls will typically be applied, and virtualized intrusion detection systems may inspect the traffic for potential threats. In terms of functionality, such virtualized security devices are equal to physical ones. They have the advantage of flexible scalability, allowing them to cope better with floods of malicious traffic. On the other hand, one could argue that they are more endangered, as they may be attacked via the shared infrastructure they use. The separation between different security zones created via network internal firewalls is only a logical one. However, as pointed out above, on the cost of reduced resource efficiency, a physical separation may be implemented for a particularly sensitive security zone.

7.5.5 Cryptographic Protection

To ensure confidentiality and integrity of data in transit or on storage, cryptographic mechanisms may be used. For the traffic over 3GPP‐specified reference points, between mobile device and network, this type of protection has already been discussed in Section 7.3. Many interfaces inside an NFV‐based network will however not be standardized. Such interfaces do exist between VNFs, but also between different VNF‐components that may be implemented as different virtual machines and could be running on different physical platforms, interconnected by a network. Applying cryptographic protection on all these interfaces seems hardly feasible – not only in terms of computing effort and delay, but also in terms of key management. Moreover, it must be noted that attackers inside the NFV environment need not necessarily attack the traffic in transit – it may be much more rewarding for them to try attacking the virtual machines themselves, for example by trying to access their memory while relevant data is present in cleartext. Consequently, virtualized networks may rather rely on networking security provided by the cloud infrastructure, which ensures that a VPN specified to connect a specific set of virtual machines cannot be accessed by any other virtual machine or outside attacker. The cloud infrastructure may in turn apply cryptographic protection where it is needed. For example, the fibers interconnecting distributed data centers are physically exposed, and could become subject to various forms of tapping. Therefore, encryption of all traffic via these fibers must be applied, most likely to the aggregated traffic, thus reducing significantly the complexity of key management compared to individual encryption of individual traffic flows.

Concerning long‐term storage of data, e.g. on shared disk arrays, relying on general infrastructure security could be sufficient. For enhanced security, individual encryption with keys maintained within the VNFs seems a plausible option, as it would require an attacker, in addition to gaining illegal access to the stored data, to also successfully attack the VNF and retrieve the keys.

7.5.6 Secure Operation and Management

Secure operation and management is crucial for non‐virtualized as well as for virtualized networks. In the latter case, the dynamic nature of the network and the complexity of having potentially many different network slices sharing the same infrastructure pose a specific challenge. As discussed in Section 7.2, a high degree of automation can help to cope with this challenge.

7.6.1 Isolation

When slicing a network, i.e. creating multiple virtual networks on a common physical infrastructure, the typical intention is that each of these virtual networks is independent of the other virtual networks. If we assume network multi‐tenancy, where different parties operate different slices, network slice isolation becomes the crucial security aspect. We can distinguish two isolation aspects – resource isolation and security isolation. The former refers to the fact that resources assigned to a network slice (such as computing, storage and networking resources) cannot be “hijacked” by any other slice. This does not mean that each slice always has the same, fixed amount of resources available. Rather, a Service Level Agreement (SLA) between slice operator and InP may specify for example a minimum amount of resources that is always guaranteed, and may further specify terms and conditions for the usage of additional resources. Resource isolation ensures that the SLA is fulfilled, even in situations where other slices may suffer from overload situations or DoS attacks. Security isolation refers to the property that information in one slice cannot be accessed or modified by other slices sharing the same infrastructure.

As pointed out in Section 7.5, sound NFV security can ensure both types of isolation within NFV environments. For the transport between distributed cloud deployments, VPN techniques can be applied to ensure isolation, where SDN allows for highly dynamic and flexible control of different VPNs sharing the same transport infrastructure. Slices may also share non‐virtualized equipment, for example base station equipment handling the lower protocol layers. Here, isolation needs to be assured by respective equipment‐specific mechanisms. For example, when several slices share a single cell, a common radio scheduler may be configurable to implement scheduling policies that ensure that each of the slices gets radio resources in this cell according to the SLA valid for the slice.

Obviously, isolation works better the less common resources are used. Not sharing physical infrastructure would therefore be the best isolation approach, but this is clearly out of question, considering the huge advantages expected from infrastructure sharing. Still, in some cases it may be reasonable to use even physical separation, like for example physically separating different subscription databases used by different slices.

If we assume a model where an InP rents out slices to third party organizations, such as industry verticals, then with sound isolation mechanisms in place, a slice used by a third party organization may be isolated from other slices. However, there is no native isolation against the InP itself, who is in control of the infrastructure and can access all the information that is processed on it. So third parties operating slices must trust the InP not only to take suitable measures to ensure isolation between slices, but also to ensure that InP access capabilities are not abused to access private third party data. Among others, this means that also the threat of malicious insiders within the InP organization must be considered and suitably mitigated.

7.6.2 Enhanced Slice Isolation Infrastructure

An industry vertical may need to provide 5G connectivity for, as an example, Industry 4.0 (I 4.0) applications on the vertical's factory plants, and for this purpose rent a suitable network slice from a network operator providing the infrastructure along with the NFs that constitute the network slice. The vertical becomes a tenant of the network operator. The slice provides connectivity between the I 4.0 devices and a Data Network (DN) operated by the vertical that hosts the I 4.0 application servers. If the applications are highly sensitive, the vertical may not simply trust the network operator to ensure isolation, but desire better, enforceable isolation. As described in [28] and outlined in the following, there are different ways how this can be achieved.

7.6.3 Other Aspects

The slicing concept is meant to provide virtual networks optimized for specific applications. This optimization may also apply to security mechanisms. Moreover, slices may have individual security assurance levels, focusing security assurance efforts on those applications where it is most meaningful. The assurance level of a slice is limited by the assurance level of the underlying infrastructure.

While a single slice may be lean and easy to operate and control, a whole network hosting many slices is much more complex than a traditional, un‐sliced network. The attack surface will therefore be larger in a network comprising multiple slices, in particular in network multi‐tenancy scenarios, where third parties like industry verticals operate individual slices. Interfaces and procedures provided by the network operator to third parties for managing slices must be carefully secured and management operations must be authorized. Similarly, when slices controlled by verticals have interfaces to common parts of the network controlled by the operator, these interfaces must be secured and access must be authorized. The same holds for inter‐slice communication in the sense of communication between (virtual) networks operated by different organizations (network operators or third parties). Other slicing specific procedures that may increase the attack surface, and must therefore be secured, diligently comprise slice selection procedures and slicing‐specific authentication and authorization procedures.

With sound slice isolation, a DoS attack on a single slice will not affect other slices in the same network. However, a slice that is engineered for a “small” application, like for a small number of mobiles and/or a low amount of traffic may rather easily be overwhelmed by a flooding attack, compared to a large, un‐sliced network. DoS attacks against specific slices can probably be carried out even if the slices are not explicitly made visible by the network, because the existence of specific slices may be hard to conceal in the longer term.

A threat that may arise in case of simultaneous connectivity of a UE to several slices is the forwarding of malicious traffic between different slices via the UE. However, this would mean the UE acts maliciously, probably because of some malware having been installed. As a network or slice needs anyway be protected against malicious or erroneous UE behavior, no specific security measures may be required against this threat.