Re: Quantum Cryptography
Alexander Klimov [EMAIL PROTECTED] writes: So what kind of threat models does it address, and what does that say about the kinds of customers who'd want it? 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. Peter. - 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: TPM, part 2
Leichter, Jerry [EMAIL PROTECTED] writes: All your data belong to us. From Computerworld. Trusted Computing Group turns attention to storage I think it's more like There must be some business case for these things somewhere, surely. Let's try a breadth-first search David G. Koontz [EMAIL PROTECTED] writes: Even conservatively there is in the tens of millions of these devices sold, although we have no indication how many were actually used for Trusted Computing purposes. I have a friend who implemented a basic trusted-boot mechanism for a student project, so we have evidence of at least one use of a TPM for TC, and I know some folks at IBM Research were playing with one a few years ago, so that's at least two users so far. Anyone else? Peter. - 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: TPM, part 2
Peter Gutmann wrote: Leichter, Jerry [EMAIL PROTECTED] writes: All your data belong to us. From Computerworld. Trusted Computing Group turns attention to storage I think it's more like There must be some business case for these things somewhere, surely. Let's try a breadth-first search David G. Koontz [EMAIL PROTECTED] writes: Even conservatively there is in the tens of millions of these devices sold, although we have no indication how many were actually used for Trusted Computing purposes. I have a friend who implemented a basic trusted-boot mechanism for a student project, so we have evidence of at least one use of a TPM for TC, and I know some folks at IBM Research were playing with one a few years ago, so that's at least two users so far. Anyone else? There is a project at the University of Applied Science in Hanover working on Trusted Network Computing. http://tnc.inform.fh-hannover.de/wiki/index.php/Main_Page Daniel - 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]
