Skip to content

Encryption, iOS and Windows

July 16, 2014

A problem that many mobile device developers seem to have escaped from is the difficulties in having symmetric encryption between a mobile platform and a server.  Nobody seems to have paid much attention to this and it is a non-trivial problem.

One way people have gotten around this is through the use of SSL.  If you are interacting with a web server, nearly all of your problems are solved simply by using SSL – i.e., HTTPS.

It is important to understand a distinction here.  There are two broad categories of encryption in the world: symmetric and asymmetric.  Asymmetric encryption involves the use of a public/private key pair and a different key is used to decrypt a message than the key used to encrypt it.  It is also pretty slow, which is why asymmetric encryption is often used as a means of exchanging symmetric encryption keys in a secure manner and then switching over to symmetric encryption for the bulk of data transfer operations.  Symmetric encryption is where both the encryption and decryption keys are the same and is generally a lot faster than asymmetric encryption.

Symmetric encryption is, at first glance, pretty simple to set up.  You simply pass a block of data to the “encrypt” function and you get back encrypted data.  Similarly, on the receiving end you simply run the “decrypt” function and get the unencrypted data out.  The problems start with getting everything to be interoperable across different platforms and then there it the small matter of the key.

Well, in the development of the DB Freedom app, it turned out that I had to solve this for sending data between a server (C++) and an iOS app (Objective C).  There are some data items that really need to be secure and DB Freedom is certainly the sort of app that is going to need to be secure.  What I found in looking at the options for things other people had done was pretty surprising.

The first part of the problem is deciding on what sort of encryption could be supported on both ends.  My first impression was AES 256 was the right way to go.  Well, unfortunately iOS and the CommonCryptor framework do not support AES 256, just AES 128.  There were not a huge number of other options available.

The next issue is the key to be used.  There are several shortcuts to building a key but none of them appear to be cross-platform in any respect.  So it is necessary to understand how to build a key, salt and initialization vectors.  There are plenty of people on the Internet that know way, way more about the current state of symmetric encryption than I do, so I am going to let you find other sources because the issues aren’t all that different for different platforms.  Let’s just say that any shortcuts you might find probably aren’t going to work across different platforms.  You are going to have to do it the hard way.

With this knowledge, I was finally able to use the Windows Cryptographic services and CommonCryptor on iOS to utilize encryption without building a separate implementation.  This is pretty much a requirement because if you build your own encryption into an iOS app there are more hoops to go through and potential export limitations.  Similarly on Windows, if you build encryption into the application you will have to contend with distribution issues in countries outside the US.  Some countries disallow the use of encryption altogether and some require further disclosure and/or licensing in order to import such applications.  Using a Windows or iOS service removes these considerations.

What did I learn from this?  First off, there are relatively few mobile apps out there that communicate with a server apart from a web server like IIS or Apache.  Secondly, because of this there aren’t a lot of examples of how to insure you are doing something that is interoperable across different platforms.

I also understand a bit more about the problems in sharing a secure key for symmetric encryption across a network link.  Yes, I can see the value in using a public/private key pair to enable sharing a truly randomly generated key – but this level of complexity wasn’t something that I was prepared to commit to.   One of things important in building any sort of application is when to say “No”.

Advertisements
One Comment leave one →
  1. July 16, 2014 3:21 pm

    A brilliant post here!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: