[Anti-fraud] Re: Another entry in the internet security hall of shame....

[Ian G]

Alaric Dailey wrote:
> 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.

This statement is only plausible if you consider
the paper cryptography domain.  When applied to
the business / user world, the statement fails
due to the way that real life breaks the assumptions.

> No one is touching on the key issues
>  sharing of keys securely and how to validate that they haven't been
> comprimised.

Generally, for most apps, there is already a way
to share stuff.  Just to look at one particular
application such as online banking, the bank and
the user generally communicate through post and
other means such as email at a minimum so as to
set up a relationship.  These methods may not be
secure (according to paper crypto metrics) but
they are multi-factor and are uncorrelated with
the threats.  So they work;  so the keys can be
shared securely, according to some risk measure.

>  how a user is supposed to keep track of the secure keys (kind of a side
> point)

Software?

>  how the validation of identity of these systems would work

Shared keys validate in that they are shared; the
keys themselves aren't sent over the wire in the
setup, and if the other party doesn't have the key,
then the setup fails.  This amounts to validation
of identity being measured by "has a copy of my key
too."

Now, you'll probably think this is woefully insecure
because it falls to MITM.  True, but so does most every
other system.  online browsing fails to MITM by means
of phishing in such an evidently purile fashion that
heads should be hung with shame .. if not lopped off.
Even if the browser were to do more here, the MITM is
still possible within the ivory tower of the CA,
which have't exactly inspired of late given that
they now sell lots and lots of domain-certs for
bargain basement prices.  ($7 was the latest I saw!)

So, in a business context, PSK does identity validation
more or less as well as anything else, at least on
paper (coz it hasn't been tried yet!).


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


Not really.  With SSL in the browser you have
approximately zero assurance that anyone verified
it.  If you look at the browser, and find a padlock
that gives you maybe 5% of what you need.  If you
go searching into the cert then you might be able
to establish the CA which would perhaps give you
5-20% of what you need, but to actually work out
whether a website is really the right one, you
are going to have to go elsewhere for assurance.

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

Sure.  When it matters, expect phishers to set up
SSL sites, to steal domains, to steal email confirmations,
to do all sorts of things.  Right now, they are dealing
with low hanging fruit.

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

No, I'd challenge your underlying assumption here that
the intention is to deliver trust.  Trust cannot be
delivered, it can't be sent, it can't "lie" anywhere.

Trust is something that only each individual can find
for themselves on their own checks.  Trust never leaves
a person.

What the system can do is make statements and present
evidence.  It's up to the user to decide whether to
trust those statements and whether to seek further
evidence or risk it with what she has.

The difference in these two approaches is immense.  In
your view you have to get it right;  except you have no
way to establish "trust" that actually makes sense and
hence you're trapped into an ever increasing quality
cycle, while the businesses selling that "trust" are
trapped in an ever decreasing quality cycle!

In the alternate view, the system simply has to present
a set of evidence.  PSKs presents a good statement - both
parties have the keys.  But others might too!  PKI presents
some other statements, with their own set of flaws.  It's
up to the user to assess her own risk profiles and decide
beyond that.

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

You don't necessarily know these things but the question
you are asking is about someone else's threat model, it
isn't about the threat model that the average user faces
when dealing with the average web site.

iang

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