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-----
participants (5)
-
Doug_Tygar＠cs.cmu.edu -
Eric Murray -
Jeremey Barrett -
Robert Hettinga -
William H. Geiger III