[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 May 2019 09:20:54 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: fprintd: found storing user fingerprints without encryption
Roman Drahtmueller writes:
> [...]
>
> > 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.
Therefore dedicated tamper-proof IC-designs+embedded software
exist, that perform the biometry template storage and matching
on the chip (MoC). There are some vendors out there providing
such hardware + MoC-algorithms, but mainly fingerprint and some
iris biometry variants seem certified so far. These are intended
for access cards or USB-tokens in two or more-factor authentication
schemes in a 1-to-1 match fashion, not as centralized 1-to-many
matching schemes also deployed rarely (e.g. in Japan where they
really like biometrics as long as you do not have to touch the
biometry reader ...).
> [...]
>
> > 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.
At the momenent I do not know of any algorithms providing sufficient
entropy binary hash data from fingerprints in a reliable way.
Changing extraction to deliver more entropy results in higher
FNR during authentication step later on, I think.
> [...]
When working on a project to provide highest security MoC solutions
with Linux (for other type of biometry, not fingerprints), Nitrokey
was offering an open-source USB-token hardware (even the PCBs are
open source, if I remember correctly). That platform seemed closest
to be a good starting point for developing such an open source MoC
biometry solution as they sell also one part with a certified tamper
proof trusted element that seemed to allow performing biometry
template storage and comparison on chip if programmed correctly.
Time in the project was too limited to explore, if that hardware
would REALLY allow to upgrade it to a powerful, highly secure but
still affordable open source biometry system for use by journalists,
human rights activists, NGOs ... and nerds, e.g. for password+biometry
secured full disk encryption schemes.
> [...]
hd
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.
