How to Eliminate Framework Dependencies in Mobile Data Encryption
This article is part of a multi-post blog series about common but difficult challenges mobile developers face when implementing mobile app security features or 3rd party mobile SDKs into Android and iOS apps. You can find the other posts from this series listed in the final paragraph below. In this post, I’ll discuss how to eliminate framework dependencies in mobile data encryption, and how developers can overcome compatibility issues and other complications they face when implementing data-at-rest encryption for iOS and Android.
A major challenge developers face when attempting to implement mobile app security using SDKs, open-source libraries, or specialized compilers stems from the fact that these methods all rely on source code and require changes to the application code. And as a result of that, each of these methods is explicitly bound to the specific programming language that the application is written in, and are also exposed to the various programming language or package ‘dependencies’ between those languages and frameworks. In software development, a dependency is a broad term used to describe a program or piece of code that relies on another program in order to run or to perform a function. For instance, if Program A requires Program B to be able to run, Program A is dependent on Program B (and vice versa this makes Program B a dependency of Program A). Now let’s explore how framework dependencies hinder mobile data encryption efforts.
What is Data Encryption and Why is it Important?
Data encryption is the process of encoding data to transform it from human-readable format into non-human readable format (aka: ciphertext), whereby only the holder of a private key can decrypt/read the data.
Data Encryption is one of the most important security methods to protect mobile app data because it ensures that data can only be accessed or read by its intended recipients (people, servers, or other machines, etc). If the data should fall into the hands of anybody or anything for which it wasn’t intended, then that entity would not be able to read the data unless they could decrypt it (by using the private key).
In mobile apps, it’s important to encrypt data in all 3 states that it exists (at rest, in transit, and in-memory). To keep this blog focused, I will cover encryption of data-at-rest (DAR encryption). And I will touch on some of the challenges of implementing encryption in mobile apps using do-it-yourself (DIY) methods.
Developer Challenges in Encrypting Data In Mobile Apps
Some of the key challenges developers face when implementing data at rest encryption are outlined below:
What Data Should be Encrypted in Mobile Apps?
In both iOS and Android apps, there are many different locations or parts of the mobile application where data is typically stored. This includes the app sandbox, user/system preferences, user defaults (eg: NsUserDefaults), resources, configuration files (eg: info.plist), XML strings, or even external locations such as an SD card (for Android). Since these are well-known locations and because a plethora of tools exist to mine or extract or this data (decompilers, disassemblers, etc) it would be wise to consider encrypting sensitive information stored in these locations or other parts of the application.
If you decide to implement encryption on your own (or using an SDK or open-source libraries), some of the challenges you’ll face consist of:
Data Structure Challenges
Different data types have varying sensitivities to latency, I/O, or retention. The choice of algorithm can significantly impact the app’s security as well as its performance. Where you store the data will also constrain your choices on the encryption model you use. How often the data needs to be accessed and by what/whom/when the data needs to be available is also a consideration.
Programming Language Dependencies
Next there are programming language dependencies: Android encryption libraries or SDKs for Java may not work for Kotlin. In Android, there’s also the native C or C++ layer (for native libraries) to consider, which may require a completely different implementation or library, which would come with its own set of dependencies.
In iOS, same deal. You might visit StackOverflow and find that the commonly used Cryptokit framework for Swift won’t work for Objective C.
And what about Non-native or cross-platform apps? These are an entirely different ballgame as you’re dealing with web technologies like JavaScript, HTML5, CSS and non-native frameworks like React Native, Cordova, Flutter or Maui, Xamarin which won’t work out of the box (or at all) with SDKs or libraries built for native languages. In addition for non-native apps, you may not have access to the relevant source code files in order to implement encryption in the first place.
For a real-world example of a framework/library dependency for encryption, below is an excerpt from an iOS developer complaining because he was forced to introduce a 3rd party dependency when trying to implement Elliptic Curve encryption in a Swift app.
Encryption algorithm / cipher suite / key size
Another set of challenges lies with the encryption model itself such as: which algorithm and cipher suites are best for your data? How do you validate the security requirements or performance characteristics of the algorithm or key strength for your diverse data types? How do you know that you’re not implementing an encryption algorithm or cipher suite that has known security limitations or vulnerabilities?
Finally, there’s key management. How do you derive the keys, what key strength should you use, and most importantly where do you store the encryption keys? For Android apps, you might choose to use the Jetpack crypto library, but one of the main challenges you’ll need to face is key derivation and storage (since the recommended default master key and subkeys are stored within the Android application, which means that there is the possibility that those keys can be extracted and used to decrypt the data).
Data Encryption and Code Obfuscation Go Hand In Hand
Encryption also goes hand in hand with code obfuscation, where the goal is to make it hard for hackers to learn and understand the inner workings of your code and app by reverse engineering it (using static code analysis techniques). For instance, as part of your code obfuscation process, you should be thinking about encrypting the application’s strings (eg. strings.xml in Android apps, NSString in iOS apps) Why? Because hackers will often search through an application’s strings or perform cross-reference searches using a decompiler/disassembler tool in order to piece together the app’s logic, determine the best entry point or most valuable application classes to hack for example.
Challenges with SDKs and 3rd party Open-Source Libraries
There are commercial SDKs and 3rd party libraries available to developers who wish to take a DIY approach to encryption. But fundamentally these approaches often require extensive development work and ultimately introduce additional frameworks or programming language dependencies and incompatibilities. It’s like a huge Pandora’s box, and no mobile developer ever has enough time to work through all these issues related to security.
And I could go on for days. Not to mention, a misstep in any of the above areas could have a dramatic impact on the app’s performance, usability and security posture, the extent to which you’ll never know until you do the development!
And that’s just one security feature – data-at-rest encryption! A solid security defense requires not only encryption alone, but also other common security best practices that complement and reinforce each other – including jailbreak/root prevention, code obfuscation, anti-tampering, app shielding/RASP, certificate pinning and/or certificate/CA validation, etc. Doing all that using SDKs or 3rd party libraries would be an insurmountable feat requiring dozens of SDKs, libraries, packages, plugins. This is why I have always stated that mobile SDKs can never fit into a DevSecOps model. Each SDK could be its own development project, requiring manual coding, specialized resources, trial and error development work. Each SDK would introduce its own framework and programming language dependencies, which may in fact conflict with one another, especially if you use multiple programming languages in your app (eg: Android apps may use Java or Kotlin for parts of the app and import native libraries using C or C++).
Given the complexities covered in this blog, it’s not hard to understand why most mobile applications do not have comprehensive encryption or other required best practices implemented and thus are relatively easy to hack. It’s a vicious cycle.
So how can mobile developers solve this seemingly intractable problem? The answer lies in automating mobile app security.
A Better Way: No-Code Mobile Data Encryption for Android, iOS apps
Using Appdome, you can implement data at rest encryption in any iOS or Android app in seconds – no coding, no SDK, no open-source libraries, no framework dependencies.
This Knowledge Base article describes Appdome’s mobile Encryption solutions and explains how to encrypt data-at-rest in any iOS or Android app instantly.
Unlike SDK-based and manual encryption methods that only encrypt part or all of the application sandbox, TOTALData Encryption encrypts both data stored in the sandbox as well as data stored throughout the code. Using Appdome, you can easily encrypt app preferences, strings, resources and in-app secrets, strings.xml value, and java class .dex files and more, all without any coding.
And key storage is not a concern; Appdome’s technology dynamically generates encryption keys at runtime and encrypts all data generated and stored in the app using industry-standard AES 256 cryptographic protocols (so encryption and decryption happen on the fly, whenever the data needs to be accessed). Encryption keys are never stored inside the mobile application.
Video: How to Encrypt Data-at-Rest In Mobile Apps In Under a Minute
Check out this short 1-minute video to see how this is done. Again, this works for any mobile app on the planet.
That’s it for today. Hope you enjoyed this post. Here are the other related blog posts from this series:
- Native and Non-Native Framework Differences
- Code Obfuscation for Native and Non-Native Apps
- Jailbreak Prevention and Rooting Prevention
- How to Handle Webview Incompatibilities in Mobile Apps
- Secure Remote Access without an Enterprise VPN
If you’d like to see Appdome in action, feel free to Request a Demo by clicking below.
