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