I want to make an app like McAfee Secure Container. The container app should launch other (specific) apps and provide them isolated execution environment. There should be no data sharing outside the container and all the apps inside container should use container's network connection.
What can be a way forward?
I know one solution that runs each app within it's own dalvik VM with a unique ID (uid ref linux) to protect all resources for that app. It makes use of the linux file permissions to protect these resources. The only way to get apps running with the same UID is to sign it with the same publisher key and declare this ID in the manifest. To get resources world readable you have to declare this explicitly when opening the resources within the app. Further more the apps can only access certain system resources if they declare that permission in the manifest. Think of IO operations and so on. These permissions will than be prompted to the user and install time.
... It's called Android :-)
Or in other words what more do you search for than what is already provided by the Android system? If you're looking for security I would say the Android system is pretty secure on its own. Some threats I can think of are listed next.
A possible threat is that the system itself (not the app) is compromised (rooted or so). Then all your app data will be exposed on that system. The solution for that is encrypting your data. Google for Android Derived Key for more information on how to get a key from a user password and use that key to encrypt sensitive data stored on a device. The main rule here is to only store sensitive data if you really have to and encrypt it if you do. Also make sure to use CBC mode instead of ECB mode and provide a salt and an IV.
Never ever think that your code is save. Not even if it is obfuscated. Obfuscation does not make it impossible to get the code in a readable format. It just makes it harder. So it's always a bad idea to keep sensitive data in your code.
Another possible threat I can think of is network traffic. Use SSL/TLS and verify hostnames. Limit credentials going over the network by using generated tokens for authentication. Encrypt data over the network, this time use a dynamic IV. Also validate input and be aware of SQL injection.
Short answer : you can achieve this with Dynamic Library loading.
Long answer please refer to this:
https://www.youtube.com/watch?v=siVS2jmPABM
Related
After reading over tons of articles and stackoverflow posts, I can't find a concrete reason to use
EncryptedSharedPreferences or EncryptedFile compared to using their non-encrypted counter-parts.
To start off with, I want to talk about the 2 states of a device that security must be thought about:
the device is not compromised
the device is compromised
When the device is not compromised, the application is sandboxed. As long as the application follows Android's Security Best Practices, then the application should be fine -- security wise. Because internal app data is safe when the device is not comprised, there is no need to encrypt it.
When the device is compromised, there is very little an application can do to protect itself. The only real strategy is to minimize the amount of sensitive data on the device. However, EncryptedSharedPreferences and EncryptedFile seems to imply that it can protect user data even when the device is compromised, as talked about in Android's Blog Data Encryption on Android with Jetpack Security:
Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection... In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data.
But what does it mean by "extra level of protection"? According to the same Blog:
Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key... which is generated and stored in the AndroidKeyStore.
So Jetpack's EncryptedSharedPreferences and EncyptedFile uses the KeyStore to generate and store the keys for encryption. This is verified by examining the source code. And this is also where the problem is.
The KeyStore is not intended to generate keys to encrypt data local to the device. As the answer to the post Android - What are the practical security benefits of using a hardware-backed keystore vs software-only keystore vs no keystore points out:
The purpose of a key store is not to restrict access to an application or application data, it's purpose is to protect the credential from being exposed during use. Since a key store will willingly leverage its knowledge to encrypt data or access sensitive application information, it's not really a challenge for an attacker to leverage as you pointed out in many of your breakdowns across all three types.
This means that, on a compromised device, a malicious program can use the KeyStore to decrypt all of the previously encrypted data. The Android Documentation acknowledges this:
If the Android OS is compromised or an attacker can read the device's internal storage, the attacker may be able to use any app's Android Keystore keys on the Android device, but not extract them from the device.
This completely nullifies any encryption done by EncryptedSharedPreferences and EncryptedFile when the device is compromised.
To recap: When the device is not compromised, internal app data is safe. When the device is compromised, internal app data is not safe, regardless of whether it is encrypted via EncryptedSharedPreferences/EncryptedFile or not.
Question:
If the above is true, then what are the benefits to using EncryptedSharedPreferences and EncryptedFile? Is there a specific scenario where EncryptedSharedPreferences and EncryptedFile can protect internal app data, as compared to their non-encrypted counterparts?
EDIT 1:
As pointed out in the comments, "internal app data" is ambiguous. Specifically, I mean the location at /data/data/<package name>, which is protected by app sand-boxing and credential encryption. Also, in terms of this question, I would like to focus on Android 10+ as this is when FBE was required. However, I am also interested in scenarios in lower Android versions too (at the time of writing, minimum API level for EncryptedSharedPreferences/EncryptedFile is 21).
EDIT 2:
After re-reading the question, I think its also really important to be clear here by what the KeyStore is. The KeyStore consists of 2 major parts: a physical component (e.g. TEE, SoC, HSM) and an OS daemon. The physical component is the thing that performs crypto operations on behalf of the OS, so no process (including the OS) can know what the key is. The OS daemon is the thing that restricts usage of the physical component. Because the OS daemon restricts usage, a malicious program (on a compromised device) can circumvent those restrictions and directly use the physical component. This is the reason why the KeyStore is not supposed to be used to encrypt data that remains local to the device. The physical component only provides the property that the key itself will not be known by an attacker, not that it can't be used by them. More information about the KeyStore can be found here and here.
If device is compromised, the security of whole system is in doubt and all data might being considered exposed. If device is not compromised, the OS itself should guarantee safety of the applications, data and execution environment.
I'd elaborate on another state, the device being analyzed by a 3rd party, in many cases in offline mode -- possibly law enforcement subject or a thief.
According to docs EncryptedSharedPreferences the preferences file gets encrypted hence protect data at rest. This level of security is independent of other security aspects of the device (optional FDE or SD card encryption) and is manageable by the application developer. Using Android KeyStore should allow to use of the Android security features (such as HSM) via standard and stable API.
Answer
... what are the benefits to using EncryptedSharedPreferences and EncryptedFile?
The application developer can assure some security level for the application data via standard API.
Is there a specific scenario where EncryptedSharedPreferences and EncryptedFile can protect internal app data, as compared to their non-encrypted counterparts?
Yes, during evil-maid or offline attack on the device (or storage), EncryptedSharedPreferences/EncryptedFile can provide protection for the application data or at least raise the bar required to acquire such data to non-trivial level.
Based on my knowledge and expereince in this part.
EncryptedSharedPreferences came to secure user data even in rooted devices.
When you create a SharedPreferences object in your implementation, a file is created in a directory called shared_pref, and it would include the filename you passed in your code implementation.
This shared_pref folder is located in data/data/your package name.
This directory is accessible if the device is rooted, so data inside could be exploited.
It's easy to read the preferences file as it's a map file, with key and values like the following:
while, if you used EncryptedSharedPrefences, your key and value are encrypted by default, so even the device is root no data could be exploited.
like the following:
If you need to check your sharedPref files, you can do it from Android Studio
Open Android Studio
Run your application on an Emulator
on Device File Explorer(Bottom Right of the Android Studio)
Find your package name within the data/data directory.
I read this regarding how to extract code from apk.
I am really confused how does other app ensures security. I have a website. In that I have written all queries in PHP. So There is no way to get my queries unless they compromise my server.
In case of android app, I will have to write all the queries, connection details in Java. So when they can able to get code from APK, they can get my credentials. Isn't?
How does other app work? If I understood wrongly, please help me to understand.
So when they can able to get code from APK, they can get my credentials. Isn't?
Yes. If your app contains secrets and you distribute it to your customer, you customer has the secret.
Whilst you can obscure the secret using obfusctation tools like Proguard, his will be of limited effectiveness again all but the most casual attacker.
How does other app work?
Usually, the client-side app makes a connection to a front-end application on your server. The application server does its own identity management, connects to the database, and performs whatever limited range of operations the application allows for each user.
The application server is typically accessed using some kind of web services. You can re-use your PHP code here; the client app is then effectively just a convenient interface to making HTTP calls against your existing web site.
Android has a feature Pro guard. Pro guard convert all String and Const value into Obfuscated code. It also remove unused files. So by using pro guard, You will get two benefit. First You get your code security. Second, Apk size reduce to 25%.
Save your queries in res/string.xml file and use Proguard. Do not write queries in Java, just use the string in string.xml as query.
I've been using Nikolay Elenkov's blog (http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html) to store encrypted password information in our android application. The requirements are such that we a) don't want to store the key/salt in our code directly, because this can be decompiled/removed, b) need to support back to android API level 14, and c) need to store password (encrypted) information on the device (i.e. can't currently use an OpenAuth token or similar system, as it would require server changes that can't be made right now).
So, on JB 4.2+ devices, I can utilize the newer secure credential storage, which doesn't cause any problems. For JB 4.1 and ICS devices, though, I need to use the aforementioned method of interacting with the keystore daemon through nelenkov's techniques.
The problem here is that when the secure credential storage is initialized, it requires that the user set up a device password/pin, as it uses this to base the encryption key used for the master storage off of. This is kind of a bad deal, because it is a big hindrance for the user.
Alternatively, I've looked at using a separate key store, based off of SpongyCastle. The problem with this direction, though, is that I would need to initialize it with some password (likely stored in my source code). This would mean that, if the device were stolen/rooted, it would be relatively easy to procure the contents of the "secure" key store, as the password could be retrieved from the app's decompiled source.
Is there a better solution to this problem that I'm not seeing, or is it just not possible with API versions < 18?
There are really only two ways to do this: either the user enters some kind of password and you derive your keys from it, or you generate a key and store it on the device. Using the device unlock password is a lot more user-friendly than having the user remember a dedicated password for your app only. BTW, on 4.2+ you still need a lockscreen password so nothing is changed compared to 4.0. As usual, if the device is rooted, the attacker can get the user's Google authentication tokens, and bruteforce the lockscreen password so you'd have much bigger problems. So think about your threat model first and decide how far you are willing to go. If the data is truly sensitive, use a dedicated password with sufficient complexity that needs to be entered every time the app is opened. You can also write a device administrator and require that the device is encrypted, that the lockscreen PIN/password is sufficiently long/complex, etc.
The alternative is to use tokens, either your own or from a third party identity provider (Google, FB, etc.).
I'm writing a ringtone gallery app which ringtones reside on a server and they can be downloaded by user.
What I want is to check and verify if the connection is really from my app not other apps or a HTTP request generator. for example I don't like someone write an app that uses my back end and show his ads in the app. It's like image leaching in web site which is prevented by checking the referrer.
It's not possible to insert a key in the app as android apps can be decompiled so easily. I thought of gaining the app signature and send it's hash as a key, but it's like any app can access other apps signature hash.
what about writing part of app which do the communication in native code? is it decompilable as easy as java code?
I really can't think of any other way and I don't like others use my resources for their benefit.
There are a couple of things you can do.
Create your own Certificate Authority, ship a certificate with your app and use two-way TLS authentication. This does not protect against decompilation and reverse-engineering but protects traffic en route.
Use the advice in this slide deck to detect modifications and debuggers.
Use Jelly Bean's hardware-backed secure storage.
At the end of the day, though, DRM is a lost battle. If the user has root access, all bets are off, with or without obfuscation (which native libraries are). The only question is how important is your data. For 90% of applications, running it through ProGuard makes it nearly impossible to untangle (especially if you use data flow obfuscation). Along with the certificate approach, that should suffice for most things.
Alternatively, try to change your model, so that you're authenticating the user and not the app - that's far simpler!
as you know, we can access to any folder on android device after rooting. My app has a database and some other binary files. I know that I can't prevent user see my files and database. But is there any way to prevent user copy it to other android devices for illegal use?
One option is to encrypt the data stored in database. Normally it is stored in plaintext. SQLCipher, I believe works for Android too..
From Android/google official forums,
Users with rooted phones can get access to any files they want.
Otherwise, databases in the conventional on-board flash location are
secure.
If you want to prevent that (routed access) only option is to encrypt it. However long it takes.
EDIT:
What I am saying is, it is never completely secure. You can make it as much difficult for hackers. You can save the decryption key (only) in the server (if downloading entire data from server is time consuming) but then app needs net connection to work. You can save the key in a hidden file (filename starting with .), but rooted users with knowledge about linux type file system can find them. Or you can do as Teovald suggests it in the comment to this answer, by generating the key in run time using any hash algorithm from any constants (like IMEI number), but it also need some processing. The more you try to secure it, the more works you need to do to use it. So it is a 50-50 kind of situation, and decision should depends on one's requirement.
Apart from encryption (see Krishnabhadra's answer) the only way to ensure critical data is to not have everything on the device. So you could access the most critical data always online only.
Of course this has the downside that not all of your app is usable if the user has no connection. You have to balance between your need to keep data safe from prying and allowing instant offline access to data.
If you can alleviate the former problem depends on the data. If all is critical, nothing is allowed on the device. Users will understand and begrudgingly accept this. No one would want a copy of his bank account on his device. But you should allow access to everything that is not critical even in offline mode.