1

What I'm trying to achieve is a confirmation of transaction (not payment) with a fingerprint sensor. Pretty much like Google does in its Play store:

  1. Chose a product, click pay
  2. Approve your choice with a fingerprint scan

What I feel is that Google uses this only on the client side, without any confirmation on the backend that fingerprint was really asked by the app.

In my case, it's required to provide a proof to the backend that the fingerprint was really asked. To do so I:

  1. Gen key pair
  2. Enroll a public key to the backend
  3. Write a private key to the secure key storage and bind it to the fingerprint

so that next time I need a transaction approval I:

  1. Ask a user to provide a fingerprint, receive a private key
  2. Sign the transaction with the private key
  3. Validate tx with the public key on the backend

But here comes two ideas why it may be not secure:

  1. The client (android/ios) application can be altered to JMP around fingerprint call and don't bind a key to the fingerprint at all.
  2. Fingerprint & key storage can be emulated e.g. in Android VD

In both cases, the backend will have no idea the fingerprint call was walked around as it's just validating the data by signature.

I'm by no means a mobile platform (security) expert and I'm trying to figure out whether those attacks are really valid/likely to occur and is it somehow possible to protect against them?

ovnia
  • 111
  • 3
  • 1
    If you can't trust the client, then you can't know for sure whether the client actually scanned a fingerprint or not. What's your threat model here? – Joseph Sible-Reinstate Monica Mar 10 '18 at 23:47
  • 2
    I'm no expert on Android, but according to [this](https://developer.android.com/training/articles/keystore.html) your (second) step 1 is impossible. The signing happens outside of the application process, and the application can never access the key directly. If a secure element is used, the key never leaves it. You should also look at [key attestation](https://developer.android.com/training/articles/security-key-attestation.html). – AndrolGenhald Mar 11 '18 at 00:32
  • @AndrolGenhald what I meant by "keep somewhere else" is that it won't be bind to fingerprint, but it still can be in the same keystore. sorry for the confusion, I updated the question. – ovnia Mar 11 '18 at 08:29
  • @JosephSible the threat model of the app doesn't matter. the only thing I'm curious about is whether it's possible to rely on a fingerprint scanner as an additional **end-to-end verifiable** security step. Tx processing is just an example. Did I get it right: it's not possible? – ovnia Mar 11 '18 at 08:32
  • @ovnia - the reason for threat model question is that it is impossible to "rely" on anything in all threat models. You need the model to inform what level of assurance you need – Rory Alsop Mar 11 '18 at 09:58

1 Answers1

1

The client can fake the whole process, but not authentication. This means that even if the device is stolen and the lock-screen password is compromised, the attacker cannot retrieve the key from keystore, and cannot perform a purchase in the name of the original (registered) owner. Same if the device is rooted (with or without the end-user's consent).

In the latter case, though, the following scenario is still possible: the end-user does confirm a transaction with fingerprint, but the attacker could have mangled the transaction, e.g. the end-user believes that he approved a $10 purchase, while actually it is $100. Or the end-user wants to have the product sent to her home address, but actually the transaction lists a different address.

As for the first, and most realistic threat: it should not be a big concern to you, and if it is, your model should be revised. If you have a fake user who choses to fake his authentication, he can as easily confirm a transaction with a true fingerprint, or with a fake fingerprint.

Probably one use case attack that may be mitigated on the server side: fake fingerprint transactions may come at much higher frequency, and originate from different devices. So, if you consider this attack, you can rise a flag when the same user account produces very fast purchases, and/or uses many devices simultaneously.

Alex Cohn
  • 823
  • 5
  • 7