Let's take a look at the Android Developer docs "Android keystore system". We'll need to break this down depending on how you use the
KeyStore object. If you're using the Android KeyStore
1) If the device the app is running on has hardware-backed secure storage, then
Key material may be bound to the secure hardware (e.g., Trusted Execution Environment (TEE), Secure Element (SE)) of the Android device. When this feature is enabled for a key, its key material is never exposed outside of secure hardware.
The "Android keystore system" article gives more info on how to use this feature.
2) If the device does not have hardware-backed secure storage, then:
Key material never enters the application process. When an application performs cryptographic operations using an Android Keystore key, behind the scenes plaintext, ciphertext, and messages to be signed or verified are fed to a system process which carries out the cryptographic operations.
Presumably this system process is written in C where they have more control over memory management and can zeroize the key properly when it goes out of scope in your application (which leads me to my rant about garbage collectors...)
3) If for some reason you use
KeyStore.getInstance("JKS") as in the examples here - maybe you need access to the private keys for some reason, or you need to load / store the private keys in a
.jks file - then No, you can not wipe it: because the Java garbage collector is famous for returning memory to the OS without clearing or zeroizing it. From the Android developer docs, I don't see any evidence that the Dalvik garbage collector works any differently.
Moreover, one of the mechanisms of the Java garbage collector is to make a copy of any heap variable that's currently referenced by your program and then free the old heap. This means that a copy of your private key may be freed back to the operating system even before it goes out of scope.
Bottom line: If the Android KeyStore object is used properly, your private keys will remain securely inside the Trusted Execution Environment (TEE), Secure Element (SE)) or System process.
If for some reason you do bring the private key into your app, then all bets are off because in Java / Dalvik / Android, once something is in your app's memory, it is nearly impossible to clear or zeroize it.