Freeze - Too many operations - Advanced Unlock

[unoukujou]

When using advanced unlock I'm getting the message "Too many operations" after a certain number of times unlocking with advanced unlock. So, advanced unlock is working fine for maybe 4 to 7 times, then "Too many operations" appears and I cannot use advanced unlock anymore until I reboot the OS.

I tried the device unlock both with Pin code and Password. Same thing either way.

KeePassDX Version 3.3.1 from F-Droid. Samsung phone running Android 11.

I tried flipping on and off every imaginable setting in KeePassDX to no avail.

I searched and found #1200 that is almost the same thing. Except that guy had mistakenly thought that it was because of using 2 databases. However, I only use 1 database so I don't believe it has anything to do with multiple databases (at least in my case as I only use one and still have this problem).

I cannot get through a singe day without rebooting the phone to "reset" this problem, only to have it happen again and need another reboot. I can consistently reproduce the problem on purpose by just opening the database with advanced unlock, then lock the database. Do it about 6 or 7 times in a row unlock & lock, and you get the error. However... this isn't happening because I'm locking and unlocking too fast just to cause a problem (that shouldn't be a problem to do anyway). But this is happening with regular normal everyday use. Example: Use advanced unlock... then lock database... come back an hour or 2 later and unlock again. Few hours later again... And eventually before the day ends you will have this error message and need to reboot the phone. So that happens during regular normal use. And can be reproduced quickly for testing purposes as I've described. Like I said, so far I have not gotten through a single day without this problem. I tried pretty much all the different settings in KeePassDX.

I do have other apps that use the same device unlock screen to protect parts of the app with the unlock code. These apps function without any problems no matter how many times I lock & unlock them. It's only happening with KeePassDX for me.

I'll be happy to try any suggestions you have.

Thanks.

[J-Jamet]

The problem is with the biometric API of the device linked to the keystore. You say it works with other apps, but do they also use the keystore to store a key with the fingerprint? I don't think so, the only thing for me to do is to send it back to Samsung because with my devices I can't reproduce your problem.

[J-Jamet]

This is a security feature of your system because it is not normal to do quick biometric unlocks several times in a row. I think it just comes back after a while. Afterwards, nothing prevents you from getting explanations from the Samsung developers.

[unoukujou]

The problem is with the biometric API of the device linked to the keystore. You say it works with other apps, but do they also use the keystore to store a key with the fingerprint?

Just in case it matters, I'm not using the Biometric unlocking option of KeePassDX, I'm using the Device credential unlocking that goes with the PIN/Password (not fingerprint). So in case that makes any difference I want to clear that up. I don't really know how the other apps work. I just know that they use the same device credential unlock screen where I enter my code and it works fine.

This is a security feature of your system because it is not normal to do quick biometric unlocks several times in a row. I think it just comes back after a while. Afterwards, nothing prevents you from getting explanations from the Samsung developers.

Could be some kind of a security feature, but like I said it happens with normal daily use. I can reproduce it fast if just unlocking and locking quickly. But besides that, just normal use throughout the day will end up with this error after unlocking the 6th/7th time. WHat I'm saying is that I can unlock once every hour and it still happens. Whether fast or slow, it does not matter. Through my normal daily use, I am unable to make it through any single day without this error. This is all I know.

I tried other password managers. None are good for me as KeePassDX. Even with this problem... I guess I just cant use advanced unlock and will just settle on typing my full pass each time. Maybe one day it will get fixed either by Samsung or by KeePassDX itself. I don't know what else I can do, because you cant reproduce it then I don't know.

[unoukujou]

I think it just comes back after a while.

I forgot to respond about this in the last message. Seems to be permanent for me and never comes back until I reboot the phone. Example, I got the error yesterday and did not reboot yet. Today, still the same error "Too many operations". As far as I can tell, it never goes away by itself until I reboot the phone. But then after, it comes back after 5-6 times of unlocking anyway.

[J-Jamet]

In older versions of Android, Device credential unlocking is not related to the Biometric API but in newer versions it is. As you have a recent device, I deduced that it is a behavior of the Biometric API. (https://developer.android.com/reference/androidx/biometric/BiometricManager.Authenticators#DEVICE_CREDENTIAL) But it can make a difference, so you're right to point that out.

My first thought would be that this is a problem with the device because even if it is a safety feature, it should behave normally after a while (maybe 10 minutes) and not just after a restart.

Maybe there is a parameter in the API that needs to be changed to fix this issue, but I don't know which one, so I need to do some more research.

[unoukujou]

If you do manage to find anything that would be great.

The message "Too many operations" is generated from somewhere. I suppose the Biometric API? Because this phrase "Too many operations" isn't anywhere in the KeePassDX source code so must be a relayed message from somewhere else. Maybe looking to where this message is coming from can reveal what triggers it, or how to avoid it.

If you want to look at this other app:

https://github.com/helloworld1/FreeOTPPlus

From the settings menu, choose "require authentication". Then settings menu "Quit and Lock".

I can open this app, unlock with my device credentials, then "settings->quit and lock". I can do this unlimited times over and over again as fast as I want, never any issue. Maybe you can check how they do it, if it can reveal any useful information. It's not anything I understand. Or I would look myself. So I'm just pointing out, if this might be a good way to figure something out.

[unoukujou]

UPDATE

My phone received an upgrade to Android 12 a few days ago.

I don't get the message "Too many operations" anymore. But now instead of the message, KeePassDX will just freeze, become unresponsive, and needs to be force closed.

Once this freeze happens, I cannot use Advanced Unlock anymore or it gets instantly frozen again. The only way to unfreeze KeePassDX is to disable Advanced Unlock. If I disable Advanced Unlock, I can continue to use KeePassDX without freezing. But I can never re-enable Advanced Unlock until I reboot the phone or it will just keep freezing up. After rebooting the phone, Advanced Unlock works again but only for a limited amount of times until it freezes again and needs to be disabled or reboot.

So Android 11 and now Android 12, pretty much a similar thing. Except with Android 11 you get the message "Too many operations". And with Android 12 there's no message, just freezes.

Up until now, this problem only happens to me with KeePassDX. I did not encounter any other app with this issue as of yet with my testing. I will update here if I do find another app with a similar issue or if I have any further information to provide.

[J-Jamet]

Thanks for the detailed feedback, it helps me understand the problem a little better. The thing is that I can't reproduce it, as you say, the error displayed is not a KeePassDX error but a biometric API error. If there is a freeze with Android 12, it is even more problematic. I'll see if there are no successive calls, but from memory I had paid attention to this detail, I think it comes from a bug in the API that does not manage correctly the recovery of secure key from the Keystore. I'll check it and I'll put a version here for testing so you can tell me if there are any changes.

Linked to #1273

[J-Jamet]

I just checked the FreeOTPPlus code and the Biometric authentication system is basic, it doesn't use the Keystore as I thought so there is no key stored on the encrypted memory of the device. (This must be where the problem lies). I'm trying to modify the initialization call of the API by modifying the builder, maybe it will improve some elements on your device.

[J-Jamet]

~Another potential issue is that the problem may come from a deprecated createConfirmDeviceCredentialIntent() method, perhaps on newer devices the method is simply not even implemented anymore...~

No it's not, this method corresponds to the old method replaced by the biometric API so it is not executed on the new devices.

[unoukujou]

I just checked the FreeOTPPlus code and the Biometric authentication system is basic, it doesn't use the Keystore as I thought so there is no key stored on the encrypted memory of the device. (This must be where the problem lies).

I'll see if I can find some other app which uses the Keystore. Or if you know of any such app that you want me to try let me know. I think it'll be good just to see what happens on my phone with another app that performs the same functions as KeePassDX.

I'll check it and I'll put a version here for testing so you can tell me if there are any changes.

OK yes, I will.

If you want to know the exact moment of the freeze, it happens exactly after I select the database and I get to the password screen and everything is frozen in that exact moment on the password screen. It never pops up the pin code screen to enter my phone pin code for the advanced unlock. Normally when everything is working properly, I'll select the database, I get to the password screen, and the pin code screen pops up to enter my pin. This is from using the option "Auto-Open Prompt" in the Advanced Unlock settings.

I tried both with and without the "Auto-Open Prompt" option. It does not make any difference. I will still select the database, get to the password screen, and instant freeze at the password screen.

After a few minutes of being frozen, the OS pops up a message saying KeePassDX is unresponsive and gives me 2 options: Terminate or Wait. If I choose Wait then it just stays frozen until I terminate. The only way to get back to KeePassDX is to terminate, then re-open and be sure not to select the database or it will freeze again on the password screen. Instead I need to go to the settings and disable everything on the advanced unlock settings. Then I can select my database and open normally with the password.

After you get the freeze, there is nothing you can do to solve it. If I enable advanced unlock again, then it's just back to instant freeze on the password screen. Even if I go to the KeePassDX app settings, clear cache, clear data, uninstall KeePassDX and re-install KeePassDX, I still get instant freeze at the password screen if I enable advanced unlock.

The only way to fix the freeze is reboot the phone. Then KeePassDX can use Advanced unlock just fine and everything works. But only for a few times until the freeze problem happens again and then I have to disable Advanced unlock. I tried all the different settings and options like "Temp Advanced Unlock", really tried all the options there. Nothing made any difference.

So anyway, here is what I know about Android 11 and Android 12.

Android 11: Choose database -> Password screen says "Too many operations". No freeze. I can still go back and into settings to disable advanced unlock and continue with my normal password

Android 12: Choose database -> Password screen is frozen (no message about "Too many operations"). Cannot do anything without terminating KeeePassDX and reload it and go into settings to disable advanced unlock. Then proceed with normal password.

In both cases, the only way to get back advanced unlock is to reboot the phone. But again, its only temporary until the problem comes up again.

Android 11, I was able to reproduce it easily just by enabling Advanced unlock and then lock and unlock several times in a row and I can reproduce it within a minute after about 6-7 times unlocking.

Android 12, seems a little better. Because I can lock and unlock it many times in a row without any issue so far. So on Android 12 it just happens randomly and does not reproduce so easily. However, so far with Android 12 I still am able to reproduce it every single day, it just happens at random so I have to continue using KeePassDX normally and eventually the freeze comes. Once the freeze comes, it never goes away until reboot. I never got through a single day yet without having the freeze problem. But it just happens at a random moment, not like Android 11 where I was able to reproduce it easily. I would say so far on average I am able to use advanced unlock normally for like 8 hours until the freeze happens. I don't know if it's exactly 8 hours, it just feels like that. Because I can reboot my phone in the morning, everything is good with advanced unlock. Then by the afternoon or evening, the freeze problem happens. This is with just regular normal use of KeePassDX. Opening it maybe 4 or 5 times throughout the day.

[J-Jamet]

I tried both with and without the "Auto-Open Prompt" option. It does not make any difference. I will still select the database, get to the password screen, and instant freeze at the password screen.

This is interesting, it means that the problem does not come from the opening of the biometric prompt but right from the initialization of the API.

After a few minutes of being frozen, the OS pops up a message saying KeePassDX is unresponsive and gives me 2 options: Terminate or Wait. If I choose Wait then it just stays frozen until I terminate. The only way to get back to KeePassDX is to terminate, then re-open and be sure not to select the database or it will freeze again on the password screen. Instead I need to go to the settings and disable everything on the advanced unlock settings. Then I can select my database and open normally with the password.

It means that the code is blocked and it can't go to the next instruction but I don't see anything in my code that can block an execution indefinitely, that's what I don't understand.

The problem is not even the same on Android 11 and Android 12, which means that the system has changed its behavior between the two versions. I think Samsung is changing the AOSP code for biometric API and as few applications use the biometric unlocking feature with the device credential by storing data in the Keystore, they didn't see the bug on their devices. This is a guess, and since Samsung's code is not open source, we can't verify. And I don't know of any other apps that use this feature, otherwise I'd have to create a mini app just to test it but that would take a lot of time and I honestly don't really have the courage to do it.

I have tested all configurations on emulator with Android 11 and Android 12 with AOSP code and I have no problem.

I will still improve the initialization and provide a test APK, we never know.

[unoukujou]

This is interesting, it means that the problem does not come from the opening of the biometric prompt but right from the initialization of the API.

Yes. That was an important detail so you can know exactly when it happens. Definitely, it's before the biometric prompt. During the initialization as soon as the keepassdx password screen is displayed. If I do see the biometric prompt, that means everything is good and I'll be able to open the database with advanced unlock. No biometric prompt, means the problem occurred before it ever gets to the prompt.

And I don't know of any other apps that use this feature, otherwise I'd have to create a mini app just to test it but that would take a lot of time and I honestly don't really have the courage to do it.

No worries. In the worst case I'll just use KeePassDX without advanced unlock. Sure it's convenient. But maybe after all it could give me greater security to just use my full password.

I did find andOTP just now. It says one of the features is:

Encrypted storage with two backends: Android KeyStore Password / PIN

Maybe it's similar. In any case, I installed it now and testing lock&unlock for the next several hours/days to see if I get any kind of strange issue.

[J-Jamet]

I checked the code and I don't see how I can improve it without live debugging. I think it comes from the initialization of the KeyStore, as we said before but without being able to see the error I'm afraid to bring bugs. So I have to find an emulator instance that allows to reproduce the error otherwise I won't be able to identify the issue in the code and a workaround.

[J-Jamet]

KeePassDX-3.3.3_Test_build202203191553.zip Can you test this build? I aggregated the load from the keystore, maybe it will change the behavior on your device.

[unoukujou]

KeePassDX-3.3.3_Test_build202203191553.zip Can you test this build? I aggregated the load from the keystore, maybe it will change the behavior on your device.

Thanks! I'll check it out and let you know how this goes. Hoping it's good. I was also using andOTP since yesterday, I did unlock&lock over 50 times since yesterday and still no issue with that app (in case they are similar to KeePassDX it's good to know that something can work which also uses KeyStore). I will continue testing with andOTP and your new KeePassDX test build now, I'll report back to you about that. Thanks.

[unoukujou]

Hi, this new version "KeePassDX-3.3.3_Test_build" just gave me an instant freeze at the password screen. This time I couldn't even do advanced unlock even one time. I just got to the password screen and it froze and had to terminate, I didn't even have a chance to set up the advanced unlock so there was no key even stored yet at the keystore.

With the previous version, I could still use advanced unlock a number of times until the freeze happened.

I did clear cache/data and do a complete uninstall of the old version before I installed this new test build just to be sure.

[unoukujou]

I disabled Advanced Unlock, and now I can open the database and get passed the password screen.

As soon as I turn on Advanced Unlock, password screen is frozen and needs to terminate. There is never even a chance to set up the advanced unlock. So definitely this new test build is a little bit worse than the old one. Because at least the old version I can use the advanced unlock a few times. This one is just doing an instant freeze with 0 times of using advanced unlock. Meaning, I never even get a chance to store anything in the keystore. But maybe, that's a helpful thing to know? Because it means the problem is somewhere before the keystore ever gets used. I didn't even press the advanced unlock button on the password screen. It's just instantly frozen as soon as the password screen shows up.

[J-Jamet]

OK, it's weird, but it gives more information. I just looked at the andOTP code, it does use the Keystore but not yet in the same way, it uses it to create a certificate to store an asymmetric key pair for RSA encryption and it only uses the deprecated method to display the credential (createConfirmDeviceCredentialIntent()) of the device and not the new method (setAllowedAuthenticators()). I also noticed that it didn't aggregate the initialization of the Keystore, it made instances just before using them (so the opposite of what I was trying to do to have only one initialization).

My assumptions :

• Samsung has broken the new method that allows to recover the keys of the Keystore from the credentials of the device through the biometric prompt.
• Or we have to initialize the keystore by retrieving a new instance just before using it
• Or parameters of the KeyGenParameterSpec.Builder are not taken into account or must be added on some devices

I will create several packages with different code, you tell me which ones work and which ones don't.

[unoukujou]

Yes, whatever you need, I'll test it.

I just now tried another test with KeePassDX-3.3.3_Test_build202203191553.

This time I cleared cache -> clear data -> uninstall KeePassDX-3.3.3_Test_build202203191553 -> reboot phone -> re-install KeePassDX-3.3.3_Test_build202203191553

I set up advanced unlock, this time it let me do it. I was able to lock&unlock about 5 times and then got the freeze problem again now.

I just wanted to be sure because the first time I did the test with KeePassDX-3.3.3_Test_build202203191553 I re-installed it cleanly, but I did not reboot. Now I did reboot, but it made no difference. Still same problem unfortunately.

So without reboot in my first test, it was just an instant freeze without even a chance to set up advanced unlock. Now with the reboot, it worked setting up the advanced unlock, but only a few times lock&unlock and then the freeze.

[J-Jamet]

A - Always uses oldest auth method : https://drop.infini.fr/r/zgfruJds7b#RdQxNZ0RBkU6sPjGA354gBCN+jRogat2rzY4oeH4KYI= B - Non aggregate Keystore init : https://drop.infini.fr/r/TrgPFhXBcF#PvF+4nTgMJipDo+mzd7Ak71H98+m+MWbs5Q9k4BAc7M=

Here are two more test cases, I'm not sure if it will make a difference but I don't have any other solutions at the moment.

Thanks for the last feedback, it allows me to eliminate a cause of modification that would have aggravated the case. Now I know that KeePassDX-3.3.3_Test_build202203191553 didn't change anything to the bug behavior.

[unoukujou]

OK great, I'll try them both now and report back. Lets hope something good.

[unoukujou]

Unfortunately both "A" and "B" still have the issue as I am able to reproduce the freeze either way. I tried them both after clearing cache/data and uninstall the previous version, then reboot phone and do a fresh install of a new version. No matter what version, the problem persists among them all. After "A" and "B", I even tried the regular Google Play version just in case it could be any different. I was using F-Droid before. But in any case, they're all the same.

Thanks for trying at least. If you get any other ideas I'll try whatever. But I also don't mind using KeePassDX without advanced unlock. It works fine that way at least. Strange thing with this Samsung. I was thinking of switching to LineageOS. Maybe I'll finally do it.

I'm surprised not many other people reported this issue because Samsung is one of the most popular brands. I would think this issue would have been very common. But maybe most people just didn't care to report it. They probably just get the problem and switch to some other password manager or they just don't use advanced unlock and never got the error. I would be interested if anybody out there has a Samsung (Android 11 or 12) and is able to use advanced unlock without issues? That's something good to know.

[J-Jamet]

https://github.com/Kunzisoft/KeePassDX/issues/1200 and https://github.com/Kunzisoft/KeePassDX/issues/1273 were reported. For the error message, I just thought it was normal, as I had no information about it not coming back without rebooting the device. And for the other issue, there was too little information for me to infer anything.

[unoukujou]

1200 and #1273 were reported. For the error message, I just thought it was normal, as I had no information about it not coming back without rebooting the device. And for the other issue, there was too little information for me to infer anything.

At least to know I'm not the only one. Although I still hope other Samsung users can say if they are able to use advanced unlock with or without issues. But even if this can't be solved for us Samsung users, KeePassDX is still the best for me. Especially because of magikeyboard and a good clean interface.

[J-Jamet]

On the contrary, it's even more annoying that you're not the only one, it means that it's a generalized problem and we have to solve it quickly. Maybe the problem comes from the type of key used not fully supported by your device, as you tell me it works with andOTP, I'll try to inject asymmetric keys algorithm, I'll refactor a package when I'm done, but it can take time because I have to refactor some code.

[unoukujou]

Yes, andOTP has no issue on my phone. Already testing it for 2 days, lock&unlock well over 50 times and still no issue. So that app would certainly be a good place to look. If I'm able to find any other apps that use the KeyStore, I'll test those too and let you know.

[J-Jamet]

It seems that the implementation of the Keystore on Samsung is very badly done on many levels:

• https://stackoverflow.com/questions/39859579/how-come-i-cannot-perform-multiple-keystore-cipher-decryptions-on-samsung-s6-and
• https://stackoverflow.com/questions/36043912/error-after-fingerprint-touched-on-samsung-phones-android-security-keystoreexce
• https://www.schneier.com/blog/archives/2022/03/samsung-encryption-flaw.html & https://threatpost.com/samsung-shattered-encryption-on-100m-phones/178606/ (This scares me)

So finding workarounds for a feature like this is pretty touchy. Honestly, not being able to reproduce the problem, I don't feel like going blind when it's clearly a problem in the OS. I need an AES symmetric key and if I have to go through certificates and RSA asymmetric keys to workaround this issue, it changes the workflow and requires key invalidations, etc... I really don't know what to do except ask Samsung to implement a proper Keystore.

[J-Jamet]

What I think (I could be wrong but I wouldn't be surprised): the reported exceptions of too frequent key usage is a poor attempt to correct a bad implementation of the KeyStore, that's why there is even a crash after a system update. Honestly, I just want to filter samsung devices by indicating that their Keystore is not secure.

[unoukujou]

Thanks for checking into this. In that case, even if this issue is resolved I would probably hesitate to use the advanced unlock. Maybe then, it's all for the best because the convenience is not necessarily better security. So instead of trusting the KeyStore, I'll just trust my password. I felt this way even from the beginning. And if Samsung is closed source then it's even more reason to hesitate.

[J-Jamet]

By default the biometric recognition will now be disabled and I have added a warning to the user about the use of the Keystore and that there may be incompatibility.

[PurpleCodingWizard]

I'm on a samsung smartphone with android 11 and I do not experience this biometric issue others mention. Even if I unlock/lock multiple times in succession. Device is A22 5g

[J-Jamet]

@PurpleCodingWizard Thank you, it's good to know. Maybe a specific device problem but not general.

[iwismer]

I've got an s10e on android 12 and have this issue as well. I can use fingerprint unlock for a bit, and then as some point it just freezes on the unlock screen and I can't use the app until I kill it, but every time I try to unlock the database it freezes again until I reboot. Then after the reboot it works fine for a bit, then happens again. I have not been able to figure out a cause.

I've never had this issue when using keepass2android, so maybe their biometric code might hold some clues?

I'm going to try and get some logs when it happens next and I have time to see if they include any clues.

[Ilithy]

I tested on my Pixel 6 pro under grapheneos (android 12), I never have this error, even when trying to perform successive fast closing/opening.

Application version: 3.3.3 Database version: V2 - KDBX V4 Database size: 11Mb Unlocking method: biometric Attachment: yes

[ghost]

I have a Galaxy S10+ and hadn't seen this freezing problem until recently (perhaps since Android 12, but couldn't say for sure). The symptoms for me are as described above:

• Using biometric unlock
• Works for a while
• Then will freeze at some point (does not have to be after quick sequential unlocks)
• And from that point, no keyboard, no biometric prompt, and only a phone reboot brings it back.

(This is not to complain, but to confirm the steps others describe as they happen for me.)

My database password is a bit diabolical and routinely typing it on a mobile keyboard would be a challenge.

[ghost]

Although after reading those links, maybe a dumber password would be light years safer than letting the Samsung phone store keys.