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

[Seong-Joong Kim <sungjungk () gmail com>]

I think that maintainer of fprintd should participate in this conversation.
As I mentioned before, I've just reported this vulnerability to the
upstream and shared the contents of maintainer's decision.

BTW, we first need a consensus about the necessary for protection of
fingerprints.
If not, there is no need to talk about it no longer.
But, I think it is worth protecting fingerprints as others have tried, that
I've mentioned before.

If you agree with this, it seems that we need more discussion about solving
the problem.
Also, I wonder if your solutions are already proven way to solve this issue.

Sincerely,
Seong-Joong Kim.

2019년 5월 8일 (수) 오후 10:13, 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.