how to secure biometric data

Question

I'm designing a database to store biometric data collected from worn medical devices. For obvious reasons this is pretty delicate, and I'm trying to ensure that there is very limited ability to tie the data to the individual.

I am considering using a multi salt hashing strategy - where I use one salt on a user's password to log in to their personal data, and a second salt which can be hashed with their password to create the unique Id in another table, with us not storing the salted password other than in the other table as unique ID.

I think that this would mean that between logged in sessions we would have no ability to tie the biometric data to the individual, but the user would when logged in.

However the problem I foresee is that if we have to reset their password then the user loses all access to their historic biometrics with no reasonable possibility of recovery.

Can anyone suggest an alternative solution which is no less protective of personally identifiable data, but which doesn't lose access on a password reset please?

Ideally we do not want to even encrypt the biometric data, just prevent it from being associated to any one individual (even under court order - we'd like the prevention to be mathematically based rather than trust based). We will never need to tie it back to the individual.

Thanks for reading, and apologies if this is the wrong place.

Answer 1

There are some common-sense security measures you can make to help protect your biometric data, including these:

• Strong passwords mean that it’s harder to steal your data by simply cracking your password.
• Keeping your biometric information in only a few, limited places gives hackers fewer places to breach your data.
• mOne of the best ways to help secure your devices is to keep your software current.
• When your device manufacturer notifies you of an available software update or patch, install it right away to help reduce the opportunity of your device being vulnerable to security flaws.
• It’s especially important to keep your operating system and Internet security software current.
• If you're worried about the security of your biometric data, sometimes you can opt out of providing it.
• Consider a smartphone that doesn’t require fingerprint authentication, or choose not to use facial recognition software.
• You can also disable facial recognition in your Facebook settings

Answer 2

Data security and biometric data: Increasing numbers of data security threats equally affect biometric data as well. Since biometrics has gone all electronic and automated, where biometric features are captured, processed and stored electronically on information systems and equipments, it becomes imperative to safeguard biometric data like other important electronic data. An individual’s measurable anatomical or behavioral characteristics are called biometric identifiers. Biometric identifiers of a person become a biometric template when they are sampled by a biometric recognition system and processed by pre-defined rules and algorithms within the systems. Biometric template of a person does not contain biometric data in its original form, like facial or fingerprint image. It can rather be called a mathematical summary that is produced by processing originally captured biometric pattern. Biometric templates are binary files that are in unreadable form. These templates contain the unique characteristics of a person’s biometric information, and they are the master copies that each future data acquisition would be compared to.

Though claims are often made that biometric template of an individual is of no use since they are just digital reference of one’s biometric identifiers and cannot be reverse engineered, security of this data, however is still crucial because hacking attempts are getting more sophisticated with time, and reverse engineering of biometric templates may be possible at some point of time.

Answer 3

Unfortunately, what you are asking for has a logical contradiction: If you want only the user to be able to make that link between his account and the data, then the user must supply something that only he knows. It could be a password, it could be some other key of some sort, could use public key cryptography to decrypt something, etc., etc. But no matter how you do it, if you can reset the user's password and let him back into his account - that is, by definition, "trust based", because you were able to allow him access again without him providing the missing piece of information to do that.

My suggestion on a solution would be something like this (both of the following together):

• Instead of using a one-way hash to link to the account/password, you could encrypt the key of your biometric data table and store that in the user table - encrypt it with the password. And if the user changes the password, decrypt with the old and encrypt with the new. That essentially makes the password the "key" to getting the ID which links to the data.

• You could separately record another set of information which would be used as part of the account recovery/password reset procedure. You could store, for example, the person's account number, answers to a few security questions, date of birth, etc. These could also be used as a key to separately encrypt the ID that links over to the data. How much data you need to make that secure is subjective and depends on your scenario - but would at least still be information that the user must provide.

Perhaps someone has a better answer, but that's my take on it.

Answer 4

I'm not familiar with the subject, but I'll give it a try. First, a few questions:

• you say you'll never veed to tie it back to the individual, but you are concerned about him losing access to his historic data. To me, this is incompatible. In the end, you need to tie it back, right?

• doesn't a simple read-only method/unilateral procedure accomplish this? Like storing passwords. You can never see what a password stored is, you can just run a procedure to see if a given password matches with the stored one. So, in your case, data would be available only through a single/double password (session + security one). And the second could be available only after the first is ok (equals "logged in").

Hope I understood the question.