Re: Lack of fraud reporting paths considered harmful.
[EMAIL PROTECTED] writes: >> His firm routinely discovers attempted credit card fraud. However, >> since there is no way for them to report attempted fraud to the credit >> card network (the protocol literally does not allow for it), all they >> can do is refuse the transaction -- they literally have no mechanism >> to let the issuing bank know that the card number was likely stolen. > > A former boss has become "Head of Fraud Technology" (I asked him who > was "Head of Anti-Fraud Technology") and he answers like this. > > I am not really a cards man but I would have said the good > old telephone, a call to the acquirer, would be the way. The > acquirer would then pass that on to the issuer. Granted the > merchant may not know for certain that had happened, but he > has done his duty at that point. That's not practical. If you're a large online merchant, and your automated systems are picking up lots of fraud, you want an automated system for reporting it. Having a team of people on the phone 24x7 talking to your acquirer and reading them credit card numbers over the phone, and then expecting the acquirer to do something with them when they don't have an automated system either, is just not reasonable. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Lack of fraud reporting paths considered harmful.
Perry wrote: > His firm routinely discovers attempted credit card fraud. However, > since there is no way for them to report attempted fraud to the credit > card network (the protocol literally does not allow for it), all they > can do is refuse the transaction -- they literally have no mechanism > to let the issuing bank know that the card number was likely stolen. A former boss has become "Head of Fraud Technology" (I asked him who was "Head of Anti-Fraud Technology") and he answers like this. I am not really a cards man but I would have said the good old telephone, a call to the acquirer, would be the way. The acquirer would then pass that on to the issuer. Granted the merchant may not know for certain that had happened, but he has done his duty at that point. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
"Potential Hazards of the Protect America Act"
Matt Blaze blogs about a paper he, Steve Bellovin, Whit Diffie, Susan Landau, Peter Neumann and Jennifer Rexford have written on the hazards of surveillance technologies: http://www.crypto.com/blog/wiretap_risks/ -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
The per-card cost need not be such a big problem. Singapore has a proximity-card-based system. They use the same card both for the long-term cards and for the single-use cards. There is a S$ 2 (IIRC) deposit on the card, which is refunded after the card is used. Waste not want not! /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
more terrorist crypto hype
There has been more hype about "Jihadist" crypto software lately. For example: http://www.eetimes.com/rss/showArticle.jhtml?articleID=205918680 I'll note that the presumed users would probably be better off with a well vetted program like GPG. I'll also note that there is literally no way to prevent people from writing such software, since they are non-US nationals living outside the US. (As much as we would like US law to apply to all foreigners living abroad, that's not how the world works.) None the less, I'll predict that this "news", which has been hyped in several places of late, will be brought up by some as a reason why we must restrict crypto exports, never mind that this "solution" would in no way alter the availability of cryptographic software to terrorists, any more than New York City gun control regulations would prevent AK-47s from reaching fighters in Congo. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Dutch Transport Card Broken
Oberthur Card Systems has a card designed for transit use with 3DES, according to their datasheet (registration required, http://www.oberthurcs.com/get_downloadsection_file.aspx?id=43&otherid=95&typ eid=5) it's certainly fast enough. Interestingly, they also make the card that's failed so spectacularly here... Regards, Jim Cheesman -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Aram Perez Enviado el: viernes, 25 de enero de 2008 5:59 Para: Cryptography Asunto: Re: Dutch Transport Card Broken Hi Folks, > Ed Felten has an interesting post on his blog about a Dutch smartcard > based transportation payment system that has been broken. Among other > foolishness, the designers used a custom cryptosystem and 48 bit keys. Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader. Regards, Aram Perez - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
BSF/DIMACS/DyDAn Workshop on Data Privacy
* BSF/DIMACS/DyDAn Workshop on Data Privacy February 4 - 7, 2008 DIMACS/DyDAn Center, CoRE Building, Rutgers University Organizers: Kobbi Nissim, Ben Gurion University, kobbi at cs.bgu.ac.il Benny Pinkas, University of Haifa, benny at cs.haifa.ac.il Rebecca Wright, Rutgers University, rebecca.wright at rutgers.edu Presented under the auspices of the DIMACS Special Focus on Communication Security and Information Privacy and the Center for Dynamic Data Analysis (DyDAn). An ever-increasing amount of data is available in digital form, often accessible via a network. Not surprisingly, this trend is accompanied by an increase in public awareness of privacy issues and by legislation of privacy laws. The interest in privacy, and the tension between privacy and utility of data, is amplified by our growing ability to collect and store large amounts of data, and our ability to mine meaningful information from it. This workshop will view privacy in a broad sense in order to facilitate interaction and discussion between privacy-oriented researchers in different communities. The study of "privacy" is inherently interdisciplinary, spanning a range of applications and scenarios, such as analysis of census data, detection and prevention of terrorist activity, and biomedical research. There is a fundamental interplay between privacy and law, security, economics, and the social sciences. This workshop will foster interactions between researchers in these fields with those in statistics and computer science, toward the goal of developing problem formulations that can be translated into a technical mathematical language that lends itself to a more rigorous study of privacy. The workshop will contrast these formal definitions with more intuitive notions of privacy from the social sciences, economics, philosophy and law to determine the extent to which they capture the perceived meaning of privacy in different settings. Privacy-preserving technologies may soon become an integral part of the basic infrastructure for the collection and dissemination of official statistics, as well as for research in business, economics, medical sciences, and social sciences. Functional solutions for preserving privacy would therefore serve as a central part of the infrastructure for those disciplines. This workshop will address a variety of questions on algorithms for privacy-preserving analysis such as: * To what extent can such techniques be applied to statistical data? * What are the consequences to privacy and confidentiality if such techniques are not used? * Are changes in statistical tools needed to make them compatible with such techniques? * Can the techniques be modified to allow use of standard statistical tools and practices? ** Program: Monday, February 4, 2008 8:00 - 8:50 Breakfast and Registration 8:50 - 9:00 Welcome and Opening remarks Rebecca Wright, DIMACS Deputy Director 9:00 - 10:00 Tutorial: Differential Privacy Adam Smith, Penn State University 10:00 - 10:30 PINQ Frank McSherry 10:30 - 11:00 Break 11:00 - 12:00 Tutorial: Smooth Sensitivity and Sampling Sofya Raskhodnikova, Penn State University 12:00 - 12:30 Tutorial: Exponential Mechanism Kunal Talwar 12:30 - 2:00 Lunch 2:00 - 3:00 Tutorial: Statistical Methods Alexandra Slavkovic 3:00 - 3:30 Break 3:30 - 4:30 Tutorial: Synthetic Data John Abowd Tuesday, February 5, 2008 8:30 - 9:00 Breakfast and Registration 9:00 - 10:30 Tutorial: Secure Multiparty Computation and Privacy-Preserving Data Mining Yehuda Lindell, Bar Ilan University 10:30 - 11:00 Break 11:00 - 11:35 The Difficulty of Preventing Disclosure Moni Naor 11:35 - 12:05 E Gov, Online Citizen Scrutiny and Participation - The Joint Challenges for Cryptologists and Policy Makers Tal Zarsky, University of Haifa 12:05 - 12:30 Robust De-anonymization of Multi-dimensional Databases Vitaly Shmatikov, The University of Texas at Austin 12:30 - 2:00 Lunch Statistics: 2:00 - 2:25 Privacy: Theory Meets Practice on the Map John Abowd 2:25 - 2:50 A Hybrid Perturbation/Swapping Approach for Masking Numerical Data Rathindra Sarathy, Oklahoma State University 2:50 - 3:20 Break 3:20 - 3:45 Deterministic History-Independent Strategies for Storing Information on Write-Once Memories Gil Segev, Weizmann Institute of Science 3:45 - 4:10 Cell Suppressions Leak Information Shubha Nabar, Stanford University 4:10 - 4:35 A Learning Theory Perspective on Data
Re: Dutch Transport Card Broken
Moin, Am Thu, 24 Jan 2008 20:58:38 -0800 schrieb Aram Perez: > Not to defend the designers in any way or fashion, but I'd like to > ask, How much security can you put into a plastic card, the size of > a credit card, that has to perform its function in a secure manner, > all in under 2 seconds (in under 1 second in parts of Asia)? And it > has to do this while receiving its power via the electromagnetic > field being generated by the reader. Hmm, how about Triple-DES for starters? :-) There are cards using 3DES (called Mifare DESfire) available from the same manufacturer (NXP) as the Mifare Classic cards with the proprietary algorithm that we looked at. Apparently the main difference is that DESfire cards cost 1.50 EUR per piece while Classic cards are at 0.50 EUR per piece. Other public transport systems, such as Madrid, did the sensible thing and chose DESfire: http://www.nxp.com/news/identification/articles/otm81/madrid/ -- Henryk Plötz Grüße aus Berlin ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ pgpsmBWu8tOGO.pgp Description: PGP signature
Re: Dutch Transport Card Broken
Aram Perez wrote: Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader. we sort of saw that in the mid-90s when we were doing the x9.59 financial standard http://www.garlic.com/~lynn/x959.html#x959 and getting comments that it wasn't possible to have both low cost and high security at the same time. we looked at it and made the semi-facetious statements that we would take a $500 milspec part and aggresively cost reduce it by 2-3 orders of magnitude will improving the security. along the way we got tapped by some in the transit industry to also be able to meet the (then) transit gate requirements (well under 1 second and do it within iso 14443 power profile). part of it was having to walk the whole end-to-end process ... all the way back to chip design and fab manufacturing process ... little drift about walking fab in a "bunny suit" http://www.garlic.com/~lynn/2008b.html#13 we effectively did get it on close to the RFID chip (i.e. the one that they are targeting for UPC) technology curve ... i.e. chip fabrication cost is roughly constant per wafer ... wafer size and circuit size have been leading to higher number of chips per wafer (significantly reducing cost/chip). As circuit size shrank with a corresponding shrinkage in the size of chips (that didn't have corresponding increase in number of circuits) there was a "blip" on the cost/chip curve as the area of the cuts (to separate chips in the wafer) exceeded the (decreasing) chip size. Earlier this decade there was a new cutting process that significantly reduced the "cut" area ... allowing yield of (small) chips per wafer to continue to significantly increase (allowing pushing close to four orders of magnitude reduction ... rather than 3-4 orders of magnitude reduction). aads chip strawman references http://www.garlic.com/~lynn/x959.html#x959 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
my impression has been that with lack of takeup of various kinds of security solutions that were extensively marketed in the 90s ... that the current situation has many of those same organizations heavily involved in behind the scenes lobbying saw some of that nearly a decade ago when we were brought in to help wordsmith the cal. state electronic signature legislation which led to also be brought in on federal electronic signature legislation ... some past posts http://www.garlic.com/~lynn/subpubkey.html#signature some other references ... Hackers break into transport smart card http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php Transport smart card hacked again (update) http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
> How much security can you put into a plastic card, the size of a > credit card, that has to perform its function in a secure manner, all > in under 2 seconds (in under 1 second in parts of Asia)? And it has to > do this while receiving its power via the electromagnetic field being > generated by the reader. The 24C3 presenters to their credit made this exact point. But mixing the 16-bit nonce with the card identifier was an optimization too far. That said, it's a hard problem. Inside Picopass is one of many examples that progress is possible. IMHO as always. Cheers, Scott - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Aram Perez <[EMAIL PROTECTED]> writes: >> Ed Felten has an interesting post on his blog about a Dutch smartcard >> based transportation payment system that has been broken. Among other >> foolishness, the designers used a custom cryptosystem and 48 bit keys. > > Not to defend the designers in any way or fashion, but I'd like to > ask, How much security can you put into a plastic card, the size of a > credit card, that has to perform its function in a secure manner, all > in under 2 seconds (in under 1 second in parts of Asia)? Several other transit systems have payment cards that have proven remarkably resilient to attack. For example, the NYC "Metrocard" system has been attacked repeatedly without significant breaks (but it does not rely on its cards being tamperproof -- it is an online system using magstripes.) The authors of the paper on the Dutch break claim that it would have been possible to use far more secure means even given the basic design, such as a non-proprietary crypto algorithm and longer keys. I see no real reason to disbelieve this. In any case, if it was not possible to do this with smartcards, existing, well proven mechanisms that are in use in other transit systems could have been adopted. It is not necessary to use an unimplementable architecture when implementable and proven architectures exist. Often we hear of a false need for "engineering tradeoffs" in such circumstances. Engineering tradeoffs do indeed sometimes become critical in security design. However, you should be very skeptical when someone claims that they "need" to use a home grown crypto algorithm or that they "need" to use a home grown protocol instead of a well proven one. Generally these are not "engineering tradeoffs" but reflections of ignorance on the part of the designers. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Hi Folks, Ed Felten has an interesting post on his blog about a Dutch smartcard based transportation payment system that has been broken. Among other foolishness, the designers used a custom cryptosystem and 48 bit keys. Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader. Regards, Aram Perez - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Perry E. Metzger wrote: Ed Felten has an interesting post on his blog about a Dutch smartcard based transportation payment system that has been broken. Among other foolishness, the designers used a custom cryptosystem and 48 bit keys. http://www.freedom-to-tinker.com/?p=1250 The Dutch government paid two billion dollars for stupidity, for foolishness that almost anyone on this list could have told them was foolish. Secret algorithm! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
