I am unsure how one saves biometric fingerprint data, so I will just put forward what I came up with.
Ideally, even if an attacker was able to read out the storage of the location (in the secure enclave?), like a raw dump, the attacker should have to invest huge efforts into actually extracting usable fingerprint data.
In a sense, a fingerprint is like a password taken to the extreme. You never ever want to save the password in clear text, and one surely never never never want to save a fingerprint as is.
So assuming, that the raw data captured by the sensor can be computed into unique features without any prior state information needed, one could do the following (and avoid saving this state at all):
Using these calculated unique features, one could generate a unique position in memory, generate this starting position by something like PBKDF2 rounds over the unique features of the fingerprint.
Assuming there are 20 unique features generated without any prior state information, the process to verify a fingerprint would go as follows:
- Generate/calculate the 20 unique features without any prior state
- Generate with known PBKDF2 parameters and a known salt a unique hash and thereby position in storage for at least one unique feature (this storage is clustered and has 1 section for each feature) to look for another set of PBKDF2 parameters and a salt. These second set of parameters is important to speed up the process.
- The system can then use these newly obtained parameters from storage, calculate with these parameters new hashes for the unique features and compare them to saved hashes. If a specified number of unique feature hashes match up, the fingerprint can be verified as correct.
This is obviously a draft and can be optimized in a number of ways, depending on hardware capabilities, attacker scenarios etc.
Let me know what you think.