by Brian Contos, AppDome VP of Customer Engagement and IDG Contributor
Data at rest encryption is about as far from a cutting-edge topic as one can get. But while encrypting inactive data that is stored digitally is regarded by most security professionals as a must have, as well as data in use and data in transit for that matter, there are some special considerations that need to be thought through on the mobile side of the equation.
This is my latest in a number of blogs that looks at the intersection between traditional security issues and mobile. I’ve also written about mobile malware, mobile pharming and mobile phishing. I wanted to tackle data at rest encryption on mobile because like these other blogs, the particulars can be very different for mobile devices vs. traditional devices.
Hardware encryption
Hardware encryption is available on most modern mobile devices. However, while it’s very common to have encryption enabled on iOS devices at around 95 percent of devices, it’s estimated that having encryption enabled on Android devices is less common at around 10 percent of devices.
Hardware encryption generally follows some permutation of encrypting 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. A simple way to think about this is authentication process. When you authenticate with your PIN, fingerprint, etc. the device is decrypted and ready for use. When you lock your device either manually or because you’re inactive, it automatically encrypts.
Software encryption
If hardware encryption is the shotgun approach, software encryption is sniper rifle. Software encryption can be associated with a specific app or groups of apps. Perhaps you use it for your email, calendaring and contact apps or maybe it’s just your CRM app. Form a user experience perspective you would authenticate against your mobile device, then you would authenticate again for your app.
Having an added layer of software encryption intuitively makes sense if you are sharing a physical device, you have a device that doesn’t support hardware encryption or you simply have sensitive data that you want to protect with another layer of encryption just in case someone cracks, guesses your PIN. In this last case, they’ll get into your device, but your software encryption will still protect that app which hopefully has a different, stronger authentication mechanism than the one just cracked.
Other considerations
From the perspective of an application developer, when a decision is made to build an app with data at rest encryption, the data types need to be considered. Just like a traditional device, there can be several data structures like databases, logs and documents. Encrypting three different data structures could require three entirely different approaches. And for each approach there can be many options.
Consider a common mobile database like SQLite. Within SQLite there are multiple encryption options like SEE, CEROD, SQLiteCrypt, SQLCipher. With encryption there is always a need to consider performance. For performance, the developer may need to exclude some types of files from the encryption process like MP3 and MP4 files if it compromises the user experience. They also need to consider the type and level of encryption.
For example, do they want to use 256-bit AES encryption? Or is there a need for encryption that utilizes FIPS 140-2 cryptographic modules? The FIPS requirement is common for developers that need to demonstrate that their apps have data at rest compliance with NIST standards when deploying in US federal government agencies.
We all get that data at rest encryption is valuable. This holds true for mobile devices. On mobile devices there are a number of mobile-specific factors that need to be considered from a development perspective and a user perspective to ensure that data is safe while still meeting the usability requirements expected in mobile.
