Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM
iacr.org
iacr.org
Snooping on this traffic seems benign, but… security is crumbling away under ETCS' foundation.
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.
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.
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 imagine gprs will appear as an attack vector for … something
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?
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.
Are we talking obsolete SSL ciphers?
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?
> What a lovely hat
>Is it made out of tin foil?
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...
That these clowns don't use server-side scripting for this speaks volumes to why everyone should block their JavaShit.
Childish stuff like this makes sense for personal blogs, but this unwarranted hostility immediately made me distrust this organisation.
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.
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.
(Security would have to be the same as <script>)
This is not possible with a frame.
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.
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?
Most definitely still ongoing looking at history.
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.
However, there are algorithms that do make a concerted effort to mitigate these problems and advertise themselves as such, such as Ed25519.
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.
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 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.