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]
fyi: UK National Information Assurance Strategy Launched
From: Peter Tomlinson [EMAIL PROTECTED] Subject: National IA Strategy To: [EMAIL PROTECTED] Date: Mon, 02 Jul 2007 16:00:16 +0100 From http://www.cabinetoffice.gov.uk/csia/ : News National Information Assurance Strategy launched http://www.cabinetoffice.gov.uk/csia/national_ia_strategy/index.asp On 27th June, a National Information Assurance Strategy was launched at the IA07 event in Brighton. The annual event is hosted by CESG and brings together key players in industry and government to work in partnership to address the UKs needs in safeguarding information and ICT. The document is available at: http://www.cabinetoffice.gov.uk/csia/national_ia_strategy/index.asp . I haven't read it yet, and so cannot comment, but in a related area I'm puzzled: having heard that Cabinet Office will be supporting Cabinet, I wonder what will happen to all the technical stuff such as Govt Gateway and even CSIA. Peter -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On 07/01/2007 05:55 AM, Peter Gutmann wrote: One threat model (or at least failure mode) that's always concerned me deeply about QC is that you have absolutely no way of checking whether it's working as required. With any other mechanism you can run test vectors through it, run ongoing/continuous self-checks, and (in the case of some Type I crypto) run dual units in parallel with one checking the other. With QC you've just got to hope that everything's working as intended. That alone would be enough to rule out its use as far as I'm concerned, I can't trust something that I can't verify. That's partly true, but there's more to the story. Let's start by looking at the simple case, and then proceed to a more sophisticated analysis: By analogy: -- baseball pitchers should be evaluated on things like ERA, while -- football halfbacks should be evaluated on things like yard per carry, ... and not vice versa. By that I mean: -- the integrity of DH depends fundamentally on the algorithm, so you should verify the algorithmic theory, and then verify that the box implements the algorithm correctly; while -- in the simple case, the integrity of quantum cryptography depends fundamentally on the physics, so you should verify the physics theoretically and then verify that the box implements the physics correctly, ... and not vice versa. Don't complain that you cannot verify the physics the same way you would verify the algorithm; it's not a relevant complaint. There are some beautiful operational checks that *can* be made on a simple quantum crypto system. For starters, you can insert a smallish amount of attenuation in the link, as a model of attempted eavesdropping. The system should detect this, shut down, and raise the red flag; if it doesn't, you know it's broken. == A more sophisticated analysis takes into account the fact that in the real world (as opposed to the ultra-specialized laboratory bench), there is always some dissipation. Therefore any attempt to do anything resembling quantum crypto (or even quantum computing) in the real world uses some sort of error correction. (These error correction schemes are some of the niftiest results in the whole quantum computation literature, because they involve /analog/ error correction, whereas most previous modern error-correcting codes had been very, very digital.) So there is some interesting genuine originality there, from a theory-of-computation standpoint. From a security standpoint though, this raises all sorts of messy issues. We now have a box that is neither a pitcher nor a fullback, but some weird chimera. To validate it you would need to verify the physics *and* verify the algorithms *and* verify the interaction between the two. Needless to say, an algorithm intended for crypto requires much stricter scrutiny than the same algorithm intended for ordinary computation. In particular, the oft-repeated claim that quantum cryptography detects eavesdropping may be true on the lab bench, but it does _not_ follow in any simple way that a usable long-haul system will have the same property. === I agree with Steve that there is a difference between bona-fide early-stage research and snake oil. I did research in neural networks at a time when 90% of the published papers in the field were absolute garbage, such as claims of solving NP-hard problems in P time. -- When there are people who respect the difference between garbage and non-garbage, and are doing serious research, we should support that. -- When people try to publish garbage, and/or package garbage in shiny boxes and sell it to the government, we should call it for what it is. - 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]
Re: TPM hacking
Yes, and that's why we cited Kauer on the page, in Evan's paper, and in the video! http://os.inf.tu-dresden.de/papers_ps/kauer07-oslo.pdf (mainly section 2; section 2.2 describes the TPM Reset trick) - 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]
Using crypto to prevent printer cartridge ink refills
Quoting: Cryptography Research Inc. (CRI), a San Francisco company, is developing chip technology aimed at helping printer manufacturers protect this primary source of profit. The company's chips use cryptography designed to make it harder for printers to use off-brand and counterfeit cartridges. http://news.com.com/Can+cryptography+prevent+printer-ink+piracy/2100-1041_3-6193424.html?tag=news.1 -- Perry E. Metzger[EMAIL PROTECTED] - 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: Quantum Cryptography
At 5:11 PM -0400 7/2/07, John Denker wrote: By that I mean: -- the integrity of DH depends fundamentally on the algorithm, so you should verify the algorithmic theory, and then verify that the box implements the algorithm correctly; while -- in the simple case, the integrity of quantum cryptography depends fundamentally on the physics, so you should verify the physics theoretically and then verify that the box implements the physics correctly, ... and not vice versa. This is a nice, calm analogy, and I think it is useful. But it misses the point of the snake oil entirely. The fact that there is some good quantum crypto theory doesn't mean that there is any application in the real world. For the real world, you need key distribution. For the cost of a quantum crypto box (even after cost reductions after years of successful deployment), you could put a hardware crypto accelerator that could do 10,000-bit DH. Going back to the theory, the only way that quantum crypto will be more valuable than DH (much less ECDH!) is if DH is broken *at all key lengths*. If it is not, then the balance point for cost will be when the end boxes for quantum crypto equals the cost of the end boxes for still-useful DH. Oh, and all the above is ignoring that DH works over multiple hops of different media, and quantum crypto doesn't (yet, maybe ever). --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
