3 ms·

Linking biometrics to cryptographic authentication is difficult. When I worked on this problem about 5-6 years ago somewhere else, it came down to adding a sepa

Linking biometrics to cryptographic authentication is difficult. When I worked on this problem about 5-6 years ago somewhere else, it came down to adding a separate applet for the biometric verification to the secure element, which then authenticated itself to the user authN applet, which was then authorized to generate the user authentication cryptogram. Biometrics are probabilistic samples of data, where cryptographic verification requires deterministic inputs. They are apples/oranges and that's what made this hard, so you need a connector for them. The attack on such a scheme means spoofing the biometric authenticator's validation message to the cryptographic authenticator, which, if this all occurs between applets on the same secure element, raises the bar for attacks.

someguyorother 6y ago
There are ways to use error-correcting codes to turn probabilistic samples into deterministic ones and mix them with a key. These are constructed so that you gain no information if you only know the key, or only know the biometric. See https://en.wikipedia.org/wiki/Fuzzy_extractor https://en.wikipedia.org/wiki/Fuzzy_extractor.
- motohagiography 6y ago
  Great papers linked from that. At the time, it seemed the sensor APIs didn't provide a key with sufficient entropy to be considered a cryptographic verification for the tokens we were using. We didn't take it further because the entropy of the biometric sample was going to be diminished by using it to generate a static key, even though the papers linked show you can compose a key with error correcting codes, and intuitively, you could use some kind of probabilistic filter to verify a set of bits in the sample via shamir secret sharing to provide a threshold for a key. It still relies on separate security domains between the biometric sample collection and the cryptographic verifier, and we'd be deep in to the engineering over the differences, but these papers are really useful for getting into the details. One of the early ones was a good intro to it: http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf

someguyorother 6y ago

There are ways to use error-correcting codes to turn probabilistic samples into deterministic ones and mix them with a key. These are constructed so that you gain no information if you only know the key, or only know the biometric. See https://en.wikipedia.org/wiki/Fuzzy_extractor https://en.wikipedia.org/wiki/Fuzzy_extractor.

motohagiography 6y ago
Great papers linked from that. At the time, it seemed the sensor APIs didn't provide a key with sufficient entropy to be considered a cryptographic verification for the tokens we were using. We didn't take it further because the entropy of the biometric sample was going to be diminished by using it to generate a static key, even though the papers linked show you can compose a key with error correcting codes, and intuitively, you could use some kind of probabilistic filter to verify a set of bits in the sample via shamir secret sharing to provide a threshold for a key. It still relies on separate security domains between the biometric sample collection and the cryptographic verifier, and we'd be deep in to the engineering over the differences, but these papers are really useful for getting into the details. One of the early ones was a good intro to it: http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf http://people.csail.mit.edu/madhu/papers/2002/ari-journ.pdf