Hacker News Reader

Comment by lxgr | Hacker News Reader

> Your carrier can upload and run arbitrary code without your consent or knowledge.

Well, arbitrary sandboxed code.

I agree that by today‘s standards, the APIs that code has access to seem excessive and are well worth trimming down, but some of them are vital to the network‘s internal operations (like OTA updating the list of preferred roaming partners), while others enable new use cases (like M-Pesa mobile payments).

For example, multi-IMSI SIM cards are, in my opinion, an ingenious solution enabling entirely new products and bringing much needed competition to an industry that had been pretty stagnant (international roaming). That would not possible without the SIM application toolkit.

View on HN

Can a hobbyist mess around with this at all?

Edit: yes, but I wonder how much trouble you'd get in putting this into a real phone?

https://www.aliexpress.com/item/32900944064.html?spm=a2g0o.d...

Probably none at all – such a SIM wouldn't have the required keys to even connect to any real network.

SIM cards are just Java Cards, after all – the secret sauce is the proprietary software running on them (the ones you've linked seem to come with an implementation of that pre-loaded) and of course the keys they hold.

Nobody keeps you from implementing all the SIM specifications in an open-source Java Card application, and I would in fact be very intrigued to see it happening ;) As far as I know, experimental/hobbyist GSM networks, like the ones running at some conferences, are still using proprietary SIM cards, and an open source implementation would be very interesting to study.

TFA has links to the tools used. You'll find Osmocom.org an invaluable resource.

I've put test SIMs in plenty of real phones, before tossing them into an RF chamber to talk to the network simulator. The real network doesn't seem to care.

It makes sense that they don't: If you're using an unregistered/test MCC/MNC id as part of the IMSI, they would just consider your phone a roaming guest that they can't provide services to.

Even if you'd be using an actual IMSI (not recommended – this seems like a legally more gray area), you would just fail authentication with that provider's AuC and the network would not let you register in what would be the GSM equivalent to a device trying to connect to a Wi-Fi with the wrong password.

> some of them are vital to the network‘s internal operations (like OTA updating the list of preferred roaming partners)

That should be the phone's job, not the SIM card.

> while others enable new use cases (like M-Pesa mobile payments)

That should be the phone's job, not the SIM card.

For mobile payment, the SIM acts as a means to sign messages in a way that is difficult to spoof, as you cannot directly access the cryptographic key on it. This existed and worked long before secure elements or TPUs were on the scene.

That requires phone manufacturers to consistently send out updates in concert with many many phone carriers, including new ones no one has never heard of. I do not trust a single carrier to do that

True – not even Apple gets this right, being otherwise pretty good about timely software updates.

My MVNO started being recognized incorrectly as being part of another network years ago, and apparently their engineers have been unable to reach anyone within Apple about the matter and get theem to apply what should be a trivial fix in their IMSI mapping table.

Apple has never been good in this department, according to the folks I've talked to within mobile carriers.

Even Google, a nearly $2T company, operates an MVNO ("Google Fi") that does not work properly on the iPhone, because Apple has not added Fi's GID to the correct list.

Jailbroken users can (in theory) add Fi's GID to T-Mobile's "carrier bundle," and things like Wi-Fi calling, 5G connectivity, etc will work instantly.

I believe this is because Apple don't want iPhone to be used in unapproved network. Apple want to sign agreement with network operator to sell iPhone.

Originally there was a technical reason for that: Google Fi uses several carriers, not just T-Mobile, to increase coverage, and at the time preliminary iPhone support first came out for Google Fi, iPhones didn't have support for connecting to two carriers at once and switching back and forth between them based on signal.

So right now, someone on Google Fi with an iPhone and someone on Google Fi with an Android phone can be standing next to each other, and the Android phone could have great signal while the iPhone has zero signal because T-Mobile has no coverage at that location.

I don't know if iPhones now support that; if they do, then there's no longer any technical reason iPhones couldn't have first-class support for Fi.

> That requires phone manufacturers to consistently send out updates in concert with many many phone carriers

The carriers could still provide information about their network, via a standard API.

I'm talking about how this should work if designed well, not incremental steps to get there with non-cooperating entities.

> I'm talking about how this should work if designed well

I think that I've fantasized about this magical land with literally every system I've ever worked with in my entire career, including ones of my own design. I've come to suspect that utopia simply doesn't exist.

> That should be the phone's job, not the SIM card. [internal operations]

Maybe, but what would inevitably happen is for network operators to demand that only certified devices, or maybe basebands, be allowed on their networks.

SIMs are a big reason of GSMs (and its successors') success: Having a trusted computing device to allow for key management and a few other things inside an otherwise untrusted/sandboxed phone was the compromise.

I'm all for making the interfaces used less opaque and less prone to be used for shady purposes, but the concept of SIM cards is a net win for everyone, in my opinion.

> That should be the phone's job, not the SIM card. [applications]

If you have a smartphone, it is. Many people still don't own one.

USSD is an alternative and is starting to be deployed in many markets previously using SAT, but it seems much more cumbersome to use and is less secure too (no trusted client side storage and tied to the security of the underlying transport protocols).

> Maybe, but what would inevitably happen is for network operators to demand that only certified devices, or maybe basebands, be allowed on their networks.

There was already a battle between AT&T and people who dared connect phones they actually owned to the phone network, and it ended well for the general public and badly for AT&T. The cell network should not get to determine what people attach to it; it should just pass data back and forth.

(In an ideal world, the cell network would have absolutely nothing to do with phone numbers, either; it would just pass data, and phonecalls would always happen over encrypted channels to your actual phone-number provider.)

> the concept of SIM cards is a net win for everyone, in my opinion

Public/private key crypto doesn't require a card that can also do other secret operations. And it doesn't require a smartcard either.

> The cell network should not get to determine what people attach to it; it should just pass data back and forth.

I absolutely agree.

> And it doesn't require a smartcard either.

There are many good reasons why a counterparty does not trust you (fully) with a set of keys.

The biggest one is keys that allow financial transactions or billing events to happen: It makes the "I lost my password" defense for friendly fraud much less credible. Another can be to discourage sharing of a service (i.e. "account sharing").

Now there's two ways to keep "your" keys safe as a service provider: You build a fully locked down platform and only allow devices sold and made by you to attach to it (and play your content, use your phone network, transact on your payments network etc.), or you standardize the interface to the "key jail", keeping the rest of the device open and accessible to independent security research.

You can call such a tamper-proof device holding some issuer's private or symmetric key any way you want – functionally, it will be very similar to a smartcard.

> There was already a battle between AT&T and people who dared connect phones they actually owned to the phone network, and it ended well for the general public and badly for AT&T.

The now reformed SBC/AT&T is doing something similar - only devices on this list[0] can connect to their VoLTE network. Without registering for VoLTE, the phones will not be able to connect to the network.

Even if a phone has full VoLTE compatiblity (the OnePlus 6 series, for example), if the manufacturer does not work with (read: pay) AT&T for certification, it will not be allowed on their network.

This is illegal under California SB822[1], which among other things prohibits the blocking of "nonharmful devices" on networks - but AT&T, along with the other major carriers, are currently acting like this doesn't exist until they're forced to by abide by it by a court of law.

[0] https://www.att.com/idpassets/images/support/wireless/Device...

[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...

> [W]hat would inevitably happen is for network operators to demand that only certified devices, or maybe basebands, be allowed on their networks.

This is already the case.

In what way?

I‘ve heard that in the US, some providers are still insisting on this (essentially a leftover practice from the pre-SIM days!), but at least in Europe I‘ve always been able to use any phone I like, even really obscure ones.

My experience is in the US. PTCRB is the standardized one. Even on top of that, AT&T has additional testing (see TRENDI, which is a whole lot better than what they used to require). Verizon has their own idiosyncratic process where you don't learn what standards you need to meet until you submit a request for testing.

The carriers don't use technical measures to keep uncertified devices off their network. It's still usually a violation of the terms of service. And yes, that means that aftermarket PCIe-form-factor cell radio in your laptop is theoretically a problem unless that precise laptop + card combination has been certified.

> Many people still don't own one.

And when my current smartphone dies, I'll be joining the ranks of those who don't own one. I'm aware of two other people who are also moving back to dumb phones. I wonder if this is going to become more common as time goes by.

I strongly disagree on the first point. The carriers used are entirely an issue with my carrier. I don't use a phone that's in any way associated with my carrier, and I expect the SIM card to "just work" when I put it in a phone.

Would you rather have to copy-paste an arbitrary list of parameters into some preference menu option every time you travel internationally?

(Ironically, SIMs are falling short on this end quite a lot since they don't allow providing GPRS and MMS related configuration, which means that now we have SIMs and manual lists...)

I'm confused by what you're saying. I'm disagreeing with the comment saying that SIM cards being smart is bad.

Ah, sorry, I must have misunderstood you or mixed up comments!

Yes, I agree that SIMs being (moderately) smart helps them to just work in a new phone without any affiliation with the carrier.

It's not perfect, though – APN settings are annoyingly part of the OS when they should arguably be a SIM and baseband implementation detail like the SMSC, for example.

> Well, arbitrary sandboxed code.

But a sandbox that has access to very sensitive data.

Much of that data is already available to the provider (the only entity able to install new SIM applications) anyway: Cell location, incoming and outgoing calls, your IMEI... They already know all of that!

There are some notable exceptions, like the ability to initiate voice calls possibly without any user interaction, and I'm all in favor of removing those from the specifications. I'm not sure whether modern devices actually implement these.

The only remaining concern then is weak authentication key security, i.e. allowing unauthorized third parties to control SIM (and by extension phone) behavior, potentially without the operator's knowledge. This seems like a very similar concern to weak phone network signalling stack security (like being able to intercept SMS via SS7), which is an ongoing problem too.

Reply on news.ycombinator.com