SET

rah@shipwright.com wrote:

>At Doug Tygar's talk at Harvard last week, he claimed to have found a way
>to crack it. I, um, forgot to press him on this. Has anyone heard about
>this, or what it might be?

Actually, I did not claim to break SET.  What I said was:

(a)  because SET is such a complicated protocol, I am certain that it
     does have flaws;
(b)  SET does not have a clear design philosophy -- for example, it has
     modes in which a consumer's credit card number is hidden from a
     merchant and modes when it is given to a merchant.  These ambiguous
     design points in the protocol make the protocol vulnerable to misuse.

I have not made a serious effort to crack SET, yet.

-- Doug Tygar

-----BEGIN PGP SIGNED MESSAGE-----

At 11:22 am -0500 on 11/12/97, Doug_Tygar@cs.cmu.edu wrote:


> Actually, I did not claim to break SET.  What I said was:
>
> (a)  because SET is such a complicated protocol, I am certain that it
>      does have flaws;
> (b)  SET does not have a clear design philosophy -- for example, it has
>      modes in which a consumer's credit card number is hidden from a
>      merchant and modes when it is given to a merchant.  These ambiguous
>      design points in the protocol make the protocol vulnerable to misuse.
>
> I have not made a serious effort to crack SET, yet.

Great. Thanks. Looking forward to seeing what you get.

Personally, I'm becoming convinced that SET is practically Ptolmaic in it's
complexity. You can get money from point A to point B, but you have to go
through a lot of epicycles to get there.

Transactional shovelware, maybe. Not unlike a lot of digital signature
legislation out there.

Unfortunately, I think that no MIS manager will get fired for using SET, and
it'll take a serious demonstration of a security breach before people will
listen to anything else. At least until someone demonstrates a transaction
protocol which is, say 3 orders of magnitude cheaper...

Cheers,
Bob Hettinga

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5

iQEVAwUBNGngp8UCGwxmWcHhAQE5bgf7B2yJ8ry6J+YeTe6K3uCTrXV5CdPYDy55
AGULzPsjkmc66HeVl8A65vlQ05mzKso2Y/AXE1KlnWDD6OiuppefHbCS1iOb6K6n
1ZE2B+EWPfwElakspqHQAH6y/RvduvJuQKtbjIrs9Hq0DAg6SurPdAGDrUrI/3QW
sVKgnNXRf2PKO1Nv4Lmbobm4fYhySbkLaevVv8mFfoKLC5/B0TC9xERiYLK0g8pj
y86gK09ZorPnZ/vqba7vUufPKd9lrQ7AV9OYjdaV/EYNGx2hR7QBBe5LyjIsCuEb
Infx5yB7hckVyz6iEbJFfF9qacDN19iA15XuyNqS2IweX8htf60ggw==
=mObY
-----END PGP SIGNATURE-----

-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/
Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

Doug_Tygar@cs.cmu.edu writes:
> 
> rah@shipwright.com wrote:
> 
> >At Doug Tygar's talk at Harvard last week, he claimed to have found a way
> >to crack it. I, um, forgot to press him on this. Has anyone heard about
> >this, or what it might be?
> 
> Actually, I did not claim to break SET.  What I said was:
> 
> (a)  because SET is such a complicated protocol, I am certain that it
>      does have flaws;
> (b)  SET does not have a clear design philosophy -- for example, it has
>      modes in which a consumer's credit card number is hidden from a
>      merchant and modes when it is given to a merchant.  These ambiguous
>      design points in the protocol make the protocol vulnerable to misuse.

I agree completely.  The people involved in the SET "standards effort" 
seem to have relatively little concern about security compared to
say the TLS working group.  There are smart security-aware people
involved but the process is controlled by non-security-aware
card company VPs.

 
> I have not made a serious effort to crack SET, yet.

Neither have I, but I've already found a significant privacy problem
which would allow merchants to determine who else a cardholder has
made purchases from.  When I posted details to the set-discuss list
the response from the SET czars was "so what?".

[details: according to the spec the cardholder sends to the merchant
thumbs (SHA1 hashes) of all the certs in the cardholder's cert cache.
Since this will contain certs from merchants the cardholder has
made purchases from in the past, a merchant could simply match up
those merchant cert thumbs with cert thumbs he obtains from other
merchants, allowing him to build a list of merchants the cardholder has
attempted to make purchases from].

When the right people do make an effort to crack SET 1.0, it's quite likely
to be broken.


Sorry to sound so negative, but I just got back from a SET meeting
and those always seem to make me especially cynical.


-- 
Eric Murray  Chief Security Scientist  N*Able Technologies  www.nabletech.com
(email:  ericm  at  lne.com   or   nabletech.com)          PGP keyid:E03F65E5

-----BEGIN PGP SIGNED MESSAGE-----

In <199711121751.JAA01757@slack.lne.com>, on 11/12/97 
   at 09:51 AM, Eric Murray <ericm@lne.com> said:

>[details: according to the spec the cardholder sends to the merchant
>thumbs (SHA1 hashes) of all the certs in the cardholder's cert cache.
>Since this will contain certs from merchants the cardholder has made
>purchases from in the past, a merchant could simply match up those
>merchant cert thumbs with cert thumbs he obtains from other merchants,
>allowing him to build a list of merchants the cardholder has attempted to
>make purchases from].


Sorry I haven't been keeping track of the SET but why would a merchant
need this info in the first place??? If anything one would think that this
would be client driven not server driven (ie the client queries the
merchant for the hash of his cert to see if the client already has a copy
or not). I am not quite sure what they are trying to accomplish by this
unless what you consider a "flaw" is realy a "feature by design"?

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNGn49o9Co1n+aLhhAQF7GAP+K2xbLQCLvFaR4nBpOOT3BfGoTtMikOvs
nhm3n4J3ALkIUtReRcwi3rc4q9/+TUK3Rq8gfVzFBCsFyDyAQLVMUCFBn7Ybja+j
qdloRfG4Tw2ueMOyaaO2/ao03s9tgOfP2Cfa0CwyScQI8BWMMoeKBongeSYZgMsm
bqGEG+XXyr4=
=rAEt
-----END PGP SIGNATURE-----

William H. Geiger III writes:
> In <199711121751.JAA01757@slack.lne.com>, on 11/12/97
>    at 09:51 AM, Eric Murray <ericm@lne.com> said:
> 
> >[details: according to the spec the cardholder sends to the merchant
> >thumbs (SHA1 hashes) of all the certs in the cardholder's cert cache.
> >Since this will contain certs from merchants the cardholder has made
> >purchases from in the past, a merchant could simply match up those
> >merchant cert thumbs with cert thumbs he obtains from other merchants,
> >allowing him to build a list of merchants the cardholder has attempted to
> >make purchases from].
> 
> 
> Sorry I haven't been keeping track of the SET but why would a merchant
> need this info in the first place??? If anything one would think that this
> would be client driven not server driven (ie the client queries the
> merchant for the hash of his cert to see if the client already has a copy
> or not). I am not quite sure what they are trying to accomplish by this
> unless what you consider a "flaw" is realy a "feature by design"?


Sending them all from the client is bit more efficient-
this way the client sends one message with all its thumbs and
the merchant side sends back any certs that are required.

The other way, the merchant would send the thumbs for all
the required certs, then the client would send a list of thumbs
for certs it doesn't have, then the server would send those certs.

So this way there's one less round trip required.

Both methods are equally open to attack unless the list of thumbs is MAC'd.


-- 
Eric Murray  Chief Security Scientist  N*Able Technologies  www.nabletech.com
(email:  ericm  at  lne.com   or   nabletech.com)          PGP keyid:E03F65E5

-----BEGIN PGP SIGNED MESSAGE-----

Robert Hettinga writes:
 > 
 > Personally, I'm becoming convinced that SET is practically Ptolmaic in it's
 > complexity. You can get money from point A to point B, but you have to go
 > through a lot of epicycles to get there.

Agreed, SET is overengineered hogwash.

 > 
 > Unfortunately, I think that no MIS manager will get fired for using SET, and
 > it'll take a serious demonstration of a security breach before people will
 > listen to anything else. At least until someone demonstrates a transaction
 > protocol which is, say 3 orders of magnitude cheaper...

Perhaps... OTOH, SET is SO bad that it will be impossible to deploy,
probably forcing everyone away from it anyway.

As far as a better protocol, it's already designed, implemented, and
running quite nicely in our software. :-)

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNGoA5C/fy+vkqMxNAQGjGAQA2fnFE85Mr2QdYuZoHwhOgioTzp833POY
EaOWT3z2eNhSBz8EkoVI6m/X/og6oqc5fHZnG7ys8jjVTcQX2rPiaIE26qDgisPx
2EiV7IW+Rul4hi9+dzQKfloXbKakANRtrT8CNYWGRmsstKQd4hXVsVmdrV4USRe5
b55K7Di7pqk=
=IeCU
-----END PGP SIGNATURE-----