DEF CON 31 - Car Hacking Village - Exploiting Wireless Side Channels in EV Charging - Kohler, Baker

DEF CON 31 - Car Hacking Village - Exploiting Wireless Side Channels in EV Charging - Kohler,  Baker

Show Video

Right. So this is Redeploying the Same  Vulnerabilities. This is a talk about EV   security work that we've been doing for a little  while together, and some of how we're seeing the   same vulnerabilities that have existed for a  long time coming back in modern standards.   This is Sebastian, and I'm Richard. We both  work at Oxford University. We've been doing   vehicle security stuff among other stuff for  about five years now, really focusing on EVs,   and charging security, the security when you  plug it in to charge. That's all we're going   to be talking about today, and then some  talks about where that field is going.  

Right. We've probably all seen something  like this, like a charging park as shown   on this slide. Actually back in December,  2022, this was supposed to be the largest   charging park in Europe, with, I believe, 56  charging outlets, DC fast charging outlets.   But this keeps changing. Every week we  hear about the new largest charging park.   But EV charging is not just for cars. We can  now see electric trucks, like this one here.  

Buses, so public transport, is currently  electrified. This shows a bus depot in Hamburg,   and I don't know if you can see, but there are  wires actually hanging down from the ceiling,   and these are charging cables. So all these  buses you can see here are fully electric.   Another example is this... Sorry.  Another example is this ferry. Going to  

switch to this. Yeah. This ferry, you can see it  charges also with... it's electric, and it has 28   charging cables, so they charge simultaneously  with 28 charging cables. But there's also now a   move in the mining industry, so making mining  greener, so electrifying mining equipment.   And yeah, why did I tell you all this? Well,  all of these examples use actually the same   charging standard, which is known as the combined  charging system, or short, CCS. I don't know,  

most of the people are probably familiar with the  left one, which is the combined charging system   plug type one, which is used in the US, and on  the right is the one that is used in Europe.   It's exactly the same technology, underlying  technology, it's just a different plug type.   Of course, there are much more charging  standards, as we can see on this overview   here. But in this talk, we are going to focus on  DC charging using the combined charging system.   So why is CCS so interesting for us? Well CCS  is actually using a power line communication.   So the car and the charger are communicating  during a charging session all the time. So the  

car is telling the charger, "Hey, this is how much  electricity I need. This is the maximum current,   the maximum voltage. This is my state of  charge," and the charger actually confirms   these messages, and also, yeah, exchanges  information about the charging session.  

There is more communication actually going on. For  example, with Plug and Charge, you can actually   plug in your car and leave without tapping a  card or using an app. It will automatically   send your credentials to the charger, and the  charging session will be authenticated.   So yeah, it's quite a detailed charging standard.  There's a range of open standards that underpin   it, and this is why it was quite interesting  to us. It was also getting deployed very,  

very widely even when we first started working  on this. That's a lot of infrastructure that's   being built, going to be expensive, going to  be hard to change. So keen to get in early.   And even then and ever since, we've been finding  insecurities and a lot of charging infrastructure,   and that made us concerned about the  kind of things we were deploying.   So particularly for CCS, we were interested  in this power line communication, because it   comes from a system called HomePlug, which  was originally these little plugin adapters   you'd use at home for wifi extension, and there  were some issues known about these in the past,   and particularly, they were built for a  different threat model--in-home, shared keys,   not a kind of open public access network.  Also, they were known decades ago, frankly,   to be able to leak their signal radiatively out  of cables. This wasn't necessarily too much of  

a problem at home, but it's interesting when  you see this deployed in a different setting.   And of course, it's part of deploying CCS, and the  new world of connected charging was that there are   lots more services. There's not just talking car  to charger, but also out to systems behind the   scenes providing additional services--automated  billing, reactive charging, load balancing, all of   these things that depend on having a nice secure  link. So it was kind of quite interesting to us.   We'll talk about a couple of bits of work  here. We started with just a purely passive   threat model. So what is it that someone just  eavesdropping might want to do? Well, as ever,  

lift some fingerprints and have some privately  identifiable information, of course. And then also   we thought maybe there'd be some opportunity for  billing fraud here. So there is a system called   auto charge, which a couple of networks implement,  which just uses identifies that are pretty much   public. If someone could lift these then they  could use them to start to pretend to be people.   And threat model's fairly simple. It's a kind  of motivated hobbyist. Not a lot of information,   [inaudible 00:05:50] deep technical knowledge  to fully build systems from scratch, but   someone that can run some code and has access to  off-the-shelf hardware. Not much more than that.  

So for a particular attack, like one example,  we had a look at signal level attenuation   characterization. SLAC. It's a SLAC attack.  This is a system that, in my opinion, probably   shouldn't have existed in the first place. This is  part of the initialization routine of a charging   session, where the car and the charger need to  make sure that even though they're connected with   a big cable, they're actually talking to the right  charger. Because there's so much potential for   crosstalk, conductive or radiative, that you could  just be talking to the charger next door, like   two, three meters away. That seems a little  bit... a bad smell in designing the system.  

Also, there's a big long protocol here.  I mean you initiate the SLAC session,   you test the attenuation, and all  the charges that can hear respond,   and then you pick the one that has the lowest  attenuation. So that's probably the one you're   talking to. In step six and seven, you say, "Oh  okay, I've picked you. You are the charger for me.   Can I join?" And he goes, "Yeah,  sure. The shared key is this." And   that's just in the clear. Unless you've got the  security mode turned on, which we've never seen  

happen, this is just given to the car. And  so anyone that can lift that has a key for   the network. There's some authentication later,  but once you've got the master key, you're in.   So can we do this in the world?   Well, we set up an experiment. So we got a car,  we ran around some charging stations, and then   we just set up software-defined radio. We've done  this with different equipment setups over time.   And just put the antenna at various points in the  car, around, nearby. A bit of an exploratory thing   to just see what kind of signal we could collect  and whether we could use that for something.  

We did quite a sort of long evaluation, 800 miles  of driving, there were three cars at the time.   Every now and then, we pick up an electric  car rental and we tested a bit further,   but even then ,14 locations,  six networks, enough to have a   good overview of what was happening in the  industry, all in the UK where we're from,   but all kinds of places. Service stations,  hotels, wherever we could find a CCS charger.   To put it into a bit of perspective, so  these are places where we're pacing the SDR,   the antennas. Some of it was super,  super close range. You're inside the car,   we're interested in whether this  signal is leaking out from the cable,   whether it's leaking out from the  car, which part of the electronics.   Some of it was further away. You'll notice it's  even sunny in England sometimes, as this picture   shows. Here we've got someone just behind the  car, in a bay behind, probably five meters away,  

and you are not going to suspect someone there  for picking up your signal. And the other one   on the right, it's about four meters away next  bay. But this is a reasonable short distance.   And even some with two vehicles. So this is when  we had the I-PACE and the Gulf at the same time,  

and we just went to, at this point, one  of the bigger charging parks we could get   to. Of course, now that's changed and you  have easily 50. But here, two was enough,   and just one radio share between and  multiple sessions being picked up.   The end result was we picked up a signal basically  everywhere we went. You could certainly see on a   frequency plot, so these plots in the top  right, they're all spectrums. You can see   this distinctive frequency usage that you get  with HomePlug. You notice these deep notches,  

they're in there to not interfere with amateur  bands. The fact that you've got this little   visual fingerprint kind of already tells you that  you are picking up the signal. The other thing to   say is it vastly varied between location, between  site, between charger hardware, how much of this   signal came through, and how much noise. You've  got all of these noise spikes around, you've got   a lot of high-power electrical devices working  there to provide the charging. So you get a lot   of noise when the charging starts. But point is  we could pick up the signal everywhere we went.   And then we built a receiver. So this is open  source, this is entirely software receiver. It  

takes a file in of just the raw signal and then  it processes it and pulls out the packets it   can find. This is pretty much just doing what a  normal modem would do, but it's open instead of   in a proprietary IC. It detects the packet, it  synchronizes on them, it does all the OFDM, and   then at the end, spits out everything it possibly  can. So messages, keys, messages that failed to  

decode, but you might be able to get some data out  of all of these, dumps them into a big database.   As I say, it's available. If it's useful to  community, please use it, please build on it.   This is a big table of numbers. You don't  really need to read or pause it very much.   The important things are probably left-hand  column. Lots and lots of messages, thousands,   big variation. Some sites very bad, some  sites much better, but lots of messages.   Column on the right, these are messages  that fully validated their CRCs, and so   these are ones that are good. So these are both  metrics of how well we were able to pick it up.  

For two examples there next to the cable,  beautiful clean signal, very easy, and is   nearly a hundred percent of the messages that are  valid. They're all modulated slightly differently   depending on which bit of the protocol they're  in. Some of them are easy to pick up than others,   but overall, you can pick up enough to have a  whole session. And a bit further away, of course  

the performance falls down. We're still picking  up some, the bay next door or the bay behind,   and I think with more equipment optimization,  this was just stuff we had in the lab,   you could increase this number further. And then   from that, we ran our bit of code.  It took a long time to perfect,  

but then out of individual messages  we just dumped out values.   What we're seeing here are messages we received  from the end of this SLAC protocol. So you can   see in this key column which messages it's  coming out of and which value we are getting.   Two are interesting here. One, for this  privacy and fingerprints or identifiers issue,   there's a vehicle MAC. We ended up getting  the same cars multiple times over a period   of months. These didn't change. I mean the  MAC addresses, you could rotate them fine,  

but they weren't being rotated. Some  manufacturers and some batches of cars   did not have vehicle unique identifiers,  and we see this happening in auto charge,   actually. Some vehicles are not compatible  because some of the MACs are zeroes.   The majority that we saw did have completely  unique MACs. You can identify that car forever   from that, and you can pick it up later sessions  as normal. Then there's also, of course, the key.   This arrives a few seconds into starting a  session, and you pick it up. I mean that's   the key in plain text there. You also get it  in Wireshark, and then from then on the code  

automatically starts to decrypt the rest  of the session, once it's got that key.   We are also outputting traffic to Wireshark.  It's a little bit of a messy capture here,   but you can kind of see the process evolving.  So at the top, there's this request to get the   master key, that's the stages six and seven  I was talking about before, getting it back,   and then trying to find the controller  that's actually going to initiate the charge.  

Keen observers on the blue lines, it talks support  15118, that's the ISO number of the standard,   that was a kind of fun little Easter  egg, and then it sets up a tunnel and   then sets up higher communication where there's  a whole stack of things. It's IP communication,   then there's TCP on top, then maybe there's crypto  on top of that, and then there's just sending XML   back and forth for state of charge for charging  speed, temperature, and all these other things.   That's also up where you would have automated  billing and stuff, per the standard.   All of those would require you to have a TLS  session. So I'm not saying that there is traffic   for that that we've ever seen unencrypted or  accessible from here. You're only getting the  

lower layers. There's also a lot of support  though for external additional services to be   built on. This is ultimately an IP link, right?  With two Linux boxes either end, you could put   any services you want. You can open additional  ports, you could have a web interface, and so on.   There's some talk about that, although we haven't  seen it much in the wild being deployed. But  

any of that, you're then back into whether the  developer secures that as well as they should.   For the simplest standard, DIN 70121, this is  just charging. There's no security on top of that,   but there's also only so much you can  learn. You can get the identifier out,   you can listen traffic, but there's not  too much important stuff going over it.   There has been laterally some talk about different  approaches to try and secure this. Some people,   one particularly big manufacturer's talking  about just establishing AVPN on top,   which maybe goes back to your own charging  provider. I mean, that or TLS is providing you  

some crypto either way. I think the big problem  is doing the PKI to support this and having the   right keys for the charger, for the car, for the  driver, for everyone involved. Still ongoing.   Right. So as Richard just told us, he  basically found that there is a unique   high quality unintentional wireless channel when  you use PLC charging, or when you use CCS that   uses PLC. The main question we asked ourselves  was can we actually also inject? Because the  

charging cable is a perfect antenna, right?  We can receive, it emits the signal. So can   we also inject into the antenna? We looked at  what can someone do, like a threat model about   active attacks. How can you actually interact with  this communication and what can you do? Since CCS,   or in general, electric vehicles, are becoming  part of critical infrastructure, so they will be   acting as battery buffers for renewable energies.  We will have vehicle-to-grid communication and   feed electricity back into the grid. It's  kind of important that they are available.   So we need this communication otherwise  we will not be able to use these services.   We looked at can we disrupt an individual vehicle?  This actually is probably the weakest motivation,   but we just had it yesterday actually when we  drove here from LA. We wanted to charge our car,  

and all of the chargers were occupied.  Could you interrupt actually one of   the chargers and get the cable? No one  would notice, right? Most of the cars,   I don't know if you're aware of that, but most  of the cars actually unlock the charging cable   if the charging has stopped or is interrupted. We  assume it's a safety feature. But yeah, most of   the cars we tested, actually all of the cars,  I believe, implemented this feature. So yeah,   you could just disrupt a single vehicle, get  the charging cable, charge yours, and be happy.  

But of course there could be another motivation, a  financial motivation, for example. Back in Oxford   in the UK, DPD has fully electric fleet now,  I believe 40 to 50 vehicles fully electric.   So if you can just knock out their entire fleet  so they can't charge let's say during the night,   you could just blackmail them. They will turn  up in the morning and the cars are not charged.   Another motivation could be unspecific  disruption. You try to disrupt as many   cars as possible or as many charging  parks as possible to for example,   disrupt supply chain. We saw earlier buses are  getting electrified, ferries and trucks. If you  

just cause widespread disruption, that's going  to be an issue, especially if we then go a few   years further and look at vehicle-to-grid  communication and bi-directional charging.   Oh yeah, I should mention maybe for this threat  model, for these goals, we assume exactly the   same capabilities. Just access to software-defined  radio or a transmitter off the shelf you can get   from Amazon, and a little bit of knowledge about  digital signal processing. We found Brokenwire,   and Brokenwire exploits the CSMA/CA  mechanism used by HomePlug Green Phy.   How did we actually find this? Well again, we had  this, there is an unintentional wireless channel.  

Can we inject? And then we looked at the standard,  actually, and we found this interesting phrase,   and this phrase basically says that the modem  should consider someone else communicating if   they receive a preamble with two dB above noise.  What this means is basically the receiver or the   transmitter would actually stop transmitting when  someone else is already transmitting to make sure   there is no interference happening. For some  of you who might not be familiar with CSMA/CA,   here's just a diagram how this usually works. Let's assume you have a car and a charger,   and they don't have or wouldn't have CSMA/CA,  the car would send a message, charger replies,   all are happy, but if they send at the same time,  you would have interference. So instead, actually  

the HomePlug Green Phy modem checks.  If the channel is clear to send,   and if it is clear to send, it would send a  message and so on, and if it is actually not   clear to send, and you can see it here, it waits  for a random period of time. So it backs off and   then tries again and checks is the channel now  clear. And if it is, it sends the message.  

On the previous slide I just showed you, the  standard says someone is communicating or the   channel is busy if we see a preamble two dB above  noise. And so what someone could do, actually,   if we now have an attacker, someone could  just, during a communication which is happening   just fine, start sending a signal to make the  channel look busy. So in our case actually,   that is the preamble. So here you can see a  HomePlug Green Phy frame we collected by just   plugging a modem into a software defined radio.  So this is in the time domain, and the first bit  

you can see is the preamble. That is used to  detect if someone is communicating and also do   frequency offset correction and timing. Then you have the frame control and the   legacy frame control and the AV frame control,  and then you have the payload. As I said, this  

was collected while plugging the modem actually  into our receiver, and there is also some noise,   of course. You might have already spotted it,  but there's also another preamble in there.   This is a preamble which is two dB above noise.  This preamble actually already caused the modems   to back off, because they consider this as "Oh,  someone is communicating. I need to stop, I need  

to wait until this communication has ended." When we found this vulnerability, we initially   tested it in our lab. We got these development  boards. These boards have exactly the same   Qualcomm chip as you can find it in charging  stations. It's a QCA 7000. And yeah, as I said,   it's exactly the same chip. We connected one to  Raspberry Pi, and this was our electric vehicle,   and then the other one which was our  charging station. So the Raspberry Pi  

was actually just providing some traffic so  we can measure packet loss and the quality or   examine the quality of the channel, basically. We connected them with a charging cable, and   then we had an attacker, which you can see in the  lower part. We used just a super simple antenna.   It's a very low frequency. So PLCs communicating  at around 2 to 28 megahertz in this band. So we  

set a center frequency to 17 megahertz. We have a  pretty high or large wavelengths, so our antenna   was actually just a bunch of wires, and I have  a photo later where you can see it. We connected   this to a small amplifier and the LimeSDR. This setup cost you maybe... Now the LimeSDR   actually got quite expensive, but it was maybe  250, 300 dollars, before the chip prices, yeah.   We did some experiments in our lab, like in the  university. You can see the HomePlug Green Phy   modems in the back. Our attacker set up in the  front, and this was roughly, I don't know, maybe  

eight, nine meters, and we successfully disrupted  it. So we plotted some graphs. We basically tested   for a given distance how much power do we  need to disrupt this charging communication,   just a HomePlug Green Phy communication. As you  can see, so it's plotted in DBM and milliwatts.   On the left, DBM, you can see that  for distance of 10 meters, we actually   were able to disrupt this communication  with less than 10 DBM or 10 milliwatts.   Your wifi router is probably transmitting at  around a hundred milliwatts. Just to give you   an idea, this is very, very low output power, and  this was from 10 meters away. So we also wanted  

to test, can we actually disrupt between floors  just for the sake of it? And yeah, we were able   to do it. So you can see, on the first floor,  we put the modems there. We didn't even stretch   out the charging cable, so it was like a bunch  of wires or just like a pile of wires. Then we   were the floor below, and we had the antenna lined  up and just transmitted. I can't remember exactly   how much power we had for this experiment, but it  was on the order of 70 to a hundred milliwatts.  

Of course we were curious. Actually, we only  tested this so far in the lab. Can we actually   target stations out in the wild? Can we test this  on real cars? So we got all of our equipment into   the boot of a car. Here actually you can see  in our antenna, which is just a bunch of wires   I mentioned, amplifier, LimeSDR, bench power  supply, which we powered with a UPS. But we   changed the setup, so now we actually just use  a power bank with the step up converter, because   we need 12 volts for the amplifier. So you can  easily fit this in your backpack, for example.   We tested different scenarios. For example, can  I just attach the antenna to the side of the car   or just in the boot and then drive or pass by a  charger? Can we do a scenario where I'm behind   some bushes and disrupt the charging? I  would say scenario two, three, and four   are commonly seen at supermarkets, for example.  Then we did another one which was just focusing  

on distance. So we wanted to see how far can we  actually go, given our power budget of one watt,   which was limited by government regulations.  So we couldn't transmit higher than one watt.   I also want to say we don't reveal which cars we  tested and which chargers, just because we want   to stress it's a standards issue. It's not an  individual car manufacturer who implemented it   wrong. They followed the standard and the standard  like HomePlug Green Phy is just vulnerable.   So these were the cars we tested. This overview  just shows you it's not just cheap cars, it goes  

up to $150,000 cars. So it was actually quite  sad. We had to drive all these cars for quite   a while and then run down the batteries,  charge them again, run down the battery.   So it was quite fun driving the shooting brake.  As you can see, all of them are vulnerable. It  

also doesn't matter what the charging capacity  is. So of course if you charge with a higher   capacity, you might have more noise, but  didn't really matter, it still worked.   We did the distance experiment.  Again, one watt of amplification,  

so roughly one watt, it was just below, and we  were able to disrupt it from around 50 meters.   What can we do to prevent this? To prevent leaking  the signal or actually having the antenna or the   charging cable acting as an antenna, of course  shielding would be the way to go. But actually   shielding doesn't work here very well because the  cable is already quite stiff and heavy. Adding   shielding might reduce the vulnerability  or susceptibility to EMI, but actually in   the end you just increase the power. Since we're  talking about super low transmission power here,   you can buy a 10 watt, 70 watt or  600 watt amplifier in this band and   you would still be good and then you would need  to add more shielding, so it's an arms race.  

Another idea would be upgrade the firmware of  the Qualcomm chip, and if anyone from Qualcomm   is here by any chance, we would be happy to chat  about this, because it would be quite interesting   to know if actually the preamble detection and  the two dB, if this is a threshold which is set   in firmware or if it's a hardware limitation. Then, finally, one thing we noticed, once you   disrupt the charging session, it stays disrupted.  So you would need to walk there, unplug the cable,   plug it in again, tap your card or activate  via the app, or if you have Plug and Charge, I   guess it would do it automatically, but you would  need to re-authenticate, which is a pain because   if you have a... like the DBD fleet I mentioned  earlier, you'd need to go there, disrupt it,   it takes 20 seconds, and then you leave and  it will be disrupted for the whole night. It   automatically doesn't reauthenticate  or recontinue the charging session.  

So we said "Redeploying the Same Vulnerabilities."  Why was this the title of our talk? Well, what is   next? That's the big question. Currently, there  is work going on on the megawatt charging system,   MCS, and interestingly, so it has almost four  megawatt of charging capacity, but interestingly,   it also uses power line communication again.  It uses differential PLC, which should be   not as easy to disrupt, but we haven't tested  it yet, because it's not widely... or it's not  

deployed yet. Just for your information, this is  like the plug. Compared to CCS, it looks quite   similar, but you now have a communication  interface in the middle for twisted pair.   The differential signaling should significantly  improve the EMC compatibility of the PLC   communication. But yeah, as I said, we haven't  tested this yet. And using unshielded twisted pair   UDP wire should also help to increase  noise immunity, roughly 40 dB higher   as CharIN saying on their website. So CharIN  is the standardization body of CCS and MCS.  

But I would like to highlight here that even  if you shield the cable, you use differential   PLC and you use twisted pair, the signal  could just couple into some other bits,   like onto the PCP directly, so you could modulate  your signal into a higher carrier, high frequency   carrier. If you just make the wire not attackable,  it doesn't mean the system is not attackable.   And now there is also the North American  charging standard. I guess you all know it's   the Tesla plug, and they say basically that for  DC charging, the electric vehicles should or NACS   should support power line communication  to make it compatible with DIN 70121,   and it should also support ISO-15118, which  means if it needs to support ISO-15118,   it needs to support PLC communication. So what is the conclusion? Well, CCS is   vulnerable to wireless attacks. We show that  we can eavesdrop on it, but we can also inject.  

Roughly 20 million vehicles are currently  vulnerable because CCS is mainly used or is the   DC charging standard in Europe. It's also widely  used in the US and in some parts of Asia, and we   just think PLC is just not a good technology  to use in such a critical communication.   So I just have a video for you. Just ignore the  Renault Zoe on the left. As I said, I didn't want  

to reveal which car we tested on, but yeah. So the  car was charging as you could see, and we put the   equipment, as you saw in one of the photos, in the  back of the car, and then as soon as we pass by,   you will see that the charging stopped.   This is the error where you need to go,  unplug it, plug it in again. It doesn't   go away automatically. Right. That's it. If you  have any questions, feel free to reach out to   us on We have more information.  There is also the paper available, and there is  

also some information on NIST for the CVE we got.  But yeah, happy to take any questions. Thank you.   Oh yeah, sorry. There is a microphone  right here if you have any questions.   Hi. Hi.   Just a question. Were you able to also...  You mentioned about the billing. There is  

a communication between vehicle and the charging  station, and there is a billing associated with   it. Were you also able to get into the billing,  like able to manipulate the user to charge?   Sorry. If I understood you correctly, you're  asking about the identifier which is transmitted   between the car and the charger? Yeah.   There are different implementations, I would  say. There is one which is called auto charge,  

which is basically the MAC address  of your EV charging controller.   If you have the MAC address, you can... If  I eavesdrop on your communication and get   your MAC address, and spoof my MAC address, I  could charge and you would be paying for it.   Okay. So, basically we can sniff MAC a address  from the car between the charger during it's   session, and then we can use this to bill for  that user that we sniff. Is that correct?  

Sorry, could you speak up a  bit? It's hard to hear.   Yeah, so the car connects to the charging  station. During the initial session,   we sniffed the MAC address. And then,  can we replay that to charge the user?   Right. If we can replay. Sorry, do we want to?  

Sorry. Yes. Yeah, you captured that MAC address,   you set your MAC address, that's associated  with someone's billing account, and then you   just go and charge until they cancel it because  they realize they're being charged. It's not the   same for Plug and Charge, and this is the gold  standard thing. Auto charge was just a couple   of industry players wanting to get in on this kind  of frictionless experience early. Plug and Charge,   no, there's certificates both sides. There's, as  far as we know, good crypto. It's not very widely  

deployed yet. But yeah, that's safe. Thanks a lot.   Dumb question. Will the slide deck  be available on the GitHub site?   This slide deck? That slide deck.   It could be, yes. It's not currently, but it  could be. There's certainly slides from other  

talks we've done on it. This one has  a little bit of extra on it. But yeah,   that paper code, you can get. Some appropriate slide deck. I know   some folks where the slide deck  would be great for explaining.  

Yeah, of course. I think you'll  find all the resources-   [inaudible 00:35:48]. No worries.   One question, please. The MAC address that you  identified, this is the MAC address of the vehicle  

or the charging system of the vehicle? There are two, and you get both of them in   different messages. So you get- Are you sure it's the same one.   So there's a modem one, and then there's one  for the... What is it, the charge controller.   We've observed different behavior in different  vehicles. Some of them have one bit different,  

some have the same MAC address in both. Some  have one of them blanks and one of them not.   It depends on which one you're looking at. Because it's totally different TCUs. The MAC   address usually will be part of the TCU,  and not part of the charging system.   I'm sorry, I missed that bit. The MAC address- The MAC address will come from the TCU.   From the controller on the EVCC? Yes. Not from the charging system.   But we have one from the modem, and one from that,  from the EVCC. I could show you in some captures,  

and it does, as I say, vary between, but yeah,  they establish a communication between the two   high-level entities, and then the very early  initialization messages are modem to modem. So   we have ones for those as well. Okay, thanks.   Hi. Thank you. You were talking about NACS and  similar vulnerabilities. Seeing as NACS is coming  

up, well CharIN is trying to standardize  it now, is this an opportunity to kind of   address some of the vulnerabilities  with some of your suggestions?   Yes, would be our opinion. Some things  are very difficult to change. You've got   a standard that has this communication, which  is possibly not the best choice baked into it.   That's probably going to be difficult to do. Some  changes are coming that are really good, like   MCS having this differential PLC, or changes that  you could deploy later, like firmware differences   or additional sort of detection systems for  just constant preamble something. But yeah,  

as a general rule, yes, let's try to fix  this, and hence why we're doing this talk now.   We'd be happy to engage with anyone that's  doing work on any new charging standards.   Thank you. Sorry, if you want me to...  

The question I have is the SDR you guys  use to do this attack is kind of unique,   because to do this you need something that  has at least 28 megahertz of RF bandwidth.   I'm sorry, I'm having difficulty hearing you.  Probably just close to the mic is fine.   Okay. So the SDR you guys used to do this is  somewhat unique, and the fact because you need   about 28 megahertz of RF bandwidth in order to do  this attack. So things like a HackRF won't work,   because they've only got 20 megahertz. Now the new  LimeSDRs don't have this nice wide band that the   original one did, and hence that's why the price  of these have gone up. But I'm kind of curious,  

have you guys found anything other  than a high-end USRP that will do this,   has a required RF bandwidth, because  I had love to hear about that?   Yeah. We played with a couple of different  ones. I mean I think prices went up a little   bit across the board. [inaudible 00:39:14].   At the time, the big LimeSDR was  what, a couple of hundred dollars,   and that was really good. That was why we had  it. And it also worked natively in that band.   The previous work, the eavesdropping, I was using  a Blade RF, which was reasonably inexpensive at   the time, but it didn't tune to that band, so  we had an up converter to bring it up to there.   And basically we've had pretty good success  with those. I'm not quite sure exactly what's   going to be the best buy at the moment,  but my gut feeling is probably still a   LimeSDR. They've got more expensive, but  they're still not quite USLP territory.  

The current Lime, are you talking about the  old version and trying to get it off eBay?   Frankly, either. A V2 should work fine. We  haven't tested the V2 ourselves, but...   The V2 two does have the required bandwidth? Yes.   And it'll tune down the 2 to 22  [inaudible 00:40:13] megahertz?   Yes. Yeah. Depending on what attack you want  to do, whether you could just do up conversion,   down conversion, use something else,  that might be quite a good route.  

I mean if you wanted a recommendation for what to  buy, we could perhaps have a little offline chat,   but most of the things that are above an RTL  or something should work fine. I will also say,   you might have some success even  with the 20 megahertz from a HackRF,   for two reasons. One, we did test  Brokenwire with less of the preamble,   because some of this will get attenuated  anyway, and I can't remember how low we went,   but you could cut off a surprising amount and  still have the preambles register as accurate.   Although the preambles don't  use all the OFDM channels?   They do, but even if some of it is horribly  attenuated, there's enough signal for it to   correlate well and trigger as a preamble. Oh, sweet.   In theory, you should be able to even do some  eavesdropping because Green Phy replicates   all across the band. So there's five copies or  sometimes seven copies depending on which message  

you're talking about for exactly the same problem.  It's a very, very hostile network if you're...   hostile transmission environment on these wires.  So it's built to be robust against that and you   could lose a whole chunk of the subcarriers  and still recover messages. Of course, your   mileage may vary, but you might have some success  with the HackRF, if not, probably swapping for a   LimeSDR or the BladeRF and up converter. Very interesting. Thank you. I didn't know   that about... I thought I was using  all the [inaudible 00:41:39].  

Yeah, of course. It tries to, but it's  surprisingly resistant to loss or noise   or whatever. Okay.   Happy to talk more afterwards. Yeah. Okay. Okay, Cool.   Hi. I'm not really knowledgeable about the  protocol, but has Qualcomm implemented something   like a spread spectrum or something that can  mitigate the radiations? I mean whenever we do EMC   testing, we basically look for, if we have this  type of radiations, we reduce the speed, reduce   the slow rates, or also doing some spread spectrum  on the transceivers to mitigate the radiations.   Has this been already placed on the table? No. It's not FDM system, and there's certainly  

per-carrier control to stay under EMC limits.  So part of it was of course that distinctive   spectrum template that I showed, notching out the  amateur bands, and you could power control there   or notch more of them out if you needed to. And  for EMC purposes, fine. It is just under the   threshold for radiation. I think, realistically,  it's just if you turn up your LNA enough, you can   still pick it up, but it's still compliant.  And then there's plenty above that in terms   of varying modulation to try to get the best  rates and so on. But that's less of a compliance  

thing and more of a throughput issue. Okay. So only through differential wires   canceling the fields and that will be enough  for the mitigation on the second version?   Some implementations of this are a wire, at which  point it's just going to be leaking out all over   the place. The differential down a twisted pair,  yeah, that's probably going to be very helpful.   But bear in mind, this is a technology  that's coming from an in-home environment   and genuinely people's power wiring, which  is just wires randomly laid over 50 years   by different electricians and so on. It wasn't  really built as a communication protocol for a  

purpose-built environment, but rather making  the best use it could of the conditions it   had. And that's why it's not ideal there. And is the amount of information that you do   during the handshake really  needs the amount of speed,   or why not use lean or [inaudible 00:44:03]? Yeah. All the other charging standards do not.   I typically use a CAN bus link, and do fine. I  think a lot of it was a future-proofing idea,   and there was some really nice design  choices. Have an IP link, you can just do   whatever. You can deploy the same technology  you have, there's no reinventing the wheel.  

Personally, I'm not sure PLC was the best  underpinning for that, but no, it's hard to make   a case. It was more to just create the capability  to deploy whatever we might need in the future,   rather than because you needed that much data. Okay. Well, thanks.   Thanks very much. And thanks  everyone for coming.

2023-09-22 07:03

Show Video

Other news