Using crypto against Phishing, Spoofing and Spamming...

Anne & Lynn Wheeler lynn at garlic.com
Wed Jul 21 12:10:24 EDT 2004


At 01:54 PM 7/19/2004, Steven M. Bellovin wrote:
>It's also worth remembering that an SSL-like solution -- cryptographically
>protecting the transmission of credit card number, instead of digitally
>signing a funds transfer authorization linked to some account -- was
>more or less the only thing possible at the time.  The Internet as a
>medium of commerce was too new for the banks to have developed
>something SET-like, and there wasn't an overwhelmingly-dominant client
>platform at the time for which custom software could be developed.
>(Remember that Windows 95 was the first version with an integral TCP/IP
>stack.)  *All* that Netscape could deploy was something that lived in
>just the browser and Web server.  SET itself failed because the
>incentives were never there -- consumers didn't perceive any benefit to
>installing funky software, and merchants weren't given much incentive
>to encourage it.

SET couldn't replace online transaction ... the encryption was
effectively there for hiding credit card while in-flight ...
which SSL was already doing ... but SET was doing at an
order to two-orders increase in complexity and overhead.
SET didn't provide any additional countermeasure against
the major exploits/vulnerabilities (vis-a-vis SSL) ... even
with all that complexity.

the transaction was still online ... since there are a bunch
of other factors involved in authorization ... like credit limit
... not just whether there is impersonation with lost/stoleln
numbers.

there was still the enormous payload bloat (certificates and
signatures increase the size of typical 8583 transaction by
two-orders of magnitude) which prevent true end-to-end
security operation. As a result the signature was verified
at some internet boundary, then the signature and certificate(s)
were stripped off and traditional 8583 packet forwarded
to the consumer/issuing financial institution. Later at some
ISO standards meeting, one of the association business
people presented numbers on number of 8583 packets
with the signature bit turned on and they positively knew
no digital signature was involved.

It wasn't even a real PKI ...

1) i.e. the x.509 identity certificates from the early 90s had
been depreciated because of the privacy and liability issues
... and the certificates effectively were issuing
relying-party-only certificates with the account number
and public key.

2) there was no revocation and/or other types of process
(which could be considered minimum requirement for
a PKI operation) ... they were simply manufactored
certificates (a term we coined to describe the SET and
SSL infrastructure; contrasting it to PKI). SET
specifically stated that the transaction would be
online and rely on the existing online infrastructure
for determining lost, stolen, revoked, canceled, etc
... as well as all the other stuff an online infrastructure
can do with  timely and aggregated information
(like credit limit)

3) it is trivial to show that for relying-party-only certificates
requiring online infrastructure ... that the certificates
themselves are redundant and superfluous ... aka the
key is registered with the issuing party ... and the transaction
is performed by the issuing party. The transaction can
be digitally signed (w/o the enormous payload bloat of
carrying a certificate) and the issuing party verify the
digital signature with an onfile public key .... w/o having
to resort to dealing with a certificate (that the issuing
party would have originally generated from the onfile
information).

 From an incentive standpoint the PKI model is effectively
orthogonal to standard business processes.

The key owner pays something to the issuing party (or
at best, the issuing party absorbs the costs). The standard
business process has any sort of contract between the
key owner and the issuing party.

This totally leaves out the relying-party ... which is the
primary beneficiary of the PKI model from being a part
of the contractual business process ... which would imply
little or no legal recourse if something went wrong. GAO
has created a facade to address this issue by making the
TTP certification authorities sort of agents of the GAO ... and
having all relying-parties signed contracts with the GAO.,
The PKI frequently creates a total disconnect between
the parties of the certification "contract" ... and the
relying parties ... which should have recourse in case
something went wrong aren't even a part of it.

In the specifics of the SET deployment ... the primary
potential beneficiaries theoritically were the merchants
(from the thoery that SET signed transactions would be
considered card-present & card-owner present ... and
lower the merchants cost for doing the transactions).
However the parties "paying" for the certificates and
most of the infrastructure were the issuers and the
consumers. Not only may a traditional TTP PKI create
legal disconnect for relying parties .... but in the SET
case there was major disconnect between who paid for
most of the infrastructure and who benefited (i.e.
need some sort of mechanism to get the merchants
to pay for the consumer's certificate .... even tho
the certificates were functionally redundant and
superfluous).



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

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



More information about the cryptography mailing list