[Q] PIN/password prompt on use of certificate stored in Android KeyChain? - Security Discussion

Android (I'm specifically on Android L 5.0.2, CM12S, but I think this would apply mostly from ICS onwards) offers a KeyChain in which a user may store a Certificate.
When an app wants to use a certificate from the KeyChain, it calls an API to pop up a list of the stored certs and asks the user to choose one.
Maybe I'm just being blind (I hope so!) but I don't see any way to require a PIN/password prompt, specific to each stored certificate, before the user/app may make use of any cert in the KeyChain. In effect, it seems that "access to the phone" = "ability to sign with any cert stored in the phone's KeyChain".
On Windows (desktop), for example, each individual certificate may be locked with a certificate-specific password, to prevent someone with access to the user's session from being able to sign with a stored certificate; the attacker would also need the certificate-specific password/PIN of that certificate before the Windows CryptoAPI could access the cert's private key.
How do I set up Android KitKat and Lollipop's KeyChain to have a certificate-specific password or PIN which must be entered on each use of a particular certificate?
thank you,

Related

[APP]Boardies Password Manager

I have uploaded my first app on to the Android Market and haven't too much interest so far on XDA so I thought I would post a little bit more information about the app.
This is a simple and light weight app that allows you to securely store and easily login to different websites on your phone.
Do you have all your passwords saved into your devices web browser meaning that anyone who has access to your phone can log on to the websites that you’ve accessed. Do you regularly wipe your phone for whatever reason and get annoyed at having to keep typing in your username and password. Then this might be the app for you.
The app will store all the login information that you enter into the app, which include the company name, the web address, username and the password. Each login is listed on the front screen. If you click on the stored login it will load the website and copy the username to the clipboard allowing you to paste into the username field. Also, when you launch the website from the app it will also create a notification. Once you have copied the username you can then click on the notification to copy the password. This way you do not need to switch to and from the app and the browser to copy the login information. Once you have launched the website, the copying of the username and the password is done while the app is running in the background.
All passwords that are stored within the device are encrypted using AES encryption algorithm to ensure your data is safe.
To protect others from accessing the app you can enable a password that needs to be entered before getting access to the app. Also, for added protection you can enable a feature that will automatically reset the app back to first use if the password gets entered incorrectly 3 times.
The app enables you to backup and restore your stored logins to a file on the SD card of your device. Should you need to wipe your phone, or if you get a new device and want to restore the logins onto your new device you can use the file that was generated from the backup in order to restore your data.
Although the App has Internet Access this is only there to enable you to submit bug reports from inside the settings menu and to enabled adverts to support the app development. I promise you, know personal information that you store inside the app is sent over the internet.
The App can be found on the Android Market. There are two versions, one which is a free ad supported version and a donate version which is identical to the free version but doesn't show ads. Please search for Boardies Password Manager.
Thanks
A new update has been released today in order to enable support for Android 2.1 and up. Tests have also been made to ensure that the app works correctly on honeycomb

[Q] Is there a way around Exchange email -no root- rule

My employer just opened up Android native email capability (to receive work email, calendar, apps) for my Note i717. Problem is, they won't allow Rooted devices.
I know there's several (6 I think) security certificates that get installed, but I was wondering if there's a way around this no-root rule.
1. If I unroot, get all certificates installed and then re-root will it nullify the certs?
2. Does anyone know enough about certs to answer if they're something that can be backed up and restored if I move to a different ROM in the future?
I've scoured the forum and have found info on bypassing the credential logins, but not pertaining to these questions above. Answers would be greatly appreciated.
It isn't really a rule...depending on your environment
b3furuya said:
My employer just opened up Android native email capability (to receive work email, calendar, apps) for my Note i717. Problem is, they won't allow Rooted devices.
I know there's several (6 I think) security certificates that get installed, but I was wondering if there's a way around this no-root rule.
1. If I unroot, get all certificates installed and then re-root will it nullify the certs?
2. Does anyone know enough about certs to answer if they're something that can be backed up and restored if I move to a different ROM in the future?
I've scoured the forum and have found info on bypassing the credential logins, but not pertaining to these questions above. Answers would be greatly appreciated.
Click to expand...
Click to collapse
Unless your company is using a type of MDM platform (Codeproof, Good, MobileIron, AppSense), they will not be able to detect that you have root access to your phone. Some companies instruct users to install a separate MDM application in order to access their email. Most Exchange servers can be connected to without installing the MDM software. If they don't force an MDM client, they won't know you are rooted.
Depending on the version of Exchange, you can use a 3rd party email app like K-9 to access the email which would also bypass the additional security policies that will be installed if you were using the built-in Exchange support. I use Touchdown, therefore the app is protected by a PIN but not my phone, so I can still unlock the phone without having to type a 6 digit number every, single, time.
The way I see it, the company's data is still protected, and I am not overly inconvenienced, it is a win-win.
Unless your company is using a type of MDM platform (Codeproof, Good, MobileIron, AppSense), they will not be able to detect that you have root access to your phone. Some companies instruct users to install a separate MDM application in order to access their email. Most Exchange servers can be connected to without installing the MDM software. If they don't force an MDM client, they won't know you are rooted.
Depending on the version of Exchange, you can use a 3rd party email app like K-9 to access the email which would also bypass the additional security policies that will be installed if you were using the built-in Exchange support. I use Touchdown, therefore the app is protected by a PIN but not my phone, so I can still unlock the phone without having to type a 6 digit number every, single, time.
The way I see it, the company's data is still protected, and I am not overly inconvenienced, it is a win-win.
Click to expand...
Click to collapse
Apologies, I did forget to mention they instruct to install Mobile-Iron.
Their process is such:
1. Install Mobile-Iron
2. Encrypt Device & set 6 digit pin
3. Install Certificates
4. Email configuration
5. Sync email, calendar, clients to phone
They do note "If your device is rooted, this process will not complete successfully."
Reviewing the steps, it looks like the whole process is done within Mobile-Iron.
No dice so far
Still can't find anything on the net for this. If anyone can help answer this I'd greatly appreciate it.
I'd love to be able to check on emails without having to open and boot my laptop. Also, it would be great to have my calendar sync so I don't miss meetings.

SplashID v7 upgrade security issue

Besides the issues SplashData has with their SplashID v7 android upgrade losing many customers data, there is also a very worrying security issue which splashdata ignores = and actively censors, my messages regarding this on their FB page have been deleted and I am blocked from commenting our writing there)
Here is the issue:
The new SplashID version 7 had a cloud sync feature (30 day free trial, then for a fee). When first starting the upgraded version (which may have been installed automatically on Android if one allows auto upgrades!), one first has to again enter one's email address/username, and then the password (which is the one used to encrypt one's database containing all one's private, sensitive data!). Then the upgrade asks whether one wants to try the cloud sync feature.
Even if one declines and opts to stay with the existing Wi-Fi sync feature only(which does not need a cloud account), the upgrade goes ahead and automatically creates such a cloud account on splashdata's servers.*and it uses the same password* for this. (In fact as further part of the upgrade procedure one needs to log into those cloud servers using that password after receiving an activation link in email.
So, splashdata leaks the master password which one uses to secure one's most private data (credit card pins, login password etc) into their cloud, without telling that this will be fine, not asking permission.
There is no info whether the password is stored securely (doubt it), whether it is in ask cases transmitted securely (doubt that too) and anyhow, once this has happened one had lost control over that most important password. It's burnt.in the wild, out of one's own control
Note that changing the password on one's own copy of SplashID us a good idea after that, but any old copy of one's encrypted database that might still live on any old disk backup, cloud service (dropbox etc) or SD card somewhere, us now vulnerable.
And because splashdata in their 'wisdom' associated one's email address (and thus identity) with that password, it's easier for hackers to fund it.better companies than splashdata have lost password in the past.
It is even a very bad idea to user the same password for s cloud service as one uses for securing one's private data. Forcing this into users without permission or warning is almost criminal.
Sent from my GT-N7000 using Tapatalk 2
sejtam said:
Besides the issues SplashData has with their SplashID v7 android upgrade losing many customers data, there is also a very worrying security issue which splashdata ignores = and actively censors, my messages regarding this on their FB page have been deleted and I am blocked from commenting our writing there)
Here is the issue:
The new SplashID version 7 had a cloud sync feature (30 day free trial, then for a fee). When first starting the upgraded version (which may have been installed automatically on Android if one allows auto upgrades!), one first has to again enter one's email address/username, and then the password (which is the one used to encrypt one's database containing all one's private, sensitive data!). Then the upgrade asks whether one wants to try the cloud sync feature.
Even if one declines and opts to stay with the existing Wi-Fi sync feature only(which does not need a cloud account), the upgrade goes ahead and automatically creates such a cloud account on splashdata's servers.*and it uses the same password* for this. (In fact as further part of the upgrade procedure one needs to log into those cloud servers using that password after receiving an activation link in email.
So, splashdata leaks the master password which one uses to secure one's most private data (credit card pins, login password etc) into their cloud, without telling that this will be fine, not asking permission.
There is no info whether the password is stored securely (doubt it), whether it is in ask cases transmitted securely (doubt that too) and anyhow, once this has happened one had lost control over that most important password. It's burnt.in the wild, out of one's own control
Note that changing the password on one's own copy of SplashID us a good idea after that, but any old copy of one's encrypted database that might still live on any old disk backup, cloud service (dropbox etc) or SD card somewhere, us now vulnerable.
And because splashdata in their 'wisdom' associated one's email address (and thus identity) with that password, it's easier for hackers to fund it.better companies than splashdata have lost password in the past.
It is even a very bad idea to user the same password for s cloud service as one uses for securing one's private data. Forcing this into users without permission or warning is almost criminal.
Sent from my GT-N7000 using Tapatalk 2
Click to expand...
Click to collapse
Ouch, that sounds a bad idea. If the user doesn't want a remote account made, they should respect that. Can you give me any more details about this, I would like to contact them and request some proper response to this. While they might not be leaking the plaintext password, anything that can be "opened" with your password is a significant enough leak, as it would allow an attacker to verify they have the right password.
pulser_g2 said:
Ouch, that sounds a bad idea. If the user doesn't want a remote account made, they should respect that. Can you give me any more details about this, I would like to contact them and request some proper response to this. While they might not be leaking the plaintext password, anything that can be "opened" with your password is a significant enough leak, as it would allow an attacker to verify they have the right password.
Click to expand...
Click to collapse
Not much more that I already said. I am a long-time user of their SplashID (Mac) Desktop and Android app to store all my credit card, bank acount and yes, many systems passwords in.
The database they use is encrypted with a 'master password' which one has to enter on ones' Android (or iPhone, etc) or Desktop everytime to
unlock and decrypt (in memory), so that one access the data.
The same password is used on both the mobile and desktop of course.
A few days ago, an upgrade to SplashID v7 was made available on the Google Play store. I don't allow 'automatic' updates (though I am sure a lot of folks do!), but this time I also did not really check what the upgrade offered, and clicked 'UPDGRADE ALL' when it was offered along with a nunber of other upgrades. So it got installed.
When i subsequently opened SplashID again, it told me about all the shiny new features (cloud sync etc) and as normal asked me for my password (it also asked for my email address. I though that this was for them to check my purchase/license ans what features woudl be enabled)..
I thought that it would then show me my data. But wrong. Instead it offered me a selection whether I want to use the new 'cloud sync' feature (30 day free trial, later for $$), or stay with the normal 'wifi sync'.
I opeted for the latter (because I don't trust having my data sent to the cloud).
Anyway, the next thing I get is a message: (paraphrasing) "we have created your cloud account, you will get an email and will have to verify your email). Sure enough, I get an email:
Thank you for signing up for SplashID Safe Personal Edition!
To activate your account, please verify your email address by clicking the link below: Verify Email
Then check your email for our SplashID Safe Welcome message.{/QUOTE]
The link goes to: https://www.splashid.com/personal/webclient/login.php
I had to again ther enter my email address, and *the same password* that I entered before (which I thought would be for my private data-store).
Yes, that same password was used to create my account on their cloud server, even though I opted for the Wifi Sync *only* and never
asked for a cloud-sync.
Nor did the app tell me that the same password would be used to secure that aco****.
The issues with this are self-evident:
a) my most secure password, the one used to secure my data on my mobile and on my desktop is now 'leaked' to their cloud account
b) I have *no* idea how secuerly that password was transferred (in clear, encrypted, just a hash), nor how securely it is stored
c) it clearly is linked to my cloud-account on their website, so
- someone somehow learning that password could 'verify' it by accessing that account
- if someone hacked their system and accessed their database, that link would be apparent to them
d) I have nost *all control* over securing that password myself. It is 'burnt', 'in the wild'
e) Any pass backups of my secure SplashID database that may live on SD cards of mine, on backup disks, which may have
been copied to the cloud (dropbox, others) are now vulnerable. It is no use for me to change this password here now, as
old copies that may still exist somewhere are still encrypted with this password (and I cannot change them back).
Yes, I am trying to limit exposure for that password data file as much as possible, but eg Titatium Backup may have at some point in teh past backed it up and copied a backup to the cloud (yes, that is also encrypted, but once that featire failed).
More that that, of course users who are not as security conscious may have opeted for 'could sync'.
While I have not tried this feature myself, it sounds to me like thsi does copy the teh data to SplashID's cloud and
there secures it too only with that one single password.
So many users wh may not have thought all this out may have opted for the 'CloudSync' trial, and not only have their
password 'leaked'/'burnt' now, but also have all their data in the cloud, again secured only with a password that is no longer in their sole possession.
In fact, any secure, trustworthy system would have
a) been *very* upfront about what they are going to do with the password and the cloud account
b) used a separate password to secure the cloud account
c) only stored my encrypted copy of the database in their cloud, without *them* having the password for it
d) done any syncing on the client (ie, transfer the complerte encrypted password to the mobile or desktop where the comparisonupdates would happen) and then copied back again a secured file, that was encrypted on the mobile).
Click to expand...
Click to collapse
More discussion on SplashID's own site: http://forum.splashdata.com/showthr...ically-send-in-background-to-splash-id-server

[APP][6.0+] - OpenSource - QRSA OTP Authentication

I made this app.
A small, OTP authentication app. The OTP authentication app makes use of the new feature in Marshmallow to allow a app to check if a specific keypair is generated inside Secure Hardware, to make it impossible to copy or extract the private key materail. This makes the app a extremely secure authentication app.
Note that if your device for some reason fails to create the key inside Secure Hardware, the app will refuse to use the key. On some phones, the secure storage may need to be initalized by setting a secure lockscreen, then enroll using the app, and then clear the secure lockscreen.
Enroll code to enroll and put public key into clipboard:
[QRCODE]qrsa://e[/QRCODE]
Your website simply encrypt a one-time password, using the enrolled public key for a specific user, encode this encrypted RSA2048 message as URLSafe Base64, then creates a qrsa:// URL with this information embedded. The end user (having this app installed) simply scans the QR code or clicks a link on web site and gets the OTP on screen or in clipboard, depending on if website was accessed on mobile browser via the link or via QR code.
Note that the app CANNOT be launched manually and thus have no "Open" button inside play store, it will automatically trigger by visiting any url with the scheme qrsa://
GitHub page: https://github.com/sebastiannielsen/QRSA
(Does contain example code for the webservice aswell)
Google Play page:
https://play.google.com/store/apps/details?id=eu.sebbe.www.qrsa
What do you think? Any toughts?
Anything I can do better?

Programming at operating system level and / or modifications of the android kernel

Developers with experience in programming at operating system level and / or modifications of the android kernel please respond.
Mock Location Application
Android 5.1 and later, we use as a B phone a ZTE Axon Mini B2016, Use a NodeJS server, with MongoDB database, the server function is to receive and send the shared locations by telephone A and that synchronizes telephone B, the database is to register users and ID's; the locations of any terminal are not saved. the application uses a developer option called Simulated Locations, additionally an Xposed module called "Hide Mode Location" is used with which it is sought to avoid being detected as a "FakeGPS"
Functioning:
The application must be configured a server and a port, once it is done it is registered and logged in (when entering a username and password, it is stored and starts immediately). Each computer in which it is installed generates its own unique ID in the database.
Then you must add the ID of the telephone A on the telephone B and vice versa, this in order to assure who is sharing the location and with whom I am synchronizing the location.
Once this process is completed, the "Share location" option is used in the telephone A and this is connected to the server and the latitude and longitude along with the ID are sent. In the telephone B, the "Synchronize location" option is used there, it shows the IDs that are paired and that are transmitting their location, the ID with whom you want to synchronize is selected and the process of taking the location of telephone A in phone B, which means that both A and B have the same location
Problem:
We use the messaging applications to take the services, since we have a fleet of vehicles to make them effective,however what we want is to distribute the services in the best way, so we locate in different strategic points within the city to be able to comply with these services as soon as possible,now the problem we have now is that although we use the Xposed module to hide the fact that it is a "GPS fake" there are applications that detect us and do not let us work , so we are looking for someone to change this method of "Simulated Locations" by a method in which the location is "Natively" synchronized for the system and thus be able to open the applications that at this moment detects the simulated location.

Categories

Resources