Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

From their "Features" drop-down:

> Minimal Data Collection

> Identifier Rotation

> Secondary Numbers

> Disappearing Call Logs

> SIM Swap Protection

> Network Lock

> Encrypted Voicemail

> Private Payment

> Last-Mile Encrypted Texting

> Secure Global Roaming

"Identifier (IMSI) Rotation", "Secure Global Roaming" and "Network Lock" do look interesting *IF* they can actually address some of the baseband vulnerabilities that plague all modern devices. That's a Big If.

SIM Swap Protection you already get by using a VoIP number rather than a cell number.

And the other features are irrelevant if you're using over-the-top end-to-end encrypted messaging, like Signal, rather than Plain Old Telephone Service and SMS.



>do look interesting IF they can actually address some of the baseband vulnerabilities that plague all modern devices. That's a Big If.

Baseband vulnerabilities are overhyped, imo. On proper phones (eg. pixels), their access to memory is restricted by IOMMU, which protects the rest of the phone from being compromised if there's some sort of an exploit. Once that's factored in, most exploits you can think of are "on the other side of the airtight hatchway[1]". For instance if you can hack the baseband to steal traffic, you should probably be more worried about your carrier being hacked or getting a lawful intercept order. Or if you're worried about the phone triangulating itself, you should probably be more worried about your carrier getting hacked and/or selling your location data.

[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...


> Baseband vulnerabilities are overhyped, imo. On proper phones (eg. pixels), their access to memory is restricted by IOMMU, which protects the rest of the phone from being compromised if there's some sort of an exploit.

Doesn't Google require all new Android-branded devices to isolate the baseband from the Android OS and applications?

I swear I read this somewhere in the last few years, though I can't seem to find any clear reference to it now. Hmmm.

> For instance if you can hack the baseband to steal traffic, you should probably be more worried about your carrier being hacked or getting a lawful intercept order.

Everything should use TLS/DTLS/QUIC, and an up-to-date PKI for obligatory certificate validation, otherwise I assume it's already being MITM'd by the NSA, every other three letter agency on the planet, corporate firewalls, and my ISP.


Baseband vulnerabilities are overhyped, imo. On proper phones (eg. pixels), their access to memory is restricted by IOMMU, ...

That just kicks the can down the road to "Why should we fully trust the IOMMU?"

Granted, it does defend against the vast majority of actors.


... because that's literally the IOMMU's job? Why should we trust the TPM or the CPU or a YubiKey or anything, really? I don't completely trust any of it but to get anything done you have to trust something at some point.


>Why should we trust the TPM or the CPU or a YubiKey or anything, really?

You raise a good point.


They built their own mobile core, does that help with resolving your "Big If"? I'm not a cellular guy, I don't know which pieces of the stack cover which attack vectors: I'm genuinely asking.

Also, the 50 foreign countries seems interesting.


Do they own the enodeBs or the RAN? How many hops does it take to get to their core? Not sure how MVNO works maybe they have encrypted VLANs to their systems. Not a RAN guy.


We don't own eNodeBs/gNodeBs (the RAN). We operate as an MVNO. It is worth calling out that we operate as a full MVNO though, which is different from many MVNOs in the US currently, who tend to fall on the lighter end of the MVNO spectrum.

The primary difference is we run our own mobile core entirely.

Can you elaborate on the hops question? Not sure I quite understand what you're asking since there are a few ways to interpret "hops".


Which vendor did you choose to partner with to provide the mobile core (IMS and such)?

I've talked to a few tangentially and it seems like an interesting space.


> They built their own mobile core, does that help with resolving your "Big If"?

Not really, but I too am uncertain about how to think about it.

Here's my long-winded but still limited understanding of the main vulnerabilities that are unique :

NETWORKS: If I build a network, and I build it out of switched Ethernet, and I control the premises completely, then I can generally trust that the data flowing through it isn't being secretly logged or tampered with. Moving away from this simplicity, my distrust of the network increases rapidly.

A cellular network is pretty much the opposite of this simple one-man, one-room, wired network, so I distrust it completely.

There is only one credible solution here: all traffic over the network must be end-to-end encrypted and authenticated. That means TLS/DTLS/QUIC/ESP/Wireguard with key-pinning and/or correctly implemented and maintained PKI. Assume that any and all traffic that is not E2E-encrypted and authenticated is subject to some combination of mass surveillance and/or individually-targeted attacks.

CELLULAR DEVICE HARDWARE: For historical reasons, modern smartphones contain [at least] two CPUs:

1. The main "application" processor, an ARM64 SoC running an OS and applications made by Google or Apple. They've put substantial efforts into hardening these OSes and applications against remote attacks.

Whether they're doing "enough" is another question; whether you should trust them is another question. But they're at least trying pretty hard to prevent rando malware-for-hire attackers from pwning your device via over-the-air vulnerabilities.

2. The "baseband" processor, a ghastly fossilized thing that runs a stack of overly-complex firmware dating back to 2G days, and controls access to the cellular network. It is probably developed by Qualcomm, which along with Samsung has a near-monopoly on baseband processors for modern devices sold outside of China. Qualcomm in particular is litigious and complacent about security issues (https://hackertimes.com/item?id=38620067), and almost everything about the processors and their firmware are closed-source and non-public.

The baseband processor is insecure both due to inattention, as well as treachery. The end user of the device does NOT control it in the way that the end user controls the main processor. Some nebulous combination of the baseband vendor, the carrier, and the government controls it (e.g. https://hackertimes.com/item?id=46848303).

So the baseband processor is an untrustworthy thing that should be walled off from the rest of the system, and only allowed to communicate with the rest of it via narrow and well-defined interfaces. However, this was not the case for many years: the baseband processor has had way too much access to the system.

In recent years, this situation has improved somewhat: recent Pixel devices with Google Tensor SoCs (and maybe others) have the baseband isolated via an IOMMU. https://grapheneos.org/faq#baseband-isolation

---

Okay, so can "Cape" do anything to assuage my concerns about _any_ of the above issues? Honestly, not very much. ¯\_(ツ)_/¯

Cape can't increase my trust in the cellular network. Cape can't increase my trust in the baseband processor on my device.

Cape can only do a couple things to make the baseband and the network Slightly Less Evil: shuffle IMSI frequently to prevent IMSI-based tracking, and don't let random scammers call up and SIM-swap me.


> switched Ethernet, and I control the premises completely

https://en.wikipedia.org/wiki/Tempest_%28codename%29


Yes, I know about Tempest. My point here is that you really can't trust networks, and as they get bigger you should trust them less and less.


Are there solid VoIP providers that aren't detected by 2FA SMS services? I can't use my Google Voice for a decent chunk of sign-ups because it is detected (and rejected) too easily. I hate getting spam, so I try to keep my primary phone number only for friends and family.


I've used my Google Voice number as my primary number for ~15 years at this point. (I use my "real" phone number so little that I have trouble remembering it.)

I've had almost no problems using my GV number for 2FA. Venmo is literally the only service I've ever used that won't accept it for 2FA… and now Venmo offers non-SMS based alternatives, which is good because SMS-based 2FA is the reason that the SIM-swap attack is worth doing.

List of services that allow Google Voice for 2FA: https://www.reddit.com/r/Googlevoice/comments/1c571kw/crowds...


Google Voice is requiring ID verification now, and porting your phone number out is difficult as they charge an unlock fee and you get to deal with Bandwidth.com's port out shenanigans as they are the real underlying carrier for Google Voice.


> Google Voice is requiring ID verification now

Yep, this is a crappy change going forward :-(

However, Google Voice does not require ID verification for preexisting accounts, so this has no effect on existing users.


Serious question, what services are you using that this isn't a deal breaker for you? And why isn't it?

Most services either don't have a legitimate interest in my phone number (so they can get bent) or they do have a legitimate interest in which case not accepting my phone number means they aren't doing their #$&^ job (so they can get bent).

It helps that the only services I'm willing to provide my phone number to are those that already inherently involve my PII. Banks, online shopping, etc. So if they won't accept whatever I give them I'll take my business to a competitor.


Use sms verification services that spammers use. They're implemented by using banks of sim cards placed in some apartment somewhere, so it's as "real" as it can get.

https://cotsi.org/methodology


Objectively, it gets even worse in regions where Google voice isn't available. The only options seem to be online SMS portals where a relatively small set of numbers are shared across many users.

If anyone knows of a good, secure VoIP provider outside of the US I'd be keen to hear about it.


Jmp.chat is the same sort of the same thing as Google voice and is allegedly based in Canada. It has the bonus feature of using standard XMPP clients.


VoIP.ms works great in both the US and Canada. (I believe it started here in Canada.)

Also, many Canadian financial institutions (including the CRA, Wealthsimple, and BMO) work fine with US phone numbers for 2FA… including Google Voice, in my personal experience. https://www.reddit.com/r/Googlevoice/comments/1c571kw


VoIP.ms is hard to port into and out of, I've repeatedly seen them drop part of the account number when transferring a number, then drag their feet for days thereafter on resubmitting the port.

Always ask for the Port Order Number (PON) so you can follow up with the other carrier to see what they received from VoIP.ms


I've only done it a few times in each direction, but I've never had an issue porting in or out of VOIP.ms, and it seemed easy enough to me.


That's frustrating, but why are you so concerned with porting out of VoIP-based carriers?



Not sure what IMSI rotation has to do with baseband vulnerabilities?


It stymies attempts to track mobile devices over multi-day periods using their IMSIs.

Trackability is definitely a vulnerability.


Right but it’s not a baseband vulnerability


Huh …?

IMSI tracking is a consequence of how baseband devices communicate over-the-air, just as WiFi MAC address tracking is a consequence of how 802.11 devices communicate over-the-air.

And it's definitely a vulnerability, because it's used to track end users and reduce their privacy.

So it IS a baseband vulnerability. And IMSI randomization mitigates it to some degree, just as WiFi and Bluetooth MAC randomization mitigate tracking via those identifiers.


I’m arguing that just because a baseband processor is involved that doesn’t mean IMSI tracking is a vulnerability of the baseband processor itself. IMSI provisioning and randomization cannot be done without cooperation with the network operator and has nothing to do with the baseband processor itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: