java - Android Keystore getEntry() and generateKeyPair() throw Exceptions sometimes -

my android app need encrypt file can decrypt , read later. should not decrypt-able else other app, user.

following how doing encryption , decryption. works of time, times users failing. not specific particular handset (nexus7, samsung, motorola, htc -- types reporting issue), not users experiencing it. users occasionally.

here relevant code:

encrypt() {    keystore ks = keystore.getinstance("androidkeystore");    final keystore.privatekeyentry entry;    if (!ks.containsalias(cert_alias)) {        calendar cal = calendar.getinstance();        date = cal.gettime();        cal.add(calendar.year, 50);        date end = cal.gettime();        keypairgenerator kpg = keypairgenerator.getinstance("rsa", "androidkeystore");        kpg.initialize(new keypairgeneratorspec.builder(getapplicationcontext())               .setalias(cert_alias)               .setstartdate(now)               .setenddate(end)               .setserialnumber(biginteger.valueof(1))               .setsubject(new x500principal("cn=" + cert_alias))               .build());        keypair kp = kpg.generatekeypair();    }    entry = (keystore.privatekeyentry) ks.getentry(                      cert_alias, null);    pub = entry.getcertificate().getpublickey();    // use pub key encrypt } decrypt() {     keystore ks = keystore.getinstance("androidkeystore");     ks.load(null);      final keystore.privatekeyentry entry = (keystore.privatekeyentry) ks.getentry(             cert_alias, null);     privatekey key1 = entry.getprivatekey();     // use private key decrypt } 

this code throws

java.lang.runtimeexception: error:0d07207b:asn1 encoding routines:asn1_get_object:header long @ com.android.org.conscrypt.nativecrypto.engine_load_private_key(native method) @ com.android.org.conscrypt.opensslengine.getprivatekeybyid(opensslengine.java:66) @ android.security.androidkeystore.enginegetkey(androidkeystore.java:86) @ java.security.keystorespi.enginegetentry(keystorespi.java:372) @ java.security.keystore.getentry(keystore.java:644) 

so modified encrypt() first try entry , if raises exception, generate new key pair.

final keystore.privatekeyentry entry = null; if (ks.containsalias(cert_alias)) {     try {         entry = (keystore.privatekeyentry) ks.getentry(                       cert_alias, null);     } catch (exception e) {     } } if (entry == null) {     //generate new key pair } 

but failing following exception.

java.lang.illegalstateexception: not generate key in keystore @ android.security.androidkeypairgenerator.generatekeypair(androidkeypairgenerator.java:100) @ java.security.keypairgenerator$keypairgeneratorimpl.generatekeypair(keypairgenerator.java:275) 

1. what doing wrong?
2. how fix it/work around it?
3. does these exceptions indicate files being tampered with?
4. does happen users screenlock password/pin?
5. before generate new pair, should delete entry? (keystore.deleteentry())

i observed keystore returns null after screenlock password/pin change. others seem have experienced issue (keystore getentry return null after change password)

i ran could not generate key in keystore issue 1 of apps , after digging deep 1 of affected phones discovered devices have set phone's unlock pattern/pass/pin different password unlocks key storage. if want double check that issue can use work here: http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html @ actual private system api public keypairgenerator objects calling , check return code on it. i'm not sure why google decided hide return code behind boolean there have it.

you can trigger unlock of keystore manually calling startactivity(new intent("com.android.credentials.unlock")); might not much. i've seen if phone in state because device administrator app locked keystore in background can set vpn or email credentials. means user doesn't know password. i'm still looking workaround (possibly find out how device administrator apps access keystore can unlock way) it's hairy issue least. i'll try update if find out more in explorations, @ least points people in right direction.