As long as the phone maker and the phone service company play nice
I mean both of those things are usually something you can choose yourself?
I’m aware choices are limited with coverage and availability etc, which is also why i prefixed my statement with should.
For example here in Finland we have this thing called The Mobile ID. Which is commercial high security identification method, that works on the SIM.
That seems like a weird implementation, why would you bundle that with your SIM card?
Seems like a huge headache with stolen/lost phones, wonder how they handle revokation…
Probably only work for online services that can validate that it hasnt been marked stolen?
And wouldn’t it make alot harder to swap providers if your entire identity is tied to the card?
we have a similar thing but it’s a separate physical card you can use for identification, and with that card you can also issue mobile identification.
This entire discussion seems super offtopic though, but you seem really passionate about the Finnish Mobile ID solution.
Also physical external sim allows physical update of the crypto processor.
Are you really arguing that physical security vulnerabilities are easier to solve than a security software update?
It’s not out of the realm of possibilities that Phone vulnerabilities would affect the SIM card as well?
Presumably the phone does need to read the private key to authenticate?
With a software solution you could store the keys on Titan X chip/Apple T2/Samsung Knox(?)
which the OS knows to protect and keep separate…
But again, nothing about the mobile ID SIM solution contradicts anything i said?
eSIM allows for more flexibility overall, the market and availability might not be there everywhere but that is not an issue with the technology but rather it’s adoption (or lack thereof), atleast for all the countries not named Finland.
Seems like a huge headache with stolen/lost phones, wonder how they handle revokation…
Right maybe should have clarified that. The authentication is facilitated by the trusted middle party aka phone company.
When you log in using this service, you tell using service your phone number. Well their contacted authentication handler (usually one of the phone operators), they forward the request to your operator, who knows to forward it to the phone (as I understand as a network service SMS, like how operators settings updates also get send to the SIM and phone), this service message is handed by the phone cellular interface to the SIM. SIM applet notices “oh this is authentication request”. It displays the session ID of authentication (generated at the original authentication session and displayed there also) and then asks to enter security code to approve (or decline the request)
As such revocation is two fold. First your operator will list the certificate/key invalid. Secondly, since operator is handling the message passing anyway, they know to refuse to send the authentication requests in the first place to the compromised SIM. since as the SIM, that also defines where to send the requests. It is both the independent crypto validation, but also the cell network subscriber identity. Compromised sim stops getting any requests, since it is shutout from cellular connection. Can’t make calls, can’t send and receive texts, since the sim isn’t anymore tied to valid subscriber contact.
Plus with crypto system there is always the option of official public revocation server. Which kind of system is what the national ID smart card system uses. Anyone accepting identifying by those signatures gets told “the official key/certificate/revocation server is this one. Regularly check it for listed revocations by the root trust authority”
