 All right. Hello and welcome, everybody, to our talk, Tatra Tour de Force, jail-baking digital radios and base stations for fun and secrets. I'm very excited to stand here today and share this research with you after working on it for more than two years. My name is Jos Wetzels and these are my colleagues, Carla Meijer and Wouter Boxlock, and together we form Midnight Blue, a specialist security consultancy firm that specializes mainly in embedded systems as well as critical infrastructure. So, a little bit about Tatra. What is Tatra? It's a globally used radio technology that competes with the likes of P25, which you might know from being used by the United States police. DMR and the confusingly named Tatrapool was standardized in 1995 by Etsy, that's the European Telecommunications Standards Institute, and they are known for also doing work on GSM, 3G, 4G and so on. It's used for voice and data communications, as well as machine-to-machine communications, and it relies on secret proprietary cryptography. That's why we're standing here today. So, it's the vast majority of global police forces outside of the United States and France use Tatra for their voice communications. And this is countries like the Netherlands and Germany and the United Kingdom, but also Scandinavian countries, Eastern Europe, large parts of Asia and South America use this. In addition, it's used in military and intelligence services context. Now, the countries that you see highlighted on the map here are the ones where we could conform military or intelligence users through open source intelligence, but this is likely the tip of the iceberg, so there might be many more countries out there that use it in this capacity. And on top of that, it's used by critical infrastructure. So, if you see private security forces at airports, harbors and train stations, there's a good chance that their handheld radios are Tatra-based. And on top of that, it's also used as a radio link for wide area networks carrying SCADA communications in order to do telecontrol and telemetry of high-voltage substations, oil and gas pipelines, as well as railway signaling. So, serious stuff. Now, a common misconception is that Tatra is an open standard, but that's not true. Some parts of the standard are public, but the cryptography within it is secret. And it's only available to you if you sign an NDA, and I mean, in that case, you can't talk about it, and you're only allowed to sign an NDA if you are what they call a bona fide party. And these bona fide parties are usually manufacturers, and these manufacturers have to ensure that the algorithms are protected either by implementing them in hardware or implementing them in software with extraction countermeasures. Now, the first problem already is that there are lots of these bona fide vendors, and they are geographically dispersed. So, every major country in the world essentially has a domestic Tatra manufacturer. That's the United States, the United Kingdom, China, Russia. So, you can feel that top-tier adversaries likely already have these specifications of these algorithms, either through their in-country manufacturers, or through just getting them from a share point somewhere at a manufacturer. We, however, had to jump through a lot more hoops in this case. So, Tatra Security has two main pillars, the first of which is the TAA1 suite, which is the authentication, key management, and distribution suite. It's also used for identity encryption. The second suite is the Tatra Encryption Algorithm suite, which is used for voice and data encryption through the Air Interface Encryption functionality. And this has four different flavors. The first of which is TA1, which is readily exportable. Then you have TA2, which is restricted in its use to European public safety organizations. Then you have TA3, which is used for extra European public safety for those countries that are friendly relationships with the European Union. And then you have TA4, which is the same use case as TA1, but it's hardly used in practice. Optionally, there are Tatra end-to-end solutions available, but these are only used by some countries and only in special cases, in most of the cases. So, think about special intervention units, counterintelligence observation units. It's not a part of the Tatra standard. There are some guidelines around it, but it's a vendor-specific proprietary solution that you bolt on top of the Air Interface Encryption. It's expensive and, again, very opaque as well. It hasn't been looked into yet. So, with this in mind, we undertook Project RETATRA, which was the project to reverse engineer these algorithms. And you can find all the details about this on this particular URL. We undertook this with Karkov's principle in mind now. I probably don't have to explain to you guys what Karkov's principle is, but I'm still going to anyway. It says that a crypto system should be secure even if everything about the system, except for the key, is public knowledge. So, no security through obscurity, right? Violators of this principle have historically not done well. If you look at the history of standards like GSM, GMR, GPRS, all Etsy standards, by the way, their secret cryptographic algorithms either turned out to be broken or backdoor. And we had the suspicion that this might be the case for TETRA as well. But in more than 20 years, nobody had looked at this publicly. Now, Etsy thinks very differently about this. In an interview with the journalist Kim Zetter, Brian Murgatroyd, who's the chairman of the Etsy Technical Committee on TETRA, said, well, obscurity is also a way of maintaining security. Well, let's see if that's actually the case. So, the project was undertaken with funding from NLNet, which is a Dutch nonprofit organization that hands out money for open source initiatives. And they kindly supplied us with some money to undertake this research. And now we can talk about TETRA for the first time in public. So, let's break open a radio. Well, before we could break open a radio and see what's going on inside, we did a little bit of analysis first, because you want to select the right kind of target, because if you select a radio that is harder to reverse engineer, you might end up spending a lot of time on that end. So, we did some analysis of the internal architectures of different kind of radios from different vendors by looking through the different data sheets. And here you can see that, well, there's a variety of architectures, some of which are quite esoteric, but also they implement different kind of security features. Like, certain radios will implement hardware-based ASICs that likely include the algorithms. And we don't want to spend a lot of time with assets and scanning electron microscopes. So, we went for the one that has a trusted execution environment in software. And that turned out to be the Motorola MTM 5400. This is a very common model. It's easily obtained secondhand online on eBay. And it has a baseband system on chip that is by a manufacturer that is not Motorola, but by Texas Instruments. And this likely hints at the fact that there's no hardware implementation of these algorithms inside. Also, this ASOC has software security features, and that are very suited for likely protecting this tetra-crypto from extraction. Now, the architecture of the radio looks like something you see on the right of the slide. So, if you have the radio, you have a control head, which is where the microphone, the keyboard, and the field configuration is. Then on the back of the radio, you have a rear connector, which you use for depot programming, for configuring the radio, doing firmer updates, and so on. And then inside, you have the baseband chip. And the baseband chip, in this case the Freon baseband, is based on the OMAP L138 architecture by Texas Instruments, which has a ARM core for the high level stuff, and a digital signals processor for, well, processing the signals. And then inside the DSP, you have a trusted execution environment that likely includes our magic sauce. So, this OMAP L138, like I mentioned, it has an ARM core, but it also has a DSP core that is based on a flavor of the TMS 3 Gen 3 DSP architecture. There's very limited reversing tooling available for this particular flavor, so we had to build a lot of our own. And the DSP features an orthogonal security model. So you have a separation between the regular user and supervisor mode, but you also have a separation between secure and non-secure mode. And if you look at the supervisor secure mode, that is likely where a lot of the interesting stuff is located. First thing we did is we bought a development kit for this architecture, it was relatively low cost. Unfortunately, this didn't come with the secure version of the chip, so we couldn't analyze it on a development board. However, it's useful for reversing, debugging, testing your shell code and so on. Now, we wanted to confirm our assumptions, so we opened up the radio and we saw that all the main board was covered with shields. So in order to see, you know, what kind of chip is exactly used, we took a rotary saw, we sawed off these shields, and we found out that, yes, it is indeed this particular chip with the secure flavor. Then we took a look at the firmware. The firmware comes as an RPK package, and the RPK package, well, it's essentially a zip archive, and inside the zip archive, there's an encrypted Z 19 file. So, you know, these firmwares are not personalized, they don't differ from radio to radio, they're general, and the engineering software needs to have a way to load this firmware onto these radios, so likely it knows the passwords to these encrypted files. It's written in .NET, so it's very easy reverse engineering with a little bit of effort, you get it to passwords, which are static. So then you're able to extract the zip archive, you get the Z 19 file, you decrypted with one password, then you get the S 19 files, you decrypt those with the second password, and then you have what you're actually looking for, which is the file system of the application processor and the DSP firmware. So is this trusted execution environment actually used for the Tetra algorithms? Well, there's no proper DSP reversing tooling yet, so how do we find this out? We'll be doing the entropic analysis of the DSP firmware, so you can see on the left of the slide that in a particular area within the DSP firmware, there's a very high entropy area, which likely indicates encrypted data, and then you can see the cross references in the code to this particular area correspond with API call invocations of this particular secure kernel API. So, delving into a little bit more detail will be my colleague, Carlo Mayer, who will take you on the rest of the journey. All right, so now that we have a pretty good idea of where to go, let's break a TE. So the first thing we have to do is get code execution, obviously, on the application processor, and we identified three possible angles, the first one being the modem AT command interface, the second being modifying the NAND flash, and the third one being targeting some peripheral interface, for example, like the DPS module or what have you. After that, we'd have to move from the ARM core towards the DSP through either direct memory access or through some DSP link library, which is the library used to pass messages back and forth from the ARM core to the DSP and vice versa. And finally, once we obtain code execution on DSP, we'd have to find either a vulnerability or a side channel flaw in the trusted execution environment. So this is basically the same thing, but then presented in a nicer way. Okay, so the MTM radio has a rear connector that exposes the AT modem command interface. With this interface, you can read, write parameters, for example. Analyzing the firmware gave us a list of commands, and we immediately started looking for those with string parsing or variable length handling. The commands used to set a talk group list entry and subsequently enumerate them. We found a classic format string vulnerability, which allows us to write arbitrary data to any pointer that's listed on the stack. So on the slide on the right, you see our user input that contains %p, and on the bottom you see it interpreted as a format string. So this is a classic vulnerability. So this means that if we can write anything that we'd like to anything that's listed onto the stack, so if we can influence what's on the stack, we have a write anything anywhere primitive. Unfortunately, we don't. So how do we go about that? So luckily, there's frame pointers in this firmware. Frame pointers have the nice property that each frame pointer points to the next frame pointer. So in this particular example, let's say that argument 55, that one contains a memory address, and it points to argument 59, which in turn points to argument 71. Now, suppose that you write, let's say, 0x80 to argument 55, that will update argument 59, and in this particular example, it will now not point to argument 79, but it will point to byte 0 of argument, not point to argument 71, but in this particular example, it will point to the byte 0 of argument 79. All right, so now if we write anything to argument 59, it will update byte 0 of argument 79. Then we go back and we update, then we write something to argument 55 again, for example, 0x81, and therefore argument 59 now points to byte 1 of argument 79, and this way, by continuing this route, we end up being argument number 79 being completely malleable by us. We completely control its value, and this way, we have a pointer on the stack that we completely control, and therefore we have a write anything anywhere primitive. Good. So it turns out that the heap actually has read, write, and execute permissions. So the next steps would be just to write our shell code onto the heap, overwrite some pointer that points to executable code, and then trigger execution of that pointer, and boom. So that got us a shell on the application processor. So the next step is to move on to the DSP. So to recap, this means exploiting vulnerability in this communication library called DSP link, or exploit some misconfiguration in the MPU's configuration. Right. So this thing contains two cores that need to communicate somehow, and they do this by having shared internal RAM and some external DDR2 memory, and this could present an interesting avenue for lateral movement via direct memory access. So now the SOC has, in question, has memory protection features, which allow for the segmentation of memory areas between cores and within cores. So the plan would be to dump the MPU configuration and then find a range that's used by both the DSP and the application processor, and then identify and exploit an interface that uses this shared memory range, such as DSP link, that's used in order to pass messages back and forth. So when we dumped the configuration, we saw that there is essentially no segmentation applied whatsoever. So basically this MPU poses zero problems for us. Like getting code execution on the DSP is as straightforward as just modifying parts of the DSP firmware in RAM. So the next thing we did is we implemented a framework for running code on the DSP. We wrote multiple application processor kernel modules which hijacks DSP control by allocating shared memory, copying our payload over into the shared memory, and then redirect DSP execution to our code, meanwhile ensuring that the watchdog, which is a hardware peripheral, was periodically kicked in order to prevent the board from resetting. So all of this was kind of complicated by the fact that the DSP architecture is pretty hellish. It has delayed branches, variable degrees of concurrences, lots of conditionals, and very limited IDA support. So we had to implement our own disassembler. And on top of that, we also added support for the architecture to the Reddeck decompiler. And both will be upstreamed in the course of the next few weeks. As you can see, the decompiler output reads a lot nicer than the disassembler. All right. And with that, we had reliable DSP code execution. So onto the final step, attacking the TE. So at first, we got our hands on a chip whisperer to do some power side channel analysis. However, it quickly turned out that it wasn't the easiest route at all. We had to find clock lines on the PCB. We then find the DSP power line, decrease the DSP core clock speed, correlate measurements to the key, et cetera, et cetera, which turned out to be a nightmare. And we were quite sure that we were going to break the board this way. So we took a step back and we looked at maybe we have other options here. So it turns out that the TE is implemented in ROM by a subsystem called the SecureCurnal. This code runs in DSP secure mode and all non-secure code can do is perform a SecureCurnal API call, which is very similar to a syscall on a regular PC. So there's this thing called SK load, which is an API call which allows for runtime loading of encrypted modules. For example, our Tetra module, which contains the Tetra algorithms. And it then decrypts this module with AES and validates them using RSA and then loads them into the trusted execution environment where they're invisible in non-secure mode. Then if you're back into non-secure mode, you can invoke one of these algorithms through SKAlgoInvoke, which allows non-secure code to invoke these algorithms and get the result from one of these functions that was previously loaded. And these modules are encrypted with a customer encryption key. So that's a factory set key. In this case, that key belongs to Motorola. So now for our tech, we got some inspiration. Modern computers use caches to speed up memory accesses. And this introduces some timing differences during lookups. And this in turn may leak some information on secrets involved. So in 2005 already, Daniel Bernstein wrote an interesting paper on performing such attacks on AES, where you build a profile of timing differences and then you observe the target system characteristics. You correlate these with the observation and then you derive which key fits best. Right. So for the DSP, we are targeting, it has several caches. You have a level one data cache, you have a level one code cache, and you have a level two cache. The level one data cache has a 64 byte line where memory reads are fast and data that is already, for data that's already cached. And otherwise it's slow. So we can evict addresses from cache in this 64 byte granularity. And it turns out that doing so from non-secure mode also affects secure portions from the address space that you cannot usually read from non-secure mode. Furthermore, there's a feature called a cache freeze, which basically means the cache is turned into read only state, which means that whenever you get a cache hit, you get a performance increase. Whenever you get a cache miss, you have to fetch it from main memory, but the cache isn't updated. So now that we have some control over the cache, which AS decryption step should we target? Well, it turns out that inverse sub bytes, decrypting AS, so inverse sub bytes, uses an S-box. And that means a memory lookup, so we should probably target that. The thing is, this S-box is located in some page in ROM, but it's not readable from non-secure mode, so we don't really know where the S-box is. So first thing we have to figure out is figure out where the S-box is. So what we did is we start by evicting the first cache line, so the first 64 bytes of this ROM, invoke skload, and then measure the time it took to run that code in terms of clock cycles, and then we do so for the second cache line, and then the next answer forth, and eventually we plot this. So we get something like this. So it seems quite obvious the S-box is right over there. Okay, so let's look a bit deeper. We're going to prepare the cache as follows. We run skload so that the full S-box will be in cache, and then we evict the first 32 entries. So this is what we refer to as the first octant, because it's one-eighth of the S-box, and then we enable this cache freeze feature. And now, whenever a timing penalty occurs, we know that this happens due to the first octant of the S-box being hit. So we'll assume this setup for the remainder of the presentation. So having evicted the first octant of the S-box from cache, we set CT zero, so that's the first ciphertext byte that we provide to skload. We set it to zero, and we randomize the remainder of the ciphertext, and we measure average running times of skload, and then we repeat that for other values of CT zero as well, and then we plot the results. So again, we set the first ciphertext byte to zero, we randomize the remainder, and we get the average running time of skload. So that thing, now our controlled value gets put through the S-box. So when we plot that, we get something like this, which is quite interesting. So we know by construction that the penalty is observed when our ciphertext byte x or a round-key byte is less than 32. And in the above example, we find that this leaks some information about the round-key byte. So in this particular case, the round-key byte is located somewhere between 32 and 64. So that's great. We effectively leaked three bits of this round-key byte, so we repeat the same thing for the remaining 15 round-key bytes. We obtain a total of 48 bits of round-key. However, this approach is inherently limited, because after all, the other five bits of the round-key do not influence which S-box octant is hit, and therefore we cannot leak those. And there's still 80 bits left to brute force, so that's not really viable approach either. So we have to dive in even deeper. So suppose that we, instead of attacking the first S-box lookup, let's look at the second S-box lookup. So round one S-box lookup has introduced some diffusion within the state byte. So this now means that the least significant bits of this byte actually do influence which octant is hit during the S-box lookup. So we now have to account for shifting of the state bytes, the influence of the next round-key, and the diffusion of mixed column step, which was a step that's taken in between. And then we can extend our attack. And I won't go into further details because this probably goes, if I would explain to myself, it would go way beyond my head. So I'll just demonstrate it. All right, so this is right after we got a shell on the radio, on the arm core. So this is loading a kernel module that kicks the watchdog. Now we hijack code execution on the DSP. And next thing we do is run the side channel attack. So this is the full thing. I'm showing you this because we optimize it such that it's stupidly fast. So this only takes a minute and then it gives you the key. So all the bytes in between that you see, those are round-key bytes. And there we go. That's the key. Now, clearly this isn't the actual Motorola key. It's just a mock-up. Right. Of course, it wouldn't be fair if there weren't even more hurdles for us to jump over. So it turned out there was an additional encryption layer for which we had to adapt the attack to. Then there was an additional obfuscation layer which stumped us for a bit. But once we observed similarities between the loaded modules, it turns out that the obfuscation was just a rolling XOR that incrementally calculated a checksum. And with that, we could now extract the customer encryption key in less than a minute. We reverse engineered the remainder of the module format, decrypted our target module, reverse engineered it, and finally got the secret algorithms. So a little recap for the journey so far. We found the format string vulnerability in the AT interface on the real connector of the radio to get us code execution on the baseband's application processor. We then jumped to the DSP via shared memory, exploited the cache timing side channel on the DE of the DSP to extract your secret algos. And now we have them. All right. So that brings us to the point that we can actually start doing what we wanted to do. And that is analyze the cryptographic primitives underpinning the security of Tetra. And is this better? All right. So we can now finally start doing what we came here for. And that is analyze the security of Tetra. All the primitives are, by the way, public now, so you can get them off GitHub if you want to take a look at it for yourselves. I will start by explaining some things and explain some vulnerabilities that we found. So what you see here is how this authentication is shown in the standards. You see some boxes, TA11, TA22, and those are like black boxes. They don't tell you how it works. We are now able to actually inspect how these things are implemented. And we saw that all the primitives that are marked TA something are based on a proprietary cipher named hurdle. It's a 16-round fysol cipher which uses 64-bit blocks and a 128-bit key. And the primitives based on Tb are based on very simple XOR and addition operations. Also interestingly, we found that some of these blocks are identical or highly related and that will help us later. So this is an overview of a part of hurdle. Hurdle has an f-function that combines half of the states, so 32 bits, with 96 bits of round key information. And it has this really extensive cascading structure. So it's quite interesting to look at and I'm looking really forward to some professional cryptanalog analytical insights. We could not break it. We could, however, find the function that originally generated the S-box. It's based on the Nyberg S-box just like AES. But, yeah, we didn't get any further with this. So we hope some of you guys maybe want to look into this. We will discuss, however, an attack we found on this authentication scheme. What you see here is how the mobile station and the infrastructure perform mutual authentication. So they generate some random numbers and through cryptographic dance, they prove knowledge of a shared secret key. And if this authentication succeeds, it will also yield a session key, the DCK. And below, on the bottom of this slide, you see how this DCK is constructed in terms of these primitives. Now that we have obtained these primitives, we can do some simplification. We found that TA-21 is actually identical to TA-11, except that the RS, the random seed supplied by the infrastructure, has a reversed byte order. Additionally, TA-22 is actually identical to TA-12. And the TB-4 function is nothing more than an XOR. So the session key is generated by XORing together two half session keys that were generated previously. Now, this is interesting because this allows for an attack. Let's assume that we impersonate the infrastructure and we target a mobile station. Additionally, let's assume that we can predict the random number that is being generated by the mobile station. This may seem like a bit of a stretch, but in embedded systems, random number generation is really hard and quite often not fully unpredictable. So this may be more feasible than you might initially think. We can provide the mobile station with an RS, a random seed, that is a palindrome. So it's identical in the reverse byte order as in the forward byte order. And if we do all that, then we can simplify the DCK derivation formula to something that has the same on the left and on the right side of the XOR operation. And by nature of the XOR function, we end up with a zero key. So what we have achieved in this case is an authenticated channel with a mobile station with a known session key of all zeros without even having knowledge of the original shared secret key. So next, let's talk about identity encryption. Identity encryption in Tetra is implemented in a primitive called TA61. And this is used to encrypt 24-bit Tetra addresses, which you can compare to a phone number if you want. And these encrypted addresses are used for a while until a certain network is changed. This won't happen very often, maybe every few weeks or so. So Tetra doesn't offer strong anonymity, but pseudonymity nonetheless. At this point, unfortunately, we cannot disclose the implementation of TA61 due to some serious concerns from Tetra stakeholders. We will publish them in December. But at this point, at least we can share with you the outline of an attack so that we can have an informed discussion on the security of this primitive. And the attack looks as follows. The CCK network key is first being used in a hurdle encryption in order to generate a 64-bit intermediate secret, which is shown here as C. And only then this intermediate secret is used in order to encrypt this 24-bit identity. And this happens in a weird two-round lightweight crypto scheme. And this is vulnerable to a meet-in-the-middle attack. As an attacker, we can try to gather a few pairs of unencrypted identities together with their encrypted equivalent and start computing forward from the unencrypted one and backwards from the encrypted one and see at the meeting point which guess for the intermediate secret C would make sense. And this attack has a complexity of 2 to the 48th with which a regular laptop runs in about a minute. And after you have computed this value of C, you can instantly de-anonymize anything that comes past on the air interface. Also, it gives you an option to attack a hurdle encryption because you have C, which is the output of a hurdle encryption. And if you can somehow break that encryption and derive what the original CCK was, there is a very, very serious problem for Tetra. So that's also something to investigate in the future. Now de-anonymization can be quite serious depending on the use case of a Tetra network. Tetra identities are typically distributed in ranges. So regular police forces will get one range while intervention teams get another range and firefighters will get yet another range. So as an attacker, if you invest some efforts into identifying which ranges belong to which kind of services, you can have a very interesting intelligence position. This can be used for instance in a counter-intelligence context when you may be able to notice when covert surveillance units are near you all the time. Or it can serve as an early warning for organized crime when intervention teams seem to pile up somewhere in the vicinity. The attack is fully passive and can be executed with very cheap hardware. So it's very realistic that this can be done. Right. So let's talk about the actual encryption algorithms. In Tetra, traffic is encrypted with one of four key stream generators, as Yos pointed out previously. And we found that all of them share a very similar structure. And depicted here is TA2. On the top, you see the key register, an 80-bit register that provides information to the state register below and eventually the state register will output key stream, which is then used for encryption of Tetra traffic. To us, TA2 looks robust, but we are not cryptographers and more public scrutiny is needed before we can finally decide that this is all good and safe to use. But this is where it gets real interesting because we found a backdoor in the TA1 cipher. TA1 is intended for private use cases, commercial use cases like private security, but it's also been distributed to, like, say, less friendly police and military forces that Europe did not have very good footing with at the time these networks were originally conceived. TA1 is advertised as having an 80-bit key, but the first thing it does is apply a secret reduction step that compresses this 80-bit key into a 32-bit register. And from then on, it will only use this 32-bit register for the generation of key stream. So, obviously, this is trivial to attack nowadays. You will be able to crack such a key in a minute and get a key that works for decryption of all traffic on that frequency. Additionally, you could decide to actually start injecting traffic, which is especially worrisome when Tetra is used in a data-carrying capacity such as SCADA-1 telecontrol kind of traffic. So, small demonstration. Room and Night Blue, a specialist security consultancy firm. In this video, we're going to demonstrate a proof-of-concept attack from the Tetra-Burst vulnerabilities recently uncovered by our team. Terrestrial Trunk Radio, or Tetra, is a radio communication standard used globally by law enforcement, emergency services, military operators, private security, and harbor and airport personnel. In addition, Tetra is used in a wide-area network-carrying capacity for SCADA-telecontrol of oil and gas pipelines, electrical substations, water management, and even railway signaling. Tetra offers confidential communication guaranteed through its so-called air-interface encryption feature. This feature encrypts Tetra traffic by means of one of four proprietary stream ciphers, TEA-1, TEA-2, TEA-3, and TEA-4 Of these ciphers, TEA-1 can be exported globally for the appropriate export approval and can be used by both commercial and government parties. As such, TEA-1 is used to protect select law enforcement, military and private security radio communications, as well as SCADA radio links of global critical infrastructure. Tetra is used in many different sectors, ranging from electrical and water utilities to oil and gas, transport, and mining. Since the Tetra encryption algorithms have been kept secret for over 20 years, their security has never been properly publicly evaluated. Until now, Midnight Blue researchers have reverse engineered the algorithms and uncovered several vulnerabilities in Tetra, including a back door in the TEA-1 algorithm, which reduces its advertised key strength of 80 bits to a mere 32 bits. This back door, which has festered in global critical infrastructure for decades, enables the interception and manipulation of TEA-1 protected Tetra communications from anywhere within cell tower coverage, which may be up to tens of kilometers. Due to the simplicity of the back door, even attackers with limited resources, such as a $10 radio dongle, can crack TEA-1 keys in a matter of minutes. In this demonstration, carried out on a real network, the attacker captures traffic and identifies messages on which to mount the attack. Now, the attacker computes the key used on this frequency. This will take about a minute. Once the key has been cracked, voice communications can be intercepted while the attacker remains fully undetected or if data can be actively injected. In the case of SCADA telecontrol communications being carried over Tetra-wide area networks, attackers could use this vulnerability to obtain direct access deep within the operational technology networks of critical infrastructure, allowing them to intercept and manipulate network traffic controlling equipment like switchgear, circuit breakers, and valves at electrical substations or oil and gas pipelines. Due to the highly sensitive nature of the uncovered issues, Midnight Blue has spent more than one and a half years in a carefully coordinated disclosure process with multiple government and industry stakeholders guided by the Dutch government's National Cyber Security Center. During this process, detailed... Thank you. Awesome, thank you. So, with a small recap and demonstration video, I think we made a point, right? Well, Etsy has some interesting things to say about this. First, they claim that we are using a very high-powered graphics card in order to be able to attack this. Well, in my opinion, a 2016 consumer-grade graphics card is not that high-end, but, hey, opinions may differ. Also, they state that 25 years ago when Tetra was standardized, 32 bits of key entropy was probably sufficient to withstand attack. And they state that you need some pretty reasonable equipment in order to be able to attack TEA-1. Now, I don't think I have to explain to you that this... Now, I don't think that I have to explain to you guys. Thank you. That this just doesn't make sense. But, yeah, you know, why would we make any assumptions on this? Why would we use reasonable equipment in order to attack such a cypher? Let's see what this bad boy can do. We're midnight blue. About two weeks ago, we announced that Tetra burst vulnerabilities, consisting of five vulnerabilities in the Tetra radio standard, two of which are deemed critical. Since then, Etsy, the standardization body responsible for Tetra, has made public statements in which they downplay the seriousness of the vulnerabilities. In these statements, they resorted to a semantic discussion, not calling a spade a spade, or, more specifically, not calling a backdoor a backdoor. Furthermore, they made a number of evidently false statements, such as claiming packet injection, TA1 encrypted networks would be impossible, and that 32 bits of cryptographic strength would have been sufficient in the late 90s. To any information security expert, it's pretty clear that this is not the case. But to help remove those few remaining doubts, we decided to take on the challenge of cracking TA1 on this beautiful machine produced in 1998, running good old Windows 95. Frankly, the hardware is so old that it wasn't easy to get our hands on. When we run the cracking tool, we see it reports that it needs about 13 hours to go through the entire search space. After 12 and a half hours, the key is found, demonstrating the feasibility of cracking TA1 on 90s consumer hardware. All right, Etsy, now that we've cleared up this issue, please let us know if you'd like us to demonstrate packet injection as well. Right, now, I think we've got that out of the way. So, we discussed TA1, it's backdoor, it's rivally breakable. But the other encryption algorithms should be fine, right? There's still TA2 and TA3, which are used generally by law enforcement and emergency services. Well, not really, because we also found a protocol level vulnerability in Tetra. And in order to understand that, we need to dive into the standard a little bit more. So in Tetra, signaling is encrypted, and only the very first part, the MAC header is unencrypted. The MAC header contains some high-level stuff like the length of the package and the address C of the message. And everything after that is encrypted with the Keystream Generator. It's important to note that Tetra messages have no authenticity or integrity guarantees whatsoever. So there is a CRC on the MAC level, and you may optionally add a CRC32 in the data that's encrypted here, but that's not a cryptographic MAC in any sense. So an attacker will be able to forge messages, and whenever such a message is decrypted, the radio will just interpret it and parse it at face value. So the application of the Keystream works as follows. The Keystream Generator function gets two inputs. It gets a key and it gets an IV. And this IV is intended to make sure that for each message, a different Keystream is being generated. And in Tetra, the IV mostly consists of the network time. So the network time is a set of frame counters. There's slot frame, multi-frame, all kinds of frame counters. And these things must be known to the radio whenever he wants to perform an encryption or a decryption. So how does he know that? Well, because it's broadcast by the infrastructure in sync and sys info frames. And once more, these messages in Tetra have no further integrity guarantees whatsoever. So the attack starts to be clear to some of you, maybe. An attacker can decide to overpower the infrastructure and target a mobile station and alter its perception of the network time. And if you start playing with the sync and sys info frames with a targeted mobile station, it will happily use those counters and start using Keystream that was relevant at the time you specified to it. And this works regardless of which Keystream Generator is used. So also on TEA 2 and TEA 3. The attack outline would be as follows. Imagine we capture an interesting message at some point in time. It's encrypted, but we decide that we would like to have the plain text contents. Then at a later point in time, we identify a mobile station that we want to attack. And it can be the same mobile station. It can also be another mobile station as long as it has the same key material. We then overpower the legitimate infrastructure signal, for instance, by use of directional antennas or just by being closer to it than the regular cell tower is. And from that perspective, we can start messing with the perception of time of this mobile station. So we can set the mobile station time all the way back to time t when we originally captured our encrypted message. Now we will somehow need to be able to extract the Keystream from the mobile station that we need to decrypt our message. We'll get into that later. But if we can do that, then we have one. We will be able to decrypt. Now, for the recovery of Keystream, let's start out with an assumption that we already have some Keystream at our disposal. So we will construct a message that is of length n plus one, so one bit longer than the Keystream we have, such that it has an FCS, a frame check sequence, which is a checksum that is embedded in the encrypted part. And it needs an acknowledgement from the mobile station up on receipt. We can encrypt this message with the Keystream we already have and the last bit which we don't have, we will just guess that the Keystream bit there is zero. We send it to the mobile station and the mobile station will decrypt the message, check the checksum, and if everything is good, send an acknowledgement. If that happens, we know the Keystream guess was correct and we have now recovered one additional bit of Keystream. If we do not get an acknowledgement, we know our guess was wrong and we have still recovered a bit of Keystream. You can repeat this and each time you will recover an additional bit of Keystream up to the length you desire. Now, this assumption of having initial Keystream is nice, but we need more. We need to have something that actually works in order to generate this initial seed Keystream. And we are going to do that by sending 16 messages to the mobile station and the first four bits will all be tried and we add the last zero. It doesn't matter what is there, but we will try 0, 0, 0, 0 up to 1, 1, 1, 1, 0. And given how Tetra works, these four bits encode the message type on the LLC level. And what's interesting is that for these 16 messages, there will be exactly one message that will get an acknowledgement from the mobile station. And this is the BL data without FCS message type and all the other messages are either supposed to be way longer and just discarded as being invalid or will not require an acknowledgement to be sent in the first place. So we try these 60 messages, we will get one acknowledgement and that means that we will know how the mobile station decrypted this. So we will know four bits of Keystream. That's pretty cool, but still we need a bit more because the shortest message we can use for the first attack we presented here is 37 bits long. So what we do is we recover these four bits for 10 consecutive slots. And we then craft our 37 bits message with the checksum inside of it and we use Mac fragmentation feature Tetra offers in order to distribute our message over all of these small slots where we have only four bits of Keystream available. The radio will then make sure that these things are stitched back together, we'll decrypt them, we'll validate whether the checksum makes sense, if it makes sense you get an acknowledgement, the story we discussed. So in this way, you can easily choose for which slots you would like to have an additional bit of Keystream, make a guess on that Keystream bit and recover an additional bit. So when we presented this to Etsy, they said that's an interesting and valid theoretical attack. But it's quite serious because it affects all Keystream generators. So we asked them, okay, understandable, but please provide us with a base station so we can instrument it and validate whether this attack is actually practical. And they said, ah, lol no, maybe the wording was a little different. We tried more stakeholders and they all kind of responded like this. So we had to go about this in another way. So what options do we have? We could implement the Tetra infrastructure stack on a software-defined radio and in that way try to target our radio, but that sounds like an awful lot of work. It's very complex, painstaking and not what we're here for, right? So what we did is get our own base station. Meet the Motorola MBTS. It's old, it's heavy, I believe it's 75 kilos or something. It was a clear text base station so it doesn't support encryption and it's cool as fuck. And we decided to transform this thing into an attack platform. So short overview of the MBTS. It has two main components. It has a side controller which does all the high-level stuff and it also holds the firmwares for both the site, both itself and for the base radio modules. And these base radio modules, you can have one or multiple of them. They are actually connected to the antenna. They perform modulation and demodulation, but they also perform the encryption. Both of these components are running on PSOS Plus real-time operating system and based on PowerPC CPUs. Also, they both have management consoles over serial ports, so you can connect to the serial ports, enter some passwords and then you're allowed to enter commands for diagnostics and for debugging purposes. Interestingly, both of these things use unsigned firmwares. So let's go do some base station hacking. We modified the firmwares in order to allow for the implementation of a proof-of-concept and the first thing we did was implement a tinker command which can be invoked from the command line and our tinker command allows raw memory access. So you can just enter a command, read memory or with another command, write to memory. You can also execute memory by just jumping to a random memory address as specified. And we also added malloc and free primitive so that you can allocate blocks of memory for other stuff. Also, we added TEA support. We used our own reference implementation for that and what was very helpful is that this firmware already supported almost the entire suite of cryptography that's required for Tetra, but it just had an empty stop function for the Keystream Generator. So we replaced that. We did some more small changes and we had a functional encrypting base station on our hands. We wrote a framework that allows for the loading of modules into the memory of the base station and for the placement of hooks on functions where we were either interested in debugging or changing the behavior. So making implants for this base station was kind of straightforward actually. Right, so we then decided to continue and start working on our proof of concept for which we dedicated the .ksreuse command which allows the base station to suddenly change the network time as required in order to be able to mount the attack. And also it implements the recovery mechanisms that I've just explained to you guys. Once we started messing with the network time, we saw that our radio rebooted, our mobile radio rebooted and we found that it was due to some synchronization issues in Tetra. Certain messages are expected at certain times and if you mess with the timing then it will start misinterpreting stuff. This can be resolved, we resolved it by making sure our time changes aligned to four multi-frames. It can be done neater, we'll get you a performance improvement but that's way beyond what a proof of concept should be. So with some more tinkering, our MTM radio gladly accepts any jump in network time and we can start attacking. One last thing on the base station, we found several vulnerabilities. For instance, the unauthenticated firmware which is quite an issue for mission-critical communications. An attacker could implant such a thing and gain permanent access to a base station or he can just axle-trade keys and be on his way. Also the firmware of both the side controller and the base radio have hard-coded undocumented backdoor passwords and these passwords give you an authentication level on the command line that's even higher than these systems owner would normally have. Lastly, if you can crash the side controller by some kind of unhandled exception, it will drop to a debug shell that allows you direct code execution and memory access once again allowing for key exfiltration. So we have looked at multiple radios, multiple base stations and mobile stations at this point and there seems to be some kind of industry-wide issue here. The software stacks that are being used are really not up to standards and we start wondering whether anyone is actually pentesting these things in any condition. In any case, here is a demonstration video for the Keystream Recovery attack. Hi, we are Midnight Blue. We have uncovered several serious vulnerabilities in the Tetra radio standard, DOP Tetra Burst. We will first demonstrate an encryption oracle attack to recover a text message, but the attack can also be applied to voice communication and data. The demonstration takes place on our lab setup. The radio receives an encrypted message which is also captured by the attacker. We see the message says secret. The attacker now needs to target the radio and impersonate the infrastructure and carry out the attack to decrypt the previously captured message. We have sped up this process. The attacker has now recovered all he needs to decrypt the message. This attack applies to all Tetra configurations but can be resolved with a firmware update. Further details will be disclosed on August 9th. Thank you. So, this is pretty concrete, right? So, what would Etsy say about this? We presented our proof-of-concept status and now in their public response on the vulnerabilities we uncovered, all they have to say on this key stream recovery issue is that the research, our research, uncovered some general areas for improvement in the Tetra protocol. Lastly, I would like to draw your attention to TA3. We have analyzed it and we have not found it vulnerable but there is something very weird going on. Now, in the other TS, there is also an S-Box but these S-Boxes look normal like an S-Box should look and in TA3 the S-Box is not a permutation so there is one entry that is there twice and this is highly, highly irregular and probably certainly not a positive thing for the security of this algorithm. It might be a mistake, right? Just some random bit flip that occurred somewhere. Well, at least it has to be a mistake when the standard was drafted because if not, our radio would not be compatible with other radios in the field. And what makes it extra suspicious is the fact that there is another small structural change to the feedback mechanism of the key register that hides the issue. Usually you get state merges and in this case, you don't. So there's another small difference from TA1 and TA2 that is here, that kind of masks that there is something weird going on. So at this point, the impact is unclear but we're really asking anyone who knows his way around these kind of things to take a good look at it and publish their findings. Right, so let's discuss the coordinated vulnerability disclosure process. We started working on this project in January 2021 and it took us four months to get the secret cryptography out of the radio. The rest of the year we spent on analysis of the ciphers, on analysis of the protocol and on building some proof of concepts. At the end of 2021, in December, we contacted the Dutch NCSC which then started enumerating stakeholders and in January 2022, we got our first meetings with the Dutch police, with Etsy, the standardization body and with the intelligence community. In February, we distributed a preliminary advisory that was to be distributed among stakeholders. The remainder of the year, we were in touch with various stakeholders like manufacturers, network operators, etc. users in order to do our best into helping them understand the vulnerabilities and understand mitigations that they could take. Now, let's talk mitigations. The key stream recovery attack can be resolved in firmware because the radio can be told not to trust these weird changes in network time. It's important, however, that these patches are properly validated because it's a tricky thing to tackle and it's easy to get it wrong. Alternatively, end-to-end encryption can be used to have a secondary layer of encryption on top of the air interface encryption. And if you're using a tetra radio in a data carrying capacity, you can also consider TLS or IPsec to add additional encryption. The TA1 backdoor obviously cannot be resolved with a firmware patch because it's an essential part of the standard. So we would recommend TA1 users to migrate to TA2. Or alternatively, if that's not possible, use end-to-end encryption or TA3. The de-anonymization attack also cannot be resolved with a firmware update. These users will have to migrate to TA2, which is a new version of the standard that Etsy has drafted and has been published last year. This implements a new encryption mechanism for identities that should be better. Lastly, we have the DCK pinning attack, the SessionKey pinning attack. This can also be resolved with a firmware update. All right, thanks for that. So in the aftermath of disclosing these issues, there were some interesting discussions with Etsy, which we'd like to highlight. So in Kim Zetter's interview with the Etsy Tetra Chairman, he says a couple of interesting things. First of all, he says, well, TA1, is it such a big deal this backdoor? Because anyone in Europe who would need high security would be using TA2. Well, I mean, this is not true. We look through various standards and procurement documents, and they show that TA1 equipment was procured by various countries for police and military use in the last five years. And these are countries like Poland, Bulgaria, Croatia, Montenegro, Moldova, all of which are either EU countries or candidate EU countries. And some of these have been allowed to use TA2, according to Etsy's own standards, as far back as 2003 or 2008. Regardless, in the last five years, they were supplied with this backdoor algorithm within Europe. So what happened here, we don't know, but it's not just limited to the outside of Europe. Secondly, when it comes to the use of TA1 in critical infrastructure, the chairman says, well, if you're using TA1, well, we know that certainly a government actor could have a go at them in a short order because that's what the researchers have proved. But he says, you know, you might be able to migrate away or, you know, are high-value targets actually using this. Well, the problem in critical infrastructure is that you don't have a lot of choice. You can get TA1, or TA3, you're limited to TA1 due to the export controls. In many cases, there are no Tetra end-to-end solutions for the RTUs, the remote terminal units that you're using critical infrastructure. And some of the compensated controls that you might want to take, such as TLS or IPSAC on top of Tetra, might not be supported by these RTUs either. And even if you could migrate away to TA2 or TA3, sometimes this is just not possible in field. As you can see on the snippet from the manual from one of the popular Tetra RTUs, you pick an algorithm and then you stick with it. You can't update it in the field. So now you're stuck with this 32 bits of security. But maybe all of the stuff we've covered, you know, maybe it doesn't matter, maybe it's a big nothing burger because nobody actually targets Tetra networks. And actually in Etsy's official statement, they say Etsy and TCCA are not at this time aware of any exploitations on operational networks. Well, that's interesting because two out of five attacks are passive, so how are you going to notice that? And it's also not true because we looked through Snowden documents and we found that a joint NSA and Australian Signals Directorate Project was undertaken in 2007 against the United Nations Climate Change Conference in Bali, where they targeted the networks of the Indonesian police and they collected Tetra communications describing demonstration routes, as well as the Bali chief of police's private mobile phone number. Now they don't go into the technical details, so this is not proof of our vulnerabilities being exploited, might be, might not be, but it does show that Tetra networks are being actively targeted. We also found a second reference in the Snowden documents where GCHQ mentions that in 2009 they undertook what they call an effects operation called Operation Keto against Argentina around a conflict regarding oil exploration rights tensions, regarding the Falklands or Malvinas Isles. And here they mentioned they were collecting high priority military and leadership communications and that involved a number of Tetra collects. So this shows, again, Tetra networks are being targeted. So, what's next? Well, Etsy announced an update to the standard. They're gonna replace the TAA1 authentication suite with TAA2. They're gonna update the TAA1 to 3 algorithms with five to seven. They have some mitigations around the keystream recovery attack and they're gonna keep the new algorithms all secret again. So, in the interview with the chairman, the journalist asked, you know, if you're saying the only reason these algorithms are secret is because the government has advised it, can Etsy actually decide to make them public on their own? And then they say, yes, we can make that decision and then the journalist asks, so why don't you? And the only answer is, well, I don't know. So, should we trust TAA6 and 7, especially because these will be the new export-controlled ones? What do you think? No. Well, let's just ask Etsy themselves first. So, the journalist says, should we trust Etsy algorithms going forward? And then the chairman says, well, we have no reason to produce dodgy algorithms, if you like, except for the ones that they did. And then he goes further and he says, well, these algorithms were just handed to us and they were designed with some assistance from some government authorities. Let me put it that way. And a little bit later, he says, well, at the end of the day, it's down to customer organizations to ensure that things are secure enough for them. I agree it's difficult with a private algorithm, but the reason we have three different algorithms available must be clear to someone that they're not all as secure as each other. So, you're gonna get three new different algorithms that are gonna be private, so make up your own mind about those ones. In conclusion, this has been the first public in-depth Tetra security analysis in more than 20 years. It affects more than 100 countries, many different sectors that are critical. We reverse engineered the secret cryptography algorithms published on GitHub, so you can go take a look. Multiple vulnerabilities were uncovered both in the standard, as well as equipment, including a backdoor in TEA-1. This is implications for voice and data communications as well as SCADA tele-control communications. Patches are available for some of the issues, while mitigations will be required for others. And I'd like to finish this talk off with a call to action, because there's much more work to be done on Tetra. First of all, people need to take a closer look at the TEA algorithms, especially that very fishy S-Box in TA-3. See if you can get a handle on that one. Also, take a closer look at hurdle, the block cipher that forms the core of the authentication suite, because an attack on hurdle could be catastrophic for Tetra security due to our attack on TA-61, which gives you a little bit of a foothold to play around with that cipher. Secondly, if you're more of a developer, we recommend to implement and extend the open Tetra stacks that are there. The people at OsmoCom have done some great work, and you can go talk to the OsmoCom people, as well as the NLNet Foundation, who will happily help you around, extend these open implementations. And finally, stop doing secret cryptography, please. It's a bad idea, it always ends in tears, and it's just not polite. Stop doing that stuff. Finally, if you want to read more, white papers will be forthcoming on tetraburst.com, an overview of all the vulnerabilities in the radios and the base stations are on midnightblue.nl slash re-tetra. The algorithms are on GitHub. If you want to ask questions to us that you don't want to ask in public, you can always send us an email on one of the addresses below. And if you do have questions that you want to ask in public, I'd like to open the floor for that right now. And that's that.