Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM(iacr.org)
iacr.org
Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM
https://www.iacr.org/cryptodb/data/paper.php?pubkey=34281
52 comments
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.
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.
Snooping on this traffic seems benign, but… security is crumbling away under ETCS' foundation.
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.
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.
>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.
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.
> 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.
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.
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
I imagine gprs will appear as an attack vector for … something
> 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?
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?
> 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.
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.
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.
> an ethical hacker got through the HTTPS layer pretty fast.
Are we talking obsolete SSL ciphers?
Are we talking obsolete SSL ciphers?
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).
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.
Many systems have been built directly on top of SMS, for very low-bandwidth messaging.
> 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?
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?
TLS will protect the data, but the same encryption also does a lot on the control plane. That can still be a big issue.
The non-Javascript message on this page reads:
> What a lovely hat
>Is it made out of tin foil?
Oh my, very aggressive
> What a lovely hat
>Is it made out of tin foil?
Oh my, very aggressive
>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
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
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>)
(Security would have to be the same as <script>)
We could call it <frame>, or maybe <iframe> since all the cool kids use isomethings these days.
Frames don't reflow. For headers etc people would want to integrate with the rest of the DOM.
"seamless" iframes were meant to, right? Don't know what happened to that.
Most headers today are expandable and need to be”open up” to take the full more of the screen when interacted with.
This is not possible with a frame.
This is not possible with a frame.
Obligatory reminder that XSLT exists.
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.
Childish stuff like this makes sense for personal blogs, but this unwarranted hostility immediately made me distrust this organisation.
Welcome to 2024 when JavaScript is indeed everywhere. It's not hostility. It's reality. Aside from two people here and Stallman, absolutely no one cares about disabling JS any more.
I almost always run websites with Javascript (sometimes I turn it off to get out of illegal cookie walls). I don't really care about the website requiring Javascript (even though it doesn't for this specific page), I care about the explicit hostility against someone whose browser doesn't load JS.
The website would've been fine if they hadn't added anything, yet they went out of their way to insult a small minority of their visitors using a <noscript> element, and took the time to write a weird rant about how you should really enable Javascript for some reason (I guess they only know frontend stuff and don't know how to run a backend server?).
To me, this degrades the website to the level of "personal blog of someone with a grudge" as much as websites that'll redirect you to a rant for leaving Javascript on. For a personal blog, that's just a weird quirk, but for a supposedly scientific, academic space to publish research, that's just bad vibes.
The website would've been fine if they hadn't added anything, yet they went out of their way to insult a small minority of their visitors using a <noscript> element, and took the time to write a weird rant about how you should really enable Javascript for some reason (I guess they only know frontend stuff and don't know how to run a backend server?).
To me, this degrades the website to the level of "personal blog of someone with a grudge" as much as websites that'll redirect you to a rant for leaving Javascript on. For a personal blog, that's just a weird quirk, but for a supposedly scientific, academic space to publish research, that's just bad vibes.
> Welcome to 2024 when JavaScript is indeed everywhere. It's not hostility. It's reality. Aside from two people here and Stallman, absolutely no one cares about disabling JS any more.
This is an irrelevant diversion, and materially untrue - "> What a lovely hat\nIs it made out of tin foil?" is absolutely hostile, and that fact is not contingent on the number of people who disable Javascript.
This is an irrelevant diversion, and materially untrue - "> What a lovely hat\nIs it made out of tin foil?" is absolutely hostile, and that fact is not contingent on the number of people who disable Javascript.
How many enterprise security suites offer remote browser isolation though
Have they considered iframes?
[deleted]
> 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...
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...
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.
It's not a message about websites working without JS. It's about browsing with JS disabled.
[deleted]
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.
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.
"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.
From the paper: "...Although designed in the 80s, such networks are still quite active today, especially for embedded systems..."
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?
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?
The “age of the universe” estimate typically refers to how long it would take to brute force a cipher, i.e. try all possible decryption keys until a valid key is found. Such attacks are almost never practical because we can’t wait that long. So thinking of encryption this way, comparing encryption algorithms by their brute force resistance, is fairly useless. Instead, most real-world attacks rely on implementation flaws and side-channel attacks, which allow an attacker to make an educated guess or even avoid having to guess in the first place. These vulnerabilities can’t be so easily quantified in terms of how long it will take to break, which is why most algorithms don’t talk about it much in their advertising, even though ease of implementation and side-channel resistance are some of the most important attributes.
However, there are algorithms that do make a concerted effort to mitigate these problems and advertise themselves as such, such as Ed25519.
However, there are algorithms that do make a concerted effort to mitigate these problems and advertise themselves as such, such as Ed25519.
GSM is the first (civilian) cellular system to have any encryption at all. The fact that all the primitives are broken comes from the fact that all of them are custom and optimized for hardware implementation on for the time very resource constrained device, also the design predates the open cryptology research community and thus there were not many existing primitives that could just be used unchanged (one can imagine specifying something derived from DES as A3 and A8, but that is moot as the Comp128 in the spec is only an recommendation and these can be freely chosen by the network, I believe most current SIMs use somewhat convoluted algorithm based on AES and SHA256 as that is what is used for EPS-AKA procedure in LTE). As for the authentication being unilateral, nobody probably expected that to be a problem. And the weird way how the A5 stream cipher is used to encrypt the radio frames (which do not have cryptographic authentication, except the fact that what gets encrypted are FEC symbols, not the raw data) shows that the designers were somewhat familiar with military encryption systems, which often have similar availability-vs-authenticity tradeoff.
And well, given the track record of AES, we can probably consider AES secure for foreseeable future. And for many other modern symmetric algorithms (Salsa/ChaCha, Keccak…) one can produce quite believable arguments that they are as secure as AES.
And well, given the track record of AES, we can probably consider AES secure for foreseeable future. And for many other modern symmetric algorithms (Salsa/ChaCha, Keccak…) one can produce quite believable arguments that they are as secure as AES.
Apart from the one-time pad or something equivalent, I don't think anybody can fully guarantee (to the point of mathematical proof) that any particular encryption is mathematically unbreakable. The existence of true one-way functions is technically an open question in the first place.
And even if you make the (probably reasonable) conjecture that one-way functions do in fact exist, there's still a lot that isn't known about the fundamental computational hardness of various problems used for encryption.
Most statements about the strength of particular encryption methods are educated guesses based on current mathematical understanding. Some particular encryption may be unbreakable for millions of years assuming no breakthroughs in mathematics that would allow significant shortcuts in breaking the cipher. For some mathematical problems those breakthroughs may seem more likely than for others.
Would be glad to hear if someone with current understanding of cryptography has more insight, though.
And even if you make the (probably reasonable) conjecture that one-way functions do in fact exist, there's still a lot that isn't known about the fundamental computational hardness of various problems used for encryption.
Most statements about the strength of particular encryption methods are educated guesses based on current mathematical understanding. Some particular encryption may be unbreakable for millions of years assuming no breakthroughs in mathematics that would allow significant shortcuts in breaking the cipher. For some mathematical problems those breakthroughs may seem more likely than for others.
Would be glad to hear if someone with current understanding of cryptography has more insight, though.
Obviously cryptographers were not naive about future technology. One example that comes to my mind is this: in a 1981 paper discussing Triple DES, the authors state: “A generalized meet in the middle attack would then require 2^112 operations and be well beyond the foreseeable technology for at least 50 years, and possibly forever.” - Merkle, R. and M. Hellman, "On the Security of Multiple Encryption", Communications of the ACM, vol. 24, no. 7, pp. 465–467, July 1981
While I would not count on any Triple DES encrypted data remaining secret forever, their other prediction has held up for the time being – 2^112 operations is still completely out of reach 43 years later. Of course there are other ways to attack TDES and it is rightfully considered obsolete.
While I would not count on any Triple DES encrypted data remaining secret forever, their other prediction has held up for the time being – 2^112 operations is still completely out of reach 43 years later. Of course there are other ways to attack TDES and it is rightfully considered obsolete.
wrt GSM the grapevine lore is that three-letter agencies lobbied for the encryption to be weak.
That was publicly and openly stated by a Nokia researcher during a local university guest lecture in the late 90s. He also strongly implied that wired traffic between base stations was specified to be plaintext for easy wiretapping.
It's all TLS nowadays :^]
It's not lore, it's a fact: https://blog.cr.yp.to/20220805-nsa.html
Most definitely still ongoing looking at history.
Most definitely still ongoing looking at history.
> . Could a public encryption standard be made secure enough to protect against everything but a massive brute force attack, but weak enough to still permit an attack of some nature using very sophisticated (and expensive) techniques?
And this, I believe, is the main reason crypto algorithms are usually broken after 20 years. They were designed to be breakable with very expensive tech, and over time that tech gets cheaper and 20 years later it's within reach of phd students and it gets broken.
If it weren't designed with deliberate weakness, some crypto might still have design or implementation flaws, but the majority would last thousands of years since the underlying math its based on doesn't suddenly get weaker.
And this, I believe, is the main reason crypto algorithms are usually broken after 20 years. They were designed to be breakable with very expensive tech, and over time that tech gets cheaper and 20 years later it's within reach of phd students and it gets broken.
If it weren't designed with deliberate weakness, some crypto might still have design or implementation flaws, but the majority would last thousands of years since the underlying math its based on doesn't suddenly get weaker.
Exactly - and they will continue to be used despite their now marginally increased insecurity.
[deleted]