DEF CON 31 - Car Hacking Village - Exploiting Wireless Side Channels in EV Charging - Kohler, Baker
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 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 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
