We have a AOSP device that does not have a keyboard or touch (wearable). We can attach a keyboard via Bluetooth but that is only for development purposes.
Furthermore, we use Enterprise Wifi (WPA2-Enterprise using TLS and MSCHAPv2) at our shop that uses a corporate certificate + private certificate.
Everything works but there is a very annoying problem. After every reboot, somebody has to type in the password for the credential store and then again confirm the "PIN".
Is there any programmatic way to "open" the credential store & "PIN" at startup? Without doing so, it is not possible to connect to the WiFi.
We are willing to create a custom launcher or ROM if needed.
Android Version: 4.0.4
Related
Edit: -
Look is it just me or doesn't the W3C spec say this should be happening already: -
1.2.2. Authentication
On a laptop or desktop:
User pairs their phone with the laptop or desktop via Bluetooth.
User navigates to example.com in a browser and initiates signing in.
User gets a message from the browser, "Please complete this action on your phone."
Next, on their phone:
User sees a discrete prompt or notification, "Sign in to example.com."
User selects this prompt / notification.
User is shown a list of their example.com identities, e.g., "Sign in as Mohamed / Sign in as 张三".
User picks an identity, is prompted for an authorization gesture (PIN, biometric, etc.) and provides this.
Now, back on the laptop:
Web page shows that the selected user is signed in, and navigates to the signed-in page.
===============
My WebAuthn code happily interacts with Windows Hello for user verification via PIN. My Samsung Android phone happily interacts with the https://webauthn.appspot.com demo and accepts fingerprint verification.
But I can't seem to use my phone as an Security key like a YubiKey connected on my computer?
I can pair it with the PC via Bluetooth or tether it with a USB cable, but Windows will not recognize it as a security key.
Is this possible, or is the functionality restricted?
If we could use our phone as security keys, we'd need no special dongles for platform agnostic authentication.
In order for that to work, the phone device manufacturer would have to either always present itself as a FIDO2 authenticator, or have some sort of switch that allows it to change mode, kind of like how you can configure USB connection to be for charging or for data transfer. I don't see any technical reason why that could not be done, in fact it's come up multiple times in various discussions, but to my knowledge that is not an Android feature, at least not yet.
For that either smartphone OS or a 3rd party application needs to implement CTAP protocol to receive and process authentication operations on the phone. Currently, Android does - but not in a way to be used as a cross-platform authenticator to not stick to only one PC.
For 3rd party apps, there are some certified solutions that are listed on the FIDO Alliance website as certified authenticators.
I recently find that the PIXEL phone can do this.
When you open a FIDO2 Web via Chrome or Edge, it will prompt a dialog shows add Android Phone. Click it and a QR code(FIDO:/AAACCC...) appeared. Scan the QR Code by your Pixel Camera (registered FIDO2 Token).
Magic...
A push notify show on the Pixel. Click it and wait and scan FP. Finally your WebAuthn web Verify OK via BT.
The only question for me is what kinds of Andoid phones can support this scnerio.
Can any other phone except Pixel support scan the QRCode(FIDO:/....).
I am having the most difficult time figuring out how to get a cell phone that will trust my local domain certificates without being very difficult or expensive.
Android devices tested up to 8.0 give a warning like: "Certificate authority installed by an unknown third party" or "Network May Be Monitored" on boot.
Is it possible to remove this message without rooting the phone? I need to set up always on VPN and SIP calling for the local pbx along with internal web sites. Android is the only offering with a native SIP client. But the warning causes too much trouble =/
The following worked for me in Android 8.
First transfer copy of the cert file to phone.
If using mkcert, the file location is found via CLI: mkcert -CAROOT
Then install the cert file in Android settings, the location of which varies per device and Android version.
In my phone it was in: Android Settings / General / Lock screen & security / Encryption & credentials / Install from storage
You might have to restart the phone. Also might have to click TRUST on the cert in Android settings.
Then enable Firefox secret settings by tapping multiple times on the Firefox logo in the About page, then in secret settings enable "Use third party CA certificates".
Voila!
In google home app, the app can connect with GoogleHome without asking password for connecting.
Even though, the app doesn't have root permission to do that. How google home can connect with device?
Short answer: you cannot access the Wi-Fi password without root access. (with root it's just stored as plain text on disk)
What Google does (I'm guessing) is to get your Wi-Fi password from your Android Phone's backup. After all, after resetting your Android phone you just have to log in to your account and you magically have your Wi-Fi passwords back.
Note: They could also be using a private API, but as that would be a security risk, my best guess is the solution above.
Note2: This is very much in line with what Apple does in their WAC set up protocol. They've provided a proprietary flow to set up "Made for iOS" devices so you don't have to ask a user for her password.
I don't have an actual answer, but had too much background data for a comment.
From this Super User answer:
Chromecast acts as an access point when first turned on.
For the initial setup, you install an app on your Android, Windows or mac device, that will find it and connect to the chromecast's AP directly. Then the chromecast scans for nearby access points, allowing you to pick one and enter in its password.
Once this is done, it will connect to that access point instead of acting as its own access point.
So the overall flow is:
You install the app
The app sees the Chromecast's access point
The app connects to the Chromecast access point (named ChromecastXXX, with random alphanumeric chars)
The Chromecast scans for nearby access points
You select your WiFi network
You either enter your password, or the mysterious wifi share happens.
Chromecast uses your WiFi network
This is api to securely transfer wifi creds from one device to another.
https://developer.android.com/preview/features#wifi-suggest
I found it in Q's arsenal of secret 007 spy tools.
AFAIK (remember) I had to enter the wifi password on the google home app and wear os when I set up.
Basically your phone and home device are connected to the same Wifi. And your phone already is successfully connected to the Wifi. So the Wifi password is kind of auto fetched while Google Home device is connecting.
Below are some hints from the Google Home setup page -
Make sure to connect your mobile device/tablet to the same Wi-Fi
network that you intend to use to set up your Google Home device.
Choose the Wi-Fi network you want to connect to your Google Home. To
automatically fetch the password for this network on this device, tap
OK. The password will populate in the password field. Note: Android L
and above is required to auto fetch the password. Tap Continue. You
can also manually enter your password. Tap Continue.
https://support.google.com/googlehome/answer/7029485?co=GENIE.Platform%3DAndroid&hl=en
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
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.