Data security in mobile applications
"In April 2016, the FBI appealed to a specialist company to unlock the iPhone of Syed Farook, one of the prepetrators of an attack in San Bernardino in the US. After a tense stand-off lasting several weeks, in which the FBI attempted to convince Apple to provide a way to unlock the telephone, the FBI eventually managed to gain access to the protected data via a back door."
This event has given rise to heated debate and controversy regarding the right to a private life and the legality of the method used to break into the phone, reminding us that telephones and tablets, which are becoming more and more common as part of IT solutions, are becoming an increasingly sensitive element in terms of information security.
Security specialists are on the case, working to protect companies’ data against external attacks and are constantly adapting the systems used to ensure maximum protection for their information. On the other hand, as employees, we are also demanding easier access to this data in mobile environments, even in situations where the connection is sub-optimal. Users can therefore carry sensitive data in their pockets, and in so doing, run the risk of having their devices stolen by third parties – or simply misplacing them. Protecting data on mobile applications is therefore very important. While it is a little technical, we explain what you can do to secure your data.
Risks specific to mobile devices
The current trend of using private devices in a professional setting (bring your own device - BYOD) further complicates this problem by allowing business applications (with company data) to run alongside applications for private use (such as games). Such private applications may not always come from reliable sources, and the applications may be able to interact with the mobile device without this necessarily being visible to the user. An application such as Facebook running on an Android platform, for example, is notified when an SMS is received, and can even intervene further (by reading the SMS, saving the information it contains, or sending the SMS to another application). This is a critical issue, because some e-banking systems use a secure authentication system based on SMS messages, and there is nothing in place to ensure that these messages are not intercepted by an application such as Facebook, or even transferred and stored in the foreign application’s database. Something that is possible with Facebook is also possible with a malicious application, distributed under the guise of a free game, for example. Once permissions have been granted, the application can access a range of information from a smartphone. It is worth mentioning that the new version of Android (version 6) allows individualized permissions management as is possible on iOS, but there is nothing in place to force applications to adhere to this new method of authorization (mainly due to the need to ensure backward compatibility).
While it’s possible to implement custom application-specific encryption mechanisms (as is for ELCARD), in some cases, after careful evaluation of the data and the associated risks, it can also be decided to not store extreme sensitive information on-device and consequently having to be online to consult them, even if it means sacrificing convenience.
The Microsoft approach offers a clear advantage, as it means that a user can control who sees the document after he has given access to it. If the recipient of a document sends it on via e-mail, the new recipient will be unable to open it.
The ELCARD mobile application is part of the multifactor authentication solution developed by ELCA. It offers secure user authentication by using a smartphone at the moment of connection. This application is used by ELCA employees and many of their clients to connect to their company VPN. Indeed it is essential to have an application that guarantees excellent security for data stored on the device. This application works using an authentication token, which is generated and then sent to the server to validate the identity of the user. This token is calculated using a coding sheet and incorporates a range of information: a challenge sent by the server, the identity of the device and a pictogram to be completed by the user (principle of password-based encryption, where the data encryption key is derived from a password, neither of which, in this instance, are saved anywhere). All this information combines to generate the authentication token, the accuracy of which can only be verified by the server. The coding sheet, which is a central component of the algorithm - together with the user pictogram - is saved as an application-specific file storage on iOS, ensuring adequate isolation between applications. On Android, where the data are less isolated, this coding sheet is implemented using a native hidden plug-in application, which is different on every device. This device-specific application is generated by the server using identifiers from the device itself, and is integrated dynamically with the application on the mobile at runtime. This process takes place when a new coding sheet is activated and ensures that copies of the application on other devices are unusable (since the native integrated plug-in part is no longer compatible with the device’s identification). This system also serves to limit the range of an attack through the use of reverse engineering (decompiling an application code) to a single device.
Handling Sensitive Data in the Health Domain
As corporations continue to bring their professional health applications to the mobile space, ELCA is constantly exploring state-of-the-art of mobile device security, in particular around the following topics:
- Secure backend communication.
- Secure on-device storage solutions.
Today, the best practice approach for authorizing mobile applications is the OAuth 2.0 protocol. Yet, as a research paper by Microsoft shows, close to 60% of the most popular apps available on the Google Play store "contained faulty protocol implementations that are vulnerable to attacks". Indeed, the OAuth2 protocol specification itself (more specifically its authorization code grant flow), contains a well-documented security flaw affecting mobile apps. As a consequence, ELCA recommends taking the proper mitigating measures (as described in a recent IETF draft) whenever OAuth 2.0 is being used.
Even though on iOS data is stored in isolated application sandboxes and encrypted by default, it is important to keep in mind that the encryption (and hence, protection), relies on the strength of the on-device passcode. With applications available through the public app stores, this poses a particular challenge since developers have no way of enforcing the usage of such an on-device passcode (note that this can be mandated when integrating the app in an enterprise scenario by Mobile Device Management solutions). While it’s possible to implement custom application-specific encryption mechanisms (as with ELCARD), in some cases, after careful evaluation of the data and the associated risks, a decision may be made to not store extremely sensitive information on-device, and thus there is a need to be online to consult the user, even if this means sacrificing convenience.
The approach taken by Microsoft’s Enterprise Mobility Suite solution is different, because it offers direct protection for documents containing information, and therefore does not rely on the application itself to guarantee this protection.
This feature can be provided thanks to the integration of Azure Rights Management (Azure RMS), which manages user authentications and encrypts the documents (whatever their format) in order to restrict access to them.
The system behaves as follows:
- The user must first hold an account with Azure Active Directory. This is mandatory in order to use the Azure RMS system.
- The document is encrypted for security and therefore cannot be directly displayed.
- When accessing a protected document, an access request is sent to Azure RMS.
- Once the user has received authentication, Azure RMS will generate a decryption key, itself protected by the user’s public key.
- Once back to the client, the decryption key can be decrypted using the user’s private key.
- The document content can then be displayed, and the user rights can be implemented by the associated application if it incorporates Azure RMS access rights management.
This approach offers a clear advantage, as it means that a user can control who sees the document after he has given access to it. If the recipient of a document sends it on via e-mail, the new recipient will be unable to open it.
This solution is available for both mobile platforms (iOS, Android and Windows) and desktop operating systems (Windows and Mac OS X), and it is directly integrated into the Office 365 package, as well as other tools such as Foxit Reader for PDFs.
Please note that the system uses Azure Active Directory, but the documents themselves are not necessarily available in the cloud – it is just the authentication process that requires a Microsoft cloud account.
The implementation of a mobile application entails new challenges, not least data security. Furthermore, the use of personal mobile devices in a professional setting, where professional applications sit alongside programs for leisure use, means that the aspect of data security in applications must be considered right from the conception phase. A standard risk/threat assessment is conducted using a data flow diagram, and a data classification is allocated according to the sensitivity level. The aim of the analysis is to evaluate the risk and to subsequently make well-grounded decisions regarding the conception of the application. It is therefore essential to rely on experienced partners to support the development and successful deployment of mobile applications.
- "OAuth Demystified for Mobile Application Developers", 23.05.2016 (http://research.microsoft.com/pubs/231728/OAuthDemystified.pdf)
- "Enhancing OAuth Security for Mobile Applications with PKCE", 23.05.2016 (https://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applic...)
- "Proof Key for Code Exchange by OAuth Public Clients", 23.05.2016 (https://tools.ietf.org/html/draft-ietf-oauth-spop-15)
- "A (not so) quick primer on iOS encryption", 23.05.2016 (http://www.darthnull.org/2014/10/06/ios-encryption)