Beyond PS-LTE: Security Model Design Framework for PPDR Operational Environment

National disasters can threaten national security and require several organizations to integrate the functionalities to correspond to the event. Many countries are constructing a nationwide mobile communication network infrastructure to share information and promptly communicate with corresponding organizations. Public Safety Long-Term Evolution (PS-LTE) is a communication mechanism adopted in many countries to achieve such a purpose. Organizations can increase the efficiency of public protection and disaster relief (PPDR) operations by securely connecting the services run on their legacy networks to the PS-LTE infrastructure. This environment allows the organizations to continue facilitating the information and system functionalities provided by the legacy network. The vulnerabilities in the environment, which differ from commercial LTE, need to be resolved to connect the network securely. In this study, we propose a security model design framework to derive the system architecture and security requirements targeting the restricted environment applied by some technologies for a specific purpose. After analyzing the characteristics of the PPDR operation environment under the PS-LTE infrastructure, we applied the framework to derive the security model for organizations using PPDR services operated in their legacy network through this infrastructure. Although the proposed security model design framework is applied to the specific circumstance in this research, it can be generally adopted for the application environment.


Introduction
Advances in mobile communication technologies enrich civilians' lives and enhance the operational efficiency for public protection and disaster relief (PPDR). The technologies connect agents from fields and command posts to increase their field functionality. Besides, response agencies can enhance their mutual co-operation by exchanging information over a shared communication channel.
Many countries have constructed mobile communication network infrastructures for PPDR. However, cutting-edge mobile communication technologies have rarely been adopted as a communication mechanism. Instead, some functionalities required for PPDR are added to the technologies whose reliability and safety are guaranteed through experience.
LTE is one of the most widely used mobile communication technologies and is used by 262 operators in 120 countries, the number of which continues to increase [5]. The earliest standard related to LTE 1 was published in 2007, and the first commercial network was launched in 2010 [14].
In 2013, 3GPP defined Public Safety LTE (PS-LTE) by adding the system features of LTE, namely, a proximity-based service (ProSe) and group communication system enabler (GCSE). The standards of these features were included in 3GPP release 12 in 2015. One year later, in 3GPP release 13, additional PPDR functions, including mission critical push-to-talk (MCPTT) and an isolated E-UTRAN operation for public safety (IOPS), were applied.
PS-LTE networks are widely spreading as a communication mechanism for PPDR in many countries. Figure 1 shows the global status of PS-LTE diffusion as summarized in [2] 2 . Organizations using the PS-LTE infrastructure need to provide the services run on their legacy network to the infrastructure to increase the effectiveness of a PPDR operation. The services allow the organizations to continue facilitating the information and system functionalities provided from the legacy network.
A security threat analysis for the operation environment is necessarily preceded when designing a secure system linking architecture between the PS-LTE infrastructure and the legacy networks. The protection mechanisms of most of the analyzed threats should be reflected in the system architecture design. However, the security requirements of the system components against other threats also need to be subtly tightened.
We extensively consider not only the operational environment but also the overall system elements and provide the technical guidelines practically applicable to organizations using the PS-LTE infrastructure.

Contribution
The main contributions of this paper can be summarized as follows: First, a security model design framework is used to construct an environment adapting to certain technologies for a specific purpose. In addition, we designed the system architecture and security requirements for the user organization in PPDR operational environment on PS-LTE infrastructure.
In the security model design framework section, we propose the general framework used to design the security model by analyzing the security threats, building the system architecture, and deriving the security requirements for the construction of an environment in which certain technologies are applied for a particular purpose.
In the next section, we describe the application results of the proposed framework used by PPDR organizations under the PS-LTE infrastructure. First, we analyzed the characteristics of the operational environment from the aspect of user organization on PS-LTE infrastructure. This analysis will help the user organization raise situational awareness of their systems, applying PS-LTE infrastructure.
We constructed a baseline security level test-bed, as described later, and conducted empirical studies of the security threats toward the test-bed environment. Finally, we designed a secure system architecture to connect a legacy network to a PS-LTE infrastructure while protecting the identified security threats. To fill in the security gaps that the architecture cannot cover and tighten the security level, we provide the security requirements of the system elements that must be satisfied.
We want to mention that our empirical studies on the test-bed constructed using the hardware used in the PS-LTE environment in the field may not be fully generalized depending on the vendors and the system versions, the operational environment, and so on. However, the security model design framework and the application example can provide insight on how to enhance the security of PS-LTE based PPDR operational environment.
The following section provides the preliminary technical background required to understand this study.

Basic Structure of LTE
The basic concept of the LTE system structure is described in [10] and schematized in Figure 2. In the figure, the dotted and solid lines represent two logical planes separated in an LTE network depending on the functionalities of the data; the user and the control plane, respectively. The LTE network transfers the data necessary to operate and maintain the network properly through the control plane. The user plane is responsible for carrying data that users intentionally generate (e.g., voice communication, SMS, application traffic) and sent over the network.
The following subsections describe the key points of the components making up the LTE structure. User Equipment (UE) UE includes cellular devices, such as cell phones and tablets, interacting with base stations through radio signals. Several components make up a UE and indicate its identity. Mobile Equipment (ME) includes mobile terminals made by cell phone manufacturers.
A Universal Integrated Circuit Card (UICC), also known as a Universal Subscriber Identity Module (USIM), is a smart card inserted into an ME. UICC stores the cryptographic key used for the authentication and key agreement (AKA) with the LTE network. UICC also contains a network ID, called a Public Land Mobile Network (PLMN), from which the Mobile Network Operator (MNO) of the UE obtains LTE service.
A UE has two permanent IDs assigned by the manufacturer and the MNO, an International Mobile Equipment Identifier (IMEI), and an International Mobile Subscriber Identity (IMSI).
Evolved Universal Terrestrial Radio Access Network (E-UTRAN) An UE transmits and receives a radio signal to/from the base stations, which is called Evolved Node B (eNodeB or eNB), to communicate with the core network. E-UTRAN is a mesh network composed of eNodeBs that modulate and demodulate radio signals.
Evolved Packet Core (EPC) EPC is the brain of an LTE network. It authorizes UEs to connect to the network and manages their connections. The following are the key components included within the EPC.
• Mobility Management Entity (MME): The primary entity treats signal plane data, including the functionalities that control AKA procedures between UEs and Home Subscriber Server (HSS), and selects gateways that route user plane data sent to/from the UEs. IP Network Any external IP network connected to an LTE network is called a Packet Data Network (PDN). The P-GW routes the data from a PDN. The gateway between the EPC and PDN is called an Access Point Name (APN), which also serves as the identifier of the PDN. A UE must be assigned APNs to connect to the PDNs.

PS-LTE Characteristics
PS-LTE provides additional features to support an effective PPDR operation compared to a conventional LTE system. Group communication system enabler (GCSE) is a fast and efficient mechanism to distribute various media content to multiple users in a controlled manner. Proximity-based Services (ProSe) enable direct and relayed communications among neighboring UEs without passing the core network. IOPS provides the ability to maintain communications following the loss of a backhaul connection. In addition, MCPTT supports enhanced PTT services suitable for mission critical scenarios. Table 1 lists above features and related 3GPP documents. The specifications of the features can be found in the documents.

Related Studies
Researches into LTE security vulnerabilities help to understand security threats on the proposed security model design framework. In [16], LTEInspector is proposed, which analyzes the LTE system by leveraging the combined power of a symbolic model checker and a protocol verifier through a model-based adversarial testing approach. For three critical procedures of the 4G LTE protocol (attach, paging, and detach), ten novel and nine known attacks were found using LTEInspector.
In [28], the vulnerabilities of the RRC protocol are analyzed corresponding to the layer two LTE protocol. The authors assumed two types of attack models, passive and active. In their analysis, they found identity mapping and website fingerprinting vulnerabilities under the passive attack model. In addition, a DNS spoofing vulnerability was identified through the passive attack model. The authors also demonstrated the feasibility of all three attacks using realistic setups.
In [19], a semi-automated testing tool, LTEFuzz, is implemented, which is a dynamic testing tool targeting the control plane procedures of an LTE network. The authors identified 15 known and 36 new vulnerabilities among different commercial LTE networks and device vendors. They also demonstrated several attacks based on the vulnerabilities. The attacks caused a denial of service, phishing messages, and eavesdropping/manipulation of the data traffic. Table 2 summarizes the characteristics of the approaches in [16,19,28].
In [25], the researchers survey a number of new security threats to cause unexpected service interruption and disclosure of information in 4G. They also found there still remain several open issues although many are working on fixing and/or designing new security architectures for 4G. This helps us to build security model design.
There are security threats on LTE system in [12,22,23]. These works are relevant to our security threat analysis on 6.6. We analyze the security threats on PPDR operational environment and build system architecture preventing security threats.
In [23], attacks toward an LTE system are classified into four groups: 1) attacks against security and confidentiality such as Evolved Packet System Authentication and Key Agreement(EPS-AKA) security issues or a management handover key failure, 2) IP-based attacks against a backhaul, GPRS Tunneling Protocol(GTP), voice over LTE(VoLTE) Session Initiation Protocol(SIP), and diameter, 3) attacks on the signal plane and 4) jamming attacks on the physical layer.
In [12], the researchers survey existing authentication and privacy-preserving schemes. They present four threat models classified into privacy, integrity, availability, and authentication, three countermeasures classified into cryptography methods, humans factors, and intrusion detection methods. They provide a taxonomy and comparison of authentication and privacy-preserving schemes for 4G and 5G cellular networks in the form of tables.
The LTE security threats against jamming, spoofing, and sniffing at physical channels are researched in [22]. The researchers measured each LTE jamming attack's complexity and efficiency and identified which channel/signal is the weakest. Due to LTE is not designed to become a mission-critical communication technology, it is highly vulnerable to jamming attacks.
The IMSI-catchers, also known as cell-site simulators or stingrays, are threats to LTE system subscribers. They act as rogue base stations that can track cellphone locations and often eavesdrop on cellular communications. The works for catching IMSI-catchers help us to analyze threats against rogue base stations.
In [11], there are two implementations of an IMSI Catcher Catcher(ICC). IMSI Catchers identify and eavesdrop on phones in mobile networks, and ICC detects this threat. They implemented ICC with stationary measurement units and app for standard consumer grade mobile phones.
In [24], Seaglass is a city-wide cell-site simulator detector. Seaglass is capable of detecting anomalies across a wide variety of signature classes, potentially caused by actual cell-site simulators. This may be needed to PPDR operational environment preventing from city-wide tracking and eavesdropping on cell phones.
The other proposal for enhancing subscribers' security is using multiple IMSIs for a mobile telephony subscriber. The proposed schemes in [17] provide a form of pseudonymity on the air interface, even when it is necessary to send the IMSI in cleartext. The schemes reduce the impact of user privacy threats arising from IMSI capture.
Although the system is designed to be secure, threats maybe still existing. The existing errors in implementation or configuration generate threats to LTE system. The LTE specification must be implemented accurately in PPDR operational environment.
In [9], four misconfigured networks and multiple cases of implementation issues are existing in commercial networks. The researchers analyze the security configuration and test the security algorithm selection in a total of twelve LTE networks in five European countries.
According to [30], several modern smartphones are not implemented with the LTE specification. They do not inform the user that even the user data is sent unencrypted. The researchers present Man-in-the-Middle(MitM) attack against an LTE device that does not fulfill the network authentication requirements.
The srsLTE, in [13], is an open-source platform for LTE experimentation, designed for maximum modularity and code reuse and fully compliant with LTE Release 8. It is applicable to experimental LTE test-bed platforms and testing LTE configuration or implementation. It can be used as either UE or base stations with software-defined radio (SDR) device. This implementation helps us to understanding attacks by UEs(6.3) like type 2 and type3 or rogue base station(6.3) in our research.
In [15], among 28 carriers, 19 carriers have easily predictable and consistent patterns in GUTI reallocation mechanisms. Revisiting 4 carriers, they also have predictable patterns after invoking GUTI reallocation multiple times within a short time period. By using this predictability, the adversary can track subscribers' locations.
Early VoLTE implementations contain several vulnerabilities that lead to serious exploits, such as caller spoofing, over-billing, and denial-of-service attacks. VoLTE is also used in mission-critical-push-to-talk(MCPTT), which is one of functionality in PS-LTE. [18] and [20] are dealing with these vulnerabilities in VoLTE.
Unlike the traditional call setup, the VoLTE call setup is controlled and performed at the Application Processor(AP), using the SIP over IP. A legitimate user who has control over the AP can potentially control and exploit the call setup process to establish a VoLTE. In [18], the researchers identified a number of vulnerabilities of early VoLTE and proposed immediate countermeasures that can be employed to alleviate the problems but the more comprehensive solution that eliminates the root causes may be needed.
In [20], several vulnerabilities exist in both control-plane and data-plane functions that can be exploited to disrupt both data and voice in operational networks. The proof of concept attacks are validated using commodity smartphones in two Tier-I US mobile carriers. It is possible that these vulnerabilities also exist in smartphones used in PS-LTE system.
Four root causes for attacks in the current mobile network(2G, 3G, and 4G) are analyzed in [29]: wireless channel, protocol context discrepancy, an implementation issue, and specification issue. The researchers categorize known attacks by their aim, proposed defenses, underlying cases, and root causes. This paper classifies threats into root causes compared to our paper.
The authentication and key agreement(AKA) algorithm used in LTE system has several vulnerabilities. [21,33] are researches about identified vulnerabilities of AKA and improved authentication algorithm. These are needed for our security requirements to UE and PS-LTE infrastructure(6.7).
In [21], Evolved Packet System Authentication and Key Agreement (EPS AKA) procedure is used to provide mutual authentication between the user and the network in the LTE/SAE architecture has several vulnerabilities such as disclosure of user identity, man-in-the-middle attack. The proposed Security Enhanced EPS AKA(SE-EPS AKA) can satisfy the security and efficiency properties in the LTE/SAE architecture.
In [33], the lack of identity protection at the first initial attaches and the lack of perfect forward secrecy for the AKA mechanism are access-level security issues that may arise at the eNodeB, UE and MME level. The proposed usage of Password-Authenticated Key Exchange by Juggling(J-PAKE) protocol instead of AKA protocol suited for use in the mobile device environment.
We analyze security threats and design the system architecture(6.7), enhancing security. The researches about security requirements and LTE security enhancement helps us to propose system security requirements in detail.
In [27], eight main Security Requirement Engineering(SRE) activities are proposed for Cyber-Physical System(CPS). The purpose of these activities is to identify security requirements in a heterogeneous CPS system. In the case study of smart car parking systems, 40 security requirements are elicited following their activities. Compared to our research, this work just focused on the efficiency of the SRE framework. The researchers identified security threats and assessed the risks of a car parking system to evaluate eight SRE frameworks.
In [26], the proposed Security Improvement Framework(SIF) can predict and protect various potential malicious attacks in the Zigbee network and respond accordingly through a notification to the system administrator. The designed SIF has been implemented in an office security system as a case study for realtime monitoring. The evaluation results show the capacity for detecting and protecting several potential security attacks. The researchers have categorized attacks by key requirements and network layers. There are some limitations to applying this methodology to our works because our study's target system is more complicated than the Zigbee network.

Security Model Design Framework
Some systems can be used in ways that were not intended when developed. In addition, some technologies are adopted to implement environments that are not intended to be developed. In either case, the security model should be properly designed for modified environments.
To overcome this issue, we propose a practical framework for the security model design for a particular application environment, as shown in Figure 3. The framework enables the design of the security model for the system composed of the components developed as heterogeneous purposes. To reduce the scope of a security threat analysis ( 1 ), our framework applies certain assumptions based on the application environment and the actual restrictions. If necessary, some of the assumptions can be satisfied by enforcing them as the security requirements ( 2 ). The threats neither within the analysis scope nor covered by the assumptions are accepted risks. Following a security analysis for a reduced analysis ( 3 ), some of the threats are protected by modifying the system architecture ( 4 ), and others by specifying the security requirements of the system ( 5 ).
In this framework, one can adopt any available security threat modeling methods, including those introduced in [31]. If the method requires the data flow diagram (DFD) as an input, the coverage of the DFD should be restricted by applying the analysis scope.
The goal of the security model design framework is to improve the security of a system. Some of the threat modeling methods also provide a guide to discover security control that effectively removes, counter, or mitigate all relevant vulnerabilities. For example, PASTA [32] includes the countermeasure indication process. Since PASTA focuses on the software security aspect, the countermeasures are derived as the form of additional the security functions. LINDUN [34] deals with security problems as the privacy aspect. In the mitigation strategy elicitation step of LINDDUN method, the privacy-enhancing technologies (PETs) are provided to obtain privacy. OCTAVE [8] has the step to select the protection strategy among accepting, mitigate, and defer as introduced in ISO 20071. These threat modeling methods provide conceptional mitigation strategies, techniques, and functionalities. Compared with these threat model methods, our security model design framework specifies the mitigation strategy to the system architecture modification and the security requirements specification, which includes additional functionalities and software modifications. Therefore, this framework helps to understand how to reflect the mitigation strategy to the system.
The framework can be clarified through the application demonstrated in the following section. As aforementioned, the mitigated strategy toward the security threats belonging to Table 3 against the initial system in Figure 5 are specified to the improved system structure in Figure 6 and to the system requirements in Table 7.

Application to the PPDR Operational Environment under PS-LTE Infrastructure
Before the scope restriction step, the operational environment characteristics from the user organization aspect of the PS-LTE infrastructure need to be analyzed to support the situation awareness.

Analysis of Operational Environment
PS-LTE is a network infrastructure allowing the PPDR organizations to communicate and share information regarding an operation. To conduct security threat analysis and derive proper security requirements, it is crucial to understand the operational environment through which several organizations share infrastructure and connect their legacy systems. Figure 4 demonstrates the characteristics of the PPDR operational environment based on the PS-LTE infrastructure.

Fig. 4. PPDR operational environment characteristics based on the PS-LTE
The components consisting of the operational environment can be categorized into UEs, LTE infrastructure, and IP networks. Individual users utilize the UEs owned by their organizations, and the device information is registered in LTE infrastructure, specifically in the HSS. All personnel conduct operations using their UEs under a shared LTE infrastructure (eNodeBs and EPC), and services (e.g., VoLTE, SMS, and MCPTT) are managed and controlled by another authority. Legacy IP networks can be connected to the LTE infrastructure to provide unique services required for each organization.
In terms of the connection characteristics, UEs can communicate not only with UEs under the same organization but also with those under different organizations. The connected legacy IP networks are reachable from all registered UEs even when they belong to different organizations.
These characteristics invoke environment-specific vulnerabilities, which must be prevented using features primarily provided by the LTE system.

Assumptions
Two assumptions and their effects on the analysis are described below.
A1. PPDR organizations are unable to affect a PS-LTE system. The requirements of the PS-LTE system are defined in the standards, as summarized in Table 1. Because PS-LTE is based on the LTE system, more standards exist to define a plain LTE system. Although several vulnerabilities caused by the standard issues have been reported [19], PPDR organizations are typically not the stakeholders resolving such issues.
By this assumption, we exclude the LTE and PS-LTE standards from our research scope.
A2. Security of the shared infrastructure and services are provided by the host organization. The authority and responsibility to maintain and control the shared infrastructure and common services, as shown in Figure 4, are typically established for an organization. Security requirements of the infrastructure and services should be applied and verified during the system construction. In addition, they should be monitored by the organization. The PPDR organizations need to trust the security status maintained by the host organization.
Based on this assumption, we consider the threats to the UEs and the IP network connectivity inside attackers authorized to connect to the EPC and rough eNodeBs that are not linked to the infrastructure.

Analysis Scope Reduction
We categorized the types of security threats within the research scope considered in this study. To analyze the security threats and conduct empirical studies on them, we also designed and built a test-bed. The threat categories and test-bed structure are graphically shown in Figure 5.

UEs of other organizations (type 2)
Other UEs (type 3) rouge eNodeBs  5. Categories of security threats and test-bed structure applied baseline security Category 1. UE UEs are sub-categorized into three types depending on their authorization to use the infrastructure and entities. A type 1 UE is owned by the same organization operating the linked entities and is able to obtain services provided by these entities. Thus, a type 1 UE is authorized to use the infrastructure and linked entities. A type 2 UE is owned by other organizations using a shared infrastructure. This type of UE can use the infrastructure but should be prohibited from using the linked entities. A type 3 UE is not even authorized to use the infrastructure regardless of having the transmission ability of the same physical radio frequency as type 1 and 2 UEs.
Each type of UE comprises a security threat. Type 1 UEs can be misused (1.1), and type 2 and 3 UEs can threaten type 1 UEs (1.2 and 1.3). Furthermore, all types of UEs can have an adversarial effect on the connected entities (1.4).
Category 2. eNodeB Assumption A1 excludes eNodeBs belonging to a shared infrastructure from this research. However, eNodeBs that are not connected to the infrastructure for an adversarial intention still threaten type 1 UEs by resulting in an unintended connection (2.1).
Category 3. EPC Based on assumption A2, the threats through an EPC are monitored, although it is difficult to monitor those originating from the EPC. We consider the threats by an insider attack (3.1) from the EPC side to the IP networks and HSS A , which is operated by the user organization and set as baseline security. The reason for this is described later.

Category 4. IP network
We apply a virtual private network (VPN) gateway and an external app server in the baseline security of an IP network, the reasons for which are described later. We also derive the threats that can bypass the baseline security (4.1 and 4.2). Table 3 summarizes the categories of security threats within this research scope.

Test-bed structure
To conduct an empirical study and analyze the security threats, we constructed a test environment applying HSS A connected to an EPC controlled by the user organization, a VPN gateway, and an external app server as the baseline security elements, as shown in Figure 5. These are selected to make critical data controllable by the organization and protect the processes and data flow originating from the organization in terms of threat modeling [6].
The HSS stores the cryptographic keys matched to the UEs. These keys are essential to protect the UEs and the network because they are used for mutual authentication between the UEs and the LTE network. The user organization needs to be able to control and protect such data even from the operating authority of the shared infrastructure. For this objective, HSS A independent from HSS belonging to the shared infrastructure is added to the entities of the user organization. Because the authentication vector, which is generated using the keys and sent to the MME from the HSS for mutual authentication, does not contain the keys [4] [10], the objective can be achieved through this baseline security. A subscriber location function (SLF) is required to operate more than two HSSs by selecting the HSS used for the authentication [3].
The LTE network provides confidentiality and an integrity protection mechanism for control and user plane data. However, the application of the confidentiality protection of both planes remains an option of the network operator [4] [10]. To protect the data flow originating from the user organization's IP networks, the VPN gateway is required to encrypt the user plane communication channel between the UEs and IP networks regardless of the operating authority. We used SSL VPN, which works on the application layer.
The last baseline security element is the external app server. The user organization's internal web server providing the PPDR services is one of the assets belonging to the organization's legacy network where critical data are saved and transmitted. Although the radio frequency band is physically separated from that of a commercial network, it is risky to allow the UEs to connect to the web server directly. The app server is located between the web server and the UEs and operates as a proxy in the demilitarized zone (DMZ), which transmits traffic from the UEs to the web server in the proper format. We also implemented the service policy function in the web server, controlling the services to be provided to the app server. Through this mechanism, UEs allow only permitted services based on policy among the services running on the web server.

Security Objectives
In Table 4, we list the general security objectives for the data and assets of the PPDR service environment linked to PS-LTE. Table 4. Security objective of the PPDR service system environment linked to PS-LTE No. Security objectives 1 Confidentiality, availability, and integrity of data between the user organization and its UEs should be protected. 2 Unauthorized access to the assets of the user organization should be denied.
Based on the first assumption described above, we only set the confidentiality, availability, and integrity protection of the user plane data between the organi-zation and the owned UEs as the first security objective. The second objective defines the denials of access that are unnecessary to provide and maintain LTE and PPDR services.

Security Threat Analysis
For each security threat category listed in Table 3, we have drawn several potential threats. The numbers of threats and their examples are provided in Table 5. 3 Compared to [7] and [1], which document security threats applicable to a general LTE and mobile environment, our threats mostly target the specific operational environment described earlier. Total number 84 Table 6 shows the statistics of the impart for each threat category. We assumed that the priority of system security is in order of integrity, confidentiality, and availability. In terms of confidentiality of data, the plain text data in order of the deciphered user data and the system configuration data is important than the ciphered data. Therefore, we defined the categories of the threats impact crucial, high, medium, and low, where definitions of each are described in Table 6.
It is worth noting that over 90% of the threats belonging to the EPC category show crucial or high impact. Since all user and system data between UE and IP network, including cipher setting information transferred through S-GW and P-GW, the threats in this category cause the most significant impacts.

System Architecture and Security Requirements
To prevent the analyzed security threats at the architecture level, we designed the system architecture ( Figure 6) by enhancing the security features of our test-bed structure ( Figure 5).  The necessities of each entity except for those described in section 6.4 are as follows.

S-GW
• S/P-GW A : allocates IP to UEs within distinguishable range and protects from a sniffing of the user data • LTE firewall: enforces LTE signaling data transferred only between components through protocols defined in the specifications • APN firewall: protects IP network from unallowed external access and LTE components from unallowed internal access • DMZ firewall: allows network access only to legitimate app-web server pairs and certain services/protocols • Security systems: enforce security policies to UEs • Monitoring system: watches for prohibited or abnormal network access The specifications of the security requirements used to protect from the threats, categorized as UEs, infrastructure, and the service system, are listed in Table 7. The UE category includes the requirements directly implemented in and applied to the UEs through security systems. The infrastructure category covers EPC, S/P-GW A , LTE, APN firewalls, and a transfer cipher function (VPN). The service system category corresponds to apps and web servers, as well as a DMZ firewall.

Conclusion and Future Work
To design a security model in a PPDR operation environment under the PS-LTE infrastructure, we first introduced a framework for designing the security model for the environment under which the technologies are adopted for a specific purpose. In addition, we demonstrated the application results in the target environment. As a result, the system architecture and the security requirements for the system are designed as the security model.
The main observation in the framework application example in section 6 is that even the cryptographic setting information can be sniffed from the S-GW and the P-GW. For a reason, we proposed constructing the S-GW and the P-GW that are owned by the user organization. However, the security objective can also be achieved by using IPSec VPN, which works on the network layer. Since IPSec VPN supports the symmetric cipher, the cryptographic key exchange is not required.
During the proposed framework application under the PPDR operational environment, the PS-LTE technologies defined in standards such as GCSE, ProSe, and IOPS are excluded from the analysis based on certain assumptions. However, these technologies may cause security threats, which have yet to be researched. We would like to extend this analysis's scope to increase the security of the PPDR operational environment.

UE
-restrict to only access the LTE network (PLMN 4 ) that the shared infrastructure (PS-LTE) operates -prohibit from accessing other IP networks except those operated by the owner organization -restrict not to provide network functionalities that enable other devices to access the IP networks, e.g., hotspot and tethering -protect external storages to be read -apply data leakage protection, e.g., use data store ciphering or build a cloud system to prohibit UE from storing data -enforce memory protection and apply PIN to USIM -enforce user to UE authentication -allow to transceive only the PS-LTE radio frequency bands (enforced requirement) -enable minimum functionality of UE when network is disconnected or the mobile device management (security) policies are not applicable -allow only the mobile service application to be installed in the white list -enforce encryption/decryption of all data tranceived from/to UE -enforce the security policies to be applied after the factory initialization of UE -protect the mobile applications to enforce security policies to be terminated and removed -keep the versions of OS and the mobile applications installed in UE up to date and confirm the integrity of the update files -prohibit to execute all functionalities of rooted UEs PS-LTE infrastructure -enforce multi-factor authentication for user to UE, user to infrastructure (network), and user to services authentications -check validity of IMSI and IMEI pair and user and UE pair during network connection -allow connections between LTE components only specified in standards and restrict the connections to service/protocol level -allow UE connection to IP network only to those allocated IP within distinguishable range -continuously change ciphering keys for transferring data even within the same session -enforce the traffic tranceived between type 1 UE and IP network of an organization to pass P-GWA and S-GWA, not P-GW nor S-GW -allocate IP address to type 1 UEs distinct to other UEs -use security certified devices consisting the security systems PPDR service system -provide API to call functions in web server and defines/sets authorization levels considering user types -prohibit from executing the functions for which the API is not defined -provide services run in web server to UEs only through app server -do not store any generated or passing data to app server during service; app server behaves like a proxy -develop the mobile service applications as in-app fashion and check if requests sent from UE generated by the applications; apps must not rely on browser -develop mobile service applications applying obfuscation technologies -develop the app/web server programs and the mobile service applications following the secure coding norms -use security certified devices consisting the security systems