g_p

VoLTE and SIP do indeed retail a lot of the concepts of circuit switched. The challenge is that now you have the complexity of (seemingly invariably) a Telco managing a k8s stack on an OS they don't understand, and which has hundreds of CVEs per month they aren't patching. The failure modes of VoLTE/SIP are also a load more complex than CS domain issues - IMS interop issues and XML parsing delights await!

So I guess it's not only about getting off the internet - there is a real shift in complexity in these more modern stacks too.

You don't need to go out and buy hardware keys today. You should be able to use any FIDO2 key these days for SSH, as long as your server runs a recent enough OpenSSH server, which supports ecdsa-sk or ed25519-sk public keys.

Reputable vendors of those hardware keys included Yubikey and Token2, among others. You are really just using them as FIDO2 tokens, so go for what's reputable there.

If you are just getting started, you can generate and use software-backed keys (using ssh-keygen) and copy the public keys to servers' authorized_keys file using ssh-copy-id (or manually adding it). You should probably start learning this way (with plenty of online guides, and fewer risks of an old server implementation not supporting FIDO2 credentials), and then move to hardware keys once you understand the mechanics of copying around public keys, etc. Your password manager might also support acting as an SSH agent for key based logins - I believe Bitwarden and some others now do this, for example.

You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.

The data broadcast from ADS-B includes both GPS position (Lat + Lon) and altitude. If you created a bounding box, you could add a height parameter to make it 3D, and get a list of such aircraft and the timestamps of their transmissions while inside that (3D) bounding box.

That wouldn't be too difficult to do with a little bit of filtering of the feed coming out of an ADS-B receiver.

Yes, you should be able to. In essence, the state of the TPM is represented in the values of the PCRs (Platform Configuration Registers). Those are hash-extended through the boot process.

You can create a key or similar attribute which has an unlock policy based on those PCR values. If you play back the log of PCR write events from first principles (the log can be captured for debug purposes), you'll put the TPM into the same state and should be able to use anything protected by the respective policy.

For attestation, I presume you're thinking about sending an attested PCR quote - in that case, the TPM uses a non-extractable key to sign the current PCR states. As you can put the PCRs into the "correct" state, you'd be able to get a signed attestation the system is in that state.

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.

When roaming, your home network is needed for routing incoming calls to you, and handling authenticating your device to the visited network.

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.

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).

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.

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.

There's a couple of options in settings worth checking, as Netguard works for me when roaming just fine.

Under Settings > Defaults, make sure you don't have "block roaming" turned on.

Expand the rules for the apps giving you issues, and check "Block roaming" isn't ticked for them.

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!