Re: New Credit Card Scam (fwd)
On Mon, 11 Jul 2005, Lance James wrote: [...] 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. [...] You dismiss too much with your just. They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
-- Adam Fields [EMAIL PROTECTED] 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. Widely shared secrets are inherently insecure, and no good practices exist to make them secure. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG pPiA9t4S8XPLqBdKsuV/tb+p7tvWdaBMwkYer7hl 4+JSXe6MBo4npe1jgiYmnZNAqOAsX9u+daHcBra01 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Well, whether you like the cell phone as the out-of-band second-factor, you can now unlock your front door with it... http://weblog.physorg.com/news2334.html --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Menezes on HQMV
Eric Rescorla wrote, on July 1: There's an interesting paper up on eprint now: http://eprint.iacr.org/2005/205 Another look at HMQV Alfred Menezes ... In this paper we demonstrate that HMQV is insecure by presenting realistic attacks in the Canetti-Krawczyk model that recover a victim's static private key. We propose HMQV-1, a patched version of HMQV that resists our attacks (but does not have any performance advantages over MQV). We also identify the fallacies in the security proof for HMQV, critique the security model, and raise some questions about the assurances that proofs in this model can provide. Obviously, this is of inherent interest, but it also plays a part in the ongoing debate about the importance of proof as a technique for evaluating cryptographic protocols. I notice that Hugo Krawczyk has now responded by updating his HMQV paper at http://eprint.iacr.org/2005/176. The details are a little complicated; basicaly he agrees with Menezes about some things but disagrees on others. However he then goes on to address the underlying issue, the nature and use of proofs of security. [Krawczyk writes:] A personal perspective. I would like to thank Alfred Menezes for identifying the oversight in the HCR proof and the need for group membership verification in the one-pass protocol. At the same time, I must strongly disagree with the attempt in [32] to discredit the effort of the cryptographic community dedicated to improving our understanding and design of protocols. True, we make mistakes (and I do not justify my own); and proofs (even if correct) are never stronger than the model and assumptions they are based on. But with all its imperfection, this form of analysis is an essential tool for gaining confidence in the soundness of a cryptographic design. Moreover, as clearly shown here, the proof process itself serves as a guide in choosing the right design elements. At a time when we demand the best (almost perfect) security from basic encryption and hash functions, and having witnessed the effects of initially-mild attacks, we can only hope that the applied-cryptography community and its representing standard bodies will see formal analysis as a requirement, and main source of confidence, when adopting protocols for wide use. These analyses can (and must) be verified by the community at large (in contrast, ad-hoc designs do not even provide the 'luxury' of judging well-defined security properties). This is all the more significant in the case of a protocol such as MQV which is not only intended for wide commercial use but also to protect 'classified or mission critical national security information'. [End of Krawczyk comments] The question of the usefulness and value of proof techniques in cryptography will continue to be debated. Hugo Krawczyk is going to present his HMQV technique at Crypto next month, so perhaps there will be additional discussion there. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New Credit Card Scam (fwd)
Jason Holt wrote: On Mon, 11 Jul 2005, Lance James wrote: [...] 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. [...] You dismiss too much with your just. They already do attack plenty of sites, but they also phish because it has a larger return on investment. Security is the process of iteratively strengthening the weakest links in the chain. I'm being misunderstood - Cross-User attack concepts specifically is what I'm referring to. The straight on attacks on sites are definitely a processed phase within the many attack vectors they are performing, I'm just making clear that the businesses need to start working on those weak links. -Lance -J -- 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
Perry E. Metzger wrote: Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides a trusted communications path to the user that the PC itself cannot. On the surface, we already have such technology in Germany (it's optional for bank customers), but there's a drawback: The external device doesn't know anything about the structure of banking transactions, so it relies on the (potentially compromised) host system to send the correct message to display before generating the signature. Ouch. That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. This would preclude, for example, offline transactions. As I've said before, I totally agree that the only way to go is to have signatures made on such a device, but I do think its very important to design the thing right - and the above isn't sounding right to me. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
Peter Fairbrother wrote: 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 ... Which, of course, they would never do if you were extracting money to buy a ticket, or showing your season ticket. Explain to me how the contactless system alters this risk in any way? Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Ben Laurie [EMAIL PROTECTED] writes: That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. Tedium is something that computers do very well. They don't care about how much work they have to do. The only issue is whether we induce too many serialized public key operations, and thus too much delay. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? Yup. I want that for a variety of reasons. In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. That's the case already. Only the issuing bank knows if the account has any credit left in it, after all. This would preclude, for example, offline transactions. We used to live in an era where offline transactions were important. Now that you can get online literally anywhere, and now that merchants pretty much are required to check card validity and funds availability online anyway, that's no longer an interesting concern. I can't think of the last time I was involved in an offline transaction -- even folks at street fairs can now afford GPRS and similar communications for their veriphone (and similar) units. As I've said before, I totally agree that the only way to go is to have signatures made on such a device, but I do think its very important to design the thing right - and the above isn't sounding right to me. It sounds right to me, because it puts the trust relationships in all the right places. The merchant trusts the accepting bank that it will be paid. The accepting bank trusts the card network, the card network trusts the issuing bank. The issuing bank and cardholder have a bilateral relationship, too. If we keep the cryptographic exchanges purely in correspondence with the trust relationships, and we get rid of reliance on third party certification of public keys entirely, we also fix most of the trouble in the system. By the way, I note as an aside that this also means (in my opinion) that certificates are no longer an interesting technology for payments protocols, because in a purely online environment, you never need a third party x.509 certificate in the course of the payments protocol itself when there are no offline components of the protocol and all relationships are bilateral. The overwhelming disadvantage is deployment complexity, but given deployment (ha, what an assumption on my part!) the system would work very cleanly indeed. The user would not have to worry about his PC being infected or his merchant deploying a dishonest terminal (though theft of a token + beating the PIN out of the user would still be an issue). By not responding to requests that do not come from the issuing bank specifically encrypted for the token, you reduce (though of course not eliminate) the possibility of side channel attacks or inducing buffer overflows and such in the token, as well as depriving intermediate entities of privacy damaging information. The issuing bank would not have worry about the origin of the token's signature -- it could be reasonably assured that, short of physical attacks on the tokens (which would happen but be infrequent), the signature came from the token, and no information that would permit independent payment authorizations has been left with the merchant or card processor. Overall, I think such things are a win. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
In Brazil there's alot of trojans similar to the one Steven mentioned, almost all of them targeted at diferent national banks. A while back they worked as external pop-ups as we named them. That is they appeared on top of the browser appearing visually like when you are asked for your credencials by the bank (although many times they ask for all your data including ssn). Now a days they are more advanced, we have seen trojans lately that closes the browser and opens a window just like IE and then navigates the banks site inside, when it comes to entering the credencials it shows more fields to fill in than normal. They often come with keyloggers too to rob your pin number as you enter it. That made the banks use virtual keyboards, entering the PIN with the mouse on screen, to avoid entering PIN numbers via the keyboard. Then the bad guys started using mouse loggers that captures a tiny square with every mouse click. The captured data are sent via smtp, ftp or via an http post. The latest trick is to encrypt the captured data with AES although the key is fixed in the code ;-) Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. -- Mads Rasmussen Security Consultant Open Communications Security +55 11 3345 2525 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only at the specific issuing bank. If anything in between can tamper with the communications channel you don't have the properties you want out of this. Not entirely clear what you mean by the issuing bank here, but I'm hoping you don't mean that the bank issues the device - that would be very tedious. Tedium is something that computers do very well. They don't care about how much work they have to do. The only issue is whether we induce too many serialized public key operations, and thus too much delay. Sure, but multiple physical devices aren't my computer's problem, they're my problem. I also find directed only at the specific issuing bank unclear - I presume you mean encrypted s.t. only the issuing bank can read it? Yup. I want that for a variety of reasons. In which case, you're adding complexity - a relying party has to let the issuing bank come between it and you to get anywhere. That's the case already. Only the issuing bank knows if the account has any credit left in it, after all. This would preclude, for example, offline transactions. We used to live in an era where offline transactions were important. Now that you can get online literally anywhere, and now that merchants pretty much are required to check card validity and funds availability online anyway, that's no longer an interesting concern. I can't think of the last time I was involved in an offline transaction -- even folks at street fairs can now afford GPRS and similar communications for their veriphone (and similar) units. There are reasons to want to do offline transactions and to not have intermediaries that go beyond mere connectivity. Anonymity being the one of most concern to me, but I'll wager there are others. Cheers, Ben. -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: By the way, I note as an aside that this also means (in my opinion) that certificates are no longer an interesting technology for payments protocols, because in a purely online environment, you never need a third party x.509 certificate in the course of the payments protocol itself when there are no offline components of the protocol and all relationships are bilateral. my impression of the 3party x.509 identity certificate model of the early 90s ... was that every person would pay $100/annum for their identity certificate grossly overloaded with personal information. the certificate model has a design point from the early 80s, offline email, where the receiver dials their local (electronic) postoffice, exchanges email and hangs up. they then are faced with dealing with first time email from total strangers. the x.509 identity certificates, grossly overloaded with personal information ... were targeted at (hopefully) including at least one piece of personal information (about the sender), that the receiver might find useful when dealing with total stranger. moving into the early 90s, with a model where everybody would have $100/annum identity certificates ... the apparent business model would be that all established business relationships would be done away with ... and people would only be performing spontaneous business transactions with total strangers ... supported by the x.509 identity certificates. For instance, rather than depositing money in an established bank account you would spontaneously contact a total stranger to accept your large sums of money. The exchange of x.509 identity certificates with total strangers would provide sufficient trust and integrity to safegard your large sums of money. Moving into the mid-90s, some institutions started to realize that such x.509 identity certificates represented huge privacy and liability issues and there was some implementations by financial institutions of relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which only contained a public key and some sort of database lookup index (as unique information) along with a lot of CPS and other types of certification accounting gorp. In this situation, it was trivial to show that such relying-party-only certificates were redundant and superfluous: the relying party already has all the necessary information on file, which invalidates the certificate design point of providing letters of credit type of information between two strangers in first time communicate (where there is no other recourse for information about the party you are dealing with). of course, there was a side issue in these payment protocols from the period. the typical iso8583 payment message is on the order of 60-80 bytes. the typical overhead for even the relying-party-only certificates (attached to every payment message) was on the order of 4k-12k bytes ... leading to an enormous payload bloat of one hundred times for something that was totally redundant and superfluous. In general, the design point of x.509 identity certificates were to turn all transactions (regardless of kind, even the most lightweight authentication transactions) into heavyweight identification operations. You would even find some govs. passing legislation that was oriented towards mandating x.509 identity certificate be appended to every digital signed transaction ... even when you might be looking at purely a lightweight something you have authentication operation. misc. recent posts on the subject: http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Perry E. Metzger wrote: Ah, I see what you mean. Sadly, I don't think there is much to be done about that, but I think that (personally) I'd only end up with two of the things. If they can be made credit card sized, I don't see this as worse than what I have to carry now. there are a couple of issues. in some ways if institutional-centric physical tokens were to be succesful ... you would start to see one in lieu of ever pin, password, /or shared secret ... for every possible type of relationship requiring authentication. there was an issue in the early e-commerce days http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 a lot of the funding for the early commerce server work was targeted at a mall type environment/experience ... where a large outsourcer would provide electronic mall space for retail stores. The apparent assumption was that the physical distance metaphor addressed by shopping malls, would be carried over into the internet. however, the basic characteristic of the internet the world-wide-web already was obliterated physical distance concepts. the issue then was why would a metaphor designed to address physical distance limitations, carry over into an environment where physical distance was a meaningless concept. the issue with many of the existing issued cards and tokens are that they are institutional-centric, one per institution. this could approach the DRM/copy-protect approach of the mid-80s ... where applications were being shipped with unique floppy disks that were required to be mounted anytime the application was executed. an operation with one or two such applications wouldn't be so bad ... but can you imagine that being succesful today? where you might have hundreds of such floppy disks and requirement to have a dozen such floppy disks concurrently mounted in a single floppy drive ... and possibly having to select and exchange floopy disks (from a pile of hundreds) several times a minute. i contend that the physical store checkout and payment model ... where you are physically performing checkout and can likely do only one such at a time has analogies to the shopping mall physical metaphor model ... and it starts to hit limitations when you translate that into internet electronic metaphor with the possibility of multiple things going on concurrently - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Anonymity is a concern to me, too, but I suspect that it is hard to get anonymity in a credit card transaction using current means, even if the merchant isn't online. Pseudonymity, perhaps. Can we not aim higher than merely doing as badly as current systems do? I think that by eliminating the need for a merchant to learn information about your identity I have aimed higher. Given that we're talking about credit instruments, however, it may be difficult to eliminate the need for the issuer to track transactions. However, given the way I've described the protocol, it would be possible to use a variant on it for digital cash purses without the merchant being impacted. It isn't clear to me, though, who would issue such things in the current environment. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Forwarded] RealID: How to become an unperson.
Perry Metzger wrote: So, the next time one of your friends in Germany asks why the crazy Americans think ID cards and such are a bad thing, remember my father, and remember all the people like him who fled to the US over the last couple hundred years and who left children that still remember such things, whether from China or North Korea or Germany or Spain or Russia or Yugoslavia or Chile or lots of other places. And one of those places is the US itself. African-Americans have no trouble envisioning scenarios in which mandatory IDs and universal surveillance could be a problem. Japanese-Americans don't have to think very hard to remember that banking regulation can also be used to freeze bank accounts, or that postal and census data can be used by the Army to put a particular ethnic group in concentration camps. Followers of the Church of Jesus Christ of Latter-day Saints do not believe that vicious religious persecution in the US is an impossibility. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
At 09:29 PM 7/9/2005, Perry E. Metzger wrote: The Blue Card, so far as I can tell, was poorly thought out beyond its marketing potential. I knew some folks at Amex involved in the development of the system, and I did not get the impression they had much of a coherent idea of what the technologies would be used for other than creating marketing buzz. On the other hand, only a short time before that, Apple's iMac created a whole marketing revolution and set of spinoff products and revitalized the company by coming out with a semi-transparent blue-green case that effectively packaged the Reality Distortion Field, and they were able to maintain the effect over several years by the radical introduction of several other semi-transparent colors. It'd be nice if good crypto and authentication methods could create a market for improved products, but hey, if blue-green translucent dancing pigs gets customers, the marketing people have done _their_ job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ID theft -- so what?
I am reminded of a passage from Buffy the Vampire Slayer. In the episode Lie to Me: BILLY FORDHAM: I know who you are. SPIKE: I know who I am, too. So what? My point here is that knowing who I am shouldn't be a crime, nor should it contribute to enabling any crime. Suppose you know who I am. Suppose you know my date of birth, social security number, and great-great-grandmother's maiden name. As Spike said, so what? It's only a problem if somebody uses that _identifying_ information to spoof the _authorization_ for some transaction. And that is precisely where the problem lies. Any system that lets _identification_ serve as _authorization_ is so incredibly broken that it is hard to even discuss it. I don't know whether to laugh or cry. Identifying information cannot be kept secret. There's no point in trying to keep it secret. Getting a new SSN because the old one is no longer secret is like bleeding with leeches to cure scurvy ... it's completely the wrong approach. The only thing that makes any sense is to make sure that all relevant systems recognize the difference between identification and authorization. Repeat after me: identification is not authorization. Identification is not authorization. When people talk about authentication factors such as a) something I know b) something I have c) something I know it is crucial to keep in mind that item (a) must be something I know _that other people don't know_. Identifying information doesn't qualify, and cannot possibly qualify. My SSN is not a password. It lacks many of the properties that a password should have. Credit-card numbers, in practice, do little more than identify me and my account. They are not handled the way passwords should be handled. Eliminating ludicrously broken authentication schemes is something we should work on. Password theft is something we should try to prevent. But when it comes to ID theft, we should say: So what? I've been saying this for years, but it seems timely to say it again. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
On Tue, Jul 12, 2005 at 02:48:02PM -0700, Bill Stewart wrote: | At 09:29 PM 7/9/2005, Perry E. Metzger wrote: | The Blue Card, so far as I can tell, was poorly thought out beyond its | marketing potential. I knew some folks at Amex involved in the | development of the system, and I did not get the impression they had | much of a coherent idea of what the technologies would be used for | other than creating marketing buzz. | | On the other hand, only a short time before that, | Apple's iMac created a whole marketing revolution | and set of spinoff products and revitalized the company | by coming out with a semi-transparent blue-green case | that effectively packaged the Reality Distortion Field, | and they were able to maintain the effect over several years | by the radical introduction of several other semi-transparent colors. | | It'd be nice if good crypto and authentication methods | could create a market for improved products, | but hey, if blue-green translucent dancing pigs gets customers, | the marketing people have done _their_ job. In light of the ID theft drumbeat, companies that don't require your SSN have a marketable edge. I'm waiting for some to use it. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: EMV
In Hong Kong a lot of people do little more than wave their bags at the turnstile. Removing the wallet and revealing its size is unnecessary. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie Sent: Tuesday, 12 July 2005 8:14 PM To: Peter Fairbrother Cc: Florian Weimer; David Alexander Molnar; ? Schmidt; cryptography@metzdowd.com Subject: Re: EMV Peter Fairbrother wrote: 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 ... Which, of course, they would never do if you were extracting money to buy a ticket, or showing your season ticket. Explain to me how the contactless system alters this risk in any way? 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
