Re: REVIEW: "Biometrics for Network Security", Paul Reid

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 10/06/04 

Date: Wed, 06 Oct 2004 10:33:21 -0600

followup
http://www.garlic.com/~lynn/2004l.html#4

note that while three factor authentication

* something you know
* something you have
* something you are

allows pin/passwords as "something you know" authentication, there can
be a big different between "something you know" as a "shared secret"
and "something you know" as a "non-shared secret".

for instance the current payment card scenario effectively has account
numbers as shared-secrets ... since gaining knowledge of the account
number can enable fraudulent transactions. harvesting of merchant
transaction files can result in account/identity theft impact because
of the ability to use the account numbers for fraudulent transactions.
some related discussion of security proporitional to risk
http://www.garlic.com/~lynn/2001h.html#61
misc. past postings about secrets and account numbers
http://www.garlic.com/~lynn/subpubkey.html#secrets

where there is a big focus on protected all occurances of account number
because of its shared-secret vulnerability. an alternative solution is
x9.59
http://www.garlic.com/~lynn/index.html#x959

where financial transactions are digitally signed and there is a
business rule that account numbers used in x9.59 transactions can't be
used in non-authenticated transactions. as a result, just knowing an
account number used in an x9.59 doesn't enable fraudulent transactions
(or account/identity theft) and therefor such account numbers no
longer needs to be considered as a shared-secret.

one of the requirements of shared-secret based infrastructure (in
addition to the requirement to needing to protect the shared-secret)
is frequently to require a unique shared-secret for different security
domains .... aka ... the password on file with your local garage ISP
should be different than passwords used for personal banking or for
you job. The issue is that for different security domains ... they may
have different levels of protection for shared-secrets. there may also
be instances where one security domain may be at odds with some other
security domain.

In effect, anything that is on file in a security domain ... and just
requires reproducing the same value for authentication can be
considered a shared secret. shared-secret passwords frequently also
have guidelines regarding frequently changes for the shared-secret.
some past references to password changing rules:
http://www.garlic.com/~lynn/2001d.html#52
http://www.garlic.com/~lynn/2001d.html#53
http://www.garlic.com/~lynn/2001d.html#62

A "something you have" hardware token can also implement "something
you know" two-factor authentication, where the "something you know" is
a non-shared-secret. The hardware token contains the secret and is
certified to require the correct secret entered for correct operation.
Since the secret isn't shared ... and/or on file with some security
domain, it is a non-shared-secret ... rather than a shared-secret.

A relying party needs some proof (possibly at registration) that
authentication information (like a digital signature) is uniquely
associated with a specific hardware token and furthermore needs
certified proof that a particular hardware token only operates in a
specific way when the correct password has been entered .... to
establish trust for the relying party that two-factor authentication
is actually taking place. In the digital signature scenario, based on
certificate of the hardware token, the relying party when it validates
a correct digital signature then can infer two-factor authentication:

* something you now (password entered into hardware token)
* something you have (hardware token generated digital signature)

In a traditional shared-secret scenario, if a shared-secret has been
compromised (say merchant transaction file has been harvested), new
shared-secrets can be issued. Typically, there a much fewer
vulnerabilities and different threat models for non-shared-secret
based infrastructures compared to shared-secret based infrastructures
(in part because of possible greater proliferation of location of
shared-secrets).

It turns out that "something you are" biometrics can also be
implemented as either a shared-secret infrastructure or a
non-shared-secret infrastructure. Biometrics typically is implemented
as some sort of mathematical value that represents some biometric
reading. In a shared-secret scenario, this biometric mathematical
value is on file someplace, in much the same manner that a password
might be on file. The person is expected to reproduce the biometric
value (in much the same way they might be expected to reproduce the
correct password). Depending on the integrity of the environment that
is used to convert the biometric reading to a mathematical value
... and the integrity of the environment that communicates the
biometric value, a biometric shared-secret imfrastructure may be prone
to identical vulnerabilities as shared-secret password systems ... aka
somebody havests the biometric value(s) and is able to inject such
values in to the authentication infrastructure to spoof an individual.

Many shared-secret biometric infrastructures with distributed sensors
that might not always be under armed guards ... frequently go to a
great deal of trouble specifying protection mechanisms for personal
biometric information. One of the issues with respect to shared-secret
biometric infrastructures compared to shared-secret password
infrastructures, in that it is a lot easier to replace a password than
say an iris or a thumb.

There are also hardware tokens that implement non-shared-secret
biometrics, in much the same way that non-shared-secret passwords are
implemented. Rather than having the biometric values on file at some
repository, the biometric value is contained in a personal hardware
token. The personal hardware token is certified as performing in a
specific manner only when the correct biometric value is entered.
Given adequate assurance about the operation of a specific hardware
token, a relying party may then infer from something like validating
a digital signature that two-factor authentication has taken place,
i.e.

* something you have (hardware token that uniquely generates signature)
* something you are (hardware token requiring biometric value)

biometric values are actually more complex than simple passwords,
tending to having very fuzzy matches. for instance an 8-character
password either matches or doesn't match. A biometric value is more
likely to only approximately match a previously stored value.

Some biometric systems are frequently designed with hard-coded fuzzy
match threshhold values .... say like a 50 percent match value. These
systems frequently talke about false positives (where a 50 percent
match requirement results in authenticating the wrong person) or false
negatives (where a 50 percent match requirement results in rejecting
the correct person). Many of these systems tend to try and adjust
their fuzzy match value settings in order to minimize both the false
positives and false negatives.

in value-based systems, hard-coded fuzzy match values may represent a
problem. an example is transaction system that supports both $10
transactions and million dollar transactions. In general, a risk
manager may want to have a higher match requirement for higher value
transactions. 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: REVIEW: "Biometrics for Network Security", Paul Reid
    ... allows pin/passwords as "something you know" authentication, ... longer needs to be considered as a shared-secret. ... It turns out that "something you are" biometrics can also be ... There are also hardware tokens that implement non-shared-secret ...
    (comp.security.misc)
  • Re: Two-factor authentication with SSH?
    ... > And unlike real hardware tokens it costs nothing. ... shared-secret authentication vis-a-vis non-shared-secret ... the registration of the public key at the relying-party ... ...
    (comp.security.ssh)
  • Re: Innovative password security
    ... shared-secret for every unique security environment. ... The master password scenario tends to be simply a secret ... ... the authentication material ... ... either a software/file container ...
    (alt.computer.security)