Mobile App Encryption Made Easy | Appdome

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 the 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 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.

Developer Challenges – to DIY Encryption (in source code)

When developing an app that needs data at rest encryption, mobile developers need to resolve multiple challenges:  For one,   you are often faced with variable data structures, choices among the type of encryption to use and even regulatory mandates like FIPS 140-2 (see separate post on FIPS 140-2 encryption). 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. And that results in the data being unprotected.

Appdome’s No-code mobile data at rest encryption

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. In addition, the frameworks and methods developers use to build apps also do not impact the encryption model (because Appdome’s technology handles all of that complexity on behalf of customers).

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.

For advanced use cases, Appdome also provides a way to manage and control various elements of the encryption model. For example, you can seed your own key, control which algorithms, cipher suites, key derivation techniques and key strengths). You can even exclude specific data types such as video files or images from the encryption process. These optional features enable customers to fine-tune the encryption model and adapt it to their specific use case or app.  And here’s another cool part, Appdome can be used in concert with the existing encryption methods already in your application. Appdome’s technology fills in for holes in the app’s native encryption protection.

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 and performance. Appdome’s approach to abstract data encryption is much faster than file-level encryption. Because of this, you can add encryption to any app without a noticeable impact on app responsiveness and usability.