the limits of crypto and authentication

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler wrote:
> But SET Lite and MOSET critically alter the SET 1.0 architecture and
> soften SET's rock-hard security - all for the sake of convenience. For
> example, the technologies abandon the idea that each online consumer is
> going to have a bank-issued SET digital certificate for credit-card
> encryption. This certificate was to be the main means of verifying the
> consumer's real identity on the Internet.

note that the bank-issued consumer SET digital certificate ... wasn't
used for credit-card encryption. the original set had this terribly
convoluted process where the consumer encrypted some of the stuff with
the *merchants* public key and other stuff with the *processors* public
key.

the consumers relying-party-only digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

was used for the client to perform "something you have" authentication
... aka digitally signing with the corresponding private key (aka the
verification of the digital signature implies that the signer has access
and use of the private key)

since it wasn't an x.509 identity certificate, didn't contain any
personal information, and was purely a relying-party-only certificate
... there was no real identity on the internet (avoiding raising
horrible privacy and liability issues).

futhermore, since it was a simple relying-party-only certificate, it is
trivial to demonstrate that it is redundant and superfluos ... aka just
flow the transaction thru to the consumer's bank ... and they can
validate the digital signature using the onfile public key. it isn't
necessary for the consumer to repeatedly append a relying-party-only
certificate to possibly thousands of transactions ... for transmission
back to the issuing institution ... which has the original *onfile*;
especially when the redundant and superfluous relying-party-only
certificate can represent a payload bloat of one hundred times.

note that the referenced article is dated 1999/3/22 and references the
original SET 1.0 deployment (full blown redundant and superfluous
relying-party-only customer certificates) two years earlier (spring
1997). The draft 1.0 specification had appeared spring 1996, initial
prototype appeared early fall 1996, and dedicaed demo systems showed up
at floor shows by the end of 1996.

the other reference indicates that browsers with ssl support appeared
late 1994 with big announcement the spring of 1995.
http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and
authentication

a trivial side-note ... since the SET specification wasn't issued by a
sanction standards body ... it wasn't a Standard in the official sense.

one of the operational differences between SET and x9.59 financial
industry standard ...
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy

is that x9.59 has an operational rule that account numbers used in x9.59
transactions can't be valid in non-x9.59 transactions .... which
eliminates the requirement for horrendous amounts of cryptography as
countermeasure for evesdropping of transactions during transmission
(since evesdropping of the transactions doesn't provide an attacker with
sufficient information to perform fraudulent transactions). As a
by-product, it also eliminates the threats and vulnerabilities from
data-breaches ... where there is sufficient information in logged
transactions for a crook to perform fraudulent transactions.

In the SET scenario ... even when the transaction is authenticated using
digital signature ... there was still a requirement for horribly complex
cryptographic implementation as countermeasure to attacker evesdropping
the transaction and using the gained information to perform fraudulent
transactions.

There is an issue where both account fraud and identity fraud have been
lumped under global identity theft label. In the strict account fraud
case, the attacker just needs to obtain sufficient information to
perform fraudulent transactions (against existing accounts) w/o
necessarily obtaining any real personal information.

While SET avoided the horrible privacy and liability issues with real
x.509 identity certificates by using relying-party-only certificates ...
it was still subject to account fraud where crooks obtaining access to
information from transaction (either *data-in-flight* or *data-at-rest*
.... aka data breaches) have access to sufficient information for
performing fraudulent transactions.

In contrast, x9.59 is signifcantly simpler and represents significantly
lighter payload ... and even eliminates the need to provide security
confidentiality for transactions as countermeasure against attackers
(both in the *data-in-flight* as well as the *data-at-rest* cases)
looking at performing account fraud transactions.

past posts mentioning x9.59 & business rules:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic
Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software
for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki11 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the
Way Down
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM
(was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the
session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and
authentication
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card
Protocol on Web Site
http://www.garlic.com/~lynn/2002n.html#14 So how does it work...
(public/private key)
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network
Security", Paul Reid
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand

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