Please provide the following:

* Which version of the SDK are you using? Any

* Which Android build are you using? (e.g. LPV79) Any version that supports 802.1X (WPA-Enterprise or WPA2-Enterprise)

* What is the desired behavior of the feature? (Be specific!) Currently, when you install any 3rd party certificates you are forced to enable a lock screen. This requirement ranges from annoying to absurd.

On the absurd side of things, it is insane that something like the public portion of a root CA certificate has to be stored in an encrypted credential store. By its very nature the public portion of a certificate can be viewed or copied by anyone without compromising the security of the connection. By storing the certificate in an encrypted certificate store, and forcing a lock screen on users that don't want it, this issue results in lowered security for everyone. Inevitably, someone will figure out if they modify their configuration profile to remove the certificate that they no longer have to have the lock screen. However, few people will understand that this opens them up for handing over their user name and password in either clear text, or a trivially reversible hash string.

On the annoying side of things, forcing the lock screen when something like a private key is involved with an EAP-TLS type authentication is frustrating for users that would rather not have a lock screen. I am well aware of the issues with how data gets stored in the key store, and why the decision was made to lock the keystore with a lock screen PIN or password. However, I think it is reasonable to consider the user experience as well. Forcing a lock screen on a user that doesn't want it is one of the worst possible user experiences that you can have. At the same time, using data stored on the device to encrypt the key store runs the risk of making that data available on a stolen device that is later rooted. Perhaps a middle ground could be implemented. If the user has a lock screen enabled, the use the PIN or password to encrypt the key store. If not, then use something like the device serial number or some key hidden on the file system as the method for locking the key store. Then, provide a public API call for apps that use the key store to know which method is in use, and to force a more secure method if it is needed.

Consider the case of an 802.1X authentication using EAP-TLS. If a device is stolen and data can be read from the keystore, the thief may be able to log in to a wireless network with the identity of the user that the device was stolen from. However, any reasonable deployment of EAP-TLS has the ability to easily revoke the user certificate. So, once the user realizes their device has been stolen, they should be able to easily revoke the cert, and nullify the threat.

The opposing case would be using the keystore to store something like a bank account number that is more difficult to change. In this case, there is a good chance that significant damage would be done to a user, possibly before they even know their device is stolen.

If apps are allowed to read the method used to encrypt the keystore, then they could choose to enforce the lock screen to encrypt the keystore data, making the security of that account number stronger.

I believe the other use case is with apps in general using the keystore. The APIs are all there for apps to make use of the keystore for storing data that needs to be secured. However, I would bet there are VERY few, if any, that use it because they don't want the negative ratings from forcing a lock screen on a user that doesn't want one.

Changing the keystore to work like I am suggesting would improve the overall user experience with secure wireless networks, along with providing apps an easy to use method for storing data that needs to be secured better than just writing it to the file system. Using information from the device as the password to the keystore isn't ideal security, but it is probably good enough for what most users would want to do. And for the organizations that are more security minded, there are already calls to force the user to use a lock screen.

I think this would be a win-win across the board.

* If relevant, why are current approaches or workarounds insufficient? Workarounds that I have found for this issue have been systematically removed, probably because they were viewed as security holes. So a supported method of getting the job done would be very valuable.

* If relevant, what new use cases will this feature will enable? The relevant portion is the use cases that this would prevent. And that is someone that configures their device for a secure wireless network and then removes things like certificate validation so that they can disable the lock screen.

Thank you for this suggestion. We will pass this along to the development team and provide updates as they are available.