 If data, you usually should secure them, and if you have really sensitive data, you may want to put them in an air gap network. An air gap network is just a few computers connected by a handful of cables, and data can never leave that network because there's no cable and nothing where they could travel out of the network, even if an attacker manages to run his code on your computers because you were curious enough to plug that USB stick you found on the parking lot into one of the computers. But, as Yadzak Lipkovsky, as in radio amateur news, a network cable is but an antenna by any other name, and if you can run code on the computer, you can use even a network cable as an antenna to send the data to places where they have never been before. Have fun with Yadzak's talk. Hello. I'd like to present Etherify, bringing the Ether back to Ethernet. My name is Yadzak Lipkovsky. My hobby is amateur radio. I have been licensed since more than one-fourth of a century, and my call sign is Sierra Quebec Five Bravo Papa Foxtrot. My hobby is also electronics, making and breaking networking systems and security, and I work at a financial institution in Poland. However, all opinions stated here are mine and not my employers. And in this presentation, I'll talk about Tempest, also Soft Tempest, a bit about Ethernet, about Etherify, and show some demos. So Tempest is often treated as magic, but maybe we could have a peek behind the curtain and implement it something ourselves. So this phenomenon was first documented in 1943 during the World War II. Bell Lab technicians found out that a teletype, which included a mixer, which was a cryptographical device, which they sold to the military, caused electromagnetic interference. And this was nothing spectacular, most electronic or electric devices caused some radio interference. However, they found out that they could recover plaintext from it. And it could be recovered via over quite a large distance, which was quite bad during the war, because the war effort used a lot of this equipment. On the left, you have the teletype, which is just an old type of serial terminal with a printer. And on the right is this mixer device, just a device that does exclusive R with a keystream which is provided on paper tape. So this problem was rediscovered by CIA in 1951, and on the same equipment. And this time it got a nice codeword, they called it Tempest. And soon they started to research it and found other channels, like acoustic, optical and so on. But the problem of electromagnetic interference isn't new. So it's quite possible that somebody else discovered it, we don't know who, when and if it was used for anything. So Tempest is a codeword, but it's often used as a single word to describe the phenomenon of data leaking out of devices via radio or some other channel. And this was officially declassified in 2007, so it's 64 years after the initial discovery. So somebody really wanted to keep it secret. And also of course civilians discovered this phenomenon. So in 84, Vin Van Ek showed that it's possible to eavesdrop remotely on computer monitors. And so he would just pick up the radio interference caused by the monitors at a distance, add some synchronization to it, connect, feed it to his own monitoring. He could basically watch somebody's screen from a large distance. Now Una Raisanen has a very nice video of her implementation of Tempest receiver, which works with an HDMI monitor. So this still works. And there's a link at the end of this presentation to her video. Now, site channels are very popular right now, because people use it to recover secrets from cryptographic devices. And by monitoring, for example, radio emissions or power consumption or other things. And it's just like Tempest, but the concept is the same, just the distance is usually much smaller, because they try to receive it at a distance of a millimeter or less. What are these site channels? There's the original electromagnetic side channel. There's also the acoustic side channel, optical side channel, thermal and others. So what is soft Tempest? Soft Tempest is modifying Tempest properties by software put on some device. So for example, this software could use these side channels to intentionally leak some secret from this device. Or it could also be used as a countermeasure. So this software could lower or mask emissions. So the adversaries will be less able to receive these signals. So Tempest is a phenomenon which is associated with military or espionage agencies. So what do I care, right? But actually people do have devices which are not connected to the Internet and they have some secrets on them. So for example, one such device would be an HSM or a simpler device would be a dedicated workstation which would be used for a poor man's certificate authority. Many people keep unconnected workstations which they use as CAs. And also high-risk facilities often have air-gapped networks or systems, like factories for example. And also this phenomenon can be used for defense. For example, to make it harder for interceptors, one example would be Tempest fonts in the Tails Linux distribution. And also it can be used as a fun experiment because you can see how long, what is the distance that you are able to exfiltrate the data from your devices and then assume that probably your adversaries will be able to do it at least 10 times further or much more even. And there is a lot of research in academia. If you want to read only one article about it, I would really recommend reading the presentation from Black Hat two years ago. It's called the air-gap jumpers. And it's from the University of Negev, Israel. They have a lot of very, very interesting Tempest and soft Tempest work and they do publish it. And one example of such research is GSMEN, data exfiltration from air-gapped computers over GSM. So in this publication, they use a malware on a PC, a receiver in GSM phone-based band software, but unfortunately, there is no source code, no raw data, and nothing that we could really use to reproduce it, right? It's great that they publish it and it's unclassified, but still it's not as easy to use for amateurs. And academia also has grants. They have access to expensive equipment, herds of professors and so on. There is one shining counter example. It's called Screaming Channels. It's a publication about extracting keys from Bluetooth devices. And it has its source code published, has raw data published. There's a very nice how-to to show how to reproduce the results. And this is really how this research should look like. But unfortunately, this is a rare exception. It's not the norm. Most publications are like the previous example. So how does military research look like? Actually, we know almost nothing about it. I'll show a declassified paper from the 1970s. It was declassified in 2007. And even though it's an old paper, you can see the first page is OK, the second page is OK, the third page has half of it redacted, the next page is redacted, and last page is redacted. So half of the document is actually redacted. So they really want to keep something secret, even if it's from the 1970s. But sometimes we get a leak or two, which is also nice. We can assume that probably they have an unbelievable amount of money, equipment, which is totally out of this world, battalions of professors and so on. And this is a military tempest research team. And this is us amateurs. We have no funds. We have no expensive equipment. Often we don't know what we are doing even. However, we don't know that something cannot be done, so sometimes we do it anyway. We also have cheap software defined receivers, zip ties, silver tape and all of the things that make engineering work. And so let's just have a go. Let's try to do a few simple soft tempest demo and see what we can achieve. And we will be using this receiver. It's just a dongle used to receive television, but it can be repurposed as a software defined receiver that is able to receive from 24 megahertz to 1.7 gigahertz. So it's quite a lot. And it costs less than 20 euros. So it's really technology available to everyone. And on the right you see my tempest receiver, which was used in some of this work. So let's try to find a side channel. It should be quite easy. You pick a bus, which is clocked in the megahertz range, the more the better, because it radiates better, usually. Find a way to modulate it in some way, like turn it on or off or change frequency or whatever. You can see if you can receive it at this clock frequency or its harmonics. Unfortunately, it's not that easy because devices cannot produce a lot of electromagnetic interference and so the clocks are often spread spectromodulated or the equipment is shielded for compliance reasons. Now one such interesting bus and common bus is Ethernet. And right now I mean just simple Ethernet, right? Over normal cables, not over fiber, not over coaxial cable. So this Ethernet cable, which is called UTP, unshielded twisted pair, it's just four balanced lines. There's also a variant called STP, it's shielded. So let's radio interference leak out, but it's more expensive. And there are three basic variations of Ethernet, 10 megabit Ethernet. This uses a 20 megahertz clock, 100 megabit Ethernet. This uses 125 megahertz clock and one gigabit Ethernet, which uses also a 125 megahertz clock, but it uses a different encoding and four pairs simultaneously. And Ethernet devices offer a split into two parts. One is the MAC part, which is the device that produces the Ethernet bitstream. And the other is the PHY, which is the thing that interfaces this bitstream to the physical layer, like to the copper cable or fiber optics or whatever. And there is a standardized interface between these two parts, which is called MII, media independent interface. And for one gigabit, there are three types of MIIs. One is GMII. The clock is for 10 megabits is two and a half megahertz. The clock for 100 megabits is 25 megahertz. And the clock for gigabit is also is 125 megahertz. There is also RGMII, which is a reduced pin count version. The clocks are the same. And there is also SGMII, which always uses a 625 megahertz clock. And the Raspberry Pi, which we'll be using in our experiments, has an RGMII interface. So let's try it. Now Ether is a term which was associated with radio. It was this imaginary medium that enabled electromagnetic waves to propagate, which physicists were trying to find in the 19th century. So Ethernet is wired, but maybe we could put some Ether into it and it will be wireless again. So let's try some simple modulation, changing the speed via ETH tool. So we'll assume that bit one is 100 megabits, zero is transmitted by setting 10 megabits. And for encoding, we'll use Morse code for several reasons, because first, it's easy to judge the signal to noise ratio by ear. Also it is easy to decode it by ear if somebody knows Morse code and it's much better than software decoders. And also it has some additional hack value. And to reproduce this demo, I used two Raspberry Pi 4s, because it's hardware that anybody can get. If I used some other hardware, then people would have problems reproducing it. And I made a primitive implementation as a shell script. So let's try to change the speed, try to receive a signal at the harmonics of the fgmii clock. And the result was quite surprising, because I was able to receive it at 100 meters. So that's really, really a lot, because most tempest demos work for meters or even centimeters. So let's have a demo. We have two Raspberry Pi's, our tempest receiver on the right. And one of the Raspberry Pi's is running a script that will be exfiltrating some data from it. Okay, so we're logging into one of the Raspberry Pi's via a serial port. We have a gigabit link between these devices, and we will set it to 10 megabits and no auto negotiation. Please listen closely to the audio, okay, and now 100 megabits, oh, and we have a signal. So every time a radio amateur has a device that can produce a beep, he will just try to send Morse code with it, right? Again, turned off, turned on, quite readable signal. This is at 5 meters, by the way. But there is a lot of interference, because this was in an area with a lot of internet. Okay, so we're now exfiltrating the contents of the Fiosecret1.txt. You can hear the nice Morse code, and for the people that do not know Morse code, there is a Morse code decoder here, and the message is HelloRC3. So we've successfully exfiltrated more data from an unconnected Raspberry Pi, not connected to the internet. We exfiltrated it via radio at a distance of 5 meters. So let's try a different type of modulation. Let's leave the interface at 10 gigabits, but let's flood it with data. And for simplicity, we'll just use the flood ping. And there is, of course, the encoding is still Morse code, and there is a primitive implementation also as a shell script. And we will be also receiving a harmonics of the fgmii clock. I found out that 500 MHz is the best frequency for this demo, and I could achieve reception at 30 meters. So this is also quite distant. So this is our demo again. This time one of the Raspberry Pis has a script which will flood the network with packets. So let's try it. As you see, we have a 1 gigabit link between the devices. The receiver is set to 500 MHz. And listen closely, there was a short beep, right? Try it again. Okay, we can retransmit something, so let's exfiltrate data. This time the file is secret2.txt. You can hear the Morse code. The signal drifts out, but it is readable by ear without problems. This decoder is not very good, but okay, it's decoding also. And the secret message is start2d world. So we have successfully exfiltrated data by flooding the network with packets. Okay. So I was researching this phenomenon, and by accident I didn't plug a cable in. And surprisingly, I was still able to receive a signal from the Raspberry Pi. And it turns out that if I put a Raspberry Pi at my balcony at home, I am able to receive it at 50 meters, which is really a lot. Still an unconnected device, no Ethernet cable. So the Raspberry Pi 4 really generates a lot of interference, or at least the units that I have. I would have to try it on another batch. And unfortunately, this makes EtherFi 1 and 2 less spectacular. So oops, right? But Raspberry Pi's are probably quite representative of other embedded devices. So this probably also happens in other embedded devices, however I haven't checked. So let's have a demo. We have a single unconnected Raspberry Pi. There's no Ethernet cable connected to it. It runs a shell script. Okay. So no Ethernet link, and we will set the speed to 10 megabits, and now to 1 gigabit. Very nice signal. Right? At 375 MHz. So let's exfiltrate data. This time in secret3.txt. Very nice. Good signal, and the message is Raspberry Pi's dirty little secret. Okay, so this is, we can see that Raspberry Pi's are quite unique. Maybe we could try some other device. And so I made EtherFi 4. It was that I tried to implement EtherFi 1 and 2 on different hardware, and in this case it was Dell laptops. I have 2 Dell laptops which I know that they don't produce a lot of electromagnetic interference. So they're quite good in this respect. Unfortunately, most Ethernet hardware brings the link up after several seconds. They're changing the speed. So this is bad for transmitting regular Mars code. But we can do something which radio amateurs call QRSS CW, which just means very, very slow Mars code. And this is Mars code which has the length of the dot in their order of several seconds. And as usual we'll receive a harmonics of 125 MHz. And we will decode the Mars code visually from a slow spectrogram. And at the bottom of this slide you see that changing the interface speed changes the sum clock. When it's 10 Mb, it has a higher frequency and tends to drift upward. While when it's 100 Mb, it tends to drift downward and has a lower frequency. At least this is how it works in these 2 Dell laptops. And you can see the dot, dash, 4 dots and so on on the spectrogram. So let's have a demo again, 2 laptops connected via Ethernet. One of the laptops has a script that will exfiltrate some data from it. So you can see the spectrogram. The audio from the SDR receiver is fed into a program called SpectrumLab, which does a very slow spectrogram of the sound. So over here you see a dot, then a dash, 4 dots, which is E, T, H and so on. This demo sends the word Etherify. And you can see that the data transmission speed is very slow, but it is possible to exfiltrate data. And this demo was done at a distance of about 3 meters. So if we are able to transmit on normal hardware, maybe we could try it on something else, maybe on networking equipment, which is quite interesting. So I took two links, one gigabit switches and connected them via an Ethernet cable and made a small script to change the speed via SNMP. And as usual, you'll listen to harmonics of the LG MIA clock. In this demo I found that 50 MHz is the best frequency to listen to this signal. And on the bottom of this slide, you can see the signal. This was received at a distance of about 5 meters. So you have a dot, dash, 4 dots, dot. So it just sends the word Etherify again. And these switches behave quite differently from the laptop, right? It's just different hardware, you don't see this drift over here and so on. So let's have a demo. Two switches linked via an Ethernet cable and some workstation that has a script that will change this uplink speed via SNMP. This time the receiver is tuned to 50 MHz, the speed is set to either 10 MHz or 100 MHz. And the signal is present when it is set to 100 MHz. So as you see, the signal, the data rate is also very slow. But it is possible to send exfiltrate some data. And I promise I will try it on a different device. This can also be implemented via scripting facilities in switches. For example, Cisco switches have a TCL interpreter in it. OK, so enough of radio. Initially, this was supposed to be a collection of soft tempest demos, showing how to exfiltrate data via different channels. Unfortunately, I got too focused on radio because I like radio. But I did a quick hack to transmit data via ultrasound. This is absolutely nothing new. But I just wanted to find what distance I could achieve. So and I named this Sonify. The implementation again is as a simple shell script. The sound is transmitted via the laptop speakers from one of the laptops. And received via the internal microphone in another laptop. Now the hearing range of humans is up to 20 kHz. And this is really rare that somebody can really hear 20 kHz. Usually it's more like 16 kHz. And the sound card in most laptops has a sampling rate of at least 48 kHz. So that means that it is possible to produce a signal of a frequency of up to 24 kHz, or half of the sampling rate. So we can use the whole sound spectrum from the top of the human hearing range, or 20 kHz, up to 24 kHz, to transmit data. And I've had a very good result at 21.5 kHz. This was just arbitrarily picked frequency. I could receive a clear signal at 20 meters. Now this can be extended with an ultrasound directional microphone. But even the internal microphone in the laptop works really good. So let's have a demo again. One laptop transmits sound to the other laptop via ultrasound. This is by the way nothing spectacular. It has been demonstrated multiple times. Maybe not with Mars code, but with other technologies. OK, so this is the audio spectrum. And we'll be exfiltrating data from one of these laptops. And the receiving laptop is at 20 meters distance. This program, which is running right now, which is called Spectrum Lab, also written by a radio amateur, shows the spectrum and also converts the 21.5 kHz sound into 650 Hz so that we can hear it by ear. And we can see that the decoder is struggling with receiving this signal. OK, but right now it got a decode, right? So the message is Ultra RC3 Sound. So we have successfully exfiltrated data via ultrasound. This is still a work in progress. I'll have to test the Ethernet, the Etherify demos and other hardware. Also I'll have to look at the data encoding because it is possible to influence the spectrum of the transmitted radio signal by changing the data which is sent. And there is a demo which does this. It's called ESP-Thernet. It's an implementation of Ethernet on an ESP32 processor. And this is not real Ethernet hardware. It's just an implementation using the processor spin pins. And in this demo, because Ethernet is 10 megabit, Ethernet is Manchester encoded. So if you send a data containing all zeros, it will send an Ether alternating stream. And if you send a data containing only containing 10101010, it will be the Manchester encoding encoded in a different way. So one other thing I would like to look like is the networking interfaces. And especially the Intel E1000 network card because it's present in most laptops that I have. And it has some registers that set PLL settings, clock frequencies. I haven't even locked into it, but it's probably possible to change some frequency or do some modulation with it. And also I'd like to implement some other soft tempos demos, like optical, and of course keep them as primitive as possible so that people can reproduce it easily. So try it yourself. Get a cheap SDR dongle. If you still don't have one, there's absolutely no reason not to have one. Buy it. It's really cheap. And try one of these demos. And also remember that these demos are deliberately as primitive as possible. So it's easy to understand them and it's easy to reproduce them. This is just a fun demo. It's not a military data exfiltration exercise. If an adversary would like to do it, he will probably do it in a much more advanced manner. Also read the literature. It's a lot of fun. And if there are any questions, I'd really like to answer them. Thank you very much for listening. OK, thank you, Jacek, for that talk. We are a bit over time, but we may squeeze in a few of the questions. One question we've got is, which component of the Raspberry was actually emitting the signal if it wasn't the cable? I don't know for sure, but it's probably the RGMI interface. But I must say that the signal is surprisingly strong and I have a YouTube video with absolutely nothing connected to the Raspberry Pi, only a power bank. And I'm still able to receive the signal at 50 meters. So it's really a surprisingly strong signal. But I think it's the RGMI clock. So the lines between the Broadcom chip and the Pi. And another question, did you try the flapping method on another device than the Raspberry? Yes, I have. This is a work in progress and some things are still not documented. I will be publishing them. And the first experiment was with unshielded cables. Do shielded cables make much of a difference here? Yes and no, because in the case of the Raspberry Pi, we can see that actually it's not the cable, it's the Raspberry Pi that does the radiating. So it doesn't make, because obviously I've done such a test, and it doesn't make as much of a difference. However, with normal hardware, like with laptops or with switches, it does make a difference, quite a difference. But I'm still able to receive it, but just the distance is not that large. And our question that just came in, I guess you tested this under idle conditions. How well does it work under real-life, busy conditions if there are other applications running? Well, with switching speed, it's not a problem, because it's just the speed that changes. This might be a problem for the applications because it disrupts the communication for a while. But in case where I modulate the bandwidth, I mean the traffic, like the flood pink, it depends on how much the applications generate, how much traffic the applications generate. So for example, if I have an application that uses one megabit of traffic and all of a sudden I start using 100 megabits of traffic, this will be detectable without problems. And another more general question, as a total beginner on high-frequency stuff, could you give any advice on how to analyze the obtained signals, for example, which programs there are and what can help, for example, generating visualizations? Yes. First of all, get the television dongle, the DVBT dongle. It's really, really cheap, and there is no excuse for not having it. Any software-defined receiver. So for example, in Linux there is GQRX, which I'm using in these demos. And for analyzing the audio further, for example, showing the slow spectrum, I use a program which is called SpectrumLab. But this is an answer which is only pertaining to this presentation, but a more general answer would be to try software like Universal Radio Hacker or stuff like that if you're trying to, for example, analyze, I don't know, remote controls or stuff like that. There's really a lot of material. But first, try just a simple software-defined receiver like GQRX or DRSharp or something like that. OK, thank you for your talk and for being here to answer the question. The Signal Angel just wrote that there was much applause from the chat inbound with an exclamation mark, which I think is well deserved. Thank you again. OK, thank you very much. And it was an honor to present at this conference.