Another entry in the internet security hall of shame....

[Anne & Lynn Wheeler]

Alaric Dailey wrote:
 > ATMs would be infeasible if they were not a 2 factor authentication
> system, and every day we see more cracks in the way that system is
> implemented.  Starting with the way the PSKs are shared. 
> 
> http://news.bbc.co.uk/1/hi/technology/4183330.stm

ATMs use "something you have" authentication ... a card with a magstripe
that is sent out. There is a 2nd factor, PIN, that is also distributed
... as a countermeasure to lost/stolen cards.

note that both credit cards and many debit cards can be used in non-PIN,
signature mode (i.e. if the card is lost/stolen, crook may still be able
to use it w/o PIN).

multi-factor authentication presumes that the different factors are
subject to different kinds of vulnerabilities and exploits.

PINs are a form of shared-secrets ... security requirements typically
mean that there is a unique shared-secret for every environment. the
result is vast proliferation of PINs and passwords leading to people
writting down their pins & passwords (there was some study that claimed
30percent of atm cards have pins written on them). As a result,
multi-factor infrastructure is undermined because of shared-secret based
environments has led to scores of shared-secrets that people are
required to keep track of.
http://www.garlic.com/~lynn/subpubkey.html#secrets

the short-coming of shared-secret environment, is that a shared-secret
can be used for both origination as well as verification (the same value
 used for authentication can also be used for impersonation), which has
led to requirement that there are large number of unique shared-secrets,
 which has led to the huge proliferation in the number of shared-secrets
... which has also led to underminning principle of multi-factor
authentication ... having unique failure modes .... sorry for that ... I
spent some large amount of time producing  high availability systems ...
where security exploit/vulnerabilities were just another kind of system
failure.
http://www.garlic.com/~lynn/subtopic.html#hacmp

it isn't so much that the key distribution/sharing mechanism is flawed
... it is that there are flaws in shared-secret based infrastructures
(including swamping nominal human factors with an impossible number of
different things to memorize).

The other short-coming in current ATM environment is skimming that can
go on at the POS or ATM terminal ... where the attackers can record the
card and pin information. This results in both 1) common vulnerability
for two factor authentication ... defeating purpose of having
multi-factor authentication and 2) that existing technology is quite
vulnerable to replay attacks (aka creating copy of magstripe in
counterfeit card and being able to reproduce the pin).

So fundamental public key operation can address a number of these
short-comings w/o resorting to PKI infrastructure and/or changing the
key and card distribution operation.

1) upgrade magstripe to hardware token that does digital signature
authentication. the digital signature is unique each time and is
therefor resistant to existing replay vulnerability, threats and attacks

2) since public key is not a shared-secret based infrastructure ... it
is practical to record the same public key in multiple different
environments, in theory transitioning to a person-centric environment
(from the existing institutional-centric environment). this also is more
resistant to data breaches ... since any exposure of the recorded public
key can't be used for impersonation.

3) there is still the issue of using a PIN as countermeasure to
lost/stolen token ... which is a significantly lower threat compared to
crooks being able to harvest tens of thousands or millions of pieces of
information for purposes of account fraud (skimming recording devices at
ATM & POS terminals or data breaches).

4) with hardware token, the PIN can be used directly with the token for
token operation ... as opposed to be transmitted and recorded in the
infrastructure. That eliminates the PIN as a shared-secret. In theory a
person-centric environment can use the same PIN/token with multitude of
different infrastructures and/or use the same PIN with multitude of
different tokens. This last becomes a trade-off between remembering lots
of PINs (and threat of having them written down) vis-a-vis compromise of
single PIN can expose several tokens. However, in person-centric
environment, it is possible to leave such a threat trade-off decision to
the individual.

The issue of PKI, certificatin authorities, and digital certificates
were that the original digital certificate design point was for first
time communication between strangers where the relying party also had
not timely, direct (possibly online) access to a trusted party. The
digital certificates filled this trust void in a manner siumilar to
letters of credit from the sailing ship days.

In an environment where relying parties have long-standing and extensive
relationship management operations keeping track of large number of bits
of information ... it is trivial to show that digital certificates are
redundant and superfluous.

Furthermore, even in the first time communication between strangers ...
where the relying party has no prior interaction with the subject ...
digital certificates may still be redundant and superfluous standin for
the real information if the relying party is able to directly contact
some authoritative agency responsible for the information (aka real-time
communication obtaining the real current information in lieu of a
redundant and superfluous, stale, staic digital certificate).

misc. past person-centric related postings:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst
case, or average case? (TCPA)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so
dumb???
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times
- open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and
authentication
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com