The webinar, <Comprehensive Guide on Automotive Cybersecurity Solutions and Engineering> hosted by FESCARO on August, concluded successfully. We welcomed over 100 pre-registered attendees from 60 different companies. The significant interest in the webinar seemed to stem from its focus on pressing concerns regarding the implementation of cybersecurity solutions and engineering, grounded in real examples.

The webinar tackled eight prominent concerns, consolidating frequently asked questions from Tier companies and queries received during pre-registration. To offer precise insights, we assembled a panel of experts, with an average experience of over 20 years. Why not delve into the insightful responses from CEO Hong Seok-min, an authority on automotive cybersecurity, Director Ku Seong-seo, a specialist in automotive software development, and Team Leader Yang Hee-guk, an expert in automotive engineering?

​

■ QUESTIONS LIST

1. How should we analyze cybersecurity specifications that vary between OEMs?

Cybersecurity response strategies can also be called as security solutions, security controls, or security requirements. These cybersecurity responses have two main purposes:

​

· Protecting the content itself

· Protecting the systems for content handling

​

To help you understand, I will give you an example from Netflix. They also have a security response strategy, again from two perspectives. One is a strategy to protect the content itself that Netflix distributes over the Internet, for example, applying a DRM solution such as Widevine, and the other is to protect the player device that receives and plays the content from external attacks.

​

The same concept goes for the vehicle. That is, protecting data processed inside/outside the vehicle, such as CAN communication data and FW images of ECUs, and protecting electronic device ECUs that process such data. After all, all OEMs create security requirements and specifications from these two perspectives. Remembering this will help you analyze OEM requirements, composed of slightly different terms, phrases, and items.

​

​

However, we often see companies struggling with difficulties since the security specifications distributed by OEMs are generally drafted without distinction of ECUs. That is why it is very important to first determine whether the requirements are suitable for the ECU that are being made, and then distinguish between what needs to be reflected and what does not need to, and confirm it through discussion with the OEM. In the end, such a process directly influences the duration of development, resource allocation, and material costs, so it is important to discuss with the OEM in advance.

​

If you remember the explanation so far, it may help you understand the OEM's requirements, but it is still very difficult to understand and respond to them properly. If you are unable to determine what the OEM's requirements are or how to respond to them, you can contact a group of security experts like FESCARO and make a more efficient response.

​

2. Security level and functions of ECUs

At FESCARO, we have worked hand in hand with OEMs to establish security levels and have also implemented various security features as requested by various OEMs. What we learned through this is that the criteria for determining security levels are slightly different for each OEM. However, we commonly refer to the method for distinguishing whether an ECU is related to cybersecurity as described in the ISO/SAE 21434 standard.

​

· Electrical and Electronic ECUs

· Safety-related ECUs

· ECUs to collect/process information (Related to driver, passenger, vehicle location, etc.)

· Network-based ECUs (Whether it’s connected to the vehicle’s internal network or it has external communication contact points)

​

Security ECUs are classified based on the above criteria, and their security level is determined through a process called TARA (Threat Analysis and Risk Assessment).

​

​

Then which ECUs will be given the highest security level? There may be deviations, but we will give our opinion from a broader perspective.

• Highest security level: ECUs with a communication point that directly contacts the outside, such as an OBD port, Telematics, Wi-Fi, Bluetooth, and USB

• Medium security level: ECUs that are directly connected to the vehicle's internal network and directly affect vehicle driving or safety

• Lowest security level: ECUs that are directly connected to the vehicle's internal network but do not directly affect driving or safety

The security features are determined based on both the security level and the functions inherent to the ECU. If we look at commonly applied functions, first of all, those related to diagnosis include Secure Assess, Secure Flash, and Secure Unlock. And security functions to protect the ECU system include Secure Boot, Secure Debug, Secure Storage, Runtime tuning protection, and Memory protection. HSM is sometimes required as a way to implement these functions.

​

If you need technical support and security solutions on whether the security level determined by the OEM matches the ECU and how to determine the level of security functions that should be applied accordingly, please feel free to contact FESCARO.

​3. Must change AUTOSAR or semiconductor chips when applying new cybersecurity to existing ECUs?

This question is one of the most frequently asked questions over the past year. European regulations are scheduled to be applied to new vehicles from July 2022, and to all mass-produced vehicles from July 2024. This means that vehicles produced before July 2022 must be ready for cybersecurity regulations by July 2024. To achieve this, cybersecurity functions must be integrated into existing ECUs, but in cases where existing SW platforms (e.g. AUTOSAR, etc.) suppliers or semiconductor chip manufacturers do not support cybersecurity functions, there is no choice but to develop new cybersecurity functions. I believe that new development will be a challenge as it requires additional development time and costs. In this case, it would be a good idea to look for a security solution not from a SW platform provider or a semiconductor chip manufacturer, but from a company that has:

• Independent security solution

• Professional personnel and organizations involved in automobile security

• Experience in porting solutions to various SW platforms and semiconductor chips

​

If you collaborate with a company that meets the above conditions, you will be able to apply new cybersecurity functions without changing the AUTOSAR solution or semiconductor chip. FESCARO has experience carrying out various projects not only with global SW platform providers but also with automotive semiconductor chip manufacturers. FESCARO's security solution allows for the integration of cybersecurity features directly into the existing ECUs. This approach diminishes the expenses associated with new development and significantly cuts down the time needed for both development and validation.

4. ​What security features do OEMs require?

As mentioned earlier, OEMs' security requirements are divided into requirements to protect communication data inside/outside the ECU and requirements to protect the ECU itself.

​

ECU data protection requirements include Secure Assess and Secure Flash for diagnostic communication, and Secure On-Board Communication, LS security requirements for CAN/Ethernet communication. ECU protection requirements can be divided into two aspects: firmware tamper prevention and tamper detection. Firmware tamper prevention includes a Memory Protection function that protects MCU memory and a Secure Debug function that blocks external debugging interfaces, and ECUs with OS such as Linux have OS Hardening requirements, including access control functions such as DAC/MAC. Tamper detection has the requirements of Secure Boot function that is used to assess the integrity of the boot loader, and the Run-time Tuning Protection that checks the firmware's integrity as the ECU application operates.

​

In terms of cryptographic security technology, there are requirements for AES-128/256 encryption/decryption, message authentication codes such as AES-CMAC and SHA2 HASH, signature verification techniques such as RSA-based PKCSv1.5, v2.2, ECC-based ECDSA, X.509 certificate management, and random number generation methods based on NIST SP 800-90B and BSI AIS 31 standards. Especially in recent years, OEMs are demanding more secure technologies such as the Secure Flash function based on the ECDSA signature verification technique using an elliptic curve, and also the message-based Secure Access function that verifies the integrity of the diagnostic message itself, rather than a simple Seed & key authentication technique.

5. Is it possible to apply security solutions without HSM?

To conclude, it is possible. Customers with ECUs without HSM may be wondering whether they should switch to a chip with an HSM hardware core. They must be worried about the additional development period and cost burden of changing the chip. The security solutions provided by FESCARO can be divided into four types, such as diagnostic security, SW specialized solution, HSM, and HSE solutions.

​

​

The ‘diagnostic security solution’ provides Secure Access and Secure Flash functions essential for diagnostic communication even without HSM. The ‘SW specialized solution’ is a security solution that virtualizes the HSM hardware core in software, and provides security functions equivalent to HSM, although it has a lower level of security compared to HSM hardware solution. The ‘SW specialized solution’ supports AES-128 encryption/decryption, AES-CMAC, SHA2-HMAC message authentication code, RSA PKCS v1.5 and v2.2 Signature Verification, X.509 certificate management, NIST SP 800-90B based random number generation, and Secure Storage function using Data Flash and MPU functions in MCU.

​

If FESCARO's SW specialized solution is applied to an existing mass-produced vehicle's ECU without an HSM hardware core, it has the advantage of not having to change the existing ECU hardware, thereby dramatically reducing the development period and cost.

6. Deployment process of security solutions and its impact on the ECU

The following diagram illustrates the general integration process of FESCARO's security solution. The ECU supplier has to initially consult with the OEM regarding the necessary security specifications and the security level to be implemented. Once the discussion is complete, FESCARO will develop a security solution based on the security specifications to be applied to the ECU and deliver it to the supplier. Integration procedures can be classified into two types depending on the type of security solution, such as a SW specialized solution, HSM/HSE solution.

‘Diagnostic security solution’ and ‘SW specialized solution’ require the use of hardware resources such as the Data Flash within the ECU's MCU, MPU, and timer, so there may be a HAL API that needs to be implemented by the ECU supplier. FESCARO provides detailed guide manuals and verification libraries required to implement the HAL API. Once the HAL API has been implemented and verified, you can implement OEM's requirements by utilizing the security solutions deployed such as the HSM and HSE solution integration procedures.

FESCARO's security solutions provide only the necessary functions specialized for the OEM's security requirements, so we can help ECU suppliers more easily integrate security solutions and implement specifications. Moreover, we offer in-depth descriptions and use cases of security solution features in a guidebook, while also providing technical support at any time during development.

Meanwhile, some people are worried that applying the security solution will affect the existing ECU functions. First, the ‘diagnostic security solution’ operates only in a special environment where diagnostic equipment such as UDS diagnostic communication and reprogram are connected, so it does not affect the basic operation of the ECU. In the case of the ‘ SW specialized solution’, designed for MCUs lacking a hardware security core, the security solution has to use HOST CPU together. It aims to minimally impact the ECU's basic operations. It has been tested and validated on over 70 different mass-produced ECU's MCUs, so you can think of it as a safe security solution. For MUCs equipped with a hardware security core like ‘HSM solution’ or ‘HSE solution’, the basic operation remains largely unchanged, with the exception of a slight boot time increase of around 10ms before the HOST boot loader launch due to the activation of the Secure Boot function.

7. Validation of security solutions and hackability after application

No matter how robust our cybersecurity solution is, at the moment, no solution can guarantee 100% safety due to the constant evolution of hacking techniques. Many cybersecurity experts share the same view. UN R155 also emphasizes the need to set up an organizational and procedural framework to address cybersecurity incidents that might arise even after the vehicle has been released, and requires related certifications. This is known as CSMS(Cyber Security Management System) certification.

​

This does not mean that cybersecurity solutions can be created carelessly. The law states that ‘cybersecurity solutions must use encryption algorithm standards that are internationally recognized for their safety and that this fact must be proven.’ This includes various encryption algorithms detailed earlier.

Fast HSM, one of FESCARO's security solutions, is trustworthy since it includes a security module that has obtained FIPS 140-2 certification issued by NIST, a U.S. national agency. Furthermore, we can attest to its reliability as it has been implemented in approximately 150 ECUs and is currently in mass production.

Even if you apply such a reliable security solution to protect the ECU, security events may occur, so you need to continuously monitor them and prepare countermeasures. These monitoring activities should be carried out continuously. For this reason, it is usually necessary to introduce an operating system. We call this system SIEM (Security Information & Event Management) or SOC (Security Operation Center).

​FESCARO has provided automotive OEMs with an operating system that streamlines a range of security-related processes. Consequently, it has contributed to obtaining certifications like CSMS in line with UN R155, SUMS in line with UN R156, and VTA. It is expected that not just OEMs, but also Tier companies are increasingly being asked to implement systems that can efficiently manage and handle these security incidents. It would be better for you to solve this problem with FESCARO rather than worrying about it alone.

​

8. Security management after mass production of cybersecurity functions

​

It is essential to implement and operate a security management system that is closely connected with both customers and suppliers. To explain in more detail, we gather information related to cybersecurity, and through this, we identify if any security incidents have taken place. Security incidents that have been identified are assessed based on the vulnerability management process. In the vulnerability management process, the TARA methodology is employed to scrutinize identified security vulnerabilities, gauge the associated risks, and devise appropriate counteractions. Also, it tracks and manages the remediation of identified vulnerabilities throughout the entire life cycle of the vehicle. For security incidents evaluated using this approach, corrective actions will be implemented in line with the incident response procedure. Steps such as crafting an incident response plan and updating security patches will be undertaken.

Currently, FESCARO is working with a passenger vehicle manufacturer to build and consistently manage a cybersecurity monitoring and incident response IT system for 7 vehicle models. Additionally, we are partnering with a commercial truck producer to create a cybersecurity monitoring and incident response IT system for 2 truck models. FESCARO has secured the reliability of the security solution itself, but also has an ‘IT management system’ as above. Through this, we can confidently offer maintenance such as ongoing security monitoring and timely security patch.

​

​

FESCARO’s specialized security solution analyzed ECUs in a total of 7 vehicles, including internal combustion engine vehicles and electric vehicles, and mass-produced security solutions for more than 150 ECUs among those vehicles. The security solution is compatible with over 70 models in 10 leading semiconductor manufacturers worldwide. Moreover, FESCARO maintains close collaborations with global AUTOSAR providers like Vector, ETAS, and Elektrobit. FESCARO collaborates with multiple semiconductor producers and international AUTOSAR vendors, and is renowned for its expertise specialized in automotive engineering.

​

If you find it difficult to respond directly to OEM's security requirements, or if you are experiencing difficulties in managing automotive cybersecurity related professional workforce and organizations, collaborating with FESCARO might be a solution.

■ Webinar Reviews