There are mobile banking applications that use SMS channel to communicate with their server. Some of them offer both internet and sms channels which the customer gets to choose from.

While there's much data on secure communication via internet (How to implement TLS, certificate pinning, etc) by OWASP, Enisa, Gartner and other organizations there seems to be lack of guides and tutorials on how to have data transmitted securely over SMS channel.

Several options come to my mind about secure architecture for SMS data transmission:

  • PGP like system where server's public key is bundled with the application and resides on customers phones. The application uses this key and a symmetric key to encrypt its data.

  • HTTPS like system where each time the client and the server communicate, they agree on a session key and the data is encrypted using that.

Other solutions where symmetric key is stored or generated on the client side and no public key cryptography is used are generally insecure.

SMS has a limited length so one of our goals in this system has to be keeping the messages as short as possible, what are some ways we can achieve this goal without losing the security of the system. (Does it make the first proposed option (PGP like) more suitable?)

In this scenario the data is encrypted both by the server and the clients, integrity is our concern here too and we want to keep the number/length of transmitted messages as short as possible to minimize round trip time and number of text messages sent.

5 Answers 5


The TextSecure Messenger (now called Signal) provided encrypted sms based on a public key encryption scheme. However, they dropped the feature a year ago. According to the blogpost, the reasons for dropping the support were the impossibility to do this properly with iPhones and the bad security of SMS in general.

This is of course only one example - but it shows one possible approach to encrypt the content and protect the integrity of SMS messages.

I can't help you with the details of the cryptography involved - but maybe it's worth looking into the documentation and the sourcecode of Textsecure / Signal / Silence (Textsecure fork).

  • I coudn't find which cipher method is use in Silence, are you familiar with that?
    – Mirsad
    Apr 26, 2016 at 19:55
  • 1
    If this paper is correct, then Signal uses "AES in both, counter mode without padding and cipher block chaining mode with PKCS7 padding" and a HMAC- SHA256 for the integrity of the messages. For asymetric encryption, ECDH based on Curve25519 is used. Please note that the paper is from 2014 and TextSecure was renamed to Signal last year. And as Silence is a fork of Textsecure, it should use the same cryptographic schemes as TS.
    – Lukas
    Apr 26, 2016 at 20:55

There is no secure data transmission over SMS. The data is exposed to a large variety of information disclosure threats from and through the telco, from tools which sync your SMS to email (such as Exchange and Google Voice).

As Lukas says, it is super-hard to encrypt your data and then send it via SMS. If you're going to build an app, then why use SMS as a transfer layer? If you're not going to build an app, then SMS is insecure.


Long story short: For legacy reasons there isn't away to encrypt SMS as a whole. But what about the message itself?

Now I'm not saying you should do this, but you could easily use a key to encrypt the message you want to send, then send the encoded message in a few texts with meta information to link them together. Then you just need another way to send the key securely and privately to the other person. That's the real question.

Of course this shows the real question you should think about instead: Why should I use SMS to send secure data? And the answer to that is you shouldn't.


I'm not aware of any existing technologies that do this. It seems to me that any kind of PKI would involve sending data through untrusted carriers and seems generally fraught with peril. In addition, the key lengths you would want to use for your public key may not even fit within a single SMS due to the length and different possible character encoding protocols.

The only solution that comes to mind for me is to use something like Diffie-Hellman to generate a shared key and then use symmetric encryption over SMS, which again, may run into issues with character encoding. Like you mention, this key would be stored on the device as a per-conversation (SIM-SIM) key, which could be extracted from the device and used to decrypt a conversation.

SMS has been used for almost 30 years at this point and simply wasn't designed with security in mind. Most other protocols facing this issue have needed to be replaced by a more secure version or wrapped by some other security. It's possible MMS security may be more likely, but I don't know very much about that.


I may be sound paranoid and disappointing, but IF your customers are on stock firmwares/spywares/crapwares or - even worse - on iOS, then you have no other option than an external message decryptor/signer, an offline one based on sealed system with pre-seeded key, or - at least - an OTP time-based token. PGP, RSA, SSL, e.t.c. are good unless compromised by firmware. No further comments to add, sadly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .