Sending Secure SMS – That’s Crazy Talk!

Many of us know that when we send an SMS (aka text message) it is sent in plain text and can be read by anyone with sufficient access.

This is normally limited to your cell provider but there are hackers out there using readily available hardware to act as a cell tower and initiate a man-in-the-middle attack.

Now I don’t know about you but I seldom send a regular SMS message – I use WhatsApp most of the time. Not only does it allow group chats (very handy for communicating with the family – especially during Covid-19 Lockdown) but it also provides end-to-end encryption. This means that only the intended recipient(s) and myself can read the message content.

It’s not that I’m doing anything illegal of course, it’s all about privacy.

Now, before you start down the ‘what about terrorists and paedophiles’ route I’ve already covered my thoughts about that argument, normally spouted by Government officials when trying to justify an erosion of our privacy and freedoms, in a previous blog post.

The UK Government (and they are not alone by any means) are continually using this argument to attempt to force technology companies to weaken their encrypted messaging systems. They are calling for backdoors to be put in to allow ‘authorised’ agencies to access the data to aid with criminal investigations.

My argument is that should the tech companies relent and add these backdoors then the bad people will just use something else or, crucially, write their own. This would leave the rest of us on hobbled, insecure system with ‘authorised agencies’ trawling around peoples private messages attempting to justify their hard won access.

So what is involved in writing your own secure messaging system? Surely it’s not just an app on the phone. Surely there needs to be servers and things to receive and forward these messages to the correct recipients. How would a regular user set these things up?

Well, yes there does need to be some form of delivery system but that doesn’t mean we need to write it – there’s already one out there, it’s on just about every phone out there and it’s been tried and tested for years. I am of course talking about the humble SMS text message.

Hang on, SMS isn’t secure!

True, the way SMS works doesn’t add any encryption to the process – plain text goes in and plain text comes out.

But this doesn’t mean that we can’t encrypt the message before we send it and for the recipient to decrypt it at the other end.

Now, I consider myself as a pretty competent developer – but I’m not what I would think of as a “rockstar developer”. I won’t have any of the big tech companies banging on my door offering me a massive salary and stock options to work for them. But surely I could write a mobile app which would allow the user to send and receive encrypted messages over SMS. As it happens – I can, and did just that.

As a proof of concept (you’re going to hear that term a lot in this post) I wrote an Android application, using Xamarin, which handles Key Pair generation, Key Exchange via QR code, Encryption, Decryption and integration with the devices SMS functionality.

Encryption is handled by the Open Source Sodium.Core library which is a fork of libsodium.net (also Open Source) which is itself a wrapper around the well regarded libsodium library – yep, Open Source all the way down.

In the image below Bob is sending a message to Alice, they have already exchanged their public keys using the app to display and scan a QR code containing the required data.

Basic flow showing Bob sending an encrypted message to Alice (sequence shortened)

Lets break this down a bit and explain, at a high level, what is happening here;

  1. Inside the Shhh.SMS app Bob selects Alice as the message recipient and enters his message (he can add emojis if he likes – that all works too!)
  2. After clicking Send devices SMS app is opened with the encrypted message ready to send
    • Bob will need to specify the recipient from his contacts
  3. Alice receives the SMS just like any other and uses the SMS apps ‘Share with’ functionality to send the encrypted message content with the Shhh.SMS app
  4. Shhh.SMS opens and if it can verify the message it displays the decrypted text

After passing the message over to the devices SMS application is only exists on Bob’s phone in it’s encrypted form.

When Alice receives the message it is only decrypted for viewing within the Shhh.SMS application.

Moreover, while the message was being sent it was encrypted using keys that only exist, securely, on the sender and recipients devices. The cell carriers involved in the delivery of the message have no way of decrypting it.

So what’s the point?

Let’s get this absolutely straight – I did not write this app so that bad people could communicate with each other about bad things. That’s not the point I’m trying to make here.

The point is that the encryption genie is out of the bottle and it cannot be put back in. It’s just math!

“…it’s a proof of concept and lacks polish but that’s not the point”

If the world Governments think that outlawing the use of encrypted messaging applications is going to stop bad people from using them then they are frankly deluded.

This app took me a couple of weeks of evenings to put together – sure, it’s a proof of concept and lacks polish but that’s not the point. The point is that if I can write this in a couple of weeks as an investigation, what could others with a more sinister mindset achieve?

The general public are, generally, good people. So why should we all be treated as if we are criminals?

When privacy is criminalized, only criminals will have privacy.

Daniel Suarez, Change Agent

Our privacy is being eroded because of a small minority of bad people. Laws are being passed that target a tiny proportion of people but affect us all.

You may be surprised to know who can currently request (demand?) access to your internet browsing history from your Internet Service Provider. Some are obvious, GCHQ and the Home Office, but I’m still at a loss as to why the Welsh Ambulance Services National Health Service Trust would need access to such information. And this is all without considering the security and accessibility of this data – is it just the agencies on this list?

OK, so how do I get the app?

As previously mentioned, this is a proof of concept and nothing more than that.

The user interface is basic and pretty ugly (no attempt has been made to style the app beyond some basic layout). The code could do with refactoring and cleaning up.

It certainly is not ready for the Google Play Store (development was Android only) and I have zero intention of making it so. That is not the purpose of this exercise.

What I have done is to make the source code fully Open Source and available on Github.

If you want to submit pull requests to fix problems or improve the app then please feel free to do so – but do bear in mind that it will never be my intention to release this as a production app via the Google Play Store.

By the way – did I mention that Shhh.SMS is only a Proof of Concept? Good, just checking 🙂

PersonalEncrypter – New and Improved

A couple of months ago I updated the PersonalCLI project to remove information leakage in the form of the original filename of the encrypted data. In my original post about this project I eluded to updating it to move away from the Microsoft encryption libraries and to implement the libSodium library instead.

Well, I’m happy to say that I’ve found some time to do this and moved to .NET Standard at the same time – yep, the future is here.

The initial project was really a quick and dirty exercise to demonstrate the ease with which these applications can be developed. It didn’t really lend itself well for extension – it was only meant to be a proof of concept after all.

In the new project I have created a class library to handle the mechanics of the encryption and a separate project for the CLI. There is also a skeleton project for a UWP desktop application which I’m currently working on (and committed in error – but hey, I’m only human). The UWP application will be initially aimed at Windows 10 but the ultimate aim to for a version of this project to be installable on just about any platform, e.g. Mac, Linux, iOS and Android.

Continue reading “PersonalEncrypter – New and Improved”

Personal Encryptor CLI v1.1.0 Released

It’s been a good seven months since I released the initial version of the PersonalEncryptorCLI project and in that time I’ve had more than a handful of emails asking me about the utility. Most of these were asking if I could/would be creating a Desktop version, i.e. something with a GUI. It seems only geeks like the Command Line – who knew 😉

Well the answer is yes, but I needed to clear the remaining issue that I had identified with version 1.0.0 – the need for the recipient to know the context of the encrypted content, i.e. whether it was a text file, an image or a Word document.

This was due to the initial release of the utility requiring the filename to be specified during the decryption process – including it’s extension. Now, if the user didn’t know that it was a Word document, how would they know to specify a filename with a .docx (or .doc) extension?

Continue reading “Personal Encryptor CLI v1.1.0 Released”

The Personal Encryptor 1.0 Released

 

Following on from my post about the UK Governments campaign to erode our privacy by demanding that tech companies put back doors in their encrypted products, I have created a simple utility to demonstrate how easy it is for a reasonably competent developer to create their own using standard development tools and libraries.

Now, I’m not expecting the UK Government to take a blind bit of notice but the fact is that encryption is out there, it’s only mathematics after all, and it’s not going away. You cannot feasibly make maths illegal – although the US did classify encryption as a weapon until 2000 (and to some degree still does).

Anyway, following my commitment to watch at least one Pluralsight course a month during 2018 I opted for Practical Cryptography in .NET by Stephen Haunts to give myself some suitable background.

The course was a minute under four hours and took me a couple of evenings to get through, Cryptography is not the most stimulating subject but Stephen did his best to key the information flowing. At times I did feel frustrated at how he seemed to labour some points but the upshot is that by doing this the information did seem to get through and stick. During the course he slowly increased the complexity, developing and enhancing C# code to demonstrate the principles.

It is this code which I have used as a base to create the ‘Personal Encryptor’ (hereafter referred to as PE) – a command line application that can be used to generate encryption keys, encrypt and, of course, decrypt data into files that can be safely sent over the Internet. Only someone with the required public and private keys will be able to decrypt the file and view the original data.

I’ll probably put another post together shortly diving a bit deeper into the functionality and explain the contents of the output file – but I highly recommend you watch the above course as Stephen know the subject inside out and does a great job of explaining it.

Why would I need/want to encrypt a file?

Imagine the following scenario;

Alice and Bob want to exchange private messages with each other; maybe they are planning  a surprise birthday party or sharing ideas about a new business venture. Whatever the messages contain, they are Alice and Bobs business and nobody elses.

  1. Alice and Bob both download the PE application and copy it to a location on their Windows PC (Mac version coming soon).
  2. They then use the utility to generate a Public and Private key pair – which will create two XML files.
  3. They each send each other their PUBLIC keys (this is just an XML file and can be freely sent over the Internet or via Email).
  4. Both Alice and Bob copy their PRIVATE keys to a safe location (maybe a secure USB key – or a normal USB key which is stored in a safe)

Now Alice wants to encrypt a file, a PowerPoint presentation for their new product, and send it to Bob

  1. Alice uses the PE application to encrypt the file using Bobs PUBLIC key.
  2. The PE application Digitally Signs the encrypted data using Alices PRIVATE key.
  3. A text file is created containing the encrypted data and everything needed to verify the contents has not been tampered with and to confirm that Alice encrypted it.
  4. Alice then emails the file to Bob as she normally would if she was sending a photo of her cat!

Bob receives the message and downloads the encrypted file to his computer.

  1. Bob uses PE to decrypt the file by specifying the location of his PRIVATE key and Alice’s PUBLIC key.
  2. The PE utility will check the digital signature using Alice’s PUBLIC key to confirm that it was signed with her PRIVATE key.
  3. It will then check the integrity of the package to ensure that it has not been tampered with in transit
  4. If all is well then the PE application will decrypt the file and write the contents out to a location that Bob has specified.
  5. Bob can now endure enjoy Alice’s PowerPoint presentation.

Of course if Alice (or Bob) just wanted to encrypt a file for their own personal use and not for sharing it is perfectly feasibly to provide their own Private AND Public keys to encrypt the data. These keys will be required to decrypt the data.

And that’s it, privacy restored/reclaimed.

I can now safely download my Lastpass vault in plain text, encrypt it and save it to any cloud drive I like, secure in the knowledge that, as long as my private key remains under my control, nobody can decrypt it to access it’s contents. Nothing illegal there – these are passwords to legitimate sites (Amazon, Pluralsight, Microsoft, Apple etc) and need to be protected. A valid use of The Personal Encryptor.

Going Forward

Yes, at the moment it requires the users to have some familiarity with the Command Line but this project was always intended to be a proof of concept. The original aim was to explore encryption to enable me to implement it in an existing mobile Chat application.

Creating a simple GUI would certainly be possible – a simple Winforms or WPF application to collect file paths and call out to the command line utility shouldn’t take too long for a competent developer to write. That said, I’m probably going to focus my attention elsewhere.

While using the Microsoft libraries is perfectly valid in my opinion, I am aware that many people will wince just a little bit. With this in mind I intend to investigate using the libSodium Crypto Library which Steve Gibson is such a fan of – so that’s good enough for me.

You can download the latest version of the Personal Encryptor application by clicking here. Alternatively you can download the full source from Github.