[Series] FESCARO's Automotive Cybersecurity FAQs

​

FESCARO has been operating the ‘FAQs Series’ to address cybersecurity issues for stakeholders in the automotive industry. We have conducted live webinars on four key topics, and the expert panel from FESCARO provided answers to the most commonly asked questions from industry professionals. If you missed a webinar on a topic that interests you, you can access both the recorded video and a text summary (FAQs) at the following link.

 

# FAQs Series

1. Cybersecurity Strategies for Tiers (Emerging-OEMs oriented)

2. Comprehensive Guide on Cybersecurity Solutions & Engineering

3. Cybersecurity Testing method based on VTA Success Stories

4. ECU Cybersecurity guidance : From production to post-mass production

5. How Korea’s Motor Vehicle Management Act Amendment impacts OEMs and Tiers

The last webinar of the year organized by FESCARO was successfully completed. This webinar, titled <ECU Cybersecurity guidance : From production to post-mass production> took place on October and attracted approximately 80 participants from more than 50 companies.

​

Automotive controller developers should not only apply security solutions to their controllers, but also consider cybersecurity during and after the production. This webinar focused on both the KMS (Key Management System) required during production and the Security Control System required on the post-production phase.  Let’s check out the clear answers from the FESCARO’s expert panel.

 

 

■ Expert Panels

​

 • Director Ku Seong-seo & Team Leader Choi Hee-sun : 20+ years of experience in embedded system SW development, including automotive controllers and security solutions

 • Director Lee Hyun-Jeong: A white hat hacker who is a question setter for 'CODE GATE CTF', an international hacking defense competition, and an IT/Automotive security expert.

​

 

■ QUESTION LIST

■ Video Ver.

■ Text Ver.

 

1. What kind of cybersecurity do OEMs require on their production lines?

Typically, OEMs rarely explicitly request cybersecurity-related precautions for manufacturing controllers. This is due to the variations in controller characteristics, semiconductor types, required security functions for each controller, and the assets that need protection.

​

From the supplier's perspective, it is crucial to establish an appropriate response strategy as they must effectively address these vague requirements. When automotive cybersecurity requirements are unclear, it is advisable to consult the international standard ISO/SAE 21434. The key is to develop a rational and consistent response plan tailored to the specific controller characteristics while aligning with OEM requirements. 

The table provides a summary of ISO/SAE 21434 in its entirety. Section 12 outlines the requirements that need to be considered when manufacturing controllers or vehicles. It establishes two primary objectives: first, the application of WP-10-02, which outlines the requirements that must be met during production after development phase, and second, the prevention of new vulnerabilities from entering the controller during production process. These requirements can be broken down into in three key aspects: the establishment of a robust control plan for production, the inclusion of four specific conditions within the production control plan, and the successful execution of production in accordance with this plan.

 

WP-10-02, which pertains to the requirements on the production process after development includes the initialization actions such as safely injecting and activating security assets (e.g. encryption keys, passwords, certificates, etc.) used in the operation of the security solutions so that the cybersecurity solutions or controllers can operate properly in the vehicle after production.

​

The production Control Plan, mentioned in RQ-12-02, should include :

  a. Procedure to meet the production requirements described above

  b. Description of tools or equipment to be used for this purpose, e.g. KMS, key injection device, verification device, etc.

  c. Measures to keep the production environment safe (e.g. firewall, VPN, etc.)

  d. Measures to ensure reliable and proper fulfillment of production requirements

​

We looked in more detail on WP-10-02 and the four key components that must be incorporated within the Production Control Plan. In summary, two things are essential for meeting OEM’s cybersecurity requirements: One is to safely apply and activate security assets during the production process so that the cybersecurity measures applied to the controller can function effectively post-production, and the other is to provide environmental factors so that this process can be sufficiently protected from external intrusions.

 

2. What are security assets and KMS? 

To help you understand, let me begin by explaining the terms. An asset is something that requires protection since it possesses inherent value or contributes to the overall value. In the context of a controller, assets encompass controller functions, hardware (HW), software (SW), and the data stored or utilized within the controller. The security assets mentioned in the question refer to data, software, and various information used for cybersecurity functions. These are also critical assets that need to be protected.

​

Moving on to KMS (Key Management System), it refers to a device or equipment responsible for generating, securely storing, and managing security assets used in the controller's security functions. Additionally, it facilitates the distribution and injection of security assets into the controller during the production process. For those who may not be familiar with KMS, I will provide a more detailed explanation. 

The diagram above illustrates the process of applying security assets, whether provided by OEMs or independently created, to controller production. In total, there are three Key Management Systems (KMSs), all of which are responsible for managing security assets, such as certificates and security keys, and distributing them as needed. For instance, OEMs create, distribute, and manage security libraries or other keys required for security functions at the request of suppliers request. The suppliers, in turn, receive, manage, and securely maintain these assets, incorporating them into production when required. The controller suppliers themselves have to generate essential security keys, passwords, and other components, inject them into the controller, and activate the security functions, and collect, manage the information to be used when needed.

​ 

Therefore, it is crucial to understand the OEM's requirements, identify the assets integrated into the controller, and make informed decisions regarding the configuration of the KMS and related processes. This necessitates professional judgment grounded in expertise and experience.

FESCARO possesses a track record of constructing and delivering Key Management Systems (KMS) for OEMs. The KMS incorporates processes to create/distribute/manage security assets necessary for OEMs to cooperate with suppliers, and to carry out tasks appropriate to each role within the organization.

 

The KMS developed for suppliers was tailored to suit the unique attributes of both the controller and the supplier, and it was seamlessly integrated with the production line. Furthermore, we furnished a key injection system that interfaces with both the KMS and the controller during the actual production phase, allowing for the injection of security assets. Additionally, we have frequently created and supplied software (SW) capable of receiving these assets from the controller, securely storing them, and triggering security functions when needed.

 

 

3. Requirements for building KMS

 

When selecting a Key Management System (KMS), it is vital to understand its intended purpose, namely, what data will be generated, managed, and distributed. This can differ significantly between various OEMs and controller types. This discussion outlines the fundamental factors that should be taken into account when dealing with KMS, even when their specific purposes may vary. Two key considerations must be addressed when developing KMS.

 

1. The robustness and reliability of the security assets generated by KMS need to be upheld.

2. The environment where the KMS is located must be very safe from external access.

 

First, to ensure the robustness and reliability of security assets, it is imperative that only authorized individuals have the capability to execute actions in accordance with their granted permissions. The security assets should be created and stored securely, and the recipients requiring these security assets must be accurately specified to ensure precise distribution. Moreover, effective management of their expiration dates and change cycles is essential, and they should be restored or disposed of as necessary.

 

We will express the above five requirements technically so that practitioners can understand them more easily. We can assess compliance with the first condition by verifying whether the system aligns with the Key Management Interoperability Protocol (KMIP). KMIP serves as a client-to-server communication protocol utilized for the storage and maintenance of security assets, including security keys and certificates. The second requirement involves the use of Hardware Security Module (HSM) certified under FIPS 140-2 standards. This certification ensures the stability and reliability of the security logic within the system. As for the third condition, it's imperative to implement redundancy measures to protect the created assets and prevent operational disruptions. Lastly, the system should offer support for functions such as dashboards, enhancing convenience in terms of management and operations. 

First, to ensure the robustness and reliability of security assets, it is imperative that only authorized individuals have the capability to execute actions in accordance with their granted permissions. The security assets should be created and stored securely, and the recipients requiring these security assets must be accurately specified to ensure precise distribution. Moreover, effective management of their expiration dates and change cycles is essential, and they should be restored or disposed of as necessary.

 

We will express the above five requirements technically so that practitioners can understand them more easily. We can assess compliance with the first condition by verifying whether the system aligns with the Key Management Interoperability Protocol (KMIP). KMIP serves as a client-to-server communication protocol utilized for the storage and maintenance of security assets, including security keys and certificates. The second requirement involves the use of Hardware Security Module (HSM) certified under FIPS 140-2 standards. This certification ensures the stability and reliability of the security logic within the system. As for the third condition, it's imperative to implement redundancy measures to protect the created assets and prevent operational disruptions. Lastly, the system should offer support for functions such as dashboards, enhancing convenience in terms of management and operations. 

Usually, as part of quality activities, a process for managing security events is defined and operated according to a manual. However, today we will focus on collecting and managing security events that occur in the field.

 

FESCARO is constructing security event monitoring systems for clients across the entire vehicle life cycle. The security event monitoring function is initially activated during the vehicle production on the assembly line. At this stage, details such as the software (SW) and hardware (HW) version information installed on the vehicle, and the occurrence of security events, are recorded on the server.

 

Once the security event monitoring function is initiated on the production line, the Central Gateway (CGW) is tasked with collecting and storing data regarding security events for controllers equipped with cybersecurity functions within the vehicle.

​

Subsequently, when a manufactured vehicle is brought to a repair shop for maintenance, diagnostic equipment is employed to ascertain whether any security events have transpired in the vehicle. In the event of a security event, the security log is gathered and transmitted to the server to update the vehicle's status.

​

In cases where a security event occurs in a connected vehicle equipped with an external communication controller, the controller communicates a security event notification to the server. The server can, if necessary, request comprehensive data from the vehicle for further analysis. Upon receiving such a request, the vehicle transmits detailed data, including CAN messages before and after a security event, to the server.

Upon receiving a security event that has transpired in a vehicle through the three pathways previously described, the server undergoes an automatic process to determine the vehicle model, controller, and software (SW) in which the security event occurred. The server automatically categorizes the array of security events obtained from diverse vehicles, facilitating an environment where individuals can carry out their respective analysis tasks. The server may encounter security events of a type that it cannot classify. In such instances, these events are labeled as "Unknown" to enable human analysis.

 

Next, one or more security events that are related to each other are grouped and managed as one security vulnerability. For example, security events identified as abnormal messages by CAN-IDS are amalgamated into a singular security vulnerability and collectively managed until the security vulnerability is resolved.

 

Lastly, abnormal vehicles are managed. The status of each vehicle produced on the production line is recorded, and this status is continually updated through maintenance and connectivity activities. During this process, not only the vehicle that reported the security event but also those vehicles with a potential risk of encountering a similar security event are identified. This proactive approach enables preemptive measures to be taken, enhancing overall security.

 

5. Examples of building a security control system

 

FESCARO has successfully developed and maintained security control systems for global passenger and commercial automakers. The image above illustrates the security control system we've implemented for a global OEM. While there are numerous functions within the system, we will introduce some of the key features.

 

First, let's discuss the dashboard. The dashboard provides a concise overview of the current security event status. It offers real-time updates on which security events have occurred in specific vehicles and compiles statistical data. This data includes insights into which security events on which vehicle type have been most frequent. It also includes a highly regarded feature among OEMs: the ability to 'Download as Report.' This feature generates reports detailing the status of security events, organized by month, week, vehicle type, and individual vehicle, all conveniently presented in Excel format.

 

Next, we have a feature that allows to examine the status of security events in greater detail. It displays information about which events occurred on which vehicles, along with their timestamps, event specifics, and any mitigation actions taken. To simplify the analysis of raw data, this feature visualizes and presents CAN messages.

 

Furthermore, the system provides a timeline of security events for a specific vehicle. This timeline aids in easily assessing which security events have taken place in a given vehicle. Importantly, the security control system goes beyond merely collecting security events from the field; it streamlines and visualizes tasks that would otherwise require manual handling, reducing the workload for human operators. Feedback from our customers attests to the convenience and efficiency that the security control system brings to the analysis process.

 

 

6. Do Tiers necessarily need a security control system? Wouldn’t quality activities be enough?

 

Of course, we can manage security events through quality activities. However, there are practical limitations to manual management, especially for Tier suppliers who often work with multiple OEMs and their various vehicle variants. Instead of manually classifying and analyzing every security event, the adoption of a security control system can significantly enhance efficiency.

​

While security control systems may not be mandated for Tiers, an impact analysis process is crucial. A single security event may potentially affect multiple vehicles and vehicle types. Security control systems automatically conduct impact analysis and identify vehicles that haven't encountered a security event yet but are at risk, enabling proactive measures to prevent the propagation of damage resulting from security incidents.

​

Vehicles become increasingly interconnected with external networks and hackers' attack strategies continuously evolve. What may be cutting-edge security technology for controllers today may not be so in 10 or 20 years. Given that no security system is entirely foolproof, ongoing monitoring after production is essential. Rapid identification and analysis of security incidents, followed by appropriate mitigation actions, are vital.

​

To achieve this, an appropriate security control system must be introduced to protect against security threats throughout the vehicle's entire life cycle.

 

7. How is the security events of the vehicle shared?

 

Security events that can occur in vehicles include intrusion detection events, software tampering events, and secure storage tampering events etc. When these events occur, related information is collected and stored.

​

In the case of connected vehicles, security event data is instantly relayed to a controller equipped with a telematics unit, such as a CCU. The contents of security events and related information are gathered by the CCU and then transmitted to the server. However, since connected services are optional for vehicles, not all vehicles transmit security event data to the server in real time.

​

For vehicles that are not connected, there is currently no direct means to send security events to the server in real time. Nonetheless, the collection of security events from as many vehicles as possible is essential for addressing and preventing potential security incidents in the future.

​

To address this, non-connected vehicles rely on car repair shops to carry out this task. When a vehicle is brought to a repair shop and connected to diagnostic equipment, the diagnostic tools search for stored security events within the vehicle's gateway and subsequently transmit this information to the server. FESCARO is also actively developing and delivering a security solution for diagnostic equipment to facilitate the search and automated transmission of security events from the gateway to the server.

Let's explore the details of the security event information transmitted to the server. In paragraph 7.2.2.2 of UN Regulation 155, the regulation doesn't specify the exact information to be managed. However, it does emphasize the need for a process to provide relevant data to support the analysis of attempted or successful cyberattacks. This process must be in operation and proven during the certification process.

​

To establish effective preventive measures, it is crucial to utilize security event information to understand the nature of intrusion attempts, identify issues, and pinpoint the timing of such events. Therefore, the necessary information must be collected for analysis.

​

The information sent to the server includes the Vehicle Identification Number (VIN) to determine which specific vehicle the security event occurred in, the type of security event, a timestamp to track the time it occurred, and, a freeze frame (for intrusion detection events) containing the CAN messages that were involved in triggering the event.

 

8. How does the gateway protect vehicles?

The gateway maintains vehicle security with the following functions:

 

 1. Primary defense against intrusion attempted through the OBD diagnostic port connected from outside the vehicle

 2. Monitoring abnormal behavior of vehicle controllers and reporting detected abnormal operations to the server

 3. Detecting the operation of unauthorized software other than officially certified software through the VTA certification process and reporting it to the server

​

Let's begin by examining the concept of 'defense against intrusion from outside the vehicle'. Indeed, this concept is about shielding the vehicle from external intrusions that might occur through a diagnostic port with an external contact point. This protection is achieved by implementing security measures such as Secure Unlock, Secure Access, Secure Flash, etc. For more about security features, please refer to the ‘Comprehensive Guide on Cybersecurity Solutions & Engineering’ FAQs.

​

Second is about CAN-IDS, which upholds vehicle security by focusing on the ‘detection and reporting of abnormal behavior occurring inside the vehicle’ as specified in UN R155. This encompasses the following six key activities:

 

· Undefined message detection

· Undefined signal detection

· Abnormal DLC message detection

· Abnormal cycle message detection

· Bus load detection

· Signal rate of change detection

​

In the development of a gateway, CAN messages or signals are typically routed and processed according to a CAN DBC. The CAN-IDS function comes into play when a message is received that is not defined in the CAN DBC or when the signals fall outside the specified range. It is also utilized when the length of the actual message received differs from the DLC defined in the DBC or exceeds the defined cycle.

 

Expanding on this functionality, the CAN-IDS can detect as abnormal conditions if it exceeds the defined range which the bus load of the CAN network defined and gets overloaded or if signals that should change gradually, such as RPM or vehicle speed, exhibit rapid and irregular changes. However, it's important to clarify that the gateway primarily detects and reports abnormal behavior rather than immediately implementing defense mechanisms. This is because vehicles operate on a broadcast CAN network, making it exceedingly challenging to identify the specific controller responsible for an abnormal operation. Attempting to immediately control the problematic controller can be hazardous during driving. Therefore, the current approach involves detecting abnormal behavior, reporting it to the server, and subsequently addressing the issue through software modifications and updates to ensure safety.

 

Last is the 'detection of unauthorized software.' As previously discussed UN Regulation 155, we will now introduce UN Regulation 156, known as the Software Update Management System (SUMS). The gateway plays a vital role in maintaining vehicle security by guaranteeing that only safe and authorized software updates are applied and operated. This is achieved through a database that manages software and hardware versions, compatibility information, and other relevant data, which is linked to vehicle type certification and referred to as RxSWIN for all controllers within the vehicle.

UN R156 requirements:

 

· 7.1 : Identify hardware and software versions and component information and check software integrity

· 7.2 : Identify software (RxSWIN) related to Vehicle Type Approval (VTA) and check update compatibility;

· 7.2.1.1 : Protect and prevent damage of the authenticity and integrity of software updates, and prevent invalid updates

· 7.2.2 : Ensure safe execution of updates and demonstrate that vehicle users are aware of updates.

 

The gateway plays a crucial role in ensuring that only software specified in the RxSWIN DB can be updated. It also verifies the integrity of the software to guarantee secure execution during the updating process, utilizing methods such as Secure Flash.

​

 

FESCARO has proven outstanding capabilities in key management systems (KMS), security control systems, and security gateway controllers. For key management systems, we have provided security asset injection solutions to OEMs and Tiers. Additionally, we have developed and maintained security control systems for leading global automakers and commercial vehicle manufacturers. FESCARO's security gateway controller, encompassing development on both software and hardware, is employed in approximately seven vehicle models, including both passenger cars and commercial vehicles, recognizing for its reliability.

​

 

If you encounter challenges in meeting OEM cybersecurity requirements or face cybersecurity difficulties on production and post-production phase of controllers, please contact the FESCARO’s ‘Security Counseling Center'. Together, we can collaborate to identify and implement solutions to address your specific cybersecurity needs.

■ Webinar Reviews

* Cheol Lee "I hope that more specific and honest webinars focusing on cases like this continues. I was impressed by the difference from other webinars."

* Hoon Noh “I think FESCARO's guidelines are a good strategy to respond to OEMs. It was beneficial as I had no experience communicating with OEMs.”

* Ki Song “The issues our company was concerned about were covered well, and it was especially helpful to my business as it was a Q&A related to practical work.”

* Kyo Jeong "I was curious about the security control system for monitoring and incident response after mass production, and it was easy to understand with actual application examples."

* Seok Go "I liked that it went beyond controller security, such as production lines and security control. There was a lot of new content that couldn't be found anywhere else."

* Mi Seung "It was good that production and post-production responses were also covered, and that the issues tiers were concerned about were explained from the OEM's perspective."

* Cheol Kang "The talk format was refreshing. It was interesting to hear things I was curious about before but found it difficult to ask questions about openly."

* Jun Lee "The TALK with the host and panelists was outstanding. I would like to hear about the cybersecurity system and preparations for SDV in future webinars."