iPhone Banking Proxy

While we are quite pleased with the performance of the Banking iPhone application when a wifi network is available, the speed at which account balances and transaction histories are retrieved over 3G (and even more noticeably; 2G) leaves a lot to be desired. Even though 3G bandwidth is quite respectable (usually about 1 mbit/s on my Optus 3G connection), latency is the performance killer. 3G connections can be likened to the “long, fat pipe” model often used to describe the woeful one-way satellite connections of yesteryear. By that we mean it takes a long time for a round-trip between your phone and the bank’s servers, but the data contained in that round trip is quite generously portioned.

Typical latency on a 3G connection on a good day can range from anywhere between 500ms to more than a few seconds. This is bearable (just!) when surfing the web using Mobile Safari, but is a real killer if you want to load half a dozen pages (or more, depending on the bank you use and how many accounts you have) in quick succession and you can’t parallelise it on account of not knowing the correct URLs ahead of time. This is compounded by the SSL/TLS underpinning secure web surfing requiring a substantial handshake.

The link to Wikipedia goes into much more depth than we need for our purposes here, but I will recap the important aspects here. When you connect to your bank’s server (by means of either the browser or Banking application), you must first establish a secure channel to prevent malicious eavesdroppers from snatching your confidential password and financial information. This process is shown below:

1. The client (i.e. the browser or Banking application) sends a ClientHello message to the server, indicating its desire to establish a connection.
2. The server responds with a ServerHello message, a Certificate message and a ServerHelloDone message.
3. The client now sends a ClientKeyExchange message, a ChangeCipherSpec message and a Finished message.
4. The server sends its ChangeCipherSpec message and its Finished message.
5. A secure channel has been established and only now the client can transmit its request for the webpage.

SSL/TLS requires at least two round-trips (and non-negligible associated cryptography computation) in addition to whatever communication it encapsulates. It should hopefully now be apparent why a secure website is slower to load even on a desktop computer (which, on a broadband connection, can be subject to latencies as low as 50ms to local web servers), let alone the painful experience it is over a connection with large latencies.

With this in mind, we set out to see what we could do to minimise the effects of this latency upon the Banking application’s performance. We couldn’t switch to vanilla HTTP as the banks will not allow connections over non-secured HTTP (and rightly so), but even if they did, we would not be happy transmitting login credentials in plaintext. Even then, the performance improvement would be negligible as a secure channel needs only be established once per session per bank. The fact that we had to load more than half a dozen pages would marginalise the benefit of removing two round-trips.

We arrived at the conclusion that we’d have to implement functionality that we had been keen to avoid until just now. As hinted at in the title, this was a global (i.e. hosted by us, Glass Echidna) proxy server that all clients could use as an intermediary to communicate with their banks. Disregarding the technical implementation, this would require another level of trust (above and beyond storing your login password in the iPhone Keychain for use by our application, which can be audited by ensuring no communication with non-bank servers ever takes place.) as you would be transmitting your password to our servers. Obviously, this will be an option disabled by default and suitable warning will be provided should a user enable it.

We decided that with time, some users would decide to trust us and take advantage of the advertised speed advantage. At this point, the application redirects its efforts towards our server. The initial connection from the device to our server wraps up the usernames, passwords and a shared secret (we’ll get to that later) for each bank in a compressed message encrypted with our RSA public key. This ensures that only our server (and not an imposter) can read the plaintext message.

Upon receiving this request, our server uses its private key to decrypt the message and immediately begin logging into your bank accounts and retrieving balances and transaction history using its high-speed connection. Once this process has completed, the server bundles together all this information in a format appropriate for the application; essentially stripping out all the useless formatting data from the webpages. This is then compressed and encrypted using AES (the key being the shared secret mentioned above), as symmetric-key cryptography is much less computationally-expensive than the asymmetric RSA. Finally, it is sent to the client application as one message.

The important aspect to take away from the above two paragraphs is that the entire exchange requires only a single round-trip between the iPhone and the server and no unnecessary data is transmitted to the iPhone. When logging into all our test accounts (with WBC, ANZ, STG and NAB; totalling 12 accounts!), the traditional method takes anywhere between 60 – 120+ seconds, depending on how congested the 3G is at that moment. Using the proxy, this time is reduced to under 20 seconds consistently and usually on the order of 12 – 15 seconds. A significant improvement, if we’re allowed to say so ourselves!

For those readers that are interested, the shared secret mentioned above is a StoreKit-generated receipt. We will be selling access to the proxy service for a nominal cost (to cover the expense of hosting such a service) using the in-app purchasing mechanism made available by Apple in iPhone OS 3.0. Apple provides a mechanism by which developers can verify the transaction receipt remotely (e.g. from our proxy server) and if this receipt is valid, we can then use its contents as a shared secret known only by the proxy server and the user’s device. In essence, this is a stripped down version of the TLS model for our own application.