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

Wed Sep 7 13:34:11 EDT 2005

Thus ATMs and the weak 2 factor authentication system they use are
untrustworthy, I knew that already, but as I said, its better than not
having the multifactor authentication.  The fact that many cards may be
used as credit card and you thus bypass the second factor, is a HUMAN
failing, the entity accepting the cards are supposed to check the
signature, against a photo id, ESPECIALLY if the card says "See ID".

But this overabundance of text doesn't solve my problems with the
assertion that PSKs are somehow more secure than Public/Private key
encryption with a trusted third party as verifier, and specifically the
X.509 Certificate Authority System that is the backbone for SSL.

No one is touching on the key issues
 sharing of keys securely and how to validate that they haven't been
comprimised.
 how a user is supposed to keep track of the secure keys (kind of a side
point)
 how the validation of identity of these systems would work

Peter brought up ATMs and I wasn't going to go out on a limb and say
they aren't trustworthy before, but the truth is, they aren't
trustworthy.  That being said, its a completely beside the point.

Unless the issues I pointed out are addressed , PSK is a much WORSE
solution than trusting a third party for verification of the other
entities identity.  Especially since you profess that certs are
"redundant and superfluous standin for the real information", how I am
to verify that a given website in Timbucktoo, is owned and operated be
the entity making the claim without going there myself, with SSL we have
SOME assurance that someone verified it. 

Its no different than trusting that the people at the DMV did their jobs
when a drivers license was issued, but even drivers licenses aren't
acceptable authoritative proof that someone is who they profess to be. 
Here in Nebraska we have one of the most difficult drivers licenses to
forge, so what did the criminals do? they stole the machines, so they
could make perfect forgeries.   Trust must lie somewhere, if you have a
structure that gives some assurance of that the entities are who they
say they are, that is a world better than lacking those arrurances. 

So, my point is very simple, how am I to verify that a website, that I
have no control over, that has the proper PSK is who they say they are? 
I have seen no answers, and I still see the same flaw, with ATMs
websites or anything else, a shared key isn't a secret, and if you are
professing it is, how are you to know it hasn't been comprimised?

Anne & Lynn Wheeler wrote:

>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
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3544 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050907/d9dacd46/attachment.bin>