> <i>Two of the vulnerabilities are deemed critical. One of them appears to be an intentional backdoor</i> [...] Reading the contents of a firmware upgrade is not trivial though, as it is heavily encrypted and relies on a Trusted Execution Environment (TEE), embedded in the core processor of the radio.*<p>I don't know whether the backdoor allegation is correct, but unfortunately we should treat opaque ostensible security with skepticism.<p>By their nature, such things often can be used for our protection at the same time they are secretly used against us.
The newsworthy item here is that this is an intentional backdoor. The wikipedia pages list the specific uses per country and department. <a href="https://en.wikipedia.org/wiki/Terrestrial_Trunked_Radio#Usage" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Terrestrial_Trunked_Radio#Usag...</a>
Sounds like they took the "roll your own and don't tell anyone how it works" approach. Security by obscurity is never security. History has shown that the open encryption standards are the most secure.
The interview that is linked[0] in the footnotes of the article with the person from ETSI is absolutely wild... Some excerpts:<p>> kz (interviewer): How did it go about meeting those requirements, because that's the one they're saying has a backdoor in it. Was that the condition for export?<p>> BM (ETSI): Backdoor can mean a couple of things I think. Something like you'd stop the random number generator being random, for instance. [But] what I think was revealed [by the researchers] was that TEA1 has reduced key-entropy. So is that a backdoor? I don't know. I'm not sure it's what I would describe as a backdoor, nor would the TETRA community I think.<p>...<p>> KZ: People ... believe they're getting an 80-bit key and they're not.<p>> BM: Well it is an 80-bit long key. [But] if it had 80 bits of entropy, it wouldn't be exportable.<p>...<p>> kz: You're saying 25 years ago 32 bit would have been secure?<p>> BM: I think so. I can only assume. Because the people who designed this algorithm didn't confer with what was then EP-TETRA [ETSI Project-TETRA is the name of the working group that oversaw the development of the TETRA standard]. We were just given those algorithms. And the algorithms were designed with some assistance from some government authorities, let me put it that way.<p>...<p>> bm: That's what we now know yeah - that it did have a reduced key length.<p>> KZ: What do you mean we now know? SAGE created this algorithm but the Project-TETRA people did not know it had a reduced key?<p>> BM: That's correct. Not before it was delivered. Once the software had been delivered to them under the confidential understanding, that's the time at which they [would have known].<p>...<p>You've really got to wonder who at ETSI gave the thumbs up on doing this interview.<p>0 - <a href="https://www.zetter-zeroday.com/p/interview-with-the-etsi-standards" rel="nofollow noreferrer">https://www.zetter-zeroday.com/p/interview-with-the-etsi-sta...</a>
What exactly were TETRA radios used for? I assume they were government/infra related, but then I don't understand why they'd need to backdoor the keying
Some time ago there was a github repo online that has all teaX and hurdle algorithms code, and also ta61 identity encryption algorithm mentioned by Midnightblue.
<a href="https://web.archive.org/web/20230213001503/https://github.com/frits-greuter/ampx/blame/5ee95317a2c05a751e64a909b630f51d6d08b643/projects/tetra/source/ai/mm/security/algorithm_tea1.cpp" rel="nofollow noreferrer">https://web.archive.org/web/20230213001503/https://github.co...</a><p><a href="https://web.archive.org/web/20230213001335/https://github.com/frits-greuter/ampx/archive/refs/heads/master.zip" rel="nofollow noreferrer">https://web.archive.org/web/20230213001335/https://github.co...</a>
In 2023 you're telling me that some <i>emergency vehicles</i> are happily rocking encryption protocols with 80-bit, wait actually, 32-bit keys? These are all cases of systemic procrastination. We're talking about emergency vehicles here though, so: neglect.<p>Nobody is surprised these protocols have been broken, it should not be a surprise, and having some kind of panic reaction should
be considered either a charade or a case of abysmal management.
I heard about this some time ago... the timeline shows the sources should be available from august this year, but nothing yet on github ( <a href="https://github.com/MidnightBlueLabs/TETRA_burst">https://github.com/MidnightBlueLabs/TETRA_burst</a> )
The fact many armies use this (including my own country's) is mind boggling. Didn't they request the technical details of the encryption and the source code and have it vetted properly before awarding the tender for these devices? /sarcasm
> The vulnerabilities were discovered during the course of 2020, and were reported to the NCSC in the Netherlands in December of that year. It was decided to hold off public disclosure until July 2023, to give emergency services and equipment suppliers the ability to patch the equipment.<p>Interesting discussion about responsible disclosure. It seems a strange belief that you can tell all the radio operators about the vulnerability without also telling exploiters. Aren't they often one and the same? What's a reasonable approach here?
TL;DR: The only newsworthy vulnerability is the breaking TEA1 - which is anyways the least secure of them all and only intended for commercial use (that is, no emergency services).<p><a href="https://www.tetraburst.com/" rel="nofollow noreferrer">https://www.tetraburst.com/</a>