If you’d been quietly chasing down cryptographic bugs in a proprietary police radio system since 2021, but you’d had to wait until the second half of 2023 to go public with your research, how would you deal with the reveal?
You’d probably do what researchers at boutique Dutch cybersecurity consultancy Midnight Blue did: line up a world tour of conference appearances in the US, Germany and Denmark (Black Hat, Usenix, DEF CON, CCC and ISC), and turn your findings into a BWAIN.
The word BWAIN, if you haven’t seen it before, is our very own jocular acronym that’s short for Bug With An Impressive Name, typically with its own logo, PR-friendly website and custom domain name.
(One notorious BWAIN, named after a legendary musical instrument, Orpheus’s Lyre, even had a theme tune, albeit played on a ukulele.)
Introducing TETRA:BURST
This research is dubbed TETRA:BURST, with the letter “A” stylised to look like a shattered radio transmission mast.
TETRA, if you’ve never heard of it before, is short for Terrestrial Trunked Radio, originally Trans-European Trunked Radio, and is widely used (outside North America, at least) by law enforcement, emergency services and some commercial organisations.
TETRA has featured on Naked Security before, when a Slovenian student received a criminal conviction for hacking the TETRA network in his own country after deciding that his vulnerability reports hadn’t been taken seriously enough:
Trunked radio needs fewer base stations and has a longer range than mobile phone networks, which helps in remote areas, and it supports both point-to-point and broadcast communications, desirable when co-ordinating law enforcement or rescue efforts.
The TETRA system, indeed, was standardised back in 1995, when the cryptographic world was very different.
Back then, cryptographic tools including the DES and RC4 ciphers, and the MD5 message digest algorithm, were still in widespread use, though all of them are now considered dangerously unsafe.
DES was superseded at the start of the 2000s because it uses encryption keys just 56 bits long.
Modern computers are sufficiently fast and cheap that determined cryptocrackers can fairly easily try out all possible 256 different keys (what’s known as a brute-force attack, for obvious reasons) against intercepted messages.
RC4, which is supposed to turn input data with recognisable patterns (even a text string of the same character repeated over and over) into random digital shredded cabbage, was found to have signficant imperfections.
These could be used to used to winkle out plaintext input by performing statistical analysis of ciphertext output.
MD5, which is supposed to produce a pseudorandom 16-byte message digest from any input file, thus generating unforgeable fingerprints for files of any size, turned out to be flawed, too.
Attackers can easily trick the algorithm into churning out the same fingerprint for two different files, annihilating its value as a tamper-detection tool.
End-to-end encryption for individual online transactions, which we now take for granted on the web thanks to secure HTTP (HTTPS, based on TLS, short for transport layer security), was both new and unusual back in 1995.
Transaction-based protection relied on the brand-new-at-the-time network-level protocol known as SSL (secure sockets layer), now considered sufficiently insecure that you’ll struggle to find it in use anywhere online.
Party like it’s 1995
Unlike DES, RC4, MD5, SSL and friends, TETRA’s 1995-era encryption remains in widespread use to this day, but hasn’t received much research attention, apparently for two main reasons.
Firstly, even though it’s used around the world, it’s not an everyday service that pops up in all our lives in the way that mobile telephones and web commerce do.
Secondly, the underlying encryption algorithms are proprietary, guarded as trade secrets under strict non-disclosure agreements (NDAs), so it simply hasn’t had the levels of public mathematical scrutiny as unpatented, open-source encryption algorithms.
In contrast, cryptosystems such as AES (which replaced DES), SHA-256 (which replaced MD5), ChaCha20 (which replaced RC4), and various iterations of TLS (which replaced SSL) have all been analysed, dissected, discussed, hacked, attacked and critiqued in public for years, following what’s known in the trade as Kerckhoff’s Principle.
Auguste Kerckhoff was a Dutch-born linguist who ended up as a professor of the German language in Paris.
He published a pair of seminal papers in the 1880s under the title Military Cryptography, in which he proposed that no cryptographic system should ever rely on what we now refer to as security through obscurity.
Simply put, if you need to keep the algorithm secret, as well as the decryption key for each message, you’re in deep trouble..
Your enemies will ultimately, and inevitably, get hold of that algorithm…
…and, unlike decryption keys, which can be changed at will, you’re stuck with the algorithm that uses those keys.
Use NDAs for commerce, not for crypto
Commercial NDAs are peculiarly purposeless for keeping cryptographic secrets, especially for successful products that end up with ever more partners signed up under NDA.
There are four obvious problems here, namely:
- More and more people officially get the opportunity to figure out exploitable bugs, which they will never disclose if they stick to the spirit of their NDA.
- More and more vendors get the chance to leak the algorithms anyway, if any one of them violates their NDA, whether by accident or design. As Benjamin Franklin, one of America’s best-known and well-remembered scientists, is supposed to have said, “Three people may keep a secret, if two of them are dead.”.
- Sooner or later, someone will see the algorithm legally without a binding NDA. That person is then free to disclose it without breaking the letter of the NDA, and without trampling on its spirit if they happen to agree with Kerckhoff’s Principle.
- Someone not under NDA will eventually figure out the algorithm by observation. Amusingly, if that is the right word, cryptographic reverse engineers can be pretty sure their analysis is correct by comparing the behaviour of their alleged implementation against the real thing. Even small inconsistencies are likely to result in wildly different cryptographic outputs, if the algorithm mixes, minces, shreds, diffuses and scrambles its input in a sufficiently pseudorandom way.
The Dutch researchers in this story took the last approach, legally acquiring a bunch of compliant TETRA devices and figuring out how they worked without using any information covered by NDA.
Apparently, they discovered five vulnerabilities that ended up with CVE numbers, dating back to 2022 because of the time involved in liaising with TETRA vendors on how to fix the issues: CVE-2022-24400 to CVE-2022-24404 inclusive.
Obviously, they’re now holding out on full details for maximum PR effect, with their first public paper scheduled for 2023-08-09 at the Black Hat 2023 conference in Las Vegas, USA.
What to do?
Advance information provided by the researchers is enough to remind us of three cryptographic must-follow rules right away:
- Don’t violate Kerckhoff’s Principle. Use NDAs or other legal instruments if you want to protect your intellectual property or to try to maximise your licensing fees. But never use “trade secrecy” in the hope of improving cryptographic security. Stick to trusted algorithms than have already survived serious public scrutiny.
- Don’t rely on data you can’t verify. CVE-2022-24401 relates to how TETRA base stations and handsets agree on how to encrypt each transmission so that each burst of data gets encrypted uniquely. This means you can’t work out the keys to unscramble old data, even if you’ve already intercepted it, or predict the keys for future data to snoop on it later in real time. TETRA apparently does its key setup based on timestamps transmitted by the base station, so a properly programmed base station should never repeat previous encryption keys. But there’s no data authentication process to prevent a rogue base station from sending out bogus timestamps and thereby tricking a targeted handset into either reusing keystream data from yesterday, or leaking in advance the keystream it will use tomorrow.
- Don’t built in backdoors or other deliberate weaknesses. CVE-2022-24402 covers a deliberate security downgrade trick that can be triggered in TETRA devices using the commercial-level encryption code (this apparently doesn’t apply to devices bought officially for law enforcement or first responder use). This exploit allegedly turns 80-bit encryption, where snoopers need to try 280 different decryption keys in a brute-force attack, into 32-bit encryption. Given that DES was banished more than 20 years ago for using 56-bit encryption, you can be sure that 32 bits of key is far too small for 2023.
Fortunately, it looks as though CVE-2022-24401 has already been quashed with firmware updates (assuming users have applied them).
As for the rest of the vulnerabilities…
…we’ll have to wait until the TETRA:BURST tour kicks off for full details and mitigations.
Adam
Thanks, I just learned the word “winkle”.
Only one very minor typo: “network-leve protocol”. Missed the “l” at the end of “level”
Paul Ducklin
Fixed the typo, thanks.
A winkle (properly a periwinkle) is a small sea mollusc with a spiral shell that is commonly fished for food, along with cockles, mussels, whelks and the like.
As far as I know (I have never eaten a winkle or its ilk – I’ve always assumed that chewing on a pencil eraser would achieve the same gastronomic outcome), the verb, which means “to extract something small with difficulty”, is a metaphor based on the effort needed to get a winkle out of its shell for eating purposes.
Teapot
Disclosure rules should be simple:
– Found a vulnerability? Disclose it responsibly.
– Found a deliberate backdoor? Disclose it publicly & immediately.
Understandable that involuntary vulnerabilities should be given time for bugfixes.
Deliberate backdoors however deserve no grace period, just leak the backdoor directly & publicly.
What do you think Tetra is going to do?
Researcher: “Hello, I found a deliberate backdoor in your product. May you fix it and next time remove all backdoors?”
Vendor: “Hello, thank you for your cybersecurity report. We will remove just this backdoor only and make our future backdoors stealthier so that you don’t find them again.”
Responsibly disclosing deliberate backdoors doesn’t help anybody.
You should instead expose all backdoor details publicly & let customers shun & dump the vendor.
Jeff
I agree that a vendor that deliberately includes a backdoor deserves harsh judgement, but an immediate disclosure of the backdoor doesn’t affect just the vendor, but also affects all users of that product. It’s not reasonable to expect every customer to be able to immediately dump the vendor and replace all of those products (with a significant cost), and even if cost was effectively covered by the vendor, the availability of replacement products for all users could be quite a ways out. Thus the immediate disclosure will have a negative effect on the customers, who have done nothing wrong.