Re: Re: fprintd: found storing user fingerprints without encryption

[Roman Drahtmueller <draht () schaltsekun de>]

[...]

> I am not insisting that encryption key should be on the disk or is
> encrypted with a static key that is embedded in the binary.
> Instead, we can make fprintd to use a TPM, if available.


The problem persists: The encryption key must be available for the FP 
data to be accessible, and so it is for an attacker. It doesn't matter 
where you store the key.

A TPM (and, transitively, products that encrypt with TPM-sealed or 
TPM-bound key material) is good for the situation where the system is 
physically stolen while powered down (or the drive fails). But that's not 
our problem here.


> Otherwise, but even though it is not perfect, it would be better to apply
> the fingerprint data protection, such as keyring or access control, rather
> than raw fingerprint template.
> FYI, Windows Hello might use Next Generation Cryptography (called CNG) to
> protect and store user private data and encryption keys.


There are not many options left to solve the stored credential problem, 
and it should be clear that saving a file, encrypted or not, is not the 
solution.

One possible solution is to use a hash algorithm, potentially cost-based, 
to derive a bit string (that is suitable for comparison with the 
persisted authoritative string) from the output of a fingerprint reader.

Another one is to use the fingerprint reader output as input to a KDF, 
which unwraps the private key of an asymmetric key pair, against which a 
challenge can be requested or which unwraps further wrapping material to 
bootstrap a key hierarchy (that can be discarded and rebuilt at any 
useful time). (*)

> > I think that this is similar approach with Lenovo Fingerprint Manager,
> Microsoft Windows Hello and other products.

I can only recommend to NOT TRUST in any security value that is not 
satisfyingly documented and/or open-sourced, but instead to expect the 
worst.

The worst btw is introducing a false sense for a security value by 
wipe-the-eye type of design (security by obscurity).


(*) Note that the overall system design for a multi-purpose key hierarchy 
must be able to cope with the requirement that "master key data", which 
might encompass biometric data, must never be accessible even to 
operating system components. A small portion of memory that is accessible 
only for a very small, associated portion of code, doing only minimal 
things, but never let go the secret. This is non-trivial to build and 
typically mandates a root of trust beyond the O/S builder.

> Have you read the following papers about fingerprint image reconstruction
> technology from standard templates?

[...]

Those are all good papers, and all of them potentially lead to the 
conclusion that
a) your fingerprint is a username, yet not public, but not secret either
b) your username is subject to being copied, regardless of how it is
   manifested.
c) biometric authentication is flawed unless combined with
   other authentication factor types


> Lastly, as you mentioned,  it is a stupid idea to use it for various
> authentication.
> But, it is still working on various authentication/identification system.


Make informed desisions about the sufficiency and adequacy of your 
protection measures based on:

* the value of your assets
* the threats against your assets
* the risks that threats against your assets create damages

In movies, the fingerprint-reader-protected-only "max security" lab 
isn't.

R.