[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.02.1905081352280.25606@i8.fpunygfrxha.qr>
Date: Wed, 8 May 2019 15:13:58 +0200 (CEST)
From: Roman Drahtmueller <draht@...altsekun.de>
To: Seong-Joong Kim <sungjungk@...il.com>
cc: oss-security@...ts.openwall.com,
Noel Kuntze <noel.kuntze+oss-security@...rmi.consulting>
Subject: Re: Re: fprintd: found storing user fingerprints
without encryption
[...]
> 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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
