Even with a ported number, inbound call routing still heavily relies on the "number range" owner to direct the incoming call to the correct network.
If the original number range owner has their subscriber database go down, they can't do the lookup for the network to direct the incoming call towards, so it can cause disruption. The same is true if the incoming signalling endpoints are unavailable, as the incoming call requests won't be responded to.
There are absolutely ways to intercept a call from a targeted user that would be viable to use to gain access to a mid to high value user's funds.
SS7 call routing and rogue 2G base stations are some potential approaches.
In terms of banking security, a good (ideal) architecture would treat the user PIN as a credential which is not transmitted over insecure means. Unfortunately many banks don't do this right, and still support bank-side PIN verification (with the PIN sent over the wire to the bank), rather than using the bank card's smart card features to carry out on-chip PIN verification.
If you built a bank from scratch, for security first, you'd likely still use smart cards as bank cards, but you'd only do PIN verification on-card, so the user PIN is never exposed to even the bank - the card can securely vouch for the PIN in a manner that's far more costly for an attacker to defeat than using a $5 wrench against the user of the card to make them reveal the PIN (h/t to XKCD).
Sending the card number and PIN over the phone is just asking for trouble - mobile phone calls are decrypted at the base station and available in the clear, before being transmitted up into the wider telecoms network.
While this is true, this is a completely different threat model than most people face.
For 99% of people, 99% of the time, what they need to worry about is someone calling them suspiciously asking for key information.
The fact that targeted attacks like that exist does not make it a good idea to treat them as ubiquitous. People with the kind of money that would make executing such an attack worthwhile should be expected to take higher precautions than the rest of us with it.
In terms of existing examples, there's a few equivalent (or at least similar) fields defined as SIM files - for example, the FPLMN (forbidden PLMN) list of networks your phone shouldn't attempt to attach to.
You're right that this needs limited at the modem - but the main user accessible method of configuring the modem is the phone UI. As this setting is one which needs network support, and is likely to disconnect a user who misconfigured this, a SIM file for permitted RAT (radio access technology) types would make sense, as SIM files are under the responsibility of the operator.
Where this would get complex is edge cases, like under roaming scenarios, where your home network can't predict what might be available, and your handset may need to permit downgrading to a technology not permitted on the home network.
The toggle in Android to disable 2G seems a start towards a user accessible setting for this, which selects what the modem is willing to join, but it's certainly far from a user friendly way to enable and disable particular technologies.
> To help ensure compatibility of iPhone and cellular iPad devices on private 5G SA networks, infrastructure vendors must adhere to the following security and privacy requirements:
> Privacy concealment: The Subscription Concealed Identifier (SUCI) must use a non-null protection scheme. This can be achieved through either an on-SIM SUCI calculation or an ME SUCI calculation, as outlined in TCA 2.3.1 and 3.1 specifications. For detailed information, refer to the 3GPP Technical Specification 33.501.
This pertains to private networks rather than public operator networks, but it certainly seems to imply that use of SUCI is an expectation on 5G SA networks (private in this context).
One thing I've always wondered is if you need a R15 sim card for it to use SUCI or if the old cards can receive provisioning to do it. I know for a fact you can use any USIM on t-mobile (so it had to support at least 3G) and it will work in the latest 5G devices without issue on SA.
You need a SIM card (ideally) with support for elliptic curve crypto, and some additional fields added in the profile (SIM services 124 and 125). You can then, once those services are enabled, place network public keys on the SIM itself.
There are 2 ways to do SUCI calculation - both require SIM support to hold public keys. SUCI-on-SIM requires a SIM that can do the encryption to the public key on the SIM itself, and issue that in response to the IDENTITY command; SUCI-on-phone requires a SIM that "just" has the public key fields present, and the handset can do the SUCI calculation and encrypt the SUPI for the public key stored on the SIM.
Either way, your scenario isn't using SUCI concealment by my understanding, unless you got a new SIM card, or it was reprogrammed somehow to support the SIM service fields needed (but I'm not aware of operators doing that).
A lot of the patents needed to implement mobile standards are designated as "standards essential patents", meaning that the party bringing them up the table in the standards committees needs to disclose them and agree to licence them on a FRAND basis to anyone who asks (fair, reasonable and non-discriminatory).
In many cases there are patent pools you can license that cover large areas of the standards, without needing to negotiate each one individually.
Many very fundamental parts of 4G/ 5G are patented and you'll not be able to get your device to work on the network without those patents, so Apple will have licensed those patents under FRAND for their new C1 modem.
Ooh this is interesting. Theoretically these could still be associated with my account right? Since you need to use my session token to generate these privacy tokens. Is there a technical explainer somewhere with instructions for setting this up without a web extension?
> When an internet challenge is solved correctly by a user, Privacy Pass will generate a number of random nonces that will be used as tokens. These tokens will be cryptographically blinded and then sent to the challenge provider. If the solution is valid, the provider will sign the blinded tokens and return them to the client. Privacy Pass will unblind the tokens and store them for future use.
So it seems like as long as the cryptography is done right and Kagi's webextension does what it says, they are actually private.
Awesome. I didn't see much detail about how it works in the page. Something like this would be useful for other sites as well. Is this using an existing technology?
(Firefox extension is not found. It's probably not in the store yet. Can't find with search either.)
We didn't launch this yet. It is in testing which is why we published this doc for testers. Full blog post with complete run down of the tech and implementation coming (very) soon.
Holy crap this is going to let me move some privacy-focused folks over to join me in Kagitopia. Good job guys, you are always working on something cool.
I recently came across a signature check that was (correctly) checking the signature against a public key... The issue was the public key itself was unauthenticated, and provided by the (signed) ciphertext itself... Meaning the crypto was fine, but it wasn't checking anything meaningful, as any rogue message would just include its own public key in the message!
It's not only about the raw operation of checking bytes are equal (hopefully in a constant time manner, if applicable), but also about ensuring the desired security properties are actually present in the application!
I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move.
I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA.
Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...
I'm also waiting for a password manager that tightly integrates with a hardware device to protect passwords individually and in-memory.
I wrote a quick PoC using certificates to encrypt a password, with the cert private key 'stored' in the TPM, with a PIN. This is pretty easy on Windows, which exposes the TPM as a special crypto provider.
If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used.
If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs.
That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.
That's a fair point, although as the PIN is validated locally, you could argue from the server perspective you gain a second (knowledge) factor, but from a local perspective it's entirely correlated with the existing stored factor (a weakness in the local device implementation can skip that PIN check and yield the result).
Perhaps this is excessive, but it's a model where I like to see layers of security that depend on different, uncorrelated failures being required to bypass them.
Today if you want to get into an account using "FIDO2 as MFA" you need both the account credentials or ability to reach the Fido prompt (say password reset), and the hardware token device (with optional pin). The device alone being compromised shouldn't get you into the account.
For anything that is important enough, I put passkeys on 2 separate FIDO2 key devices directly. Services that come to mind are things with recovery backdoors; like email or device backups. Unfortunately many banks and financial institutions don't support passkeys, but I'd consider using that solution there too.
If the original number range owner has their subscriber database go down, they can't do the lookup for the network to direct the incoming call towards, so it can cause disruption. The same is true if the incoming signalling endpoints are unavailable, as the incoming call requests won't be responded to.