Automotive HPC Security Challenges and Solutions - Ep 22

Welcome to Cars, Hackers, and Cyber Security. Here we break down the latest in automotive cyber security, helping you stay ahead in building secure, connected vehicles. Today, we're getting into something pretty complex. The electronics inside our cars, they're getting incredibly sophisticated. Oh, absolutely. We're talking a major shift away from, you know, basic engine control. Cars are basically turning into software platforms now run by these central high performance computers. Uh, HPCs, that's the term. Yeah, HPC's. So, our mission today is to understand this evolution and maybe more importantly, what does this all mean for security, especially as cars get more and more defined by their software? It's a huge question. And we'll be using insights from a uh an APC webinar transcript and also a presentation that really focused on securing these systems in nextgen cars. Good sources. Yeah. For a long time, vehicles had this well distributed system, sometimes over a hundred separate little computers, ECUs, electronic control units. Hundred. Wow. Yeah. Easily. Each one doing its own specific job. Yeah. Think uh anti-lock brakes, airbags, you name it. All separate. And they talk to each other over something called the canvas. Okay. So, let's unpack that old way a bit. What was that decentralized approach like? What were its sort of defining features? Well, the traditional way, it was actually pretty robust in certain aspects because things were separate, right? If one little unit failed, it didn't necessarily take down the whole car. Right. Contain failures. Exactly. Now, the communication, the CANbus was pretty limited in speed bandwidth wise, but the physical separation meant attacking the whole system was hard. You'd have to go after each ECU individually. The attack surface for any single one was well smaller. But then things changed. The demands on cars just exploded, didn't they? Suddenly, we needed all this power for ADA's advanced driver assistance systems. Yeah. Adaptive cruise, lane keeping, all that stuff. and high def infotainment cars needing to talk to well everything around them B2X plus just the sheer number of software features automakers wanted to add precisely and that huge increase in demand that's what really pushed the move towards centralizing the computing power we saw this sort of intermediate stage first with domain controllers these acted like hubs integrating things and they worked alongside these new HPCs that were starting to appear and they were connected by much faster networks like automotive Ethernet right Ethernet That's where things really started to shift, wasn't it? Because this new setup allowed for things like overthe-air updates, which is huge. Big danger. And you could do the really complex data crunching needed for better driver assistance and eventually, you know, autonomous driving. Mhm. But I guess the downside is connecting these powerful computers with high-speed links. Well, that opened up a lot more doors for potential attackers, didn't it? A lot more doors. And the trend now where the industry seems to be heading is towards fully centralized HPCs. Basically, one super powerful brain controlling almost everything directly. One brain for the whole car pretty much. So, the big change isn't just more power. It's concentrating it. Yeah. And concentrating the potential points of failure or attack where you had maybe a hundred somewhat isolated targets before, now you might have just one or a few, but they're highly connected and control everything. That's a fundamental shift for security. So, what is an automotive HPC exactly? It sounds like way more than just a beefed up ECU. Oh yeah, way more. We're talking complex system chips, so or powerful multi-core CPUs. Often they'll have dedicated GPUs for the fancy graphics on the dashboard and maybe even specialized AI cores. AI cores for what? For processing all the sensor data in real time, like from cameras and LAR. But critically, these HPCs have to manage what's called mixed criticality workloads. Mixed criticality. Okay, explain that. Right. So imagine your navigation app needs some processing power. Right. Right. But at the same time, The anti-lock braking system needs instantaneous guaranteed responsiveness. Okay. Yeah. Very different priorities. Exactly. They're running on the same computer. The HPC has to absolutely guarantee that the safety critical stuff like breaking always gets the resources it needs no matter what. Even if your Spotify app crashes or worse is trying to cause trouble. And these HPCs rely heavily on automotive Ethernet for that high-speed communication we mentioned. And they share resources like memory and processing accelerators across different functions. Okay, so with all that happening in one box, the software must be incredibly complex. Unbelievably complex. You often need something called a hypervisor. Think of it like a traffic cop for software. It manages multiple different operating systems running simultaneously on the same hardware. Multiple OC's like what? Yeah. So you could easily have AutoSAR running the really critical safety functions. Maybe Q&X for other real-time stuff, Linux for certain things, maybe even Android Automotive for the infotainment system, all coexisting. And then you've got the challenge of integrating all these software pieces from different suppliers, making sure they all play nicely together. And as you can imagine, all this complexity, this mix of systems, well, it brings huge security challenges. So just to recap, we went from a distributed system harder to attack maybe in a wholesale way to a system where critical functions are concentrated in these powerful interconnected HPCs. That's a good summary. And like our sources kept saying, basically more power, more connection equals bigger risk. The potential attack surface just balloons, right? It's not just about someone plugging into the OBD port under the dashboard anymore, is it? No, not at all. The connectivity is the real game changer security-wise. You've got the cellular connections, 4G, now 5G, Wi-Fi hotspots in the car, Bluetooth for your phone, and this vehicle to everything, V2X communication that's coming fast. So many wireless signals going in and out. Every single one is a potential way in for an attacker. And what about less direct ways? You mentioned supply chain issues. use. Yeah, that's a big one. Think about all the software libraries developers use. If just one of those third party libraries tucked inside the HPC software has a vulnerability, well, that could potentially open the door. Mhm. Then there's the risk of manipulating the inputs to the car, faking GPS signals, messing with camera fees or other sensors. Oh, wow. That could directly impact safety systems like ADS, couldn't it? Tricking the car about its surroundings. Exactly. You could potentially make the car break when it shouldn't or steer incorrectly or not see an obstacle that's really there. That's uh that's pretty frightening. Yeah, that is genuinely unsettling for sure. And even systems we think of as non-critical like door locks or the infotainment system, they're targets, too. Maybe to unlock the car for theft, intercept messages, or just cause annoyance, maybe even render the car undrivable. But the really scary one you mentioned, privilege escalation, right? That's a key risk highlighted in the sources, especially for HPC's. escalation. What does that mean in a car context? So, imagine an attacker finds a way into a less critical part of the system. Maybe they hack the infotainment system through a vulnerability in an app, something seemingly harmless. Okay. Privilege escalation is when they manage to use that initial foothold to move sideways or upwards, exploiting other vulnerabilities to eventually gain control over more critical safety related functions like going from controlling the radio to messing with the brakes or steering. That is the nightmare scenario. Our sources mentioned sandboxes, right, as a way to stop that. Yeah, sandboxing is a really important mitigation technique. It's about creating these isolated digital zones like quarantine areas within the HPC. The idea is to keep different software components strictly separated so they can't interfere with each other or access things they shouldn't even if one gets compromised. Building digital walls inside the computer pretty much. Yeah. Okay. So, we've got these powerful central computers lots of connections, potential for attackers to move from non-critical to critical areas. What are the biggest hurdles, the main challenges in actually securing these things? Well, first off, just the sheer complexity we've been talking about, this incredibly intricate mix of hardware and software, often from dozens of different suppliers, all needing to work together securely. That's inherently difficult, right? Then there's this constant tension, this tradeoff between performance and security. Things like strong encryption, memory, protection, constantly monitoring the system for threats. They all consume processing power and memory. So, they could potentially slow the car down or make the interface laggy. They could. Yeah. If not implemented really carefully. You need security obviously, but the user experience has to be good, too. It's a tricky balancing act. I can imagine. What else? Life cycle management is huge. Cars last a long time, right? 10, 15 years, sometimes more. How do you keep that vehicle secure over its entire life? Good point. Threat change over time. Exactly. So, you need robust ways to deliver secure over-the-air updates for years. And you need a long-term plan for finding and fixing vulnerabilities as they emerge. That's a massive commitment. And the supply chain, again, definitely ensuring the integrity of every single chip, every line of code from every supplier that goes into that HBC. That's a major challenge. Seems like a herculean effort. It really is. And then we're back to that mixed criticality problem. Making absolutely sure that the infotainment system can't mess with the braking system, even indirectly when they're sharing the same hardware. And finally, there's cost. Ah, yes, always cost. Yeah, proper security isn't cheap. It often means using more sophisticated, more expensive hardware components like dedicated hardware secure modules or HSM. And it dramatically increases the amount of testing and validation needed, which also costs time and money. Okay, so the challenges are significant, but people are working on solutions. What are the key strategies being used to try and lock down these automotive brains. The overarching philosophy is what's called defense in depth. Basically, you don't rely on just one security measure. You layer multiple defenses. So, if one layer fails, others are still there to hopefully stop or detect an attack. Makes sense. Layered security. Yep. And it starts right at the foundation with hardware and architecture. Security by design is the mantra here. You have to think about security from the very first concept stage. Build it in throughout the entire development process, not just try and bolt it on at the end. Exactly. Trying to add security later is way less effective and much more expensive. Key hardware components here include those hardware security modules, HSM we mentioned, right? The dedicated security chips. Yeah, these are specialized tamperresistant co-processors. They handle things like cryptographic calculations, securely storing secret keys, managing the devices identity. They provide what's called a hardware route of trust. It's a secure anchor for the whole system. Okay. Then you have cure boot. This process makes sure that when the car starts up, only software that is authenticated and trusted by the manufacturer can actually run. It verifies the digital identity right from the moment you turn the key or press the button. Like a digital bouncer checking IDs at the door. Good analogy. Yeah. And trusted execution environments or TE's create these secure isolated pockets within the main processor to run sensitive applications or security functions protecting them even if the main operating system gets compromised. More walls and inside the chip kind of. Yeah. Yeah. Memory protection units, MPUs, and memory management units, MMUS, are hardware features that enforce strict boundaries in memory, preventing one piece of software from messing with another's data. And resource partitioning, often using those hypervisors we talked about, or containerization, is about isolating different software components so they can't interfere. Digital compartmentalization. Okay, that covers the hardware and architecture. What about software and networks? Well, security bug and access control are vital. You need tight control over who can access the diagnostic ports or development interfaces because those can be powerful entry point if not properly secured right the OBD port USB ports exactly then there are intrusion detection and prevention systems IDPS these are becoming more feasible now with the power of HPC's they actively monitor what's happening on the vehicle's internal networks and within the HPC itself looking for suspicious activity or known attack patterns like a burglar alarm for the cars network kind of yeah and Some can even actively block malicious traffic. That's the prevention part. Secure communication is also crucial. Making sure data exchange between ECUs or between the car and the outside world is authenticated and encrypted. Things like MASS seek for Ethernet help protect data moving around inside the car. And OTAA updates, you mentioned needing secure ones. Absolutely critical. The whole overtheair update process has to be locked down tight. You need to guarantee the update file hasn't been tampered with, that it really came from the manufacturer. And you need reliable ways to roll back to the previous version if something goes wrong with the update. Makes sense. What about the processes around security? That's where things like threat analysis and risk assessment or Tara come in. This is a structured way to think about potential threats, analyze the risks they pose, and figure out how to mitigate them. It's a continuous process throughout the vehicle's life. ISO 21434, a major standard, really emphasizes Terra. Okay. Vulnerability management is related. That's the ongoing job of monitoring for newly discovered security flaws maybe in third party software and having a plan to fix them. Network segmentation using firewalls helps isolate critical parts of the car's network from less critical ones. Robust logging and monitoring are essential too. You need to collect detailed logs of what the systems are doing so you can analyze them later if there's an incident. Often feeding this data into a central security operation center or SOC, a security nerve center for the car company. Exactly. And finally, various software techniques are used to create even more isolation between different software domains running on the HPC. It's all about layers and separation. It really is a multi-pronged attack or rather defense. And you mentioned standards and regulations playing a big part now, a huge part. And crucially, in many places, the US, EU, Japan, South Korea, these aren't just recommendations anymore. They're becoming legal requirements to sell cars. Ah, okay. So, they have real teeth now. They do. UN Regulation 155 or UN R155 is a big one. It basically ically mandates that car manufacturers have a certified cyber security management system, a CSMS. They have to prove they have processes for managing cyber risks throughout the vehicle life cycle. Right? And they need the capability to actually detect and respond to cyber threats partly by analyzing data and logs from the vehicles themselves. Then there's ISO 21434 which provides a very detailed framework for how to do automotive, cyber security, engineering, risk assessment, mitigation, validation, the whole process. So compliance isn't optional if you want to sell cars globally. Not anymore. No, it's basically market access requirement now. And these complex HPCs, they really raise the bar for things like the threat analysis and risk assessment required by these standards. You need deep expertise because the systems are so intricate. So implementing these rules and adopting HPCs requires some serious changes for car makers. Definitely big organizational shifts, new skills, significant effort to make sure these minimum security requirements are consistently met across the board. Now the presentation we looked at also talked about modular invehicle security solutions. What's the thinking behind that? The idea there is to have a more integrated and adaptable security system inside the vehicle itself. One that can work across different components and potentially connect back to a central monitoring system for the whole fleet. Okay. So, security sensors in the car. Exactly. Invehicle detection sensors designed to spot security events, suspicious network traffic, weird software behavior in real time as they're happening. Like an immune system for the car. So, detecting and preventing, that's the goal, real-time detection, but also ideally real-time prevention of unauthorized actions if possible. And a key aspect is that these security measures need to be updatable. New threats emerge all the time. So, the rule sets, the configurations, maybe even the detection software itself needs to be updated over the air. Makes sense. Keep the defenses current, right? And when these invehicle systems detect something serious, they need to report it usually to a vehicle security operations center of VSOC. The VSOC like the SOC but specifically for vehicles. Exactly. This allows the manufacturer to see the bigger picture. Are multiple vehicles seeing the same attack? Is there a widespread issue? It helps analyze threats at the fleet level. So breaking down silos between different sensors in the car is important, crucial. You might have a network sensor detecting weird traffic and a host sensor on the HPC detecting odd process behavior. Harmonizing that data, correlating events from different sensors gives you much better chance of spotting sophisticated multi-stage attacks that might cross different boundaries within the car. And the presentation argued for maybe getting everything from one provider, the sensors and the cloud part. Yeah, the potential benefit there is smoother integration and maybe a more streamlined response when things go wrong. A one-stop crop kind of idea. Okay. The source mentioned specific types of modules like host protection. What does that cover? Host protection is all about securing the HPC itself while it's running. It includes things like platform integrity, making sure no unauthorized code is executing. System limiter functions, basically hardening the operating system against attacks, threat detection modules that look for deviations from normal expected behavior. Yeah. And self and data protection to make sure the security software itself can't be easily disabled or tampered with. Pretty comprehensive for the main computer. Yeah. And within that, they mentioned specific host sensor bundles for different operating systems. Linux, Android, QX tuned to detect specific attack types. like denial of service, reconnaissance probes, attempts to exploit known vulnerabilities. Really getting into the weeds of protecting the host OS. Okay, what about these acronyms IDSM and IDSR? Right. So, ISM is intrusion detection system manager. It's basically a standardized component often within the AutoSAR framework that acts as the central hub for intrusion detection inside an ECU or HPC. It collects security events from various sensors, normalizes them so they're in a common format, applies logic to ide if an intrusion is happening, manages alerts and communicates securely. So EDSM is the brain detecting the intrusion. You could say that. Yeah. And ESR is the intrusion detection system reporter. Its job is to provide a standardized way to report the findings. It talks to EDSM, logs the events, forwards alerts to other systems like the VSOC, and allows for customization in how reporting is done. So EDSM detr reports. Got it. Exactly. Ham protection for the networks too. CAN and Ethernet. Yep. For the older key bus, you can have things like specification enforcement checking that messages follow the rules, IDs are correct, data values are in range, and frame timing analysis, looking for messages arriving too fast or too slow. Yeah. Which can indicate an attack. For the faster Ethernet networks inside the car, the focus is on real-time traffic inspection, looking for malicious communication patterns based on rules that can be updated. Some systems can optionally block suspicious traffic. These Ethernet protection functions can sit in gateways, domain controllers, network switches, even inside specific ECUs, often using hardware acceleration to keep up with the speed. And the source claimed these modular solutions offer a quick ROI, return on investment. So, does that work? Well, the argument is that by detecting and stopping attacks quickly in real time, you avoid potentially much larger costs later on, instant response, damage repair, maybe huge data transmission costs if a compromised system starts sending lots of data over the cellular connection, or excessive cloud storage costs for logs. Okay. saving costs downstream, right? And by having smarter detection in the vehicle, you can reduce the number of false positive alerts going to the VSOC, making their monitoring more efficient and saving analysts time. Plus, the fact that the protection is updatable makes it future proof, reducing the risk of needing expensive recalls or major security patches down the line. Makes sense. Lastly, our sources just touched on future trends. What's coming next in HPC security? Well, AI is likely to play a bigger role, probably in more sophisticated anom detection systems, spotting subtle deviations from normal behavior that rule-based systems might miss using AI to fight AI attacks maybe potentially. Yeah. Then there's the looming challenge of quantum computing. Once powerful quantum computers exist, they could break much of today's standard encryption. So, the industry is already working on quantum safe cryptography algorithms. Planning ahead for Qday. Exactly. And we have to assume attackers will keep getting smarter, too. We need to think about new attack vectors like manipulating the AI models used for perception or decision-making in the car or model poisoning where an attacker could subtly corrupt the training data for a machine learning model potentially affecting thousands of vehicles that use that model. Wow. A single attack with massive scale. That's the worry. The landscape is definitely not static. Absolutely. It's clear that securing these automotive HPCs is just fundamentally crucial. It's about safety. It's about privacy. It's about trusting the vehicles we rely on more and more. Couldn't agree more. And it requires this really holistic defense in-depth approach that has to be constantly vigilant covering hardware, software, networks, processes, the whole life cycle. It's a continuous effort. So, it leaves you thinking, doesn't it? As cars get even more complex, even more connected, how is that critical balance between performance and security going to evolve? And what truly novel, maybe even unexpected solutions might we need to invent just to stay one step ahead of the threats that are definitely coming down the road? That's the billion-dollar question, isn't it? It really is. to chew on. If you want to explore this further, definitely check out those standards ISO 21434 and UNR155 and dig into concepts like defense and depth and security by design. Thanks for joining us.