Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM

https://www.iacr.org/cryptodb/data/paper.php?pubkey=34281

by belter • 2 years ago

101 48 2 years ago

krackers• 2 years ago

especially for embedded systems

Do any embedded systems actually use it for sensitive phone calls? If they're just using it as data transport then they (hopefully) have TLS on top.

ale42• 2 years ago

Do any embedded systems actually use it for sensitive phone calls?

I hope not...

then they (hopefully) have TLS on top.

I'd hope so too, especially given that many cellular modem modules have SSL/TLS support themselves (and they had already 10 years ago), so even a tiny microcontroller communicating by UART to the modem can do TLS.

But reality might be different... it would actually be interesting to see some real-world data about this. I think that some systems connect to special GPRS endpoints (not the usual ones) that connect them directly to some VPN network instead of using the public internet... (if I remember well, I've read this about some automotive systems). So they might actually rely on the VPN encryption for the Internet part, but the GPRS part would then be unsecured if the GPRS crypto is broken.

486sx33• 2 years ago

These systems used to be considered secure. Lots of things blast data out over gprs, at one time it was a backup for home security systems for example. Since throughput was limited and data was expensive, the actual communication was usually designed to be as quick and “frugal” as possible. There used to be lots of weird end points like BB PIN messages (which were encrypted on their own) but most of that is retired now.

I imagine gprs will appear as an attack vector for … something

pzs• 2 years ago

an attacker passively eavesdropping a GSM communication between a target and a base station can decrypt any 2-hour call with probability 0.43, in 14 min

The authors give the above example in the abstract. It does not look like the typical use case for embedded systems. I would think embedded systems send and receive small amounts of non-critical data over GSM, hopefully encrypted, as the parent pointed out. But I may be wrong here - is there a real use case for attacking embedded systems using this method?

mschuster91• 2 years ago

But I may be wrong here - is there a real use case for attacking embedded systems using this method?

yeah, any IoT device that has been built with the assumption of GSM being not eavesdroppable. Cars and alarm systems come to my mind here.

Cthulhu_2• 2 years ago

I wouldn't make that assumption; adding TLS or HTTP on top adds more work and processing power, and if good-enough encryption was promised by the use of GSM/GPRS, why would they add it on top? That's like adding custom encryption on top of HTTPS... which isn't unheard of actually, I knew someone who built that for a banking app, and an ethical hacker got through the HTTPS layer pretty fast.

quesera• 2 years ago

an ethical hacker got through the HTTPS layer pretty fast.

Are we talking obsolete SSL ciphers?

rocqua• 2 years ago

TLS will protect the data, but the same encryption also does a lot on the control plane. That can still be a big issue.

rnhmjoj• 2 years ago

Only embedded systems? At least in Italy, ISPs have enabled VoLTE (voice over LTE) just a couple of years ago and I don't know how well-supported it is by phones. I wouldn't be surprised if the vast majority of calls still happens over GSM (3G networks have been dismantled already, here).

iforgotpassword• 2 years ago

I'm in Germany, my phone most of the time has the volte icon in the status bar, but whenever I start/receive a call and it actually starts out in that mode it usually falls back to GSM after a minute or so. Doesn't seem very stable.

yencabulator2• 2 years ago

Many systems have been built directly on top of SMS, for very low-bandwidth messaging.

eqvinox2• 2 years ago

they (hopefully) have TLS on top.

my sweet summer child…

One, traces recorded 10 years ago can be decrypted now. Even if it's getting better now, 2014 era embedded systems barely had the capability to encrypt their traffic.

Two… GSM, GPRS, … the entire telco world … is sold as secure by merit of government standards body rubberstamp. How many government-related or …-regulated embedded systems are out there you think? And how many just took the "GSM → secure" checkbox?

electrozav• 2 years ago

The non-Javascript message on this page reads:

What a lovely hat
Is it made out of tin foil?

Oh my, very aggressive

qsort• 2 years ago

Oh my, very aggressive

And also missing the point entirely. Websites working without JS is not only a matter of security. It's security + accessibility + SEO + usability on older or quirky devices + usability via the likes of curl...

robertlagrant• 2 years ago

It's not a message about websites working without JS. It's about browsing with JS disabled.

hagbard_c• 2 years ago

Yes, a textual site which requires Javascript - or any other active component really - for the text to be read is a bit like a book which requires a decoder ring to read. Just present a text-only or pre-rendered site if the visitor can not or does not want to enable scripting, Maybe add a reminder that the site has some functionality which only works when scripting is enabled.

Dalewyn• 2 years ago

Due to maintainability issues, the navigation header and footer are fetched via javascript ajax requests and inserted into pages on iacr.org.[1]

That these clowns don't use server-side scripting for this speaks volumes to why everyone should block their JavaShit.

[1] https://www.iacr.org/tinfoil.html

jeroenhd2• 2 years ago

The JS on this page isn't even used to fetch the header/footer either. Most of the 230KiB of Javascript seems to be mathjax.

Childish stuff like this makes sense for personal blogs, but this unwarranted hostility immediately made me distrust this organisation.

Cthulhu_2• 2 years ago

Have they considered iframes?

pjc502• 2 years ago

The amount of pain caused by HTML not having a "client-side include" is ridiculous. Server-side include is very old, but for various reasons having it client side would be easier for use cases like this.

(Security would have to be the same as <script>)

tgsovlerkhgsel2• 2 years ago

"Death Knell" for GPRS and GSM encryption, which was already considered widely broken in many different ways in practice, this just adds one to the pile.

belter• 2 years ago

From the paper: "...Although designed in the 80s, such networks are still quite active today, especially for embedded systems..."

londons_explore2• 2 years ago

I would like to know why encryption designed in the 80's has failed so spectacularly despite claims that it would take "longer then the age of the universe" to break...

Were experts naieve about the progress of computation? Can we trust experts now that claim data is mathematically protected in a way unbreakable for millions of years?

tgsovlerkhgsel2• 2 years ago

Exactly - and they will continue to be used despite their now marginally increased insecurity.

Majromax• 2 years ago

Note that the attack described in this article is a passive attack, so sufficiently long calls that were previously recorded might be vulnerable. I doubt this will matter for most people, but mass interception for later decryption was one of the surprises of the Snowden files.

mannyv• 2 years ago

Realistically speaking, nobody cares about mobile security.

For IoT, well, who cares?

And it's been well-known that GSM/GPRS encryption has been useless for decades.

People just want a cheap pipe. If they care about security they can do it at the application level by, say, encrypting their stream.

eqvinox2• 2 years ago

I'd like to point out that the entirety of ETCS (european train control system, used around the world despite the name) relies on GSM-R, which is just GSM on different frequency bands with a few extra features.

Snooping on this traffic seems benign, but… security is crumbling away under ETCS' foundation.

iggldiggl• 2 years ago

Original ETCS communication was unencrypted, but at least is already cryptographically authenticated between train and infrastructure. (Though since the authentication is based on 3DES, it's no longer entirely bullet-proof.)

AFAIK however, the new ETCS baseline 4 has introduced specifications in preparation for a) switching away from GPRS to 5G-based communications (FRMCS) and b) introducing TLS-based encryption.

Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM

Related Stories