Re: PGP Lame question

Stefan Tillich <stefanti@gmx.at> writes:
> You don't need all three of the above to do authentication. In fact,
> biometrics is not (yet) very suited for a large class of real-world
> systems.

sorry ... it is about the 3-factor authentication *model*
http://www.garlic.com/~lynn/subtopic.html#3factor

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

within the 3-factor authentication *model* ... you can have one-factor
authentication, two-factor authentication, and/or three-factor
authentication ... and you can have different combinations of the
factors. it is a *model* for helping thinka about countermeasures for
risks and threats.

for instance, two-factor authentication is typically considered
to have higher security than one-factor authenticaiton.

also, 3-factor authentication *model* by itself doesn't encompass all
the factors that should be considered regarding threats and
vulnerabilities.

for example, here is post from threat in comp.arch that has to managed
to roam around the financial transaction landscape ... this specially
is with regard to recent security breach involving financial
transaction information
http://www.garlic.com/~lynn/2005u.html#31 AMD to leave x86 behind?

two-factor pin-debit (pin as "something you know" and card as
"something you have") has typically considered more secure than simple
credit cards. in part, the "something you know" pin has been
considered a countermeasure to lost/stolen card threat/vulnerability.
however, there is something of an implicit assumption that the
different authentication mechanisms have different/distinct
vulnerability profiles.

however, effectively both the pin and the magstripe information (proof
of having the card) are both forms of "static data" authentication ...
and furthermore "shared-secret", "static data" (other attributes,
characteristics of authentication operations). "static data" typically
also has "replay attack" vulnerabilities.

one of the issues is the spread of compromised devices in the 90s that
recorded/skimmed "static data" (somewhat the subject of the security
breach in the reference post) ... created opportunity for "replay
attack" (aka fraudulent financial transations basically by replaying
the skimmed information). one of the issues was that such compromised
devices created a common recording/skimming vulnerability for both the
"something you know", "static data" pin and the "something you have",
"static data" card magstripe. This example sort of invalidates some
possible implied assumption about two-factor authentication being more
secure than one factor authentication (since the issue of the
different authentication factors having different, unique
vulnerabilities no longer existed).

other collected posts regarding secret vis-a-vis *shared-secret*
authentication information
http://www.garlic.com/~lynn/subpubkey.html#secrets

and various collected posts mentioning skimming/harvesting
vulnerabilities of "static data" authentication information
http://www.garlic.com/~lynn/subpubkey.html#harvest

misc. collected posts about fraud, explots, threats, vulnerabilities
http://www.garlic.com/~lynn/subpubkey.html#fraud

recently there have been some threads in other venues about the
use of SSL for hiding account numbers as part of the original
e-commerce work ... a couple posts about working with this
small client/server startup that had this technology they called
SSL and wanted to be able to do payment transactions on their
server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the issue there is that the account numbers are a form of "static
data" that in some situations are sufficient for a crook to perform a
fraudulent transactions ... and as a result the account number takes
on the attributes of "static data", "shared secret", "something you
know" one-factor authentication (for those kinds of transactins).
a related post describing sizing the risk related to exposing
account numbers ... security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

In the above mentioned security breach post
http://www.garlic.com/~lynn/2005u.html#31 AMD to leave x86 behind?

there is discussion about the work of the financial standards x9a10
working group on the x9.59 protocol.
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the x9a10 working group had been given the requirement to preserve the
integrity of the financial infrastructure for all retail transactions.
It was in the time-frame that x9a10 work on x9.59 was intitiall
starting that some of the skimming/harvesting exploits were coming to
the forefront. so one of the issues was how to create countermeasures
for all retail payments to deal with the *replay attack* threats.

as described in the post, x9.59 basically introduced a form of
*dynamic data* authentication so that skimming/harvesting of
information related to x9.59 retail transaction could not be used
(either in whole or in part) for performing fraudulent transaction.

one of the side issues was that x9.59 didn't do anything to hide the
*static data* (like ssl cryptography was used to do), it just changed
the paradigm from a *static data* authentication operation to a
*dynamic data* authentication operation ... where the
skimming/harvesting of the information would no longer result in
(*replay attack*) fraudulent transactions. With that, it was no longer
necessary to use cryptography as a countermeasure to *replay attack*
fraudulent financial transactions ... since *replay attack* fraudulent
financial transactions were no longer possible in a *dynanic data*
authentication environment. The information gained from in-flight
internet transactions, from compromised devices, and/or from data
breaches of transaction logs were no longer useful in performing
fraudulent financial transactions.

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