Support Device Credentials

bishtawi commented 5 years ago

Coming from AndOTP, one feature that I really liked was that the app's authentication supported the device's credentials. This meant that I didnt have to memorize a separate password to access my one time codes. I simply enter the password I had set on the Android device itself.

Any chance to support this?

alexbakker commented 5 years ago

When you select the "Device Credentials" option in andOTP, your token secrets will be encrypted with an Android KeyStore key exclusively. No other key or password is able to decrypt your tokens. The Android Keystore is forgetful, so this strategy can result in nasty surprises for users. This is why Aegis will always require a password in addition to any Android KeyStore backed authentication methods (like fingerprint).

That said, I see 2 ways to support device credentials in Aegis:

Plain text: Simply prompt the user for device credentials on app startup.
Encrypted: Add a new slot type for an Android KeyStore key that requires unlocking the Keyguard to use it. This means that the vault can stay encrypted and that it can be unlocked by providing your device credentials. The important difference between this and our fingerprint authentication option, is that access to the key is not governed by the TEE, but by the operating system. This means that root can always use the key, regardless of whether you've entered your device credentials. Also keep in mind that setting a password would still be required here.

Which of the two options is the closest to what you have in mind?

In general, I prefer giving users two simple options: no security or great security. Offering alternative 'security' options (like prompting for a PIN) in between those two extremes is only going to confuse non-technical users, by making them think they're getting real security. There are a number of apps that have taken the whole flexible security thing too far and I think we should be cautious to not fall into the same trap.

Long story short, I'm not a big fan of either of the two options, but I'm curious to hear what others think about this.

bishtawi commented 5 years ago

Option 2 is probably the closest to what I would want. Option 1 is pretty much useless and is basically pretend security as the database is plaintext. I definitely agree that giving users a false sense of security is not a good idea at all.

chiraag-nataraj commented 5 years ago

I think the second one would be iffy as an option. I think the strength of Aegis is that it puts security first, and the issue with Option 2 is that root (aka the system) would always be able to unlock the database if it wished to do so. Contrast this with the current situation, where root would not be able to unlock the database even if it wanted to.

If I understand @alexbakker correctly, this is a design flaw ("feature") of the way the keystore works. If there is no way we can work around that (and I don't think there is), I'd prefer not adding this feature.

claudioweiler commented 4 years ago

@alexbakker

Just to understand:

Option 2 is use the hardware backed keystore to protect password used to encrypt database?

If yes, then, about forgetfull keystore:

If I change my device security settings, than I just need to re-enter my password?

About security:

I don't understand the issue here. Are you concerned about android itself or about rooted devices?

alexbakker commented 4 years ago

I'm mostly concerned about adding additional ways of securing the vault that are inferior to what we have right now.

claudioweiler commented 4 years ago

Why encryption with keys that can't be accessed are inferior?

alexbakker commented 4 years ago

As explained in my comment, the difference is in who is governing access to usage of the key. With Keyguard, it's always the operating system, making it less secure than what we currently have.

claudioweiler commented 4 years ago

Sorry been so pedantic, but I can't see why it should be less secure.

I search a lot about any security issues about hardware backed keystore, but find none except for rooted devices. This is even used for bank apps. Can you share any related issues that you find for background?

alexbakker commented 4 years ago

I search a lot about any security issues about hardware backed keystore, but find none except for rooted devices

It's not specifically rooted devices, any way of acquiring root (through an exploit, for example) would allow access to usage of Android Keystore keys. We currently require biometric authentication for usage of Android Keystore keys. So on devices that properly implement biometric authentication, even root can't use the key without the user authenticating first. Now, which of the two offers more security, in your opinion?

Note that I'm not trying to argue that relying on Keyguard for governing access to the Android Keystore is horribly weak or a bad idea. It's just that we have better authentication now, and it would be a bad idea to add Keyguard as another option and make users choose between them.

michaelschattgen commented 4 years ago

Closing this issue as we unfortunately don't have plans to implement this.

corobin commented 2 years ago

The Android Keystore is forgetful

Would you mind elaborating on this forgetfulness? the article linked has many comments that the APIs it discusses are now deprecated. Specifically, I am curious about current behaviour.

Also from the article:

namely switching between None, Swipe, Pattern, Pin and Password

Is there a problem if i change within each type? for example: a pattern is currently set, and i change it to a different pattern. or a pin is currently set, and i change it to a different pin.

It looks like MS Authenticator uses the device credentials and changing the locking "code" (pattern, pin, etc.) does not cause any problems although I haven't changed the type of locking method.

Maybe this is something to also ask over at andOTP since they actually implement it.

alexbakker commented 2 years ago

Would you mind elaborating on this forgetfulness? the article linked has many comments that the APIs it discusses are now deprecated. Specifically, I am curious about current behaviour.

It varies wildly across devices and manufacturers. It has stabilized a lot over the last couple of years, but we still occasionally get reports from users alleging that their Keystore was wiped spontaneously.

Aegis also makes use of a feature that intentionally wipes keys with that option enabled from the Keystore if changes to security settings of the device are made. This is an important security feature, but that means you need a different primary way (a password, in Aegis' case) to decrypt the vault.

Is there a problem if i change within each type? for example: a pattern is currently set, and i change it to a different pattern. or a pin is currently set, and i change it to a different pin.

I don't think that triggers a Keystore wipe, but I can't find any documentation that makes this explicit, so I'd recommend testing this to double check.

It looks like MS Authenticator uses the device credentials and changing the locking "code" (pattern, pin, etc.) does not cause any problems although I haven't changed the type of locking method.

That means they don't use setUserAuthenticationRequired(true) like Aegis does. In fact, Microsoft Authenticator just stores everything in plain text, so their device credential prompt is mostly theater.

corobin commented 1 year ago

revisiting this - since andOTP is now unmaintained - is there any possibility of getting device credentials support in aegis just with a big fat warning about the chance of data-loss?

I have been using andOTP with device credentials without a problem, changing the device passcode without changing the type (i.e. changing one PIN to another PIN, not changing PIN to pattern) does not erase the andotp keystore. of course, you'd be more familiar than me if andOTP is actually encrypting using device credentials.

I do not consider the authenticator app to be the sole store for my 2fa codes - i have backup codes for recovery and will not lose access even if aegis loses everything.

the on-device TOTP codes are meant to be hard to recover, you're not supposed to be able to take them off the device easily. if TOTP codes are easily taken off-device it defeats the whole point of proving physical possession of that device. using android's device credentials ties the TOTP database closer to that phone.

ideally you would remove any backup functionality altogether but that ship probably sailed.

Lanchon commented 2 weeks ago

@alexbakker,

2. Encrypted: Add a new slot type for an Android KeyStore key that requires unlocking the Keyguard to use it. This means that the vault can stay encrypted and that it can be unlocked by providing your device credentials. The important difference between this and our fingerprint authentication option, is that access to the key is not governed by the TEE, but by the operating system. This means that root can always use the key, regardless of whether you've entered your device credentials. Also keep in mind that setting a password would still be required here.

sorry, either i don't understand you or i find this very hard to believe.

i don't know the android keystore code base, but common sense dictates that it is probably well designed.

this means that if you store a secret in the keystore protected by the device creds, and contrary to what you say here, neither root nor any userland component nor the android kernel can access it without you providing the device creds (pin/pattern). if android is well designed, the application processor simply does not cache the creds, and the hardware keystore will not release the secret without them. so the only thing the app processor can do is to ask the user for the creds whenever it needs them and hope the user releases them.

This means that root can always use the key

specifically this would be false. that's the whole reason for the hardware backing store thing to exist anyway, IMHO.

threat models

of course if you corrupt android's userland or kernel, you can make it memorize the creds the next time the user types them in, if ever. but under this threat model, nothing tells me that the same trick couldn't be done with the fingerprint sensor: just use the next unlock scan to unlock the vault instead of the phone.

I'm mostly concerned about adding additional ways of securing the vault that are inferior to what we have right now.

security solutions can't be meaningfully compared without threat models. i am curious as to which threat models you had in mind when you wrote this.

but here is a counter example: within the following threat model, if you compare the security of storing the key to the vault in the keystore protected by biometrics vs by the device creds, the device creds solution is demonstrably superior. (this again assumes a reasonable implementation of android, as said above.)

threat model: gov agents detain you and confiscate your phone. they can forcefully use your biometrics but they will not forcefully extort secrets out of you. your phone is locked but is not locked down (very reasonable). and either your phone is protected by fingerprint, or they have some application processor exploit that can bypass the lockscreen (if the phone is not locked down). then:

if the vault is protected by fingerprint: the vault is compromised.
if the vault is protected by device creds: the vault is safe, as the backing store will not release the key without the user revealing the creds.

note that if the phone is returned to you, you recognize that the phone has been breached in either case and you cease to trust it as a trusted agent of yours. consequently, you will not provide your creds to the phone ever again and will discard it instead. you know that backups of the vault are safe elsewhere, and encrypted with your strong passphrase.

so clearly, in the scenario above (which is very reasonable) the vault protected by device creds is the superior solution, not the inferior one as you stated earlier.

caveat

of course this all falls down if you have proof that android caches the device creds in the app processor. again, i find this very hard to believe, but would love to be proven wrong if i am. as someone said: it's not what you don't know that hurts you the most, but what you think you know and are wrong about.

beemdevelopment / Aegis

Support Device Credentials #212

threat models

caveat