Security tips for mobile application developers
Mobile data at rest encryption is critical to securing a mobile app. That debate is long since over. Mobile devices hold sensitive data and people want that data regardless if you think it’s valuable or not. We all know it, so It blows me away when I see that there are still some mobile apps being developed without data at rest encryption.
Mobile data and encryption
Data on mobile devices is at risk to malicious apps and physical theft. This data ranges from personal photographs and texts to business emails and applications containing confidential information. Because these devices are with us everywhere, they are much more prone to being lost or stolen which puts the data they contain at risk. As I’ve blogged about before regarding mobile malware even malicious apps on your mobile device can record and steal sensitive data. To protect this data, hardware and or software encryption can be used.
Hardware encryption on mobile devices
Hardware encryption encrypts the entire filesystem, which includes the OS and user data while it’s in flash memory. It is then decrypted in main memory when in use. However, it’s not always in use and even when it’s enabled, users often want more protection.
Andrew Cunningham wrote about this in an article for Ars Technica: Why are so few Android phones encrypted, and should you encrypt yours? He stated that 95% of iOS devices operate with hardware encryption and only about 10% of android devices operate with hardware encryption.
Software encryption for your mobile apps
Software encryption encrypts a specific app such as a CRM tool or groups of apps like email, calendaring and contacts. Even with hardware encryption in place, software encryption adds another layer of security and the two are often used together.
Data at rest encryption challenges for mobile app developers
When you are developing an app that needs data at rest encryption you are often faced with variable data structures, choices among type of encryption to use and even regulatory mandates like FIPS that I’ll blog about later. Many mobile apps require different data structures for core functions, such as databases, logs and documents. Usually encrypting three different data structures requires three entirely different approaches to data at rest encryption. Often, one or more of these data structures gets left out for performance, usability and other considerations.
Appdome mobile app data at rest encryption implementation
What I like most about our data at rest encryption methods is that the data structure doesn’t matter. It can be broadly applied, without any constraints to a database, document, etc.
For starters, we use 256 bit AES encryption to encrypt what I’ll call “pieces of data” created by the app. We abstract data from the app and encrypt blocks of data regardless of its structure. That means it doesn’t matter if you have a database, log files or documents, the data at rest encryption will work across all three and you don’t need to code your app with encryption.
It’s highly customizable so you can even exclude specific data types such as MP3s from the encryption process. And here’s another cool part, we actually fill in for holes in the apps native encryption protection. That’s right, we can be used in concert with the existing encryption methods already in your application.
Appdome’s take on encryption versus app performance
When talking about encryption, it’s always important to not just consider encryption from a security perspective but from the perspective of speed. Appdome’s approach to abstract data encryption is much faster than file level encryption. Because of this, encryption can be deployed without a noticeable impact to the user in terms of app responsiveness and usability.
Thanks for reading! This blog is part of a series focused on security tips for mobile application developers. While it’s not intended to be an exhaustive analysis of security issues or Fusion, it’s my intent to use this blog series as a platform to help mobile application developers become more security-aware. I hope you found this information useful. Happy fusing!