In Settings > Location & Security there is a section that allows the user to import certificates. There is also an option, "Use secure credentials" that "Allow[s] applications to access secure certificates and other credentials". I can find no mention of how to get to this in the documentation, and very few mentions of it online aside from people using it to connect to certificate-secured wifi networks. One of the only pertinent things I found was a post claiming that accessing these certificates was actually impossible for regular apps. Is this true? Does anyone know how to access these certificates if it isn't or documentation somewhere that states it is not possible?
Take a look at this Android Issue for some discussion on the topic:
http://code.google.com/p/android/issues/detail?id=11231
The Settings screen for installing root certificates can only be used for VPN and WiFi, unfortunately.
Related
The app has basic authentication (with google account) and a firebase database. After authentication the user is allowed to import user data from paypal into the firebase database trough the Java SDK for PayPal REST API that I've imported into my app. Could the app be forced to import fake data into the firebase db if someone run it in a rooted enviroment with a fake SSL certificate, dns server and paypal server?
From another answer:
Regarding the security risks for running apps on rooted phones. A very simplistic example would be, if an application caches an authenticated session cookie (or password) in an area in the phone that cannot be generally accessed by the user (on non rooted phones), then it can be accessed on rooted phones. (Loosing a rooted phone can lead to password theft or cookie theft quite easily)
A not so simplistic example would be an attacker trying to run an application on a rooted phone and using maybe IP tables on the android phone to redirect traffic to a proxy (for an application that cannot be generally proxyed).
To protect against these kind of threats, applications employ root protection mechanisms that results in applications not running on rooted phones or running in a restricted manner on rooted phones.
There are counter applications that try to hide root capability to bypass root detection defense mechanism. They work at times.
But a really skilled attacker can go upto the level of modifying the source code of the apk and using modified version of the application to suite his purpose.
Hence the best way for an application is to not rely on the client side for protecting sensitive data or on the integrity of the data received ( the source code or the assumption that the application will not work on a rooted phone)
Furthermore; Google itself does not allow using Google Pay on rooted devices, A google developer discussed the reasons here. It might also be interesting to know how Google detects if a device is rooted or not by something called safetyNet.
I am planning to develop an Android app that communicates with a server that I operate. Answers to android, httpurlconnection error state that classes such as HttpURLConnection and HttpsURLConnection require granting the "full network access" permission (android.permission.INTERNET) to the app. Someone on a forum told me that for the vast majority of apps, android.permission.INTERNET is unacceptably intrusive on the user's privacy, and that there exist other ways for an app to communicate with a server operated by its developer that do not require such an intrusive permission. From this post:
And the same app will ask for full network access, even though if you look at the traffic, almost all of them are using HTTP to talk to their services, and they have no legit need for full network access. However, it lets them look at what all your network connections are.
[...]
Also, no, you don't need "full network access" to access anything outside a web browser. You only need it to go off port 80 HTTP. You can still just use a subdomain for the remote app API. You're conflating two different permissions.
When I asked for further clarification on how to get this going in Android, so that I could go look it up on developer.android.com, the reply was "your ignorance doesn't demonstrate anything."
So how should an app communicate with a server operated by its developer without android.permission.INTERNET? Or is there a reliable source stating that this is impossible in Android?
that there exist other ways for an app to communicate with a server operated by its developer that do not require such an intrusive permission
Not really.
As far as I can tell from the rant that you linked to, the ranter is complaining that there is no IP- or host-level whitelisting possible in Android's permission system. INTERNET grants access to the whole Internet. This is a valid complaint about the OS, but there is nothing that an app developer can really do about it. Users can, to the extent that they are willing to install firewall-type apps (either pseudo-VPNs or true firewalls, the latter requiring root). ROM modders can. Google could. Device manufacturers could. App developers cannot.
I mean, in theory, the app could speak to the server using Bluetooth (with limited range) or NFC (with really limited range), but those are generally deemed impractical.
With regards to the ranter's claim that "you don't need "full network access" to access anything outside a web browser. You only need it to go off port 80 HTTP", that is fairly ridiculous. For example, resolving a domain name requires you "go off port 80 HTTP", and that definitely fails sans INTERNET permission.
I don't have a sample app that I can try that would work with a plain IP address, so I cannot absolutely validate right now that accessing a plain IP address on port 80 could work without INTERNET. If that proves true, that's a security flaw in Android that would need to be fixed, and I'll be very surprised if this is the case.
Or is there a reliable source stating that this is impossible in Android?
I'll state that there is no practical way for an Android app to talk to a server, outside of perhaps localhost, that does not involve the INTERNET permission.
Whether a source is reliable is a statement of opinion. I'll put my track record up against any random Slashdot poster, though.
Have a look at the apps on your Android device. The overwhelming majority of them will use the INTERNET permission. What makes them useful is their ability to talk to various web services of varying types.
Users are accustomed to agreeing to this permission when installing apps and won't be put off your app if it asks for it.
I'm trying to install a Charles Certificate on an Android emulator and I noticed that there are two Credential use options: "VPN and apps" and "Wi-Fi".
I've tried looking around for explanations regarding to the two options, but the one I've found simply say "pick one that fits your use case."
What is the difference between the two options? Which one should a developer pick?
The WiFi option is for authentication WiFi networks, while VPN and apps is for authenticating certificates for SSL/TLS communication for apps including the browser.
I can also confirm that VPN and apps is the right choice for proxying HTTPS requests for an Android device in Charles.
You can use digital certificates to identify your device for a variety of purposes, including VPN or Wi-Fi network access as well as authentication to servers by apps such as Email or Chrome. If you plan to use certificates for Wi-Fi authentication, be sure to select the Wi-Fi option from the menu described below.
Source: https://support.google.com/nexus/answer/2844832?hl=en
I am trying to create an android application for mobile device management.
I want to deny the internet access of a particular 'xyz' network to smart phone users unless they have my certain android application installed on their smart phones. Only those users, who have the application installed on their device should be able to access my 'xyz' network. What should I look into to achieve this? I am not sure what to google to find an answer. :)
If this is about security, it sounds like this would only secure the network from Android users and leave a gaping security hole for any other device. Or are you looking for an alternative to protecting WiFi with the standard clickwrap agreement before you can use the internet? Maybe it would help if you clarify your use of the term 'network'. The only other use I can think of is malware, so please clarify.
I suggest using standard internet security protocols for logging in - a password on a site secured with SSL, which the browser can remember. If it's specialty content, access it directly through the app where enhanced security can be handled automatically.
Here's the situation:
I'm working on an application which allows automated management of network connections. Users are able to configure WiFi/VPN profiles through the application and the application will manage their connectivity to these profiles.
This was all fairly straight forward (well, the VPN side required some reflection hackery) except when I got to the point of managing these connections to networks which required certificate authentication. The trouble is that these networks by and large use self-signed certificates, and as far from what I've been running up against in android it seems to me that these certificates need to be accessible from the root cert store. I tried to create a private app keystore and install the certificates there, but as far as I can tell the WiFi and VPN segments of android can't get access to this.
Is there a way to install a chosen certificate in the application keystore, create profiles based upon this keystore, then send the completed profile to the android wifi/vpn manager to allow the preconfigured connection?
This seems like it should be possible, but I just haven't yet managed to be clever enough to get it to work.
Update:
When I try to create the wifi and vpn configurations I've attempted to reference installed certificates in the local application keystore. It's unable to find them once the configs are pushed to the OS, it seems. To my understanding once a certificate is installed it becomes part of a general keystore, either at the app or the os level.
I have to keep access to the certificates internal, so I can't push them to the SD card. Even if I were to push them to the SD card I wouldn't be able to require the user to manually install the certificate, I need this to be handled in the background to simplify the configuration. I've been digging through the source and haven't found any obvious solution to this, but I was just hoping someone had stumbled across this before and I was just missing it.
Thanks in advance for the help!
Update 2
For those of you still interested in how to do this, here are the packages/classes which you will need to take a look at.
com.android.certinstaller.*
android.security.Credentials
With a little bit of digging you can find the appropriate ways to construct intents to install the certs you need.
Also, as a side note, If the credential storage password has not been set on the device the initial intent you fire to install a certificate will instead only prompt the user to provide a credential storage password. The certificate will not be installed. There may be a way to work around this but I have yet to find it.
That's more than one question, consider splitting it. What exactly have you tried? VPN and WiFi don't use regular Java KeyStore's, the access keys and certificates via the keystore daemon. The actual keys and certificates are stored as files in /data/misc/keystore. AFAIK the API for this is not public, but you could probably launch the certificate installer intent, which scans the SD card for certificates and PFX files, and installs them (this is may not be public either). Settings->Location and security->'Install from SD card' does the same thing.
In short, I don't think you can do what you are trying to do using just the SDK APIs, you'll have to look at the source, and take the risk of your app breaking in the next Android version.
Update: the installer intents are now public in ICS, you can access them via the KeyChain class.