With the development of intelligent connected vehicles, OTA (Over-The-Air) updates have become a basic function essential for smart cars. It is an important technological means for vehicles to perform software and hardware upgrades, introduce new features, update applications, and fix vulnerabilities, enabling continuous evolution of vehicles, ongoing optimization of user experience, and sustained value creation.However, OTA has also become a primary target for hackers, facing multi-dimensional security challenges such as eavesdropping attacks, malicious upgrades, rollback attacks, and DDoS attacks.
The ACES (Autonomous, Connected, Electric, Shared) framework faces the dangers of network attacks, including short-range, mid-range, and long-range attacks.
Short-range attacks: Attacks occurring at close proximity to the vehicle, targeting points such as ECUs, sensors, IVI, OBD, OBD electronics, USB ports, in-vehicle networks, and keyless entry systems.
Mid-range attacks: Attacks via Bluetooth, 4G/5G, WiFi, IT networks, and mobile apps, for instance, a mobile phone controlling the vehicle’s windows via Bluetooth when in proximity, or starting the vehicle entirely.
Long-range attacks: Attacks targeting vehicle manufacturers, suppliers, connected services, operational services, and cloud services.
From the above dimensions, the types of attacks are numerous. However, there are currently no clear security standards in the industry, only some targeted protocols. As a result, many vehicles are essentially ‘naked’, such as some new energy vehicles, where drivers have no awareness of attacks or intrusions.
Currently, some black market actors both domestically and internationally are very concerned about software vulnerabilities in new energy vehicles. According to the 2021 Global Automotive Cybersecurity Report, the attack rates on cloud servers, keyless entry systems, mobile apps, and OBD are relatively high. There have also been news reports about hackers exploiting security risks in keyless entry systems of certain vehicle brands.
In summary, the current security challenges faced by the IoV are as follows:
Diverse attack methods: The complex architecture of IoV increases exposure and leads to a variety of attack methods.
No security standards: Numerous protocols for intelligent connected vehicles exist, but there are no security standards.
No security defenses: Connected vehicles without security defenses are virtually ‘naked’.
Increased hacker interest: The potential returns from attacks on intelligent connected vehicles are rising, attracting more hacker attention.
1.2 Increasing Regulations in the Connected Vehicle Industry
Currently, the automotive industry is in an era of software-defined vehicles, with increasing quantities and complexities of software, leading to more security risk points. National attention has also increased, resulting in the issuance of many relevant regulations requiring automotive companies to comply with safety requirements when manufacturing connected vehicles.
For example, the overseas regulation WP29-R155 involves mandatory information security requirements that vehicle manufacturers must meet and how to implement cybersecurity protections. A new industry requirement titled “Technical Requirements for Information Security of Complete Vehicles” will soon be released in China, specifying the technical requirements for complete vehicle information security and corporate information security management systems, covering external connection security, vehicle communication security, software upgrade security, and data code security, along with corresponding testing methods.
▍2 Overview of OTA
2.1 Introduction to OTA
OTA (Over The Air) refers to remote wireless upgrades. OTA enables online software and firmware updates, promptly addressing existing issues in the system without the need for traditional recalls. The application of OTA also indicates that vehicles can, to some extent, address information security issues and defects. OTA technology has almost become standard for new vehicles, allowing them to remain ‘fresh’ through remote upgrades and gradually becoming one of the means to eliminate vehicle hazards.
OTA is divided into two categories: FOTA and SOTA.
2.2 Traditional Software Upgrade Process
The traditional vehicle software upgrade process is illustrated in the following diagram. The manufacturer informs the 4S dealership that a certain system can be upgraded, the dealership then notifies the car owner, the manufacturer sends the update software CD to the dealership, the car owner takes the vehicle to the dealership for the upgrade, after completion of upgrade verification, the vehicle is returned to the owner, and the dealership then provides feedback to the manufacturer about the successful upgrade.
Security Risks Without OTA
If only traditional software upgrades are performed without OTA, many risks can arise.
First, upgrades can lead to various problems, such as certain functions not operating correctly, or the vehicle becoming inoperable. As intelligent connected vehicles evolve, the amount of software in vehicles will continue to increase, and upgrades will become more frequent. If traditional software upgrades are used, when batches of vehicles go to the 4S dealership for upgrades, a significant amount of manpower and funds will be required. Additionally, if issues arising during vehicle upgrades are not addressed promptly, accidents will become more frequent. Owners will also need to spend a great deal of time and effort resolving these issues.
2.3 OTA Upgrade Process
How can vehicle software be updated in a more time-efficient manner while ensuring quality and safety? This is where OTA comes into play. The OTA upgrade process is illustrated in the following diagram.
The OTA process can be divided into three phases:
The first step involves the cloud generating firmware or software update packages,
The second step involves securely transmitting the update package through the communication pipeline,
The third step involves installing the update package in the vehicle.
The OTA server pushes the upgrade package to the PKI service for relevant signature authentication. At this point, the upgrade package includes not only the content of the package but also a signature authentication, enhancing security. The package is then pushed to the CDN, notifying the vehicle of the required OTA version. After confirmation by the owner, the vehicle downloads the software package, performs signature verification, decrypts the upgrade package, and conducts secure writing for the upgrade. The T-BOX is the connected device in the vehicle that can access external networks to retrieve the relevant upgrade packages via the gateway for upgrades, such as for the vehicle’s main display, IVI, and ECU, which constitutes the entire OTA upgrade process.
▍3 OTA Risk Analysis
3.1 OTA Security Risks
In the OTA upgrade process, many nodes present security risks, such as OTA services, PKI services, T-BOX, interactions between PKI services and T-BOX, and the link between T-BOX and the gateway, all of which can be controlled by hackers for security attacks.
3.2 Security Analysis of OTA
Based on the security risk analysis of OTA, a threat model is established, as illustrated in the following diagram.
From the perspective of attack dimensions in the threat scenario, there are risks related to ECU security, key security, and man-in-the-middle attacks inside and outside the vehicle. One important aspect in terms of attack targets is to restrict arbitrary software attacks. Currently, vehicles do not allow all apps to be downloaded, aiming to prevent attacks from unverified software. In terms of functional rejection, rollback attacks, DDoS attacks, mixed bundling attacks, and hybrid attacks must be rejected. In terms of update rejection, bundling installation attacks and dropped request attacks must be refused, where a dropped request attack refers to an attack where requests are intercepted. In terms of reading updates, eavesdropping on updates must be rejected.
In the overall threat model, defensive measures must also be implemented, such as mitigating security risks and detecting malicious upgrades.
3.3 Various Risk Analyses
OTA security risks exist at various stages of the upgrade process, with common security risks summarized in the following table.
▍4 How to Ensure OTA Security
4.1 Qualification Certification
To address the risks and challenges presented by OTA, qualification certification must first be conducted to ensure that OTA complies with relevant technical specifications or mandatory requirements.
First, OTA-related policies include data security protection laws, information security protection laws, network security protection laws, automotive safety data management, automotive data security collection, and regulations for the protection of critical information infrastructure. If vehicles are to be sold overseas, compliance with GDPR is also required.
Second, OTA-related certifications can be divided into three aspects: people, data, and vehicles. Relevant certifications for people include ISO27701, ISO27701 privacy certification, ISO/IEC 29151, APP security certification, personal information protection, and MTCS. Data-related certifications include ISO38505, classification standards, SOC, CSA STAR, and TISAX (Trusted Information Security Exchange). Vehicle-related certifications include vehicle cybersecurity and data protection standards from the United Nations WP29, ISO21434 /SAE 3061, and SOTF: ISO 21448.
Finally, based on policies and certifications, automakers must establish relevant OTA security systems internally, including information security management systems, data security management systems, and vehicle safety management systems. For people, relevant information security management can be implemented, including security management organizations, safety management, personnel management, system operation management, asset security management, application security management, network security management, and security endpoint control. For data security management, data security management, data classification and grading, data security collection, privacy protection management, data compliance management, data security audits, cross-border data management, data sharing management, and business data management can be implemented. For vehicle safety management, comprehensive vehicle cybersecurity threat analysis and risk assessment (TARA), and complete vehicle information security lifecycle management (CSMS) can be conducted.
4.2 Constructing Security Threat Analysis and Risk Assessment (TARA)
Security threat analysis and risk assessment (TARA) is the process of identifying potential security threats and assessing risks associated with those threats. It is the methodology for threat analysis and risk assessment in ISO21434 and forms the methodological foundation for cybersecurity management system certification (CSMS) under the United Nations WP.29 R155, alongside hazard analysis and risk assessment (HARA) methodologies in the field of vehicle functional safety, constituting the two main methodologies for vehicle safety.
In the entire TARA analysis process, the first phase is concept and design. The first step is asset identification, which involves identifying the operating system, relevant protocols, and control domains in the threat scenario. After asset identification is complete, relevant threat modeling must be conducted to analyze the risks associated with the operating system and the interactions between certain modules and control domains through protocols, followed by vulnerability analysis, attack path analysis, risk valuation, and the design of risk treatment and protection plans.
The second phase involves research and testing, where information security testing is conducted, vulnerability mining and attack behavior analysis are performed on the overall threat scenario, and identified risks are verified and addressed.
The third phase is the production, operation, and disposal phase, where security risks that have been identified, verified, and addressed can be resolved through OTA upgrades.
4.3 Building an Automotive Information Security Management System
Based on the information security risks throughout the entire lifecycle of automotive products, an automotive information security management system should be established, including organizational management systems, product lifecycle management systems, and external management systems.
Organizational management includes cultural governance, information sharing, and tool management. Due to the complexity of vehicles, project management systems are also critical. Product lifecycle management encompasses project management, concept, research and development, production, operation, and disposal. External management includes supplier management and user management.
The Significance of Constructing an Automotive Information Security Management System
Compliance with Requirements: Based on the actual situation of the enterprise, the goal is to meet compliance requirements, assisting in the implementation of intelligent connected vehicle information security management system solutions, and preparing for certification of the automotive information security system.
Strengthening Internal Control Mechanisms to Ensure Business Continuity: Establishing and improving automotive information security processes and systems, enhancing process management; reinforcing management and coordination of overall automotive information security work according to the system to ensure its implementation.
Further Optimizing Existing Process Standards: Optimizing and improving existing security management systems to adapt to the evolving needs of intelligent connected vehicle information security.
4.4 Constructing a Security Immunity Architecture
If the entire vehicle is viewed as a person, who has a certain immunity when ill, then vehicles can also be given a certain immunity. This can be achieved by establishing defensive capabilities, monitoring capabilities, and self-stabilizing capabilities in the cloud, pipeline, and endpoint, thus constructing a security defense architecture.
Cloud-based immunity defenses include WAF, PKI, interface security, cloud-native security, secure configuration, application security, authorization management, and secure gateways. Cloud-based immunity monitoring includes V-SOC, threat intelligence, data security, and business monitoring. Cloud-based self-stabilization includes data classification and grading, and application security.
Pipeline and endpoint immunity defenses include anti-man-in-the-middle measures, DDoS resistance, transmission security, and wireless security. Immunity monitoring includes GPS spoofing monitoring and Bluetooth monitoring. Self-stabilization includes V2X communication security.
Endpoint immunity defenses include APP security hardening, device authentication, TEE, SecOc, certificate and key deployment, in-vehicle firewalls, host security, and OTA security. Immunity monitoring includes vehicle key security, charging pile security, vehicle control security monitoring, data collection security, host security, and firmware flashing. Self-stabilization includes TARA and CSMS.
4.5 Constructing a Secure Development Process (DevSecOps) Architecture
DevSecOps is an extension of DevOps, integrating Sec (Security) into the entire lifecycle of software development and testing, thereby enhancing vehicle security.
In the vehicle development security lifecycle, during the Epic&Story phase, security feasibility and inherent risk assessments are conducted. During the CODING phase, secure coding guidelines and local scanning of source code security IDEs are implemented. During the DEV phase, source code security scanning and open-source component security scanning are performed. During the SIT phase, APP security scanning/SDK privacy compliance scanning, interface security scanning, security penetration testing, and automated security report generation are conducted. In the UAT phase, external penetration testing and Docker security scanning are performed. After the product is launched, a security operations platform is established.
Generally, internet companies focus more on cloud security development processes, but in-vehicle security also requires attention to APP and embedded development security, thus broadening the scope of security concerns.
4.6 IoT Security Emergency Response & Threat Intelligence Platform
The security vulnerability response platform integrates security testing, vulnerability mining, vulnerability intelligence, expert responses, and customized services into a comprehensive security service platform for the IoT.
Security Emergency Response: The security department leads the establishment of an emergency response center to address various emergencies, forming emergency response grading standards, and collaborating with business departments to implement relevant emergency plans to help businesses respond correctly to security incidents and reduce losses and impacts.
Threat Intelligence: Purchasing third-party threat intelligence databases and building in-house threat intelligence databases.
Business Coordination: Addressing business vulnerabilities, legal affairs & market public opinion responses.
4.7 Security Talent Development
How to develop security talent can be approached from three aspects.
Security Research
Simulating and replicating vehicle systems, cloud, APP, bus protocols, and ECUs to recreate attack scenarios for related research.
Talent Development
Incorporating vulnerability target areas, vulnerability databases, and training videos for IoT security talent development.
Generally, internet companies only need to train security department personnel. However, in-vehicle security training needs to cover business departments such as electronic and electrical architecture departments and OTA business process departments, to raise awareness of risks throughout the OTA process and enhance security awareness in design and work.
Competition Drills
Red-blue drills, crowd-sourced vulnerability mining, and emergency drills can be conducted to select talents and enhance capabilities.
4.8 Coverage of IoT Security Capabilities
Security Competitions: Hosting IoT security competitions and participating in domestic IoT security competitions.
Security Training: Laboratory members providing IoT security-related training and practical training; participating in vehicle design requirement development at all stages to identify network security risks and compliance risks, providing comprehensive security solutions to stakeholders.
Security Development: Independent research and development of automated security scanning systems for API security scanning, open-source component security scanning, and more; independent development of firmware and binary automated scanning systems; in-vehicle security hardening research and development.
Security Testing: Utilizing self-developed automated scanning tools and manual testing to cover the security testing of the entire vehicle, electronic and electrical architecture components, and deliverables provided by suppliers, identifying security vulnerabilities and assisting businesses in fixing them.
Security Operations: VSOC situational awareness, PKI infrastructure, vulnerability management, and emergency response.
This article outlines the current security challenges faced by the IoV, analyzes OTA and its associated risks, and finally introduces methods such as qualification certification, TARA, constructing an automotive information security management system, building a security immunity architecture, establishing a secure development process (DevSecOps), and training security personnel to help intelligent connected vehicles achieve OTA security, providing valuable insights for enhancing OTA security.
Open and Inclusive, Collaborate and Cooperate
Share Opportunities and Achievements of Industrial Transformation
Contact Us
Beijing High-level Autonomous Driving Demonstration Zone
Office: 010-67865603
Industry Policy and Scenario Implementation: [email protected]
Vehicle Testing and Regulation: 010-67865636
Media Cooperation: [email protected]