formThe Problem:

Capturing sensitive data on a mobile device, sending it to a backend server and ensuring it’s secure and tamper proof.

We have been commissioned to develop a cross-platform mobile app that allows users to submit claims for reimbursement of expenses. The claims are to be captured on a mobile device and sent for approval to management. Once approved, this triggers a payment to the user’s own bank account.

A key element of the system is to give the user the ability to check and potentially modify their bank account details to which the payment is made.

Collection and transmission of highly sensitive details such as bank account details is always a worry – in the wrong hands this kind of data is potentially very damaging. The confidence and reputation of the company would be significantly damaged should any of that data leak in any way.

How can we protect that data at all times, especially within the context of a mobile application, as well as a publicly accessible web front-end to which that mobile system connects?

The obvious answer to that kind of question is to encrypt the data or use SSL/TLS. That is everyone’s stock answer, but the nature of the data and its lifetime within the system is more complex and requires much more thorough analysis.

Data Minimisation.

Analyse the need for the data you’re concerned about and its lifetime within the system you’re creating.

The user needs to be able to check the bank account number is correct while using the mobile app. Initially one might think that this would require the app to store those details in the user’s configuration or get access to them when the claim is submitted. However, on close examination that is not necessarily true. If the system defaults to the last known account details, the user may only need to check that it is still the correct account and not require us to handle those details every time.

Even in written communications to an account holder the data is typically truncated or obfuscated so that it’s limited to the last 4 digits of the account number. Instead of storing the sort code and the account number, we can reduce it to the sort code and the last 4 digits of the account. This obviates the need to transmit the sensitive data, providing the user sufficient feedback to confirm the correct bank account.

Making Changes

While we can store the data in its short-form, and therefore minimise the need to protect it, there is one scenario where we have to be more careful. If we are to allow the user to change the account details on a claim-by-claim basis or to update their details from the mobile device, we obviously need to protect that information.

Using SSL/TLS to encrypt the traffic between the device and the back-end server is an obvious standard precaution, however we deem this insufficient to protect that data while it’s in transit as the SSL connection itself still may be vulnerable to a man in the middle attack. It would be far better to encrypt the data itself in the payload of the message as well.

Encrypting the sensitive data within the XML message that is sent to the server sounds straightforward but there are a number of issues to consider.

  1. What encryption to use?
  2. How to manage and secure the keys?

What Encryption to Use?

Typically when talking about encryption we like to discuss the strength of the algorithm and whether AES-256 is better than Blowfish or Twofish and we laugh at the older schemes such as DES or even Triple DES. Rarely do I hear the question “what is the encryption strategy?”

“Its not just the encryption algorithm its the encryption strategy that matters”

We could use a good strong encryption algorithm such as AES-256. It would generally be regarded as a very good choice. However AES is a symmetric cypher, one where the keys to encrypt and decrypt the data are the same and must be shared between the sender and recipient of any secured message or data.

That sharing of keys is very problematic in the scenario we’re trying to secure. Using any symmetric key cypher would require the keys to be present on the mobile device and on the back end server. Securing these keys would present huge challenges to any designer and would rely on either total secrecy, which we know is impossible, or some form of key exchange mechanism, such as IKE, which would increase the level of complexity to uneconomic levels.

Public-Private Key

An alternative to AES or other symmetric key cypher is to use a Public-Private key strategy or PKI. The use of public key encryption has the one huge advantage over AES or any symmetric key cyphers in that the key used to encrypt the data can be made freely available, in itself is neither sensitive or needs to be protected. **

The solution to our problem of protecting sensitive data when being collected on a mobile device is simply to encrypt the data with the PUBLIC key of a Public-Private Key pair and send the data to the backend where the private key can be used to decrypt the data where it’s needed.

In our example the form data is encrypted right at the point the submit button is pressed by the user and the original text is destroyed. The encrypted data is placed in the XML message and sent to the backend server. The bank details are never stored on the device in the clear (apart from the last 4 digits) and the message is invulnerable even if the transmission is intercepted.

When to Decrypt and Key Storage

We went one stage further with this idea and maintained the encryption of the bank data even within the backend user database. The data is never decrypted until it reaches the PCI compliant payment gateway, i.e. the exact point it is actually needed. Further measures increase the level of security by ensuring that the PRIVATE key is stored in an HSM which should prevent the key ever leaving the security of the PCI compliant environment.

HSM Secure Key Storage

HSM Secure Key Storage

HSM, or Hardware storage modules are hardened security devices that can be used to store and protect encryption keys and other cypher material such as digital certificates.

An HSM is a dedicated encryption engine processor that is specifically designed for the protection of the crypto key lifecycle. Hardware security modules act as trust anchors that protect the cryptographic infrastructure of some of the most security-conscious organizations in the world by securely managing, processing, and storing cryptographic keys inside a hardened, tamper-resistant device.

Why Use Hardware Security Modules?

Hardware security modules are used to protect transactions, identities, and applications. HSMs are the best way to secure cryptographic keys and provide provisioning encryption, decryption, authentication, and digital signing services for a wide range of applications.

See more at: SafeNet HSM

Next Week

In the next article I’ll discuss some of the coding issues around the encryption strategy we used and show how we built the necessary code and test environment for encrypting data with OpenSSL and C# and Public Private key cryptography.