automotive security Archives - Rambus

SAE levels of automation in cars simply explained (+Image)

Rambus Press — Thu, 09 Jun 2022 19:03:27 +0000

Formerly known as the Society of Automotive Engineers, SAE International is a global professional association and standards organization. SAE International focuses primarily on global transport industries such as aerospace, automotive, and commercial vehicles. In 2014, SAE International created the following six levels of driving automation which have since been adopted by the U.S. Department of Transportation

Autonomous vehicle technology leverages a combination of AI-powered algorithms, specialized cameras, and sensors to navigate and drive. These typically include lidar, radar, sonar, GPS, and inertial navigation systems. Self-driving cars analyze the data generated by these sensors to plot navigational paths and react in real-time by stopping, speeding up, slowing down, and avoiding objects.

Level 0: No driving automation

At Level 0, vehicles completely lack any driving automation technology. The driver is always engaged, and entirely responsible for operating the vehicle. This includes steering, accelerating, braking, parking, and any other necessary maneuverers or actions to drive or halt the vehicle.

Some Level 0 vehicles may offer limited or momentary driver assistance features, such as warnings and alerts, or even emergency safety interventions. However, these are not considered autonomous functions—so drivers must remain fully attentive and engaged. Examples of limited or momentary driver assistance include automatic emergency braking, forward collision warning, and lane departure warning.

Level 1: Driver assistance

At Level 1, automotive systems provide continuous assistance with acceleration, braking, or steering. Specific examples of Level 1 driver assistance technologies include adaptive cruise control and lane keeping assistance.

Level 1 driver assistance systems operating individually aren’t considered autonomous technology by either the SAE or US National Highway Traffic Safety Administration (NHTSA). However, adaptive cruise control and lane keeping assistance systems operating simultaneously qualify as Level 2 automation.

Both Level 1 and Level 2 technology require drivers to remain attentive and fully engaged when operating a motor vehicle.

Level 2: Partial driving automation

At Level 2, vehicles provide partial automation by continuously helping drivers with acceleration, braking, and steering. Level 2 vehicles are typically equipped with advanced driver assistance systems (ADAS) that can take control—in specific scenarios—over the above-mentioned functions.

In 2014, Tesla Motors announced its first version of Autopilot, which later expanded to support autonomous steering, braking, speed adjustment, and parking capabilities. In October 2020, Tesla rolled out the first version of its full self-driving beta (FSD Beta) software and continues to release updates at a steady cadence. Despite the introduction of additional features, Tesla’s Autopilot is still classified as Level 2 partial driving automation technology.

The Highway Driving Assist system is another example of real-world Level 2 partial driving automation. Highway Driving Assist systems are installed in vehicles manufactured by Genesis, Hyundai, and Kia. Although these cars require drivers to keep their hands on the steering wheel, the driving assist systems actively steer, accelerate, and brake when traveling on highways.

BlueCruise—a new hands-free partial driving system from Ford—is a third example of real-world Level 2 partial driving automation. BlueCruise allows drivers to take their hands off the steering wheel on certain approved highways in the United States and Canada.

Level 3: Conditional driving automation

At Level 3, vehicles autonomously handle all driving tasks. However, drivers must always be available to take the wheel if ADAS requires assistance or suddenly stops functioning effectively. Level 3 conditional driving automation systems have been developed by several major automotive companies, including Audi.

Although Audi never received approval for its traffic assistance technology, Honda managed to successfully sell a Level 3 traffic jam assistance system. Limited to Japanese roads and the Legend flagship sedan, the system was rolled out to drivers as an optional and paid upgrade.

In early 2022, Mercedes-Benz announced plans to introduce Level 3 autonomous driving capabilities in the U.S. Dubbed Drive Pilot, the technology—which was recently approved for use on certain German highways—supports speeds up to 60 kph (37 mph) and can be used to semi-autonomously navigate in heavy traffic or traffic jams. If approved, drivers will be able to take their hands off the steering wheel and stream videos, send e-mails, and communicate with colleagues.

Level 4: High driving automation

At Level 4, autonomous vehicle systems are completely responsible for all driving and navigational tasks. These self-driving cars can autonomously transport passengers who do not need to be engaged or ready to take control of the vehicle.

However, Level 4 high driving automation systems are typically limited to specific geographic locations—and cannot travel outside of designated service areas or during dangerous weather conditions. Level 4 high driving automation is particularly well suited for driverless taxis and buses on designated routes, trucks transporting goods within specific geographic boundaries, as well as airport passenger and cargo (luggage) shuttles.

Level 5: Full driving automation

At Level 5, autonomous vehicles take full control of all driving and navigational tasks. Passengers simply set a destination and can work, sleep, watch movies, and play games. In the future, vehicles equipped with Level 5 full driving automation systems will operate independently and universally in all weather conditions and roadways.

Infographic

What level of autonomy do most vehicles have now?

Most cars and trucks on the road today feature limited levels of autonomy that span Levels 0 to 2. However, automakers have already announced Level 3 autonomous driving cars—and are working to develop and deploy Level 4 self-driving trucks as well as commercial robotaxis. According to Accenture, vehicles with full-on self-driving capabilities could start hitting highways as early as 2030.

Self-driving cars reduce the risk of accidents and collisions by implementing safeguards, alerting drivers, and taking full control of a vehicle if necessary. Moreover, self-driving cars automatically detect and react to other vehicles, bicyclists, pedestrians, construction zones, potholes, traffic accidents, and traffic jams. Perhaps most importantly, self-driving cars enforce safety standards that may be deliberately or accidentally ignored by human drivers.

Additional Resources:

– Other blogs around automotive & security:

What is OTA in automotive? Over the air updates explained.

Rambus Press — Fri, 13 May 2022 14:30:41 +0000

Over-the-air (OTA) programming refers to the ability to download applications, services, and configurations over a mobile or cellular network. Over-the-air (OTA) programming is used to automatically update firmware, software, and even encryption keys. Specific OTA categories include:

Software over-the-air (SOTA)
Firmware-over-the-air (FOTA)
Over-the-air service provisioning (OTASP)
Over-the-air provisioning (OTAP)
Over-the-air parameter administration (OTAPA)

Here are some other subtopics we will cover in this article:

How do OTA updates work?

A device management system operated by the manufacturer issues a new software or firmware update. The update is uploaded to the cloud where it is queued, downloaded, and verified by the target device over a cellular or mobile connection. Once verified, the device typically triggers an alert that prompts the owner to approve or decline the update. After confirming approval—whether manually or automatically—the system installs the update and sends back diagnostic information to the manufacturer.

Software over-the-air updates are now quite common in the automotive market, with major vehicle manufacturers routinely rolling out SOTA upgrades for infotainment and navigation systems. SOTA can also update software controlling a vehicle’s physical components or electronic signal processing systems. In contrast to SOTA, firmware-over-the-air upgrades have only been implemented at scale by a small number of automotive manufacturers, including Tesla and NIO. This is because FOTA updates typically demand more computing power, faster mobile connections, and higher levels of security.

Most automakers are already designing vehicle hardware to support software updates. This enables manufacturers to shift to a revenue model that is based on services—rather than a one-time sale of a car or truck. According to Gartner analysts, half of the top 10 global automakers will offer unlocks and capability upgrades via software updates by 2023. It should be noted that Tesla began monetizing OTA upgrades in 2019 when it offered Model 3 owners an acceleration boost—from 4.6s to 4.1s—for $3,000.

How do connected cars get updates?

Most cars with infotainment systems can receive software updates. Some automotive operating systems, such as BMW’s OS 7/8, Mercedes MBUX, and Tesla, continuously scan for OTA updates in the cloud. Once identified, the update is downloaded, verified, and run by the telematics control unit (TCU) of a connected vehicle.

TCUs wirelessly connect cars and trucks to cloud services and other vehicles with V2X standards over a cellular network (4G/5G). The TCU also collects essential vehicle telemetry data, including geographical position, speed, vector, engine information, and connectivity strength.

Why would my car need a software OTA update?

OTA updates—which improve the driving experience and create safer roads—are delivered remotely and do not require a trip to a dealership or mechanic. These updates can be grouped into two primary categories: infotainment and drive control.

Infotainment updates refresh map information, upgrade audio capabilities, and optimize user interfaces, streaming services, and apps. Although infotainment updates significantly improve the in-car experience, they are not mission-critical.

In contrast, drive control OTA updates directly affect the ability of a vehicle to operate safely and efficiently. These updates typically include system enhancements or fixes for powertrain systems, chassis systems, brakes, and advanced driver assistance systems (ADAS). Drive control OTA updates—which may also improve range and charging for electric vehicles (EVs)—are generally considered critical or required.

Most automakers have already updated new vehicle hardware to support software updates. For example, Tesla pre-designs hardware and software to accommodate future function expansion requirements. New functions, along with full lifecycle updates, are introduced at a steady cadence via software upgrades.

How to address over-the-air automotive security challenges?

Unsecured automotive over-the-air updates are susceptible to multiple threats and attacks such as spoofing, tampering, repudiation, escalation of privileges, and information leakage. These threats can be mitigated by encrypting software updates; using a signed certificate containing the public key of the entity requesting the update; digitally signing updates after encryption; securing all network transactions with TLS public key authentication (signed by a trusted Certificate Authority); and (clients) performing hostname verification to ensure they are connecting a verified server.

Additional mitigation techniques include only delivering updates to authorized devices; the tamper-proof logging of all important events; the initialization of SOTA/FOTA updates with a secure boot mechanism; software update systems that are designed to “fail gracefully” in the case of a denial-of-service (DoS) attack; the utilization of anti-malware protection such as whitelists and in-memory protection; and ensuring that compliant SOTA/FOTA software update systems clear all shared resources of sensitive data and keys that were temporarily stored during software updates.

In addition to the above guidelines, the National Highway Traffic Safety Administration (NHTSA) has published official OTA update recommendations in its “Cybersecurity Best Practices for the Safety of Modern Vehicles” report. According to the NHTSA, vehicle manufacturers should:

Maintain the integrity of OTA updates, update servers, the transmission mechanisms, and the updating process in general.
Take into account, when designing security measures, the risks associated with compromised servers, insider threats, men-in-the-middle attacks, and protocol vulnerabilities.

What company makes the security technology for OTA updates?

Rambus automotive embedded hardware security modules (HSMs) can help manufacturers adhere to the NHTSA’s recommendations. In addition to securing SOTA/FOTA upgrades, these HSMs provide secure boot, secure debug capabilities, and work with other security functions such as MACsec, IPsec, and TLS embedded protocol engines to protect network traffic in cars. To operate properly, components such as electronic control units (ECUs) and other systems must run the manufacturer intended firmware—without tampering. A root of trust ensures firmware is valid and can be securely updated when needed.

Rambus offers embedded HSM (root of trust) variants for both ASIL-B (RT-640) and ASIL-D (RT-645) that are specifically designed for the functional safety requirements of ISO 26262, an international automotive electronics system standard. The Rambus RT-640 Embedded HSM recently received Automotive Safety Integrity Level B (ASIL-B) ISO 26262 certification. Certified ASIL-B compliance is a critical requirement for automotive manufacturers and their suppliers to ensure vehicle systems meet necessary safety levels. Integrated into an automotive SoC, the ASIL-B certified RT-640 silicon IP design provides powerful cryptographic functions, state-of-the-art safety mechanisms, and anti-tamper technologies to protect critical automotive electronics and data.

From a holistic perspective, Rambus end-to-end security solutions comprise a tightly integrated ecosystem that enables simple, rapid, and secure integration into automotive supply chains. Chips and devices can be securely provisioned at the time of manufacture with CryptoManager Provisioning and securely managed through cloud-based services over the entire lifetime of a vehicle. The cloud-based Rambus CryptoManager Device Key Management platform also enables automakers and partners to deliver Feature-as-a-Service (FaaS) by leveraging provisioned cryptographic keys and identities.

Additional Resources:

– Other blogs around Over-The-Air updates (OTA):
1. Securing connected vehicles with Rambus CryptoManager
2. Securing intelligent transportation systems
3. How not to get pwned @ automotive cyber-security
4. Securing chips for the IoT
5. Mitigating DDoS attacks with secure IoT endpoints
6. The challenge of securing smart homes
7. Hack the planet: Security concerns about the IoT

– White Paper: Navigating the Intersection of Safety and Security

– Market page: Automotive Solutions

– Products for Automotive Applications:

Autonomous Vehicles: Everything about self-driving cars explained

Rambus Press — Fri, 08 Apr 2022 10:51:33 +0000

A self-driving car is a computer-controlled vehicle that drives itself. Also referred to as an autonomous vehicle, driverless car, or robotic car (robo-car), a self-driving car analyzes its environment to safely move and react without human input.

In this article, you’ll learn:

6 levels of autonomous cars

In 2014, the engineering group SAE International created six levels of driving automation which have since been adopted by the U.S. Department of Transportation. These include:

Level 0: No automation
Level 1: Driver assistance
Level 2: Partial driving automation
Level 3: Conditional driving automation
Level 4: High driving automation
Level 5: Full driving automation

Automakers have already announced Level 3 autonomous driving cars—and are working to develop and deploy Level 4 self-driving trucks as well as commercial robotaxis. According to Accenture, vehicles with full-on self-driving capabilities could start hitting highways as early as 2030.

Keep on reading: SAE level of automation in cars simply explained.

History of autonomous vehicles

The concept of a self-driving car was first introduced by General Motors (GM) at a 1939 World Fair exhibit. In 1953, RCA Labs and GM built a miniature car that was guided and controlled by patterned wires. A full-size system was subsequently demonstrated in Nebraska using specially designed road lights and buried detector circuits.

By the 1980s, self-driving technology had improved considerably, with the Defense Advanced Research Projects Agency (DARPA) leveraging lidar, computer vision, and autonomous robotic controls to direct a vehicle at speeds of up to 19 miles per hour (31 km/h). DARPA partner HRL Laboratories later demonstrated the first off-road map and sensor-based autonomous navigation in a test vehicle that traveled over 2,000 feet (610 m) at 1.9 miles per hour (3.1 km/h) through challenging terrain.

The 1990s saw Carnegie Mellon University pioneer and refine neural networks to steer and control autonomous vehicles under the auspices of the Navlab project, with a test vehicle completing a 3,100 miles (5,000 km) cross-country journey. Additional self-driving advances were made by major automakers and technology companies like Waymo, Uber, and Tesla throughout the 2000s, 2010s, and early 2020s. In 2014, Tesla Motors announced its first version of Autopilot, which later expanded to support autonomous steering, braking, speed adjustment, and parking capabilities. In October 2020, Tesla rolled out the first version of its full self-driving beta (FSD Beta) software and continues to release updates at a steady cadence.

How do self-driving cars work?

Most advanced driver-assistance systems (ADAS) powering vehicles with various levels of autonomy leverage a combination of specialized cameras and sensors to create an internal map of the vehicle’s surroundings. These sensors include:

Lidar—Pulses thousands of beams of infrared laser light at objects to calculate distances and avoid objects.
Radar—Uses radio waves to measure angles, ranges, and velocities of objects in most environmental conditions.
Sonar—Identifies large objects made of solid materials, such as metal and ceramics, at short distances.
Inertial navigation system—Helps self-driving cars stabilize themselves.
GPS—Geolocates with numerical coordinates, including latitude and longitude, while navigating by combining real-time GPS coordinates with other digital map data applications.

Self-driving cars analyze the data generated by these sensors to plot navigational paths and react in real-time by stopping, speeding up, slowing down, and avoiding objects. They reduce the risk of accidents and collisions by implementing safeguards, alerting drivers, and taking full control of a vehicle if necessary. Moreover, self-driving cars automatically detect and react to other vehicles, bicyclists, pedestrians, construction zones, potholes, traffic accidents, and traffic jams. Perhaps most importantly, self-driving cars enforce safety standards that may be deliberately or accidentally ignored by human drivers.

Security vulnerabilities, risks & concerns of connected and autonomous vehicles

Semiconductors in connected vehicles and self-driving cars power extremely complex electronic systems. In the past, vehicle electronic systems implemented flat architectures with isolated functions controlling various components of the powertrain and vehicle dynamics. These electronic systems communicated primarily through legacy bus interconnect protocols, such as controller area network (CAN) and media-oriented systems transport (MOST) technologies.

To support the realization of Level 4 and Level 5 (L4/L5) autonomous driving, a massive architectural shift is underway. The software-defined vehicle, automotive Ethernet, vehicle-to-everything (V2X) connectivity, over-the-air updates (OTAs), and domain controller units are just some of the technologies required to achieve L4/L5 capabilities.

Indeed, new electronic systems support powertrain and vehicle dynamics, ADAS, autonomous driving, connectivity, and infotainment. At the heart of these electronic systems is a complex, multi-island IC containing multi-core processing, dedicated artificial intelligence and machine learning (AI/ML) engines, mixed-signal processing, and more.

Whether it’s a complex system on chip or a mixed-signal IC sitting at a sensor edge, security and safety are essential. Indeed, the advancements in vehicle electronic systems have resulted in a large attack surface for adversaries to exploit. In commercial or industrial applications, security is focused on providing trust, protecting assets, and protecting identities. In automotive, these focus areas remain, but another dimension is added.

This is because security vulnerabilities have the potential to directly impact safety measures implemented in a vehicle. For example, the lack of a robust safety architecture can cause a design to malfunction, with failures creating new security penetration points in the ICs, systems, and throughout the entire vehicle. On the flip side, an incomplete security architecture may be exploited by adversaries to circumvent or disable safety features, making the vehicle vulnerable to run-time failures.

What company makes the security technology for ADAS?

Rambus automotive hardware security modules (HSMs) are designed to protect self-driving cars and connected vehicles. These HSMs provide secure boot, secure firmware (OTA) upgrades, secure debug, and work with other security functions such as MACsec, IPsec, and TLS embedded protocol engines that protect network traffic in cars. To operate properly, ECUs must run the manufacturer intended firmware—without tampering. A root of trust ensures firmware is valid and can be securely updated when needed. Rambus offers embedded HSM (root of trust) variants for both ASIL-B (RT-640) and ASIL-D (RT-645) that are specifically designed for the functional safety requirements of ISO 26262, an international automotive electronics system standard.

The Rambus RT-640 Embedded HSM recently received Automotive Safety Integrity Level B (ASIL-B) ISO 26262 certification. Certified ASIL-B compliance is a critical requirement for automotive manufacturers and their suppliers to ensure vehicle systems meet necessary safety levels.

Integrated into an automotive SoC, the ASIL B certified RT-640 silicon IP design provides powerful cryptographic functions, state-of-the-art safety mechanisms, and anti-tamper technologies to protect critical automotive electronics and data.

Moving the flood of data in autonomous vehicles

All the data from the array of cameras and sensors employed in autonomous vehicles takes tremendous bandwidth. The MIPI Camera Serial Interface 2 (MIPI CSI-2®) v3.0 is increasingly the workhorse solution for transporting this vast volume of data. CSI-2 v3.0 offers capabilities including Unified Serial Link (USL) for encapsulating connections between a sensor module and application processor.

Regarding the choice of network connectivity in electronic systems, weight is not normally a first-order consideration, but it absolutely is when it comes to vehicles. A major networking hurdle introduced by the proliferation of sensors is the weight of cabling. In many vehicles, wiring is one of the top four heaviest subsystems. This issue is compounded as more cars go electric adding in the weight of the battery. A Tesla® battery pack, for instance, weighs about 900 pounds which nets out much heavier than an engine and full tank of gas.

What’s more, it’s often the electric vehicle makers that are leading the charge for autonomous driving. They need more sensors and better networking while simultaneously reducing weight to compensate for the battery. The weight benefit of MIPI, and networking technology such as automotive Ethernet, is that it can provide low-latency, high-bandwidth connections with fewer wires than legacy networking solutions. This enables the continued profusion of sensors for ADAS while keeping the weight of cabling low.

On the human interface side, whether for instrumentation, navigation or entertainment, modern vehicles include a large and growing number of displays. Here too MIPI plays a leading role with DSI-2^® solutions providing the high-bandwidth, low latency connectivity needed for high-resolution video and images.

What company makes automotive MIPI solutions?

Rambus has been a provider of MIPI IP solutions since 2010 and offers 32 and 64-bit digital controllers for CSI-2 and MIPI DSI-2 connectivity. Partnering with top-tier MIPI C/D-PHY suppliers, such as Mixel and Samsung, Rambus solutions have enabled over 250 ASIC and FPGA MIPI designs. An increasing number of these designs are for ADAS applications with leaders in the automotive market which Rambus supports with a full suite of customization and integration services, applicable safety manual, FMEDA and DFMEA.

Rambus MIPI CSI-2 Controller Block Diagram

The Rambus MIPI CSI-2 Transmitter (TX) Controller and the associated development processes have been certified to meet the ISO 26262 functional safety requirements. As with the embedded HSM solutions discussed earlier, using ISO 26262 certified IP enables automotive chip makers to accelerate the process of creating and safety certifying their SoCs.

Additional Resources:

– Other blogs around automotive & security:

– White Paper: Navigating the Intersection of Safety and Security

– Market page: Automotive Solutions

– Products for Automotive Applications:

Rambus talks vehicle security at TU-Automotive

Rambus Press — Tue, 22 Nov 2016 15:51:11 +0000

Joe Gullo, the senior director for Rambus automotive strategy and development, recently participated in a TU-Automotive panel that explored the importance of securing next-gen autonomous vehicles. Indeed, the number of threat vectors in the automotive sector have exponentially increased in recent years. This is due to a range of factors, such as more complex software code, ubiquitous connectivity, a greater number of components and broader functionality.

Gullo kicked off his Q&A session by observing that automotive security best practices currently fall into three primary categories: authentication, multi-faceted designs, and flexibility.

“Authentication needs to happen in both directions. In other words, the car has to trust the cloud and the cloud has to trust the car,” he told panel participants and conference attendees. “Unfortunately, I think that authenticating vehicles sometimes gets less attention than it should. This is also true for any IoT device, even refrigerators and washing machines.”

As Gullo pointed out, a multi-faceted design approach is required to address a range of threat vectors, including attacks on the cloud-to-car connection, the in-vehicle network and specific ECUs. However, he emphasized there isn’t a “single, simple solution” that offers optimal security.

“For example, the components for V2X security may not be effective for monitoring and protecting in-vehicle networks. In general, security architectures need to be flexible because future threats are unlikely to resemble our current understanding of threat vectors,” Gullo explained. “These architectures need to have the ability to learn, evolve, and improve ‘in the field’ as new threats emerge. We also need to be thoughtful regarding solution complexity so systems can be adapted quickly as new threats emerge. This means relying on the fundamentals, such as proven algorithms, robust key management, secure boot loaders and constant threat detection, for example.”

As Gullo noted, this is precisely why automotive security architecture needs to evolve from static, simple solutions to a more dynamic framework that is self-learning, easily updatable and multi-faceted to address multiple threat vectors. This progression inevitably brings a number of new issues to the fore, including end-to-end secure data storage for autonomous vehicles.

“There are a host of companies whose core competence is secure, cloud-based data storage. OEMs can and should leverage these companies, although they should make it clear that while partners are tasked with securely storing data, they don’t own it,” Gullo opined. “Analyzing the data, generating insights from the information and acting on those insights is solely within the purview of the OEMs. Also, it goes without saying that a robust key management solution is required to secure the data in the vehicle and during transmission to and from the cloud service.”

To be sure, there are expected to be more than 350 million connected cars on the road by 2020. Google’s autonomous vehicles generate about 1 gigabyte of data every second, while Intel says autonomous vehicle are likely to produce about 2 petabytes of data per year. Information generated by connected and autonomous vehicles includes environmental data, as well as vehicle and driver performance.

“Maintaining the integrity of safety-critical and forensic vehicle data, particularly with respect to V2X, driver performance and vehicle performance, is absolutely critical. While some data should be shared for the ‘common good,’ it will undoubtedly be challenging to reach consensus on precise parameters,” Gullo emphasized. “Whether it’s through the Auto-ISAC or some other consortium, the industry clearly needs to agree on a ‘common good’ data set and ensure that vehicle owners are aware of the requirement to share this information.”

Gullo also described current security standards, specifications and guidelines including the ISO 26262 standard for functional safety and SAE’s J3061 Cybersecurity Guidebook (for Cyber-Physical Vehicle Systems).

“There is also SAE’s pending J3101 standard titled Requirements for Hardware-Protected Security for Ground Vehicle Applications, while UMTRI and the Southwest Research Institute are working on a framework for secure OTA software and firmware upgrades. This space is still evolving, although quite a lot has already been accomplished,” he added.

Video: Rambus and Movimento secure OTA updates for connected vehicles

Rambus Press — Thu, 21 Jul 2016 16:46:06 +0000

Earlier this summer, Rambus and Movimento teamed up to demonstrate a joint OTA update solution at TU-Automotive in Detroit. Essentially, Movimento’s OTA technology uses Rambus’ CryptoManager platform to enable in-field provisioning of encrypted keys generated for a specific vehicle, thereby facilitating secure communication between cars and the Cloud.

“We tend to think of cars as mechanical [entities], but [modern vehicles] are actually very sophisticated,” Asaf Ashkenazi, senior director, product management for Rambus’ Security division, explained.

“So we need to make sure that we not only address today’s security challenges, but also those [that could occur] one or even five years from now.”

As Ashkenazi notes, most OTA solutions currently on the market offer limited functionality and lack personalization features.

“[For example], secure elements work fine for some purposes, but they aren’t enough for OTA vehicle updates. [Yes], they can get a key into a car, but without personalization, they end up using the same key in all vehicles,” he told the EE Times earlier this summer. “Alternatively, one can specify one key for each vehicle. But this requires automakers to implement the secure injection of keys at the manufacturing site. No personalization means that each vehicle has no unique key, which is critical in authenticating codes for software downloads.”

In contrast, says Ashkenazi, updates provided by Movimento and Rambus are delivered via one-time, single-use keys that are unique to each vehicle.

“Today we are using CryptoManager for over the air updates, but tomorrow we can use it for other solutions. Security is not new to us and we believe there is a real need for what we’re doing,” he added.