37C3 - All cops are broadcasting

Thank you so much.

It's really great to be here after one and a half years of responsible disclosure.

We're finally able to talk about this research we did.

So we are Midnight Blue.

This starts off really well.

We are Midnight Blue.

I'm Wouter Bochslag.

These are Karlo Meyer and Jos Wetzels.

And together we form Midnight Blue, a security consultancy company based in the Netherlands.

We mainly specialized in embedded system security and critical infrastructure communications and stuff like that.

You may have heard of us before.

We investigated vehicle immobilizer systems, broke a few of them, found issues in the BlackBerry UNX operating system, broke a hardened variant of the MiFaire RFID chip, and more stuff.

And obviously this Tetra research.

So some of you may already have seen our research at, for instance, CCC camp or maybe the DevCon or Black Hat talks.

So today we will be presenting some new material, some old stuff as well, because I don't think everyone is familiar with it.

But new will be some details on the de-anonymization attack that would allow you to more accurately pinpoint who is using Tetra networks and at what time.

We're going to talk about how cryptographic backdoor has spread throughout Europe and the implications that this has in some very sensitive use cases.

We have had multiple reports of vendors misinforming their own customers, so we will dig into that a little bit.

And we will discuss some new developments regarding Tetra as a technology.

So what is Tetra?

Tetra is a globally used radio technology.

There's more of them.

There is, for instance, P25 and DMR and Tetra-Pole.

But Tetra is a very, very large one.

It has been standardized in 1995 by the ETSI organization, which also was involved in standardizing GSM, 3G, 4G, DMR, DECT, that kind of stuff.

And it's used for voice communications, like portable radios and stuff like that.

But it's also used in a data-carrying capacity, including machine-to-machine communication, IP or serial traffic.

And what's interesting about Tetra is that it relies on secret proprietary cryptography.

So it's very hard to assess the actual strength of it.

And it's being used globally.

So its primary use case was used by police forces.

The vast majority of police forces around the world use Tetra, with the notable exception of the U.S. and France, who have Tetra-Pole because French.

You may be familiar with your own national network in the Netherlands that will be seen in the 2000s.

Here it's Bosnet.

And there's many, many more places where this is being used by police.

But there's also use by military and intelligence services.

Now note that these maps, the countries that we've highlighted here, are places where we have been able to confirm that it's being used in some capacity by this use group.

There's bound to be much more out there for which we could not find any public documentation or tender.

But at the very least, these countries are using this technology.

And maybe even more importantly, critical infrastructure is also using it.

Parties like airports, harbors, train stations, energy distribution networks, they use Tetra for voice communication, like engineers that need to communicate on a site or surveillance personnel that wants to be able to talk with these portable handhelds.

But it's also used in a data-carrying capacity, as I mentioned before.

So you must imagine that, for instance, for energy distribution, you can use Tetra to carry this SCADA telecontrol data and remotely operate your sites.

And that's kind of a sensitive use case.

More on that later.

So a common misconception is that Tetra is an open standard.

It's not really an open standard.

It's a public standard.

Large parts of it are indeed publicly available.

So you can dig through these thousands of pages of documentation explaining many, many aspects of the Tetra radio technology.

But when it gets to cryptography and security, you will typically see stuff like this.

You will see some charts and you will see some boxes with labels.

And these labels correspond to a cryptographic primitive, a secret cryptographic primitive.

And if you would want to know how such a primitive works, you would need to get those from ETSI under a non-disclosure agreement.

And ETSI determines whether you are eligible to receive those.

They only provide these specifications to bona fide parties, whatever that is, in their eyes.

Also, as a manufacturer, if you obtain the specifications, you are bound by the terms of the NDA to protect these algorithms against extraction from your hardware.

So either you could implement the Tetra cryptography in silicon, which makes it quite hard to reverse engineer this using electron microscopes and stuff.

Or if you would want to consider a software implementation, you need to add countermeasures that protect the secret algorithms from extraction.

Now, a problem is that by now there is a lot of bona fide vendors.

Almost any geopolitical block of any influence has its own vendor on its own soil.

There is vendors in the United States, in the UK, in France, in Russia, in China.

So in these countries, there are manufacturers that possess these specifications.

And if, for instance, a nation state would like to investigate the security of this, they can just demand their local manufacturer to hand over the specifications, and they would not have to jump through all the hoops that we had to jump through.

Also an attacker could probably just choose a small one from this list, hack a SharePoint, get the specifications off there.

But in all these cases, you would not be able to have a public discussion on the security of Tetra.

Now, Tetra security is based on two parts.

There is the TAA1 suite, which implements authentication and key distribution, as well as identity encryption.

And then there is multiple algorithms for actual encryption.

So air interface encryption, which is the TEA suite.

You have TEA1, which is readily exportable and free for any use case.

There's TEA2, which is intended for emergency services within Europe.

Then there is TEA3, which is also for emergency services, but for countries outside of the EU, with which the EU has good relationships.

So our allies, so to speak.

And then there is TEA4, which has a similar designation as TEA1, but isn't actually used in practice.

So optionally, you could augment the security of your Tetra network by adding end-to-end encryption.

This is not actually part of the Tetra standard, but they do provide some guidelines and some ways of integrating end-to-end encryption into a Tetra network.

But the actual implementation is left to the manufacturers.

So in practice, this has caused that these solutions are exceedingly expensive, quite hellish with regards to key management, and once again, very, very opaque.

So with that in mind, let's talk about the retetra project we undertook.

So I assume that most of you will be familiar with Kirchhoff's principle, but I'll explain it to you briefly.

The Kirchhoff's principle states that a cryptosystem should be secure if everything about the system, except for the key, would be public knowledge.

And why do we want to adhere to this principle?

Well, because violators don't fare well.

In the past, we have seen numerous examples of proprietary secret cryptography that have been broken or even turned out to be back-doors as soon as the secrecy was no longer there and the specifications became public.

So to mind comes the old GSM ciphers, the GMR and GEA ciphers, the counterparts, but also your DECT phones, which use encryption, which turned out to be quite weak once we figured out how it actually worked.

Now ETSI seems to have a different opinion on this matter.

In an interview with Kim Zetter, the Tetra chairman of the technical committee stated that to them obscurity is also a way of maintaining security and we will figure out whether that is actually the case here.

So our project motivation has probably become clear now.

We disagree with these statements.

We want to open up Tetra, make it available to anyone to be able to assess the actual security of this technology.

We approached the NLNet foundation which often provides funding for this kind of research in open technologies and with that funding we were able to pursue this research.

Carlo will tell us more about that.

Thank you very much, Walter.

So we needed a way to extract the algorithms from a radio because obviously we didn't want to sign an NDA.

So in order to do that we first had to explore the landscape of available radios and in the end we stumbled upon this MTM5400 from Motorola and we basically just bought it off e-day second hand.

Then we analyzed the firmware.

We identified where the algorithms could be within the firmware, obviously in a non-clear form.

And then we developed a bunch of reverse engineering tools.

We had to find multiple zero days in this radio in order to extract the algorithms from them.

Then we analyzed them and then we looked into them, validate their security and see if there's weaknesses and then see if we could make proof of concepts for those.

So that would be the end goal.

Right.

So how do we get to the algorithms given that we have this radio?

So this is a simplified form on a diagram.

This whole thing is pretty much a talk on its own.

I'd love to tell you about it.

We only have 15 minutes here.

So I'd like to refer you to the CCC camp talk earlier this year.

So the thing is the MTM5400, it has a baseband chip from Texas Instruments.

It's the TI OMAP L138.

It has an ARM core and a DSP core.

Obviously the ARM core does high level application stuff and the DSP core, well, digital signal processor, it processes signals.

And within the DSP there's a trust execution environment.

So what we did is first we found a vulnerability in the ARM core, like in the software that runs on the ARM core.

So you can talk to this thing through the peripheral connector and we found a format string vulnerability there, which we exploited, which got us code execution on the ARM core.

Then we pivoted to the DSP through a shared memory misconfiguration.

And then we finally extracted a secret key from the trusted execution environment, which allowed us to decrypt the secret algorithms and we got that key through cache timing side channel analysis.

So again, hopefully this sounds appealing and you'll watch the talk.

Okay.

So given that we have those algorithms, let's have a look at them and see what we found.

So first we'll talk a little bit about the authentication.

The TAA1 suite is used for, again, authentication and over the air rekeying.

So again, the standard specifies some diagrams but not the actual primitives.

So we recovered all of them and we figured that all of the primitives prefixed with TA have something to do with encryption and TB are just simple transformation or like expansion and compression functions.

Right.

Okay.

So during the authentication, what happens is that you have a long-term shared secret between the infrastructure and the radio.

It's called key K.

And they both do a handshake.

They combine it with a random seed RS and that results in KS.

The infrastructure then authenticates the radio to the infrastructure and then the radio authenticates the infrastructure, authenticates the radio and the radio authenticates the infrastructure by taking these KS values and combining them with random numbers, rand1 and rand2 and in the end a shared secret key, DCK, it's a session key, is produced.

Now this in itself doesn't look awfully insecure but when you dive deeper, you figure out that some of these boxes are actually the same or very related.

So for example, TA21 is just TA11 with the random seed in reverse byte order and TA22 is just TA12, it's just the exact same thing.

And TB4 turns out to be an XOR.

Okay.

Now assume that we impersonate the infrastructure towards a radio and then we send a seed RS, which is just like whenever you reverse it in order, it will be the same, so a palindrome, let's say.

If you then can predict the challenge sent out by the radio, which is in our case for the MTM5400, that was actually the case because it has a weak random number generator, which is quite typical in embedded devices.

And we would find that if we then just use the predicted random number in the infrastructure as an infrastructure random, it turns out that you end up with an XOR between two identical parts, which results in a key that's all zero.

So this will give you a partial man in the middle attack, so you can intercept all the uplink traffic from a radio.

Obviously you cannot just send it onto the actual infrastructure because that has a different key, but you do get some nice position.

You can access post authentication attack surface, if you will.

So somewhat nice.

Okay.

So there's also identity encryption.

So Tetra doesn't have strong anonymity, but it has a pseudonymity scheme.

So every subscriber identity is a 24 bit number, and that is obfuscated with a key.

And it turns out that due to some -- that it's actually easily breakable, and then you can actually recover the plain text identity.

And due to some serious stakeholder concerns, that primitive that we decided to hold back that primitive back in the day, which we are going to make public today.

So you'll find the code on GitHub if you're interested.

So the way the anonymization scheme works is you get an intermediate secret C, which is based off of a key, using the hurdle block cipher.

And the hurdle block cipher is used in such a fashion that it sort of resembles a hash function.

So the details, again, can be found on GitHub.

And so you get a custom transformation scheme, like sort of in between cryptography and krypto.

So you get on the right side, you get this key.

It gets XORed into the plain text identity, then there's a transformation function, which also public as of today.

It applies transformation, then more bits are XORed in, and another transformation, and then you end up with an encrypted identity.

Now, it turns out that this scheme is actually vulnerable to a meet-in-the-middle attack.

So you need some modest amount of computing power, and then you can actually recover the secret C. Which doesn't give you actual network key, but it does give you the ability to de-anonymize all the traffic immediately.

So what does it give you?

So picture the following scenario.

You get -- there's subscriber identities, those are encrypted.

You manage to decrypt them.

Then you find out that there's certain ranges, right?

Looks like between 0 and 10, there's police forces between 11 and 20, it's covert operation.

21 to 30, that's fire brigade, you name it.

You can easily spot those patterns, and this will give you an interesting counter surveillance capability.

This can be done very conveniently with a Raspberry Pi and some RTL-SDRs, very cheap, you just scatter them around, and it's also a passive attack, so nobody will notice.

So let's have a little demo.

In order to protect against traffic pattern analysis, Tetra provides an identity encryption scheme which transforms plaintext subscriber identities into pseudonymous versions.

However, as part of our research into Tetra security, we uncovered that TA61, the primitive responsible for identity encryption, suffers from an easily exploitable weakness allowing attackers to instantly de-anonymize Tetra traffic.

The attacker needs to identify three pairs of identities with their encrypted equivalents.

These can be obtained by observing unencrypted authentications, in which both a user's encrypted and unencrypted identity are used.

This can be done fully passively.

By analyzing which key fits the observed identity pairs, the attacker may recover an identity encryption key in about two minutes on a five-year-old laptop.

Using this key, an attacker can now instantly decrypt identities and use them for subsequent analysis.

For example, an attacker could use this to correlate subscriber identity ranges to specific user groups, such as undercover police or special intervention units, and build a powerful counterintelligence and early warning capability.

While this issue cannot be resolved by a firmware upgrade, it is addressed in the new, non-backwards-compatible Tetra algorithm set B.

All right.

So let's cut to the chase.

Let's talk about the actual error interface encryption that Tetra uses.

We found a protocol-level issue that applies to all the encryption algorithms regardless of strength.

So on the slide, you can see a signaling message.

And the contents are encrypted, but the Mac header at the left, that's actually unencrypted, and it contains, like, basic stuff, like the length of the message and who the message is intended for.

And starting from the LLC header, it's going to be encrypted.

So what's important to realize here is that Tetra messages have no cryptographic integrity or authentication checks.

There's a checksum, but that only goes over the ciphertext, so it's not really relevant here for an attacker.

So the way keystream generator works is that it needs fresh information for every frame, right?

Otherwise it will generate the same keystream every single time.

So that's being facilitated by frame numbers, or let's say network time.

So those frame numbers are unique for every message you send, so therefore a unique keystream is generated for every message, which is then XORed with the actual message.

Right.

So the problem is, like, suppose that you're a radio and you want to subscribe -- you want to register to the network.

Which network time will you be using?

Well, it gets told to you by the network.

So how does that work?

Well, the network actually tells you in an unauthenticated and unencrypted fashion.

So as an attacker, you can use that to force the use of a certain keystream.

So imagine that an attacker overpowers a signal.

Can be done in many ways, like just put more transmit power in or just be closer to your victim or use a directional antenna or a combination of those.

And so if you then decide to tell the radio, like, hey, this is the network time, it will just start using that network time.

And that means that the keystream will be generated that corresponds to that network time in the past.

So this isn't -- this works regardless of the TEA cipher you're using, and it's also not prevented by network authentication that we discussed earlier.

So the way the attack works is, like, you get a message, you passively capture a message, and it turns out that you're interested in what that message contained.

So the plain text of that message.

So the time that you capture this message, let's say that's called time T, then later on you just go back to that same location where you caught it, or a different one.

It doesn't really matter.

You can go anywhere.

As long as the radio that you're targeting shares key material with the one that sent out the message.

Okay.

So now then at some point you tell this victim radio, like, hey, the time is now the time that it was in the past at time T, and that radio will start generating keystream for that time, and then you do a little dance with that radio and it will gradually tell you what the keystream is.

So I will go into that more deeply now.

So in order to recover the keystream, assume that we already have N bits of keystream, and we want to extend that knowledge.

So we construct a message that is exactly of length N plus one bits, and we make sure that it has a checksum in there, and we make sure that the message has to be acknowledged whenever it's received in good order.

So what do we encrypt that additional keystream bit with?

Well we just pick zero.

Okay.

Now, if we encrypt that and we send it off to our victim radio, the radio will probably we'll see what happens, but if the zero bit was guessed correctly, it will acknowledge the message.

If our guess was wrong and it was actually a one, it will just silently drop the message.

In our case we learned what the value of this keystream bit is and we could just repeat this over and over and over again and then we get the entire keystream.

Okay.

So how do we get this first couple of bits of keystream?

Well it turns out that you can just brute force a four bit message.

So we just try all 16 of them, and it turns out that just one of them will be acknowledged and then you know what the keystream for those four bits will be.

Well in the end we need 40 bits of keystream, so four won't do.

So how do we get from four to 40?

Well it turns out that we can leverage Mac layer fragmentation for that.

So we can just use ten slots of four bits of keystream in a row.

And we can just use fragmentation and then layer our message on top of that.

And then have the radio stitch back all those pieces together.

And if the checksum turns out to be correct, then it will just happily acknowledge that it received the message in good order.

So that means you can just pick any of those slots and then extend the keystream for that and therefore we have our magic keystream recovery capability.

Okay.

So that's the attack in full.

So when we presented this ETSI, they also had something to say.

Well, they found it a nice theoretical find, but not practical at all.

Like how are you going to overpower a signal, blah, blah, blah.

So like okay, we gave them a friendly gesture and asked them like hey, could you just hand us a base station so we could just figure this out for you?

And they said ha ha, well no.

Lol.

So yeah, so we also were in contact by those days with several stakeholders and they pretty much said the same -- they gave us the same message.

And we really wanted to verify this.

So how do you go about this?

Well, obviously, we didn't want to spend time developing a full Tetra stack on our own, because as things currently stand, we kind of like our life.

So yeah, well, we just went ahead and bought one off eBay.

So this is a Motorola base station from 2004.

It's really old.

It's very bulky.

It's 75 kilos.

It's in my house.

And well, at first it didn't really want to cooperate, but then again it doesn't really check firmware signatures, so it's very easy to persuade.

We found some vulnerabilities in there and built our attack platform on top of this.

So the key scene recovery attack looks kind of like this.

Hi, we are Midnight Blue.

We have uncovered several serious vulnerabilities in the Tetra radio standard.

We will first demonstrate a decryption 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 a 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.

All right.

On to the next issue.

We'll dive into the key stream generators a bit.

So they all have a very similar structure, consisting of several linear feedback shift registers, some nonlinear function, and some S boxes.

And this picture is a diagram of TEA2, like the European police one.

And it seems pretty robust.

We weren't able to really pinpoint any, like, graph issue with it.

But then again, I have to admit that I'm not a real hardcore cryptographer.

Well, when it gets really serious is with TEA1.

When we took a look at that, well, basically the first thing it does is it will grab that 80 bit key and push it through a function which outputs a 32 bit key and then does everything based on that.

So yeah, that's pretty awful.

We can now just brute force that 32 bit key that takes about a minute on the laptop.

And then you can just basically intercept and traffic and inject some whatever you like.

This TEA1, as I should probably remind you, that's used in critical infrastructure, and not just outside of Europe, but within Europe as well.

Because critical infrastructure isn't public.

It's private, usually.

And it's also not police.

So as a critical infrastructure asset owner, you typically have the choice between no cryptography or TEA1, which turns out to be sort of equivalent to no cryptography.

All right.

So what was ETSI's response to this?

In the interview that Wouter also referred to with the ETSI technical committee chairman, they claimed that our proof of concept attack is used on a very high powered graphics card, which is a stretch, because it was consumer hardware in 2016.

To be fair, it's probably very powerful 25 years ago, when these things were invented.

And then he goes on to claim that 32 bits may or may not have been sufficient back in those days.

So how about we just put this discussion to rest?

Let's not assume...

Let's not use reasonable equipment.

Let's see what this boy can do.

Hi, we're Midnight Blue.

About two weeks ago, we announced the Tetra burst vulnerabilities, consisting of five vulnerabilities in the Tetra radio standard, two of which are deemed critical.

Since then, ETSI, 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 and TEA-1 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 TEA-1 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 in 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 TEA-1 on 90s consumer hardware.

All right, ETSI, now that we've cleared up this issue, please let us know if you'd like us to demonstrate packet injection as well.

Hello.

Oh, we are made by blue.

All right, thanks for that.

So surely this is a terrible backdoor, but it shouldn't be a problem for Europe, right?

It should only be a problem for all those big bad countries outside of Europe.

Surely nobody would design a backdoor and then end up shooting themselves in the foot.

In the interview with Brian Murgatroyd, the chairman of the ETSI technical committee on Tetra, he said, "Well, I would expect that anybody who would need a lot of protection would not just be using TEA-1.

In Europe, I would suggest that anyone who needed high security would be using TEA-2." So luckily, crisis averted, no real problem here, right?

Except it's bullshit.

So we went through several RFPs and tenders and public documents and found that there are multiple countries in Europe that are part of the European Union where police and military units are actually using TEA-1.

So the first example that you can see on the slide is from Poland, which has been a European Union member since 2004, where the municipal police were sold TEA-1 radios as shortly recently as 2019 or 2020.

And this is in cities like Warsaw and Krakow and Lutz, and they're using TEA-1 there.

A second example is Bulgaria.

They're a AU member since 2007, and there the Ministry of Defense has been procuring TEA-1 radios as recently as 2020 for various systems.

A third example is Slovenia, also an EU member since 2004.

And they recently already had a bit of a Tetra scandal where an independent researcher showed that actually they weren't encrypting anything at all, contrary to what they thought.

He went to the media with this, got jail time for it, and then shortly after that scandal, they started procuring police helicopters, announcing that they were now using TEA-1, which is also no encryption.

So fourth example is Montenegro.

They're a candidate EU member since 2010.

They've really been struggling with international organized crime and drug cartels, especially in the city of Barre.

And there the police has been procuring TEA-1 radios as recently as 2018.

And given the use and lifetime of these radios, you know all of this stuff is still in use.

And 32 bits of cryptography isn't just terrible for state actors, it's terrible for organized crime as well.

The fifth example, just to continue the trend, is Moldova.

Moldova is a candidate EU member since 2022 for obvious reasons.

They're geopolitically very sensitive currently because of tensions with Russia.

And there the Moldovan police in Carabinieri have been procuring TEA-1 radios between 2017 and 2020, including with United Nations aid.

So this really goes to show that geopolitical relations might change over time, but technology stacks don't really.

So you might think these people need to have TEA-1, they need to have a backdoor, and then your relationship to these countries changes and now you end up shooting yourself in the foot.

Which also happened outside of Europe with United States local allies.

We found various procurement documents describing that local allies of the United States were handed TEA-1 radios and not TEA-3 radios, such as the entire Iraqi police network, the entire Lebanese police network, the combined joint task force in the Horn of Africa, which is in Somalia with the United States Department of Defense, and the United Nations in Afghanistan when they still were there.

They were all using TEA-1 equipment, 32 bits of cryptography there.

But on top of that, and far worse in my opinion, is the use of TEA-1 in critical infrastructure.

Like Carlo already mentioned, there's two options if you're critical infrastructure.

Either you use plain text communications or you use TEA-1.

And to understand the impact of this, you need to have a little bit of background about Tetra usage in critical infrastructure.

So there's multiple ways to do networking.

You can have radio to radio communications.

You can have a gateway where all the radios communicate with a gateway.

And on top of that, you have two main modes of communication.

There's the short data service, which is a little bit like SMS, but for Tetra.

And then there's packet data where you have an IP subnet that gets extended over a Tetra network.

And then on top of these communication modes, you have a data carrier.

And that can be serial communications, serial over IP, or pure IP networks over these Tetra communications.

And in critical infrastructure, they carry the usual suspects, the IEC 101, 104, DMP3, Modbus protocols, which as you may or may not know, are all insecure by design.

So these protocols have no security features of themselves and rely on the layers below that.

Now, an example of that is transportation.

So the slide you can see here is based on real world systems, the documentation of which we found online.

And there's many cases of transportation in the United States, United Kingdom, here in Germany, Spain, Greece, South America, Eastern Europe, where buses and light rail are communicating over Tetra.

And that can be as simple as the security personnel on a train.

But it can also be the control of the braking, of the doors, of the passenger information system, of the rail site safety signaling.

And all of this might go over Tetra.

Now the first scenario where that could go horribly wrong is an instance of passenger deception.

So at the top of the slide, you can see anonymized slides that we found online from a real world Tetra system, where they are controlling the passenger information systems that you see inside the trains, as well as on the stations, through SDS messages over Tetra, as well as audio.

If you are able to inject traffic into a Tetra network, as you will be able to do once you crack a TA1 key, you can send fake messages.

And that way you could, for example, call a bomb alert.

You could disrupt the passenger information systems.

And something very similar happened a few years ago in Iran, where the passenger information systems were hacked.

They put fake delays on there and they said, "Well, if you have trouble with the train, call this phone number." And it turned out to be a private phone number of the Ayatollah.

This caused some serious delays for a very long time.

So just because you're not immediately attacking the railway signaling systems themselves, just this kind of disruption can already have a serious impact.

A second scenario would be dispatcher deception.

So one of the things that you can do in transportation systems that are managed over Tetra is you can have the GPS coordinates of a bus or a tram or anything like that transmitted over an SDS message and have the dispatcher that sits in a command center tell a certain vehicle where it needs to go.

Now obviously if you can fake these messages, you can tell the dispatcher that vehicles are where they aren't, or you can tell the vehicles to go where they shouldn't be going.

Something similar happened at the start of the invasion in Ukraine, where Yandex taxi was hacked and hundreds of taxis were sent to the same place in Moscow, causing a gridlock that takes a long time to resolve.

So a scenario like this could potentially be possible too.

Thirdly, and more worryingly, as you can see on the slides, some transportation systems over Tetra allow for remote control of the trains, switching a train on or off, doing emergency braking, disabling the service brake, messing with the fire detection.

And if you're able to trigger an emergency brake on a train, this might not immediately lead to a safety impact.

That depends on how these systems are engineered.

But it will certainly cause disruption, especially when you're doing this at scale.

And something similar happened this year in Poland, where a other analog radio system, they injected a message that caused emergency braking and several trains were halted.

In 2008, a Polish team did a replay attack on an emergency braking message on a tram and that caused derailment.

So the potential impact of this stuff is very serious.

And to leave that up to 32 bits of encryption is absolutely mind-blowing.

So, finally, there is a little bit to be told about TA3, that's the third algorithm, and a very interesting case because it's not the one that is meant for the countries where they have bad relationships with.

It's also not meant for Europe.

It's meant for allies outside of Europe.

And we found an interesting thing there that the S-Box, a crucial cryptographic component, had a duplicate entry.

And I won't go into the details of what that means, but this is certainly something that you don't do if you want to strengthen an algorithm.

It's also unlikely to be accidental because all the vendors will need to have the same implementation for interoperability reasons, and they made some changes to the cipher that really put it apart from TA1 and TA2.

Now the impact of this is currently unclear to us.

We would like more public scrutiny of this.

But if there turns out to be an additional backdoor here, that is very interesting indeed.

All right.

So a little bit about the coordinated vulnerability disclosure.

So as you can see, this is a very long timeline.

We started working on this project in January of 2021.

Within four months, we had the algorithms, and we spent essentially the rest of the year perfecting the attacks, writing the reports.

And in December of 2021, we first contacted the Dutch National Cyber Security Center.

In January of 2022, we had our meetings with the Dutch police, with ETSI, with intelligence community to put this information outside.

And then we had our advisories throughout 2022 and 2023 and get everybody informed because these systems are very hard to patch, very hard to mitigate, very hard to work around.

So we wanted to give enough parties ample time to prepare before making this public.

So when it comes to mitigations, there's different mitigations possible for the various attacks.

When it comes to the keystream recovery attack, vendors have made firmware updates available for this.

A little bit more about that later.

For the TEA1 backdoor, you will most likely need to either migrate to a new TEA cipher if you are able to do that, or you will need to put end-to-end encryption on top of that, or if you're in critical infrastructure, you will need to start thinking about security on the layers that are put on top of Tetra.

When it comes to the de-anonymization attack, well, you can't really do anything.

You need to take operational security measures, and you need to wait until the new Tetra algorithms are available from a vendor.

And finally, when it comes to the DCK pinning attack, firmware updates are available for that as well, depending on your vendor.

Now, a little bit of information about misinformation.

So we wanted to insert this because since our disclosures, we've had a lot of contact with a lot of different vendors, a lot of different users, a lot of different system integrators, and we've consistently heard vendors and standards organizations spread misinformation.

First of all, when it comes to the official statement by ETSI and the TCCA, which is the industry organization of Tetra, in their official statement in July of 2023, they first said, "Well, TA1 is not a backdoor.

It's a surreptitious weakening, semantics, nonsense." But then they also didn't make a mention of any of the other vulnerabilities.

The only thing they said about the keystream recovery attack, the de-anonymization, the DCK pinning, is the research uncovered some general areas for improvement in the Tetra protocol.

Well, you can say that again.

As of December this year, continued statements are being made by these organizations to the industry claiming that only the TA1 issue is relevant, and that's simply not the case.

So if you are someone who works with Tetra, if you know someone who works with Tetra, please push back on this.

They also, very irresponsibly in my eyes, continue to recommend Tetra as a highly secure wireless link for SCADA as of this year, one and a half years after we disclosed these issues to them.

For example, they say, "Well, many train, rail, metro, and transport operators use Tetra for control and functionality for their public transport operations.

The high security and encryption support of Tetra enables these safety-critical applications." And they go on to say that the same holds for oil and gas pipelines and whatever.

So they're trying to stand up new systems with these technologies.

Now when it comes to the vendors and the system integrators, well, the vast majority of responses have been crickets.

They have made no public statement.

Some don't even inform their customers.

Others just echo what ETSI says, which makes sense because the vendors are ETSI and the other way around.

They just say, "Well, it's all hypothetical.

There are lab conditions.

There's no evidence of real world attacks.

And this makes our and NCSC job a lot more tiresome.

So please stop doing this. Interestingly, they also do risk assessments for their customers.

They say, well, wholly selflessly they say, "Well, we'll do a risk assessment free of charge," which is like grading your own accent, right?

It's the butcher judging his own meat, "for supposedly hypothetical vulnerability." So you already know what kind of conclusions they're going to draw.

And this wouldn't be so terrible if they didn't fundamentally misunderstand things.

For example, we saw vendors saying that the keystream recovery attack is a man in the middle, which means you haven't understood it.

And then they end up giving bad advice on top of that.

So we've heard of multiple vendors trying to sell the backdoor TA1 algorithm to multiple European critical infra parties as late as May of this year telling them it was either fine, there was nothing wrong with it, or that it would be patched, which is impossible.

Also multiple vendors told critical infrastructure in Europe that network authentication would protect them against message injection, which is nonsense because there's no cryptographic signing at a message level for Tetra.

So this is plain false information.

And at least in one case, we saw a vendor deliver a patch that did absolutely nothing.

So I'm not saying it's a bad patch.

It didn't do anything.

So these are the people giving the advice and doing the risk assessment.

So please take this with a grain of salt and maybe get a second opinion and independent advice.

So a little bit about the aftermath of this stuff.

Maybe I'm all exaggerating.

Maybe this is a big nothing burger.

As ETSI said, well, our official position is that at this time we are not aware of any exploitations on operational networks, which two out of five attacks are passive.

So how are you going to know this?

But we also did some digging in the Snowden documents.

And we found that in 2007, there was a joint NSA and Australian Signals Directorate operation to collect the communications of the Indonesian police during the United Nations Climate Change Conference in Bali.

And there they mentioned that they got the demonstration routes, they got the Bali chief of police's mobile phone number, and they were collecting this kind of traffic.

Now I'm not saying that they exploited our vulnerabilities.

We don't have those technical details.

But it is proof of active Tetra targeting by state-sponsored actors.

We also found in the Snowden documents that the United Kingdom's GCHQ undertook an effects operation called Operation Quito against Argentina around the Falklands Islands because of conflicts around oil exploration rights in 2009.

There they were collecting Tetra communications of military and leadership, again showing that Tetra is being actively targeted.

So with that, what's next?

I'll let Wouter handle that part.

Thanks.

All right.

So some time ago already, ETSI has released a new version of the standard with an algorithm set B, and that includes new encryption algorithms for the air interface and new authentication suites with new primitives, also new identity encryption.

And they were initially going to be secret again, so they were going to make the same mistake all over again.

But following our research, they have discussed among themselves and with the manufacturers, and they have now decided to make both the old and the new algorithms public for public scrutiny.

So that's a big win for open technologies.

Thank you.

Because transparency is at the root of ETSI.

So yay with a small star, because just disclosing cryptographic primitives is not really enough.

Like we talked about TEA 3, there is some weird stuff going on.

We would like to have full disclosure on design process.

No one explained constants.

We want to understand why they devised the algorithms in that way.

And then we can gain some understanding and some confidence in the strength of these ciphers.

Now also a statement that was made and it was less widely covered is that the TEA 7 algorithm they admitted has an effective key length of 56 bits.

So it has another reduction function which reduces the key length to 56 bits as per the Wassenaar arrangement.

And well, let's put that into perspective a little bit.

Let's make some assumptions.

Let's say that the new key stream generators are about as fast in generating key stream as the old ones.

And let's take our fastest implementation of a cracker on TEA 1 as a baseline.

So in that case, a single really fat Amazon machine would take 170 days of crunching through all the possible keys to find the TEA 7 key that corresponds to a network.

And if you are using spot pricing, so that's a discounting pricing model using underutilized servers, you can look up online which region at that point has the lowest pricing for a specific device type, then we estimate that this could cost as little as 5,000 euros.

And you could, of course, speed this up by getting more machines.

You could grab a couple of dozen maybe.

And we think it's reasonable to think that you could mount an AWS-based attacker platform and for 5,000, 6,000 euros within a week get your hands on a TEA 7 key.

And that is without discussing GPU implementations or FPGA implementation.

It's just a lower bar.

It's also excluding the fact that computational costs will go down over the next couple of decades.

So obviously this is an amount of money that any reasonably or even somewhat motivated adversary would be able to handle.

It would be within range for organized crime and maybe even a poor teenager that just has too much money on his hands at some point in the future.

In any case, this is not going to be future proof.

So we keep hearing that Wassaner [arrangement] is the reason that these backdoors are there and have to be there.

And while there is certainly restrictions on the exports of strong cryptography, there are also exceptions in Wassaner.

There are exceptions regarding public cryptography, exceptions regarding civil use, like mobile civil use, and exceptions for what they call connected civil industry applications.

So in many, many, many cases, a network would not need to be restricted to these low levels of security.

So will critical infra now be getting TEA 7?

And will we have the whole TEA 1 debacle again?

It's possible.

Let's hope not.

But at least we now know on beforehand what we are getting ourselves into.

Now TEA 6 is the counterpart of TEA 3.

It's meant for European allies, for law enforcement and emergency services outside of the EU.

Should we trust that?

Yeah.

Well, we could just ask ETSI.

Because in the interview that was cited before, the chair of the technical committee said they have no reason to produce dodgy algorithms.

They also say that there is some, well, let's say responsibility for the end user.

So if you are using weak cryptography, then you should probably have picked something else.

In the past this was a ludicrous statement because the algorithms were secret.

But now you can make up your own mind and probably come to the conclusion that you do not want a multi-decade attachment to a weak cryptographic standard.

In conclusion, we have presented the first public in-depth security analysis of Tetra.

It's a technology used in over 100 countries in a lot of different sectors.

We found multiple vulnerabilities.

We informed manufacturers and stakeholders who have been working on patches, rolling them out.

And as of yet, there is still a lot of work to be done.

But we will get there eventually.

Last, a call to action.

If your organization uses Tetra, please be sure to properly investigate the issues that we uncovered, look into mitigations, spend money on it because it will cost money and effort.

Don't blindly trust your vendors.

If you're in doubt whether they are telling you the full story or they understand the full story, please reach out to us.

It would be interesting for the cryptographic community to take a closer look at the cryptography, the new variants once they get disclosed, or the current TA3 or hurdle ciphers.

There is open technology stacks that are really great, but there is a lot of work to be done there.

So for the coding people, there is lots of opportunities to contribute.

And lastly, please stop doing secret cryptography.

Especially Tetra end-to-end is very painful because it's reserved for the most sensitive of use cases for Tetra.

And with that, I'm not sure if we have time left for questions, but at the very least, I would like to thank you for your attention.

Thank you.

Thank you.

Thank you.

It's on.

Okay.

We do have some questions.

We still have some time.

We're running over time, but we have a large break.

Please try to be a bit silent if you're leaving the room now.

I know that Signal Angel has some questions.

We'll start there.

Yes?

Yes?

I think that the internet has been satisfied by the rest of the talk.

So there may not be more questions, but I'll let you know if there are.

Okay.

Here is a question at number one.

Right side.

Hello.

Your flag of Indonesia was upside down.

But I also have a question, actually, is it not a GDPR violation if any officials use this technology and then talk about suspects, witnesses, patients, and so on?

I think with regards to the Indonesian flag, you need to take it up with the NSA.

With regards to the GDPR, I'm not a specialist on regulation.

I think it might be an issue.

But I haven't heard anyone actually digging into this.

So if this is something you're interested in, I think it might be interesting to poke at that a little bit.

Maybe there could be just like a judge decision that is illegal to use it.

Could be.

It's definitely murky waters right now.

The privacy guarantees are extremely limited.

That's for sure.

All right.

Number four, you have a question.

So one of the takeaways of your talk is that we should use publicly vetted and standardized algorithms.

So how can we make it easier to actually build secure protocols on top of those cryptographic primitives and specifically do you have any recommendations for NIST to take in on their ongoing process for standardizing SCon and for their review of the shake standard which is likely to be used in Tetra?

Right.

So as of today, there's plenty of publicly available algorithms that you can just take and just pick them and put them in as a building block, as a Lego block, let's say.

So you can just use that.

And then you build a protocol around those.

And typically what you see in practice is that every once in a while these things just get broken and then they evolve over time.

Like we now have IPv4 or IPv6, and we have TLS 1.3.

Those things didn't come falling out of the sky.

Those standards went through a painful evolution, and they're sort of reasonably secure as of today.

To add to that, these things need to be made maintainable which is not the case with Tetra where updates are very painful to roll out, and you're completely dependent on the vendor to basically allow you to do that.

Number one, please.

Thank you for the great talk.

My question would be will you probe other algorithms, including newer Tetra algorithms, but also there are a lot of other protocols and algorithms from other vendors and organizations?

Yeah, so I mean we're definitely going to look at the new Tetra algorithms.

We chose Tetra because it's one of the last remaining bastions of proprietary cryptography outside of the military space.

We have some ideas for future research, but yeah, if anybody has any ideas that they'd like to shoot our way, we'd love to have a go at it.

Okay.

I see someone here in front at number two.

Have you had a look into the cryptography of DMR?

No, but I know that it used to be RC4 with 40 bits, then there are some AES-based versions that nobody has really looked into, but I suspect that at a protocol implementation level there might be some issues there with DMR as there might be with P25 phase 2.

So that's also interesting potential research material.

We have an expert team here.

Number one.

Hi.

How does it work in this kind of use case for the -- do those industrial devices like use Tetra up to application layer when you're talking about fake messages and stuff, or is it like a network layer or something?

So it's used basically as a network, and then on top of Tetra you carry serial messages or IP messages over SDS or over the packet data mode, and it's transparent to the SCADA systems and the RTUs and so on, so they don't know about Tetra.

They just treat it like any other serial or IP network, which is also why you need to take the security layers above the security options above Tetra.

But usually they aren't encrypted.

No, no, no.

Usually OT networks and critical infrastructure are insecure.

Another number one.

Yes, sir.

How can the S box not be symmetric?

What do you do on the decrypt side?

Do you just guess?

I mean, sorry, how can it not be a permutation?

That doesn't really matter because the S box is used in the key register, so the key register is initialized with an 80-bit key, and then it just rolls and outputs a stream of key material which is injected into the state, so you never have to go back.

Oh, I see.

Only in the power.

You decrypt by reapplying the same key stream.

Besides that, they also made some tweaks to the design that prevents state merges.

And Signal Angel is waving something from outer space.

Yes, so the internet would like to know what do you think ETSI's incentive is for being deceptive about disclosure, and why do you think they haven't learned from other public ciphers?

I didn't quite get that.

Yes, I didn't fully get that.

So what do you think that ETSI's incentive is for deception around the disclosure, and why do you think they have not learned from other public ciphers?

I don't think it's a question of learning.

I think it's a question of, as you said, incentive.

ETSI continues to choose and has chosen in the past to keep these things secret and proprietary.

They did it with GSM, they did it with satellite phones, with GPRS.

It's because there is a conscious choice to enforce these export controls to have backdoor cryptography in other parts of the world, so this is not an oversight, it's policy.

Now they're making these new algorithms open under public pressure as a result of our research, but they're still going to cripple at least one of the algorithms and potentially a second one.

So this is a matter of their policy, this is something that's ingrained in the way they work as an organisation.

Whoa, we solved quite some questions here.

Thank you, guys.

They can reach you on the emails there.

Of course, you can always reach out to us.

Seems like there is still a lot of work to be done.

Thank you to Jos Wetzels, Carlo Mayer, Walter Boxster.

Subtitles created by Otto Heikkilä
KYBS2004 course assignment at JYU.FI