-- MARKDOWN --
- Some European countries use **unencrypted and unauthenticated longwave radio to steer** parts of their **renewable power**, enough to potentially **cause a Europe-wide blackout**
- The control signals can be sent with just a Flipper Zero over short distance, or **via self-built transmitters over a long distance** (e.g. using a kite to lift an antenna wire)
- The system is also used for **street lamp control**, allowing for a scaled-up “Project Blinkenlights” art installation that **transforms an entire city into a screen** (for astronauts)
- The company operating this system has **threatened us with lawsuits** and (now publicly) denies the risk
At the [38c3 hacker conference](https://events.ccc.de/congress/2024/infos/index.html), we [presented](https://fahrplan.events.ccc.de/congress/2024/fahrplan/talk/HSNZGR/) our “BlinkenCity” research, which **started as a fun art project idea**, and **ended up as a plausible European blackout scenario:**
**[media.ccc.de link](https://media.ccc.de/v/38c3-blinkencity-radio-controlling-street-lamps-and-power-plants), [slides](https://cdn.prod.website-files.com/5f6498c074436c50c016e745/6776eb76a3490010d8e59fbb_20241228-BlinkenCity-38c3.pdf)**
Below is a **slightly edited transcript** of this talk for easier consumption.
If you also don’t have the time for that, we suggest just watching the following two illustrative videos to get an impression (otherwise, you can skip those and join us on the ride):
There would be a lot more to share besides what we could cover in the talk, from data analysis on the telegrams, over bypassing PIC Code-Readout Protection without a special programmer, to custom tools (Flipper app, Telegram decoder, physics-based attack simulator), data sources and transmitter hardware considerations. Let us know if/what you’d be interested in, and we will see what we can do (also ethically and legally).
*DER SPIEGEL* has published a (German) [article](https://www.spiegel.de/netzwelt/web/stromversorgung-koennten-hacker-blackouts-ueber-funk-ausloesen-a-53c29240-425b-4603-852e-5a1c0a1e5400) ([archive link](https://archive.is/p66as)) that includes more statements from the affected company and federal agencies.
# Table of Contents
- [Introduction](#intro)
- [Time Spoofing](#time) (+ lamplighter video)
- [Versacom](#versacom) (+ solar and Streetlight-B-Gone video)
- [Semagyr](#semagyr) (+ live demo)
- [BlinkenCity Feasibility](#blinkencity)
- [Blackout Feasibility](#blackout) (+ kite demo and attack simulation)
- [Disclosure and Press Statement](#disclosure)
- [The Way Forward](#outlook)
- [Takeaways](#takeaways) (+ Pac-Man video)
-- /MARKDOWN --
*Introduction by moderators*
*Start of talk*
Thanks for the introduction. Thank you all for coming, and for the awesome La Ola here in the beginning. This is Luca, I’m Fabian, and we're both quite excited to present this research now for the first time.
But before that, we need to start with a disclaimer:
With that out of the way, let’s start this talk where the research journey also began for us: with a broken street lamp in Berlin.
One of the street lamps was missing the cover on its pole, so we could peek inside and we found this box, which had a relay and it said Funkrundsteuerempfänger. Also, each of those poles had another ominous box on the top.
Turned out, we found a radio-controlled switch and the antenna was externally mounted in this upper box.
Naturally, we got curious, and we found that this system is operated by a single company called EFR (short for Europäische Funkrundsteuerung) and it consists of three transmitting stations (two of them in Germany) that send high-power, low-frequency signals as “telegrams” over the rather obscure protocols Versacom and Semagyr to devices in Austria, Czechia, Germany, Hungary, and Slovakia.
The system works as follows: around 300 clients, mostly energy companies (which we'll call EVU), use either a web-based (internet-exposed) application or a VPN-based desktop application to trigger the sending of commands to their receivers. Those are then forwarded to one of the transmitting stations and broadcasted to the radio ripple control receivers (we’ll call them FREs). The FREs can then either switch simple relays or run more complex programs. Switching a relay will connect or disconnect a supply or load to or from the grid. Multiple relays are commonly used for a kind of dimming functionality, not necessarily for multiple devices.
We also found that this system has an arguably much more important role than just controlling street lamps: As part of Redispatch 2.0, it’s used to counteract regional imbalances within Germany to keep the grid stable.
This means the same system is used to control renewable power plants like solar, wind, biogas, as well as various loads such as heat pumps or wall boxes. It’s also used for switching between the day and night power tariffs and for controlling custom devices like industrial freezers. Additionally, the same frequencies carry a proprietary weather forecast service called Meteotime II as well as normal and some encrypted time information.
Digging just a little deeper, we found company slide decks listing many of the big names in energy as their clients, and an ever-growing number of deployed devices—over 1.6 million was the last figure we found. Also, in one of the slide decks, they actually mention numbers for some example customers, adding up to multiple gigawatts of load and supply.
Considering those large numbers, and with major blackouts already having happened in the US, plus ongoing reports of grid instabilities in Europe—and recent hybrid warfare strategies with just another undersea power cable being cut a few days ago—we wanted to investigate:
How likely could this system be abused to cause a power outage?
But before things get too serious, let’s go back to the street lamp, because our initial motivation was actually much more benign: We were inspired by the awesome Project Blinkenlights and were wondering: Could this idea be scaled up?
Could we use an entire city as our screen and play a game on it?
We were imagining something like that:
Okay, but how doomed are we really, Luca?
Okay, so the first thing we realized is we needed to learn how this radio protocol actually works. The logical place to start is to capture what’s going over the radio. There are at least three ways:
It sounds a bit like a modem, and in fact, it’s an FSK modulation. The parameters are on the slide. You can replicate this with your own setup or just buy a device, like we did, and start getting the bits.
Once we had the bits, we collected the raw radio messages received by our device. What you see on the screen is a bunch of these messages. You’ll notice they all start with 68, then there’s a length, another 68, some control field with a sequence number, some other yet unknown number, a 16-bit address (which is quite short, but still works), and then (in blue) the payload, which we were interested in understanding.
One specific message (with address zero) is sent every 10 seconds, which suggests it might be for synchronization or timing. Looking at the other ones, we can see that the message length was variable, and some of them even looked encrypted (their entropy was very high).
Let’s start with the first one.
There is an address 00 00, and we understand that this means every receiver will receive and parse the message. We logged the time when we received the message and then looked at the bytes, which only changed slightly between the messages.
Indeed, we discovered it includes a time signal: seconds, minutes, hours, all in cleartext. So the time is broadcast unencrypted, with no integrity or replay protection.
As a security researcher, the first question you ask is, “Could you replay or alter these signals?”
Possibly yes. That could confuse or override the clocks on devices that rely on time for switching, for example, street lamps that switch on/off by time-based programs (as a backup, in case direct switching did not work).
We became a bit nostalgic thinking about traditional lamplighters a century ago—someone walking around with a stick to turn lamps on. And, well, if you have some imagination you can imagine how this would look like today:
So there is a stick, and the light goes on.
Ok, this seemed interesting, but we didn't know much about the protocol. There were plenty of other messages we needed to study. At that point, we decided to build a full playground with various devices.
We bought devices from different vendors using different protocols. Then we realized we needed a way to send messages to the devices, so we implemented an emulator of the real transmitter.
We used an ESP module from the lab, a waveform generator, and a coil from a mobile phone charger. We tuned it with some capacitors to the correct frequency. With these elements, we created a lab where we could receive and send messages.
The next question was: What are we sending? To figure that out, we looked into manuals and documentation. Our research revealed that this technology dates back to the early 20th century. The version used today is called Radio Ripple Control, derived from an earlier technology simply called Ripple Control.
Ripple Control, developed about 100 years ago, involved injecting tones into a power line. A receiver would detect the tone and perform an action. When radio technology was invented, it became too expensive to continue using power lines, so radio waves were adopted. The protocol itself remained largely the same, with some additional functions to enhance its capabilities.
There are DIN standards for this technology available on the DIN website. Some are still in draft form, but if you call VDE and ask nicely, they might sell them to you. We acquired these standards and began studying them. The first protocol is called Versacom, and the second is Semagyr. We will begin with Versacom.
Versacom is somewhat more modern and easier to parse. After the EVU address in the outer telegram structure, it uses a 4-bit function specifier, a 4-bit address mode specifier, followed by the function arguments and the actual address specifications. The functions are defined in the DIN norm and range from simple and cyclic on/off switching to vendor-specific commands or deactivation of the receiver. The addressing is more complex and allows targeting a group of devices using a combination of A, B, C, and D address levels. If none of these levels are used, it targets a single receiver via the single addressing mode.
Let’s delve deeper to understand how we can control a device in front of us.
Here, we have two telegrams: the first uses the A and B address modes, while the second also includes the C address mode. The second telegram targets a smaller, more specific group of devices.
Group A addressing consists of six bits, which can be set to either one or zero, specifying whether devices parameterized with that A address level should be switched. Group B, C, and D address levels are variable in length. Group B’s length is defined by the last two bits of Group A, while Groups C and D are determined implicitly based on the remaining bytes, so all quite complicated. Also, when Groups C and D are used together, they form a matrix.
We investigated how this is used in practice and found extensive information from various energy companies. Address levels A and B are typically used to specify the energy type and power class. For example, a code like "A=1, B=1" might target wind parks with over 10 megawatts of power. Groups C and D are used in combination for regional targeting, where each German zip code corresponds to a matrix cell.
We also discovered EVU addresses in those PDFs as well as a definition of the "dimming feature," which associates relays with specific output power levels.
We could also extract EVU addresses from recorded telegrams. Additionally, we came across an internet-facing customer portal by EFR, which was leaking extensive information, including sent telegrams and a complete list of EVU addresses to unauthenticated users via WebSocket. Although this vulnerability has been fixed, it isn’t necessary for the attack to work.
Using the approximately 300 EVU addresses we collected, combined with our understanding of the addressing modes, we can target the device in front of us—or even switch off all Versacom-based devices within range.
By sending a telegram that uses only A-level addressing and setting all six bits to one, we target all devices with matching EVU addresses. If the command is to switch off, and we cycle through all 300 known addresses—or even all 65,000 possible addresses—we can disable the device and determine its configured EVU address based on when it switched off.
And with that, you can disconnect real photovoltaic systems from the grid.
On the left, an LED indicates power delivery to the grid. At the bottom, the system shows approximately 2.5 kilowatts of power being transmitted. On the right, the relays are in the "on" position. When the attack begins, within seconds the relays turn off, the power output drops to zero, and no power is delivered to the grid.
Some of you may have wondered now, “Could this really be done with just a Flipper Zero?”
Initially, we just sought a tool to select payloads and monitor attack states. The Flipper Zero, with its SDK for app development, seemed like a good fit. Only then we discovered we could repurpose its 125kHz RFID antenna and its RFID reading functionality to then in software create an FSK-modulated signal, also at 139 kHz, and with a range of around one meter.
What that means is, that with just a little bit of magic, a Flipper Zero could become a “Streetlight-B-Gone”:
So that was the closing slide for Versacom. We basically owned it…
Now, let’s move on to the second protocol, Semagyr.
We began our exploration in a similar way: starting with the standards. At first glance, it seemed more complex. The payload could be split across multiple telegrams, and there were sequences, headers, CRCs, and zero-padding to consider.
To identify where these messages were transmitted over the radio, we analyzed the bytes. We found some zero-padded message patterns and messages split across multiple Telegrams. This appeared to match the protocol's structure, however, upon closer inspection, the structure of the bits didn’t fully align.
Another problem was that these messages were sent only every six hours. This raised doubts—controlling solar plants only on a six-hour interval didn’t seem feasible. Additional encrypted messages, sent at the same interval, appeared to relate to weather forecasts (the proprietary Metotime II), which was out of scope for our research.
Since we couldn’t initially find the actual Semagyr messages, we turned to the devices themselves.
Opening them revealed two architectures: one based on an older Motorola chip with external flash memory and some security protections, and another using a modern PIC chip with internal flash. The latter was known to have a hardware bug that could allow firmware readout under certain conditions, though it required two devices with the same firmware to exploit.
Using standard hardware reverse-engineering techniques, we connected oscilloscopes and logic analyzers to observe the devices’ behavior during reboots and message transmissions. We discovered that when the correct EVU address was received, the device accessed flash memory to retrieve its unique 24-bit address. This address is crucial for targeting individual devices, e.g. street lamps.
Our next step was to understand the protocol further. So maybe we could get some information from the second type of the device affected by the Code-Readout Protection bypass?
If the device is configured (in-)correctly, it’s possible to read out its memory. However, this requires two devices of the same type and firmware. Why? Because you need to overwrite the bootloader, dump the memory of the rest, then overwrite the rest and dump the memory of the bootloader. While feasible in theory, we didn’t have the right programming device to carry out this process, and also the architecture wasn’t supported by the IDA decompiler, making the task more challenging. Also, we didn’t have the right hardware to debug this device.
This prompted us to ask: isn’t there an easier way to figure out what the device is doing?
While investigating the devices, we found an infrared port on every device, similar to those used in smart meters. In fact, one device's datasheet mentioned a standard also used in smart meters.
We found some open-source tools and tried communicating with the device using a USB adapter—but we did not receive any response. After some Googling, we learned about custom tools used to program these devices. Technicians use these tools to parametrize the device before or during installation. However, the vendor's websites did not offer to download these tools.
We decided to try fuzzing to see if we could discover anything. We experimented with different speeds and byte combinations, eventually getting a small response—more like an error than useful data.
Thinking this would take long again, we spent another half-hour searching online, and we eventually found one of the programming tools technicians use.
This tool, when connected to the infrared port, could read the device ID, the full EEPROM, and various configurations.
The tool displayed pre-stored configurations, including commands and programs we didn’t fully understand yet. These configurations included numbers, addresses, pluses and minuses, which seemed cryptic.
So we thought, we need some help, so you click F1 and you get the Windows help.
From RPT01’s built-in help function, we could find some very good information. Finally a help function that's actually helpful.
From it, we learned how the plus and minus signs worked, how the programs operated, and even used the tool’s advanced feature (“Telegramme rückübersetzen”) to decode hex strings into commands. By testing and pasting potential payloads to see which would make sense, we learned commands often started with specific patterns, like the letter E.
To deepen our understanding, we also purchased papers from 1993 authored by the protocol's creator and reviewed patents describing its functionality. Armed with this knowledge, we revisited the data.
This time, we identified relevant telegrams and matched them to specific functions. One interesting command is the “Direct Command” (0xE). One complication in Semagyr is that it allows concatenation of multiple actions in the same telegram. For example, the second telegram here starts with a 9, indicating individual addressing, followed by 24 bits for the device ID, and then the actual command starting with E.
This was actually not documented in the standard but became clear from the tool's descriptions. Examining the green-highlighted bits revealed some bits set, but mostly zeros. With the help program, we identified address and program arguments. However, we still couldn’t fully decipher the program functions as we couldn’t read it out. With again a bit more work on the bytes of collected messages for a specific EVU, we noticed patterns where certain bits corresponded to program addresses and arguments and that only very few bits are used.
The tool, RPT01, provided templates for these programs. Some templates were complex, involving nested conditional statements, reads from flash and multiple relay controls. Others were simpler, setting specific relays based on particular bits. Since our goal was to control specific relays, we returned to fuzzing again to identify existing programs and the relays they triggered. With electrical cables set up, we conducted tests, also giving us some nice Christmas lights in the office.
This process yielded a list of program addresses and the corresponding bits needed to control each relay.
Finally, we found screenshots of a testing tool used by technicians to trigger relays individually by emulating radio telegrams (e.g. DK25 here). Using this insight, we confirmed that each device contains test programs for relays. We tested this in the lab, where we had several devices. Once we identified the correct commands, we could successfully trigger the relays at will.
To demonstrate, here’s the radio ripple control receiver with its relays. We’ll also put our emulator/sender close to the device.
Since you can probably not see it very well, I thought you might need some LED, something blinking, to see it well.
*pulls up mini street lamp*
I’m going to send a couple of messages, and you might recognize the sequence I’m sending.
Okay, it’s Morse-Code for “CCC”. This is the example, we wanted to show. Of course, we can do the same for any Versacom device, so yes, we can make lights blink.
Then the question returns: Could we realize the BlinkenCity idea?
So, yes, we can control individual street lamps via radio. To display arbitrary content, we need to identify the correct individual IDs and map them to specific locations. The IDs can be extracted from recordings using single addressing mode or read via infrared. Once one is identified, you can test the previous or next IDs to see which ones go out and map them to their locations, during a bike tour or possibly with a drone. However, there is one limitation, the low “frame rate”. We can only update about two pixels (or full regions) per second and sender, and the sender(s) must cover the entire city. With those limitations in mind: Yes, it’s technically feasible but likely best suited for time-lapse visuals.
Naturally, the next question was, how many screens do we have in Germany, and we thought: “Let’s just ask the state”.
Some cities considered the technology controlling their street lamps as sensitive information about critical infrastructure, while others provided more information than asked for. For example, Bielefeld not only confirmed that it exists and uses the radio ripple control technology, but also revealed the existence of two light sensors (at the two locations mentioned in their response) acting as master switches. So ironically, it seems possible to turn off the street lamps of a few cities using just a flashlight.
You might also wonder: “What about here in Hamburg?”
There, we just stumbled upon some news from a few months ago that Hamburg is migrating its streetlight control technology to a new “future-proof” system. We were excited and wondered: “What kind of IoT stuff are they trying out?”
No, it turns out, they have just finished migrating to the system that we’re just talking about today.
So unfortunately, our talk is too late for Hamburg, but we hope that for other potential migration plans, this system’s insecurity can at least be taken into consideration during the decision-making process.
Also, when it comes to interesting news, also just from a few months ago, we read from a “Hiccup in Hesse”, where a few cities with FRE-controlled street lamps were completely dark, and people already speculated about hacking attacks. Turned out, it was a technical defect (whatever that means exactly), but I just want to use this opportunity to clarify that that was not us, and also no street lamps were harmed in the course of this research.
With that, we also need to go back to the more serious topic: Could we cause a blackout?
While we are not grid stability experts, we believe three conditions need to be met for this to happen:
Manual research for the top energy providers in Germany suggest that around 80% of the power controlled via “ripple control” technology is now controlled via the new radio-based version. Germany has laws around remote control requirements for renewable power plants:
But we wondered: Does that mean that FREs are not in use in the last case? And how about those massive solar parks?
That would be very helpful, but probably very hard to find out as that seems like the heart of critical infrastructure. That’s what we thought until we found the following YouTube-Video:
“Here we have 4 of those receivers, for each segment we have one. And you can now imagine that each of those FREs is responsible for roundabout 20 MW”
We can also confirm that those FREs are still in place there today, as based on that little information and despite those 80MW only representing a part of the full park, with those numbers it was quite easy to pinpoint:
The FREs belong to the 3rd largest solar park in Germany with over 160 MW.
We also found many PDFs from various energy providers that explicitly mention the use of FREs for power plants larger than 100kW.
But what is now the overall number of radio-ripple-controlled power? Unfortunately, neither EFR nor Bundesnetzagentur has this number, according to their own statements, so we needed to estimate it ourselves.
To calculate the total power controlled via FREs, we analyzed 2GB of zipped XML files (that include information about every single power plant in Germany), sent some questions to the press departments of various energy providers, and we dug deep into statistics.
Overall, this adds up to 60 gigawatts of imbalance potential, which seems significant, also considering that this estimate does not consider countries other than Germany or energy types other than wind and solar.
But just how significant is that?
To understand, we need to look at the grid frequency. It’s 50 hertz, and it should always stay there.
In theory, with a fully loaded grid at 300 GW, creating a 1 Hz change to reach this private load-shedding threshold requires an imbalance of 18 GW. However, such a large imbalance—though not even that massive compared to the 60 GW estimate —has never been seen.
In practice, one of the most recent incidents was in 2021, when approximately 3 GW of power were unexpectedly lost in Poland, causing the grid frequency to drop by 0.16 hertz. What this demonstrates is that the grid hasn’t yet faced such a significant imbalance.
But if we start talking about imbalances of 18 GW, or 60 GW, or even more when considering other countries, there’s an additional issue besides the theoretical effect on grid frequency. That issue is power transfer.
If a significant amount of power is missing in one region, it must be transferred there over power lines that could become overloaded. These lines might then shut off to prevent damage, which could overload other lines, causing them to shut off too.
Such a domino effect - or cascade - happened in 2006, when a power line was shut off to accommodate a cruise ship transport. The planning wasn’t thorough, and a cascade of failures followed. So, the theoretical limits of the grid don’t fully capture the potential for much larger disruptions.
Taking all of that into account, it’s clear there is enough power under radio control to cause serious trouble. Let’s consider whether we reach that power also range-wise.
Right, so we said there are three conditions. This was the first. The second condition would be to take over the radio transmissions. There are probably two ways to do this.
The first approach we considered was: can you override the signal? In other words, can you send a signal that’s more powerful than the original one?
Since we’re not that much experts in low-frequency, we consulted some experts. They provided us with formulas, and we developed a simulation tool.
We started with a basic assumption: You need a very good antenna. An antenna is essentially a wire of a specific length that resonates at a given frequency. For this case, with such a low frequency, you’d need a ~500-meter-long antenna for pretty optimal performance. That’s obviously challenging to achieve, but we explored how it might be possible.
Next, we assumed: imagine you have a 10-kilowatt transmitter. You could build your own amplifier, and use portable battery systems that can deliver that kind of power. Based on that, we ran simulations.
If you look at the map, there are green dots (the EFR transmitters) and red dots, which each represent such a rogue transmitter. For example, if the distance between the original transmitter and the rogue one is 300 kilometers, the rogue transmitter’s front lobe can overpower the original signal for about 70 kilometers. In the back, it extends up to 240 kilometers.
To cover the entire country, you’d need multiple transmitters. While it’s not straightforward, it’s possible if you have enough power and transmitters.
Now, let’s talk about the antenna. A 500-meter-high antenna is obviously difficult to build. So, we drew inspiration from radio amateurs. They often use kites or weather balloons to lift wires into the air. This technique is quite common and can take antennas to heights of a kilometer or more. Another option is using drones, though their flight time would be limited.
Once we had these calculations, we considered how practical this kind of attack might be. We decided to test it—not on the actual frequency, of course. We built a small-scale version to see if it was feasible.
Yeah, that first drone-test was a bit of a failure. So in the end, we went to Tempelhofer Feld in Berlin and used a kite. Here, we were limited by the law to:
But it gave us a feeling on how difficult it would be, and it actually worked quite beautifully.
As you see, we had a bit of fun experimenting. Let’s say this represents the approach of an amateur. However, we also need to consider how real attackers might approach this scenario. Specifically, how might an enemy state conduct such an attack?
We believe they probably wouldn’t rely on something like a kite, but instead would target the infrastructure of the company operating this service. There are probably two primary methods they could use:
Having explored these possibilities, we also considered how an attacker might plan such an operation. We drew inspiration from this 32C3 talk, which we highly recommend for anyone wanting to delve deeper into this topic. Using that framework, we created a conceptual plan for how such an attack leveraging FRE control could theoretically work.
For legal reasons, I want to emphasize that these are not “illegal instructions”, but rather a thought experiment as part of our feasibility study.
So, first, if you were to opt for the decentralized sender approach, you’d need to find good locations for transmitters, a bit further from the original ones and with controllable load or supply in range. As an attacker, I might use public data like this and input it into a custom physics simulation.
One could even use the full Marktstammdatenregister-based estimate and experiment with radiated power to determine the best approach, and maybe also check different potential transmitter locations interactively or write a program to algorithmically optimize this complex problem.
Timing the attack seems quite straightforward. There is near real-time public information on the composition of the German/European grid available online. This screenshot, taken in late September may not show the "best" day for such an attack, but it does show that even then, on a sunny day, the majority of the power is still being generated from renewables.
If you think you identified the right time, you can also consult the Netzampel, provided by energy companies, which shows how many renewables are already being turned off to keep the grid stable as part of Redispatch 2.0.
If a lot of renewables have already been turned off to maintain grid stability, the attack could begin by turning all of them back on.
This would increase the grid frequency, causing other power plants (that are not under our control, e.g. old-style coal plants) to reduce their output, basically allowing for a kind of amplification attack.
If the grid frequency returns to 50 hertz, you could time the attack with the hourly changes when some plants are being shut off and others turned on (this triggers a “natural” dip or peak in the frequency, allowing you to save an additional ~2 gigawatts). Then, you could turn off all the renewables in range and switch on all the loads. This could be done multiple times in a series of on/off cycles. Timing and syncing with the grid’s resonance frequency would further improve the attack’s effectiveness. To further complicate matters for the incident response team, you could also deactivate the FREs and continue jamming the frequency.
To summarize:
So, overall, we believe this attack scenario has the potential to cause a major blackout, especially through the cascade effects we mentioned earlier, or at least, a brownout—regional power outages. Even if it did not, it would still have significant short-term effects on energy prices, could cause a network split, and undermine public trust in grid stability.
But as we mentioned earlier, we're not grid stability experts, so when we shared this research with Der Spiegel, they reached out to Professor Dr. Albert Moser, a university professor at RWTH Aachen, asking for his opinion.
He confirmed that “an attack of this magnitude could indeed lead to the first Europe-wide power outage in history”.
I can tell you that this is not what we expected or hoped for when we started with the BlinkenCity idea. But after digging deeper into the issue—and perhaps influenced by certain aspects of the disclosure process—this is where we ended up at.
As things got a bit serious, and we are serious researchers, we initiated our responsible disclosure process in September.
We reached out to the company involved, shared the vulnerabilities, and had a call with them. Their response? “Oh, we were aware of that already.”
We then scheduled a meeting, and during the meeting, we explained more details about our findings. They acknowledged that they were aware the protocol was unencrypted and that certain attacks could be carried out. Apparently, this issue was identified by university researchers back in 2013, and it even made its way into a book published by BSI, the German cybersecurity agency. So, this was very well documented, and they had known about it since 2013.
In fact, by 2015, they had developed an encrypted version of the protocol. Unfortunately, no one wanted it —nobody was willing to pay for it—so it was never deployed. Another point we raised was about the big power plants using FREs. Their response was: “That should not be the case.”
We then disclosed this information to BSI, which in turn passed it on to other agencies. The company operating the FRE system then notified their customers not to use FREs anymore for those very big power plants. After that, we thought, “Okay, we’ve done a good job. Things are moving in the right direction.”
However, it seems EFR decided to contact their lawyers, and they became a bit concerned because we mentioned we would present this at the CCC (Chaos Communication Congress). They said, “No, no, no, you can’t go to CCC with this. You can’t present it.”
Quite funnily, the lawyer explicitly stated—and this is a direct quote from German—that we are providing “literally illegal instructions, which might be the theme of the conference, but could have severe personal consequences for you”.
So, we thought about it and decided this needed to be made public, because we wanted to ensure that a broader discussion would begin, involving multiple parties. We were actually surprised by how collaborative EFR was at the beginning. Every time we reported an issue, they took action to fix it, which was a positive thing.
But just a few hours ago, you might have seen the news—they issued a statement denying that this attack scenario was even possible.
In a previous email (lawyer letter) they sent us, they had acknowledged that such an attack could be carried out with “many suitable transmitting stations over 200 meters high”. So, they knew it was possible. But now, they’re denying it.
Of course, this is not ideal, but we’re ready: If they want, we can test it in the real world.
We also thought about potential solutions to this issue. While the protocol is old, there are newer alternatives, and quite a few of them. One in particular was approved by BSI and is relatively modern. It's specifically designed for smart meters and is called iMSys (Intelligentes Messsystem). We believe this could be the solution. It currently uses LTE for the back-channel, so in addition to using an encrypted protocol it also goes over an encrypted network. In the future, there are plans to run iMSys on a completely independent 450MHz LTE infrastructure that is exclusively for critical infrastructure. This sounds promising.
The company that operates the long-wave system also provides these devices, so it seems this could be a smooth transition. However, there is an issue with the timeline.
The system was designed in 2017 but is only starting to be deployed now, in January. Additionally, it will take seven years for (almost) full deployment. One more issue is that the planning puts the largest power plants at the end of the schedule, with deployment starting in 2028. These large power plants are just a couple hundred in number, while the rest are in the hundreds of thousands. What we're suggesting is for the regulators to review the schedule and start with the large plants first. That would mean 80% of the work is done, and the remaining plants can be handled in how many years are required.
So, that’s a stimulus for regulators to review the deployment plan and get it done.
To summarize:
Finally, there’s just one more thing: We talked about how playing Doom on this system would be super slow, but I had another game in mind that really begs to be put into the real world, or maybe already is a virtual representation of the real-world system. Does anyone want to take a guess about which game I’m referring to?
Audience: “Pac-Man”
I heard it!
--
<3 Thanks to Jakob Lell, Maximilian Kirchmeier, Dr. Markus Vester, Thomas Blinn, Prof. Dr. Albert Moser, SPIEGEL, and our lawyers.
