[discuss] UX - Unlock with face id

[Kharchevskyi]

Use face id to "unlock" app
Also we can try to save pass phrase in keychain and use face id to unlock keychain to be possible to enter pass phrase
#442

[tomholub]

Yes! this will be very helpful.

[tomholub]

This issue should be evaluated as you say. With the option to "keep pass phrase in memory", it is too inconvenient to keep re-typing the pass phrase into the app. It would be great if the pass phrase was saved in KeyChain and could be retrieved with FaceID.

[tomholub]

Current design of the app:

• there is a Realm database, which is encrypted as a whole using a key from KeyChain (unlocks transparently as long as user device is unlocked).
• the Realm database contains user OpenPGP keys, which are encrypted using user-selected pass phrase that has to have some minimum entropy. (a pass phrase like joe halloween brings pudding)
• there can be more than one key, and they could possibly each have different pass phrases (but usually they are the same for all keys)
• the pass phrase can be either stored alongside the key in Realm database permanently, or it can be only remembered in volatile memory (RAM) for a maximum of 4 hours
• choice of stored or memory pass phrase is decided during setup, either by user choosing a checkbox, or by client configuration for enterprise deployments
• if I have pass phrase in RAM, I have to keep typing it every 4 hours or every time I kill the app if I want to open encrypted message, which is annoying

For this issue:

• I suggest there could be a third option, where the pass phrase could be auto-generated and stored in KeyChain, protected by FaceID. This option would only be supported on phones that support FaceID.
• In the first version, whenever pass phrase(s) is(are) needed, they'd get retrieved from the KeyChain directly.
• In the future, we can add a 1 hour caching mechanism with the in-memory storage we already use, described above.

(I don't know exactly what possibilities we have when combining FaceID and keychain for our purposes - the above is just one idea)

[tomholub]

From Murat:

To use faceid , one must associate his credentials to faceid, so we should add option to associate any new credential with faceid.

for latest devices , apple lets just the owner of the phone to use faceid ( we don't get a hash, instead it just returns success or fail ) .

This means, if someone borrows my phone to read an email, the phone author will later be able to access to that message using faceid , if not implemented as above . I will today download the project and try to integrate it .

[tomholub]

To use faceid , one must associate his credentials to faceid, so we should add option to associate any new credential with faceid.

What does credential here refer to? What does any new credential mean - can there be more than one credential?

for latest devices , apple lets just the owner of the phone to use faceid ( we don't get a hash, instead it just returns success or fail ) .

So we run a faceid and we get a true/false and that's all? Then the app itself needs to load the pass phrase from KeyChain or something?

Can't it be made more secure to store a secret in the KeyChain that is actually protected by the FaceID, enforced by the OS instead of application code?

This means, if someone borrows my phone to read an email, the phone author will later be able to access to that message using faceid , if not implemented as above

I couldn't follow this - who is the phone author in this example?

[murataka]

I want to explain this as if there was a security level which can be set by the user, say 5 very secure to 1 , secure to the common external attacks (say, some hacker groups trying to hack anything..) .

Faceid is something not very secure , because,

• it allows someone look like the phone owner to unlock it , say twin to be able to unlock.
• When we use the existing api ,

context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) {
               success, authenticationError in

success is a boolean value , and there's no other information ( Id of the phone owner ?) , just passed or failed.

In this situation , assume that , I'm an android user who is using flowcrypt, and unluckily, my phone is broken down ( or not enough battery etc. ). Then , I will ask my coworker to read my email from his phone , he will sign-out , give me his phone , I will enter my pass phrase, read-send my emails , and sign-out. After that , the phone owner to unlock the pass phrase either stored alongside the key in Realm database permanently will be able to accessed by the phone owner. As an android user , I had no idea about that because my app does not have that option on my phone ..

So , faceid has some vulnerabilities itself, to the phone owner , or if not implemented correctly, can be used as a tool to attack someone else ( me the android owner). So I think , this should be marked as security level 1 .

If owner wants to use faceid , then whenever a new pass phrase is added , an option must exist with cautions to not associate if you are not the owner of that device ( phone ) . Also a notification mail allowing to remove the association of the faceid and pass phrase would be sent.

If we are storing Information on serverside ,that is stored and associated to the faceid and also associated to the pass phrase , then faceid would be more secure . In this scenario, the android owner never associated his faceid to any of his passphrases before, so if he enters pass phrases to an iphone, app would ask to associate that whit his ID - passphrase or not to. It would be better to add an option to associate auto (taking the android owner into account), or add a button option , according to the security level selected .

[tomholub]

Ok, that makes sense. I suppose we cannot tie a certain face to certain value? Like, "joe" FaceID can only unlock pass phrase A and "bill" FaceID can only unlock whatever other pass phrase they entered with id B. What you say sounds like, as long as they add their face to it, then that's it.

But I wouldn't worry about this particular scenario too much. For one, such use of coworker devices is a gross violation of many security protocols for the kind of customer we are deploying to. Most likely, their mobile device management system does not allow them to sign in with a second email account on their company-managed phone. So we should not worry about this particular scenario.

The only thing that I'm disappointed is that the faceid returns a boolean value, and that we cannot use any OS guarantee to actually protect a piece of data with the FaceID. We have to do this in application code.

Basically:

if(user passed face id == true) {
  // get pass phrase from keychain
}