Fingerprintd:Store holds the correspondence between two vocabularies that know
nothing about each other: the trustlet identifies a finger by an opaque 32-bit
id it chose, and fprintd speaks users and names like "right-index-finger".
Nothing else can hold it -- the trustlet has no field for a name.
No biometric data passes through here. A template is a ~252 KB container the
trustlet encrypts and QTEE anti-rollback protects; this is a table of {name ->
the id the trustlet reported}, worth about as much as a username. It is stored
as one "name fid" per line, deliberately boring and greppable, because losing
it costs names rather than templates and it should be repairable by hand.
Two properties are load-bearing. fid 0 is never storable or matchable: 0 is
what the trustlet writes into the fid field when authentication FAILS, so a
stored 0 would turn every rejection into a match. And a damaged map degrades to
"fewer names known" rather than to a daemon that will not start -- unknown
names, missing ids, partly-numeric ids and zero fids are all skipped, since the
daemon that fails to start is the one that unlocks the phone.
The gid is the caller's Linux uid. SET_ACTIVE_GROUP and AUTHENTICATE only have
to agree with each other, so the value is ours to choose, and the uid makes the
mapping total with no allocation table. The dev phone's gid 60 is recorded as a
legacy group -- it was never a decision, just the ENROLL token's timeout field
read as a gid and then made self-consistent.
Verified by mutation: storing fid 0 and accepting a partly-numeric id both fail
the suite. A third mutation did not: Lookup's own zero guard is unreachable
because Add is the only way an entry is created and it already refuses 0. The
guard stays as defence in depth for a future writer, and the test now asserts
the invariant that makes it unreachable -- no entry holds fid 0 however it was
created -- rather than leaving a branch that no test can reach.
Jorijn van der Graaf
80ff09b4ce