Services like this are actively in use by most Banks/ATMs around the world on most mobile carriers, just via creative but common reusing of long standing mobile/telco protocols.
GSMA are actively attempting to lockdown them existing methods, as they’re built on trust in a very untrustworthy environment between carriers, and in some cases state actors.
Sure on the face of it this isn’t brilliant to the average HN reader, but with context it’s a significant improvement vs where we are today.
How about an easier and better solution, stop using a broken protocol and enforcing the use of phone numbers as an identification for critical information or banking, there are better and more secure ways, and just keep the GSM network for emergencies and 911 calls.
Well, all of the 3GPP mobile networks switch to a different logic for emergency calls. In the GSM case all emergency calls (112 is hardcoded in the specification and there is a provision for both USIM and the network to add more numbers that behave that way) use different RR layer protocol that deals in physical addresses (ie. IMEI) and the whole process is streamlined. The MS that initiates emergency call will just uplink an emergency RACH frame to anything that it is synchronized with and the network will respond by allocating traffic channel for that, there is no kind of GSM signaling nonsense with multiple packets involved in that.
Difficulty: nothing that requires an end-user to understand PKI; and also would not impede a lawful (and for the purposes of this conversation: ethically necessary) police wiretap.
> nothing that requires an end-user to understand PKI
None is needed, how hard it’s for a bank handing over physical tokens to the customers when they open an account or mailing them to existing ones?
- You can loose them? Sure, just like any smartphone or even government ID, but the process after to replace is what will make you careful next time.
- They can be stolen? Same as above
- They can be used in banks or even for online banking, just tap it with your NFC enabled phone (yubico is an example)
- They can be used by someone else? Sure, just like your phone.
- However, no sim-swap attacks or similar, so in theory it’s better given no negligence from the users which is always the biggest risk anyway, but overall it’s an improvement.
>and also would not impede a lawful (and for the purposes of this conversation: ethically necessary) police wiretap.
Why would the police wiretap a banking verification, they can wiretap the transaction at the banks if they are legally authorized.
> stop using a broken protocol and enforcing the use of phone numbers as an identification for critical information or banking, there are better
There are no better ways for the average human (who doesn't have a clue what 2FA means but can understand being sent an SMS and using the code in it to access an account).
Authenticator tokens are absolutely passe right now, there probably is single-digit percentages of people who don’t have at least one Authenticator code on their phone.
And for the handful of people who just don’t have a phone… RSA/Duo tokens exist for a reason.
SMS allows a whole class of additional attacks, it’s a terrible system and should be removed.
A mobile app running on a phone that does not receive security updates anymore (or the user not installing them) and a platform fully accessible to the NSA. I really prefer hardware tokens distributed by the bank. Even if the implementation might suck from cryptographic point of view, they are offline.
Being pragmatic you’re not going to convince every Mobile network vendor to implement a new protocol, and then have every mobile operator invest in replacing their cores to support it, all in the name of a better solution.
You don’t convince, you avoid that risk completely by not using GSM as the medium of identity verification, just regulate an identity verification mechanism for banks and such, and don’t mandate it for the users so they are free to choose or opt-out.
>Traffic management of drones: the Uncrewed Aircraft System Traffic Management or the drone operator can obtain drone location information from its GPS data, however this is vulnerable to jamming or spoofing. They can query the API to verify the drone location, e.g. for law enforcement purposes or to check compliance with approved flight plan.
That’s not the real use case since not a single drone (commercial or consumer) is using the builtin GNSS in the modem (if any as most don’t even have modems) as they are usually weak compared to professional ones, the real reason is
> or to check compliance with approved flight plan.
There! Quick background: consumer drones like DJI are easily trackable by DJI AeroScope [1] which is actively used by police to track these drones in specific events, and now FAA is also requiring the remote ID is an extension to that to cover other drones. However, that doesn’t cover all drones, you have a sub-category of drones that are un-trackable, not easily anyway, the ones that fly over cellular networks, which is a challenge to know since from network perspective it’s just another UE, so what’s the easiest way to know?! Exactly, the builtin gnss, a quick query and you can tell, although I’m still not sure how they will distinguish the normal UE from drone UE. So I wouldn’t be surprised that people are disabling the builtin gnss either by the AT commands or just disconnecting the antennas.
> The API allows an application to check if a mobile device is in proximity of a given location. The API request contains the location to be checked and an accuracy range in km (between 2km and 200km). The API response indicates whether the location is within the accuracy range of the last known location of the MSISDN.
I'd say this can only "give away" the location if you already roughly know where someone is AND no rate limit exists.
Which is where API rate limits come in. But if you really need to know where someone is, today, just be a telco with its own mobile infrastructure, and you can pretty much query the current network+cell ID of any of your subscribers without any limitations.
Same goes for anyone with, say, subpoena powers in your jurisdiction and/or sufficient (social) engineering skills. And cell ID to geo mapping is also a solved problem...
Even if API rate limit exists and is strictly enforced, it's also easy to bypass it with multiple API keys and over time. Most people adhere to a weekly schedule.
The network simply has to have a pretty good idea of where the given MS is and how fast it is moving in which direction. The network maintains some kind of CDMA/OFDM/whatever radio link to said MS and thus either has to know that or learns the same data from behavior of the link. What this does is formalisation of how these data can be queried and used and by whom.
And as for some additional context: before multi-constellation GNSS receivers and such stuff, multilateriation from GSM timing advance was a somewhat good way to get precise position fix, especially with GSM PLMN that has additional support for using it for position fixes.
The FBI can already subpoena this information from your cell provider. They would even do this back in the analog cell phone days--Kevin Mitnick was nearly caught a few times because they were tracking the location of his analog cell phone.
More likely nowadays they just "buy" that location information through an API endpoint or client product from the phone companies, zero warrant required. Cops always choose the expensive "just do it" option over the warrant option because they seem allergic to the idea that their power is supposed to be gatekept and dispersed.
Keyword: Quickly.
Unlike before, now they will add this API to their OSINT software (mostly Babel X) so they can quickly access that, why all the paperwork in this digital world!!?
Subpoenas can happen extremely quickly though so don't think it's a slow process today. They just need a DA to talk to a judge and get the paperwork approved. I've heard there are judges on call effectively 24/7 ready to approve subpoenas as necessary.
> Retail marketing: a retailer Edge Application may query the API to verify that a user is close enough to a physical location before pushing a notification to them.
Hopefully by the time this is rolled out, GDPR enforcement would’ve actually caught up and forced them to make it opt-in only.
Wonder if this is in response to BeiDou having such tracking built in. There is a lot of potential value that businesses can derive from location data.
GSMA are actively attempting to lockdown them existing methods, as they’re built on trust in a very untrustworthy environment between carriers, and in some cases state actors.
Sure on the face of it this isn’t brilliant to the average HN reader, but with context it’s a significant improvement vs where we are today.