> The combination of the ICCID and the IMSI basically tells the mobile network, “hey, this person paid for a plan.”
As far as I remember, the ICCID never actually appears in standard network messaging. It might be possible for the network to request it, but it's not part of a standard 2/3/4/5g attach.
The piece seemed to miss two major uses for the IMEI (or I missed it when reading), which were working around vendor bugs and allowing emergency calling.
Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful.
GSM (and onward) actually supports a handset attaching to a network, even without a SIM card, for the sake of emergency calling. It needs some form of unique identifier for this to work. As much as it could (potentially, entirely redefining the stack) generated UUIDs, it makes some sense for these unique IDs to persist across roaming/sessions/reboots.
> Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful
Now that it’s common for devices to be updated regularly, they will typically send an extended form of the IMEI to the network called the IMEISV, which is the same as the IMEI except the final check digit is replaced with a two-digit code indicating the current software version (SV = Software Version).
Probably not a lot. It needs to have a fixed length on the wire, and having 100 updates to the radio firmware for any given model of handset... not likely?
> As far as I remember, the ICCID never actually appears in standard network messaging.
Yeah, that would be the IMSI (which a given SIM card can have multiple of, e.g. for switching to a more beneficial home network while roaming!)
The ICCID is useful for identifying a given physical SIM card (e.g. so that the phone can link a given user-selected profile name to it/the associated phone line for a "preferred line for contact" indicator in dual-SIM phones), and probably also as an identifier when dynamically assigning a new IMSI over the air.
> for the sake of emergency calling
The IMEI can indeed be an identifier of last resort for emergency calls. I wonder if some countries use it to block abuse/spam calls to emergency services, or more importantly, why some others aren't?
In Germany, for example, SIM-less emergency calls are no longer possible, supposedly due to many people calling the local emergency number to test whether a used phone is in working condition without inserting a SIM card... I don't know what they're doing with the IMSI in that case, and if it's locking these callers out, why they can't do the same for the IMEI.
At least in the US, the 911 infrastructure is dated.
In older systems, your caller ID is sent using in-band DTMF tones, which are decoded by the dispatch computer.
On newer E-911 systems they get some additional digital address data from the telephone network, but the record format wasn't designed with VoIP or cellular in mind. So in those cases, the telephone network sends a virtual number and the dispatch computer does a seperate out-of-band lookup with the VoIP/cellular company using that number as a key to get your location.
The whole emergency calling system is layers upon layers of hacks. While they can bolt additional functionality on if they're creative, it's more likely a given feature is _not_ implemented. There's a good chance that by the time the call gets to dispatchers, the IMEI/IMSI isn't displayed anywhere and they just see a random virtual number.
The PSAP (E911 end point) likely will receive an MDN/MSISDN (10 digit number you dial for NANP networks) - this is so they can call back if the call is dropped.
E911 is a special service, so in the case of deactivated/missing SIM cards, the carrier assigns a temporary MSISDN for duration of the call when the UE exits E911 mode - there are actually of regulatory and carrier requirements around E911 mode.
E911 Phase 2 required not only the DN, but also if possible the location of the device - whether thru Cell Base Station Triangulation (if possible) or GNSS with a LAT/LONG based on coarse/fine location info.
In any case, as @tjohns mentions, IMSI/IMEI are not typically used outside of the servicing network.
I've had this thought before while studying biology in college while working on legacy code as an intern. There's definitely a "designed by natural selection" feel to some old legacy systems.
Good point, and implementing a "this IMEI calls 911 to ask for the time of day every hour" block on the side of the networks seems risky as well, so I get how it might not be that helpful.
But then I wonder why having an IMSI (as far as I understand, the SIM can be deactivated, foreign etc., i.e. it doesn't need to actually register to the network) improves this in Germany?
Maybe German authorities just hope that having to insert a SIM might deter people, since SIMs are perceived as being personally identifiable more than just phones without a SIM?
I have heard of people calling emergency numbers to test if a phone is working, but never a country making that impossible. Here, I had always assumed that repeated nuisance callers would be investigated to see if there's an actual problem, and charged with a crime if they're doing it for no good reason.
Always thought it would make more sense to have a dedicated "test number" for this purpose. Probably with some rate limiting.
A lot of telcos used to have phone numbers you could call that would just say the number you're calling from (like with a computerized voice). I forget what this was called, but it was talked about in phreaking community or so on. Not sure if these "caller identifier" phone numbers are still around today though.
They're easier to make than ever, all you need is Twillio and a bit of Python code. There are quite a few in the US alone, both provided by carriers as well as enthusiasts and other companies in the industry.
BT in the UK has 17070 which tells you the number and lets you do tests like the "quiet line test". Handy when working out what was going on when I moved into a property with no live phone service (so no normal outgoing calls), lots of phone extension sockets, and (I discovered) two landlines coming in...
The AT commands are usually used at call establish time, but can be used at other times to query the status of the modem. AT commands never go into the network that is a different set of standards. They are only used on the modem in your phone. If you can get on the right serial pin on the modem you can issue AT commands to the modem and it will do all sorts of interesting things. Different companies have their own standards.
Think of the AT commands as just telling the modem to put itself in a particular mode or go do something. After that the serial bits will do different things or output different things. It does not specify what will be said in the data mode (that is the GSM/CDMA/LTE/RS232 standards and a different part of the modem). Just that the modem will do particular things.
Take for example this old command ATDT,,5555555
That tells the modem attention, go into output DMTF sounds, wait 2 seconds, wait 2 seconds, output the DMTF tones on the speaker line for 5555555, then wait for a sound of response on the receiver and negotiate the highest both ends can talk using the S registers to decide what to do. But the AT commands do not go over the wire. They are purely modem commands. The modems in many cell phones still basically do this. But just with different commands and different registers. There is nothing stopping the modem from sending more AT commands to the other side though but that would be something in the standards to declare.
AT commands also don't make it onto your phone line, after all. They're for communication between a host and a modem/baseband, not between a host and another host or even two modems.
Fun fact: Lots of cellular modem/routers have the easy ability to change IMEI. Doing so is a fairly common practice in the rural internet community. i.e., those using cellular for their internet access either because cable / fiber or an official cellular option like T-Mobile home internet is unavailable or they're mobile in an RV.
These people are not trying to do anything particularly nefarious but they do it so that they can use a phone or tablet plan in a router. Unlimited or high GB plans for routers and hotspots are expensive and there are not many options.
There are lots of reasonably priced, easy to get unlimited phone and tablet plans but if you put a phone SIM in a router it might work for while until the carrier detects that you have the SIM in an unauthorized device. The "solution" to that is to activate on a spare phone and then change the router IMEI to match the phone. Don't use both devices at the same time. The carrier now thinks the router is a phone.
The legally of it is somewhat unclear so it's talked about quietly on various forums using words like "magic configuration", "giving your router an identity crisis" etc.
It's a bit of a cat and mouse game because IMEI is probably not the only way to identify an unauthorized device but so far it seems to be the main way.
I remember back in the 00's on AT&T getting an unlimited data plan addon for a dumb phone was like $15/mo or something while adding it for a smartphone was like $40 or more. They would enforce it by checking your IMEI and seeing if it was one of the smartphones they sold.
Buying an unlocked phone of a model AT&T didn't sell seemed to never trigger the "you're using a smartphone" check. Fun times with some cheap 3G back in the day.
In 2004, I was doing something similar on Tmobile. Flip phones internet was cheap. Could tether it via a cable to laptop and I also used an external antenna to improve signal. I would leave it up overnight downloading videos on p2p. I was in Army barracks at time and no one else had decent internet.
Passive TCP/IP fingerprinting might tell a lot about the device. You could probably easily tell apart an iPad and a router. But if IMEI checking catches 95% of plan cheaters, it's probably not worth implementing more checks (more checks = more cost and infrastructure to maintain, is it cheaper than the lost revenue?).
This said, I find it insane that there are such plans. The cost of a connection should be the same whatever the device behind is.
I think there's lots of ways they could tell if they really wanted to. One way is simply looking at the traffic. "Why are apps on your Android phone accessing Windows update servers?". I guess a VPN can solve that and the game continues.
Something interesting might happen next week. T-Mobile Home Internet is not supposed to be moved from the registered address but until now that has not been enforced. It's quite popular with RVers. They just announced a new "Away" plan for $160/mo that you are allowed to move compared to $60 for the normal home plan and, not surprisingly, it seems like they're about to start enforcing the geo-restriction on the home plan. This apparently uses GPS in the device. I hear that a lot of people are using the home internet SIMs in other devices with the IMEI set. This is because there are much better devices with external antenna ports etc. These might be in trouble if they don't respond to the GPS request.
That might have legal implications (wiretap laws, they would be basically intercept your communication). But perhaps TCP/IP fingerprinting too, not sure... On the other hand, with providers that were even injecting code in web pages when HTTPS was not ubiquitous... maybe they don't care too much.
I have one of these https://www.amazon.com/gp/product/B09NDDH6S8 which is easy to change. You still need some knowledge to run some AT commands on the modem. It's easy to find the instructions online and it can be done from the web based admin. Yes, they have AT commands like old dialup modems.
Anything from https://thewirelesshaven.com. I have an old one of their routers and the latest firmware literally has IMEI as a textbox in the admin.
Interesting thread - as someone that used to be in carrier space...
IMEI - we only really cared about the TAC prefix, as this identifies the device type, which is mapped to capabilities for services.
IMSI - this is usually in the SIM card (UICC), and mapped out specifically within the uSIM/SIM application inside the card. This is aligned with the Billing/Rate Plan for services that the subscriber is set up with.
TMSI - this is usually what the network uses to page you and also deliver singaling over the NAS via the SGs interface for devices that do not support IMS/VoLTE
ICCID - this ID's the card itself, for SIM cards, it always starts with 89 as this designates the card as telephony related as a physical UICC - remember, there are other types of UICC's such as CHIP based Credit Cards, which start with a different number.
MSISDN - this is the number that you dial and send SMS to - in legacy systems, it can also be referred to as the MDN
Fun Fact that was skipped in the article - IMEI's that start with 99 are special, as these indicate that the Device is both GSM/UMTS/LTE and CDMA/EVDO capable, and generally those IMEI's will align closely with the CDMA MEID's, but they were not required to. The "99" range wasn't just Apple, but was used in the early days of dual-mode across most vendors as it helped facilitate session handovers from C2K to any 3GPP based service. For C2K, on the IMSI front, most devices would use IMSI_T (True IMSI based on the SIM card IMSIef) but some used IMSI_M which was based on the legacy MIN.
Legacy - there is the ESN in CDMA, but this is very legacy, and was largely superseded by MEID - for Legacy Support, pESN could be derived from MEID, however at the high risk of collisions...
Android defaults to sending the IMSI (SIM ID) to Google.
> SUPL is used as part of the A-GPS (Assisted GPS) system to get a faster Time to First Fix. The problem is that Android's implementation automatically sends the IMSI (ID of the SIM card) to the SUPL provider for no apparent reason. And because Google is the default provider it's a big breach of privacy.
The S in SUPL stands for secure, it's ssl encrypted. Whether or not the implementation is good, I don't know, but saying it uses plain http is patently false.
If you buy a phone in Turkey, it's IMEI is registered to a gov authority and you can use / transfer it as you wish.
If you happen to buy one from another country, it will be locked after 60 days of use and no carrier will connect it after that. You can use your passport to to prove that it was not imported commercially but you brought it with you and register it. For $1000 (yeah). And it is locked to your ID. Can't transfer it to someone else.
IMEI cloning from an already registered donor phone was a thing and maybe it still is but as far as I can tell, high end phones pretty much lock it tightly.
BTW, this also affects a lot of other stuff. Can't buy a gps dog tracker from amazon. Can't buy a gsm module for your arduiono etc...
My car has a connectivity system where it provides internet to the in car infotainment system and also allows me to open doors etc remotely. It only recently became operational when the distributor finally managed to register the IMEI numbers. A lot of companies do not bother (Mercedes, BMW etc are equipped with similar systems, not operational)
as a native English speaker I transparently read that as,"there's no point in buying a GSM module [...]", but I can see how others might possibly be tripped up by that construction.
SMS specifications include "Type 0" messages, also known as Silent SMS. These messages don't trigger any even on the phone when received, but they do send back an ACK that includes IMSI metadata. Silent SM, are literally defined in the RFC and primarily used to covertly track user locations without judicial oversight.
GSM, SS7, etc. are massive privacy holes _by design_.
Silent SMS is an incredibly convoluted and impractical way of trying to figure out someones location.
The whole purpose of mobile networks is to track a devices location (so you can route data to/from it!). Of course its easy to do it if your the operator or someone who has compromised it.
I remember using one of those dongles with a SIM card that you could talk to with an API and use that to send flash SMS. Full screen warnings to friends. Only option was 'OK' and the text was gone afterwards.
when we know that govts want this capability, when we know that govt regulators are in the same room with telcos when plans are being drawn up, when we know govt uses these capabilities routinely, why would you doubt it was there for that purpose? isn't this a good time to round up the usual suspects? If the govt intervenes to get this capability and also declares that this should not be the primary purpose, I guess that would make it a secondary purpose? OK, I feel better now, phew!
Visual voicemail is when the dialer app on your phone can show the list of voicemails similar to how you would see your email inbox. You can directly play the voicemail messages and depending on the device/carrier, there might also be a text transcription of the audio.
Many carriers implement this via "silent SMS" + IMAP (the same IMAP as for emails). The device will send an activation or status message to the carrier's visual voicemail number and the carrier will respond with an SMS containing the IMAP credentials.
The version of this I'm familiar with is T-Mobile's old CVVM protocol. During initial setup, the device will send a text message containing "Activate:dt=6" to the number 122 and T-Mobile will reply with (in decoded form):
If visual voicemail is already enabled, then sending the "Status:dt=6" SMS to 122 will also result in the same reply. Putting the credentials in an IMAP client will work and it doesn't have to go over the phone's cellular connection. You can even use curl:
T-Mobile has deprecated this protocol though. New activation messages will fail with a blocked status:
rc=0
st=B
srv=vvm.mstore.msg.t-mobile.com
T-Mobile replaced this CVVM protocol with two HTTP based protocols: "mstore" (used by OEMs like in the dialer app on Google Pixels and OnePlus devices) and "cpaas" (used by T-Mobile's first party visual voicemail app). I've been working on an open source client for mstore for use with open source Android OS's, like GrapheneOS.
I'm not sure if Visual Voicemail really uses silent SMS, but even older phones had a series of indicators such as "voicemail waiting", "message waiting" etc. which the network could control via binary SMS payloads.
By sending one that clears all of them in a network that doesn't use them (or sending one equivalent to the current state for one that does), you can achieve the outcome of initiating SMS-MT (mobile-terminated) delivery to a given ME (phone) without any user notification.
SMS delivery by necessity involves paging the device, revealing its location at a finer level (base station instead of paging area).
So I wouldn't say silent SMS were designed as a spying tool, but they're one out of several ways to silently "ping" a phone and force it to communicate with the network without having to wait for it to cross location area boundaries, get or make a call etc.
Visual voicemail is where an app on your phone can show you a list of voicemails and you can click a button to play them, as opposed to you having to dial a number to access voicemail (the old "press 2 to hear the next message" stuff).
They're not privacy holes by design, but they're not privacy friendly by design either.
When these things were designed, privacy wasn't really a concern and wasn't really thought about in the way it is now. The assumptions were very different, it was assumed that only large and trusted companies could get on SS7 and those would play by the rules, or else face the wrath of the government. Now, a small carrier in a third-world country that routinely violates human rights can get that access.
I think I’m more concerned with the fact that the carriers know the IMEI of phones and claim that they can do nothing about stolen phones. That was the beginning of the end of my infatuation with the mobile space.
I should have been well positioned for early retirement during the early smart phone gold rush but was just so put off by the Ma Bell feeling of the mobile industry that I had exited before most people had even entered.
In Kazakhstan, when a phone is used on a mobile network for the first time, the IMEI of the phone gets locked to that mobile network and that sim card. When you buy the sim card, they photocopy your passport/ID card.
No other sim will work in it until you take that photo ID/passport to the mobile companies office to have it unlocked. The photo id (even if expired) becomes the unlock code for the phone.
Stupid assumption. Phone theft including being robbed for your phone, was more common in London, Sydney, Melbourne than in any place in Eastern Europe I lived in.
Carriers have been blacklisting IMEIs for at least 10+ years. Since phones tended to be carrier-locked back then you couldn't go to a new carrier without being in good standing to get your device's unlock code from the old carrier. Now that devices are available unlocked by default, it is probably harder since it would require carriers to communicate IMEIs?
I looked it up. US Carriers were forced by the US government to start blacklisting them in the final months of 2012. They didn't do it voluntarily.
Australia had been doing it since 2003. IMEIs have been around for 30 years? Everyone having a cellphone is still a relatively recent phenomenon, but according to Pew 80% of American adults had cellphones for several years already before carriers were forced to deal with stolen ones.
~15 years ago the blacklists were certainly shared within Europe, but there was an intercontinental trade of blacklisted phones from Europe to Africa (and, if memory serves, Asia).
I believe the point is that they could've been blacklisted from the start and instead carriers would just put up their hands say "there's nothing we can do" despite there being something they can do.
It's like when your apple laptop gets stolen and then starts using your applecare support and apple won't help you get it back.
Of course, if you decided not to pay your phone bill I'm sure that device would get blackslisted real fast.
Your entire comment makes it sound like your gripes are current issues, not those that you experienced decades ago in a completely different mobile landscape.
You continually use the present tense when the argument... just doesn't apply anymore.
> I think I’m more concerned with the fact that the carriers know the IMEI of phones and claim that they can do nothing about stolen phones.
I really want mobile networks to accept their role as dumb data pipes. I should be able to just provide a password or certificate and connect. No IEMI, no SIM.
And while we are at it stop tunneling my data back "home" when I travel. I don't want increased latency.
> And while we are at it stop tunneling my data back "home" when I travel. I don't want increased latency.
You might not, but a whole lot of customers who aren't as technically sophisticated did. When T-Mobile first started doing included international data roaming, they didn't tunnel back. That caused a lot of confusion from customers who didn't realize why stuff they expected to work, like checking their bank balance, didn't. (It also made throttling speeds a lot more difficult.)
So to fix that, T-Mobile tunnels you back to a few endpoints in the States. Banking apps are generally happy, as are Netflix and Spotify. Most customers are happy because their phone "just works" the same as it "always has".
For those of us who want to avoid the latency, we get a local SIM for data (if possible).
This is interesting. I use Verizon Wireless from the US, and when traveling abroad on their travel pass (roaming), some large multilingual websites serve me the local language instead of English, on sites that serve me English when I'm at home. My browser (Accept-Language header) is configured for only English. I always decline location API browser popups.
The only thing I can think of, assuming they tunnel as you describe, is maybe I first loaded the site from local WiFi instead of mobile data, at which point I was redirected (to a localized subdomain that doesn't redirect back) or got a cookie or something, which lingered as I continued without WiFi.
> And while we are at it stop tunneling my data back "home" when I travel.
Oddly enough, I found this to be a plus when I traveled to China for work. My data was unmolested by the Great Firewall of China. I was able to get on websites with my mobile data that I couldn't when using wifi in the hotels.
How would a networking stack with no hardware addresses even work? The next hop needs a way to reach back to you, before you can negotiate anything fancy like passwords or certificates. Even IPv6 SLAAC starts with a hardware address.
The use of IPv6 in cellular devices is specified by RFC 7066. When a device first registers for a data connection, the network provides an interface identifier to use for the lifetime of the registration, which is guaranteed not to conflict with the one used by the router. The network also allocates a /64 prefix exclusively for use by the device. These two things allows the device to perform SLAAC for link-local and routable addresses without needing to do duplicate address detection.
It’s also worth mentioning SLAAC does not strictly require a hardware address to function. For example, Apple devices implement newer standards from IETF to generate random but stable addresses that don’t reveal information about the hardware addresses (https://support.apple.com/guide/security/ipv6-security-seccb...)
A MAC address is 48 bits and an IMEI is about the same entropy-wise. That's not nearly enough room to avoid duplicates (even SLAAC requires duplicate address detection, and IPv6 has a lot more bits to work with). You'd need a whole new layer 2 protocol, though to be fair you might be able to strip it down to just doing collision detection/avoidance and leave addressing up to layer 3 with IPv6, but that's not going to be any kind of backwards compatible or interoperable.
> Surely the uniqueness is only required at the bottom end of the stack before the first 'router' ie the cell tower
Not if you need to send a message to $thatUniquePhone.
Over simplifying considerably, but if a land line places a call to a mobile, the "220-1234 calling for 220-7890" message enters the network. The `220-7890` phone number needs to map to the unique modem address so you can look up which tower the call setup data should be sent to. If - by sheer coincidence - I also have your MAC address and am attached to a tower 3 states away... which tower(s) do you forward the call setup data to?!
As far as I know MAC addresses are never used to route a message to a particular recipient. They're used so that devices that overhear the message, but aren't the intended recipient, can ignore that message on the honor system.
If you have a wired connection, this makes the MAC completely superfluous. The concept is sort of still valid for wireless connections (or of course for "wired" connections where you have multiple devices physically connected by the same wire, a bus, where the concept originated). It should be rethought.
A typical Ethernet switch operates only at layer 2 and so does indeed route frames by MAC. You need a more expensive, typically managed, switch in order for it to use layer 3 addresses instead and, even then, the initial setup usually relies on layer 2 routing to get an IP address before layer 3 routing can take over. As a sibling comment points out, the whole stack would/does need a rethink to work differently than this. IPv6 SLAAC as mentioned before can potentially eliminate the need for layer 2 addresses but a lot of networks are still IPv4-only, dual-stack, or even layer 3-agnostic.
Note that this is only about last-mile/first-hop. Once you scale past a single LAN segment, routing is mostly layer 3 until you get to core Internet infrastructure which uses ASNs and BGP. At the very least, it is probably sufficient to say that routing across a WAN is all about IP, but if you zoom in on parts of that network of networks, the underlying technologies often use other routing mechanisms internally that don't get exposed to the other parts of the WAN.
Yes, but you could have hundreds of thousands of devices connected to that tower in a dense metro area. Even a single hardware address collision would result in both devices being unable to reliably reach emergency services.
It seems a number of devices are now randomizing their MACs when connected to wifi. I'm not sure how they handle address collisions, if they do at all. Most wifi APs serve a lot fewer devices than a cell tower, but it's possible that the issue isn't as significant as I thought.
And while we're at it, how come if I have a phone without a sim I can't at least navigate to a carrier webpage to buy an esim?
The phone could pop up a menu saying "Here are the available networks", and you pick one, connect and it says "Welcome to AT&T, enter credit card number here", and you type a number and hit OK and you're connected.
Oh wait - just like Wifi!! Why are mobile networks so far behind?
There is no privacy concern, really, as this is unique to the device, not subscriber, and only shared with the network operator, who obviously already "tracks" the subscriber through the SIM
, which contains the subscriber identifier (IMSI).
On the other hand, the IMEI in principle makes tracking and disabling of stolen devices easy.
By the way, in the UK it is actually an offence to change the IMEI [1]
The IMEI also allows a network operator to track a device across multiple sims. And I think it's also shared with roaming operators if roaming happens.
Disclaimer: used to work in SIGINT, so please treat anything I say about this with appropriate skepticism.
There are people that for various reasons do cycle out their SIM card frequently as a means to avoid tracking. This is ineffective. Changing the IMEI/discarding devices entirely is more effective.
But if you change IMEI and use the same SIM card, you're still trackable as if nothing changed, right? The IMSI would be the same. I guess you need to change both at the same time...
Dudes have been driving around with fake base stations, rare, but has happened. Only sent spam sms messages with links but could be expanded with buying data from data brokers. A really serious crime though
I would think state level actors have enough tools to deal with this issue. If nothing else they could go the old fashioned way and just, you know, follow you.
"There is no privacy concern, really..."
Except for the network operator, who needs to track a SIM card not a phone, but who can track you across networks and SIM cards if he has the IMEI. There is no reason the IMEI needs to be stable.
The network operator does NOT need to know who you are, even if you live in a repressive country that mandates tying ID to mobile phone lines. Get a SIM card in person and top up in cash, or use a virtual credit card, or pay in cryptocurrency for an eSIM, or get a subscription in a less oppressive country and roam.
Any immutable id is inherently a privacy concern. Network operators are ISP's, and ISP's have been known to do things like hijack unresolvable DNS entries to a search page with ads. The network operator knows who you are and what imei was associated with your account.
I wouldn't be surprised if there were some 'ghost'/virtual profiles associated to an imei similar to how Facebook would do with the like button
Well, there's your phone number. Networks and law enforcement only need that.
Existing privacy level is adequate for members of the public. Anyone who actually, really requires more either has state agencies resources available or is being wanted by state agencies...
Definitely don't let people edit it. iOS and Android don't allow picking your own MAC address for good reasons – people would inevitably pick 12:34:56, 00:00:00 etc. and cause problems for themselves and others.
To increase privacy, either randomize it (but make it much longer at the same time to avoid collisions) and/or remove it from as many signalling contexts as possible and keep it as a device-local identifier only (which then probably also doesn't have to be unique across manufacturers).
There were a lot of chinese made keiser phones that allows you to edit all the phone/sim related identifiers. Sadly they were discovered and rooted out of the amazon marketplace.
Many a year ago, when the iPhone was new and Android was on version 1.6. Sprint offered the SERO plan, an unlimited plan for friends and family. When smartphones hit, they would no longer allow the SERO unlimited plan to transfer to the new phones.
The HTC phones had a Qualcomm radio that, with the right tooling, one could write all 0s to the IMEI (or the CDMA equivalent) register. Then you could write any IMEI to the register. That worked well for a few years.
SERO was one of the Sprint Rate Plans, the other was the Pioneer Plan for early adopters on SprintPCS
HTC got into a bit of trouble with the carriers on the whole IMEI/MEID rewrite mess at the end of the day. With Qualcomm, that was an NVITEM that was supposed to be read-only.
Is there any entity or procedure that actually proves what a phone is what it claims to be?
Unfortunately, neither IMEI, Serial Number or a combination of both can assert this.
I bought a Samsung S24 a week ago off Facebook Marketplace. It was in the box and everything. I cross checked both the IMEIs and also the Serial Number with the #06# test. I even checked them online. Did all the tests, #0# and even downloaded Samsung members. Paid for the phone, convinced it was a genuine one.
Upon registering it and using it, it becomes very clear the phone is fake and is at best a clone. The camera is nowhere near the S24 and does not have the features. It heats up after charging and does not keep charge. It runs slower than a 10 year Android once you are signed it.
when you run diagnostics, it shows all the specs of an S24 Ultra. How do I know this? I went and got another S24 Ultra from the store and they are worlds apart.
So my question is, if you are buying a phone from a reseller or someone, is there any way of definitely asserting whether it is authentic?
I’m sorry that this happened to you. The debugging and tear down sound like they would make for an extremely interesting blog post though. I encourage you to write it up and post it here - I’d definitely read it.
Some YouTuber bought one of these (not specifically an S24) and found a hidden app that "told" the phone what it should be.
You could set how much RAM you wanted, how much storage, what CPU and so on, and then that info would be shown in all the "about" screens. They went to a few Tb of ram if I remember correctly.
Changing any of these parameters didn't have an impact on what the phone could actually do, just to be clear.
This is typically where consumer rights laws come into play and a key advantage of buying first hand from a “real” business rather than an individual or third party. At least there you have someone you can easily hold to account.
You need to price in the risk factor when purchasing where such legislation doesn’t apply or isn’t easy to enforce.
Also a rare UK success story in brute force lawmaking. People used to hack phones IMEI all the time, lots of utils available. Then anything relating to changing an imei was heavily punished and it all stopped. Nobody would host a utility or a guide or even mention it on a forum. If you did mention it you were banned. It was almost instant.
it will generally start with a 35, which is unused as a country calling code
It's "unused" because several country codes start with 35: Ireland, Portugal, Luxembourg, Iceland... (This doesn't mean that phones are actually manufactured there... I have a phone with an IMEI starting in 354 and it's definitely not manufactured in Iceland...)
Yeah, they seem to be confusing that with IMSIs or ICCIDs, which are indeed namespaced by mobile country code and international calling code respectively.
Based on what other commenters have already pointed out, this seems to be a quite sloppily researched article.
This is interesting - I hadn't noticed this, but my Chinese (Xiaomi) phone indeed has an IMEI starting with 86, which is China's dialling code. Perhaps a coincidence.
The ICCID starts 8944 - not sure of the significance of the 89, but 44 is the UK, where my SIM card (and me) comes from.
I remember some telco guy saying “the IMEI is unique until it isn’t.”
We always wondered if you could crash part of a cell network by dropping in 8192 phones with the same IMEI. Everyone needs to deal with non unique identifiers, but the question is how many do they expect?
FYI this is a problem on Ethernet, when you get boards that haven’t been initialized. Things don’t like multiple MAC addresses with 0s.
I'm interested in the general thrust, but this article is sloppy at best.
> Check digit: The final digit is essentially used to validate the prior 14 digits with an algorithm. Similar digits exist in other types of identifier codes, such as the Universal Product Code (UPC) and the International Standard Book Number (ISBN). The algorithm that the mobile industry uses, the Luhn algorithm, is also used for social security numbers and credit card numbers.
No, just no. SSNs (in the US) don't have check digits.
Also:
> Then there are network identifier numbers—the MAC address bestowed upon you by your WiFi network or mobile provider
Huh? This nonsense ("bestowed upon") serves only to confuse. This is bad tech journalism: it fails to inform the masses, and is transparently worthless to experts.
The Brazilian CPF (our equivalent to the SSN) goes up to eleven (literally) by including not one, but two check digits; IIRC, the first one (the tenth digit) is computed over the first nine digits, and the second one (the eleventh digit) is computed over the first ten digits.
The geographic aspect of SSNs no longer applies either. My kids have SSNs that start with different digits than my own which was assigned under the old regime where the first digit indicated where the SSN was issued.
I prefer to buy second hand iPhones for my family, and usually use Amazon. But the last couple of iPhones haven't been able to connect to the cellular network at all.
Digging into it, it seems they've been IMEI blocked – i.e. reported stolen. Sending them back to Amazon is always such a pain because it means a visit to the post office.
I don't recommend mucking about with the IMEI, as you risk a collision with another device that is already using that IMEI - IMEI's are supposed to be immutable.
I realize that there are some Modem OEM's that might allow the IMEI to be "adjusted", but proper modem vendors will not allow that AT command.
I have been looking for information like this for a while. Thank you!
Follow up, does the IMEI number get broadcast when you connect, or is it a searchable bit of information accessible by apps, et al?
Im wondering how anonymous you can be if youre making all the right privacy moves, but your phone is still essentially giving you up because your IMEI number is traceable back to you.
Very interesting!
Super cool to see it can be used against theft.
AFAIK some apps misuse it, though. If Snapchat detects a modified phone (root for example) at any point, it might block your IMEI. (As far as the internet is concerned, they're very secretive about it) Which is a horrible decision, since a phone might be re-locked and refurbished, handed down to someone else, etc.
”Other” isn’t really correct, is it? The IMEI is your phone’s number, your phone number isn’t tied to a phone, but is your user name/chat handle with your provider.
Not from the other side of a wide-area network, but if they are continuously in close proximity to you, or can effectively monitor everywhere (three letter agency), then yes. Of course, there are other ways to track you.
I think this is only true for older mobile networks. In 4G and 5G, I don't think the IMEI is part of any unencrypted radio message anymore.
Even the IMSI is only used when absolutely necessary, i.e. for the initial attachment procedure when cold starting a device or entering a new routing area; after that, it's replaced by an alias called TMSI to make tracking phone users a bit harder.
New Android versions will supposedly have a switch in their settings to show a warning every time the IMEI or IMSI is transmitted in plantext [1].
It is a minor part of the article, but I'm surprised they introduced it only to get it so wrong.
The U.S. Gun Control Act of 1968, among other things, requires traceable serial codes on guns, something that has become a key element of forensic ballistics. In some circles, this is seen as controversial, as highlighted by a case involving “ghost guns” that the Supreme Court is hearing this session.
First of all, serial numbers don't have much to do with forensic ballistics. Generally, in forensics, investigators are comparing items in their actual possession -- shell casings, bullet fragments, and weapons recovered from the scene of a crime or from a suspect. Serial numbers don't help with that.
Serial numbers are useful in investigating gun trafficking -- it's actually very similar to the example of car theft that the author presents early in the article.
Regarding the "this is seen as controversial", that is a claim that is absurd beyond belief. What is at issue in the case is when the requirement to serialize adheres and to what it adheres. That is a complex issue. A gun is made of dozens of components. Many are tiny with small surface areas, like springs and pins, and many are replaced over the life of a gun, so serializing them would (a) be ineffective and impractical and (b) could actually confuse the identity of the gun.
So when do we serialize and what do we have to serialize? For a long time, the settled practice in the industry has been that there is one component that is "the firearm". This part generally is large, is subject to low mechanical stresses, and can be expected to last the life of the gun. This is generally a part called the "receiver" or "frame".
If the receiver is ever damaged beyond repair, regardless of the state of the other parts, then a "new" firearm has to be created and serialized. Although the barrel, trigger, &c, are all the same, it is a different gun now.
This system has actually worked pretty well and has allowed for relatively robust tracing of stolen guns and guns found in investigations of international arms trafficking.
Collections of parts that make up an incomplete gun are of two kinds -- if the receiver is in that collection, the collection of parts is a firearm and has to be sold according to the rules governing transfer of a firearm; if not, it isn't.
A receiver or frame starts life as a large block of metal or plastic. So what if we sell people a parts kit where we have every part of the gun except the receiver, and also an appropriately sized block of metal or plastic? Nothing in this combination has to be serialized and it is not a firearm.
Until recently, this was not really an area of much activity because, while a receiver is subject to low mechanical stresses, that is in relative terms -- relative to other parts of the gun. It is nevertheless a component that takes a fair amount of machining and finishing to get made. What brings us to the "ghost guns" discussion and the Supreme Court case linked in the article, is the degree to which home manufacturing with light tools has improved in recent years. It is actually possible now to make a pretty good receiver without a machine shop. Some people came up with a business of selling people almost complete guns, with a block of plastic or metal and some jigs that allowed them to readily complete the receiver. This is an edge case and it will take some thought to establish when, exactly, we apply the rules regarding serialization. The people making blocks of plastic probably will not be required to serialize all blocks of plastic simply because they are potential firearms (along with potentially being many other things); but the people buying the blocks of plastic to put into kits that they then sell to others in order to make guns probably will be seen to have created a "constructive firearm" and so will be required to serialize them.
> The combination of the ICCID and the IMSI basically tells the mobile network, “hey, this person paid for a plan.”
As far as I remember, the ICCID never actually appears in standard network messaging. It might be possible for the network to request it, but it's not part of a standard 2/3/4/5g attach.
The piece seemed to miss two major uses for the IMEI (or I missed it when reading), which were working around vendor bugs and allowing emergency calling.
Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful.
GSM (and onward) actually supports a handset attaching to a network, even without a SIM card, for the sake of emergency calling. It needs some form of unique identifier for this to work. As much as it could (potentially, entirely redefining the stack) generated UUIDs, it makes some sense for these unique IDs to persist across roaming/sessions/reboots.