Why service providers didn't implement something like SSL to make SMS more secure and reliable in multiple scenarios ?
I did ask a question about why SMS is used as a way of verification while it is not encrypted in transit.
Why service providers didn't implement something like SSL to make SMS more secure and reliable in multiple scenarios ?
I did ask a question about why SMS is used as a way of verification while it is not encrypted in transit.
It is for the very same reason that SMTP does not encrypt everything by default: they are rather old protocols that were invented in a time when strong crypto was not common. And they are normalized protocol for which interoperability is essential. In fact changing SMS to include encryption, would be close to propose a new and different protocol (Signal ?) and wait/hope that the new protocol replaces the old one.
After all, it took decades for HTTPS to replace HTTP...
The original SMS design was limited to a small number of characters because it made use of an otherwise unused portion of the channel between the phone and the tower. There wouldn't have been sufficient space to set up an SSL or TLS connection, and moreover, the earliest phones with text messaging were not designed to handle the modern, secure algorithms we use today in TLS.
Cryptography in mobile phone protocols has overwhelmingly been quite terrible for a long time, and it's only with the advent of smartphones that phones became capable enough to use strong algorithms. With the development of more efficient cryptographic algorithms, it's likely that even today's feature phones could use TLS, but for backwards compatibility reasons, they don't.
This same pattern can also be seen in other embedded devices that have long tail lifetimes, like EMV credit and debit cards and terminals. For backwards compatibility reasons, they continue to use relatively small RSA keys, SHA-1, and, in some case, Triple DES, despite better algorithms being available.