RE: the limits of crypto and authentication
Amex Blue was a market success in the sense that its ROI exceeded expectations, rational and otherwise. It yielded thousands of new accounts at a cost of acquisition far less than average, even when taking into account the Windows driver support calls and the discarded readers. That said, you might have been able to achieve the same result with a gold stickie except the geeks that were the majority of the new accounts probably would have peeled it off and grumped. The winner will be the dude that can make authentication into a Mustang. Like it or not, Amex Blue pointed the way. IMHO as always. Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, July 09, 2005 6:32 PM To: cryptography@metzdowd.com Subject: Re: the limits of crypto and authentication Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
David Alexander Molnar [EMAIL PROTECTED] writes: On Sat, 9 Jul 2005, [UNKNOWN] Jörn Schmidt wrote: less attractive to commit credit card fraud. You are, however, not making it harder. That's why I believe the credit cards companies will indeed have a good, long look at smartcards. Probably not tomorrow or next week but in the near future. Actually, smart cards are here today. My local movie theatre in Berkeley, California is participating in a trial for MasterCard PayPass. There is a little antenna at the window; apparently you can just wave your card at the antena to pay for tickets. I haven't observed anyone using it in person, but the infrastructure is there right now. The contactless systems provide almost zero added user convenience. They're a nice marketing hack by the RFID crowd, but nearly nothing more. Users do not mind withdrawing a token from their wallet and inserting it momentarily into a reader. However, the contactless systems also provide a nice new mechanism for fraud, and with the increasing feasibility of phased array systems, that fraud may soon be possible at considerable distances. So, we've gained very little, other than a nice new app for RFID (RFID being a large scale solution waiting for problems), but at the same time we've lost quite a bit. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: payment system fraud, etc.
| Jerrold Leichter [EMAIL PROTECTED] writes: | In doing this calculation, be careful about the assumptions you make | about how effective the countermeasures will be. The new systems | may be more secure, but people will eventually come up with ways to | break them. The history of security measures is hardly encouraging. | | I'm not sure I agree with that, and I'll tell you why. | | Take the case of NAMPS cell phone fraud. At one time, phone cloning | was a serious problem. The main issue was that people could simply | listen in on call setup and get all the information they needed to do | phone fraud. Once strong crypto was used to authenticate mobiles with | the deployment of digital cellphone networks, mobile phone cloning | fraud didn't just shift around, it almost completely vanished It's very difficult to get a clean experiment on something like this. There is no doubt that going from NAMPS to digital cellphone networks raised the cost of phone cloning or related methods for getting uncharged/mischarged service considerably. However, at the same time, the cost of *legitimate* cellphone service fell dramatically. When you can get 500 minutes of free calls to anywhere in the US for around $40/month (with various hours or calls to customers of the same carrier free on top of that), just how much does it pay to clone a phone? Overseas calls probably provided some incentive for a while, but soon their prices dropped radically, pre-paid, cheap phone cards became widespread (and were probably stolen) - and more recently services like Skype have reduced the cost to zero. The only remaining reason to clone a phone is to place untraceable calls - but you can do as well by buying a pre-paid phone and the number of minutes of airtime you need, paying cash, then tossing the phone. (Using a clone phone for this purpose was getting rather dangerous toward the end of the NAMPS era anyway as the providers started rolling out equipment that recognized the transmission signatures of individual phones. Generally, this was aimed at preventing clones from operating, but it could as well be used to recognize a given clone regardless of the identification info it sent.) A better history to look at might be satellite TV subscription services, which took many generations of allegedly secure cryptography to get to wherever they are today (which as far as I can tell is a non-zero but tolerably low rate of fraud - the cost of entry to satellite TV subscription fraud these days is very high). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the failure of Amex Blue is due to poor timing and the requirement for hardware on the end-user's PC. At the time of it's introduction ecommerce and online banking were just getting started and consumers were more worried about whether the store was real or not than having their card stolen. It wasn't until identity theft and the rush of disclosures due to SB1386 et al here in the US that people cared about security and privacy (in some way). What I can't understand is why Visa and Amex haven't started to push their one-time credit card software solutions again - this time as protection for your privacy. I would think people would be much more receptive to it now. Little has changed, except the market's perception of the risk of using credit cards online. Amex actually pulled their program in 2004, IIRC. [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Perry E. Metzger wrote: Why does the clerk at Blockbuster want to see your driver's license? Because his management has been told, by their bank, that if they do not attempt to verify the identity of credit card users they will risk their business relationship with the bank. Credit card fraud is far too prevalent, DVDs are easily resold, and the bank wants to make sure that they won't get defrauded. Blockbuster also wants to minimize fraudulent use of credit cards (which they end up eating in some instances) and the loss of their property (which will never be returned by someone renting a video with a stolen credit card). the issue is lost/stolen credit cards ... your name is embossed on the plastic and recorded on the mastripe. this provides for the point-of-sale to check for lost/stolen card by attempting the identification process of matching the name on the card with the name on something else. this moves the card out of the relm of authentication into the relm of identification. there was a number of threads (mostly prior to 9/11) about EU privacy directives for making retail electronic transactions as anonymous as cash. basically this involved removing your name from the plastic embossing and magstripe ... so that the card was purely an authentication something you have and didn't wander across the line into identification. lost/stolen card risks then could be contained by deactivating accounts when the owner reported the card lost/stolen part of the issue has been the appearance of skimming/harvesting compromises http://www.garlic.com/~lynn/subpubkey.html#harvest where the crooks didn't actually have to physically steal the card, they could electronically record the necessary information (w/o the owner's knowledge) and then perform fraudulent transactions. The skimming/harvesting compromises can involve tens of thousands of cards ... not just a single card at a time. Also, the fraud period instead of being limited to possibly a few hrs (when the owner reports the missing card), now could extend to a few weeks (since the owner doesn't notice unitl they get around to examining the next statement). The skimming/harvesting threat and vulnerability can magnify the fraud risk by several orders of magnitude (compared to simple lost/stolen). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Perry E. Metzger wrote: If you have a sufficiently good token, you may no longer need to have identification information presented to the merchant, even by the token, to reduce misuse. It is true that the issuer will still know what transactions took place. However, you have at least reduced the number of entities that require proof of your identity and the number that have logs of your activity. this is the EU privacy directive threads that went on (mostly prior to 9/11) and why couldn't they apply in the US also ... aka that electronic retail transactions could be as anonymous as cash. names would be removed from the plastic embossing and magstripe ... and the merchant would not longer have to wander across the line from authentication into identification (attempting to match the name on the card with other credentials). when we started x9.59 in the mid-90s, http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy we frequently commented that it was privacy agnostic. it provided strong authentication that didn't have skimming and harvesting threats and vulnerabilities. there was a strong correlation with some account number ... and the degree that there was some trail from that account number to an individual was dependent on a lot of things outside of the financial transaction itself. however, the basic financial transaction didn't require wandering across the line from authentication into identification. this was also the period where it started to show up the shortcomings of the x.509 identity certification paradigm that had somewhat tried to get some toe hold in the early 90s including grossly overeloading the certificates with personal information. basically that every digitally signed transaction in the world would carry a huge x.509 identity certificate grossly overloaded with personal information. Not only would all such transactions carry such humongous personal information repositories, while in flight but all the transaction logs would be heavily burdened with the same information. You might have tens of thousands of transactions logs all over the world ... and every one would include a humongous x.509 identity certificate grossly overloaded with personal information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. this is also the EU finread standard http://www.garlic.com/~lynn/subpubkey.html#finread which has a certified display and certified pin-pad. it was for token reader external to the PC ... so that what is displayed is what gets signed ... and the PIN entry isn't easily compromised. This still somewhat assumed standard 7816 card w/o its own display and pin-entry. the issue in x9.59 design http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy was that it was possible for the relying party to get certified integrity information about the hardware token at the time the public key was registered and recheck that certified integrity information (binding to the public key) on every digitally signed transaction ... the EU finread standard didn't provide for the similar level of assurance. x9.59 allowed (but didn't mandate) that the environment, in which the signing took place, could also digitally sign the transaction. this could provide the relying party a binding not only between the integrity of the token doing the digital signing but also a binding between the environment that the digital signing took place and the integrity of that binding. The base EU finread terminal scenario provides for a standard for high integrity digital signing environment. However, it doesn't provide for any proof to the relying party that such a terminal was actually used for any specific transaction. Having the public key of the EU finread terminal registered along with the associated certified integrity level of that environment then if such a terminal was also to digitally sign the transaction, the relying party could do some risk assesement both on the integrity of the token performing the digital signing (for authentication purposes) and the integrity of the signing environment (terminal). If the display, pin-entry, and authentication token were tightly bound in the same device then when the relying party registered the public key for authentication purposes they would also register the associated integrity characteristics of the hardware token (for authentication purposes) as well as the display and pin-entry (for integrity related to the signing environment). The issue here is that the relying party is fundamentally interested in the overall risk of the transaction ... which is composed of a lot of individual integrity characteristics. Relating this to the old style x.509 identity certificate grossly overloaded with personal information a relying party ... can have done an authentication binding regarding the public key (i.e. don't necessarily need to have the identity of the person such know that the authentication indicates the entity is the one that is authorized to performed the related operations w/o having across the line from auhentication into identification and grossly confusing the difference between the two). One the relying party has done the straigth-forward authentication binding for a hardware token and a public key the really interesting charactistics for the relying party is all the integrity characteristics surrounding a transactions. To some estent, the PKI identity-centric focus have tended to distract relying parties from the more fundamental risk issues regarding integrity characteristics of performing the transaction. One an entity is registered as enabled for performing valid transactions (which can be a purely authentication operation w/o getting grossly confused about the difference between authentication and identification), then issues of certification interest to a relying party are the integrity characteristics of the authentication events (and the enormous concentration by PKI bodies on confusing identification with authentication tends to be a pure distraction to the risk assesement of the operations). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. Steve, thanks. Not really much of surprise, is it? Clearly, a user who lets malware onto his/her PC, e.g. a VBscript in this case, has lost control and is open to such attacks. But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. Yes, I know, this is far from the current situation, with corrupted PCs (Zombies) being a very large fraction (around a third?)... -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Adam Shostack wrote: On Sun, Jul 10, 2005 at 12:13:42AM +0100, Peter Fairbrother wrote: | Perry E. Metzger wrote: | | A system in which the credit card was replaced by a small, calculator | style token with a smartcard style connector could effectively | eliminate most of the in person and over the net fraud we experience, | and thus get rid of large costs in the system and get rid of the need | for every Tom, Dick and Harry to see your drivers license when you | make a purchase. It would both improve personal privacy and help the | economy by massively reducing transaction costs. | | I agree that it might well reduce costs and fraud - but how will it improve | privacy? Your name is already on the card ... and the issuer will still have | a list of your transactions. | | Not having to show ID may save annoyance, but it doesn't significantly | improve privacy. Most credit card issuers will happily give you extra cards, so your friends can spend your money. In whatever name you want. If you need to show ID, this can become, umm, complicated. This goes along with paypal's send a friend a debit card feature (I saw this two years ago, I don't know if this is still present), but this essentially allowed a user to add any name to the debit visa card (treated in most places like a credit card) which in some cases actually allowed online hijacking of domain names (depending on registrar) because the name was the same on the visa card used. -Lance -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
I think the difference now is the number of vendors entering the market, the variety of solutions ( and their relative security), and demand outside of Europe. When we started in mid-2001, we were looking at the existing hardware guys and that is it. Now there a handful of venture-backed software players with different solutions all targeting the banking market, which didn't exist then. We have not seen any interest in our two-factor solution from Germany or any country where they have some form of two-factor authentication. Perhaps this is similar to the US corporate market where companies that have tokens aren't very interested in switching to save money - the CSO only takes risk in switching and sees no personal benefit in reducing costs (my theory at least) so there's no true vetting, only beating up the current vendor for a slightly better deal. Thus your banks will still complain that the price of mailing paper is too high, which of course it is when compared to software tokens. We are, however, seeing interest from US and South American banks and the numbers are huge and we will be very aggressive in pricing. We also see that we are competing against companies that use IP address verification, secure cookies and other things that are readily compromised, but apparently easy to roll-out and maintain and inexpensive. So, we have to compete against those substitutes that don't even use cryptography or two-factor authentication but would be better termed as fraud detection and prevention. Florian Weimer wrote: * Nick Owen: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. I doubt this is true. In Germany, we already use some form of two-factor authentication for Internet banking transaction (account number/password and a one-time password for each transaction). Yet banks are desperately looking for alternatives because distributing those one-time password lists is too expensive (!). To me, this was quite surprising because it's just one sheet of paper every 200 transactions or so. Even worse, this scheme has failed, and there are successful attacks in the wild (involving compromised client PCs). Right now, time-dependent tokens do help, but only because you outrun the other guy. The real-time requirements imposed by them are not a fundamental obstacle to the attackers, and even now, the way they route the money makes it very hard to detect things in real-time (at least on the money side). Well, you can imagine my surprise when Howard Schmidt praised two-factor authentication as a solution to our current problems at the FIRST 2005 conference. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
* David Alexander Molnar: Actually, smart cards are here today. My local movie theatre in Berkeley, California is participating in a trial for MasterCard PayPass. There is a little antenna at the window; apparently you can just wave your card at the antena to pay for tickets. I haven't observed anyone using it in person, but the infrastructure is there right now. If you are interested in useful RFID applications, just visit Singapore. 8-) They use RFID tickets on the subway (MRT) and on busses, and you don't have to worry about buying the right ticket because the system charges you the correct amount. However, there's one thing that makes me nervous: if you know the card number (which is printed on the cards), you can go to a web page, enter it, and obtain the last 20 rides during the last 3 days, without any further authentication. It's a system where contactless readers make a lot of sense, though. Here's the MasterCard fact sheet about PayPass: http://www.paypass.com/fact_sheet.html In Germany, we have got something even better: digital cash (Geldkarte). The system is rather old, so it doesn't use contactless smartcards, and it was never accepted by customers and merchants. I'm not even sure if it's still usable. I own one or two of the smartcards, but I don't think I've ever used them. 8-/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
* Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com In the foreseeable future, this approach won't stop fraudulent transactions because the one-time password does not depend on the transaction content. Anything which doesn't display essential parts of the transaction contents to the end user over a trusted channel is doomed to failure. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Anti-fraud] Re: the limits of crypto and authentication
On Sun, 10 Jul 2005, Amir Herzberg wrote: But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. I disagree. Limited authority is the best way to prevent such malware from being installed (and, if installed, from causing harm). The premise that all software can be divided into categories of good and evil is a deeply flawed foundation on which to build security. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
[EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it works is that for transactions with a combined value over the default floor limit of NZ$2.5K you have to use an additional PIN sent via SMS to a pre-configured number to authenticate the session. The PIN authenticates that particular session (not just one transaction), with a fee of NZ$0.25. It's not perfect, obviously, but that was seen as the best tradeoff between cost, user convenience, and security. grumbleA few years ago I wanted to do this out-of-band authentication as a research project, and at the time couldn't find anyone interested in it; now they've paid an arm and a leg for it themselves, sigh/grumble. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Nick Owen wrote: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted? two-factor authentication per se, isn't necessarily the panecea. pin-debit ... has a magstripe card as something you have and a pin as something you know. as recently mentioned, compromised ATM /or POS machines have been able to skim the magstripe and the pin enabling creation of counterfeit cards and fraudulent transaction. in x9.59, http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy a hardware token can digitally sign the actual financial transaction. this would be single factor, something you have authentication. skimming and/or harvesting the transaction and/or transaction log files http://www.garlic.com/~lynn/subpubkey.html#harvest doesn't enable either counterfeit cards and/or fraudulent transactions. the issue of a PIN, in conjunction with the magstripe card for two-factor authentication, was a countermeasure against lost/stolen card. However, skimming as a threat, is able to capture both the PIN and the card magstripe information, enabling fraudulent transactions. a single-factor authentication hardware token (something you have) that digitally signs the transaction is sufficient countermeasure against skimming and harvesting. Enforced PIN-debit ... i.e. where the magstripe can't be used w/o the PIN ... turns out to be a countermeasure against some of the transaction log harvesting (the type of data breach stories recently in the press) ... since the PIN information isn't normally carried in the transaction log. The issue with the transaction log is that there are several other merchant business processes that require access to transaction information. The issue with magstripe and PINs ... is the threat and vulnerability model effectively is a replay attack ... static data that can be relatively easily recorded and repeated in fraudulent transactions (and/or used to create counterfeit magstripe). A single factor authentication hardware token that digitally signs that transactions, is countermeasure against attacks recording static data for replay-type attacks. Adding a PIN or biometric authentication to a hardware token for two factor authentication doesn't improve the countermeasure to skimming and harvesting attacks. The PIN or biometric authentication in conjunction with a hardware token is primarily countermeasure for lost/stolen token ... not countermeasure for skimming/harvesting replayable information. There is has been a separate issue with the use of pin/passwords shared-secrets http://www.garlic.com/~lynn/subpubkey.html#secrets for something you know authentication, is people having large number of different accounts each, supposedly requiring unique something you know shared secrets. The estimate is that possibly 30percent of the debit cards have PINs written on them. The issue is basic human factors and blindly adding something you know shared secret as a second authentication factor doesn't necessarily significantly improve the situation. so you are possibly faced with having to fundamentally rework some of the authentication landscape to compensate for well documented human short comings. So two possible pieces for reworking this portion of the authentication landscape (for human factor shortcomings with proliferation of large number of shared-secrets) 1) certified tokens that accept PINs for operation. the PINs are shared-secrets since they don't travel past the token. The token is in the person's possession and the PIN is just for activating certified token operation. this can contribute to the person being able to initialize all tokens to the same PIN 2) transition from institution-centric tokens to person-centric tokens ... aka rather than every institution in the world issuing a token ... and each token possibly requiring a single PIN, people can acquire some small number of personal tokens and register their personal tokens for valid something you have authentication at different institutions. A big issue in the recent data breach stories with respect to security PAIN acronym P ... privacy A ... authentication I ... integirty N ... non-repudiation is that many of the infrastructures tend to have relatively strong integrity requirements for their business records. this protects the infrastructure business operations. however, they tend to have much lower privacy requirements ... in part because the large number of business processes that require access to those records. furthermore, the privacy threats and vulnerabilities isn't directly against the infrastructures
Re: the limits of crypto and authentication
On Saturday 09 July 2005 23:31, [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? There was no market failure - Amex Blue was an outstanding success that sent waves of astonishment through the credit card industry. Everyone was talking about how stunningly successful it was - how it had broken the laws of account creation by actually acquiring new accounts in the millions instead of cannibalising existing accounts. (I recall a number of 4 million?) You may be thinking that the usage of the smart card being a total and complete flop was in some way correlated with the market success, but it was quite the reverse - the smart card usage was a complete and utter failure for the obvious reasons, but the program itself was fantastically successful. iang -- Advances in Financial Cryptography, Issue 2: https://www.financialcryptography.com/mt/archives/000498.html Mark Stiegler, An Introduction to Petname Systems Nick Szabo, Scarce Objects Ian Grigg, Triple Entry Accounting - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Perry Metzger writes: So, what is to be done? I would propose that the replacement of the credit card infrastructure is needed. Fraud is prevalent because of a massive inherent security flaw in the current system, to whit, the account number is identical to the payment authenticator, and you can make a payment merely through possession of a piece of stolen plastic. A system in which the credit card was replaced by a small, calculator style token with a smartcard style connector could effectively eliminate most of the in person and over the net fraud we experience, and thus get rid of large costs in the system and get rid of the need for every Tom, Dick and Harry to see your drivers license when you make a purchase. It would both improve personal privacy and help the economy by massively reducing transaction costs. Have you ever used an ATM/debit card for a purchase? You swipe it and then the merchant hands you a keypad to enter your PIN. Yes, an insider could hack the device and steal your PIN along with your card, or use various other attacks to get the PIN, but it's much more complicated than using an opportunistically stolen credit card. These have come into common use in the past several years. I don't understand the commentary here which seems oblivious to the existence of this widely used alternative payment system in the U.S. All I am reading is oh, we can't switch, no one will ever switch from credit cards. People are switching; it's happening everywhere. A video game chain store in town, I think it's EBX, only accepts these cards, they won't take credit cards. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
[EMAIL PROTECTED] writes: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? The Blue Card, so far as I can tell, was poorly thought out beyond its marketing potential. I knew some folks at Amex involved in the development of the system, and I did not get the impression they had much of a coherent idea of what the technologies would be used for other than creating marketing buzz. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Given such a structure, however, you can know when the device displays Pay 53.22 euros to amazon.fr for book X that this is precisely the transaction you are authorizing, and that the communication will not authorize any other transaction, its interception will not permit the authorization of any other transaction, and no replay of the transaction is possible. However, you need both the end to end communication and the hardware token with built in display and keyboard. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
halloween hash bash reminder--July 15 deadline
Guys, This is just a reminder that the NIST hash workshop (Oct 31-Nov 1 of this year) is still taking submitted talks, abstracts, etc., until July 15. There are no proceedings, so there should not be any problem publishing things that you discuss at this workshop. A major goal of doing this is to get people to discuss interesting ongoing work so we can understand it now, rather than after we've made decisions about how to react to all the excitement in the hash function world. (For what it's worth, I plan on presenting some new hash function results with Yoshi Kohno that we intend to publish somewhere else. I expect we'll post these on the ECRYPT server before that.) This workshop is going to have a big impact on decisions like whether we should do some AES-like process to get a new hash function standard, whether we should try to standardize on some additional algorithms (like Whirlpool or the Russian standard GOST hash function), etc. Taking part is a great opportunity to influence those decisions. If you have something new to say about hash functions, or something old that should be repeated, send us some slides, or at least an extended abstract, and we'll see whether we can fit you onto the agenda for some discussion time. --John Kelsey, NIST, July 2005 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
another characteristic of the PKI x.509 identity certificate activity (besides attempting to create mass world-wide confusion regarding the difference between identification and authentication ... and trying to get govs. to mandate that x.509 identity certificates, grossly overloaded with personal information had to be appended to even the most simple of authentication transactions) was trying to cause a great deal of confusion about the difference between *digital signatures* and *human signatures*. some of this possibly was semantic confusion because both of the terms; *digital signature* and *human signature* contain the word *signature*. nominally a digital signature is the use of a private key to encode a message/document hash. the relying party then recalculates the message/document hash, uses the corresponding public key to decode the digital signature, and compares the two hash. if they are equal, the relying party assumes: 1) the message/document hasn't been altered (since the digital signature) 2) something you have authentication, aka the originator has access and use of the private key. the base technology is asymmetric key cryptography (what one key encodes, the other key decodes). the business process of public key, identifies one key as publicly available. the other key is kept confidential and never divulged. the integrity of something you have authentication can be improved by deploying secure hardware tokens where the key pair are generated in the token and the private key never leaves the token (improving the probability that the private key is never divulged). now, normal *human signature* implies read, understood, agrees, approves, and/or authorizes. The normal *digital signature* is purely a something you have authentication process implying none of the characteristics of a *human signature*. In fact, a series of my pasts posts on *dual-use attacks* was specifically with using the same private key to apply digital signatures to random data (as part of authentication operations) and digital signatures to non-random data (assuming human signature characteristics). Somewhat in support of helping create world wide confusion about the differences between *digital signatures* and *human signatures* (in addition to creating world wide confusion about the difference between authentication and identification), the PKI x.509 digital certificate standard also defined a non-repudiation bit. For some number of PKI-oriented payment protocols in the mid-90s, there was the specification of digital certificates with the non-repudiation bit turned on. Supposedly, if a merchant could demonstrated any valid digital certificate with the non-repudiation bit turned on (for the customer's public key), then the burden of proof in any dispute would have shifted from the merchant to the consumer. The threat/vulnerability was 1) the PKI-oriented protocols provided no mechanism for proving which certificate had been originally attached to the transaction 2) supposedly the non-repudiation bit was capable of turning any digital signature operation (regardless of the environemnt in which the signature had been performed) magically into a *human signature* carrying the attributes of read, understood, agree, approve, and/or authorized. So the PKI x.509 identity digital certificates were targeted at 1) turning every transaction in the world (even the most trivial authentication operation) into a heavy duty identification operation (with attached x.509 identity digital certificates carrying enormous amounts of personal information) 2) allowing anybody that could produce a valid digital certificate (for the associated public key) with the non-repudation bit on, to magically turn all associated *digital signatures* into *human signatures* (even digital signatures that had been presumably been performed on random data for purely authentication operations). since that time, the use of the certificate-based non-repudiation bit has been severely depreciated (many people coming to realize that it takes more than magical PKI bits to turn *digital signatures* into *human signatures*). there were some that started to realize that the PKI x.509 identity certificate model represented severe privacy and liability issues. The initial quickdirty fix were the relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo containing just public key and some sort of database lookup index. The issue here is that it is trivial to demonstrate that such relying-party-only certificates are redundant and superfluous if the relying party already has all the information, then the relying party can directly look up the necessary information (including registered public key as well as all integrity characteristics that might be associated with that public key ... and the last thing they need are redundant and superfluous relying-party-only digital certificates).
Looking for crypto iButton specs
--- begin forwarded text From: [EMAIL PROTECTED] (Peter Gutmann) To: [EMAIL PROTECTED] Subject: Looking for crypto iButton specs Date: Tue, 12 Jul 2005 00:56:35 +1200 Sender: [EMAIL PROTECTED] During a recent discussion about secure crypto device bootstrap and attestation capabilities, I realised that of the three devices for which this was implemented and for which documentation was available (Fortezza, IBM 4758, and Dallas Crypto iButton), I either don't have any documentation for the Crypto iButton or I've filed it under something sufficiently misleading that I can't find it any more. So: Does anyone still have the documentation for the DS1954 Crypto iButton? Note that I specifically mean the DS1954 Crypto iButton before its Javafuxation, which removed the very nice crypto security model and crypto transaction processing/scripting capability. Dallas systematically excised any traces of the pre-Javafuxated version from databooks and web pages, so it'd be a case of someone having a copy archived somewhere. It was a very nice design and I'd like to have some record of it outside the summary I put in my Godzilla security tutorial. (If whoever did the design is reading this, I'd be interested in hearing from them as well). Peter. --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
City National Bank is the latest major US company to admit it has lost customer data.
http://81.144.183.106/Articles/2005/07/11/210820/AnotherUSbanksownsuptodataloss.htm City National Bank is the latest major US company to admit it has lost customer data. The bank says it lost data back-up tapes in April, while they were being transported to a secure facility by third-party data storage company Iron Mountain. The sensitive data contained account numbers, social security numbers... ... snip ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
Perry E. Metzger wrote: A system in which the credit card was replaced by a small, calculator style token with a smartcard style connector could effectively eliminate most of the in person and over the net fraud we experience, and thus get rid of large costs in the system and get rid of the need for every Tom, Dick and Harry to see your drivers license when you make a purchase. It would both improve personal privacy and help the economy by massively reducing transaction costs. I agree that it might well reduce costs and fraud - but how will it improve privacy? Your name is already on the card ... and the issuer will still have a list of your transactions. It's just that the drivers license number is a unique number that acts as an index to another database (and often used as authentication material as well), which the merchant has to business knowing. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV [was: Re: Why Blockbuster looks at your ID.]
On Sat, 9 Jul 2005, [UNKNOWN] Jörn Schmidt wrote: less attractive to commit credit card fraud. You are, however, not making it harder. That's why I believe the credit cards companies will indeed have a good, long look at smartcards. Probably not tomorrow or next week but in the near future. Actually, smart cards are here today. My local movie theatre in Berkeley, California is participating in a trial for MasterCard PayPass. There is a little antenna at the window; apparently you can just wave your card at the antena to pay for tickets. I haven't observed anyone using it in person, but the infrastructure is there right now. Interesting, they have a card (smart card)? and key fob version. I hope their key fob version is not as insecure as the SpeedPass RFID transponder token used by Exxon/Esso, which has recently been broken http://rfidanalysis.org/ The SpeedPass implemented an authentication algorithm (I think it was a CRC-like challenge response based on a secret that defined the polynomial used) based on a 40-bit key. Bono al. figured out the algorithm (based on a patent, which described the algorithm generically, they figured out the constants that were chosen). The question is why did they use a 40-bit secret? Is there some technological constraint preventing the use of something better? The other thing is that many of the smart cards also have a magnetic strip, so your security level is as strong as the weakest point (magnetic stripe type payments). Untill all the cards are smart cards, readers will accept both type. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: City National Bank is the latest major US company to admit it has lost customer data.
If anyone knows how many people this affected, I'd love to know. (I'm assuming its their entire customer base) Adam On Mon, Jul 11, 2005 at 09:07:45AM -0600, Anne Lynn Wheeler wrote: | http://81.144.183.106/Articles/2005/07/11/210820/AnotherUSbanksownsuptodataloss.htm | | City National Bank is the latest major US company to admit it has lost | customer data. | | The bank says it lost data back-up tapes in April, while they were being | transported to a secure facility by third-party data storage company | Iron Mountain. | | The sensitive data contained account numbers, social security numbers... | | ... snip ... | | - | The Cryptography Mailing List | Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Peter Gutmann wrote: [EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it works is that for transactions with a combined value over the default floor limit of NZ$2.5K you have to use an additional PIN sent via SMS to a pre-configured number to authenticate the session. The PIN authenticates that particular session (not just one transaction), with a fee of NZ$0.25. It's not perfect, obviously, but that was seen as the best tradeoff between cost, user convenience, and security. grumbleA few years ago I wanted to do this out-of-band authentication as a research project, and at the time couldn't find anyone interested in it; now they've paid an arm and a leg for it themselves, sigh/grumble. Back when we used to run O2's (then Cellnet) web stuff, we used to authenticate user accounts by sending random words to their phone. This was so long ago I can't remember when it was, but certainly 5 years. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: However, you need both the end to end communication and the hardware token with built in display and keyboard. there is two issues for digital signatures ... 1) something you have authentication and 2) proof to the relying party as to the integrity level of the operations it is possible to establish the integrity level of the hardware token at the time the public key is registered ... and then possibly track the token integrity level as it degrades over time (because of technology advances). in the EU finread standard case http://www.garlic.com/~lynn/subpubkey.html#finread it assumed that the display/pinpad and the token were separate. the the case of relying party being able to evaluate the risk of the transaction ... then it would actually need the separate display/pinpad to also digitally sign the transaction (and also having previously registered the finread terminal public key and integrity level). the co-signing by the separate display/pinpad was allowed for in x9.59 financial transaction standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/supubkey.html#privacy but not mandated. when the display, pinpad, and token are all a single device ... then there would only be a requirement for a single digital signature ... representing both the something you have authentication as well as the integrity level of the signing environment. in the *human signature* realm there is the aspect of many financial point-of-sale termainals where there is requirement for some sort of manual, human interaction that demonstrates some sort of agreement, approval, and/or authorization of the transaction (in addition to the authentication operation). frequently this is a display of the transaction requiring the person to hit the agree/yes button ... as a separate operation from any authentication operations. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
Florian Weimer wrote: * David Alexander Molnar: Actually, smart cards are here today. My local movie theatre in Berkeley, California is participating in a trial for MasterCard PayPass. There is a little antenna at the window; apparently you can just wave your card at the antena to pay for tickets. I haven't observed anyone using it in person, but the infrastructure is there right now. If you are interested in useful RFID applications, just visit Singapore. 8-) They use RFID tickets on the subway (MRT) and on busses, and you don't have to worry about buying the right ticket because the system charges you the correct amount. However, there's one thing that makes me nervous: if you know the card number (which is printed on the cards), you can go to a web page, enter it, and obtain the last 20 rides during the last 3 days, without any further authentication. London Underground have a contactless system too, but it isn't used much. As I remember it had a similar problem, but they may have changed that. You take out your wallet with the card in and wave it over a palm-sized yellow blob on the turnstile, but you don't have to open your wallet to withdraw a token. Muggers and pickpockets keep a close eye out to see how fat your wallet is and where you keep it ... -- Peter Fairbrother - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: talk: Reflective side-channel cryptanalysis
From: Eu-Jin Goh [EMAIL PROTECTED] Subject: FRI 15 JULY 1630 HRS : Reflective side-channel cryptanalysis To: [EMAIL PROTECTED] Date: Mon, 11 Jul 2005 08:46:19 -0700 - --- When - FRI 15th July 1630 hrs at Gates 4-B (opposite 490) Who - Eran Tromer, Weizmann Institute of Science What - Reflective side-channel cryptanalysis - --- Abstract: Side-channel cryptanalysis exploits physical information leakage from cryptographic devices to undermine their security. Most side-channel attacks require special measurement equipment and are thus limited in applicability. This talk will present two side channels that can be exploited in many settings without special equipment. First, CPU cache contention leaks information on memory access patterns in several ways. Second, acoustic emanations from electronic circuit components can be information-bearing and are often detectable by a plain microphone. Applications of these side channels to RSA and AES will be shown. In some common cases these attacks can be carried out by software within the target computer, allowing an unprivileged process to glean secret information from privileged ones without any explicit interaction. This raises new challenges for multiuser, partitioned and sandboxed environments. Joint work with Dag Arne Osvik and Adi Shamir. - --- Map to Gates Computer Science Building http://campus-map.stanford.edu/campus_map/results.jsp?bldg=gatesdept=addr= - -++**==--++**==--++**==--++**==--++**==--++**==--++**== -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
On Mon, Jul 11, 2005 at 09:37:36PM +, Jason Holt wrote: I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. The 3-digit code is stupid. It protects against one thing and one thing only - someone getting an imprint of the card without copying down the 3-digit number. But only if you never give it out. According to at least several credit card companies, it's supposed to be okay for you to give this code out to vendors when you make a purchase. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out secure from suspicious site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... But it's so much worse than that. Not only is there no standard behavior, the credit companies themselves have seemingly gone out of their way to make it impossible for there to be any potential for a standard. -- - Adam ** I can fix your database problems: http://www.everylastounce.com/mysql.html ** Blog... [ http://www.aquick.org/blog ] Links.. [ http://del.icio.us/fields ] Photos. [ http://www.flickr.com/photos/fields ] Experience. [ http://www.adamfields.com/resume.html ] Product Reviews: .. [ http://www.buyadam.com/blog ] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Attack on Brands blind signature
eprint.iacr.org/2005/186 is an attack by Xuesheng Zhong on several blind signature schemes, including one widely discussed on the Cypherpunks mailing list back in the 1990s by Stefan Brands. The paper seems to show that it is possible for the bank/mint to recognize blind signatures (i.e. untraceable electronic cash tokens) when they are re-submitted for deposit, which is exactly what the blind signature is supposed to prevent. The math looks right although I haven't tried to look back at Brands' old work to see if it is correctly described in the new paper. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
Jason Holt wrote: I remember the first time a site asked for the number on the back of my credit card. It was a Walmart or Amazon purchase, and with no warning they redirected me to some site with a questionable domain. I thought for sure my session was being hijacked, and my bank had given me no idea what the number was for or whether it was something I was supposed to give out. To me, this is closely related to the discussions we have here about web browser security semantics. With a very good understanding of the underlying PKI, we can usually sort out secure from suspicious site behaviors with some discussion, but how is the average user (or even the average engineer) supposed to cope? Is there a standard or even just a document somewhere that defines best practices for both server and user behavior with respect to SSL web sites and credit card transactions? Or are we leaving them to forward emails to each other warning them not to give out their 3-digit codes over the phone, and that they had better make sure their Dell doesn't have a DHS keylogger installed... Even with standards in place for the consumer, that's only half of the circle. Phishers/Scammers are evolving rapidly and are either black hats themselves or have access to employing black hats to compromise sites, or perform cross-user attacks on the user. Companies like Amazon are only as secure as how they have devised their infrastructure - and as you and everyone else here knows, SSL is one layer of the security in depth infrastructure model. This threat vector has not been addressed by commercial entities that offer transaction services for many reasons, one being that the procurement process takes a long time just to get any security technology in place to fend off these attacks. Soon phishers will just use the site itself to phish users, pushing away the dependency on tricking the user with a spoofed or mirrored site. -J -- Forwarded message -- Date: Mon, 11 Jul 2005 11:28:50 -0700 To: undisclosed-recipients: ; Subject: New Credit Card Scam I got this from a co-worker today: Apparently, they don't ask for your number, just the 3 digit code on the back. They'll tell you they're calling from your Visa or Mastercard company and that they're trying to verify whether or not you've made a $497.99 purchase from a company in Arizona or something. They'll tell you to call your credit card company if you have any questions, etc, and they never ask for your card number, so it sounds pretty legit, but it's not. If it does happen to you, within a few minutes of the phone call you'll have a charge for $497.99 on your card. You can always call the credit card company yourself and make sure they're the ones wanting to check about fradulent charges, so if you get a call that sounds fishy, just tell them you'll call them back at the number on your card. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
