The only way I've found to protect against SIM Swap is to use Google voice for my SMS. Google has good two factor authentication and, since it has no telephone customer service, is hardened to PII based social engineering, or at least you can't SIM Swap somebody with just a name and an SSN.
That's a working, but very very scary foundation for security.
"Google's customers service is _so_ fucked even the most dedicated social engineers with the biggest of whales in their sights can't get them to do a fucking thing."
To be fair, banks do an OK job of that. (Well, it's hard to take over an account purely by remote social engineering, some of mine still blindly use SMS as an authentication thing...)
Telcos do not secure phone numbers to banking grade security, because they never agreed to be part of anyone's critical security posture, and their own incentives are to make it as easy and quick as possible for customers to move their phone numbers around. It's in the telco's interest for you to be able to walk into a $TelcoBrand store and walk out with a functioning device with your old number. (Or to call up their support line and do the same thing.) They never offered to make that more difficult than it needs to be just because companies like PayPal wanted to outsource security to be somebody else's expense. They've been actively recommending against it since forever:
It would be nice if you could show up in person with a photo id and validate yourself. For a lot of bank transactions in developing countries you have to inconveniently show up in person with your ID because it's a simple way to reduce fraud.
SIM Swap [1] is not covered by this. SIM Swap is a social engineering attack powered by PII leaking from everywhere and for long time. Today, SIM Swap attackers don't even need to use phishing or buy PII from ilegal sources. After so many leaks, peoples full name, mother name, addresses, credit cards, SSNs are all over the internet. Just Google it.
Out of curiosity, do eSIMs, now common in newer phones, make these kind of attacks less likely or more likely? It seems like they would be more likely since there's no physical component anymore.
No difference, because there is still a physical component ;) Where a normal SIM card is removable, with an eSIM the chip is soldered on the device. But there is still the same secure chip as in a removable SIM card really, it just takes a lot less space. Because it is soldered, it must be possible to remotely change the content of the SIM, for example to change your telco operator. How to do this securely and in a standard way is what eSIM is all about.
The technical name for a SIM card is UICC (Universal Integrated Circuit Card IIRC). eSIM is eUICC. The next step is iUICC, for an integrated on die function. There is no separate chip then, it's integrated in the modem SoC. But the way it is standardized (on-going) the iUICC must run in a secure enclave, with similar security level as current discrete SIM cards. So again, no real difference: a iUICC will behave as an eUICC one from an end user point of view. The operator do not want to reduce the security of their UICC.
It's not that simple. A profile is generated for a specific, unique eSIM chip. You cannot install nor use a profile on another eSIM. The target device is tracked. That gives some traceability and security.
Then there are two variants of eSIM, for M2M and for consumer devices.
With the consumer variant the profile is requested from the target device itself. So you must own the device to install a new profile, and also have the needed credentials. So this is more than inserting a physical SIM today, where you also need the device but there's no local credentials and no SIM/device mapping.
For M2M, the profile is explicitly pushed to a specific device, which is remotely managed.
Is there also some level of virtualization with eSIM, where the single chip allows for multiple SIM "profiles" (SIM-card-ISA VMs, basically) to run on one chip? Or are the manufacturers that claim that eSIM "allows" for multiple simultaneous operator accounts, just putting multiple eSIM chips in their devices?
Always remember, there's another computer inside your phone, the UICC computer, it contains software from the past, written by hardware people who've never heard of security, no one's looked at the code for bugs, and it controls your phone.
Yes and no. Yes, an eSIM can contain several profiles from different operators. But only one profile is active at a time.
There is typically a default bootstrap profile, to provide just enough connectivity to get started and choose your actual operator. And then this operator profile will be installed too. But the system is more generic, and could store more profiles. At least in theory, in practice there is a cost to generating a profile so this is only done if there is a real need.
Err, no. That describes one (relatively new) attack called Simjacker.
This article / link describes this and a possible other attack (also an applet on the SIM card, calle Wireless Internet Browser (WIB)) AND a way to test if your sim card is vulnerable plus mitigation measures (hint: do not allow MSL (Minimum Security Level) zero).
From reading this it seems that this is unrelated to the SIM Swapping attacks that were in the news recently and are mostly customer service exploits and not technical issues.
Do you know whether this requires the person in store to enter an exact match/have you enter it on a pinpad, and that it is absolutely not removable in any way by any CSR, customer service, or other humans other than you knowing it and logging in with it?
ATT asks for the PIN over the phone too, so best practice seems to be changing PIN after giving it to an ATT employee.
But who knows if PINs are visible to ATT employees, and what verification they do in case PIN is forgotten. It’s all moot if any ATT employee can reset it without a significant paper trail.
Well, ideally, it would lead to stricter penalties and process improvements to prevent it from happening. And it would allow for fraud liability to be placed on ATT causing them to care to fix the issue.
Ah, good old days. I wrote some of the tooling back in the days. Was a lot of fun. Damn, video cards have advanced so much in the past years I wonder how fast that code would now run. We were using Radeon 5970s at the time -- integer performance was pretty bad on NVidia cards back then.
