-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PATCH] Don’t require strong auth on regular time interval #32
base: master
Are you sure you want to change the base?
[PATCH] Don’t require strong auth on regular time interval #32
Conversation
This disables the need to provide strong authentication except when booting the device. The idea behind this is that you are no longer forced to enter your strong authentication credentials in random locations where it might be easy to snoop your strong authentication credentials allowing an adversary to boot and decrypt your device against your will. Changing DEFAULT_STRONG_AUTH_TIMEOUT_MS is not enough. Rather, it has the opposite effect for some reason. In my tests, it caused the strong auth to be required every hour rather than a 42 d interval. In my tests, dpm.getRequiredStrongAuthTimeout(null, userId)) returned 3600000.
This one has wider implications and will need more discussion. Merged your other patches. Can you describe a specific scenario where this is a risk? I worry about border-check situations where a timeout that enforces strong auth vs a fingerprint could be useful. |
I have not been in such a border-check situations but I don’t believe that this patch would make much of a difference there. Without this patch, Android defaults to a 3 day interval. I find it very unlikely that boarder control will just wait for such a duration without trying to unlock the phone. When you read the discussion in RattlesnakeOS/community_patches#9, you will find that there are some more thoughts also. Another idea is to use https://f-droid.org/en/packages/xyz.iridiumion.plucklockex/. So currently in practice I think the following scenarios are realistic:
Without this patch, the need to provide strong auth kicks in every 3 days regardless of other factors like location or if you have just unlocked your device successfully a second ago. Some situations where this can be a risk:
I came to the conclusion that for me it makes more sense to keep this strong auth passphrase as secret as possible and rather manually lockdown the device when needed because the 3 day interval is just a hassle for me and I don’t see the benefit of it. The only (declared) benefit is that people don’t forget their strong auth passphrase which I mitigated otherwise. |
Well argued, and I am inclined to agree. Approved to merge into our next release. |
This disables the need to provide strong authentication except when booting the device. The idea behind this is that you are no longer forced to enter your strong authentication credentials in random locations where it might be easy to snoop your strong authentication credentials allowing an adversary to boot and decrypt your device against your will. Changing DEFAULT_STRONG_AUTH_TIMEOUT_MS is not enough. Rather, it has the opposite effect. In my tests, it caused the strong auth to be required every hour rather than a 42 d interval. Ref: frameworks/base/services/devicepolicy/java/com/android/server/devicepolicy/DevicePolicyManagerService.java In my tests, dpm.getRequiredStrongAuthTimeout(null, userId)) returned 3600000. Note that this patch circumvents the values that DeviceAdmin may provide. In other words, it ignores whatever a MDM would request for the strong auth timeout! To be clear, this patch is a practical approach, in an ideal world, we would properly use the DeviceAdmin feature. Confirmed working on: * Android 9 * Android 10 Submitted to: * hashbang/os#32 * RattlesnakeOS/community_patches#9 * https://github.com/ypid/ypid-android-patches
This disables the need to provide strong authentication except when booting the device. The idea behind this is that you are no longer forced to enter your strong authentication credentials in random locations where it might be easy to snoop your strong authentication credentials allowing an adversary to boot and decrypt your device against your will.
Changing DEFAULT_STRONG_AUTH_TIMEOUT_MS is not enough. Rather, it has the opposite effect for some reason. In my tests, it caused the strong auth to be required every hour rather than a 42 d interval.
In my tests, dpm.getRequiredStrongAuthTimeout(null, userId)) returned 3600000.
Also submitted to: RattlesnakeOS/community_patches#9, GrapheneOS/platform_frameworks_base#19