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.
So 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 into charge. And that's all
we're going to be talking about today, and then some thoughts about where that field
is going.
Right. So 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, so 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. I'm 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. So I don't know, most of the
people are probably familiar with the left one, which is the combined charging system
plug type 1, which is used in the U.S., 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.
So 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, and 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 in 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 plug-in
adapters you'd use at home for Wi-Fi 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, and 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, part of deploying CCS and the new world of connected charging
was that there were lots more services. There's not just talking car to charger, but also
out to systems behind the scenes, providing additional services, you know, automated billing,
reactive charging, load balancing, all of these things that depend on having a nice
secure link. And so it was kind of quite interesting to us. So 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 AutoCharge, which
a couple of networks implement, which just uses identifiers 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,
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. And 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, conducted 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
a system. Also, there's a big long protocol here. I mean, you initiate the SLAC session,
you test the attenuation, and all the chargers 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're 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 this 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 to 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 wild? 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. And 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 test it 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, you know, service stations, hotels, wherever we could find a
CCS charger. And to put it into a bit of perspective, so these are places where we're placing the
SDR antennas. Some of it was super, super close range. You're inside the car, we're
interested in whether the 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, you know, probably five metres away. And you're
not going to suspect someone there for picking up your signal. And the other one on the right,
it's about four metres away, next bay. But this is, you know, a reasonable short distance.
And even some with two vehicles. So this is when we had the I-PACE and the Golf at the
same time, and we just went to, you know, at this point, you know, 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 shared between in multiple sessions being
picked up. And so the end result was we picked up a signal basically every hour we were in.
You could certainly see on like 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.
So 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're picking up the signal. The other thing to say is it vastly varies between location,
between site, between charger hardware, how much of the signal came through, and how much
noise. You've got all of these noise spikes around. You've got a lot of, you know, high
power electrical, um, 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, 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. Um, and this is pretty much just doing what a normal
modem would do, but it's open instead of in a, a proprietary IC. Um, so it, it detects
the packets, it synchronizes on them, it does all the OFDM, and then at the end, spits out
everything it possibly can. So messages, keys, uh, messages that fail to decode, but you
might be able to get some data out of all of these, dumps them into a big database.
Um, and as I say, it's available. If it's useful to community, please use it. Please
build on it. So, I mean, this is a big table of numbers, you don't really need to read or
parse it very much. The important things are probably left-hand column, lots and lots of
messages, you know, thousands, big variation, some sites very bad, some sites much better,
but lots of messages. Uh, column on the right, these are messages that fully validated their
CRCs, and so these are ones that are good. So the, these are both metrics of how, how well
we were able to pick it up. So, for two examples there, you know, next to the cable,
beautiful clean signal, very easy, um, and is nearly 100% of the messages that are valid.
And they're all modulated slightly differently depending on which, which bit of the protocol
they're in. So, some of them are easier to pick up than others, but overall, you can pick up
enough to have, uh, a whole session. And a bit further away, of course, the performance
falls down. We're still picking up some, you know, 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, you know, increase this number further. And then, from that, we had, uh, we, we ran our
bit of code, it took a long time to perfect, um, but then out of individual messages,
we just dumped out values. And so, what we're seeing here are messages we received from the
end of this Slack, um, protocol. So, in the, you can see in this sort of key column,
which messages it's coming out of and which value we're, we're getting. And 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,
the Mac addresses, you could rotate them fine, um, 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 zeroed. 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.
Um, then there's also, of course, the key. Um, this arrives a few seconds into starting a session,
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're 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, you know, there's this request to get the master key, that's the stages 6 and 7
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 tunnel, and then sets up higher communication where there's a whole stack
of things. There'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 can have a web interface,
and so on. And 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 to traffic, but there's not too much important stuff going over it.
There has been latterly some talk about different approaches to try and secure this.
Some people, one particularly big manufacturer is talking about just establishing a VPN 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 everyone, 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.
So the main question we asked ourselves was, can we actually also inject? Because the charging
cable is the perfect antenna, right? We can receive, it emits the signal, so can we also
inject into the antenna? So we looked at what can someone do, like a threat model about active
attack. So how can you actually interact with this communication and what can you do? So 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. So we looked at, can we
disrupt an individual vehicle? So 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. So could you interrupt actually one of the chargers and get the cable?
No one would notice, right? So most of the cars, I don't know if you are 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 most of the cars we tested, actually all of the cars I believe
implemented this feature. So 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. So you try to disrupt
as many cars as possible or as many charging parts as possible to, for example, disrupt
supply chain. We saw earlier buses are getting electrified, ferries and trucks. So 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 bidirectional charging. I should mention
maybe for this threat model or for these goals, we assume exactly the same capability. So just
access to software defined radio or transmitter off the shelf you can get from Amazon. And a
little bit of knowledge about digital signal processing. So we found broken wire. And broken
wire exploits the CSMACA mechanism used by home plug green fi. So 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 2dB 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's no
interference happening. For some of you who might not be familiar with CSMACA, here's just
a diagram how this usually works. So let's assume you have a car and a charger. And they don't have
or wouldn't have CSMACA. 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 home
plug green fi modem checks if the channel is clear to send. And if it is clear to send, it would
send the 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. So on the previous slide, I just showed you the
standard says someone is communicating or the channel is busy if we see a preamble 2dB 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 home plug green fi
frame. We collected by just plucking a modem into a software-defined radio. So this is in the time
domain. And the first bit you can see is the preamble. So that is used to detect if someone is
communicating and also do frequency offset correction and timing. And then you have the
frame control and, yeah, the legacy frame control and the AV frame control. And then you have the
payload. And as I said, this was collected while plucking the modem actually into our receiver.
And there is also some noise, of course. And you might have already spotted it, but there's also
another preamble in there. And this is a preamble which is 2dB above noise. And 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. So 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
QCA7000. And, yeah, as I said, it's exactly the same chip. We connected one to a 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, like, examine the quality of the channel, basically. Yeah, 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 PLC is communicating at around 2 to 28 megahertz
like in this band. So we set a center frequency to 17 megahertz. So we have a pretty high or
large wavelength. So our antenna was actually just a bunch of wires. And I'll have a photo
later where you can see it. We connected this to a small amplifier and a Lime SDR. So this setup
cost you maybe, I mean, now the Lime SDR actually got quite expensive. But it was maybe $250, $300
before the chip prices. Yeah. Right. So we did some experiments in our lab, like in the
university. You can see the home plug green fire modems in the back. Our attacker set up in the
front. And this was roughly, I don't know, maybe 8, 9 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. I mean, just a home plug green fire communication.
And as you can see, so it's plotted in dBm and milliwatts. On the left, dBm. You can see that
for a distance of 10 meters, we actually were able to disrupt this communication with less than
10 dBm or 10 milliwatts. So your Wi-Fi router is probably transmitting at around 100 milliwatts.
So just to give you an idea, this is like 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. And 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 like 70 to 100 milliwatts. So, of course, we were curious. Actually,
we only tested it so far in the lab. Can we actually target charging 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 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.
And, yeah, we tested different scenarios. So, 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 then disrupt the charging? So I would say scenario
2, 3, and 4 are commonly seen at supermarkets, for example. And 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 1 watt, which was limited by government regulations. So we couldn't transmit
higher than 1 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 follow the standard and the standard like home black green
fire 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 break. And so, yeah, 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 it didn't really matter. It still
worked. So we did the distance experiment. Again, 1 watt of amplification. So roughly 1 watt. It
was just below. And we were able to disrupt it from around 50 meters. So what can we do to
prevent this? So 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. And since we were 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,
yeah, 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 pre-ample
detection and the 2 dB, if this is a threshold which is set in firmware or if it's a hardware
limitation. And 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
depot like the DVD 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
re-authenticate or re-continue the charging session. So we said,
redeploying the same vulnerability. So why was this the title of our talk? Well, what is next?
That's the big question. And currently, there is work going on on the megawatt charging system,
MCS. And interestingly, so it has almost 4 megawatt of charging capacity. But interestingly,
it also uses power line communication again. It uses differential PLC, which should be, yeah,
not as easy to disrupt, but we haven't tested it yet because it's not widely deployed, or it's not
deployed yet. Just for your information, this is like the plug compared to CCS. I mean, it looks
quite similar, but you now have a communication interface in the middle for a twisted pair.
Yeah, so the differential signaling should significantly improve like the EMC
compatibility of the PLC communication. But yeah, as I said, we haven't tested this yet.
And using a shielded, unshielded twisted pair, UDP wire should also help to increase noise
immunity. Roughly 40 dB higher is Jarin saying on their website. So Jarin 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,
right, like onto the PCB directly. So you could modulate your signal into a higher carrier,
high-frequency carrier. And so it's not, 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. It's the Tesla plug. And they say basically that for DC charging,
the electric vehicle should or NACS should support power line communication to make it
compatible with 1070-121. 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 showed that we can e-strap 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 U.S. 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 Saurier 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 can 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. Yeah, and this is the error where you need to go
unplug it, plug it in again, so it doesn't go away automatically. Right. That's it. If you have
any questions, feel free to reach out to us on brokenwire.fail. We have more information. There
is also the paper available. And there is also some information on NIST for the CVE we got. But
happy to take any questions. Thank you. Oh yeah, sorry. There is a microphone right here if you
have any questions. Hi. Just a question. Were you able to also... there was a... you mentioned about
the billing. You can... there's 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 talking...
or you're asking about the identifier which is transmitted between the car and the charger. So
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. And so if you have the MAC
address, yeah, you can... so if I e-stop on your communication and get your MAC address and
spoof my MAC address, I could charge and you would be paying for it. So basically we can snip MAC
address from the car between the charger during the session and then we can use this to auto...
bill for that user that we snipped. Is that correct? Sorry, could you speak up a bit? It's
hard to hear. So the car connects to the charging station during the initial session, we sniff the
MAC address and then can we replay that to charge the user? Right, if we can replay...
Yes, you capture 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 doesn't... 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 kind of 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... Some appropriate slide deck. I
know some folks where the slide deck would be great for explaining. Yeah, of course. Yeah,
I think you'll find all the resources there. No worries. One question, please. The MAC address
that you identified, this is a MAC address of the vehicle or the charging system of the vehicle?
There are two, and you get both of them in different messages. 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.
And 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 blanked and one
of them not. It depends on which one you're looking at. Because it's totally different ECUs.
The MAC address virtually will be in part of the TCU and not part of the charging system.
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.
We have one from the modem and one from that, from the EVCC. So I mean, 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, Sharon 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. There's... I mean, some things are very difficult to change, right?
You've got a standard that has this communication was 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 you could deploy later, like
firmware differences or additional sort of detection systems for just constant preamble
or something. But yeah, I mean, as a general rule, yes, let's try to fix this. And hence why we're
sort of doing this talk now. And we'd be happy to engage with anyone that's doing work on any
new charging standards. Yeah, thank you. Sorry, if you need to...
Yeah, so the question I have is, like, 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 use to do this is somewhat unique in the fact... because you need,
about 28 megahertz of RF bandwidth in order to do this attack. So things like a hack RF
won't work, because they've only got 20 megahertz. Now, the new LIME SDRs 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, like, a high-end USRP
that will do this, you know, has a required RF bandwidth? Because I'd love to hear about that.
Yeah. So we played with a couple of different ones. I mean, I think prices went up a little
bit across the board. At the time, the big LIME SDR 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 the LIME SDR.
They've got more expensive, but they're still not, you know, quite USRP territory.
So the current LIME... are you talking about the old version and trying to get it off eBay?
Frankly, either. I would probably... a V2 should work fine. We haven't tested the V2 ourselves,
but, you know... Well, the V2 does have the required bandwidth? Yes. And it'll tune down to,
you know, tune down to 2 to 20, 2 to 30 MHz? And in fact, I mean, depending on what attack you
want to do, whether you're, you know, 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 of what to
buy, we could perhaps have a little offline chat, but most of the things that are above, you know,
an RTL or something should work fine. I will also say, you might have some success even with the
20 MHz Sumerhack RF for two reasons. One, we did test broken wire with less of the preamble,
you know, 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. 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. You know, it's a
very, very hostile network if you're, if you're, um, hostile, uh, transmission environment on these
wires, and so it's built to be robust against that, and you could lose a whole chunk of the
sub-carriers and still recover messages. Of course, your mileage may vary, but, uh, you might have
some success with the HackRF, if not, yeah, probably swap in for a LimeSDR or the, or the
BladeRF and upconverter. Very interesting, thank you, I didn't know that about, I thought it was
using all the OFDMs. Yeah, of course, I mean, it tries to, but it's surprisingly resistant to,
to loss or noise or whatever. Okay. Happy to talk more afterwards, yeah. Okay, okay, cool.
Hi, um, I'm not, I'm not really knowledgeable about the protocol, but, uh, 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, uh, if we have this type of radiations, we
reduce the speed, reduce the slew rates, or, uh, also doing some spread spectrum on the transceivers
to mitigate the radiations. Has this been, uh, already placed on the table? Um, so no,
so it's an OFDM system, um, and there's certainly per carrier control to, to stay under EMC limits.
Um, so part of it was, of course, that, that distinctive spectrum template that I showed,
you know, notching out the, um, the amateur bands. Um, and you could power control there or you, and,
just under the threshold for, for radiation. Um, I think realistically it's just, if you turn up
your LNA enough, you can kind of still pick it up, but it's still compliant. Um, and then there's
plenty on 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. Yeah. So only through, uh,
I mean, so some implementations of this are a wire, um, at which point it's just going to be
leaking out all over the place. Um, the differential down a twisted pair. Yeah. That's probably going
to be very helpful. Um, but you know, bear in mind, this is a technology that's coming from
an in-home environment and genuinely people's power wiring, which is just, you know, uh,
wires randomly laid over 50 years by different electricians and so on. So it's not, it wasn't
really built as a communication protocol for a purpose-built environment, but rather making the
best use it could have of the conditions it had. And that's why it's not ideal there. And is the
amount of information, uh, that you do during the handshake, uh, really needs the amount of,
uh, speed or why not use lean or... Yeah. I mean, all the other charging standards do not,
like I typically use a CAN bus link and do fine. Um, I think a lot of it was a future-proofing
idea. Um, 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, you know, but, um, 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 need that much data. Okay. Well, thanks. Thanks very much.
And thanks everyone for coming.