HAL149 Logo
Back to blog

Unhackable Biometric Keys?

Traditional passwords are already biometric keys — and they are mutable.

Unhackable Biometric Keys?

Traditional passwords are already biometric keys — and they are mutable. They’re stored in your brain, and you can change them. They can’t be stolen unless you give them away or write them down. That’s why fingerprints or retinas have the same problems, or even worse: they are not mutable, and they can be stolen without you even knowing.

The problem with keys isn’t that they’re not biological — it’s that they are centralized, making them vulnerable to hacking. Using a private key, even via a password, decentralizes that information and makes its security solely the responsibility of the key holder.

Almost always, the first solution to a problem is the best one — not always, but often enough.

The problem of bio-identification is not simple. Removing the flesh and blood from processes to make them more efficient, and then bringing them back to solve something, is a complicated issue — unless there’s a technological revolution.

Transhumanism follows that path, but in that case, the true agenda is not the freedom and privacy of individuals, but their control and exploitation through the integration of biometric data into the cloud.

What would be interesting is if your biometric data could be used to create a secure key (accessible only by you), and from it, generate the keys you use to access any system — much like what is done now with public key cryptography.

The idea would be to have a blockchain-like system where ‘mining’ could only be done with your biometrics. The issue is not just using biometrics, which are hackable and thus stealable, but using SOMETHING that enables secure and unique identification. In such a way that YOU are the key.

This could be achieved if, in addition to your key, you include a ledger of your physical locations. If encrypted, there should be no problem. The point is that if your access key includes some kind of personal history, it would be much more secure. But this returns us to the same problem: how do you assign that history or ledger to your key?

Related to the above, to verify if a hash is correct, you would have to generate it again separately (like with PGP), which invalidates the assumption of uniqueness or exclusivity of the calculation. The solution could be to generate two hashes and check if they align in some way (i.e., they correspond to the same biometrics). But still, the problem remains: WHO is the subject?