Anti-tamper sensors are an essential tool among several defenses used to protect against these security threats. By continuously monitoring for abnormal environmental or electrical conditions, anti-tamper sensors help ensure that when a device is touched, opened, glitched, or zapped, your security stack knows and reacts to protect your system.

The Modern Tamper Landscape

Today’s adversaries use voltage glitching to skip instructions, clock manipulation to desynchronize logic, and electromagnetic fault injection (EMFI) to flip bits at precise moments. They may also use strong magnets or environmental shifts to blind sensors or disrupt measurements, especially in metering and industrial systems.

Why does this matter? Because hardware secrets (keys, certificates) underpin secure boot, encrypted communications, and software trust. Physical compromise of just one device can open a backdoor to a much larger network if unique per device protections and real-time tamper responses aren’t in place.

The Top Customer Pain Points

From conversations with SoC designers, several recurring challenges emerge:

1. Evolving attack techniques
   Digital-only countermeasures often miss analog domain faults like voltage, clock, and EMFI attacks. Teams need diverse, low latency sensors that can spot subtle, nanosecond scale anomalies before damage is done.
2. Integration across process nodes and foundries
   Analog IP is traditionally process specific, making portability painful when supply constraints or costs push a design to another process node or foundry. Reengineering slows releases and consumes scarce analog engineering talent.
3. Tuning and false positives and negatives
   Tamper sensors must be sensitive without being noisy. Poor thresholding or inadequate environmental compensation can trigger needless shutdowns, or worse, miss an actual attack. Getting that balance right demands robust IP and good system architecture
4. Compliance pressure
   Regulations and certifications (e.g., FIPS 140-3 Level 3 and 4, Common Criteria High Assurance Levels, SESIP L3, ISO 21434) add requirements for key protection,  tamper responses, and secure boot. Meeting them while hitting power, area, and schedule targets is hard.

What a “Good” system Looks Like: Principles of Anti-tamper by Design

A resilient anti-tamper strategy embraces sensor diversity, secure event handling, and automated responses:

• Multi‑modal sensing (voltage, clock, temperature, magnetic/EMFI) to detect a broad spectrum of physical attacks.
• Secure response paths anchored in a hardware Root of Trust (RoT)—so detected events can trigger policy-driven actions like key zeroization, boot lockdown, or secure telemetry, even if an application code is compromised.
• Per device uniqueness (unique keys, secure provisioning) to contain the blast radius if one unit falls into the wrong hands.

This is where Agile Analog and Rambus complement each other.

Agile Analog: Deep Tamper Detection + Prevention in the Analog Domain

Agile Analog’s agileSecure portfolio brings a comprehensive, customizable set of tamper detection IP to protect SoCs on advanced process nodes:

• agileVGLITCH – Voltage Glitch Detector: Detects nanosecond scale supply anomalies used in instruction skipping and bypass attacks.
• agileCAM – Clock Attack Monitor: Catches clock frequency shifts, holds, and glitches with programmable thresholds.
• agileTSENSE_D – Digital Temperature Sensor: Monitors abnormal thermal profiles indicative of physical interference or environmental manipulation.
• agileEMSensor – EMFI Detector: Detects electromagnetic fault injection, one of the hardest physical attack vectors to counter with digital logic alone.

Beyond tamper detection, Agile Analog’s agileSecure also offers tamper prevention IP—internally biased LDOs, bandgap references, oscillators, power-on reset and power-OK blocks—to isolate and harden critical circuits against external manipulation.

Why customers choose Agile Analog

• Process portability and time-to-market: Their digitally wrapped, process agnostic, fully verified approach helps teams seamlessly integrate analog IP blocks like digital IP, reducing re-spins across nodes/foundries and speeding SoC schedules.
• Standards alignment: Deployments are increasingly aligned with FIPS 140‑3 and Common Criteria requirements—critical for regulated markets.
• Proven on advanced process nodes: Recent deliveries include TSMC N4P engagements with a tier1 U.S. customer, underscoring maturity on cutting-edge processes.

Rambus: Hardware Root of Trust, Anti-tamper, and QuantumSafe Security

While Agile Analog monitors and hardens the physical attack surface, Rambus provides the secure control plane that decides what to do when tampering is detected.

The CryptoManager Security IP family spans Root of Trust (RoT), Hub, and Core offerings, delivering progressively higher levels of functionality and integration:

• Hardware RoT with secure boot, secure storage, and policy driven tamper responses—available from compact state machines to programmable secure coprocessors.
• Quantum‑Safe boot flow and crypto accelerators to protect against future quantum compute threats while meeting today’s performance needs.
• DPA/FIA countermeasures to resist power analysis and fault injection at the cryptographic core, complementing analog tamper detection located next to critical circuitry.
• Inline memory encryption and protocol engines (MACsec/IPsec/TLS) to protect data in use and in motion, completing a holistic data‑centric security posture.

With support for FIPS, SESIP, PSA Certified, and ISO 21434, CryptoManager solutions help teams accelerate certification and ship faster into regulated markets like automotive and data centers.

Mapping Pain Points to the Joint Solution

Implementation Checklist: Getting It Right the First Time

1. Threat model by device class. Map likely physical attacks (serviceable vs. sealed units, field vs. factory) and decide which sensors you need (voltage, clock, temp, EMFI) for layered coverage.
2. Place sensors near assets. Position voltage and clock monitors on relevant domains and route signals securely to the RoT—short paths, shielded where practical.
3. Calibrate and test. Use built-in programmability to tune thresholds across PVT corners. Run fault injection tests (voltage glitches, clock glitches, EMFI) pre and post silicon to validate coverage and false positive rates.
4. Provision uniquely, attest continuously. Unique keys and attestation to prevent a single device compromise from scaling to a fleet.
5. Plan for updates. As attacks evolve, update RoT policies and, where applicable, firmware to refine responses without re-spinning silicon.

Real‑World Momentum

Agile Analog has announced deliveries of its agileSecure anti-tamper suite—including EMFI sensing—to tier1 customers on TSMC N4P, reflecting demand for robust analog security IP on advanced process nodes. As well as tamper detection IP, the portfolio also includes tamper prevention IP (LDOs, bandgaps, POR/POK) to harden critical circuits against manipulation. In parallel, Rambus introduced its nextgen CryptoManager Security IP with a three-tier architecture, QuantumSafe boot, and a broad certification roadmap—aimed squarely at data center, AI, automotive, and high assurance SoCs.

The Bottom Line

Anti-tamper sensors are non-negotiable in a world where physical attacks are mainstream. But sensors alone aren’t enough. You need a secure control plane that can decide and act, anchored in hardware, with the independent analysis that certifications bring and countermeasures to withstand both today’s and tomorrow’s threats.

• Agile Analog delivers highly configurable analog tamper detection and tamper prevention IP — portable across processes, tuned for advanced nodes, and designed to spot the faults attackers rely on.
• Rambus provides the Root of Trust and cryptographic backbone—with anti-tamper hardening, QuantumSafe readiness, and a proven path to compliance.

Together, they offer a defense in depth blueprint that addresses customer pain points comprehensively: better detection, simpler integration, fewer false positives, and smoother certification. If your roadmap includes secure SoCs for AI, automotive, industrial, or payments, pairing  Agile Analog’s agileSecure with Rambus CryptoManager is a pragmatic way to raise the bar.

The categories of tampering attacks include:

• Non-invasive: usually passive, the attacker monitors the operation of the chip but does not try to modify its normal operation
• Semi-invasive: an attacker induces electrical failures within the chip and monitors the resulting effects
• Fully invasive: often destructive attacks where an attacker bypasses shields, modifies signal connectivity, etc.
• Reverse engineering: destructive analysis of the chip aimed at obtaining the non-volatile memory (NVM) contents or recovering netlist algorithms

One of the values of thinking about the threat in this hierarchical manner is that it aids in planning the anti-tamper defenses for a chip appropriate to the motivation and funding of the attacker. For instance, if a chip is going into a military platform that could fall into the hands of a state-actor adversary, then it should be hardened against the full range of tampering attacks.

Within this context, Scott details eleven categories of tampering attacks ranging from protocol and software attacks to NVM extraction attacks. For each category, he lays out the resources and skills adversaries employ and the countermeasures to counter these attacks. It’s a great road map for chip makers planning the anti-tamper safeguards they need to incorporate into their designs. You can listen to a replay of the full webinar here.

White hat security researchers from Vrije Universiteit Amsterdam and ETH Zurich have unveiled a new exploit dubbed NetCAT. The exploit targets Direct Cache Access (DCA) – widely known as Data-Direct I/O (DDIO) – found in recent generations of Intel server processors. As a performance optimization feature, DDIO grants network devices and other peripherals access to the CPU cache and inadvertently exposes servers in local untrusted networks to remote side-channel attacks.

According to the researchers, NetCAT represents the first network-based PRIME+PROBE cache attack against the processor’s Last Level Cache (LLC) of a remote machine.

“NetCAT not only enables attacks in cooperative settings where an attacker can build a covert channel between a network client and a sandboxed server process (without network), but more worryingly, in general adversarial settings. In such settings, NetCAT can enable disclosure of network timing-based sensitive information,” the researchers state in a recently published paper that offers an in-depth description of the exploit.

“As an example, we show a keystroke timing attack on a victim SSH connection belonging to another client on the target server. Our results should caution processor vendors against unsupervised sharing of (additional) microarchitectural components with peripherals exposed to malicious input.”

Leaking SSH Passwords

In real-world terms, NetCat enables an attacker to discern an SSH password as it is typed into a terminal. As The Register’s Shaun Nichols explains, a well-positioned eavesdropper can connect to a server powered by one of Intel’s vulnerable chipsets and potentially observe the timing of packets of data – such as keypresses in an interactive terminal session – sent separately by a victim that is connected to the same server.

“These timings can leak the specific keys pressed by the victim due to the fact people move their fingers over their keyboards in a particular pattern, with noticeable pauses between each button push that vary by character,” writes Nichols. “These pauses can be analyzed to reveal, in real time, those specific keypresses sent over the network, including passwords and other secrets.”

As Nichols notes, a determined attacker can monitor keystrokes by repeatedly sending a string of network packets to the server and filling one of the processor’s memory caches.

“As the victim sends in their packets, the snooper’s data is pushed out of the cache by this incoming traffic,” he elaborates. “As the eavesdropper quickly refills the cache, it can sense whether its data was still present or evicted from the cache, leaking the fact its victim had sent over some data. This ultimately can be used to determine the interval between the victim’s incoming packets and thus the keys pressed and transmitted by the victim.”

The Unintended Security Vulnerabilities of DDIO

According to the Vrije Universiteit Amsterdam (VUSec) website, DDIO was specifically introduced to improve the performance of server applications running on fast networks. Indeed, rather than reading and writing from and to slow memory, DDIO enables peripherals to read and write from and to the fast (last-level) cache.

“In traditional architectures, where the network card uses direct memory access (DMA) to talk to the operating system, the memory latency alone quickly becomes the bottleneck on fast (e.g., 10Gb/s) networks,” the researchers explain. “To alleviate the bottleneck, Intel introduced DDIO, an architecture where peripherals can operate direct cache access on the CPU’s (last-level) cache. The DDIO cache region is not dedicated or reserved in the cache, but allocating writes are statically limited to a portion of the cache to avoid thrashing caused by I/O bursts or unconsumed data streams.”

Complexity vs. Security

It is important to understand that hardware-based CPU vulnerabilities were inadvertently created over the years by well-meaning engineers focused on designing ever-faster silicon. To be sure, CPU performance increased significantly in recent decades, with speeds improving every year. This rather impressive feat was made possible by chip architects who leveraged a range of clever techniques to squeeze as much performance as possible out of every transistor, even as the number of available transistors was increasing as per Moore’s Law.

As the years went on, new techniques were adopted for increasing performance while many of the old ones were still in use. The new techniques were more complex, because most of the easy approaches had already been adopted. As a result, the techniques required to increase chip performance became more complex and multi-layered. From a security perspective, this complexity has arguably led to a decrease in security. Increasing silicon complexity – across a diverse range of devices and verticals – practically guarantees that additional vulnerabilities with varying threat levels will continue to be unknowingly introduced into devices and systems. Moreover, a successful attacker has only to identify a single vulnerability, while system designers must secure a multitude of functions and interactions.

Despite real-world security risks, techniques to accelerate CPU speeds remain critical as compute workloads become more processor intensive. Nevertheless, system designers should be considering a more comprehensive and holistic approach to security, rather than simply focusing on the micro-architectural level question of ‘how do we optimize the CPU?’ Rather, they should be thinking about securing the system at the most fundamental architectural level of the system itself. Put simply, semiconductor security is dynamic and should evolve organically to intelligently and proactively protect changing workloads and applications.

Here’s a much more sobering fact: earlier this decade, the Senate Armed Services Committee found over 1,800 cases where counterfeit electronic components were introduced into U.S. military hardware, including airplanes, helicopters and missiles. Let’s be clear about what that means; in each of those cases, a semiconductor of unknown origin, of dubious quality, and operating in a manner which cannot be assessed found its way into equipment used by our servicemen and women. This is not only an immediate risk to the health and safety of our troops, but also a potential significant security threat.

To be clear: Not all counterfeit semiconductors are the product of nefarious parties. Some are simply “recovered” from scrap stock, while others are removed from older circuit boards and reworked to look new. However, there is no real way to know this. While some may be the product of a party simply trying to reuse discarded stock, many of the counterfeit semiconductors are in fact manufactured to look and function like the real thing…but why? Further clarity: Like counterfeit consumer goods, it’s often impossible to visually determine if a semiconductor is authentic or not.

It’s not all doom and gloom though. There are ways to help address this issue. Rambus has recently released a white paper on this topic, where we explore the topic of how to combat counterfeit semiconductors in the military supply chain. Specifically, we address:

• The magnitude of the problem of counterfeit chips in the military supply chain?
• How and why are chips counterfeited?
• Why is the defense market in particular so susceptible to counterfeiting?
• The consequences of an unsecured supply chain
• How our CryptoManager Infrastructure and CryptoManager Root of Trust can help address this growing threat

The white paper is free to download. Click here for access.

The Defense Advanced Research Projects Agency (DARPA) recently published an article that details the goals of its Automatic Implementation of Secure Silicon (AISS) program. As the name implies, AISS aims to automate the process of incorporating scalable defense mechanisms into chip designs, while enabling designers to explore economics versus security trade-offs and maximize design productivity.

“The security, design and economic objectives of a chip can vary based on its intended application. As an example, a chip design with extreme security requirements may have to accept certain tradeoffs,” explains Serge Leef, a program manager in DARPA’s Microsystems Technology Office (MTO). “Achieving the required security level may cause the chip to become larger, consume more power, or deliver slower performance. Depending on the application, some or all of these tradeoffs may be acceptable, but with today’s manual processes it’s hard to determine where tradeoffs can be made.”

According to DARPA, AISS aspires to develop a design tool and IP ecosystem – which includes tool vendors, chip developers, IP licensers and the open source community – that will enable security to be inexpensively incorporated into chip designs with minimal effort and expertise. More specifically, AISS addresses four specific attack surfaces: side channel attacks, reverse engineering attacks, supply chain attacks and malicious hardware attacks.

In addition to on-chip defenses, AISS seeks to ensure that silicon IP blocks remain secure throughout the design process. As such, the program aims to advance provenance and integrity validation techniques for preexisting design components by improving current methods or inventing novel technical approaches. Such techniques could include IP watermarking and threat detection to help validate the chip’s integrity and IP provenance throughout its lifetime.

Secure silicon in a post-Meltdown & Spectre world

From our perspective, DARPA’s AISS program is critical in a world haunted by the fallout of Meltdown and Spectre, which were independently disclosed in January 2018 by multiple security researchers, including senior Rambus technology advisor Paul Kocher and senior Rambus security engineer Mike Hamburg. Essentially, the two security flaws exploited critical vulnerabilities across a wide range of modern processors, including Intel, ARM and AMD. Although Meltdown and Spectre were certainly not the first high-profile semiconductor security flaws to gain widespread attention, they did represent a new class of vulnerabilities related to out-of-order and speculative execution.

As Kocher notes in a recent Rambus Press article, the industry is clearly in need of better ways to protect security-critical computations, ideally without the slowing of less sensitive performance-critical tasks.

“Processor design teams are radically rethinking the relationship between hardware and software,” he writes. “The one-size-fits-all philosophy that has historically limited thinking for computing architectures has been replaced with excitement about tailored designs. Looking toward 2019 and beyond, we’re going to see processors that are tailored for specific requirements, including security.”

According to Kocher, chipmakers and innovators are collectively leveraging open-source to develop better solutions and reduce time-to-market.

“The open source RISC-V architecture is particularly notable for its availability of unencumbered reference implementations and compiler/software support,” he explains. “As a result, RISC-V greatly reduces the amount of ancillary work required for a processor security project, allowing design teams to move more quickly and focus on areas of innovation – including security.”

Some of the largest initial gains, says Kocher, will be realized by adding separate security processors onto chips.

“For example, instead of building a chip with 16 identical performance-optimized cores, a chip designer can integrate 15 fast cores and one security-optimized core,” he elaborates. “The software stack for the secure core(s) can also be independent from the main processor, helping reduce software-related risks as well.”

Multiple roots of trust

Siloed from the primary processor, a security core can enable anti-tamper features that detect fault injection (glitch) attacks which push operating circuits outside their normal operating conditions.  Likewise, secure cores can integrate more aggressive protections against cache attacks, differential power analysis (DPA) and other side channel attacks.

Moreover, a security core can safely host multiple roots of trust, with hardware ensuring isolation of resources, keys and security assets. In real-world terms, this means each entity – such as a chip vendor, OEM or service provider – has access to its own ‘virtual’ security core and performs secure functions without having to ‘trust’ other entities. This allows individual entities to possess unique root and derived keys, as well as access only to specified features and resources such as OTP, debug and control bits. Moreover, support for multiple roots of trust enables the security core to assign or delegate permissions to other entities at any point in the device lifecycle, while isolating (in hardware) unique signed apps that are siloed away from other programs. These multiple roots of trust effectively create a hierarchical and secure execution environment in which mutually distrusting entities are safe to execute on the same CPU.

Interested in learning more about securing silicon with Rambus? You can check out our CryptoManager Security Platform product page here and our CryptoManager Root of Trust white paper here.

• Architectural options for implementing security in electronic devices, from software to hardware, with focus on a range of hardware security approaches
• Selecting the right security IP, navigating regulations and certifications, and implementing it in your product
• Integrating security hardware into a secure supply chain

We begin the tour in two locations in Southern California in late July, then continue to Denver, Orlando, Boston, and then travel across the pond to Herzliya, Israel, and finish up in Yokohama, Japan. Sessions will feature talks from a number of Rambus security experts, as well as guest talks from senior technical staff of Tortuga Logic at specific events. More information on the sessions, including registration information and speaker bios, can be found here.

If we’re not coming to your town, but you still want to hear more? These lunch & learns build on the topics presented in our recent three-part Secure Silicon IP webinar series, available on demand. Additionally, we are presenting and demonstrating our solutions during the ongoing SiFive RISC-V technical symposiums.

Security, as always, was a hot topic at the recent Global Semiconductor Alliance (GSA) Silicon Summit in Santa Clara, CA. As the recognized leader in semiconductor and device security, Rambus played a large part in the summit. As part of our participation, Neeraj Paliwal, VP of Products at Rambus Cryptography, delivered a speech titled “Securing the Infrastructure” during the Smart Connected Industries and Infrastructure portion of the summit.

During the talk, Neeraj explained that for any smart connected device, security must start at the silicon level. Further, it’s not just making sure your chip has some amount of security, but rather that chip and device OEMs need to make sure their chips are designed, manufactured, and deployed in-field with security in mind for the Infrastructure to truly be secure.

Neeraj started with detailing securing silicon at the design phase and that the race for processor speed coupled with the economics of Moore’s Law has led to a situation where modern processors may not meet the security requirements demanded by consumers. The myriad of processor security breaches of late supports this. Rambus advocates a siloed hardware root of trust co-processor approach to chip security. This approach allows the main CPU to do what it does best – run extremely fast and efficiently – while allowing the root of trust to form a trust anchor for secure apps and processes within a system.

However, as Neeraj pointed out, you need to do more than this. In order for a chip to be truly secure, that chip needs to be manufactured with security in mind. To Rambus, this involves the inclusion of robust device provisioning systems into chip manufacturing, regardless of whether that manufacturing is done in captive (trusted) or 3rd party (untrusted) facilities. Automated systems allow each chip to be given a unique and immutable identity that is cryptographically bound to the chip, stored in the root of trust. Without provisioning, it is extremely difficult, if not impossible, to guarantee the identity and provenance of the chip.

Finally, Neeraj spoke of the importance of trusted, in-field cloud services. As he put simply, “If you can’t trust data coming from a device, you can’t trust the device itself.” He explained that by using the information provisioned into the device during manufacturing, the device itself can be authenticated and attested. Having this capability allows the device OEM a whole host of product security features, including functions like secure boot, secure FOTA (firmware over the air updates), and others.

Rambus believes that the most holistic and effective approach to securing our connected devices starts with securing the silicon inside, and building outwards from that trust anchor.

Counterfeit semiconductors are everywhere. Industry estimates are up to 5% of military and medical equipment contain counterfeit parts. The issue isn’t unique to any particular application or geography. In 2017’s “Operation Wafer,” the European-wide Joint Customs Operation (JCO) seized more than one million counterfeit semiconductor devices during a 2-week operation. One million devices – in just two weeks! Industry Week has pegged the fake semiconductor market at $75B, with Havocscope reporting more than $169B in counterfeit parts circulating in the marketplace. The problem is so prevalent that the Global Semiconductor Alliance started a working group on supply chain security.

So…why should fake chips matter to you? Lets talk safety. There is no way to understand how counterfeit parts function. Are they actually doing what the original (authentic) part is supposed to do, or are they operating differently? An even scarier thought, are they intentionally compromising the systems around them? Or are they passing information they gather to an adversary? Confirmed recent incidents of counterfeit parts being found in the field include automated external defibrillators (AED), airport landing lights, intravenous (IV) drip machines, and braking systems for high speed trains. Each of these represent a significant risk to human health and safety.

Device OEMs are forced to address a key question, “if we can’t trust the authenticity of semiconductor components we buy, how can we (and our customer) really trust the devices we make?” Frankly, the answer is “we can’t.”

So how can we fix this? Trust starts at the silicon level, but that trust is only as good as the security applied during manufacturing. That’s where the Rambus CryptoManager Infrastructure becomes a highly valuable tool towards guaranteeing semiconductor authenticity, starting at time of initial manufacturing and stretching all the way to end of life.

During the manufacturing of a chip, whether at an OEM or 3rd-party facility, CryptoManager Infrastructure securely provisions (injects) each and every semiconductor with a unique cryptographic key, or other secure data, in a known-secure area of the chip. Each key is unique to the individual chip and forms the basis of a trusted identity. The process is completely automated. There is no human intervention, allowing the process to take place in just about any facility around the world. Keys are securely generated in air-gapped systems, and only known to the OEM. Once the chip leaves the factory and is placed into a device, the authenticity of that chip can be checked at any time using the Rambus Key Management Service (KMS).

Chip OEMs who use our infrastructure product can provide a chip authenticity guarantee to their device OEM customers, who can then provide the same guarantee to their customers. By cutting down the number of counterfeit chips, we lower the risks to safety and security in electronic devices.

Handschuh is chair of the RISC-V Foundation’s security standing committee and a Fellow at Rambus.

Titled “RISC-V, DARPA Advance Security,” the article cites the fact that companies often don’t build security into their products from the start.  Instead, she noted, they add on cryptographic algorithms and primitives to achieve confidentiality and authenticity properties.  But, Handschuh cautioned, “this add-on approach makes the product a target of possible attacks.”

Her article included the work DARPA is performing with its System Security Integration Through Hardware and Firmware (SSITH) program.  Helena explained the program was created to break the cycle of vulnerability exploitation. She noted that the goal of SSITH is to develop new hardware security architectures and associated design tools. These are the tools she said that provide security against hardware vulnerabilities, which are exploited through software.

She discussed a particular RISC-V Foundation member, Galois, as a company developing tools and techniques for quantitatively measuring and reasoning for system security, particularly for hardware.

Galois is said to be working on developing baseline processors from which security improvements will be measured, port and support baseline operating systems and compilers for those CPUs and develop a demonstration application for secure hardware.

According to her article, DARPA recently announced that Galois will be developing a voting system as the demonstration vehicle for this secure system, built with fully open source hardware and software. As explained in her article, this voting system is intended to serve as an important demonstration of how DARPA technology can be used for a critical infrastructure system.

She explained, “The voting system will be built on open source RISC-V CPUs and will incorporate auditable software components, enabling the public to review both the software and the hardware since the RISC-V ISA is public and standardized.”

According to Handschuh, the purpose of the voting system is to encourage continued research and innovation to develop more secure hardware and software solutions for the benefit of everyone.

In closing out her article, Handschuh said, “the future of security is in the hands of developers. We strongly encourage everyone to get involved and work together to tackle the dynamic security demands of this new era of innovation.”

The past few weeks have been a busy time for white hat hackers demonstrating cyber-security vulnerabilities in connected vehicles. Firstly, Keen Labs researchers published a report that details how to hack a Tesla Model S by remotely controlling the steering wheel with a gamepad.

“When the car is parked, we can take control of the steering system with no limitations; when the car has been switched from R (Reverse) mode to D (Drive) mode by shifting handle, the APE [Autopilot ECU module] seems to think the car is in APC (Automatic Parking Control) mode, which allows us to control the steering system at a speed of around 8 KM/H,” the Keen Labs report explained. “When the car is in the ACC (Adaptive Cruise Control) mode with a high speed, the steering system can be also controlled without limitations. Even when the car is not in the ACC (Adaptive Cruise Control) mode, the steering wheel can also be compromised.”

Separately, a group known as Team Fluoroacetate managed to successfully hack a Tesla Model 3 via its browser during the Pwn2Own 2019 contest in Vancouver, Canada.

AsZDNet reports, Amat Cama and Richard Zhu exploited a JIT bug in the browser renderer process to execute code on the car’s firmware and display a rogue message on its entertainment system. It should be noted that a previous white hat hack in 2015 targeted a Tesla Model S, with security researchers bringing the vehicle to a stop by assuming control of the entertainment system. The 2015 hack also saw security researchers remotely lock and unlock the car, control the radio and touchscreen displays, as well open and close the trunk.

Car alarms as a gateway hack

In addition to the above-mentioned Tesla hacks, a company known as Pen Test Partners confirmed that a number of high-end car alarm systems manufactured by multiple vendors are plagued by a security flaw. According to HackADay, the security flaw affects approximately three million vehicles.

In real-world terms, the flaw allows attackers to exploit the car alarms to locate vehicles in real time, control door locks and start or stop car engines. Moreover, some of the alarms are equipped with microphones, which means an attacker could theoretically eavesdrop on drivers and passengers.

Attacking Autonomous Vehicles

Looking beyond the connected cars of 2019, Skanda Vivek, a postdoctoral researcher in the Peter Yunker lab at the Georgia Institute of Technology, recently concluded that even a small-scale hack, affecting only 10 percent of autonomous vehicles in Manhattan, could cause citywide gridlock and interfere with emergency responders and services. He and his team, including Yunker, graduate student David Yanni and Jesse Silverberg, used agent-based simulations to investigate how hacks could impact traffic flow in New York. They ultimately discovered that by using percolation theory, a mathematical approach based on the statistical analysis of networks, they could quantify how these scenarios would play out in New York City in real time.

“Connected cars are the future. They hold tremendous potential for positive impact economically, environmentally, and, for former drivers no longer frustrated by congested commutes, psychologically,” Vivek stated. “[However], collisions caused by compromised vehicles present physical danger to the vehicle’s occupants and these disturbances would potentially have broad implications for overall traffic flow.”

Perhaps even more disturbing than Vivek’s study is a report published by the University of Michigan that warns of a range of new cybersecurity threats unique to automated vehicles. This includes hackers who might attempt to take control of or shut-down a vehicle, criminals who could try to ransom a vehicle or its passengers and thieves who would direct a self-driving car to relocate itself to the local chop-shop.

The University of Michigan report also warns about security threats to the wide-ranging networks that will ultimately connect with automated vehicles including financial networks (to process tolls and parking payments), roadway sensors, cameras and traffic signals, the electricity grid and personal home networks.

“Without robust, sophisticated, bullet-proof cyber-security for automated vehicles, systems and infrastructure, a viable, mass market for these vehicles simply won’t come into being,” the report concludes.

Automotive security by design

To prevent attacks against vehicles, a report issued by KPMG advises automotive manufacturers to embrace the concept of security by design.

“… Automakers will need to rethink how vehicles are designed and built. Security cannot be an afterthought. Patchwork security of individual technology components is not sufficient to prevent breaches of the open, internet-connected networks behind today’s vehicle fleets,” the report states. “Rather, a secure architecture requires that cyber security be integrated into every step of the development process. Establishing a multi-layered security model, including the cloud, telematics and on-vehicle layers, will be the key to the successful implementation of vehicle cyber security.”

Automotive cyber-security: The Rambus perspective

From our perspective, the concept of automotive security by design is absolutely paramount, as today’s vehicles are essentially a network of networks equipped with a range of embedded communication methods and capabilities. Potential automotive security exploits include intercepting unprotected vehicle-to-vehicle communication, the unauthorized collection of driver or passenger information, seizing control of critical systems such as brakes or accelerators, accessing vehicle data and altering over-the-air (OTA) firmware updates.

This is precisely why manufacturers should work to ensure the security of connected vehicles by embedding a hardware root-of-trust in electronic control units (ECUs), infotainment headend/gateway processors, as well as advanced driver assistance systems (ADAS) and autonomous car chips. Siloed from the primary processor, a hardware root-of-trust can verify OTA updates, as well as offer support for secure boot, authentication and advanced anti-tamper resistance. Additional automotive security features supported and enabled by a hardware root-of-trust can include anti-emulation protection, E2E services, secure key storage and device personalization capabilities.

Interested in learning more about securing connected and autonomous vehicles with Rambus? You can check out our automotive solutions page here.