Re: a fraud is a sale, Re: The bank fraud blame game
re: http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game recent item with the other side of the issue (as opposed to being able to profit when merchants have fraud) Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940 from above: Identity Theft and Fraud cost business $600 billion a year, according to the Association of Certified Fraud Examiners. .. snip ... post from earlier this spring about series of articles essentially appearing simultaneously: http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007 ID fraud down, except credit cards http://www.pcadvisor.co.uk/news/index.cfm?newsid=8280 Survey: ID fraud in U.S. falls by $6.4B http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9010082aintsrc=hm_list Survey Indicates ID Theft May Be Diminishing http://yro.slashdot.org/yro/07/02/01/2127224.shtml Study: ID fraud in decline http://www.securityfocus.com/brief/423 US ID theft losses decline http://www.astalavista.com/?section=newscmd=detailsnewsid=3376 US ID theft losses decline http://www.theregister.com/2007/02/05/us_id_fraud_survey/ and ID Theft Is Exploding In The U.S. ttp://www.informationweek.com/news/showArticle.jhtml?articleID=197800774 ID fraud soaring across the pond http://www.silicon.com/financialservices/0,3800010322,39166236,00.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
R. Hirschfeld wrote: - differential pricing: electronic purse payments are potentially cheaper to process than those of debit cards because they are offline, but consumers find it more convenient to keep money in their bank account than on a smart card and will likely continue to do so as long as it costs no more. (This may become less of an issue if/when all vending machines and parking meters are on the internet anyway.) re: http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game in the mid-90s a number of US financial institutions looked at the economics of the EU chipcard electronic purses (modulo the float issue ... which could be made to work) the issue was that the (much more) expensive chips were being used to offset the significantly higher PTT costs (and/or just plain PTT availability) in Europe. The US could deploy a magstripe authentication card for stored-value ... that did online transactions using much of the existing online point-of-sale infrastructure ... for significantly lower overall infrastructure costs than the EU chip-based offline stored value. The magstripe card basically became a something you have authentication mechanism. The primary trade-off issue was that the US telecom pricing was so much lower than in Europe (and lots of 80s 90s design in europe was being driven by the extremely high PTT costs and/or, in some cases, lack of PTT availability). Note, however, the internet along with various telcom and technology changes around the world have contributed to significantly changing the online/offline economic trade-off considerations. Independent of the online/offline economic issues ... there are some fraud and security issues that could drive towards using chips for a more secure something you have authentication device. however, there is some lingering effects from the older high PTT costs related to chip-based architectures ... and whether there are any residual design features related to (originally) supporting offline operation. Part of this could be seen in the yes card exploits ... where, transaction business rules were left in the chip implementation (as oppsed to the chip being purely an authentication mechanism) ... contributing to the enormous vulnerability increase http://www.garlic.com/~lynn/subintegrity.html#yescard For the float issue with regard to this class of US gift/stored-value cards ... they are sold as merchant cards ... i.e. the kind of gift stored-value cards you see used by coffee shops, video rental, grocery stores, large department stores, etc. Possibly, in part, because they are merchant cards ... as opposed to bank cards ... the associated accounts and balances are pretty far removed from any jurisdiction that might impose payment of interest. misc. past posts about how the large difference in telecom costs drove different solutions http://www.garlic.com/~lynn/aepay11.htm#28 Solving the problem of micropayments http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) http://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money) http://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002d.html#41 Why? http://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested http://www.garlic.com/~lynn/2003h.html#54 Smartcards and devices http://www.garlic.com/~lynn/2004j.html#39 Methods of payment http://www.garlic.com/~lynn/2004j.html#43 Methods of payment http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
R. Hirschfeld wrote: During the course of the CAFE project some commercial electronic purse systems emerged, notably Proton (from Banksys in Belgium, replicated in other counties under other names) and Mondex. These were in many ways less sophisticated than CAFE's system (which was multi-issuer, multi-currency, privacy-respecting, etc.) but had serious commercial backing. For the most part these seem to have stagnated or died. I suspect that getting them to catch on would require drastic measures such as: we had gotten tasked to do a design and costing of mondex implementation in the states (all the transaction processing dataprocessing, sizing capacity and resources, etc) ... and looking at pricing various kinds of mondex related transactions (super brick from mondex international and how it flowed thru the rest of the infrastructure). the conclusion we came up with was that nearly all the financial justification for mondex was in the float. later there were scenarios where mondex international was encouraging deployment in various countries by offering to split the float with the chartered mondex national body (and then it seemed like float offerings were starting to peculate down to financial institutions lower in the mondex hierarchy) then along came an EU statement that mondex (and similar implementations) would only be given a grace period with regard to retaining the float (as a mechanism to underwrite start-up costs) ... but after a period of 2-3 yrs, they were then going to be required to start paying interest on balances carried in the cards. after that, much of the interest(?) seemed to evaporate. separately there were some issues with the chip technology being used in the mondex cards. misc. past posts mentioning mondex. http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS http://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP http://www.garlic.com/~lynn/aadsm20.htm#7 EMV http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards? http://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006 http://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays http://www.garlic.com/~lynn/2002e.html#14 EMV cards http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX? http://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX? http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root http://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure? http://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless) http://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Stefan Lucks [EMAIL PROTECTED] writes: There is a big difference between a TPM providing this kind of service, and Peter's device. The TPM is supposed to be hard-wired into a PC -- so if you are using it to safe your banking applications, you can do banking at one single PC. On the other hand, Peter's device is portable, you can use it to do safe banking from your PC at home, or in the office (only during lunch- breaks with the employer's permission of course), or even at a public internet cafe. To this end, Peter's device would be much more useful for the customer than a TPM ever could be. The portability aspect was one contributing factor, but the other one was more philosophical. As Dan Geer put it recently, If you're losing at a game that you can't afford to lose, change the rules. We've been trying since at least the mid-1960s to move the insecurity away from the computer using an entire industry's worth of gadgets and tricks, and yet we're falling further and further behind the attackers. The external-authorisation-box approach changes the rules and instead moves the computer away from the insecurity. Since the only interface to the computer is feed in blob and retrieve blob, it doesn't matter how insecure the surrounding environment is, there's not much that it can do to the auth-box. BTW, Peter, are you aware that your device looks similar to the one proposed in the context of the CAFE project? See http://citeseer.ist.psu.edu/48859.html I had the feeling it sort of collapsed under its own complexity, the smart card/EMV/etc problem that I referred to earlier. Philipp =?iso-8859-1?q?G=FChring?= [EMAIL PROTECTED] writes: About 50% of the online-banking users are doing personal online banking on company PCs, while they are at work. Company PCs have a special property: They are secured against their users. A user can't attach any device to a company PC that would need a driver installed. The external device emulates a standard USB memory key, to send data to it you write a file, to get data back you read a file (think /dev). There's no device driver to install, and no particularly tricky programming on the PC either. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Philipp � wrote: * An external device that lets the user verify the transaction independently from the PC. The second possiblity has been realized by some european banks now, based on SMS and mobile phones, which sends the important transaction details together with a random authorisation code, that is bound to the transaction in the bank�s database. The user can then verify the transaciton, and then has to enter the authorisation code on the webinterface. (And the good thing is that they succeeded to get the usability so good that it�s more convenient than the previous TAN solution, and the cost increase of SMS compared to paper TANs is irrelevant) So I personally woul declare the online-banking problem solved (with SMS as second channel), but I am still searching for solutions for all others, especially non-transactional applications. How large is this code? The security of this system would seem to rest on the security of mobile phones against cloning. How were mobile phones protected against cloning? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Hi, The second possiblity has been realized by some european banks now, based on SMS and mobile phones, which sends the important transaction details together with a random authorisation code, that is bound to the transaction in the banks database. The user can then verify the transaciton, and then has to enter the authorisation code on the webinterface. How large is this code? 5 characters, including numbers and letters. I think you have something like 4 tries to enter a code correctly. (rough estimation: 5^30 = 931322574615478515625 / 4 = 232830643653869628906 , so you have a chance of 1:232830643653869628906 per transaction if you try it 4 times) The security of this system would seem to rest on the security of mobile phones against cloning. How were mobile phones protected against cloning? Well, the security depends on an attacker not being able to infect a specific users´s computer with a MitB and knowing and being able to clone this specific users´s mobile phone at the same time. Peter Gutmann wrote: The external device emulates a standard USB memory key, to send data to it you write a file, to get data back you read a file (think /dev). There's no device driver to install, and no particularly tricky programming on the PC either. Neat idea! It only has the problem that I know several companies already where you have to register your USB-stick, and only registered USB-sticks are allowed on the network ..., but it´s a neat workaround, yes. I think SecurityLayer should be easily adaptable to that concept. Do you already have an demo implementation of that external device, Peter? Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Date: Tue, 3 Jul 2007 10:01:19 +0200 (CEST) From: Stefan Lucks [EMAIL PROTECTED] BTW, Peter, are you aware that your device looks similar to the one proposed in the context of the CAFE project? See http://citeseer.ist.psu.edu/48859.html This has been a more ambitious project, not just supporting secure banking applications at an insecure host PC, but rather a digital wallet. Nevertheless, it may be interesting to study why the project failed (or ended without follow-on projects). I have no quick answer to this question, but as much as I understand, the banks where just not interested in deploying such a device. I guess, it was much too expensive at that time. Instead, in Germany we got the Geldkarte, a simple and very cheap smartcard for payment purposes with neither a display nor a keyboard. The Geldkarte has been around us for about ten years, and, as far as I can tell, hardly any customer is interested in using it. There was a follow-up project called OPERA that implemented a user trial of the CAFE system on the premises of the European Commission in Brussels and two Greek banks in Athens (primarly with smart cards--the infrared wallets worked too but most users didn't have them). During the course of the CAFE project some commercial electronic purse systems emerged, notably Proton (from Banksys in Belgium, replicated in other counties under other names) and Mondex. These were in many ways less sophisticated than CAFE's system (which was multi-issuer, multi-currency, privacy-respecting, etc.) but had serious commercial backing. For the most part these seem to have stagnated or died. I suspect that getting them to catch on would require drastic measures such as: - differential pricing: electronic purse payments are potentially cheaper to process than those of debit cards because they are offline, but consumers find it more convenient to keep money in their bank account than on a smart card and will likely continue to do so as long as it costs no more. (This may become less of an issue if/when all vending machines and parking meters are on the internet anyway.) - coercion: if vending machines and parking meters accepted only electronic purses and not cash, this would drive their adoption. Something like this happened with phone cards--here in this part of the world it is difficult to find a pay phone that still takes coins (except a few at airports). Of course phone cards too have been somewhat obsoleted by ubiquitous cell phones (which might also make good electronic wallets--I believe NTT DoCoMo is/was taking this approach using FeliCa, but I haven't followed how it's doing.). Ray Hirschfeld former Technical Director, CAFE - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: remote-attestation is not required (Re: The bank fraud blame game)
I think you misread what I said about BIOS jumper required install. Ie this is not a one click install from email. It is something one user in 10,000 would even install at all! It would be more like people who program and install custom BIOSes or something, people who reverse-engineer security products. Point is to allow audit of running code by a few paranoid people to keep things honest. The whole point of the separate program space is that it DOES NOT get infested with viruses like windows does. The software running in it will be very very simple, have minimal UI, minimal code etc. Obviously there would be no software connection between anything received in email and changing the software in the physical or virtual software compartment. Adam On Tue, Jul 03, 2007 at 05:53:19PM -, John Levine wrote: I do not believe the mentioned conflict exists. The aim of these calculator-like devices is to make sure that no malware, virus etc can create unauthorized transactions. The user should still be able to debug, and inspect the software in the calculator-like device, or virtual software compartment, just that installation of software or upgrades into that area should be under direct explicit user control. (eg with BIOS jumper required to even make any software change!) In view of the number of people who look at an email message, click on an attached ZIP file, rekey a file password in the message, and then run the program in the file, thereby manually installing a virus, it's way too dangerous to let users install any code at all on a security device. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
a fraud is a sale, Re: The bank fraud blame game
Nicholas Bohm wrote: That is why efforts by banks to shift the risk to the customer are pernicious - they distort the incentive the bank ought to have to get the security right. Yes. Today, under current practice, there's actually a strong incentive to keep existing fraud levels than to try to scrub it out -- fraud has become a sale: in 2001, the last year enough HARD data was available, their revenue stream from fraud was USD $550 Million. That all came from chargeback fees against the merchants. And since it was fraud, the merchants lost the product and the income from the product along with the shipping costs and the chargeback fees. Merchants, of course, have no choice but to pass those losses on to the honest customers. in http://woip.blogspot.com/2007/03/fraud-is-sale.html See also https://financialcryptography.com/mt/archives/000520.html Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[EMAIL PROTECTED] (Peter Gutmann) writes: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. [...] On Sun, 1 Jul 2007, Hal Finney wrote: In theory the TPM was supposed to allow this kind of thing. [...] This was one of the main goals of the TPM as I understood the concept. Unfortunately everyone got focused on the DRM aspect and that largely torpedoed the whole idea. There is a big difference between a TPM providing this kind of service, and Peter's device. The TPM is supposed to be hard-wired into a PC -- so if you are using it to safe your banking applications, you can do banking at one single PC. On the other hand, Peter's device is portable, you can use it to do safe banking from your PC at home, or in the office (only during lunch-breaks with the employer's permission of course), or even at a public internet cafe. To this end, Peter's device would be much more useful for the customer than a TPM ever could be. BTW, Peter, are you aware that your device looks similar to the one proposed in the context of the CAFE project? See http://citeseer.ist.psu.edu/48859.html This has been a more ambitious project, not just supporting secure banking applications at an insecure host PC, but rather a digital wallet. Nevertheless, it may be interesting to study why the project failed (or ended without follow-on projects). I have no quick answer to this question, but as much as I understand, the banks where just not interested in deploying such a device. I guess, it was much too expensive at that time. Instead, in Germany we got the Geldkarte, a simple and very cheap smartcard for payment purposes with neither a display nor a keyboard. The Geldkarte has been around us for about ten years, and, as far as I can tell, hardly any customer is interested in using it. So long -- Stefan Lucks (moved to Bauhaus-University Weimar, Germany) Stefan.Lucks(at)medien.uni-weimar.de -- I love the taste of Cryptanalysis in the morning! -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
remote-attestation is not required (Re: The bank fraud blame game)
I do not believe the mentioned conflict exists. The aim of these calculator-like devices is to make sure that no malware, virus etc can create unauthorized transactions. The user should still be able to debug, and inspect the software in the calculator-like device, or virtual software compartment, just that installation of software or upgrades into that area should be under direct explicit user control. (eg with BIOS jumper required to even make any software change!) The ring -1 and loss-of-control aspects of TPM are different, they are saying that you are not really root on your own machine anymore! In the sense that if you do load under a debugger the remote party can tell this and refuse to talk with you. This remote attestation feature is simply not required for user-centric, user-controlled security. Adam On Sun, Jul 01, 2007 at 11:09:16PM -0400, Leichter, Jerry wrote: | something like a palm pilot, with screen and input and a reasonably | trustworthy OS, along with (as you say) the appropriate UI investment. You do realize that you've just come down to what the TPM guys want to build? (Of course, much of the driving force behind having TPM comes from a rather different industry. We're all happy when TPM can be used to ensure that our banking transactions actually do what the bank says it will do for a particular set of instructions issued by us and no one else, not so happy when they ensure that our music transactions act the same way) Realistically, the only way these kinds of devices could catch on would be for them to be standardized. No one would be willing to carry one for their bank, another for their stock broker, a third for their mortgage holder, a fourth for their credit card company, and so on. But once they *are* standardized, almost the same potential for undesireable uses appears as for TPM's. What's to prevent the movie download service requiring that you present your Universal Safe Access Fob before they authorize you to watch a movie? If the only significant differences between this USAF and TPM is that the latter is more convenient because more tightly tied to the machine, we might as well have the convenience. (This is why I find much of the discussion about TPM so surreal. The issue isn't the basic technology, which one way or another, in some form, is going to get used. It's how we limit the potential misuses) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Hi, The problem I found (during my research for http://www.cacert.at/svn/sourcerer/CAcert/SecureClient.pdf ) for Smartcards and other external devices for secure banking is the following: About 50% of the online-banking users are doing personal online banking on company PCs, while they are at work. Company PCs have a special property: They are secured against their users. A user can´t attach any device to a company PC that would need a driver installed. So any solution like Smartcard-readers, or USB Tokens that needs any special application or driver will not work for 50% of the online-banking customers. (And the banks aren´t that happy about loosing 50% of their customers). So I would say there are 2 possibilities left: * An external device, where you have to enter the transaction details a second time to generate some security code (Can you show me the user that wants to enter each transaction twice?) * An external device that lets the user verify the transaction independently from the PC. The second possiblity has been realized by some european banks now, based on SMS and mobile phones, which sends the important transaction details together with a random authorisation code, that is bound to the transaction in the bank´s database. The user can then verify the transaciton, and then has to enter the authorisation code on the webinterface. (And the good thing is that they succeeded to get the usability so good that it´s more convenient than the previous TAN solution, and the cost increase of SMS compared to paper TANs is irrelevant) So I personally would declare the online-banking problem solved (with SMS as second channel), but I am still searching for solutions for all others, especially non-transactional applications. Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: remote-attestation is not required (Re: The bank fraud blame game)
Adam Back [EMAIL PROTECTED] writes: I do not believe the mentioned conflict exists. The aim of these calculator-like devices is to make sure that no malware, virus etc can create unauthorized transactions. The user should still be able to debug, and inspect the software in the calculator-like device, or virtual software compartment, just that installation of software or upgrades into that area should be under direct explicit user control. (eg with BIOS jumper required to even make any software change!) The ring -1 and loss-of-control aspects of TPM are different, they are saying that you are not really root on your own machine anymore! In the sense that if you do load under a debugger the remote party can tell this and refuse to talk with you. I agree with Adam that the unique and defining aspect of TPM technology is this property that users can prove their machine state without being able to lie about it (modulo hardware attacks etc). This can easily work to the user's detriment - lying is often useful - but could sometimes be to the user's advantage as well - being able to provably tell the truth is useful too. In the case of bank security, the question is whether there is any point in trying to keep users from being able to falsify information about their system configuration and software status. Generally, the user has no incentive to do so. The question is whether attackers could somehow exploit the ability of users to make undetected changes to their secure computing base via social engineering and similar hacks. In the case of the calculator-like device, for example, if it is fully reprogrammable by the user, is there a risk that he could be fooled into hooking it up to his computer in that mode and letting attackers change its workings? Or in the case of a TPM-like chip with an owner override, could he be manipulated into using the override so as to make fake banking software look real? Such questions have two sides to them: the case of a user who does get fooled into taking these actions and is harmed by them; and the case of a user who merely pretends to have gotten tricked like this in order to escape liability for transactions he truly did originate. Defending against the latter class of frauds may give the bank incentive to prefer systems where users cannot override their security, so as to reduce the chance of false repudiations. Looking at the system as a whole, then, there may indeed be a case for financial security systems that cannot be overridden by end users. If such measures reduce the overall costs of fraud in the system, then users do benefit at least indirectly from giving up this degree of control. Sometimes in life, paradoxically, you do better by being able to give up certain options, in a verifiable way. TPM technology's benefits to the user would arise from such paradoxical situations. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Adam Shostack wrote: It may be, indeed. You're going (as Lynn pointed out in another post) to be fighting an uphill battle against the last attempts. I don't think smartcards (per se) are the answer. What you really need is something like a palm pilot, with screen and input and a reasonably trustworthy OS, along with (as you say) the appropriate UI investment. given the recognition of the serial port issues from the earlier, dial-in online banking ... providing a strong motivation to transfer responsibility for all such problems to ISPs (under the guise of moving to the internet) http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game that even the transfer of a little bit of institutional knowledge would have enabled the avoidance of later smartcard reader deployment disasters http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game However, following some of the early yes card deployments http://www.garlic.com/~lynn/subintegrity.html#yescard it appeared to be more of a case where smartcard organizations were very narrowly focused on purely smartcard issues and ignoring everything else. that aspect was highlighted in an early presentation about circumstances surrounding the yes card ... and there was a somewhat uncontrolled comment from somebody in the audience do you mean to say that they managed to spend a billion dollars to prove that chips are less secure than magstripes. misc. old posts/threads mentioning the pc/sc serial port issue smartcard reader deployment disasters http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: a fraud is a sale, Re: The bank fraud blame game
Ed Gerck wrote: Yes. Today, under current practice, there's actually a strong incentive to keep existing fraud levels than to try to scrub it out -- fraud has become a sale: thread from earlier this year ... when over a period of a month or so there were several releases that essentially had fraud declining by 10-15 percent simultaneously with fraud increasing by 200-300 percent. http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007m.html#65 nouns and adjectives this followed an article pointing out that EU financial institutions had something less than 10percent of their bottom line coming from payment transaction operation ... while it was closer to 40percent for US financial institutions. http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization http://www.garlic.com/~lynn/2007k.html#13 IBM Unionization http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based and articles about interchange fee represents the single large expense for some retail merchants http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#72 Free Checking - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: remote-attestation is not required (Re: The bank fraud blame game)
I do not believe the mentioned conflict exists. The aim of these calculator-like devices is to make sure that no malware, virus etc can create unauthorized transactions. The user should still be able to debug, and inspect the software in the calculator-like device, or virtual software compartment, just that installation of software or upgrades into that area should be under direct explicit user control. (eg with BIOS jumper required to even make any software change!) In view of the number of people who look at an email message, click on an attached ZIP file, rekey a file password in the message, and then run the program in the file, thereby manually installing a virus, it's way too dangerous to let users install any code at all on a security device. R's, John PS: Yes, they really do. I didn't believe it either. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Adam Shostack wrote: I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year. re: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game there was a detailed analysis of the 99/00 smartcard deployments ... looking at the most common causes for problems. this was overlapped with opinion claimed to be widely held among consumer financial institutions, that it had been proven that smartcards were not practical in the consumer market segment. for something of a lark, at the annual smartcard conference, i went around to most of the booths asking people at the booth if they were 1) aware that the financial industry considered smartcard not practical in the consumer market segment and 2) what was the cause of the majority of the problems. some of the major deployments selected to be pc/sc compliant ... which at the time only supported serial port attachment ... and did not support USB plugplay. It turned out that the vast majority of smartcard deployment problems in that time-frame had to do with consumers trying to install serial port card readers, consumers that couldn't find the serial port, serial port connections that conflicted with something else, serial port conflicts, serial driver conflicts (large number of BSOD and consumers having to re-install their systems from scratch). there was then a very complex and intricate series of negotiations getting agreement to upgrade pc/sc to support USB plugplay (for starters, responses like why even bother since it had been proven already that smartcards weren't practical in the consumer marketplace ... ignoring for a moment that major factor in the failures was the pc/sc serial port limitations) . There were also things like alternative packaging ... USB keyboard with built-in smartcard reader, display, and PIN-pad cut-out switch ... where keyboard incremental cost was more like $5 (but again, it required PC/SC to be upgraded to USB plugplay) however, by that time, nearly every where you went, there were echos that it (some deployment or another) had proven that smartcards were not practical in consumer environment. Note that it wasn't just consumer limited, there were instances where commercial operations figured that it would be on the order of $500/PC to be able to handle PC/SC serial port smartcard reader attachments. it was in the midst of these particular disasters that you also saw some of the smartcard operating system projects being canceled (again the spreading belief that smartcards were not practical in the consumer market place). All of this can be pretty much put at the doors of the institutions failing to understand some of the fundamental issues attempting to deploy serial-port PC/SC in the PC market place of the time (and/or understand that large driver behind doing the whole USB plugplay thing was the significant problem and issues attempting to deal with the serial port implementation) some number of past posts mentioning the whole PC/SC serial port problems encountered with various attempts at smartcard deployments in the PC/consumer marketplace http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
On Sun, Jul 01, 2007 at 08:38:12AM -0400, Perry E. Metzger wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). I've been thinking this was the way to go for years now. Who hasn't? Oh, I'm sorry -- I meant to say: who, outside of the set of producers and consumers of security snake oil aimed at financial institutions, hasn't? Regular readers will recall the SecurID discussion of about a year ago, when an individual who appeared to be a paid consultant to RSA vigorously put forth the notion that secure devices which required the user to actually do something to authenticate a transaction were _not_ what was needed -- to the shock and awe of most readers of, and writers to, the thread here, at least as I would summarize the discussion. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[EMAIL PROTECTED] (Peter Gutmann) writes: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). In theory the TPM was supposed to allow this kind of thing. The idea was that the OS would support secure applets that could not be molested by legacy software. Only such an applet would have access to your payment information. Some specialized, perhaps customized screen would be displayed by the applet to get you to authorize the final transfer. This was one of the main goals of the TPM as I understood the concept. Unfortunately everyone got focused on the DRM aspect and that largely torpedoed the whole idea. Still we might see it eventually. Research in this direction is still going on, particularly in IBM's Integrity Measurement Architecture[1] and some of the new security extensions to the Xen virtualization software[2]. Hal Finney [1] http://domino.research.ibm.com/comm/research_people.nsf/pages/sailer.ima.html [2] http://xensource.com/files/xs0106_security_print.pdf , also http://www.hpl.hp.com/techreports/2007/HPL-2007-69.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
On Sun, Jul 01, 2007 at 04:01:03PM -0400, Perry E. Metzger wrote: | | Adam Shostack [EMAIL PROTECTED] writes: | On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote: | | Given that all you need for this is a glorified pocket calculator, | you could (in large enough quantities) probably get it made for | $10, provided you shot anyone who tried to introduce | product-deployment DoS mechanisms like smart cards and EMV into | the picture. Now all we need to do is figure out how to get there | from here. | | I'd suggest starting from the deployment, training, and help desk | costs. The technology is free, getting users to use it is not. I | helped several banks look at this stuff in the late 90s, when cost of | a smartcard reader was order ~25, and deployment costs were estimated | at $100, and help desk at $50/user/year. | | Of course, given the magnitude of costs of fraud, and where it may be | heading in the near term, the $50 a year may be well spent, especially | if it could be cut to $25 with some UI investment. It is all a | question of whether you'd rather pay up front with the security | apparatus or after the fact in fraud costs... It may be, indeed. You're going (as Lynn pointed out in another post) to be fighting an uphill battle against the last attempts. I don't think smartcards (per se) are the answer. What you really need is something like a palm pilot, with screen and input and a reasonably trustworthy OS, along with (as you say) the appropriate UI investment. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Ian G.: Banks are the larger and more informed party. But not as far as client-side fraudulent activity is concerned. After all, the attacked systems are not under their administrative control. They need to provide systems that are reasonable given the situation (anglo courts generally take this line, when pushed, I'm unsure what continental courts would do with that logic). We have courts that are traditionally bank-friendly, and courts that aren't. While we do not heavily rely on case law, it's a bit of luck which one sets the precedent (which will eventually help to shape legislation). And what's worse, the situation is so unstable that a case that gets decided in favor of one party might actually end up shifting the risks to the other party in the long run because the environment keeps changing rapidly. Customers aren't in any position to dictate security requirements to banks. And vice versa. It might even happen that we see competion from foreign, EU-based banks that offer transactions without the safeguards German banks have agreed to among each other. We'll see if this increase in convenience turns out to be a major selling point. Unfortunately for the banks, there is a vast body of evidence that we knew and they knew or should have known that the PC was insecure [1]. I think the extent to which end users, hardware and software manufacturers, and ISPs don't care about compromised machines was a real surprise. If there's malware on the PC, it's not just banking that is affected. You'd expect people to do something about it, but no one does without significant external pressure. And if you look closely at which attacks security experts predict (and not just self-proclaimed ones!), and which actually materialize, there are significant differences. These differences are usually mulled over by ambiguous terminology, but the gap is there. So, by fielding a system -- online commerce -- with a known weakness, they took responsibility for the fraud (from all places). They didn't build the Internet, they didn't provide the PC and its software, they don't even run the most-frequented online commerce applications. But in a moment of weakness, they started to take responsibility. And the real difficulties began. For a rare security success story, look at how ISPs manage to sell a completely insecure product which puts their customers at significant risk, and take virtually no blame for it. And technologically, banks are not that different from mail providers. They just pass around messages. Why should they be responsible for their content, if ISPs aren't? Now they are in the dilemma. The customer can't provide evidence of the fraud, because the system fielded doesn't support it (it's login authentication not transaction authorisation). Non-digital crime faces the same problem. You haven't got a cryptographically secured audit trail, either. But clues can still be found. [1] To my knowledge, continental banks knew of the risks and acted in the 90s, then scaled it down because the risks proved overstated. Brit banks knew of the risks and didn't care. American banks didn't care. The American banking system is mainly protected by its obsolescence. It's not an end-to-end transaction system, unlike the European ones. [2] Again, continental banks are shifting to SMS authorisation (dual-channel) ... Brit banks are unsure what to do ... The new APACS standard should be a huge leap forward for the UK. AFAIK, it includes the limited form of transaction signing that is possible within the constraints. Of course, it's still not foolproof, but the non-fools can actually detect a compromised terminal. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Anne Lynn Wheeler: In the mid-90s, financial institutions looking at the internet for online, commercial banking and cash management (i.e. business equivalent to consumer online banking) were extremely conflicted ... they frequently were almost insisting on their own appliance at the business (and low-end of SOHO at least overlaps high-end of consumer online banking). Well, in 1994, German Postbank already had 300,000 online banking customers. (To put this into perspective, there are somewhere around 3 million online customers today, and this was well before the Internet took off in Germany.) On top of that, there were other forms of digital banking that were mainly used by business customers, such as transactions submitted on floppy disks. Various of the PC-based dedicated financial applications go to quite some lengths to compensate for kind of vulnerabilities typically associated with browser activity. For instance, instead of relying on a trusted third party to certify that some remote location really has a valid digital certificate, they have a trusted repository of valid financial institutions. Oh really? In Germany, early digital banking had no cryptographic protection at all. Integrity and confidentiality were inherited from the underlying phone system. There were no end-to-end digital signatures. Nothing. Just a one-time password for each transaction, but the password was not tied to the transaction in any way. This has the added benefit of eliminating the horribly complex and vulnerable PKI-type of operation Except that there aren't any attacks on the browser PKI. That's part of the reason why the certificate prices plummeted. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Florian Weimer wrote: Oh really? In Germany, early digital banking had no cryptographic protection at all. Integrity and confidentiality were inherited from the underlying phone system. There were no end-to-end digital signatures. Nothing. Just a one-time password for each transaction, but the password was not tied to the transaction in any way. This has the added benefit of eliminating the horribly complex and vulnerable PKI-type of operation Except that there aren't any attacks on the browser PKI. That's part of the reason why the certificate prices plummeted. 8-/ re: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game there had been lots of home banking with PCs starting in the 80s. these were dial-up into private bank modem pools (both consumer and business cash management). one of the trade-offs looking at going to internet based operation is the enormous infrastructure savings to financial institutions. in 1995, a presentation by one financial institutions figured that they were supporting something like 65 different software modem drivers (different modems, different operating systems, different platforms, etc). transitioning to internet met that they could eliminate all of that (lots of help desk, lots of serial port issues, lots of hardware issues ... a much smaller precursor to the later smartcard PC/SC serial port disaster). they talked about what trade-offs were with any conversion to internet, the operating system vendors and ISPs would go to a common connectivity operation, bearing the cost of all the online connectivity ... amortized over a lot of online use (not just online banking). This eliminated an enormous cost for online banking. The downside was that the security issues significantly increased. the dedicated financial applications have some similarities to that earlier dial-up phone environment ... except they are using something akin to a controlled SSL encrypted path (tunneled thru the internet) where the remote PC application has preloaded information about the financial institution's server (not needing traditional PKI trusted 3rd party certification authority to provide information about unknown parties). now with respect to weakness of using PKI for such purposes, i've contended in the past that the image/picture authentication helped increase the possibility that the consumer/client was dealing with valid financial institution (that they had previously registered the image/picture with). in that sense, it can be viewed as countermeasure to common phishing attacks ... where clients are convinced to click on some field that takes their browser to some webserver. Given that the attacker can supply both the actual URL and the corresponding SSL digital certificate ... and majority of clients have very weak binding between websites and the corresponding URL (i.e. SSL PKI digital certificate is just checking that the webserver contacted actually corresponds to the supplied URL) then attackers have found an enormous PKI weak link in the current way SSL is deployed (it relies on the user to provide the binding between the webserver they think they are talking to and that webserver's URL ... where SSL PKI is then only providing the binding between a URL and a webserver). As a result, active MITM attacks have happened ... where consumer is convinced to click on a field purported to connect them to their financial institution. The attack actually provides a URL to their own webserver for which they have a valid SSL digital certificate ... then they can transparently pass communication between the real financial institution website and the consumer (with two different SSL sessions connected at the attackers website) ... aka the image/picture authentication stuff is to imcrease the sense of comfort a customer would have that they are actually talking to their financial institution (in view of all the SSL short-comings ... however, it doesn't actually preclude the security attacks). lots of past posts mentioning MITM-attacks http://www.garlic.com/~lynn/subintegrity.html#mitm some specific past posts about MITM-attacks and bank site authentication http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2 http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007 part of this harks back to when were originally called
Re: The bank fraud blame game
| | Given that all you need for this is a glorified pocket | | calculator, you could (in large enough quantities) probably get | | it made for $10, provided you shot anyone who tried to | | introduce product-deployment DoS mechanisms like smart cards and | | EMV into the picture. Now all we need to do is figure out how | | to get there from here. | | | | I'd suggest starting from the deployment, training, and help desk | | costs. The technology is free, getting users to use it is not. I | | helped several banks look at this stuff in the late 90s, when cost | | of a smartcard reader was order ~25, and deployment costs were | | estimated at $100, and help desk at $50/user/year. | | | | Of course, given the magnitude of costs of fraud, and where it may | | be heading in the near term, the $50 a year may be well spent, | | especially if it could be cut to $25 with some UI investment. It is | | all a question of whether you'd rather pay up front with the | | security apparatus or after the fact in fraud costs... | | It may be, indeed. You're going (as Lynn pointed out in another post) | to be fighting an uphill battle against the last attempts. I don't | think smartcards (per se) are the answer. What you really need is | something like a palm pilot, with screen and input and a reasonably | trustworthy OS, along with (as you say) the appropriate UI investment. You do realize that you've just come down to what the TPM guys want to build? (Of course, much of the driving force behind having TPM comes from a rather different industry. We're all happy when TPM can be used to ensure that our banking transactions actually do what the bank says it will do for a particular set of instructions issued by us and no one else, not so happy when they ensure that our music transactions act the same way) Realistically, the only way these kinds of devices could catch on would be for them to be standardized. No one would be willing to carry one for their bank, another for their stock broker, a third for their mortgage holder, a fourth for their credit card company, and so on. But once they *are* standardized, almost the same potential for undesireable uses appears as for TPM's. What's to prevent the movie download service requiring that you present your Universal Safe Access Fob before they authorize you to watch a movie? If the only significant differences between this USAF and TPM is that the latter is more convenient because more tightly tied to the machine, we might as well have the convenience. (This is why I find much of the discussion about TPM so surreal. The issue isn't the basic technology, which one way or another, in some form, is going to get used. It's how we limit the potential misuses) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Peter Gutmann wrote: Given that all you need for this is a glorified pocket calculator, you could (in large enough quantities) probably get it made for $10, provided you shot anyone who tried to introduce product-deployment DoS mechanisms like smart cards and EMV into the picture. That seems exactly to be the problem. Germany's e-health card would be a prime candidate for technology that could boost the use of such pinpads, but unfortunately the card will contain a smart card. (The device has a host of other problems too, don't get me started.) Fun, Stephan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Adam Shostack [EMAIL PROTECTED] writes: I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year. Banks here have been using SMS-based transaction verification for a few years now (although not done very well, sigh) without, apparently, any real problems (I've been trying to get figures for per-transaction costs out of them for a while now, so far without any success). Since the SMS-based system is just a labour-intensive way of doing what I was proposing but using a cellphone instead of a dedicated device, my guess is that the overhead won't be that bad. If it was, the banks wouldn't be doing it now :-). (Using smart cards as a yardstick isn't terribly useful, as I mentioned in my previous message they're really a deployment DoS mechanism, not a solution). I don't think smartcards (per se) are the answer. What you really need is something like a palm pilot, with screen and input and a reasonably trustworthy OS, along with (as you say) the appropriate UI investment. Smart cards are part of the problem set, not the solution set - they're just an expensive and awkward distraction from solving the real problem. What I was suggesting (and have been for at least ten years :-) is a small external single-function device (no need for an OS) that can't be compromised by malware because there's no attack vector for the malware to get at it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Perry E. Metzger wrote: Adam Shostack [EMAIL PROTECTED] writes: On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote: Given that all you need for this is a glorified pocket calculator, you could (in large enough quantities) probably get it made for $10, provided you shot anyone who tried to introduce product-deployment DoS mechanisms like smart cards and EMV into the picture. Now all we need to do is figure out how to get there from here. I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year. Of course, given the magnitude of costs of fraud, and where it may be heading in the near term, the $50 a year may be well spent, especially if it could be cut to $25 with some UI investment. It is all a question of whether you'd rather pay up front with the security apparatus or after the fact in fraud costs... That is why efforts by banks to shift the risk to the customer are pernicious - they distort the incentive the bank ought to have to get the security right. Nicholas Bohm -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285(+44 1279 870285) Mobile 07715 419728(+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Peter Gutmann wrote: Smart cards are part of the problem set, not the solution set - they're just an expensive and awkward distraction from solving the real problem. What I was suggesting (and have been for at least ten years :-) is a small external single-function device (no need for an OS) that can't be compromised by malware because there's no attack vector for the malware to get at it. there is an interesting side story to this involving certification, common criteria, protection profiles, etc. possibly the majority of the smartcard protection profiles have to do with all the problems allowing software/application to be loaded. on the other hand, you can get a common criteria evaluation done on the basic chip ... w/o any application loading ... and being able to show a much higher security level ... than might be possible with any application actually loaded. one of the problems i ran into getting higher than eal4+ for aads chip strawman ... was since everything was built into the silicon at manufacturing time, and nothing could be subsequently loaded ... all the crypto had to also be resident in the silicon. one of the original objectives given for the aads chip strawman was being able to do digital signature in contactless form factor within transit gate elapsed time requirements (very low power and very fast) ... which eventually fell to doing ec/dsa ... and i couldn't get an protection profile definition for ec/dsa higher than eal4+. similar chips ... w/o anything loaded had been able to get eal5+ evaluation (or better) ... but since ec/dsa was built into the chip silicon, it was only possible to get eal4+. the other criteria for aads chip strawman was extremely aggressive cost reduction; i had joked i was taking a $500 milspec part, cost reducing by 2-3 orders of magnitude and at the same time increasing the integrity. part of the aggressive cost reduction was choosing a single function (something you have authentication via chip digital signature) that could be used in a broad range of applications ... and eliminate everything else. misc. aads http://www.garlic.com/~lynn/x959.html#aads other posts in this thread: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
On Sun, Jul 01, 2007 at 11:09:16PM -0400, Leichter, Jerry wrote: | | | Given that all you need for this is a glorified pocket | | | calculator, you could (in large enough quantities) probably get | | | it made for $10, provided you shot anyone who tried to | | | introduce product-deployment DoS mechanisms like smart cards and | | | EMV into the picture. Now all we need to do is figure out how | | | to get there from here. | | | | | | I'd suggest starting from the deployment, training, and help desk | | | costs. The technology is free, getting users to use it is not. I | | | helped several banks look at this stuff in the late 90s, when cost | | | of a smartcard reader was order ~25, and deployment costs were | | | estimated at $100, and help desk at $50/user/year. | | | | | | Of course, given the magnitude of costs of fraud, and where it may | | | be heading in the near term, the $50 a year may be well spent, | | | especially if it could be cut to $25 with some UI investment. It is | | | all a question of whether you'd rather pay up front with the | | | security apparatus or after the fact in fraud costs... | | | | It may be, indeed. You're going (as Lynn pointed out in another post) | | to be fighting an uphill battle against the last attempts. I don't | | think smartcards (per se) are the answer. What you really need is | | something like a palm pilot, with screen and input and a reasonably | | trustworthy OS, along with (as you say) the appropriate UI investment. | | You do realize that you've just come down to what the TPM guys want to | build? (Of course, much of the driving force behind having TPM comes | from a rather different industry. We're all happy when TPM can be | used to ensure that our banking transactions actually do what the bank | says it will do for a particular set of instructions issued by us and | no one else, not so happy when they ensure that our music transactions | act the same way) I don't believe that's so. The TPM guys want to add a variety of controls to extant PC designs to make them secure. I want to add a new device to the mix. | Realistically, the only way these kinds of devices could catch on would | be for them to be standardized. No one would be willing to carry one | for their bank, another for their stock broker, a third for their | mortgage holder, a fourth for their credit card company, and so on. | But once they *are* standardized, almost the same potential for | undesireable uses appears as for TPM's. What's to prevent the movie | download service requiring that you present your Universal Safe Access | Fob before they authorize you to watch a movie? If the only significant | differences between this USAF and TPM is that the latter is more | convenient because more tightly tied to the machine, we might as well | have the convenience. Fair questions. I'm sure I don't have answers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
* Jerry Leichter: OK, I could live with that as stated. But: The code also adds: We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and safeguard your secure information in accordance with this code. If you refuse our request for access then we may refuse your claim. The delay between when you were defrauded and when they request access is unspecified. But if you don't do this, customers can repudiate *any* transaction, even those they have actually issued. In other words, you run into tons of secondary fraud, where people claim they are victims, but they actually aren't. Customers need to provide some evidence that they are actually victims. Just claiming the virus did it can't be sufficient. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[EMAIL PROTECTED] writes: This is *not* a power play by banks, the Trilateral Commission, or the Gnomes of Zurich. It is the first echo of a financial thunderclap. As, oddly, I said only yesterday, I think that big ticket Internet transactions have become inadvisable and will become more so. I honestly think that the party could be over for e-commerce, with eBay Motors as its apogee. I've said roughly the same in a talk on the commercial malware industry that I'll be giving at Defcon next month (normally I'd have the slides online to point people to, but since I haven't given the talk yet you'll have to wait a bit, sorry). The malware industry is several years (at least) ahead of anything that the defenders can produce at the moment. So while US banks still haven't (after years of criticism) taken even the most basic step of using SSL on their login pages, the malware industry has things like the grams eGold siphoner, which defeats any currently known browser security mechanism, all ready to pull out and deploy. While the defenders are struggling to keep up with the latest malware (including some which are effectively undetectable using current technology), the malware authors are getting their UI designers to design flashy-looking skins for their botnet controllers and providing video demos of their products in action. The only countermeasure seems to be to relegate PCs to being untrusted network middleboxes and run the financial portions of all transactions on single-function external devices with built-in pin-pads and displays. (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[EMAIL PROTECTED] (Peter Gutmann) writes: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). I've been thinking this was the way to go for years now. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Perry E. Metzger [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Peter Gutmann) writes: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). I've been thinking this was the way to go for years now. Such a device was actually manufactured in Europe in the late 1990s, unfortunately they couldn't find any bank willing to pay the cost, and it was discontinued. Similar devices are still being made for some vertical-market applications, but they're sold at astronomical prices. Given that all you need for this is a glorified pocket calculator, you could (in large enough quantities) probably get it made for $10, provided you shot anyone who tried to introduce product-deployment DoS mechanisms like smart cards and EMV into the picture. Now all we need to do is figure out how to get there from here. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Peter Gutmann wrote: (The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20). The decade or so old EU FINREAD standard is along this line ... sort of modeled after point-of-sale terminal ... includes its own display and pinpad (countermeasure to keyloggers). lots of past posts mentioning EU FINREAD standard http://www.garlic.com/~lynn/subintegrity.html#finread the actual communications that enter and leave aren't required to be encrypted ... the communication that enter are revalidated on the display ... and the communication that exits is on the order of an x9.59 transaction http://www.garlic.com/~lynn/x959.html#x959 that are armored with digital signature (integrity and authentication) ... misc. posts mentioning naked transaction metaphor http://www.garlic.com/~lynn/subintegrity.html#payments old aads chip strawman from nearly decade ago postulated form factor agnostic ... that could even be added to existing pda/cellphone for a lot less and communicate wirelessly. http://www.garlic.com/~lynn/x959.html#aads in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. part of the detailed end-to-end threat and vulnerability analysis was not only the end-point vulnerabilities but also the large number of business processes that are giving rise to security breaches and data breaches that have frequently made the press. part of x9.59 transaction armoring was that all the transaction information could be readily exposed and still not be useful to attackers for performing fraudulent transactions. This was countermeasure to all the breaches ... regardless of whether insiders or outsiders were involved ... it was recognized that the transaction information had to be exposed in a large number of business processes. Recognizing the impossibility of eliminating all such information exposure ... the x9.59 approach was to eliminate the risk and fraud associated with such exposures (i.e. impossible to eliminate all the breaches ... so eliminate the risk and fraud associated with such breaches). We had previously been called in to consult with small client/server startup that wanted to do payment transactions on their server http://www.garlic.com/~lynn/subnetwork.html#gateway and had this technology called SSL that they wanted to use. The issue in SSL was that it hid the information was moving across the internet ... but left it totally exposed at all other points (and in fact the numerous business processes required such exposure). the x9.59 approach was then to try and eliminate all such exposures ... but to eliminate the risks associated with all exposure of the information (in effect, armoring the transaction w/o requiring the information to be hidden as countermeasure to fraudulent transactions). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
re: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game slight addendas ... 1) EU finread http://www.garlic.com/~lynn/subintegrity.html#finread http://www.garlic.com/~lynn/subintegrity.html#assurance one of the issues that we looked at early on in x9.59 standard ... somewhat related to the EU finread ... was what proof did the financial institution have as to the integrity of the originating end-point (for doing risk assessment purposes). With this motivation, X9.59 standard allowed for multiple digital signatures ... which could include device authentication for finread-like devices (giving some assurance as to the integrity of the originating end-point) 2) liability there appears to be a lot more motivation for improving assurance in the online banking scenario ... say, as opposed to e-commerce and retail payments. in the e-commerce and retail payments ... financial institutions can charge off a lot of fraud to the merchants (buried in things like interchange fees). in the online banking scenario, merchants aren't part of the scene ... just leaving the consumer and the financial institutions as the responsible parties. misc. recent financial news items ... Police arrest three suspects in credit card investigation (fraud) http://www.redlandsdailyfacts.com/news/ci_6262066 ACH Fraud: Clearing House Aims To Clean House http://www.banktechnews.com/article.html?id=200706260ZQVU91V Mobile wallets to replace payment cards - report http://www.finextra.com/fullstory.asp?id=17116 Debit Scam used 'parasite' pin pads http://www.canada.com/vancouversun/story.html?id=773122d5-556f-4b50-87bc-2dc2ad205126k=24040 Shoppers 'easy prey' for debit card fraud http://www.canada.com/vancouversun/news/story.html?id=8e460eed-1bab-4848-9f4c-eefbaecc5ab8 ... in the early aads chip strawman (from the 90s) http://www.garlic.com/~lynn/x959.html#aads form-factor agnostic in user owned pda/cellphone were countermeasure to foreign, unfamiliar POS-terminals that possibly were compromised (i.e. paranoid consumers could have some responsible control over their own devices ... as opposed to POS-terminals at random merchants) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Florian Weimer wrote: * Jerry Leichter: OK, I could live with that as stated. But: The code also adds: We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and safeguard your secure information in accordance with this code. If you refuse our request for access then we may refuse your claim. The delay between when you were defrauded and when they request access is unspecified. But if you don't do this, customers can repudiate *any* transaction, even those they have actually issued. In other words, you run into tons of secondary fraud, where people claim they are victims, but they actually aren't. Customers need to provide some evidence that they are actually victims. Just claiming the virus did it can't be sufficient. Banks are the larger and more informed party. They need to provide systems that are reasonable given the situation (anglo courts generally take this line, when pushed, I'm unsure what continental courts would do with that logic). Customers aren't in any position to dictate security requirements to banks. Unfortunately for the banks, there is a vast body of evidence that we knew and they knew or should have known that the PC was insecure [1]. So, by fielding a system -- online commerce -- with a known weakness, they took responsibility for the fraud (from all places). Now they are in the dilemma. The customer can't provide evidence of the fraud, because the system fielded doesn't support it (it's login authentication not transaction authorisation). The NZ response above is simply not facing up to the facts, it is trying to create an easy way out that (again) shifts the liability to the customer. They now face the question of whether to roll-back online access or to upgrade with some form of dual-channel authorisation [2]. iang [1] To my knowledge, continental banks knew of the risks and acted in the 90s, then scaled it down because the risks proved overstated. Brit banks knew of the risks and didn't care. American banks didn't care. [2] Again, continental banks are shifting to SMS authorisation (dual-channel) ... Brit banks are unsure what to do ... American banks apparently don't care. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote: | | Given that all you need for this is a glorified pocket calculator, you could | (in large enough quantities) probably get it made for $10, provided you shot | anyone who tried to introduce product-deployment DoS mechanisms like smart | cards and EMV into the picture. Now all we need to do is figure out how to | get there from here. I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Ian G wrote: Unfortunately for the banks, there is a vast body of evidence that we knew and they knew or should have known that the PC was insecure [1]. So, by fielding a system -- online commerce -- with a known weakness, they took responsibility for the fraud (from all places). re: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game i.e. to large extent, the existence of the EU finread standard is proof of attempt at countermeasures to the (known) PC integrity weaknesses. the original electronic-commerce adopted the MOTO model (mail-order/telephone-order) which placed significant responsibility on the merchant ... AND there was some presumption that physical goods were involved, shipping to a known address. SSL was used as compensating process, in theory, placing internet-order on level playing field with MOTO. as electronic-commerce deviated more more from the MOTO-model and related assumptions ... there were increasing risks and vulnerabilities. one of the early problems ... in the electronic-commerce genre ... was what to do with purely internet merchants. in the standard MOTO model ... there is consumer financial institution, financially responsible for the consumer and merchant financial institution, financially responsible for merchants (with merchant interchange fees largely underwriting the whole environment). merchant financial institutions tended to sponsor merchants where there were physical assets available for seizure ... equivalent to a month or two of credit card transactions. With every transaction passing thru the sponsoring organization (or its agent), the merchant financial institution had real-time knowledge of the outstanding exposure and risk (and was capable of cutting things off at a moments notice). However, a lot of internet merchants were setting up as purely order fulfillment organizations with little in the way of physical assets. In the early electronic commerce days there were some intense lobbying that went on with the risk management departments in merchant financial institutions. But as mentioned in previous post ... the move to online banking ... removes the merchant completely from the picture (it is no longer the electronic commerce MOTO-model) ... leaving just the end-user and their financial institution as the responsible party. In the mid-90s, financial institutions looking at the internet for online, commercial banking and cash management (i.e. business equivalent to consumer online banking) were extremely conflicted ... they frequently were almost insisting on their own appliance at the business (and low-end of SOHO at least overlaps high-end of consumer online banking). Various of the PC-based dedicated financial applications go to quite some lengths to compensate for kind of vulnerabilities typically associated with browser activity. For instance, instead of relying on a trusted third party to certify that some remote location really has a valid digital certificate, they have a trusted repository of valid financial institutions. This is somewhat the equivalent of the table of certification authority trusted third parties built into browsers ... but instead of table of certifying parties that can certify other parties ... it is table of the actual financial institutions. This has the added benefit of eliminating the horribly complex and vulnerable PKI-type of operation (an don't rely on certification of something totally unrelated to financial transaction operation, but instead rely directly on known financial transaction operation). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
Adam Shostack [EMAIL PROTECTED] writes: On Mon, Jul 02, 2007 at 01:08:12AM +1200, Peter Gutmann wrote: Given that all you need for this is a glorified pocket calculator, you could (in large enough quantities) probably get it made for $10, provided you shot anyone who tried to introduce product-deployment DoS mechanisms like smart cards and EMV into the picture. Now all we need to do is figure out how to get there from here. I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year. Of course, given the magnitude of costs of fraud, and where it may be heading in the near term, the $50 a year may be well spent, especially if it could be cut to $25 with some UI investment. It is all a question of whether you'd rather pay up front with the security apparatus or after the fact in fraud costs... -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The bank fraud blame game
As always, banks look for ways to shift the risk of fraud to someone - anyone - else. The New Zealand banks have come up with some interesting wrinkles oh this process. From Computerworld. -- Jerry NZ banks demand a peek at customer PCs in fraud cases Stephen Bell June 26, 2007 (Computerworld New Zealand) Banks in New Zealand are seeking access to customer PCs used for online banking transactions to verify whether they have enough security protection. Under the terms of a new banking Code of Practice, banks may request access in the event of a disputed transaction to see if security protection in is place and up to date. The code, issued by the Bankers' Association last week after lengthy drafting and consultation, now has a new section dealing with Internet banking. Liability for any loss resulting from unauthorized Internet banking transactions rests with the customer if they have used a computer or device that does not have appropriate protective software and operating system installed and up-to-date, [or] failed to take reasonable steps to ensure that the protective systems, such as virus scanning, firewall, antispyware, operating system and antispam software on [the] computer, are up-to-date. The code also adds: We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and safeguard your secure information in accordance with this code. If you refuse our request for access then we may refuse your claim. InternetNZ was still reviewing the new code, last week, executive director Keith Davidson told Computerworld. In general terms, InternetNZ has been encouraging all Internet users to be more security conscious, especially ... to use up-to-date virus checkers, spyware deletion tools and a robust firewall, Davidson says. The new code now places a clear obligation on users to comply with some pragmatic security requirements, which does seem appropriate. If fraud continues unabated, then undoubtedly banks would need to increase fees to cover the costs of fraud, he says, so increasing security awareness and compliance in advance is probably the better tactic for both banks and their customers. Bank customers who are unhappy with the new rules may choose to dispense with electronic banking altogether, and return to dealing with tellers at the bank. But it seems that electronic banking and in particular Internet banking has become the convenient choice for consumers, Davidson says. The code also warns users that they could be liable for any loss if they have chosen an obvious PIN or password, such as a consecutive sequence of numbers, a birth date or a pet's name; disclosed a PIN or password to a third party or kept a written or electronic record of it. Similar warnings are already included in the section that deals with ATM and PINs for Eftpos that was issued in 2002. There is nothing in this clause allowing an electronic record to be held in a password-protected cache -- a facility provided by some commercial security applications. For their part, the banks undertake to provide information on their websites about appropriate tools and services for ensuring security, and to tell customers where they can find this information when they sign up for Internet banking. One issue we have raised with the Bankers Association in the past is that banks should not initiate email contact with their customers, Davidson says. The code allows banks to use unsolicited email among other media to advise of changes in their arrangements with the customer, but Davidson says they should only utilize their web-based mail systems. It is hardly surprising that some people fall victim to phishing email scams when banks use email as a normal method of communication, and therefore email can be perceived as a valid communication by end users, he says. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
[ This may well be OT; I leave that to the moderator. ] Leichter, Jerry writes: -+--- | As always, banks look for ways to shift the risk of | fraud to someone - anyone - else. The New Zealand | banks have come up with some interesting wrinkles on | this process. | This is *not* a power play by banks, the Trilateral Commission, or the Gnomes of Zurich. It is the first echo of a financial thunderclap. As, oddly, I said only yesterday, I think that big ticket Internet transactions have become inadvisable and will become more so. I honestly think that the party could be over for e-commerce, with eBay Motors as its apogee. Now what I think I know and what I am about to say are all based on hearsay. It is surely wrong in part, but until I am corrected in public it is true enough for lemonade making. The story begins with E-Trade's 10-Q filing of 17 November, which filing is at [1] and elsewhere. In that 10-Q, we have this paragraph: Other expenses increased 97% to $45.7 million and 55% to $101.9 million for the three and nine months ended September 30, 2006, respectively, compared to the same periods in 2005. These increases were primarily due to fraud related losses during the third quarter of 2006 of $18.1 million, of which $10.0 million was identity theft related. The identity theft situations arose from recent computer viruses that attacked the personal computers of our customers, not from a breach of the security of our systems. We reimbursed customers for their losses through our Complete Protection Guarantee. These fraud schemes have impacted our industry as a whole. While we believe our systems remain safe and secure, we have implemented technological and operational changes to deter unauthorized activity in our customer accounts. In other words, remote exploitation of individual customer's computers, doubtless many of them home machines and the laptops of road warriors, eventually lead to a loss for E-Trade that was material enough to appear on the 10-Q. This is not a pumpdump scheme where rubes are snookered into buying some worthless stock. No, it is the actual entry of trades into legitimate trading systems by legitimate users, only with the special case that those users are actually the alien malware using the captured credentials of the legitimate user and entering the trades from the legitimate users' legitimate machine. As I understand it, some of this malware is clever enough to piggyback sessions that are opened by the legitimate user using the much vaunted 2-factor authentication; thus proving that 2-factor auth is a mere palliative. As you are well aware, stealing data is now and everywhere the name of the game, and we have lots of supporting evidence that such theft is fully professionalized. As one example, the APWG has already shown that phishing e-mails are transmitted in a pattern that suggests the transmitters are enjoying a conventional 5-day work week, and there are many other examples. Mike D'Anseglio, Security Program Director at Microsoft, said two interesting things in the last six months: (1) that 2/3rds of all PCs have unwanted software running on them and (2) that state-of-the-art attack tools cannot be eliminated without a clean install from the raw iron up. Well, ironically due to SOx, as the loss amounts get bigger -- and bigger is an assured eventuality -- then those losses will hit Earnings Per Share, and disclosure from the governance and the financial points of view is thus made requirement as those losses are material. Data security has nothing to do with the disclosure as the disclosure is purely driven by the materiality. So, let's do a little math. E*Trade, call symbol ET, has an approximate market cap of $9.66B with approximately 440M shares outstanding. Their estimated annual earning per share is $1.36. Since the fraud loss goes directly the bottom line, an $18M loss in the one quarter is a $0.04 hit in earning per share for the quarter, which on an expected quarterly earning of $0.34/share is a 12% hit to the quarter. This is sufficiently material that it MUST be disclosed, and thus we have, like it or not, data sharing about the impact of digital security lapse -- even if we do not have data sharing about the mechanism of digital security lapse. What some of the banks now want to do is to have you download fresh code each time you go to trade, code that would theoretically protect the bank from the fact that your (user's) machine is almost surely compromised. To get that protection, such ideas as seizing control of the keyboard from the operating system so that keylogging can't happen while trades are being booked, are being floated. Think about what that would mean -- training users to use their Admin privilege to accept ActiveX controls that strip the OS of this or that subsystem, and to do so in the name of security. --dan P.S., The S.E.C. tackling some Estonian clown for $353,609
Re: The bank fraud blame game
| Leichter, Jerry writes: | -+--- | | As always, banks look for ways to shift the risk of | | fraud to someone - anyone - else. The New Zealand | | banks have come up with some interesting wrinkles on | | this process. | | | | This is *not* a power play by banks, the Trilateral Commission, | or the Gnomes of Zurich. It is the first echo of a financial | thunderclap. As, oddly, I said only yesterday, I think that | big ticket Internet transactions have become inadvisable | and will become more so. I honestly think that the party | could be over for e-commerce, with eBay Motors as its | apogee Actually, we don't really disagree with the rest of your message, and I'm not claiming some kind of conspiracy. This isn't really a power play because the banks hold all the cards. Perhaps We're reading different parts of the message I forwarded. Consider: Liability for any loss resulting from unauthorized Internet banking transactions rests with the customer if they have used a computer or device that does not have appropriate protective software and operating system installed and up-to-date, [or] failed to take reasonable steps to ensure that the protective systems, such as virus scanning, firewall, antispyware, operating system and antispam software on [the] computer, are up-to-date. OK, I could live with that as stated. But: The code also adds: We reserve the right to request access to your computer or device in order to verify that you have taken all reasonable steps to protect your computer or device and safeguard your secure information in accordance with this code. If you refuse our request for access then we may refuse your claim. The delay between when you were defrauded and when they request access is unspecified. Who knows what's happened in the meanwhile? Perhaps as a result of my experience, I stopped using on-line banking, and as a result decided it wasn't worth keeping all the (obviously ineffective) software up to date. This is just too open-ended a requirement. All reasonable steps? Just what *are* all reasonable steps? I think I know more than most people about how to keep systems secure, but I'd be at a loss to make a list that could reasonably be called all reasonable steps. (Actually, my list would probably include don't use IE or Outlook. Is that reasonable?) Bank customers who are unhappy with the new rules may choose to dispense with electronic banking altogether, and return to dealing with tellers at the bank. But it seems that electronic banking and in particular Internet banking has become the convenient choice for consumers, Davidson says. On-line access is on its way to become a necessity. EZ-Pass in New York (electronic toll collection) now charges $2/month if you want them to send you a printed statement - go for all on-line access, and it's free. Hardly a necessity yet, but this is a harbinger. (Meanwhile, the percentage of EZ-Pass only lanes at toll plazas keeps rising. You don't *need* to use EZ-Pass, if you're willing to incur significant delays.) The code also warns users that they could be liable for any loss if they have chosen an obvious PIN or password, such as a consecutive sequence of numbers, a birth date or a pet's name; disclosed a PIN or password to a third party or kept a written or electronic record of it. Similar warnings are already included in the section that deals with ATM and PINs for Eftpos that was issued in 2002. There is nothing in this clause allowing an electronic record to be held in a password-protected cache -- a facility provided by some commercial security applications. This is not just wrong, it's *dangerously* wrong. The code allows banks to use unsolicited email among other media to advise of changes in their arrangements with the customer, but Davidson says they should only utilize their web-based mail systems. It is hardly surprising that some people fall victim to phishing email scams when banks use email as a normal method of communication, and therefore email can be perceived as a valid communication by end users, he says. As we've discussed here many times, banks' mail messages are incredibly hazardous, and teach entirely the wrong things. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
