Using crypto against Phishing, Spoofing and Spamming...
Anne & Lynn Wheeler
lynn at garlic.com
Thu Jul 8 11:44:52 EDT 2004
At 10:40 AM 7/7/2004, Hal Finney wrote:
>SET failed due to the complexity of distributing the software and setting
>up the credentials. I think another reason was the go-fast atmosphere of
>the late 90s, where no one wanted to slow down the growth of ecommerce.
>The path of least resistance was simply to bring across the old way of
>authorizing transactions by card number.
both SET & SSL encrypted data in transit. an issue is that SET is
significantly more complex and provided no additional countermeasure
(vis-a-vis SSL) against major remaining exploits .... like harvesting the
merchant transaction file while at rest.
there was some issue that SSL was the incumbent ... so SET had to
demonstrate significant better ROI to displace it ... rather than
significantly higher "I" with little or no additional "R".
some SSL:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the security proportional to risk reference (using merchant transaction
file as example)
http://www.garlic.com/~lynn/2001h.html#61
couple minor past refs related to SET business operations
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards
another SET issue was that it took a typical ISO 8583 transaction of 60-80
bytes and added a RSA 128 digital signature and issuing certificate of
4k-12k bytes .... effectively increasing the payload size by a factor of
two orders of magnitude. it stripped all the SET overhead off at the
internet boundary and transmitted a traditional 8583 message (in part
because it was difficult to justify a 100-fold increase in payload size for
no obvious benefit) with a flag indicating whether the signature had
verified. There was some presentation at an ISO meeting by one of the
association business people about the number of 8583 messages with the
signature-verified flag turned on and they absolutely knew that there was
no SET technology involved (some justification was association was
proposing rules that transactions with the flag on would have lower
merchant fees). missing is that typical authorization includes a lot of
dynamic and aggregation factors (like credit limit) that are totally
missing in a simple certificate-based (offline) authentication model. In
fact, most infrastructures that involve transactions of any value have
migrated and/or are migrating to online infrastructures that involve timely
and/or aggregated information .... something that is missing from a purely
offline, certificate-based, static, stale data infrastructure.
misc. implications
1) given an online transaction environment, it is then trivial to show that
certificates are redundant and superfluous ... because it is possible to
access the timely updated copy of the information rather than having to
rely on the stale, static copy of the certificate information (designed to
satisfy an offline environment requirement)
2) certificate market then becomes relegated to both offline and no/low
value (as infrastructures of value migrate to online paradigms) ... there
is little/no justification for paying money for certificates if only no/low
value infrastructures are involved.
3) w/o significant funding for certificate-based infrastructure, there is
little money to underwrite high-integrity certificate-based operations
4) with no high-integrity certificate-based operations, it is difficult to
justify using certificates for high-value operations
5) go to #2
as has past frequently noted, the requirement given the x9a10 retail
payments working group for the x9.59 standard was to preserve the integrity
of the financial infrastructure for all retail payment environments. one of
the considerations was being able to accommodate end-to-end integrity ...
aka the financial responsible entity for authorizing the transaction also
performs the authentication. another issue x9a10 had to address was to
address other kinds of risks .... like the merchant transaction file where
the information traditionally has to occur in the clear to support normal
business operations (offer something more than the encryption of data
in-flight).
http://www.garlic.com/~lynn/index.html#x959
lots of posts about certificate infrastructures
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
misc. stuff on x9.59, identity, authentication, and privacy
http://www.garlic.com/~lynn/subpubkey.html#x959
--
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