Re: the limits of crypto and authentication
Only problem is that cell phones have become so utterly complex (hosting several processors and a plethora of software components) that it will never become the trusted device that we once thought it could be... Personal it is though Jaap-Henk On Sat, 09 Jul 2005 18:56:22 -0700 James A. Donald [EMAIL PROTECTED] writes: -- Ian Grigg [EMAIL PROTECTED] In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. Such a device sounds like a cell phone. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 5nMEZ3YWGEUKZWzEprv/E7vI+8j9jzBNX8GWiJiO 4nb4BSDrVGLfq42fHktPRSAfFO3N0uGBnezGRNWrS - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. Jaap-Henk On Sat, 09 Jul 2005 20:38:38 +0200 Florian Weimer [EMAIL PROTECTED] writes: You send the pass code in an SMS to the user's mobile phone, together with some information on the transaction. (If the SMS delay is a problem, use a computer-generated phone call.) The pass code is then entered by the user to authorize the transaction. This will eventually break down, once PCs and mobile phones are integrated tightly, but in the meantime, it's reasonably secure even if the client PC is compromised. I'm not sure if users will accept it, though. What's worse, the costs for sending the SMS message (or making the phone call) are so significant that it's unrealistic we'll see widespread use of such technologies. (Manually transferring cryptographic tokens which depend on the transaction contents seems to be infeasible, given the number of bits which must be copied.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 -- -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day Radboud University Nijmegen |Gry Rocket (w) www.cs.ru.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/53132 | (f) +31 24 3653137 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
ref: http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication one of the issues raised in the x9.59 business rule case was whether there are sufficient PANs (account numbers) to be able to temporarily be able to issue two PANs for every account; one PAN useable against account in X9.59 transactions and one PAN useable against account in non-X9.59 (legacy, non-authenticated) transactions. there was some issues raised about having multiple PANs pointing at the same account ... but that is in wide-spread use already as normal business practice. Note that during any transition to secure x9.59 transaction ... the worst case scenario is that there would be two PANs in existance for every account. The issue raised whether the account number space is large enuf to have two PANs for every account (note that if this turns out to be a real issue ... it would also be a much larger problem for one-time-PAN implementations ... where you might have hundreds of PANs mapped to the same account number). The problem for an X9.59 transition is actually somewhat less severe. Part of the current PAN strategy is stacked against re-use of a PAN. However, in the x9.59 transition case, I would claim that PAN re-use is much less of a problem 1) re-use of any PAN for x9.59 use automatically disables the PAN for all non-x9.59 use (if the PAN had some lingering legacy attachment ... that woulc be disabled as soon as it was assigned for x9.59 use) 2) re-use of a previously assigned x9.59 PAN for x9.59 use ... could happen on somewhat accelerated schedule ... since the previous x9.59 PAN use would have been associated with a public key that was no longer active. the lingering issue as dangling business process associated with old transactions that are bound to a specific PAN. re-use of PANs need to after any such dangling business processes have been assured to have expired. the upside is that any transition to x9.59 would then give the consumer some choice and/or control ... strict use of x9.59 transactions would give the consumer some protection against most skimming, havesting and data breach threats and vulnerabilities. such a consumer might then want any non-x9.59 PANs to have very strict use limits (akin to some of the customer specified limits available on pin-debit accounts ... or what is available on dependent cards). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Jaap-Henk Hoepman wrote: Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. there is also the EU bank challenge/response scenario (requires two-way communication protocol chatter). the customer initiates a transaction ... on the internet or even over (voice) phone. the bank responds with a challenge which is entered into a calculator sized device and the display comes back with the response. the response then is either typed or the keyboard (or the phone keypad). basically it is a relatively dumb pin-pad sleave that a chipcard slips into ... some old post visiting the company that makes the devices: http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
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
Re: the limits of crypto and authentication
If you had two products ... both effectively performing the same function, one you already had deployed, which was significantly cheaper, significantly simpler, and significantly faster, which one would you choose? I was told that one of the reasons SSL took off was because Visa and/or MC told merchants they would for the time being treat SSL as card-present, in terms of fraud penalties, etc. If this is true (anyone here verify? My source is on the list if s/he wants to name themselves), then SSL/SET is an interesting example of betting on both sides. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
On Jul 14, 2005, at 8:13 PM, Rich Salz wrote: If you had two products ... both effectively performing the same function, one you already had deployed, which was significantly cheaper, significantly simpler, and significantly faster, which one would you choose? I was told that one of the reasons SSL took off was because Visa and/or MC told merchants they would for the time being treat SSL as card- present, in terms of fraud penalties, etc. If this is true (anyone here verify? My source is on the list if s/he wants to name themselves), then SSL/SET is an interesting example of betting on both sides. On the contrary, merchants were (and maybe still are) being charged MOTO (mail order/telephone order) rates for using SSL. Even SET was going to charge MOTO rates until just before it was finalized. The payment card companies weren't getting enough interest for SET and decided to offer card-present rates to get more interest in SET. SSL took off because it was free, in over 90% of the browsers (Netscape own the browser market then), and it was easy to integrate into shopping carts. As a merchant, basically your only cost was your VeriSign cert. But you are correct in that the payment card companies were in an interesting position: on one hand they charge higher rates for using SSL but on the other hand, the perception was that something more secure than SSL was needed. One other point, SET did NOT require certs for the consumers. The client-merchant protocol supported clients without certs. Respectfully, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Rich Salz wrote: I was told that one of the reasons SSL took off was because Visa and/or MC told merchants they would for the time being treat SSL as card-present, in terms of fraud penalties, etc. If this is true (anyone here verify? My source is on the list if s/he wants to name themselves), then SSL/SET is an interesting example of betting on both sides. I only know of MOTO ... the original netscape e-store and merchants processed thru the original payment gateway. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 SSL originally just provided for webserver authentication. while we mandated mutual authentication for SSL between webservers and the payment gateway (before there was even a specification for mutual authentication). Information about the respective other end-point were preloaded in the respective servers ... so the use of digital certificates was purely an artificial artifact of the existing code base. However, normal merchant webserver operation for SSL was purely one-sided authentication ... there was no form of client authentication that would provide any kind of basis for either cardholder-present or card-present. There is something for being there first, starting late 94 ... http://scout.wisc.edu/Projects/PastProjects/NH/95-03/95-03-27/0016.html remember what Verisign was called before it was renamed Verisign? SET prototype shows up early fall 96 with dedicated demo systems appearing at conferences late '96 (dedicated demo systems taking 30 seconds elapsed time to perform transaction). Two of the major risks and vulnerabilities that have been discussed are evesdropping on data-in-flight ... and data breaches at merchant databases ... old post on security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 both SSL and SET addressed confidentiality of data-in-flight. Neither SSL nor SET addressed data breaches at merchant databases. Going on in parallel with webservers doing MOTO transactions thru the payment gateway you also found some number of webservers doing emulated POS terminal dialup operations (also MOTO transactions). Some number of vendors were peddling software that was originally developed to run on PCs and autodial merchant processor (effectively emulated POS terminal dial) ... software originally targeted for hotels, casinos, etc. ... from long ago and far away: Date: Sat, 24 Feb 1996 17:08:01 -0500 (EST) From: H Morrow Long [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Draft SET Standard/specs now online at MC and Visa The new SET (Secure Electronic Transaction) draft standard/ specs are now online at VISA and Mastercard for downloading. The draft docs were just released yesterday (Feb 23). The docs are available in Word and Postscript file formats for Windows, Unix and the Mac. Check out: http://www.mastercard.com/set/set.htm http://www.visa.com:80/cgi-bin/vee/sf/standard.html?2+0 The Web pages also have information on how to subscribe to the set-discuss mailing list. - Morrow - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Anonymity is a concern to me, too, but I suspect that it is hard to get anonymity in a credit card transaction using current means, even if the merchant isn't online. Pseudonymity, perhaps. Can we not aim higher than merely doing as badly as current systems do? I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, however, it may be difficult to eliminate the need for the issuer to track transactions. However, given the way I've described the protocol, it would be possible to use a variant on it for digital cash purses without the merchant being impacted. It isn't clear to me, though, who would issue such things in the current environment. You never know who might do stuff if its easy for them to do so. Make it hard, and you can be more confident they won't. But I'm glad to hear we're not in opposition on this. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
a harder problem for early stage web merchants was getting a merchant financial institution the merchant financial institution that sponsors a merchant for payment transactions ... takes financial responsibility for that merchant. the standard procedure was to send somebody out to the retail brickmorter and do an asset inventory ... to see if the merchant went under ... that there would be enuf assets left to help cover the merchant financial institutions losses. retail web merchants might have nearly zero assets ... they leased time with a webhosting and fulfillment was outsourced ... so there was no onhand inventory and effectively no assets. if they were totally unsuccesful ... then the merchant financial institution would have little outstanding transaction financial liability. there were cases where merchant financial institution would try and cancel a merchant as it became succesful ... since the outstanding transaction liability for the merchant financial institution could be going way up ... with no increase in assets to cover the finanical institution's outstanding liability. for such high risk merchants ... the merchant financial institution discount might actually be bigger than the MOTO discount ... or any difference between MOTO and card-present. early web merchants tended to be existing brickmorter operations where web MOTO (mail-order/telephone-order) transactions were not separated out from non-web MOTO transactions. there were all sorts of strategy meetings in the '95 time-frame, brain storming about how to get a bank's financial risk department to even approve purely web merchant signup (and MOTO vis-a-vis card-present wasn't a primary issue). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
On 7/14/05, Anne Lynn Wheeler [EMAIL PROTECTED] wrote: remember what Verisign was called before it was renamed Verisign? Digital Certificates International, Inc. Did you consult for First Data Corp. at the time?
Re: the limits of crypto and authentication
Aram Perez wrote: One other point, SET did NOT require certs for the consumers. The client-merchant protocol supported clients without certs. there was a later set-lite w/o certs for clients ... but the original specification had client certs as part of the core process. note that the SET consumer certificate was *NOT* a x.509 identity certificate ... because of stated reasons regarding privacy and liability. It was a relying-party-only certificate that basically contained the account number and the public key http://www.garlic.com/~lynn/subpubkey.html#rpo It was also, not a true PKI ... since it didn't have any certificate administration and management infrastructure. It was purely a *certificate manufactoring* process (a term we had coined to differentiate the early SSL certificate operations from what had been defined for a PKI operation). Further, the statement was that they could get by w/o a PKI operation ... since it was purely a certificate manufactoring process using relying-party-only certificates (containing just the public key and account number), the business process could be managed by deactivating the account number in the *real*, real-time, online operation. quicky search engine for set-lite: http://iugsun.cs.uni-dortmund.de/lehre/datenschutz/material/folien/dsss2004-5-ecommerce.pdf http://www.it.murdoch.edu.au/~smr/honours/admin/info/DavidsProposal.html http://www.indiainfoline.com/bisc/ieps.html http://www.networkworld.com/archive/1999/61423_03-22-1999.html from above: When MasterCard and Visa unveiled technology for secure Internet electronic commerce transactions two years ago, they thought it would take over the world. But while Secure Electronic Transaction (SET) has made inroads in Europe and Asia, it has faltered badly in the U.S. Faced with technical and business obstacles to SET, MasterCard and Visa are now coming up with alternatives to SET - SET Lite and Merchant-originated SET (MOSET). 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. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Ram A Moskovitz wrote: Did you consult for First Data Corp. at the time? some reference: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 little later, we got to review chaum and brand stuff. brand had done a take-off on chaum's stuff so that if somebody double-spent (aka fraud) ... the financial institution could determine who did it (basically a form of solving two equations in two unknowns). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, Wasn't that a goal of SET? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Rich Salz [EMAIL PROTECTED] writes: I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, Wasn't that a goal of SET? Some of it was, yah. I don't claim that any of this is original. The problem with SET was that the protocol was far too complicated to implement (hell, the spec was nearly too heavy to lift), and it was proposed well before people even had USB connectors on their computers, let alone cheap USB card interfaces. I think people threw out the baby with the bathwater, though. The general idea was correct. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Rich Salz wrote: Wasn't that a goal of SET? there was an observation that SET possibly wouldn't divulge your account number until the merchant had been determined to be some entity registered as a merchant (akin to the SSL domain name infrastructure certificates ... if a spoofed site didn't use SSL until you hit the pay/checkout button, what is the probability that the spoofed site provide a URL that matched some valid certificate that they did have). note, however, some of the participants even got confused about this issue. note that there are a lot of merchant business processes that require the account number ... and therefor you can't prevent the merchant from possessing the account number. some might be tempted to observe that there is a kind of conflict of interest ... using the same value for authentication purposes as well as widely needed for a large number of other purposes (akin to designing a system that widely uses your userid a basis for normal functioning ... as well as making your userid also your password). some past posts where the SET issue of divulging account number was disucssed. http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption 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 I thot the goal of SET was to maximize the number of RSA-ops being executed in the world. When I first obtained a copy of the initial SET specification, I did a RSA-ops profile and a business operation profile. An acquatance had done some work on the BSAFE library and improved the performance by a factor of four times. I got him to run timing tests on the SET RSA-ops profile across a number of different machines. I then communicated the results to a number of people that were part of the SET group. The reply from various members of the SET group was that the numbers were obviously one hundred times too slow (the correct answer should have been that the numbers were four times too fast). Six months later when the first prototype SET code was running ... their measured numbers were within a couple percent of my earlier profile numbers (aka the BSAFE enhancements had been given back to RSA). One possible observation was that SSL work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 was already providing account number confidentiality for *data-in-flight*. The significantly much more complex, and heavyweight SET would have needed to provide countermeasures for significantly more threats and vulnerabilities ... like security for *data-at-rest* (aka data breaches) in order to make any headway against the (SSL) incumbant. I also made a couple comments to the SET group about the heavy-weight nature of SET (apparently the RSA-ops being one hundred times more onerous than they had anticipated). Effectively, the SET RSA-op profile was symmetrical but the standard processing is quite asymmetrical. In effect, the massive datacenters that are currently processing credit card transactions would have needed their computational facilities increased by at least one hundred times (SET RSA-op profile was looking at tens of seconds per transaction while many of these datacenters measure their thruput in thousands of transactions per second ... a four orders of magnitude gap). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
On Jul 14, 2005, at 6:23 AM, Perry E. Metzger wrote: Rich Salz [EMAIL PROTECTED] writes: I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, Wasn't that a goal of SET? Some of it was, yah. I don't claim that any of this is original. The problem with SET was that the protocol was far too complicated to implement (hell, the spec was nearly too heavy to lift), and it was proposed well before people even had USB connectors on their computers, let alone cheap USB card interfaces. I think people threw out the baby with the bathwater, though. The general idea was correct. While the SET protocol was complicated, it's failure had nothing to do with that fact or the lack of USB on PCs. You could buy libraries that implemented the protocol and the protocol did not require USB. IMO, the failure had to do with time-to-market factors. In the late 90s, when ecommerce was just at it's infancy and you took the risk of setting up a web store, were you going to wait you could integrate a SET toolkit into you web site and until your customers had SET wallets installed on their PCs before selling a product? Or were you going to sell to anyone who used a web browser that supported SSL? It was very simple economics, even if you had to pay VeriSign $400 for your SSL certificate and pay Visa/MasterCard a higher fee. Respectfully, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Pat Farrell wrote: On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote: I think that by eliminating the need for a merchant to learn information about your identity ... Wasn't that a goal of SET? As I recall, the goal of SET was to have a standard that was not invented by CyberCash. (I may be biased, I worked at CyberCash at the time). This is incorrect. The main politics around SET was the artificial `merger` of iKP (from IBM Mastercard) and STT (from Visa and MS). As far as I remember, CyberCash were involved but choose not to. They also did not disclose their protocol like the other proposals. I may be wrong about the CyberCash role, though, it was a while, and I don't think it matters so much... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Aram Perez wrote: While the SET protocol was complicated, it's failure had nothing to do with that fact or the lack of USB on PCs. You could buy libraries that implemented the protocol and the protocol did not require USB. IMO, the failure had to do with time-to-market factors. In the late 90s, when ecommerce was just at it's infancy and you took the risk of setting up a web store, were you going to wait you could integrate a SET toolkit into you web site and until your customers had SET wallets installed on their PCs before selling a product? Or were you going to sell to anyone who used a web browser that supported SSL? It was very simple economics, even if you had to pay VeriSign $400 for your SSL certificate and pay Visa/MasterCard a higher fee. can you say that that processing overhead was on the order of 20-30 seconds (on completely unloaded infrastrucutre ... demos at shows and conferences ... can you imagine what a little bit of queuing load would do to it?) ... if merchants thot SSL was onerous ... just imagine what SET did to the infrastructure and it provided effectively no additional improvement over fraud vis-a-vis effectively only addressing the confidentiality of account numbers as data-in-flight. SSL was the encumbant, was significantly less complex and significantly lighter weight (even tho most merchants decided that it was too heavy except for the credit card portion) and provided effectively the same amount of anti-fraud as SET. If you had two products ... both effectively performing the same function, one you already had deployed, which was significantly cheaper, significantly simpler, and significantly faster, which one would you choose? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Pat Farrell wrote: As others have said, and in the spirit of the subject of this thread, SET failed for many reasons, many of them economic. There was little effort made to bribe the merchants, I think there was talk of a 26 basis point change in the discount rate, which the banks thought was huge and the merchants thought was noise. What really killed it was the billions it would have cost all the banks to issue and manage all the certificates. this was some of the confusion between identification and authentication. The SET effort was smart enuf to not do x.509 identity certificates and instead do relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo and they even made comments about the enormous privacy and liability issues raised with x.509 identity certificates. They also avoided doing any sort of PKI infrastructure ... aka the management and administration of the certificates. The effectively were doing the same stuff as the original SSL domain name certificates ... for which we coined the term certificate manufactoring (to differentiate from a certificate administrative and management operation). They basically said that the certificate only contained the account number ... and the account number could be turned-off at the issuing financial institution ... making it redundant and superfluous to also have to have a separate infrastructure for invaliding the certifcate. So they have an online infrastructure with real-time transactions and real-time operation of the real information. It is an extremely trivial additional step to show that then the certificates themselves are redundant and superfluous. The cost of the certificates only become an issue if you are talking about having to pay a trusted third party, $100/annum for every certificate. So we can take this in incremental steps. 1) you have the consumer's financial infrastructure register the public key. they then can generate and issue a relying-party-only certificate to the consumer (containing the consumer's public key and account number). 2) there was work started in X9 financial standards body on compressed certificates. Even the SET relying-party-only certificate overhead ran 4k-12k bytes. The typical iso8583 financial message is on the order of 60-80 bytes. Even the trivial SET relying-party-only certificates represented a payload bloat of one hundred times (besides the RSA-ops inflating processing overhead by 3-4 orders of magnitude). 3) Because of the enormous payload bloat contributed by the certificates, the digital signature processing was being truncated at the internet boundary and a standard iso 8583 message was then generated with a flag turned on indicating that the internet had validated the digital signature. The merchants had an incentive to see that flag turned on since that was the basis on which a lower discount was calculated. At an ISO meeting in europe ... one of the association network people presented statistics on the number of iso 8583 messages that they found with the flag turned on and they could prove that no digital signature technology could have been involved 4) I presented an argument that a valid compressing technology is to eliminate all fields from the (certificate) contents that were known to already be in possession of the relying party. Since it could be proved that all fields in the SET relying-party-only certificate were already on file with at the consumer's financial institutions ... it would be possible to eliminate all fields from the relying-party-only certificates. If they preferred, i would start describing the process of appending zero byte digital certificates as an alternative to describing certificateless digital signature operation http://www.garlic.com/~lynn/subpubkey.html#certless 5) The consumer's financial institution could effectively use the existing business processes for registering PINs as a mechanism for registering public keys. That is not known to be an expensive business process. A consumer's financial institution then could set up a website where the consumer could later retrieve their (redundant and superfluous relying-party-only) digital certifcate. There is some integrity constraints here ... but since the purpose of a digital certificate is to spray it all over the world ... there isn't a lot of confidentiality constraints (i.e. it doesn't hurt a lot if other people pick up your digital certificate). However, since both the public key and the digital certificate would already be on file ... you could require people to perform digital signature authentication before picking up their redundant and superfluous digital certificate. This does have an unfortunate downside since it highlights that consumer digital signatures can be validated by onfile public keys w/o needing digital certificates 6) there were lots of comments that leaving all the PKI gorp in the hands of trusted third parties was a trade-off of the
Re: the limits of crypto and authentication
At 2:48 PM -0700 7/12/05, Bill Stewart wrote: It'd be nice if good crypto and authentication methods could create a market for improved products It can, it does, and it's called significantly reduced risk-adjusted transaction cost in financial econ-speak. Maybe the marketing droids need to come up with a 50's-era secret ingredient, a cryptographic Floristan(tm), but frankly, I don't think they're going to have to. Frankly, however, I think that reduced transaction costs creates *dis*economies of scale by reducing barriers to market entry and thus firm-size, and reducing proprietary anything to fungible graded commodities traded in so-called (see your Econ 51 textbook) perfectly competitive markets, instead of monopolistic competition (brands, trademarks, patents and other artifacts of batch-driven industrial production), which is what we have today. Think of it as the financial equivalent of grey-goo, or, better, blood-music, or whatever. Linux vs Novel/MS-DOS/Unix(tm) for instance, or, again better, IETF-esque protocols replacing various proprietary secret-sauce bit-slinging methods. BTW, Perry, I think that as we get to online instantaneity for every transaction, we eventually converge to pre-underwritten pre-encrypted pre-authenticated quasi-anonymous unique value-bits circulating on public networks: internet bearer financial cryptography protocols, in other words. Cheers, RAH But you *knew* I was gonna say *that*, right? -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 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 Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Well, whether you like the cell phone as the out-of-band second-factor, you can now unlock your front door with it... http://weblog.physorg.com/news2334.html --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. This would preclude, for example, offline transactions. As I've said before, I totally agree that the only way to go is to have signatures made on such a device, but I do think its very important to design the thing right - and the above isn't sounding right to me. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Ben Laurie [EMAIL PROTECTED] writes: That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. Tedium is something that computers do very well. They don't care about how much work they have to do. The only issue is whether we induce too many serialized public key operations, and thus too much delay. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? Yup. I want that for a variety of reasons. In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. That's the case already. Only the issuing bank knows if the account has any credit left in it, after all. This would preclude, for example, offline transactions. We used to live in an era where offline transactions were important. Now that you can get online literally anywhere, and now that merchants pretty much are required to check card validity and funds availability online anyway, that's no longer an interesting concern. I can't think of the last time I was involved in an offline transaction -- even folks at street fairs can now afford GPRS and similar communications for their veriphone (and similar) units. As I've said before, I totally agree that the only way to go is to have signatures made on such a device, but I do think its very important to design the thing right - and the above isn't sounding right to me. It sounds right to me, because it puts the trust relationships in all the right places. The merchant trusts the accepting bank that it will be paid. The accepting bank trusts the card network, the card network trusts the issuing bank. The issuing bank and cardholder have a bilateral relationship, too. If we keep the cryptographic exchanges purely in correspondence with the trust relationships, and we get rid of reliance on third party certification of public keys entirely, we also fix most of the trouble in the system. By the way, I note as an aside that this also means (in my opinion) that certificates are no longer an interesting technology for payments protocols, because in a purely online environment, you never need a third party x.509 certificate in the course of the payments protocol itself when there are no offline components of the protocol and all relationships are bilateral. The overwhelming disadvantage is deployment complexity, but given deployment (ha, what an assumption on my part!) the system would work very cleanly indeed. The user would not have to worry about his PC being infected or his merchant deploying a dishonest terminal (though theft of a token + beating the PIN out of the user would still be an issue). By not responding to requests that do not come from the issuing bank specifically encrypted for the token, you reduce (though of course not eliminate) the possibility of side channel attacks or inducing buffer overflows and such in the token, as well as depriving intermediate entities of privacy damaging information. The issuing bank would not have worry about the origin of the token's signature -- it could be reasonably assured that, short of physical attacks on the tokens (which would happen but be infrequent), the signature came from the token, and no information that would permit independent payment authorizations has been left with the merchant or card processor. Overall, I think such things are a win. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
In Brazil there's alot of trojans similar to the one Steven mentioned, almost all of them targeted at diferent national banks. A while back they worked as external pop-ups as we named them. That is they appeared on top of the browser appearing visually like when you are asked for your credencials by the bank (although many times they ask for all your data including ssn). Now a days they are more advanced, we have seen trojans lately that closes the browser and opens a window just like IE and then navigates the banks site inside, when it comes to entering the credencials it shows more fields to fill in than normal. They often come with keyloggers too to rob your pin number as you enter it. That made the banks use virtual keyboards, entering the PIN with the mouse on screen, to avoid entering PIN numbers via the keyboard. Then the bad guys started using mouse loggers that captures a tiny square with every mouse click. The captured data are sent via smtp, ftp or via an http post. The latest trick is to encrypt the captured data with AES although the key is fixed in the code ;-) Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. -- Mads Rasmussen Security Consultant Open Communications Security +55 11 3345 2525 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. Tedium is something that computers do very well. They don't care about how much work they have to do. The only issue is whether we induce too many serialized public key operations, and thus too much delay. Sure, but multiple physical devices aren't my computer's problem, they're my problem. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? Yup. I want that for a variety of reasons. In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. That's the case already. Only the issuing bank knows if the account has any credit left in it, after all. This would preclude, for example, offline transactions. We used to live in an era where offline transactions were important. Now that you can get online literally anywhere, and now that merchants pretty much are required to check card validity and funds availability online anyway, that's no longer an interesting concern. I can't think of the last time I was involved in an offline transaction -- even folks at street fairs can now afford GPRS and similar communications for their veriphone (and similar) units. There are reasons to want to do offline transactions and to not have intermediaries that go beyond mere connectivity. Anonymity being the one of most concern to me, but I'll wager there are others. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: By the way, I note as an aside that this also means (in my opinion) that certificates are no longer an interesting technology for payments protocols, because in a purely online environment, you never need a third party x.509 certificate in the course of the payments protocol itself when there are no offline components of the protocol and all relationships are bilateral. my impression of the 3party x.509 identity certificate model of the early 90s ... was that every person would pay $100/annum for their identity certificate grossly overloaded with personal information. the certificate model has a design point from the early 80s, offline email, where the receiver dials their local (electronic) postoffice, exchanges email and hangs up. they then are faced with dealing with first time email from total strangers. the x.509 identity certificates, grossly overloaded with personal information ... were targeted at (hopefully) including at least one piece of personal information (about the sender), that the receiver might find useful when dealing with total stranger. moving into the early 90s, with a model where everybody would have $100/annum identity certificates ... the apparent business model would be that all established business relationships would be done away with ... and people would only be performing spontaneous business transactions with total strangers ... supported by the x.509 identity certificates. For instance, rather than depositing money in an established bank account you would spontaneously contact a total stranger to accept your large sums of money. The exchange of x.509 identity certificates with total strangers would provide sufficient trust and integrity to safegard your large sums of money. Moving into the mid-90s, some institutions started to realize that such x.509 identity certificates represented huge privacy and liability issues and there was some implementations by financial institutions of relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which only contained a public key and some sort of database lookup index (as unique information) along with a lot of CPS and other types of certification accounting gorp. In this situation, it was trivial to show that such relying-party-only certificates were redundant and superfluous: the relying party already has all the necessary information on file, which invalidates the certificate design point of providing letters of credit type of information between two strangers in first time communicate (where there is no other recourse for information about the party you are dealing with). of course, there was a side issue in these payment protocols from the period. the typical iso8583 payment message is on the order of 60-80 bytes. the typical overhead for even the relying-party-only certificates (attached to every payment message) was on the order of 4k-12k bytes ... leading to an enormous payload bloat of one hundred times for something that was totally redundant and superfluous. In general, the design point of x.509 identity certificates were to turn all transactions (regardless of kind, even the most lightweight authentication transactions) into heavyweight identification operations. You would even find some govs. passing legislation that was oriented towards mandating x.509 identity certificate be appended to every digital signed transaction ... even when you might be looking at purely a lightweight something you have authentication operation. misc. recent posts on the subject: http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Ah, I see what you mean. Sadly, I don't think there is much to be done about that, but I think that (personally) I'd only end up with two of the things. If they can be made credit card sized, I don't see this as worse than what I have to carry now. there are a couple of issues. in some ways if institutional-centric physical tokens were to be succesful ... you would start to see one in lieu of ever pin, password, /or shared secret ... for every possible type of relationship requiring authentication. there was an issue in the early e-commerce days http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 a lot of the funding for the early commerce server work was targeted at a mall type environment/experience ... where a large outsourcer would provide electronic mall space for retail stores. The apparent assumption was that the physical distance metaphor addressed by shopping malls, would be carried over into the internet. however, the basic characteristic of the internet the world-wide-web already was obliterated physical distance concepts. the issue then was why would a metaphor designed to address physical distance limitations, carry over into an environment where physical distance was a meaningless concept. the issue with many of the existing issued cards and tokens are that they are institutional-centric, one per institution. this could approach the DRM/copy-protect approach of the mid-80s ... where applications were being shipped with unique floppy disks that were required to be mounted anytime the application was executed. an operation with one or two such applications wouldn't be so bad ... but can you imagine that being succesful today? where you might have hundreds of such floppy disks and requirement to have a dozen such floppy disks concurrently mounted in a single floppy drive ... and possibly having to select and exchange floopy disks (from a pile of hundreds) several times a minute. i contend that the physical store checkout and payment model ... where you are physically performing checkout and can likely do only one such at a time has analogies to the shopping mall physical metaphor model ... and it starts to hit limitations when you translate that into internet electronic metaphor with the possibility of multiple things going on concurrently - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Anonymity is a concern to me, too, but I suspect that it is hard to get anonymity in a credit card transaction using current means, even if the merchant isn't online. Pseudonymity, perhaps. Can we not aim higher than merely doing as badly as current systems do? I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, however, it may be difficult to eliminate the need for the issuer to track transactions. However, given the way I've described the protocol, it would be possible to use a variant on it for digital cash purses without the merchant being impacted. It isn't clear to me, though, who would issue such things in the current environment. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
At 09:29 PM 7/9/2005, Perry E. Metzger wrote: The Blue Card, so far as I can tell, was poorly thought out beyond its marketing potential. I knew some folks at Amex involved in the development of the system, and I did not get the impression they had much of a coherent idea of what the technologies would be used for other than creating marketing buzz. On the other hand, only a short time before that, Apple's iMac created a whole marketing revolution and set of spinoff products and revitalized the company by coming out with a semi-transparent blue-green case that effectively packaged the Reality Distortion Field, and they were able to maintain the effect over several years by the radical introduction of several other semi-transparent colors. It'd be nice if good crypto and authentication methods could create a market for improved products, but hey, if blue-green translucent dancing pigs gets customers, the marketing people have done _their_ job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
On Tue, Jul 12, 2005 at 02:48:02PM -0700, Bill Stewart wrote: | At 09:29 PM 7/9/2005, Perry E. Metzger wrote: | The Blue Card, so far as I can tell, was poorly thought out beyond its | marketing potential. I knew some folks at Amex involved in the | development of the system, and I did not get the impression they had | much of a coherent idea of what the technologies would be used for | other than creating marketing buzz. | | On the other hand, only a short time before that, | Apple's iMac created a whole marketing revolution | and set of spinoff products and revitalized the company | by coming out with a semi-transparent blue-green case | that effectively packaged the Reality Distortion Field, | and they were able to maintain the effect over several years | by the radical introduction of several other semi-transparent colors. | | It'd be nice if good crypto and authentication methods | could create a market for improved products, | but hey, if blue-green translucent dancing pigs gets customers, | the marketing people have done _their_ job. In light of the ID theft drumbeat, companies that don't require your SSN have a marketable edge. I'm waiting for some to use it. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: the limits of crypto and authentication
Amex Blue was a market success in the sense that its ROI exceeded expectations, rational and otherwise. It yielded thousands of new accounts at a cost of acquisition far less than average, even when taking into account the Windows driver support calls and the discarded readers. That said, you might have been able to achieve the same result with a gold stickie except the geeks that were the majority of the new accounts probably would have peeled it off and grumped. The winner will be the dude that can make authentication into a Mustang. Like it or not, Amex Blue pointed the way. IMHO as always. Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, July 09, 2005 6:32 PM To: cryptography@metzdowd.com Subject: Re: the limits of crypto and authentication Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the failure of Amex Blue is due to poor timing and the requirement for hardware on the end-user's PC. At the time of it's introduction ecommerce and online banking were just getting started and consumers were more worried about whether the store was real or not than having their card stolen. It wasn't until identity theft and the rush of disclosures due to SB1386 et al here in the US that people cared about security and privacy (in some way). What I can't understand is why Visa and Amex haven't started to push their one-time credit card software solutions again - this time as protection for your privacy. I would think people would be much more receptive to it now. Little has changed, except the market's perception of the risk of using credit cards online. Amex actually pulled their program in 2004, IIRC. [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. this is also the EU finread standard http://www.garlic.com/~lynn/subpubkey.html#finread which has a certified display and certified pin-pad. it was for token reader external to the PC ... so that what is displayed is what gets signed ... and the PIN entry isn't easily compromised. This still somewhat assumed standard 7816 card w/o its own display and pin-entry. the issue in x9.59 design http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy was that it was possible for the relying party to get certified integrity information about the hardware token at the time the public key was registered and recheck that certified integrity information (binding to the public key) on every digitally signed transaction ... the EU finread standard didn't provide for the similar level of assurance. x9.59 allowed (but didn't mandate) that the environment, in which the signing took place, could also digitally sign the transaction. this could provide the relying party a binding not only between the integrity of the token doing the digital signing but also a binding between the environment that the digital signing took place and the integrity of that binding. The base EU finread terminal scenario provides for a standard for high integrity digital signing environment. However, it doesn't provide for any proof to the relying party that such a terminal was actually used for any specific transaction. Having the public key of the EU finread terminal registered along with the associated certified integrity level of that environment then if such a terminal was also to digitally sign the transaction, the relying party could do some risk assesement both on the integrity of the token performing the digital signing (for authentication purposes) and the integrity of the signing environment (terminal). If the display, pin-entry, and authentication token were tightly bound in the same device then when the relying party registered the public key for authentication purposes they would also register the associated integrity characteristics of the hardware token (for authentication purposes) as well as the display and pin-entry (for integrity related to the signing environment). The issue here is that the relying party is fundamentally interested in the overall risk of the transaction ... which is composed of a lot of individual integrity characteristics. Relating this to the old style x.509 identity certificate grossly overloaded with personal information a relying party ... can have done an authentication binding regarding the public key (i.e. don't necessarily need to have the identity of the person such know that the authentication indicates the entity is the one that is authorized to performed the related operations w/o having across the line from auhentication into identification and grossly confusing the difference between the two). One the relying party has done the straigth-forward authentication binding for a hardware token and a public key the really interesting charactistics for the relying party is all the integrity characteristics surrounding a transactions. To some estent, the PKI identity-centric focus have tended to distract relying parties from the more fundamental risk issues regarding integrity characteristics of performing the transaction. One an entity is registered as enabled for performing valid transactions (which can be a purely authentication operation w/o getting grossly confused about the difference between authentication and identification), then issues of certification interest to a relying party are the integrity characteristics of the authentication events (and the enormous concentration by PKI bodies on confusing identification with authentication tends to be a pure distraction to the risk assesement of the operations). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. Steve, thanks. Not really much of surprise, is it? Clearly, a user who lets malware onto his/her PC, e.g. a VBscript in this case, has lost control and is open to such attacks. But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. Yes, I know, this is far from the current situation, with corrupted PCs (Zombies) being a very large fraction (around a third?)... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the difference now is the number of vendors entering the market, the variety of solutions ( and their relative security), and demand outside of Europe. When we started in mid-2001, we were looking at the existing hardware guys and that is it. Now there a handful of venture-backed software players with different solutions all targeting the banking market, which didn't exist then. We have not seen any interest in our two-factor solution from Germany or any country where they have some form of two-factor authentication. Perhaps this is similar to the US corporate market where companies that have tokens aren't very interested in switching to save money - the CSO only takes risk in switching and sees no personal benefit in reducing costs (my theory at least) so there's no true vetting, only beating up the current vendor for a slightly better deal. Thus your banks will still complain that the price of mailing paper is too high, which of course it is when compared to software tokens. We are, however, seeing interest from US and South American banks and the numbers are huge and we will be very aggressive in pricing. We also see that we are competing against companies that use IP address verification, secure cookies and other things that are readily compromised, but apparently easy to roll-out and maintain and inexpensive. So, we have to compete against those substitutes that don't even use cryptography or two-factor authentication but would be better termed as fraud detection and prevention. Florian Weimer wrote: * Nick Owen: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. I doubt this is true. In Germany, we already use some form of two-factor authentication for Internet banking transaction (account number/password and a one-time password for each transaction). Yet banks are desperately looking for alternatives because distributing those one-time password lists is too expensive (!). To me, this was quite surprising because it's just one sheet of paper every 200 transactions or so. Even worse, this scheme has failed, and there are successful attacks in the wild (involving compromised client PCs). Right now, time-dependent tokens do help, but only because you outrun the other guy. The real-time requirements imposed by them are not a fundamental obstacle to the attackers, and even now, the way they route the money makes it very hard to detect things in real-time (at least on the money side). Well, you can imagine my surprise when Howard Schmidt praised two-factor authentication as a solution to our current problems at the FIRST 2005 conference. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
* Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com In the foreseeable future, this approach won't stop fraudulent transactions because the one-time password does not depend on the transaction content. Anything which doesn't display essential parts of the transaction contents to the end user over a trusted channel is doomed to failure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Anti-fraud] Re: the limits of crypto and authentication
On Sun, 10 Jul 2005, Amir Herzberg wrote: But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. I disagree. Limited authority is the best way to prevent such malware from being installed (and, if installed, from causing harm). The premise that all software can be divided into categories of good and evil is a deeply flawed foundation on which to build security. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
[EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it works is that for transactions with a combined value over the default floor limit of NZ$2.5K you have to use an additional PIN sent via SMS to a pre-configured number to authenticate the session. The PIN authenticates that particular session (not just one transaction), with a fee of NZ$0.25. It's not perfect, obviously, but that was seen as the best tradeoff between cost, user convenience, and security. grumbleA few years ago I wanted to do this out-of-band authentication as a research project, and at the time couldn't find anyone interested in it; now they've paid an arm and a leg for it themselves, sigh/grumble. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Nick Owen wrote: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted? two-factor authentication per se, isn't necessarily the panecea. pin-debit ... has a magstripe card as something you have and a pin as something you know. as recently mentioned, compromised ATM /or POS machines have been able to skim the magstripe and the pin enabling creation of counterfeit cards and fraudulent transaction. in x9.59, http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy a hardware token can digitally sign the actual financial transaction. this would be single factor, something you have authentication. skimming and/or harvesting the transaction and/or transaction log files http://www.garlic.com/~lynn/subpubkey.html#harvest doesn't enable either counterfeit cards and/or fraudulent transactions. the issue of a PIN, in conjunction with the magstripe card for two-factor authentication, was a countermeasure against lost/stolen card. However, skimming as a threat, is able to capture both the PIN and the card magstripe information, enabling fraudulent transactions. a single-factor authentication hardware token (something you have) that digitally signs the transaction is sufficient countermeasure against skimming and harvesting. Enforced PIN-debit ... i.e. where the magstripe can't be used w/o the PIN ... turns out to be a countermeasure against some of the transaction log harvesting (the type of data breach stories recently in the press) ... since the PIN information isn't normally carried in the transaction log. The issue with the transaction log is that there are several other merchant business processes that require access to transaction information. The issue with magstripe and PINs ... is the threat and vulnerability model effectively is a replay attack ... static data that can be relatively easily recorded and repeated in fraudulent transactions (and/or used to create counterfeit magstripe). A single factor authentication hardware token that digitally signs that transactions, is countermeasure against attacks recording static data for replay-type attacks. Adding a PIN or biometric authentication to a hardware token for two factor authentication doesn't improve the countermeasure to skimming and harvesting attacks. The PIN or biometric authentication in conjunction with a hardware token is primarily countermeasure for lost/stolen token ... not countermeasure for skimming/harvesting replayable information. There is has been a separate issue with the use of pin/passwords shared-secrets http://www.garlic.com/~lynn/subpubkey.html#secrets for something you know authentication, is people having large number of different accounts each, supposedly requiring unique something you know shared secrets. The estimate is that possibly 30percent of the debit cards have PINs written on them. The issue is basic human factors and blindly adding something you know shared secret as a second authentication factor doesn't necessarily significantly improve the situation. so you are possibly faced with having to fundamentally rework some of the authentication landscape to compensate for well documented human short comings. So two possible pieces for reworking this portion of the authentication landscape (for human factor shortcomings with proliferation of large number of shared-secrets) 1) certified tokens that accept PINs for operation. the PINs are shared-secrets since they don't travel past the token. The token is in the person's possession and the PIN is just for activating certified token operation. this can contribute to the person being able to initialize all tokens to the same PIN 2) transition from institution-centric tokens to person-centric tokens ... aka rather than every institution in the world issuing a token ... and each token possibly requiring a single PIN, people can acquire some small number of personal tokens and register their personal tokens for valid something you have authentication at different institutions. A big issue in the recent data breach stories with respect to security PAIN acronym P ... privacy A ... authentication I ... integirty N ... non-repudiation is that many of the infrastructures tend to have relatively strong integrity requirements for their business records. this protects the infrastructure business operations. however, they tend to have much lower privacy requirements ... in part because the large number of business processes that require access to those records. furthermore, the privacy threats and vulnerabilities isn't directly against the infrastructures
Re: the limits of crypto and authentication
On Saturday 09 July 2005 23:31, [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? There was no market failure - Amex Blue was an outstanding success that sent waves of astonishment through the credit card industry. Everyone was talking about how stunningly successful it was - how it had broken the laws of account creation by actually acquiring new accounts in the millions instead of cannibalising existing accounts. (I recall a number of 4 million?) You may be thinking that the usage of the smart card being a total and complete flop was in some way correlated with the market success, but it was quite the reverse - the smart card usage was a complete and utter failure for the obvious reasons, but the program itself was fantastically successful. iang -- Advances in Financial Cryptography, Issue 2: https://www.financialcryptography.com/mt/archives/000498.html Mark Stiegler, An Introduction to Petname Systems Nick Szabo, Scarce Objects Ian Grigg, Triple Entry Accounting - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
[EMAIL PROTECTED] writes: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? The Blue Card, so far as I can tell, was poorly thought out beyond its marketing potential. I knew some folks at Amex involved in the development of the system, and I did not get the impression they had much of a coherent idea of what the technologies would be used for other than creating marketing buzz. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Given such a structure, however, you can know when the device displays Pay 53.22 euros to amazon.fr for book X that this is precisely the transaction you are authorizing, and that the communication will not authorize any other transaction, its interception will not permit the authorization of any other transaction, and no replay of the transaction is possible. However, you need both the end to end communication and the hardware token with built in display and keyboard. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
another characteristic of the PKI x.509 identity certificate activity (besides attempting to create mass world-wide confusion regarding the difference between identification and authentication ... and trying to get govs. to mandate that x.509 identity certificates, grossly overloaded with personal information had to be appended to even the most simple of authentication transactions) was trying to cause a great deal of confusion about the difference between *digital signatures* and *human signatures*. some of this possibly was semantic confusion because both of the terms; *digital signature* and *human signature* contain the word *signature*. nominally a digital signature is the use of a private key to encode a message/document hash. the relying party then recalculates the message/document hash, uses the corresponding public key to decode the digital signature, and compares the two hash. if they are equal, the relying party assumes: 1) the message/document hasn't been altered (since the digital signature) 2) something you have authentication, aka the originator has access and use of the private key. the base technology is asymmetric key cryptography (what one key encodes, the other key decodes). the business process of public key, identifies one key as publicly available. the other key is kept confidential and never divulged. the integrity of something you have authentication can be improved by deploying secure hardware tokens where the key pair are generated in the token and the private key never leaves the token (improving the probability that the private key is never divulged). now, normal *human signature* implies read, understood, agrees, approves, and/or authorizes. The normal *digital signature* is purely a something you have authentication process implying none of the characteristics of a *human signature*. In fact, a series of my pasts posts on *dual-use attacks* was specifically with using the same private key to apply digital signatures to random data (as part of authentication operations) and digital signatures to non-random data (assuming human signature characteristics). Somewhat in support of helping create world wide confusion about the differences between *digital signatures* and *human signatures* (in addition to creating world wide confusion about the difference between authentication and identification), the PKI x.509 digital certificate standard also defined a non-repudiation bit. For some number of PKI-oriented payment protocols in the mid-90s, there was the specification of digital certificates with the non-repudiation bit turned on. Supposedly, if a merchant could demonstrated any valid digital certificate with the non-repudiation bit turned on (for the customer's public key), then the burden of proof in any dispute would have shifted from the merchant to the consumer. The threat/vulnerability was 1) the PKI-oriented protocols provided no mechanism for proving which certificate had been originally attached to the transaction 2) supposedly the non-repudiation bit was capable of turning any digital signature operation (regardless of the environemnt in which the signature had been performed) magically into a *human signature* carrying the attributes of read, understood, agree, approve, and/or authorized. So the PKI x.509 identity digital certificates were targeted at 1) turning every transaction in the world (even the most trivial authentication operation) into a heavy duty identification operation (with attached x.509 identity digital certificates carrying enormous amounts of personal information) 2) allowing anybody that could produce a valid digital certificate (for the associated public key) with the non-repudation bit on, to magically turn all associated *digital signatures* into *human signatures* (even digital signatures that had been presumably been performed on random data for purely authentication operations). since that time, the use of the certificate-based non-repudiation bit has been severely depreciated (many people coming to realize that it takes more than magical PKI bits to turn *digital signatures* into *human signatures*). there were some that started to realize that the PKI x.509 identity certificate model represented severe privacy and liability issues. The initial quickdirty fix were the relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo containing just public key and some sort of database lookup index. The issue here is that it is trivial to demonstrate that such relying-party-only certificates are redundant and superfluous if the relying party already has all the information, then the relying party can directly look up the necessary information (including registered public key as well as all integrity characteristics that might be associated with that public key ... and the last thing they need are redundant and superfluous relying-party-only digital certificates).
Re: the limits of crypto and authentication
Peter Gutmann wrote: [EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it works is that for transactions with a combined value over the default floor limit of NZ$2.5K you have to use an additional PIN sent via SMS to a pre-configured number to authenticate the session. The PIN authenticates that particular session (not just one transaction), with a fee of NZ$0.25. It's not perfect, obviously, but that was seen as the best tradeoff between cost, user convenience, and security. grumbleA few years ago I wanted to do this out-of-band authentication as a research project, and at the time couldn't find anyone interested in it; now they've paid an arm and a leg for it themselves, sigh/grumble. Back when we used to run O2's (then Cellnet) web stuff, we used to authenticate user accounts by sending random words to their phone. This was so long ago I can't remember when it was, but certainly 5 years. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: However, you need both the end to end communication and the hardware token with built in display and keyboard. there is two issues for digital signatures ... 1) something you have authentication and 2) proof to the relying party as to the integrity level of the operations it is possible to establish the integrity level of the hardware token at the time the public key is registered ... and then possibly track the token integrity level as it degrades over time (because of technology advances). in the EU finread standard case http://www.garlic.com/~lynn/subpubkey.html#finread it assumed that the display/pinpad and the token were separate. the the case of relying party being able to evaluate the risk of the transaction ... then it would actually need the separate display/pinpad to also digitally sign the transaction (and also having previously registered the finread terminal public key and integrity level). the co-signing by the separate display/pinpad was allowed for in x9.59 financial transaction standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/supubkey.html#privacy but not mandated. when the display, pinpad, and token are all a single device ... then there would only be a requirement for a single digital signature ... representing both the something you have authentication as well as the integrity level of the signing environment. in the *human signature* realm there is the aspect of many financial point-of-sale termainals where there is requirement for some sort of manual, human interaction that demonstrates some sort of agreement, approval, and/or authorization of the transaction (in addition to the authentication operation). frequently this is a display of the transaction requiring the person to hit the agree/yes button ... as a separate operation from any authentication operations. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
In message [EMAIL PROTECTED], Nick Owen writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. How does the user know which transaction is really being authenticated? (I alluded to this in a 1997 panel session talk; see http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm ) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
To validate the transaction, a receipt could be sent to the user encrypted by the server's public key. If the receipt is correct, the user enters their PIN to 'sign' the transaction. I'm assuming an asymmetric authentication system here outside the browser. The attacker would have to steal the user's private key, their PIN and the server's private key, correct? I know that if the PC is compromised anything is possible, but I think this raises the bar significantly - perhaps to an unprofitably level. Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Nick Owen writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. How does the user know which transaction is really being authenticated? (I alluded to this in a 1997 panel session talk; see http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm ) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. There is a possible solution against an OLE event driven session rider such as this one. The solution I proposed was to use a variant of CAPTCHA that would add mutual authentication in the mix within the picture. Yes, there are some people that say CAPTCHA can be broken, but in the game of phishing, it's abouit numbers, not about silver bullets. The way to get around the porn CAPTCHA problem was to ask something that the user might only know and then ask the user about the activity they are performing. This would stop this instance of E-gold attacks. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
* Steven M. Bellovin: In message [EMAIL PROTECTED], Nick Owen writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. How does the user know which transaction is really being authenticated? You send the pass code in an SMS to the user's mobile phone, together with some information on the transaction. (If the SMS delay is a problem, use a computer-generated phone call.) The pass code is then entered by the user to authorize the transaction. This will eventually break down, once PCs and mobile phones are integrated tightly, but in the meantime, it's reasonably secure even if the client PC is compromised. I'm not sure if users will accept it, though. What's worse, the costs for sending the SMS message (or making the phone call) are so significant that it's unrealistic we'll see widespread use of such technologies. (Manually transferring cryptographic tokens which depend on the transaction contents seems to be infeasible, given the number of bits which must be copied.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
FTR, e-gold were aware of the general makeup of this threat since 1998 and asked someone to look at it. The long and the short was that it was more difficult to solve than at first claimed, so the project was scrapped. This was a good risk-based decision. The first trojans that I know of for e-gold weren't spotted until 12-18 months ago, so it was also a profitable decision. What they are doing now I don't know. In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. iang -- Advances in Financial Cryptography, Issue 2: https://www.financialcryptography.com/mt/archives/000498.html Mark Stiegler, An Introduction to Petname Systems Nick Szabo, Scarce Objects Ian Grigg, Triple Entry Accounting - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted? I also think that the lower end cell phone is now capable of handling the task. While a PC client may not be very secure, it does offer some potential benefits such as auto-validating SSL certs. Whether the carriers will bother with a potential revenue stream in two-factor authentication when they can make more money in ringtones is another question - back to the business model ;). Ian Grigg wrote: FTR, e-gold were aware of the general makeup of this threat since 1998 and asked someone to look at it. The long and the short was that it was more difficult to solve than at first claimed, so the project was scrapped. This was a good risk-based decision. The first trojans that I know of for e-gold weren't spotted until 12-18 months ago, so it was also a profitable decision. What they are doing now I don't know. In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. iang -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Florian Weimer writes: | | It would seem simple to thwart such a trojan with strong authentication | simply by requiring a second one-time passcode to validate the | transaction itself in addition to the session. | | | How does the user know which transaction is really being authenticated? | | You send the pass code in an SMS to the user's mobile phone, together | with some information on the transaction. (If the SMS delay is a | problem, use a computer-generated phone call.) The pass code is then | entered by the user to authorize the transaction. [ Disclaimer -- I advise this company ] Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com [ Disclaimer -- I advise this company ] --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
* Nick Owen: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. I doubt this is true. In Germany, we already use some form of two-factor authentication for Internet banking transaction (account number/password and a one-time password for each transaction). Yet banks are desperately looking for alternatives because distributing those one-time password lists is too expensive (!). To me, this was quite surprising because it's just one sheet of paper every 200 transactions or so. Even worse, this scheme has failed, and there are successful attacks in the wild (involving compromised client PCs). Right now, time-dependent tokens do help, but only because you outrun the other guy. The real-time requirements imposed by them are not a fundamental obstacle to the attackers, and even now, the way they route the money makes it very hard to detect things in real-time (at least on the money side). Well, you can imagine my surprise when Howard Schmidt praised two-factor authentication as a solution to our current problems at the FIRST 2005 conference. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
-- Ian Grigg [EMAIL PROTECTED] In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token that is needed - a trusted device to put the application, display, keypad and net connection on - is even more expensive than the stop-gap two-factor authentication units commonly sold. Such a device sounds like a cell phone. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 5nMEZ3YWGEUKZWzEprv/E7vI+8j9jzBNX8GWiJiO 4nb4BSDrVGLfq42fHktPRSAfFO3N0uGBnezGRNWrS - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
