> Of the five tier-1 SIMs I just have “laying around”, four of them proactively send messages or initiate connections through the cellular modem. Since these operations are happening between the SIM and the baseband processor, they are probably completely undetectable from the application processor and its Android/iOS/whatever software.
> I hope this is the start of a much larger exploration of proactive SIMs from around the world.
> I hope this is the start of a much larger exploration of proactive SIMs from around the world.
I fear that the rise of eSIM modules will make that research ever more complex. In the worst case we'll either see BGA chips with vias to the BB chipset that can't be probed without extensive reflow work (which, in turn, may be impractical/too risky to do in scenarios where the module or the phone is evidence in court) or, even worse, eSIM as part of the BB chip or SoC.
Clearly you can set it somehow, but is is hardwired? Or changeable? What if I buy a phone from AT&T and move to Verizon, does it still talk to AT&T or now Verizon?
It would be an interesting security hole if one could modify the destination number and have it just send to a third party.
The AT&T SIM still talks to AT&T regardless of what network you are connected to. It has the full international number for the AT&T SMSC hardcoded into it so it can correctly route the message it is sending.
Most operators have a whitelist of SMSCs that they will let you use. Some even ignore the SMSC field and always route all SMS through their SMSC so if you misconfigure your phone you will still get to send SMS (and so you can't use an external SMSC to send SMS without paying your telco...)
Interesting! Would that override still work when roaming internationally, though?
It sounds similar to some providers implementing a "catchall" APN for data connections, which however has a habit of failing when roaming in my experience.
The SMS messages originate from the SIM - the same device that tells the baseband how to connect to the cell network. So it's not possible (ordinarily) to separate proactive SMS from the intended recipient network.
However, if we designed an intentionally broken baseband that connected to two SIMs, and swapped the proactive SMS from one to be sent to the other SIM's network, it still wouldn't do much. The SMSes are sent to invalid phone numbers that only make sense to that carrier's internal routing.
Those are handled, usually, by checking the network code reported by SIM and applying a specific package (usually on separate partition) to the system when doing factory reset. The selection of the packages or course varies, and back with smaller flash sizes it was common to have let's say only T-mobile but for multiple countries.
" The point here is that the cellphone literally has a mind of its own, in fact multiple “minds”, including in the SIM. These various minds might not even be talking to each other, and just because a phone did something, that doesn’t mean that user caused it."
Yes, baseband, modem f/w and the operating system work together but don't have to talk to one another.
All the fun Qualcomm PDF's seem to be missing from the net now, but there were more official/confidental PDF's that went into details besides this: https://en.wikipedia.org/wiki/REX_OS
Yes, these links are not for GSM, but Qualcomm makes GSM and these carry over as a standard, and these 10-15yr old slides are amazing and should be archived too - they used to be public even on Qualcomm sites too.
But thank you for the https://yatebts.com/ link - that is so cool, what I do with diagnostic and fun tinkering is with Qualcomm Tools that I no longer have access too. QPST, QXDM, etc.
Whenever I think the Internet protocol stack is too complex, I take a glance through the (also freely available) 3GPP specifications to refresh my perspective. They are so thick and dense it's a miracle that everything works, and I remind myself that people came up with all of it and there are probably experts who know far more than I ever will about that area. Nonetheless, I'm not surprised that they are full of little-known features like this.
Baseband chips and sim cards aren't infrastructure, but you still can't compete because getting permission to run one on modern networks is financially well out of reach for most. This is why open source inspectable firmware simply doesn't exist for these things.
All we currently have is leaked 2G and 3G source code for people to build their own off, most notable would be omsocombb
"License: Affero GPLv3 for all cellular software, GPLv2+ for some remaining software (libosmocore, OsmoPCU, OsmoSTP, OsmoGGSN)[1]" (https://en.wikipedia.org/wiki/Osmocom)
No one seems to get Bluetooth right. The specification is more than a thousand pages, and my understanding is that 5.0 is an complete rewrite (but you still have to support previous versions).
Bluetooth is, while still huge, tiny in comparison to the GSM specs. I've actually read the whole thing, although not in complete detail --- just out of interest; it's similar to WiFi (802.11).
The GSM specs aren't even available in a single document. It's split into dozens of pieces. My estimate would be in the tens of thousands of pages in total.
Would eSIM[0] improve the state of affairs with respect to privacy?
On the one hand, as SIM circuits are now being shipped with phones, I can imagine the manufacturers having the opportunity, for the first time ever, to control the operations of a SIM such that it’s no longer a black-box. On the other hand, due to legislative and practical reasons, eSIM modules would likely be no different than those black-box baseband processors with the further downside than we would also become unable to intercept the communication between a SIM (whose circuitry is now embedded) and a phone.
I would love to read the answers of those who are more knowledgeable on the subject.
A SIM Card* is a ISO card running a variant of JavaCard OS with standard APIs mandated by GSMA or 3GPP (despite it's already 5G) implemented, but carriers can (and do) add internal features for their use, to the point that some weird SIMs (no longer seen today) could also function as a debit card¤. Think of it as roughly similar to the POSIX compatibilty between Linux, macOS and *BSD, while having widly different capabilities tacked on.
eSIMs just remove the physical ISO card package and put it instead into a dedicated chip inside your phone, so in theory and in practice it could do anything a regular SIM can do.
* To be fair, I'm not familiar with how CDMA networks handle this, but this is irrelevant in the sense that CDMA (depending on the carrier) is dying or even dead already (in favour of LTE et al.).
¤ Payment cards and original SIM cards are ISO/IEC Card ID-1, the "mini" SIM cards are ISO/IEC Card ID-000, and micro and nano SIM cards are non-ISO additions by 3GPP.
eSIMs are just the SIM chip implemented in a surface mount component soldered directly onto the board. The only difference is some limited parts of the cards memory are not write protected so it can be provisioned from software.
> some limited parts of the cards memory are not write protected
This is a huge oversimplification. The card is running software that allows downloading and installing new profiles, but it will perform cryptographic validation of any payload handed to it.
Even if a SIM profile passes that validation, the resulting SIM application will be instantiated with limited privileges on the smart card (which is arguably quite powerful since it matches that of SIM applications on physical SIMs).
Even in relatively technical circles, like HN, many people are not aware of this and I use every opportunity I have to reiterate:
A SIM card is a full blown computer with its own CPU and memory.
Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time.
This means that your "phone" is actually three different computers running in concert - the actual phone itself (iOS or Android or Symbian), the baseband processor running the baseband code, and the SIM card.
As an EE, plenty of chips you can get are built-in computers. You’re not going to write code that you make your users run (what a support nightmare!). You build your chip and provide an API.
And as a user, do you really want to figure how to run someone else’s code? Or do you just want a self contained unit that you slap onto your board that you just control via API?
Funny that you needed to use microservices as the base analogy for embedded MCUs. It illustrates how large the gaps are between hardware engineering, software engineering, and programming, compared to when I entered the field in the 80's. It was possible for one person to have principal-level knowledge in all three fields. The 90's broke that.
There’s a huge gap but at the same time, each layer is still very similar to each other.
Hardware engineering might be floor 1 of a building and microservices might be floor 19. Yes, they are very far apart, but one day, you realize that every floor has a bathroom. When you go down to floor 1, you might not know where the bathroom is but you know that it exists and how it will probably function. You are already 80% of the way there.
My friend owns his grandfather's "engineering encyclopedia" from the era before WWI. At that time it was possible (and expected) for a single person to have principal-level knowledge in the whole field of "engineering".
"The Network Information Service (NIS) was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed. The name Yellow Pages is a registered trademark in the United Kingdom of British Telecommunications PLC, and cannot be used without permission."
Nowadays peripheral ICs are usually accessed over SPI, I2C, onboard USB, or some other indirect method. It is common for complex devices to have a micro on the other side handling I/O requests rather than spilling their guts to the world. That "other micro" could also be a full blown multi-core processor with an MMU running at hundreds of MHz and beyond. The difference back then is that parallel bus interfaces were king and custom ASICs couldn't necessarily afford the gate overhead of an embedded micro at all.
That's funny. I've been doing full-stack embedded development (bootloader assembly all the way to touchscreen UIs) for 30 years but the idea of trying to learn modern web front end scares the hell out of me.
React? Angular? Node? What happened to Notepad and Apache?
That ecosystem used to suck heavily as of 3-5 years ago, but I know it's improving. But you still need Node and a bunch of shit running underneath to glue the UI to the drivers.
As much as I'm starting to hate Qt, I can still have it up and taking to hardware in a few minutes. And the onscreen touchscreen keyboard is worth the money.
One of the devices I’m working on had to use rust (we were looking for some niche libraries, and we found that the C ones weren’t working, while the Rust ones did).
Building GUIs in rust is still a WIP, and I had to spend 2-3 days fixing libs and tweeking stuff to get to something that compiled but was very buggy.
Instead of losing more time on that I set chromium + apache on the thing, and built the GUI as a web app. The rust executable has a simple API with actix that works flawlessly.
In that case it was the perfect solution because I had to add an API for remote management anyway, but I found the approach quite nice to work with.
I can get a decently functional UI app working in native code with just the SDK for whatever platform it’s on, but try to use React and suddenly I’ve got a web of 200 dependencies, each more shady than the last. And that’s just for “hello, world”
Plus the JavaScript engine is single-threaded and insanely slow.. it’s gross. I’m guessing that one of these days app developers are collectively going to snap out of it and throw Node in the trash
As single-board devices get faster and cheaper by the week there's a flood of developers that have cut their teeth on Node/JS/React and they get something working on a Raspberry Pi and think "Yeah, embedded development is a piece of cake. I can do this."
And maybe they're right, because doing it all by scratch and cobbling together robot parts to make a system work is just really getting to be old.
I used to get annoyed at the RPi newbies but now I welcome it as job security because someone still needs to write the bootloader and drivers. And if you read StackOverflow/Reddit you'll see there's nobody teaching that anymore.
Man, I kinda feel like embedded software is doomed. There are only a dozen or so companies where embedded software is a first-tier product for them that gets a lot of resources put into it. It feels like everything is moving toward using super low-quality Chinese drivers/firmware and really badly-designed microkernels (or treating linux like a microkernel) to squeeze all the functionality out of the OS and into bad managed software stacks.
Then again, any company that takes firmware engineering seriously can make devices 5+ years before Moore's Law makes it feasible for others, so maybe there'll always be room for us.
It feels like everything is moving toward using super low-quality Chinese drivers/firmware
You must be a Broadcom user. My sympathies. =)
But I totally hear you. I'm not as pessimistic because I tend to follow parts that the automotive sector uses (yeah, not great right now) and they typically don't put up with random Chinesium parts and code. And yeah, it seems more and more like everyone is just throwing Linux into the mix and hoping that some OSS developer and/or Otavio Salvador swoops in and fixes things up.
RISC-V may be a way out of this. Maybe. Or it will make things ten times worse.
Notepad and Apache are still present and working. Probably not a good choice for a payment processing single page online store, but fine for a simple informational website.
Strong disagree. I do embedded development of varying complexity. I often have to learn and figure out new things, but once I have something figured out, I have it figured out, and I can drill down to hardware register level to figure things out when something is misbehaving.
Every single time I touch anything web-related I discover that the entire landscape has shifted, all the tools I used last time are now abandonware, and I have to figure out everything anew. It may be more accessible if you're starting from scratch, but it's a constant treadmill that you instantly fall off of as soon as you do anything else. And when something doesn't work? Good luck finding out what's happening in the countless layers on top of layers on top of layers.
Maybe it's just me. Vendor documentation in hardware tends to be kinda crap but there's usually plenty of other sources for information from other people who implemented something using the part, and that information doesn't get stale, ever, and documentation state improves over time. I've had problems finding reliable info on what's going on in webdev, most posts are "do this" solutions which don't really help you understand what is happening under the hood, and there are countless crappy tutorials. To be fair, I'm an extreme case, I touch web stuff once every few years, and only if there's really no way around it, and a lot happens in browser capabilities and javascript in a few years.
> but there's usually plenty of other sources for information from other people who implemented something using the part
That’s only the case if you use the small (tiny!) subset of parts that everyone uses.
If instead of using some nice and common stm32FXX MCU, you need to work with some obscure Renesas or Fujitsu for example, prepare for a world of pain.
The good thing with web stuff is that you can swap frameworks until one does what you want nicely, and leave it at that. You can’t really change the IC in your board just because the I2C module is doing something weird.
I use obscure parts. For example, just this month I've used a part that the manufacturer doesn't admit exists on their website, and a part where the manufacturer doesn't even have a website, and neither is anything widely used. But there's always a small community of people who use the part, and we cling to each other and compare notes vigorously.
Web APIs are most of the time just added, rarely removed or changed. If you ignore all the frameworks and libraries from random celebrities on github and all the FOMO on not updating them constantly, the base platform is quite solid and versatile enough.
> all the tools I used last time are now abandonware
I think you are exeggarating. Over last few years, there were no hard deprecations, except for AngularJS. Many tools, popular in past, went "maintanence mode" and receive mostly bug fixes, but these tools are still viable.
I'd certainly think so.
I almost did.
I initially learned Java on my own.
It's good to know at least one full programming language before diving into embedded programming, I think.
Then got into Arduino programming. There are tutorials for that online. Try communicating with other Chips like a Shift-Register, then something that uses a standard serial protocol (ex. I²C).
When you feel like you have a good grasp of the basics, I recommend getting a development board and doing the same there.
Most Microcontrollers (ARM Cortex Processors at least) are pretty similar:
You get a datasheet and a User's Manual.
The User's Manual describes a bunch memory addresses, which control the built-in peripherals.
There are excellent descriptions of what value will give you what result, but it can be a bit daunting to get your head around it at first.
I recommend a chip that has a so called "Board support Package". I have experience with LPCOPEN.
This will make things a bit easier, as you don't have to figure out each register address for each thing and can instead use functions like "Chip_TIMER_Enable(timer_t timer)".
There is a lot more to it, but once you get started, you usually always see the next step.
I self-taught enough to design and build a working PCB (that passed a bunch of certification testing), including writing programs for an ARM Cortex microcontroller. Took about six months of learning and then a couple months of design/implementation to get a product that can be sold and have the fundamentals in place to make similar kinds of products much more rapidly.
It's very doable with dedicated study and I'd argue it's one of the best ways to get your design ability to rise to the level of being able to build something from scratch, without reference to other code / searching google for answers.
My strategy has been to get into 80s game consoles where assembly programming was expected but the platform is small and standard enough that I can use emulators with memory views/debuggers & see everything going on.
Nice, I'd like to do this too. Which console would you recommend starting with? I'd love to see an old timey programming manual and emulators for that platform. I've heard good things about Nintendo consoles, but I don't know where to start.
I think nintendo consoles, by virtue of being the most popular of the era, and therefore the most nostalgia, have probably the best debugging/tools of the lot. Personally I'm not a fan of the 6502 as a general-purpose CPU, but it's just fine for single-tasking games and global variables (there's almost no stack space).
I'm starting out on z80 since I have an MSX and I hope to move to Sega Megadrive/Genesis later since I hear nothing but good things about the motorola 68k. The z80 seems pretty easy to understand (though it's not always consistent).
It's worth checking the limitations of the video and sound hardware to see what you like as well. I'm partial to FM synthesis so Sega consoles make sense to me. 8-bit stuff is going to land you with really tough colour restrictions (often about 3 per 8x8 square, tops). You may want to start with the "16-bit" era, which generally used 4-bit colours (16 for the whole screen, easier to create assets for).
I personally like to compare it to building houses.
Programming is laying the bricks, the cables, etc. Basically doing the actual building.
Software engineering as in other engineering disciplines is more concerned with making sure everything actually works and fulfills certain standards of quality. The planning, design and architecture part of the work.
For the last decades the person doing the programming and engineering were usually the same, but they are more and more drifting apart with more engineering focused roles like software architect.
In much of the world engineer is also a protected title that requires formal education like with doctors or lawyers. The US is using it pretty inflationary.
Shades of the 1980s and prior decades! In the 1980s, I worked in the aerospace division of a Fortune 5 company. A headhunter called me up, was chatting, and asked me what I did. I said I was a "programmer". Silence on the other end and then, "Are there any people who design programs there?" "Umm, yeah, we all do." I was book-aware of this distinction in previous decades, but this was the first time I had encountered it in the real world (of a headhunter). I see that we "programmers" are still regarded as being like the streetsweepers in Victorian London, sweeping out a path in the manure and mud for the software engineers! :) (We had software architects back then.)
There’s no line. Programming a a strict subset of, and is much smaller than, software engineering. Communication, technical writing, customer and stakeholder management, system design, technology awareness and many, many more are what make a software engineer in addition to programming.
Software engineering has a higher level view which is more concerned about the architecture of the whole system.
Programming is more concerned how it's implemented on the specific hardware/language, and how its limitations and advantages play a role in the implementation.
You can know both, they intersect in a lot of places but, programming goes deeper, and software engineering goes higher.
That's a reasonable way to look at it, but there is a missing component. In the early 1990s, I was a subcontractor at a large firm which had software people who were only interested in designing software, down to a medium-level pseudocode, after which the design was handed off to coders. These designers were great people, but, on this project, none of the firm's designers and coders had hands-on knowledge of and experience with the hardware and operating system (an early version of VxWorks). The coders would gain this knowledge and experience from writing and testing the software, but not so the designers.
My missing component was that there was no mind-to-mind feedback loop conveying this knowledge and experience gained by the coders back to the designers, from which it would inform the designers' future designs. (And there was no regular feedback about how well the design fit the problem and if the design required radical changes during coding and testing, although some of that is more an administrative concern than a technical one.) The "coders", by the way, were quite capable of designing their own programs - and did. I don't know why the firm had this subset of design-only'ers; they were smart and maybe the firm wanted to hang on to them and maybe "coding" roles were intended for brand new employees.
I don't know if you can really make the distinction, is anyone actually hired as a "programmer" instead of an "engineer"?
I feel like developer is the best name for what we do, it doesn't limit us to the act of coding and it doesn't make the presumption we're engineers (very few of us actually are).
Then again if I could choose I'd probably prefer computer programmer, it doesn't get confused with property developer and pretty specifically covers what we do.
Competent interns and other skilled juniors are usually good programmers but lack all the business acumen to be good engineers. This can’t really be taught in a curriculum, because it’s something that needs to be internalized by practice.
Kind of disagree, I haven't really needed to learn much about business other than what I picked up in a couple of business papers at uni, there just isn't much to learn about business systems as far as building software is concerned.
Any good degree should be covering all the software lifecycle stuff and general information systems as a concept.
I guess there are definitely people out there that have no interest in the business side of things but I think theyre outliers.
But now that I think about it maybe I'm wrong, I know a lot of business product people and even other developers just assume I don't know anything about business. At least that's what's happened now working for an American company. Working for Aussie companies it's just assumed that were sort of business analysts as well.
One familiar chip that end users might not expect to contain a computer is the IMU or accelerometer. Take a look at this flyer from a recent Bosch smartphone IMU:
You might think an accelerometer just outputs acceleration data. I've used some that were purely analog; as an acceleration moved a mass, a strain gauge or piezo element flexed; the output wires were simply analog signals. But these excerpts:
> ...combines precise
acceleration and angular rate measurement with intelligent on-
chip motion-triggered interrupt features.
> The IMU provides highly accurate step
counting, motion detection
> provides an intelligent power management system
enabling motion-triggered always-on features to run inside the
ultra-low power domain of the IMU
That ultra-low power domain of the IMU doesn't have dedicated logic to do step counting, it has a processor. The GPS IC has a processor. The power management IC is not just a voltage regulator, it contains a processor. The uSD card or UFS flash IC contains a processor. The camera sensors contain processors. The display controller contains a processor. Looking at a teardown, I can't see too many more ICs on a smartphone motherboard...oh, I suppose the noise-cancelling/speak to wake functions of the microphone ADC are probably also implemented by a processor. Some of those, depending on the manufacturer's vertical integration and the age of the device, are inside the SoC, but many of those functions that you might imagine to be hard-wired are actually running in firmware.
Apple SoCs have something like a dozen CPUs in them all running seperate firmware. a display processor, gpu message processor, etc. Asahi Linux has a write up somewhere.
Yeah, basically everything that you consider a peripheral is a full blown computer with its own CPU and memory. Your nvme controller, your NIC, your USB hub, etc. They main thing people need to care about is whether or not they can connect to the internet without going through the main CPU on the system. I'm not worried about storage controllers for that reason, but I'm relatively afraid of my modem.
In one SoC I am familiar with, there is a ARM cortex-m3 core (far more powerful than the original PCs), with its own firmware, dedicated to managing power transitions in the SoC like suspend-to-RAM.
This is all part of the disease of modern computing where you program against a giant machine with a giant interface and you set a few config variables and have no idea or control over how it will work and your program winds up full of unintended behavior. See: game engines, gstreamer, web frameworks, browser API, HDMI modules, terminal emulators, shells (bash, etc).
The flip side is that the more popular an off-the-shelf tool is, the harder it is to sneak something in. Someone somewhere is bound to notice fishy behavior at a certain scale. It lowers the skill level required to understand the choices you make and make better choices. I wouldn't even know where to begin trying to notice, much less explore, what AT&T is doing at 1111340002.
The more components with a million eyes watching it, the more attention you can direct toward the rest.
> Someone somewhere is bound to notice fishy behavior at a certain scale.
I'm not convinced that this is true to a meaningful degree. It's certainly theoretically true.
However, we've now had a number of events where bad things were found in fundamental and popular OSS software, and those things existed for years or even decades before being found. And who knows how many more exist that haven't been found, or at least publicized, yet (and may never be).
I think the reality is that most devs aren't deeply examining the tools and libraries they use. How could we? We'd spend all of our time vetting software and little time writing it.
So you're saying having giant IP modules inside your electronics is somehow making things more secure? They certainly don't make the product any less buggy.
Sometimes it goes down a dark path, like with Google moving all the important stuff in AOSP into a proprietary app attached to proprietary services most devices end up using to deal with phone vendors not updating. I'm not sure it's possible to come to a real determination here when the viewpoint counter to mine would require someone go find and study all the obscure little modules 2 people in the world know how to work with. The data is stacked in my favor, but it's hopelessly incomplete. I might be wrong.
> 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.
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.
> 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.
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‘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.
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.
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.
> 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.
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...)
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.
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.
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.
Every device can do things behind the users back. Intel Management Engine runs even when the computer is turned off, contains a full blown operating system and has access to tcp/ip stack.
If privacy is a concern, no device should be trusted. By device I mean anything that contains a chip.
What's worse, people might suspect their phone or PC might be leaking data to third parties, but they will be less suspecting about their TV, their fridge or their car. But since anything is becoming smart these days, one can assume that anything that runs out of electricity is a potential privacy problem.
The NSA specifically orders motherboards without these management components. No one else can typically get them, they’re not available to people like you and me.
I think some things are overblown and unjustified paranoia.
> No one else can typically get them, they’re not available to people like you and me.
Isn't that just setting the HAP (High Assurance Platform) bit in the ME blob to disable it after bring-up? For Intel platforms it is possible for the end-user to modify the firmware themselves in many cases.
https://hackaday.com/tag/hap-bit/
It all depends on the one question: What IS your use case?
Mine is as an tutor on an evening college, casual writer and some dabbling into some embedded projects. For THIS use case my (very retro) Atari 520 ST with 4 MB Ram is totally working. Is it nuts? Yup, but i can be sure that no state trojan is monitoring my totally boring behaviour.
I think you were most likely right, coz you just reminded me one incident that I talked with my colleagues regarding solar power one day and just one day after that I received a cold call trying to sell me some solar solutions. There were 3 ppl in the conversation, I was the only one without solar at home and I was the only one received the call too. How likely that would be a coincident?
Such things are so scary but what can we do? For most of the ppl, they cannot prove something like that happened. For me, I might be able to prove it but I cannot easily do it without significant efforts.
People say this all the time but literally no one has been able to prove any kind of secretive listening-based advertising.
The best explanation is that either you or someone else in your household has searched for something related and now it's appearing in your ads, or actually more likely, advertisers are incredible at linking cookies to actual users, and it's enough if your friend searched for solar panels and then his interests were associated with you. Like, advertisers can figure out all your friends have solar panels but you don't - so they show you ads for them. It's far easier to do than listening and to your conversations covertly.
If you have "OK Google" or whatever it is turned on, it is indeed listening to you.
I've seen it with my parents. They will talk about it, not to their phones, but around their phones, and they'll start seeing ads for something they talked about.
I've always had that featured turned off (I have to press the button), and I don't notice it.
My wife also sees it with her iPhone with siri turned on. I talked to her about, for example, Jordan Peterson, and her phone starts blowing up with Jordan Peterson on Instagram.
>>I talked to her about, for example, Jordan Peterson, and her phone starts blowing up with Jordan Peterson on Instagram.
And why did you talk to her about Jordan Peterson? Is it perhaps because you read an article about Jordan Peterson earlier? If so, I assume you both share the same IP at home - so she starts seeing things you viewed or browsed. Facebook owns Instagram too, so if you look at something on Instagram it's not that wild that your partner's Instagram starts showing her things that interest you - it's just association.
>>If you have "OK Google" or whatever it is turned on, it is indeed listening to you.
Sure, and that's what I meant in the first paragraph - no one has been able to prove that this feature is sending your voice to Google/apple/Amazon servers unless you trigger the key word. Recording and sending voice would create some trace and no one has been able to prove this exist. That's not me saying it doesn't exist, just that for what is supposedly wide spread phenomenon, we have no proof it's actually happening other than anecdotal stories which can be easily explained by other means.
Nothing like this ever happens to me with Alexa or Siri always listening, but I have all my web browsers locked down and I don’t use any Facebook apps/sites
Professionals and hobbyists who analyze smart phone app behavior with APK decompilers, reverse engineering suites, personal cell towers, SDN radios, SIM dongles, mobile device emulators, etc: "Facebook apps are not listening to your conversations in the background, if they were we'd have seen it here, here, here, and here."
People with anecdata about which ads they see, who think of cell phones as inscrutable magic: "No, they definitely are. I can't (won't) think of any other way they'd infer my interests in these topics. You can't see it happening because they are too smart."
Yeah, I hate Facebook as much as anyone, but they’d have way too much to lose by deploying some sort of zero day-based hidden listening tools
I guess the financial incentive might be there for some shady ad network to do it, but that’s just so much risk to take on for such a tiny gain per infected phone..
I was talking about youtube. They do listen to show more relevant videos. I live in a very quiet household and if we say something out loud low and behold it will be in our recommended later.
Again, anecdotes are not data. YouTube is extremely good at guessing things you might be interested in, you could try being completely mute in your household and then after a week you will have to arrive at only one of two conclusions
1) YouTube can read minds and they know what you just thought about
2) with statistical data from literally billions of people it's not so weird to guess what you might be thinking about and show you a video about it.
Again, if they(your phone? Watch? Toaster?) were listening someone would have found some evidence by now, a trace of voice recordings being sent or even something that looks like it might be voice recordings. Yet we have zero. It's not happening, the much easier and much more probable explanation is that we're already tracked through every online service we ever touch, but also we are linked to people we live with or people we interact with, and for a company that possesses exabytes of data it can analyse it's easier to trawl that than try to sneak out voice recordings out of your phone.
I, a layman, have had similar experiences. It seems tinfoil-tier to think my phone's mic is always on and running some NLP. If I wasn't loosely technical I would dismiss it as such.
It's basically common knowledge that if you turn on "hear me say OK Google" that it needs to always be listening to hear "OK Google". That's a green light to start parsing everything said all the time, which will be turned around for advertising. Because that's how Google makes money.
Expecting Google to use data to advertise isn't tinfoil?
But detecting “oh, this is voice” is easy. Recording the time where that happens is also easy. Knowing when people are chatting around the phone, and roughly what the fundamental frequency of their voice is, could make $0.001 per person. At Google's scale, that's worth it.
So long as they don't get caught, anyway, because that's all sorts of illegal. Especially at Google's scale. (I don't think Google does this… probably.)
It's probably that psychological effect where if you buy a red car, all you can see is red cars. How many times have you received a completely random, unrelated cold call?
From Wikipedia:
Frequency illusion, also known as the Baader–Meinhof phenomenon or frequency bias, is a cognitive bias in which, after noticing something for the first time, there is a tendency to notice it more often, leading someone to believe that it has a high frequency of occurrence – a form of selection bias.
Realistically, how many real people actually use PXE? It must be tiny. Seems strange to include what is essentially a business function in a product for normal people.
Any IT department that images devices, for starters. The number of people who actually use it is quite small, but the number of devices those people image with PXE is massive.
This was driven home to me many years ago when I popped a SIM from a Mexican carrier that had an embedded Dominos Pizza app on it. Suddenly the Windows Mobile phone I was testing had a new icon on it.
Maybe, but you'd be surprised what kinds of SIM application toolkit based products there are in the world. These are actually running on the SIM, with your phone only proxying input/output!
For example in many African countries, you have M-Pesa [1], which was at least initially entirely based on SAT.
Is it still a backdoor if it is publicly documented?
Also, the API is somewhat limited. "Installing applications" here means "downloading code to the SIM card", which arguably has always been the phone provider's property.
It's definitely not possible to install apps on the application processor OS via SIM-OTA. That would be OS-based carrier profiles, which the OS vendor has deliberately implemented.
Not really updated, but new applications can be remotely installed and then interact with the baseband and (to a limited extent) the smartphone OS.
It‘s not "any entity", though – the provider’s keys are needed to do this, and they can already do much of that tracking using other, network-side means.
They could (using a setup like the one in the article), but the payload is usually encrypted in addition to being authenticated, and such OTA updates are done for legitimate reasons all the time.
Many years ago, I worked on a serial link (think SATA, PCIe, USB 3, etc.) that had a small embedded processor to self test the link, perform analog component calibration, link equalizer calibration, and even make an eye diagram for link characterization. We could patch it with a few instructions over the JTAG port. There are way more processors in ICs than you would ever imagine.
> A SIM card is a full blown computer with its own CPU and memory.
I read something to this effect years ago and mentally filed it away as “huh, that’s interesting.” This article is the first time I’ve understood what it actually means in practice, and it’s an eye-opener.
To my understanding it’s an actual subset of Java, a very limited subset, but a subset of the real Java nonetheless. Java Card applets are compiled using a real Java compiler, and then the bytecode is translated into a simplified format for running on the card.
But I agree – Java to JavaScript is not the best comparison. Maybe a better one would be C programs written for a Unix system vs. C on a microcontroller: Same language; vastly different instruction set, OS and hardware capabilities and APIs available.
Unlike C on microcontrollers, Java Card applications are hardware and OS agnostic, though!
That's what I said, it's so limited compared to Java that saying SIM cards run "a thing like Java" is massively overstating it. It doesn't even have floats.
> Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time.
Is that equally true of SIM cards and eSIMs?
I'm in the process of setting up a new T-Mobile phone and they say they support eSIM but they are really pushing me to use a traditional SIM card. I've been wondering why they care.
An eSim is essentially a virtualization solution with each eSim profile effectively running in a container which can be set up, deactivated, and deleted only by the profile manager.
The profile manager communicates with the provisioning infrastructure in an encrypted and authenticated way, so the profiles being loaded, i.e. their code (if any) and data, are as inaccessible as those on a physical SIM.
While active, an eSim profile has all the same capabilities as a physical SIM, including remotely loading Java applications, issuing proactive commands to communicate with the network, registering for event notifications about location changes and incoming/outgoing calls…
Yup! I have at least two eSIMs myself that have SIM applications running in them that wouldn't be able to function otherwise. (The operators do IMSI switching based on SAT event triggers, from the looks of it.)
The Oracle JVM installer wizard isn't lying when it's saying that there is billions of devices running Java in the world :)
They are encrypted and authenticated, since they contain the symmetric keys used to access the network.
Without the keys of a legitimate eSim (i.e. those chaining up to a GSMA-approved vendor) you won‘t be able to inspect a profile even if you know the activation code.
Generally speaking, the SIM interacts using both "proactive commands" (e.g. "send an SMS to this number) and event downloads (think "whenever the base station identifier changes, please let me know").
Thanks! Out of these, the following seem most concerning/abusable:
* "setting up a voice call to a number held by the UICC" - effectively allows turning the phone into a bug (although not a very stealthy one, since presumably the normal call UI would be shown).
* requesting the terminal to launch the browser corresponding to a URL - triggering exploits
* providing local information from the terminal to the UICC; -- depends on what exactly the card can request, doesn't look like much except location which is discussed below
* running an AT command -- depends on the AT commands available, but I don't expect anything ground breaking
* requesting the terminal to start an application on the terminal -- depends on what exactly can be triggered (e.g. if it can trigger an app install it'd be extremely concerning, already installed apps less so), but I think it's only launching or listing already installed carrier apps.
* requesting the terminal to report geographical location information to the UICC -- fine grained tracking. This is the most concerning for me, and I wonder how/if Android shows when/if that happens (or if it is allowed). I also wonder if this can be used even when the phone is in airplane mode (to collect data and upload it later).
The geographic location seems to be only network-based (i.e. this doesn't poll the phone for GPS data, but only accesses data available to the baseband).
Hopefully, the following requirement also covers flight mode implementations:
> Where location information or
Network Measurement Results has been requested and no service is currently available, then the ME shall return TERMINAL RESPONSE (ME currently unable to process command - no service).
If both are the case, then this does not leak more to the network than it could just determine itself from signalling data. In any case, as many things in these specifications, it leaves quite a lot of wiggle room for implementation mistakes, genuine and otherwise.
As a historical note, there was a quite famous implementation of SIM-based positioning in Germany: One GSM provider implemented a "home zone" feature entirely on the SIM, by populating it with a database of cells that qualify for "home use"; this was then used to bill the landline rate rather than the (at the time quite expensive) mobile rate for outgoing calls.
Yes, a very limited one but you can put a bunch of interesting things there, the EMV standard documents how other apps should be put there so that the customer can have a card that works both as a credit card in CC terminals and also have additional features that are accessible either in specialized terminals or custom CC terminals with explicit support enabled e.g. some loyalty card or discount scheme.
However, I don't consider this aspect as any risk to the user, since when using the standard payment card functionality your card payments already have no privacy or security whatsoever from the issuer of your card, from a technical perspective the issuer will (by design) see and manage (authorize, revoke, etc) all the transactions and the card + terminal is just one of the channels for sending cardholder-initiated transactions to them. It would be technically appropriate to treat it not as "your card" but "issuer's card" that the cardholder uses as a token to use when the merchant communicates with the issuer about the bill.
I think that’s the lesson of this article — the SIM can instruct the phone’s radio to send and receive any sort of data (including SMS) without the rest of the phone ever knowing about it.
My understanding is that airplane mode does disable the radio entirely - so the SMS card trying to send messages wouldn't work unless the baseband (which, on iOS, is signed by apple and likely not an unknown binary blob to them) turned the radio on, let it connect to the network, sent the message, then turned off the radio, all without informing the OS.
Apple heavily resisted building a backdoor that would only be installed on a phone the FBI already had in their possession. Why would they build a way to bypass airplane mode if they receive a warrant?
They fought unlocking secure enclave. That has no bearing on active tracking. Apple is also under the eight ball with the threat of anti-trust regulation and are more incentivised than ever to make deals that turn down the heat on questionable business practices. They lost all credibility as a "security focused" company with their crazy on-device image scanning scheme.
I don't think the iPhone used in that case had a secure enclave. I think that iPhone was the iPhone 5C[1], which had an A6[2], while the secure enclave wasn't released until A7[3].
Wikipedia has the terms the FBI demanded, and to me they look like demands relating to software directly in iOS, not some other security chip[4].
>Apple is also under the eight ball with the threat of anti-trust regulation and are more incentivised than ever to make deals that turn down the heat on questionable business practices.
Questionable business practices impacting competition/monopoly, sure. But I don't see how a backdoor would make anyone think Apple has less of a monopoly.
>They lost all credibility as a "security focused" company with their crazy on-device image scanning scheme.
Apple publicly announced that in advance. That's different from a secret backdoor.
It can be remote but shifted in time. E.g. send a remote command that essentially says "if in airplane mode, every 60 minutes turn radio on and check for new commands".
That would cause major issues in areas where phones are forbidden for national security or sensitive equipment reasons from having antennas active. I've never heard a report that a manufacturer has even considered that idea as it could potentially cost them major damages.
Of course, that's not something that a legitimate manufacturer would have in their standard firmware.
However, that is a possibility for specific malicious firmware uploaded to some "phone of interest" to prevent its user from protecting themselves by turning on airplane mode.
Depends a lot on how airplane mode is implemented on a given device, I'd say. To my knowledge, this is not specified by the relevant standards.
One way would be to shut down the SIM as soon as it's activated, which would include proactive commands of any kind (like those the SIM uses to request sending an SMS from the phone/baseband).
Another would be to keep the baseband and SIM active, but to still deactivate the radio – in this the SIM might still be able to issue proactive commands, but without any network attachment, they would just fail.
Of course an implementation could also choose to briefly reattach to the network whenever it receives such a proactive command.
Besides operators, individuals can also send OTA settings like APNs, proxies, etc. from a SIM card to SIM cards on another network. To the recipient, the message looks just like the settings you get from local MNOs when you first get connected when roaming in another country.
And where has that got us? Surveillance states, the whole… *gestures at Facebook* thing, insurance companies having access to your medical records. The oceans are full of plastic!
You'll never get the update then that it's confirming it installed. And you can't make phone calls. And you can't even use it unless you can get inside the cage. I guess it if comes with solitaire you could play that or something.
> And you can't even use it unless you can get inside the cage.
Bag not cage (though the bag is technically a Faraday cage you aren't actually entering it as it's only big enough to hold your phone). A small faraday bag is available for ~20 on Amazon.
>They can do this at any time.
You can decide when you get updates and when you want to allow yourself to be tracked by whatever corporations, governments, and other actors that seek to track your movements. It's a false paradigm to suggest (like most people on this thread are doing) that you have no choice but to allow yourself to be tracked 24/7 or to go without a communication device. Keep your phone in a small shielded bag, remove it when you want to make calls, check your messages and are willing to divulge your location - its not rocket science.
Assuming the cage works perfectly (taking out the battery if possible seems a safer bet), the only thing you actually decide is when you get it out of the cage to use the device. However at that point the device can communicate and you cannot stop it from doing whatever it wants to. In other words: you decide you want to call, and if the thing decides it wants to update it might also do it at that point.
That's a bit like saying "most of the space of a smartphone's persistent storage is empty and otherwise used to store photos and videos" when talking about smartphone operating systems and their security.
What do you mean by "original SIM"? As far as I know, SIM cards have always been specified in functional terms, so vendors were always free to implement them whatever hardware and software they choose, as long as the result complies to ISO-7816 and the relevant ETSI/3GPP specifications.
Today, it's mostly Java Card implementations, meaning that the ISA and smartphone OS/runtime is abstracted away in any case.
When I read about "binary blobs" present in electronics like in a SIM, a baseband processor, or DDR memory controller or CPU management engine, the risks they pose seem distant. This opens my eyes a bit to that they actually do phone home, hidden from and unblockable by the OS.
The Pinephone is just like every other phone in this respect. The baseband runs a closed blob that talks to the SIM and can send arbitrary SMSes of its own accord.
There are no viable fully open source phones in existence today, particularly the baseband.
The more practical question is around whether those binary blobs can take over your OS, not just do things behind its back. This is what sets apart devices like the Pinephone and Apple M1 Macs (which make an effort to isolate blobs from the main OS running on the AP) from typical Android phones and Intel PCs (which have blobs in hyper-privileged positions that have full access to the entire system).
Yes, I'm putting Apple M1 machines on a similar level as the Pinephone in this respect. How well designed a device is from a security/privacy perspective is tangential to whether the manufacturer markets themselves as an open source friendly company. It turns out Apple have done a great job making sure even their own blobs aren't allowed to take over the system. Once you run you own OS on an M1 machine, you're in a similar security position as on a PinePhone (though not exactly the same; M1s run more blobs, e.g. the display controller, so in principle a colluding set of malicious blobs could do more damage that way, but they still wouldn't be able to directly compromise your OS's execution).
I would put the Librem 5 in this category too. The baseband is treated as untrusted, and isolated in every possible way from the application processor.
Can that closed source blob be bypassed and still allow compatible communication with carrier networks? Or is there some ip or contract nonsense that allows Qualcomm this stranglehold?
This seems like exactly what we dealt with in requiring phone companies to allow dialup modems to connect to whoever the customer wants, and so on. Seems shady as hell.
There are significant regulatory issues involved. In principle it's possible (see osmocombb), but the legal hurdles around actually having user-controlled basebands in a shipping product are significant.
Of course, nothing says the baseband couldn't be open source, and even if codesigning is involved, the manufacturer could sign verifiable builds that can be reproducibly built. That should solve all regulatory concerns while still allowing users to inspect the baseband firmware for flaws or backdoors.
But, of course, no actual baseband manufacturer cares about that.
Besides the technical difficulties (trying to reverse engineer the modem internals and reimplement the firmware with no clear reference; likely encrypted and signed firmwares; etc) there's a good chance there's also legal issues.
If the hardware itself is capable of operating outside of its license (frequencies, modulations, etc), then various certifications from the FCC would likely be invalidated by replacing the firmware and it would become illegal to operate.
I guess I was thinking more in line with SDR or foss hardware and not using Qualcomm at all. I need to do a deep dive, but it looks like there's a couple FOSS 4g LTE and 5g modems around - maybe running a soft phone and personal voip setup would bypass a lot of the security concerns.
It sucks that any time you start to inspect almost any tech, there are assholes trying to exploit every last bit of data and microamp of processing power to screw you in some way.
SDRs are for research and base stations. Trying to do a mobile phone based on an SDR stack would eat through your battery in minutes. You need dedicated silicon.
Nobody knows anything for certain about literally any consumer hardware in existence, because silicon is not end user introspectable. If you want to go there you have to look at Precursor (which uses an FPGA and can make the claim that a backdoor is infeasible in that architecture).
But what we can say is that we know that Intel has hyper-privileged backdoor modes and coprocessors, while every single thing I've seen so far about the M1 indicates it was carefully designed to isolate all coprocessors from the main CPU. Everything is either behind an IOMMU or can't do DMA at all or has some other form of address filter. And knowing what I know about Apple's security posture, it's entirely logical that they designed it this way.
> In short, unless you explicitly send data to the modem, it is never in contact with the blobs running inside it. The modem cannot send any data to the phone unless phone is willing to receive it
I guess there are some legal concerns with open source modems
You can't disable STK applications: They are an integral part of the SIM card. If anything, you could hide the user-facing icon, but that wouldn't do anything about any background processing the applications might be doing.
However, they can only interact with the baseband in any case: While that still allows extensive tracking and potential mischief (like making expensive calls on your behalf), this is nothing your phone provider can't already do, i.e. knowing where you are and bill you arbitrary amounts for services you might not have initiated (when on postpaid).
> what a telecom engineer would call an “NANP E.164”.
NANP and E.164 are standards. NANP stands for North America Numbering Plan. E.164 is the international analog to NANP for public numbers. No telecom engineer would call a number an "NANP E.164." The number of a network element like an SMSC is simply called an address.
I just wish authors would stop trying to add random (and wrong) technical information to sound cool. The topic was interesting on its own without embellishment.
Not wanting to downplay the security implications of the SIM OTA/SAT infrastructure at all, but I think in this case, there is also a non-nefarious explanation:
Back in the day of feature phones and early smartphones, carriers would proactively send device connectivity profiles (not sure what the technical term is) containing things like MMS and WAP configuration data to any new phone on their network.
This might just be AT&Ts way of implementing the trigger for such a system. Obviously it would be unused today (iOS and Android don't support these profiles anymore to my knowledge), but these technologies generally have a very long tail.
> iOS and Android don't support these profiles anymore to my knowledge
Sure they do. You can configure them under the "Access Point Names" setting page in Android (buried under advanced network settings). Some MVNOs need you to input all that configuration manually when you first connect.
Ah, I think I was unclear – iOS and Android phones don't support updating these profiles via SMS anymore in the way that some older feature- and smartphones did.
The first time a network would see a new device (or after a long period of inactivity), it would send these out automatically, which was mostly useful but at times annoying when switching phones regularly.
There was usually also a way to manually trigger them, like sending a certain text (e.g. SETUP) to a short code.
Of course iPhones and Android smartphones still need APN and MMS data to function correctly, but these days that data seems to be part of the OS. In my view, that's a step back – I've had to get onto Wi-Fi to look for the correct APN for a travel SIM more than once. Arguably, it should be part of the SIM these days, just like the SMSC configuration.
We've (probably) arrived at one of those "hidden" dominant operating systems out there in the world: JavaCard OS. It's not just (probably) in your cell phone SIM, it's also (probably) in your credit cards. Add all of those devices up, and you realize that, in a weird way, if aliens were to inspect the activity of humans, they'd say, "the humans seem to be using some sort of weird thing they call 'JavaCard OS' to run their society."
If anyone is a JavaCard OS master, shoot me an email - numair@numair.com. I'm having some IC card issues that could use some external input...
In terms of the linked article, I think this part makes it clear what's going on, if we are to take an innocent view on things:
> After the lab work, deposition of an AT&T employee revealed that the only other trigger is a firmware update of the baseband processor. That is also consistent with the SIM requesting the IMEISV, since the “SV” part means “software version”, and it is updated every time the baseband processor loads new firmware. In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message.
If I was a network engineer, I'd probably want a way to figure out whenever someone's putting new equipment on my network. This is a brilliantly sneaky way to do it. There's probably other uses for this, though, and you can imagine that your favorite intelligence agencies have thought about it long before it showed up in a Hacker News article...
Is this the card "technology" that ran DirectTV tuners as well? I had a friend who was, at one point, running 7 hacked systems, and recording everything he could to burn to DVD, but I never got into that.
All cable systems in the US are mandated to supply users with those "CableCards" if they request them to decrypt cable tv channels, so you can use your own tuners and not be forced to rent one forever from the cable company. So, it wasn't just Dish. TiVo also uses them. The first one was free and the second one was $1.50/mo. Each could decrypt 4 simultaneous channels. I used them for about 15 years until cancelling cable earlier in the year. $1.50 vs a $30 cable box saved quite a bit over the years.
Here's the page on xfinity for them. They're just PCMCIA cards, which used to be popular. My first laptop had a PCMCIA port which I used for a GPS device in the 90s before they were all-in-one chips. https://www.xfinity.com/support/articles/about-cablecards
A long, long time ago it was possible to decrypt the original VideoCrypt with a serial connection attached to a smart card that ran software like 'Voyager' that could decrypt or bypass the keys/locks necessary to decode. This was running on a 286 laptop. Seems like an absolute lifetime ago now.
And before CableCards some cable settop boxes had FireWire/IEEE1394 ports on them that provided the raw video stream. You still had to rent the cable box though.
Not a Java Card expert by any means (more of an interested party), but are you able to share what you're working on? I'm always curious about new smart card use cases :)
It’s the next thing on my list of things to write — and related to a very weird security vulnerability I’ve found in a lot of corporate workflows — so, it should be done sometime this month.
I opened https://numair.com in a new tab so I could stumble on it in a bit (figuring this info would turn up there), only to discover a parking page (and TLS cert Chrome did not like). Double-checked the spelling twice.
Is it just an email domain? Where can I eventually read about this? Very idly curious :)
Yikes, sorry — this is one of those domains that got registered in the InterNIC days and transferred off years later, so I never bothered to move the A record to an IP that doesn’t use an obnoxious parking page. I’ll add that to the to-do list. It is very much email-only at this point.
I’ll probably publish the paper on my company website, once that’s up — having a bit of an identity crisis at the moment to figure out whether everything gets done in English, or Japanese, or both — probably both...
Ah, I see! Very cool. (And also cool to learn that domains showing parking pages can send/receive legitimate email. I would never have expected that!)
It would make a lot of sense to translate to Japanese if the issue is Japan-specific, but I can also see good justifications in simply releasing papers in all the languages :). That being said, if I had to pick a language to prioritize, well, it'd be the language with the widest security audience. Yep.
Look forward to seeing the paper :) (thanks for the email)
If the SIM can act as a TPM for the binary blobs and report tampering, it could be the TLAs have actually been doing what they are supposed to be doing: securing infrastructure.
The sim cards cannot be used as a secure element or a TPM in most android phones. The SWI lines that connects the SIM to Android are cut in most hardware designs.
Google cuts them in the nexus (with one nexus having a notable exception), Samsung cut them and forces you to use their embedded secure element.
If my cellphone's code can be used to "hack" my carrier, we're one open source project away from game over. Which in some ways is the SS7 hack, but I having been following the cell phone companies responses, so maybe that did get secured against.
Can somebody recommend a good book/paper/video/etc. on Cell/Mobile phone HW/SW/Internals and Hacking (everything other than the Application Processor and its OS i.e. Android/iOS). The only one that i am aware of is an old paper by Harald Welte named Anatomy of contemporary GSM cellphone hardware.
It's interesting that this message even came up when the user's messages were subpoenaed. This was not in the set of "user messages" and a case could be made for not including it at all.
There are all sorts of carrier specific messages that phones communicate. Carriers have systems that detect anomalous activity and blacklist them from towers because they assume the handset is broken and they don't want it to cause problems for other subscribers.
Yep, there must be some kind of flag on the message payload to indicate Siri dictation. I wonder if that flag gets sent through SMS at all though, if the recipient is not on iMessage. My guess is there’s nothing in the SMS spec for arbitrary user data like that, but maybe I’m wrong.
To me the process sounds like a regular ping and registration process. After all SMS was designed as a "ping protocol" and someone with a bright idea monetized it! #respect
Why is this number even on the list of SMS activities? Isn't that list compiled and issued by AT&T? Couldn't they just hide those target SMS numbers because they are, well, they could say, needed for technical implementation of SMS processing? It puzzzles me that they list these and afterwards do not tell what they really are.
Presumably when AT&T is answering a court subpoena they have a duty to supply complete information, and in any case the legal and technical parts of the company don't talk to each other much.
I was wondering how AT&T knew I got a new phone when I just moved my SIM over. That seems like a over complicated way to do that. Seems like when it does the initial handshake with the network the different IMEI would be enough (unless this is the initial handshake).
It is always a pleasure to watch the young ones rediscover the world. :D
Yes, carriers should be more transparent. Yes, even in general IT circles, this is not well known. This is known and not surprising in digital forensics circles. You should have seen the SS7 shenanigans!
I have a special corner in my heart for AT&T. The dark, dank, where all-my-monsters-live corner. Once, I have asked them to send me telco logs, they sent me 30 some CDs with the logs, but only origination details. Then, on further legal nudging they send me the other half, again in 30 some CDs. 60 CDs. They didn't even fill the discs, so the entire DB ended up to be ~17GB.
>The RP destination number, +14047259800, is a normal-looking US number, what a telecom engineer would call an “NANP E.164”. A Google search turns up documents showing that this number is associated with an AT&T “service control point” (a sort of server) that was made by Sun Microsystems. This is most likely a Sun Solaris server running an Oracle SMSC package, physically located in Atlanta, GA. Interestingly, this is not the SMSC number that AT&T uses for normal texting (+13123149810). This is a special SMSC that is used for special applications.
How many SIMs has AT&T around? (I assume millions.)
A single Solaris server (which I imagine to be a little dated) can manage the whole stuff?
It must be pretty much efficient or these data must be transmitted very seldom.
> A single Solaris server (which I imagine to be a little dated) can manage the whole stuff?
I don’t know what they run, but Oracle still sells some quite beefy hardware. SPARC M8-8 servers can have 8 CPUs of 32 cores each, for a total of 256 cores. The CPUs are clocked at 5 GHz and use a 20nm process. Maximum 8TB of RAM. The CPU and the process are somewhat dated but still can do a lot.
Fujitsu has even beefier SPARC servers - the M12-2S has 12 CPUs, 384 cores, max 48TB RAM, albeit only at 4.25GHz. Fujitsu SPARC servers run Solaris too and Oracle resells them.
So I’m sure SPARC can handle this use case, just not very cost-effectively-whatever it can do, an x64-based solution is likely to be able to do the same cheaper. And it is a technological dead-end - Oracle plans no further CPUs or major OS versions, but they’ll keep selling their current lines as long as people are willing to buy them. Fujitsu is moving away from SPARC too. Rumour has it Oracle and Fujitsu were negotiating for Fujitsu to buy the SPARC hardware business, but they couldn’t agree on terms, and now Fujitsu has decided to move away from Solaris/SPARC and towards Linux/ARM instead. Fujitsu still have a new SPARC CPU release this year on their public roadmap, not sure if it is happening, but if it does it is probably their last.
That Oracle-Fujitsu SPARC acquisition rumor is fascinating. Do you think Fujitsu's A64FX line can hold its own against Ampere's stuff and the AWS Graviton CPUs?
In this case, it would be transmitted only when a SIM is turned on in a new device for the first time. Probably still a lot of traffic, but a drop in the bucket compared with the remaining signalling traffic a large mobile network sees every day.
These systems can probably also be scaled almost without limitation for the same reason.
>In this case, it would be transmitted only when a SIM is turned on in a new device for the first time.
But this is seemingly not what happened in the case at hand.
>In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message.
So, every time the baseband firmware is updated, likely millions of devices need to send that SMS to that single server, unlesss the updates are deployed somehow sequentially.
And if these firmware updates happen not very often, which probabilities were that just after such an update the person (suspected of distracted driving) crashed with the car?
Like 0.00000000001 or very, very, very rare chance.
That's a very valid concern, and maybe there was just such an "event flooding prevention" mechanism at play, deferring the IMEISV report by a random time?
I'm not sure that I would like the SIM to send data to anyone without me knowing it. But since both Android and iOS send user data without the user acknowledging, it might not be the biggest privacy issue.
This type of stuff makes keeping phone in a faraday bag carrier when not using it seem much more appealing. Pacsafe sells a nice one (or used to?) for like $40-50.
I am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print.
But I am not sure if this is legally clear cut under the regulations of the GDPR.
> I am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print.
> But I am not sure if this is legally clear cut under the regulations of the GDPR.
> I am wondering if this is also happening in the EU or with customers from the European Union. The provider would probably put something to the effect of "we can do what we want" into their fine print.
> But I am not sure if this is legally clear cut under the regulations of the GDPR.
Those messages are part of the original reason for SMS existence, and yes all networks use them - both remotely triggered and unsolicited like in the article. They are vital to operation of the network. Allowing end users to message over this channel was a relatively late addition to the spec.
Effectively, for many good reasons, the demarcation point between your part of the device and provider part is the interface between application processor (what runs Android/iOS etc) and the baseband processor which handles the stuff you need a license for, with the licensed party being effectively the provider.
When it comes to GDPR, what actually happens is that the providers can't escape handling PII anyway, as it is crucial for their operation. Usually it means that there are some heavy safeties on access to PII, both practical and legal, but operations crew has a lot of capability and thus responsibility.
Main difference seems to be that in EU, the carriers can't get away with as much monetization of this as they can in USA.
The mechanism described does not give any information to the network that it doesn't already have: The IMEISV is part of the regular network sign-on procedure.
This is probably just an optimization so that they don't have to keep track of changing IMEISV/IMSI-pairs in their database, for whatever they do with that.
In fact, it might be even more GDPR-respecting than the database alternative: If the purpose is to trigger some updates that should happen with every phone switch, it removes the need to track this data server-side.
Realistically, it will be stored anyway, as mandated by many countries' data retention laws.
I'm not sure why this would make the suspect innocent ? Couldn't it be the situation that the person was doing an update and that distracted him during driving ?
I don't think the article is alluding to the suspect being innocent, just that this specific "text" was automated and can be ruled out as having been physically sent by the person in question. Other texts around the same time could still make them guilty of distracted driving.
Updating baseband firmware is like updating your network router; it's likely to briefly interrupt the connection.
They're applied by the operating system, so the OS is going to choose to automatically do them when the phone is locked with idle network traffic. It's probably more of a sign the phone is not in use.
It doesn’t make them innocent (is innocent the right term for a lawsuit?) but it does mean this particular fact isn’t evidence of anything related to this case.
This is a firmware update of the SIM/underlying hardware. It’s not like an OS update to iOS or Android. It’s more akin to an automatic BIOS update, but for a piece of hardware that is modular. Think Realtek driver on a NIC.
A while ago(3com905(X) I've been more into firmware, having heavily modified them, and much later on dabbled with Realtek Wifi. The latter usually had some Mips3000 lookalike on them, partially less, partially more because of DSP and such. This should also apply to gazillions of cheap switches which can be configured via some Windows app.
So, except if you are referring to something like a RTL8139(X), I wouldn't be so sure :-)
Both of those are hypotheticals the other side would have to provide some evidence to support in court
The investigation here was grounded in an attorney reading a report and saying “look person sent a text message at time x just before crash” and a forensic analysis instead showing that the SIM card sent the message not the person.
That debunks the claim of distracted driving based on the text message timing. That’s the point, if they have evidence someone was swapping sims or interacting with the phone to run and update that’s an entirely separate matter
Why would the type of driver who wants to putz with the phone while driving choose to kick off a process that will make the phone unresponsive for 15 minutes?
Changing a mini/micro/nano SIM, removing it from one phone to insert it in another one while driving would be IMHO the "essence" of distracted driving, BUT in this specific case it was an (automatic? or previous?) update, from the article:
>In this particular case, the phone had recently downloaded an update that included new baseband firmware. That was almost certainly the trigger for this message.
The "recently" is "vague" enough, as we don't know how much time passes after tyhe update for the SMS to be sent by the SIM, it could be milliseconds but as well several minutes or even hours.
Reminds me of how I ended up with a U2 album on my iPhone. I never put those files there not asked for them or gave permission. Made me wonder what else could they plant on my phone.
I mean, you're talking about a bit of a different thing here--something done by the operating system and hardware vendor.
So the answer would be "literally anything". Apple could push an update tomorrow that bricked your phone, turned it into a listening device, caused it to _only_ play that U2 album, etc. Ditto for Google (Android), Microsoft (Windows), etc.
> Of the five tier-1 SIMs I just have “laying around”, four of them proactively send messages or initiate connections through the cellular modem. Since these operations are happening between the SIM and the baseband processor, they are probably completely undetectable from the application processor and its Android/iOS/whatever software.
> I hope this is the start of a much larger exploration of proactive SIMs from around the world.