1. Introduction
In the current rapidly changing digital environment, the Internet of Things (IoT) has become a core requirement for next-generation computing, and network functions are being added to most existing and newly launched products. Individual products are connected to form a large network through a network and provide new services through the interactions between products and users. The concept of connectivity has emerged, and as the data and information of products change the competitive landscape and industry definition, it is changing into a new type of competitive environment. “Connected car services” can be called one of the representative connected services at the center of these changes.
The connected car services are creating new business opportunities through real-time fault diagnosis or real-time response for vehicle safety [1,2]. Ford uses location-based information to provide drivers with real-time traffic conditions, which can be used for road guidance, and provides services that allow users to enjoy various entertainment through cloud-based contents inside the vehicle [3]. Since the feasibility of the connected car services revenue model has been verified, interest in the connected car services is growing [4].
With the increasing interest in connected car services, there are concerns regarding the adequacy of security preparations for securing them. Attackers already view automobiles as new targets for attacks, and if they are compromised, they are expected to pose a significant risk. Therefore, in this paper, we aim to identify security threats to connected car services and analyze security vulnerabilities.
2. Related Work
2.1 Connected Car
Recently, the term “hyper-connected society” has been used frequently. Hyper-connected society refers to an environment in which people, objects, and spaces are all connected through networks and in which information is created or collected, shared, and utilized. It is expected for the future to change significantly due to the IoT and artificial Intelligence (AI), which are digital technologies that continue to develop in a hyper-connected society [5].
A connected car is a vehicle that is connected to a network and provides various services, including autonomous vehicles and smart cars. By using a connected car, it is possible to provide services such as remote start and remote diagnosis of the vehicle, telephone, message transmission and reception, e-mail transmission and reception, real-time traffic information confirmation, and emergency rescue through the network with the inside or around the vehicle. Drivers can drive comfortably using a connected car connected to the network. The main functions of a connected car include a mobile management function that allows drivers to reach their destination safely and quickly, a vehicle management function that reduces operating costs and adds convenience to operation, an entertainment function that provides entertainment to the driver and passengers, and an in-vehicle and There are a safety function that notifies the driver of external dangers, and a driver assistance function that enables partially autonomous driving, and a well-being function that provides comfort to the driver [6].
The connected car is an evolution of past telematics technology and is related to machine-to-machine communication and intelligent transportation system technology (Fig. 1). Telematics uses information communication technology technologies, including networks, to provide services such as vehicle location tracking, Internet connection, remote vehicle diagnosis, remote accident detection, and traffic information [7,8]. In addition, in-vehicle telematics is being advanced in line with the recent development of communication technology, including IoT [8].
Overview of the connected car system.
The connected car services are expected to evolve into a convergence service where network functions are improved, infotainment functions are expanded, and communication services are strengthened. It executes the optimization algorithm and transmits it to the maintenance team and driver to perform vehicle diagnosis and regular inspection, saves fuel economy, provides a driving guide, and is expected to develop into an autonomous vehicle.
2.2 Threat Modeling
The purpose of threat modeling is to use a model to find security problems in a product or a service. Threat modeling has existed in the past, but it has been studied in earnest since the 1990s. In general, when performing security threat analysis using threat modeling, the product is analyzed first, the threat is identified, the attack tree is created, and then the vulnerability checklist is derived in this order. Researchers usually create an Attack Library that collects previously known vulnerabilities to derive an attack that can occur from each threat, and they work with reference to this Attack Library [9,10] (Table 1).
Types of threat modeling [ 9, 10]
STRIDE is an acronym for potential security vulnerabilities. It stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege [11]. LINDDUN is one of the threat modeling methods, primarily used for analyzing threats to personal information. LINDDUN consists of the first letters of six properties: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance.
3. Security Threat Modeling for Connected Car Services
3.1 Structural Analysis using DFD
In this paper, STRIDE and LINDDUN are used to identify threats in terms of software and privacy. For this, a detailed analysis of key components, including entities, processes, data stores, and data flows, is required. Data flow diagram (DFD) is performed as one step in the process of security threat modeling, allowing for an overview of the data flow. The expression rules for DFD are shown in Table 2.
Symbols of data flow diagram
Connected Car Services include entities such as the user, smartphone, manufacturer server, app store server, vehicle edge, and Engine Control Unit (ECU). Since the type of conceptual data transferred between entities is expressed in the context diagram, it is possible to understand how the entire services are composed and the flow of core data. However, it does not provide an understanding of the internal workings of the analysis target. DFD is created based on the context diagram, and the main process is explained in more detail as the level rises to Level 0, Level 1, etc. The final DFD creation result for the Connected Car Services is shown in Fig. 2.
Final data flow diagram of connected car services.
3.2 Collect Attack Library
Attack Library is created to determine whether properly identifying threats that may arise from each item of the DFD created in Section 3.1. Attack Library is created by collecting various types of data such as papers, conferences, technical documents, common vulnerabilities and exposures (CVE), and international standards. The vulnerabilities and attack methods of the connected car services, the subject of this study, are classified into applications, networks, systems, and hardware. Attack Library was prepared by referring to theses, technical documents, CVEs, and security conferences. The attack library collected for this study is shown in Table 3 [12-17]. Through the creation of the Attack Library, the threat to the analysis target can be detailed, and all known attack routes, types, and methods so far can be identified.
Attack Library sample of connected car services
3.3 Threat Identification with STRIDE
When I checked all the processes of the connected car services in detail, I checked a total of 52 components. Each component contains a potential threat. Using STRIDE, one can identify the threat of each component. At this time, for accurate and consistent threat identification, the threat is identified by referring to the Attack Library created in Section 3.2. Table 4 shows the results of STRIDE analysis for each element.
STRIDE analysis result sample of connected car services
As a result of STRIDE analysis, a total of 99 threats were found in the connected car services. Among them, Tampering and Information Disclosure were identified as the primary threats, while Spoofing (disguised as a normal user) and Elevation of Privilege (acquiring administrator rights) were relatively less common. This seems to be because the connected car services offer a generic service that can be used by various users instead of offering user-specific services through user identification or authentication. The STRIDE analysis result is a list of threats that can occur in the connected car services, and it is necessary to use the Attack Library and Attack Tree to check which attacks can occur due to these threats.
3.4 Attack Tree
In Attack Tree, an attack target is named as a root node, and detailed attack methods to carry out the attack are created as sub-nodes. There are four types of attacks that are used in the connected car services. They are data acquisition, data tampering, administrator privilege (shell) acquisition, and denial of service. Most attacks are generated by tampering with firmware or executing malicious applications (Table 5).
Attack Tree sample of connected car services
3.5 Threat Identification with LINDDUN
We identified threats related to personal information of the connected car services using LINDDUN, which is advantageous for privacy-focused threat identification. Unlike STRIDE, LINDDUN builds a Threat Tree for each possible threat. The analysis result by applying LINDDUN to the DFD element of the connected car service is shown in Table 6.
LINDDUN analysis result sample
As a result of detailed LINDDUN analysis, most threats were related to Detectability, that could potentially reveal a user's interests, preferences, or tastes, rather than Identifiability, which can identify a user's identity from personal information in connected car services. This is because the portions of authentication and identification in the connected car services are not as large as the result of STRIDE analysis in Section 3.3, so there is not much data that can identify the user's identity. In addition, we can know that there is a lot of data that could potentially reveal interest items, tastes, dispositions, and personalities, which can be analyzed based on the behavior patterns or behaviors of connected car services users.
3.6 Threat Tree
When threat identification for each component of DFD is completed using LINDDUN, a Threat Tree is created that identifies detailed information for each threat related to each item. Table 7 is the Threat Tree of the Entity.
Entity Threat Tree sample
3.7 Misuse Case
In order to help the understanding of the created Threat Tree, a Misuse Case (MUC) is created based on the scenario. The MUC is written to include all the contents of the Threat Tree, which includes the identifier, summary, main attacker, scenario, and the results of the Threat Tree related to the MUC. Table 8 is the MUC based on the Threat Tree.
MUC sample for Threat Tree
As a result of analyzing the Threat Tree, a total of 15 MUCs have been derived. As a result of checking 15 MUCs, cases for Identifiability and Unawareness have been derived for Entity, and cases for Linkability, Identifiability, Detectability, Disclosure of Information, and Non-Compliance have been derived for Data Store, Process, and Data Flow. Through this, it is judged that the Data Store, Process, and Data Flow share similar vulnerabilities.
4. Security Vulnerability Analysis of Connected Car services
4.1 Derivation of Checklist for Vulnerability Check
In this study, vulnerability checks are mainly performed on mobile apps for Connected Car Services. We decided that it would be appropriate for experts to perform a vulnerability analysis on a mobile app rather than relying on a commercial solution. Therefore, a checklist for vulnerability analysis was derived, and vulnerability analysis was performed on the list. The vulnerability checklist was prepared by referring to the “Mobile Public Service Security Vulnerability Check Guide” of Korea Information Security Agency, a guideline for mobile app vulnerability check. Among the threat items of the list derived by applying STRIDE and LINDDUN modeling, the checklist is composed of items that can be checked without affecting the vehicle. The vulnerability checklist was divided into three areas: application, network, and system (Table 9).
Checklist for security vulnerabilities in connected car services
4.2 Security Vulnerability Analysis Result
As a result of the security evaluation of the connected car services by each manufacturer, it was confirmed that the development was carried out with security in mind, except for some items. The vulnerabilities found in the service are shown in Table 10. In the application section of the checklist, vulnerabilities were found in the authentication policy limit of the number of login attempts (A1) for one manufacturer service and the complexity of setting password rules (A2). In addition, all four manufacturers requested unnecessary permission for App operation (A5), and the communication data is encrypted through Secure Sockets Layer (SSL). However, Android Package (APK) source code obfuscation (A6) has not been applied, so it may be exposed to the risk of source code analysis for malicious purposes. In the network and system section, safety actions were taken by performing encryption and other proper actions, but company C and company D did not check whether the device is rooted (S4), so there was a threat that could be used for an attack through an emulator.
Compare security vulnerabilities in connected car services
5. Conclusion
In this paper, we reviewed the research related to the connected car services that have been published so far and presented a security checklist through security threat modeling to improve the fundamental security of the connected car services. To derive an effective security checklist, DFD was derived from analyzing the data flow of the connected car services, and based on this, threats that could occur in the connected car services were identified using STRIDE and LINDDUN, the security threat modeling methodology. Afterwards, a checklist to remove the identified threats was derived. Using this, we performed the security vulnerability analysis of the connected car services.
As a result of analyzing apps developed by four manufacturers, all four companies excessively requested unnecessary permissions for APP operation, the source code was not obfuscated, and there were still vulnerabilities in the application section such as exposing error messages and debugging information. In addition, it was confirmed that there was a high possibility of being a target of an attack because some manufacturers' apps did not check if the devices were rooted.
STRIDE, a security threat modeling method for the software aspect, and LINDDUN, a security threat modeling method for personal information protection, were applied together to examine two aspects of security threats: the software aspect and personal information protection. In the case of existing papers related to security threat modeling, security threat modeling was mainly performed using one methodology, but it can be said that there is rarity in that both were applied together. We derived the security threat of the connected car services using the security threat modeling methodology, and we made a security checklist based on this. Car manufacturers should consider security aspects as well as service usage aspects in the planning stage of connected car services. If we use the checklist made through this study, the security aspect can be further strengthened.
The results of this study are expected to be used in various ways as follows. First, a threat model can be used to identify issues before developing software for connected car services. Second, it is expected that it will be helpful in effectively performing vulnerability analysis on connected car services in the future based on the identified security threats and checklists for vulnerability analysis to connected car services using threat modeling. Third, it is expected that the threat identification, checklist, and vulnerability analysis results presented in this paper can be used as an objective reference to consider in terms of security when developing connected car services.
In this study, we conducted vulnerability tests on apps that can be controlled remotely, rather than on parts of connected car services that are directly connected to the vehicle. When conducting vulnerability tests on vehicles without the help of vehicle manufacturers, the scope of the test is necessarily narrowed due to the risks that may occur in the vehicle. In addition, when conducting penetration testing, it is usually performed with the knowledge of the operating organization of the target system. In the case of connected car services, we excluded them from the scope of our analysis because conducting vulnerability analysis on vehicle-related servers at random would place a significant load on the servers. In the future, it is believed that much more meaningful results can be obtained by including equipment such as vehicles and related servers in the scope of vulnerability analysis in consultation with vehicle manufacturers.
The scope of this study was limited to analyzing security threats to apps that focus on remote monitoring and remote-control functions in connected car services. It would have been more meaningful to identify the characteristics of security vulnerabilities specific to connected cars and derive checklists, but we had to narrow the scope due to the mentioned risk issues that may occur in vehicles. If future research is conducted in collaboration with vehicle manufacturers and an environment is created where tests can be conducted on vehicles or manufacturer servers, we expect that this aspect can be strengthened to identify the characteristics of security vulnerabilities unique to connected cars, add them to the checklist, and conduct actual vulnerability analysis to derive more meaningful results.