[HN Gopher] Time-Memory Trade-Offs Sound the Death Knell for GPR...
___________________________________________________________________
Time-Memory Trade-Offs Sound the Death Knell for GPRS and GSM
Author : belter
Score : 81 points
Date : 2024-08-30 07:06 UTC (15 hours ago)
(HTM) web link (www.iacr.org)
(TXT) w3m dump (www.iacr.org)
| krackers wrote:
| >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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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_ wrote:
| 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 wrote:
| > _an ethical hacker got through the HTTPS layer pretty
| fast._
|
| Are we talking obsolete SSL ciphers?
| rocqua wrote:
| 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 wrote:
| 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 wrote:
| 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.
| yencabulator wrote:
| Many systems have been built directly on top of SMS, for very
| low-bandwidth messaging.
| eqvinox wrote:
| > 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 wrote:
| The non-Javascript message on this page reads:
|
| > What a lovely hat
|
| >Is it made out of tin foil?
|
| Oh my, very aggressive
| qsort wrote:
| > 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 wrote:
| It's not a message about websites working without JS. It's
| about browsing with JS disabled.
| hagbard_c wrote:
| 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 wrote:
| >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
| jeroenhd wrote:
| 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.
| chx wrote:
| 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.
| ikekkdcjkfke wrote:
| How many enterprise security suites offer remote browser
| isolation though
| jeroenhd wrote:
| 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.
| Cthulhu_ wrote:
| Have they considered iframes?
| pjc50 wrote:
| 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>)
| creshal wrote:
| We could call it <frame>, or maybe <iframe> since all the
| cool kids use isomethings these days.
| pjc50 wrote:
| Frames don't reflow. For headers etc people would want to
| integrate with the rest of the DOM.
| thomashabets2 wrote:
| "seamless" iframes were meant to, right? Don't know what
| happened to that.
| charrondev wrote:
| 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.
| o11c wrote:
| Obligatory reminder that XSLT exists.
| tgsovlerkhgsel wrote:
| "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 wrote:
| From the paper: "...Although designed in the 80s, such networks
| are still quite active today, especially for embedded
| systems..."
| londons_explore wrote:
| 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?
| SSLy wrote:
| wrt GSM the grapevine lore is that three-letter agencies
| lobbied for the encryption to be weak.
| Sesse__ wrote:
| Note that this applies to A5/2; the stronger A5/1 took
| much longer to break, and this is an attack on A5/3 which
| was backported from 3G (UMTS) to GSM/GPRS.
| ttyprintk wrote:
| But A5/2 and 1 shared the same key generation, leading to
| an attack replaying the recorded, encrypted stream.
| Aerbil313 wrote:
| It's not lore, it's a fact:
| https://blog.cr.yp.to/20220805-nsa.html
|
| Most definitely still ongoing looking at history.
| londons_explore wrote:
| > . 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.
| yencabulator wrote:
| 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.
| sholladay wrote:
| 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.
| tgsovlerkhgsel wrote:
| Exactly - and they will continue to be used despite their now
| marginally increased insecurity.
| Majromax wrote:
| 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 wrote:
| 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.
| eqvinox wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-30 23:01 UTC)