On the Deprecation of JetSec Crypto
As the Android community might have heard, recently the Jetpack Security team at Google deprecated the “JetSec Crypto” SDK androidx.security:security-crypto. Some things have been written already about this, and one of the articles that (in my opinion) best describes the situation Android dev’s are left with is this one by Ed Holloway-George. Ed is a Google Developer Expert for Android and a well-known speaker, oftentimes about Mobile App Security. Today, I want to take a close look at the article and dig a bit deeper in some of the topics he touches on, either to complement them or, also, challenge them (a bit).
But, before we get the ball rolling, let’s use his words to explain what JetSec Crypto Crypto is (or was):
JetSec Crypto consists of only a small handful of classes, primarily wrappers around popular storage mechanisms, (i.e. EncryptedSharedPreferences and EncryptedFile) that offer convenient methods to encrypt/decrypt the data held within them. The library also provides a wrapper around Google’s cryptography library Tink through the MasterKeys class which, via a straightforward API, allows developers to create secure keysets for the encryption process utilising best practices for Android.
Storing Data Locally
Let’s go with the first point I wanted to share my view on:
To some extent, using EncryptedSharedPreferences should be seen as a red flag that perhaps your app isn’t following security best practices in the first place 🚩
Ask yourself, are you using the library for storing data locally on a device that’s sensitive? This would include data such as personally identifiable information, financial data, credentials, etc. If you are, should you be? Chances are, no — you shouldn’t. Any sensitive data should ideally be server-side, only fetched when required, and require some form of authentication to access.
Besides the philosophical debate of whether (backend-)centralized storage of sensitive user data is more secure than (device-)distributed storage of it (which I certainly don’t want to go into right now), as he rightfully points out later in the article, there are certain situations in which you might need to store data on the end user device. He mentions regulation as an example, but it’s certainly not the only one: another example would be the usage of such data in offline scenarios.
Even if we assume that not all developers will face this situation, what can those developers that do face it do? Certainly, using a deprecated lib is far from ideal — more so in the security space, where unpatched security software will result in… insecure software! As Ed points out as well, implementing it yourself is a bad idea, as it might end up just like before: an insecure implementation. In this situation, turning to security professionals and ready-made solutions is not only a guarantee, but a necessity to ensure things are done properly.
Dealing with Crypto
Another idea he drops in the article that I’d like to expand on is the following:
Another often-overlooked reason why JetSec Crypto is so popular is the APIs are straightforward and follow the best practices for cryptography in Android. […] This won’t change with deprecation and I’d always prefer (and recommend) to use this over rolling my own solution. That’s never a good idea…
Couldn’t agree more on that. And let me tell you why this is critical: cryptography is done by hardcore mathematicians. It is insanely complex. And, what is worse, it is extremely easy to get wrong: initialise a random array the wrong way and, all of a sudden, all your encryption scheme might fall apart. The distance between mathematicians and software developers is, unfortunately, too big, which means that, historically, Crypto APIs have been developed with the wrong user in mind (i.e. crypto experts rather than regular developers). Looking at you, JCE 😉
But, in the Android ecosystem, this gets even worse: the fragmentation in the device base makes things even harder for the suffered Android Developers. As I wrote a few years back in this article, there are several different “categories” of Android Devices when we look at them from the point of view of their capabilities in storing cryptographic keys. This means that Android Developers willing to implement some sort of cryptographic system by themselves need to either a) handle all this complexity on their own or b) fall back to the mechanism that is supported by all devices — which is, unfortunately, the less secure of all.
And last, but not least, we have the topic of key distribution and management. See, a cryptographic system is only as secure as the security with which their keys are protected. If we just need to create and AES (symmetric) key for encrypting locally stored data, then there is not much complication: you generate the key locally and store it with whatever mechanism the OS provides you. But, what if we want to use this key for encrypting the communication with our backend? Or what if we need to share the public counter part of a private key so that we can use it to authenticate against our backend? This is where it gets tricky, because you need a high level of assurance that they are transmitted securely (both in terms of confidentiality but also integrity), as they will represent the cornerstone on top of which your security system will be built upon.
As you can see, relying on professional solutions that take away all the complexity and provide robust and fail-safe implementations proves to be, again, of the utmost importance to implement secure and reliable systems.
Are Rooted Devices Safe?
And, finally, one last statement to be commented on:
[…] A common rebuttal to this is “Well, what about rooted users?” and yes, a user with root access would be able to read cleartext SharedPreferences but once the device’s integrity is compromised is anything really safe, EncryptedSharedPreferences included? Many experts (and I), would argue that it isn’t. 🥲 Some food for thought there!
Again, fully agree: when a device is rooted, nothing is really safe anymore. Basically, in a rooted device all the security mechanisms provided by the OS (Android, in this case) are no longer present (or, at least, they are no longer applying to those apps or software that runs with root privileges). Unfortunately, however, rooted devices are a reality in the Android ecosystem. Not only because users might consciously and willingly root their devices (for whatever reason they might have), but also because all sorts of malware exist that exploit vulnerabilities in unpatched versions of Android which grant their authors root privileges on the target’s device with the user not even being aware of it.
Data collected by Build38 shows that between 1% and 2% of the device base is or might be rooted (please take this numbers with a pinch of salt — there are huge variations depending on markets and geographical regions). So, should we just ignore those millions of users out there with rooted devices? Of course, that is not an option — and here’s where root detection (and reaction!) comes in.
In terms of root detection, unfortunately, it is a cat and mouse game: when a piece of software has root access, it has such privileged access that it can (theoretically speaking) disguise any third party software that is trying to detect whether someone has root privileges. This is why trivial root detection techniques (such as trying to read directories that would, in a “secure” OS, not be accessible) will not even stand the first round, and also the reason why popular tools (hello, Play Integrity API) are often defeated within weeks of their updates.
Reaction is also a tricky matter, as there is no right or wrong here: either you assume your app will run on insecure devices, or you deny access to (all or part of) your app to a relevant chunk of your users. Of course, neither option is ideal, but at least having the capability to strongly and reliably detect rooted devices is a starting point. On top of this, if you can have an app that is capable of operating in such compromised environments, even better.
