Re: mother's maiden names...
In message [EMAIL PROTECTED], R.A. Hettinga writes: At 12:26 PM -0400 7/13/05, Perry E. Metzger wrote: Why do banks not collect simple biometric information like photographs of their customers yet? Some do. Cambridge Trust puts your picture on the back of your VISA card, for instance. They have for more than a decade, maybe even two. One New York bank -- long since absorbed into some megabank -- did the same thing about 30 years ago. They gave up -- it was expensive then, and may not have solved any real problems. (Possibly, it simply didn't fit their real purpose of attracting more customers.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
On Wednesday 13 July 2005 18:29, Mike Owen wrote: Back in 2000, I opened an account with BofA, and they took a photo of me, and added it to my debit/check card. Around that same time, American Express was doing the same with their Costco branded cards. I'm sure others are doing it, those are just the ones I have experience with. FYI, that's a feature of Costco, not AmEx. Costco requires a picture because the card is used in place of a normal Costco card to get admitted into the store. They are somewhat ruthless about sharing cards for personal memberships. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
On Wednesday 13 July 2005 23:31, Dan Kaminsky wrote: This is yet more reason why I propose that you authorize transactions with public keys and not with the use of identity information. The identity information is widely available and passes through too many hands to be considered secret in any way, but a key on a token never will pass through anyone's hands under ordinary circumstances. It's 2005, PKI doesn't work, the horse is dead. He's not proposing PKI, but nymous accounts. The account is the asset, the key is the owner; at the simplest conceptual level it is the difference between Paypal and e-gold. But, thank the heavens that we now have reached the point where people can honestly say that PKI is the root cause of the problem. Can you now tell the browser people? The credit-card sized number dispensers under development are likely to be what comes next. Right, alongside nyms on a spectrum is big random number-sized tokens. If you want to get sexy, go for the blinded ones. It's all the same infrastructure, we call it FC. Amusingly, your face is an asymmetric authenticator -- easy to recognize, hard to spoof. True, but also easy to copy and can be stolen. For some value, you don't want to go there. https://www.financialcryptography.com/mt/archives/000440.html 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: the limits of crypto and authentication
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, Wasn't that a goal of SET? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
Perry E. Metzger [EMAIL PROTECTED] writes: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which I could not have forged? I don't know about photos specifically, but I know that signature imprints are often still moved around by laborious manual means because the background infrastructure to handle images doesn't exist. Most banks are still using 3270-style interfaces, even if they have a screen-scraped GUI front-end. There simply isn't any provision for handling anything other than basic text records - the data-centre back-ends are text-record based (and in some cases the text is EBCDIC), the communications channels send and receive text records (often at a few kbps over leased lines, X.25, or PSTN dialup), and the branch software processes text records. So using images (of any kind) isn't just a case of making an executive decision to do so, it would involve a massive, end-to-end infrastructure upgrade to implement. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: UK EU presidency aims for Europe-wide biometric ID card
when we were called into help word-smith the cal. state and later the fed. electronic signature law ... a lot of effort went into making the wording technology agnostic as well as trying to avoid confusing authentication and identification. We've been discussing those very same topics within Europe for many years now. When some EU Member States (Germany, Austria, ...) already had very stringent signature laws the EU was kind of forced to act. They tried to enact a signature directive which they thought would be as technology neutral as possible. And although that approach seemed to be a good one they failed: they were overambitious wrt certain issues, what's more the implementation of the directive into national legislation lead to 20+ different EU signature laws: http://www.pki-page.info/eu/ In 2003 we wrote a report for the European Commission, trying to compare the situation throughout the Member States as well as focussing on practical applications: http://www.law.kuleuven.ac.be/icri/itl/elsig.php http://www.secorvo.de/publikationen/electronic-sig-report.pdf Cheers, Stefan. --- Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Ettlinger Straße 12-14, D-76137 Karlsruhe Tel. +49 721 255171-304, Fax +49 721 255171-100 [EMAIL PROTECTED], http://www.secorvo.de/ --- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
On Wed, Jul 13, 2005 at 12:26:52PM -0400, Perry E. Metzger wrote: A quick question to anyone who might be in the banking industry. Why do banks not collect simple biometric information like photographs of their customers yet? Some, like Citibank do. I have a photo on my VISA from them, but I believe the photo is not linked to the account nor taken into consideration when doing identification at the bank. When I asked about it, the answer was something about that the photo is stored only by the credit card issuing center, and not in the main system. Random peeking on clerk's screen while I'm at the bank seems to confirm this - no place for customer picture in the account info. Sometimes they aren't allowed to do so, data privacy policy here says that a business may not request or store any personal information that is not directly needed to conduct business with that person; a national ID card is routinely xeroxed when establishing an account and the copy is kept at the bank, then the photo is blackened out; when the regulation came live bank staffs had working weekends sitting with black felt-tip pens, blacking out photos and other unneeded info on the ID xerocopies. Alex -- mors ab alto 0x46399138 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
[EMAIL PROTECTED] (Peter Gutmann) writes: Perry E. Metzger [EMAIL PROTECTED] writes: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which I could not have forged? I don't know about photos specifically, but I know that signature imprints are often still moved around by laborious manual means because the background infrastructure to handle images doesn't exist. Most banks are still using 3270-style interfaces, even if they have a screen-scraped GUI front-end. That's true. Several banks I deal with in New York use displays that are disturbingly 3270-like. That brings up another thing that has always tickled the back of my mind -- I have never actually had a professional opportunity to analyze any of the systems used by tellers in commercial banks, and I always wonder at what is securing the links between small branches and HQ, and how bad the protection of the user passwords etc. might be... So using images (of any kind) isn't just a case of making an executive decision to do so, it would involve a massive, end-to-end infrastructure upgrade to implement. Yah, true enough -- which also impedes things like letting branch managers to look at check images, signatures, etc. Groan... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
Ian Grigg [EMAIL PROTECTED] writes: It's 2005, PKI doesn't work, the horse is dead. He's not proposing PKI, but nymous accounts. The account is the asset, the key is the owner; Actually, I wasn't proposing that. I was just proposing that a private key be the authenticator for payment card transactions, instead of the [name, card number, expiration date, CVV2] tuple -- hardly a revolutionary idea. You are right, though, that I do not propose that any PK_I_ be involved here -- no need for certs at all for this application. I don't claim this is a remotely original idea, by the way. I'm just flogging it again. But, thank the heavens that we now have reached the point where people can honestly say that PKI is the root cause of the problem. Root Cause of the Problem isn't correct either. It is better to say that PKI doesn't solve many of the hard problems we have, or, in some cases, any problems -- it doesn't per se cause any problems, or at least not many. This is not a new realization -- this goes back a long way. People were saying PKI was a bad idea a decade ago or more. A number of the people here, including me, gave talks on that subject years ago. I spoke against PKI during the debate I was invited to at the Usenix Electronic Commerce Workshop in 1998 or so, and at many opportunities before and since. Dan Geer has a pretty famous screed on the subject. Peter Gutmann talks about the follies of X.509 so often it is hard to keep up. I don't mean to single us out as visionaries -- we were just saying things lots of other people were also saying. Honestly, where have you been? Can you now tell the browser people? I can smell the rest of this discussion right now, Ian. You'll misunderstand the constraints the browser people are under, and start claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm not playing the game. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Rich Salz [EMAIL PROTECTED] writes: 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, Wasn't that a goal of SET? Some of it was, yah. I don't claim that any of this is original. The problem with SET was that the protocol was far too complicated to implement (hell, the spec was nearly too heavy to lift), and it was proposed well before people even had USB connectors on their computers, let alone cheap USB card interfaces. I think people threw out the baby with the bathwater, though. The general idea was correct. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
Jörn Schmidt [EMAIL PROTECTED] writes: The answer to this dilemma? I'm afraid this time it really is legislation. Frankly, I'm not even sure if that would work but, at this time, it's our best shot. Congress won't do anything about this unless a few representatives have their identities stolen and experience first-hand what a PITA it is to have to deal with the fallout. I agree that legislative changes are necessary, but I think they are fairly small. Consider the following: Alice is a model citizen with a good credit history Bob steals Alice's identity by finding out semi-public static information Bob gets a loan from Charlie under Alice's identity, where Charlie transfers something of value to Bob and records a debt from Alice. Here, Bob has committed a crime, and this being a crime isn't controversial. Until this point, Alice hasn't really been harmed unless she tries to interact with Charlie herself. Charlie tries to collect from Alice, or Charlie reports that Alice owes a debt to a third party, or Charlie reports that Alice is in default to a third party. In my view, _Charlie_ has comitted a tort against Alice because he has been negligent (or at least incorrect) in issuing credit. If Charlie has decided to issue credit with minimal checks because the business benefit of that is more than the fraud losses (similar to our credit card system today), then it's only fair for Charlie to cover the full burden to Alice, including all the effort of cleanup. If Charlie isn't being careful to the some degree, so that such incidents are rare, triple damages are probably in order. Even if Charlie is very careful, actual damages should be paid. A reasonable penalty for Charlie might be on the order of $1000 statutory damages plus $100/hr for any time over two hours Alice has to spend dealing with the issue, plus any legal fees incurred if any problems remain 30 days after the first report. This puts the onus on Charlie and the reporting systems will quickly adjust to enable Charlie to withdraw the incorrect report completely and quickly. Of course, Charlie should be able to recover all of his own costs, as well as payments to Alice, in triplicate from Bob. Many credit issuers willfully conduct their business with the knowledge that this will occur. So, as I see it the basic problem is not one of security, but the fact that credit issuers etc. impose costs on innocent third parties and get away with it. -- Greg Troxel [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
Steven M. Bellovin wrote: Cambridge Trust puts your picture on the back of your VISA card, for instance. They have for more than a decade, maybe even two. One New York bank -- long since absorbed into some megabank -- did the same thing about 30 years ago. They gave up -- it was expensive then, and may not have solved any real problems. (Possibly, it simply didn't fit their real purpose of attracting more customers.) They don't for example seem to reduce fraud -- shop staff don't compare the photo to the customer carefully enough: R. Kemp, N. Towell, G. Pike, When seeing should not be believing: Photographs, credit cards and fraud, Applied Cognitive Psychology Vol 11(3) (1997) pp 211-222. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EMV
AFAIK, the cards are still the same (Sony FeliCa: http://www.sony.net/Products/felica/): I never changed mine since I got it several years ago. The same card was also adopted in 2002 by EZ-Link in Singapore (http://www.ezlink.com.sg ). Enzo - Original Message - From: Anne Lynn Wheeler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Ben Laurie' [EMAIL PROTECTED]; 'Peter Fairbrother' [EMAIL PROTECTED]; 'Florian Weimer' [EMAIL PROTECTED]; 'David Alexander Molnar' [EMAIL PROTECTED]; '? Schmidt' [EMAIL PROTECTED]; cryptography@metzdowd.com Sent: Wednesday, July 13, 2005 8:55 AM Subject: Re: EMV ... the original introduction of HK octopus transit card used the sony flavor of iso 14443 with 10cm and transit requirements of transaction in 100ms. having it in the bottom of a bag and bringing the bag within 10cm of the reader does the trick. there was a transit meeting where the mondex people attended ... they claimed that they could also be used for transit ... just get a wireless sleave for the mondex card ... and build 14' long tunnels leading up to the transit gates ... and have the people walk slowly thru the tunnels. Gabriel Haythornthwaite wrote: 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. - 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: mother's maiden names...
On Wed, 13 Jul 2005, Perry E. Metzger wrote: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which I could not have forged? While we are very good at recognizing somebody we know on a picture, it is in fact very hard to answer the following question: is the person in front of you is the same person who is depicted on the photo? AFAIR there were experiments which show that if you just get a random photo of a person with the same race, age, and gender as you have you have very good probability to successfully pretend that you are the person on the picture. As a result the criminal don't really need to change the photo to be able to pretend that he is you. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Rich Salz wrote: Wasn't that a goal of SET? there was an observation that SET possibly wouldn't divulge your account number until the merchant had been determined to be some entity registered as a merchant (akin to the SSL domain name infrastructure certificates ... if a spoofed site didn't use SSL until you hit the pay/checkout button, what is the probability that the spoofed site provide a URL that matched some valid certificate that they did have). note, however, some of the participants even got confused about this issue. note that there are a lot of merchant business processes that require the account number ... and therefor you can't prevent the merchant from possessing the account number. some might be tempted to observe that there is a kind of conflict of interest ... using the same value for authentication purposes as well as widely needed for a large number of other purposes (akin to designing a system that widely uses your userid a basis for normal functioning ... as well as making your userid also your password). some past posts where the SET issue of divulging account number was disucssed. http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards I thot the goal of SET was to maximize the number of RSA-ops being executed in the world. When I first obtained a copy of the initial SET specification, I did a RSA-ops profile and a business operation profile. An acquatance had done some work on the BSAFE library and improved the performance by a factor of four times. I got him to run timing tests on the SET RSA-ops profile across a number of different machines. I then communicated the results to a number of people that were part of the SET group. The reply from various members of the SET group was that the numbers were obviously one hundred times too slow (the correct answer should have been that the numbers were four times too fast). Six months later when the first prototype SET code was running ... their measured numbers were within a couple percent of my earlier profile numbers (aka the BSAFE enhancements had been given back to RSA). One possible observation was that SSL work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 was already providing account number confidentiality for *data-in-flight*. The significantly much more complex, and heavyweight SET would have needed to provide countermeasures for significantly more threats and vulnerabilities ... like security for *data-at-rest* (aka data breaches) in order to make any headway against the (SSL) incumbant. I also made a couple comments to the SET group about the heavy-weight nature of SET (apparently the RSA-ops being one hundred times more onerous than they had anticipated). Effectively, the SET RSA-op profile was symmetrical but the standard processing is quite asymmetrical. In effect, the massive datacenters that are currently processing credit card transactions would have needed their computational facilities increased by at least one hundred times (SET RSA-op profile was looking at tens of seconds per transaction while many of these datacenters measure their thruput in thousands of transactions per second ... a four orders of magnitude gap). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
(Dan, in answer to your question on certs, below.) On Thursday 14 July 2005 14:19, Perry E. Metzger wrote: Ian Grigg [EMAIL PROTECTED] writes: It's 2005, PKI doesn't work, the horse is dead. He's not proposing PKI, but nymous accounts. The account is the asset, the key is the owner; Actually, I wasn't proposing that. I was just proposing that a private key be the authenticator for payment card transactions, instead of the [name, card number, expiration date, CVV2] tuple -- hardly a revolutionary idea. You are right, though, that I do not propose that any PK_I_ be involved here -- no need for certs at all for this application. I don't claim this is a remotely original idea, by the way. I'm just flogging it again. Well, that's helpful. Having built one or two of these things (and I know of 3 others on the list that have done the same thing) it helps to know we aren't starting from scratch. But, thank the heavens that we now have reached the point where people can honestly say that PKI is the root cause of the problem. Root Cause of the Problem isn't correct either. It is better to say that PKI doesn't solve many of the hard problems we have, or, in some cases, any problems -- it doesn't per se cause any problems, or at least not many. This is not a new realization -- this goes back a long way. OK, so maybe this part is the new realisation: The browser security model includes PKI for two purposes - MITM protection and spoofing protection. Ignoring MITM (today), the spoofing protection is supposed to alert the user that the cert and the site don't match. Phishing is a spoof - the wrong site is used. So SSL+PKI should pick that up. It isn't. Why? Simply put because the browser too easily lets SSL's anti-spoofing protection not be seen. It's not being done properly. Why is that? Because the browser people are under severe constraints - your words - and nobody is correcting their missunderstandings. No security folk, no security companies, no CAs, just a few researchers (some lurking here...). Too many words? OK, here's the short version of why phising occurs: Browsers implement SSL+PKI and SSL+PKI is secure so we don't need to worry about it. PKI+SSL *is* the root cause of the problem. It's just not the certificate level but the business and architecture level. The *people* equation. People were saying PKI was a bad idea a decade ago or more. A number of the people here, including me, gave talks on that subject years ago. I spoke against PKI during the debate I was invited to at the Usenix Electronic Commerce Workshop in 1998 or so, and at many opportunities before and since. Dan Geer has a pretty famous screed on the subject. Peter Gutmann talks about the follies of X.509 so often it is hard to keep up. I don't mean to single us out as visionaries -- we were just saying things lots of other people were also saying. Honestly, where have you been? I've been over at Mozilla trying to tell them the PKI isn't doing it's job. Peter Gutmann and Amir Herzberg have been there supporting this push. They're not visionaries either but at least they put their money where their mouths are - trying to get Mozo people to touch up the PKI + SSL code to deal with spoofing. (Demos and code available on request ) We recently set up a new group for all anti-phishing researchers so they could congregate and cross-fertilise ideas in a scientific fashion. I'm proud to say that in less than one month our understanding of phishing and the browser security model has significantly advanced. We've talked to dozens of programmers over on the Mozilla camp, sadly without success and I think that's because the crypto community has been relatively silent on this issue. Most over in the browser community remain simply unaware and uneducated on the reasoning behind the security model, and how out of date it is. So, where have you been, Perry? If you wish to patronize me (on a public list, with no right of reply!) do so from a position of strength. Can you now tell the browser people? I can smell the rest of this discussion right now, Ian. You'll misunderstand the constraints the browser people are under, and start claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm not playing the game. Perry, for the last few months or so the game you have been playing is disagree with Ian, rag him in public, drop his posts. I don't mind .. but as I showed above, you are 100% diametrically wrong about what it is I am saying or likely to say. Just so you're aware that you're inventing the rest of the discussion and disagreeing with your own invention... 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
Re: ID theft -- so what?
RANT-PET_PEEVEWhy do cryptography folks equate PKI with certificates and CAs? This fallacy is a major root cause of the problem IHO. Why was the term PKI invented in the late 70s/early 80s (Kohnfelder's thesis?)?. Before the invention of asymmetric cryptography, didn't those people who used symmetric cryptography need an SKI (secret key infrastructure) to manage keys? But no one uses the term SKI or talks about how to manage secret keys (a very hard problem). Anytime you use any type of cryptography, you need an infrastructure (http://en.wikipedia.org/wiki/Infrastructure) to manage your keys, whether secret or public. There are at least two public key infrastructures that do NOT require CAs: PGP and SPKI. But like in so many real life cases, the best technology does not always win and we are stuck with the system that garnered the most business/ economic support./RANT-PET_PEEVE Respectfully, Aram Perez On Jul 14, 2005, at 6:19 AM, Perry E. Metzger wrote: Ian Grigg [EMAIL PROTECTED] writes: It's 2005, PKI doesn't work, the horse is dead. He's not proposing PKI, but nymous accounts. The account is the asset, the key is the owner; Actually, I wasn't proposing that. I was just proposing that a private key be the authenticator for payment card transactions, instead of the [name, card number, expiration date, CVV2] tuple -- hardly a revolutionary idea. You are right, though, that I do not propose that any PK_I_ be involved here -- no need for certs at all for this application. I don't claim this is a remotely original idea, by the way. I'm just flogging it again. But, thank the heavens that we now have reached the point where people can honestly say that PKI is the root cause of the problem. Root Cause of the Problem isn't correct either. It is better to say that PKI doesn't solve many of the hard problems we have, or, in some cases, any problems -- it doesn't per se cause any problems, or at least not many. This is not a new realization -- this goes back a long way. People were saying PKI was a bad idea a decade ago or more. A number of the people here, including me, gave talks on that subject years ago. I spoke against PKI during the debate I was invited to at the Usenix Electronic Commerce Workshop in 1998 or so, and at many opportunities before and since. Dan Geer has a pretty famous screed on the subject. Peter Gutmann talks about the follies of X.509 so often it is hard to keep up. I don't mean to single us out as visionaries -- we were just saying things lots of other people were also saying. Honestly, where have you been? Can you now tell the browser people? I can smell the rest of this discussion right now, Ian. You'll misunderstand the constraints the browser people are under, and start claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm not playing the game. Perry - 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
On Jul 14, 2005, at 6:23 AM, Perry E. Metzger wrote: Rich Salz [EMAIL PROTECTED] writes: 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, Wasn't that a goal of SET? Some of it was, yah. I don't claim that any of this is original. The problem with SET was that the protocol was far too complicated to implement (hell, the spec was nearly too heavy to lift), and it was proposed well before people even had USB connectors on their computers, let alone cheap USB card interfaces. I think people threw out the baby with the bathwater, though. The general idea was correct. While the SET protocol was complicated, it's failure had nothing to do with that fact or the lack of USB on PCs. You could buy libraries that implemented the protocol and the protocol did not require USB. IMO, the failure had to do with time-to-market factors. In the late 90s, when ecommerce was just at it's infancy and you took the risk of setting up a web store, were you going to wait you could integrate a SET toolkit into you web site and until your customers had SET wallets installed on their PCs before selling a product? Or were you going to sell to anyone who used a web browser that supported SSL? It was very simple economics, even if you had to pay VeriSign $400 for your SSL certificate and pay Visa/MasterCard a higher fee. Respectfully, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Pat Farrell wrote: On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote: I think that by eliminating the need for a merchant to learn information about your identity ... Wasn't that a goal of SET? As I recall, the goal of SET was to have a standard that was not invented by CyberCash. (I may be biased, I worked at CyberCash at the time). This is incorrect. The main politics around SET was the artificial `merger` of iKP (from IBM Mastercard) and STT (from Visa and MS). As far as I remember, CyberCash were involved but choose not to. They also did not disclose their protocol like the other proposals. I may be wrong about the CyberCash role, though, it was a while, and I don't think it matters so much... -- 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: ID theft -- so what?
From: Aram Perez [EMAIL PROTECTED] Sent: Jul 14, 2005 10:45 AM To: Cryptography cryptography@metzdowd.com Subject: Re: ID theft -- so what? RANT-PET_PEEVEWhy do cryptography folks equate PKI with certificates and CAs? One nontrivial reason is that many organizations have spent a lot of time and money building up elaborate rules for using PKI, after long negotiations between legal and technical people, many hours of writing and revising, gazillions of dollars in consultants' time, etc. So, anytime you start doing anything involving public key cryptography, all this machinery gets invoked, for bureaucratic reasons. That is, you've now trespassed on PKI turf, and you'll have to comply with this enormous set of rules. I know of a couple cases where this led to really irritating results. In one, a friend of mine was using a digital signature to verify some fairly trivial thing, but was told it was against policy to use a digital signature without the whole PKI. (I believe he changed the documentation, so that he was using a modular arithmetic checksum instead of a signature verification.) As a consultant, I designed and evaluated a lot of systems that used public key cryptography. None of the successful ones tried to use the whole X.509 + CRL + CPS + everything else overhead--typically, they just used a one-deep hierarchy, where the keypair was put into the device by the manufacturer along with a copy of the top-level public key used to sign all device public keys. This works, because it doesn't try to incorporate the output of 20 years of make-work programs in cryptography (they weren't intended that way, but that's largely how they turned out), and it doesn't try to incorporate every idea that might be useful anywhere in the world into some very limited and simple application. Aram Perez --John Kelsey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
Ian Grigg [EMAIL PROTECTED] writes: This is not a new realization -- this goes back a long way. OK, so maybe this part is the new realisation: No, it isn't a new realization either, Ian. We all knew from nearly the start that the model we were using in browsers was wrong. I don't know anyone who defends it. Netscape threw SSL together in a hurry -- so much of a hurry that the first version of the protocol wasn't even any good -- and threw a bunch of certs right into the browser to bootstrap it, and no one has particularly liked the situation ever since. That doesn't mean that people are interested in throwing the baby out with the bathwater, either, as you have in suggesting that people should just send credit card numbers in the clear because passive interception is (you have claimed) not an issue. Too many words? OK, here's the short version of why phising occurs: Browsers implement SSL+PKI and SSL+PKI is secure so we don't need to worry about it. I am unaware of real security professionals who hold that opinion or ever held it, or even a variation on it. Perhaps there are a handful out there, but it isn't the majority. Again, you are telling people what they already know. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Aram Perez wrote: While the SET protocol was complicated, it's failure had nothing to do with that fact or the lack of USB on PCs. You could buy libraries that implemented the protocol and the protocol did not require USB. IMO, the failure had to do with time-to-market factors. In the late 90s, when ecommerce was just at it's infancy and you took the risk of setting up a web store, were you going to wait you could integrate a SET toolkit into you web site and until your customers had SET wallets installed on their PCs before selling a product? Or were you going to sell to anyone who used a web browser that supported SSL? It was very simple economics, even if you had to pay VeriSign $400 for your SSL certificate and pay Visa/MasterCard a higher fee. can you say that that processing overhead was on the order of 20-30 seconds (on completely unloaded infrastrucutre ... demos at shows and conferences ... can you imagine what a little bit of queuing load would do to it?) ... if merchants thot SSL was onerous ... just imagine what SET did to the infrastructure and it provided effectively no additional improvement over fraud vis-a-vis effectively only addressing the confidentiality of account numbers as data-in-flight. SSL was the encumbant, was significantly less complex and significantly lighter weight (even tho most merchants decided that it was too heavy except for the credit card portion) and provided effectively the same amount of anti-fraud as SET. If you had two products ... both effectively performing the same function, one you already had deployed, which was significantly cheaper, significantly simpler, and significantly faster, which one would you choose? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
Pat Farrell wrote: As others have said, and in the spirit of the subject of this thread, SET failed for many reasons, many of them economic. There was little effort made to bribe the merchants, I think there was talk of a 26 basis point change in the discount rate, which the banks thought was huge and the merchants thought was noise. What really killed it was the billions it would have cost all the banks to issue and manage all the certificates. this was some of the confusion between identification and authentication. The SET effort was smart enuf to not do x.509 identity certificates and instead do relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo and they even made comments about the enormous privacy and liability issues raised with x.509 identity certificates. They also avoided doing any sort of PKI infrastructure ... aka the management and administration of the certificates. The effectively were doing the same stuff as the original SSL domain name certificates ... for which we coined the term certificate manufactoring (to differentiate from a certificate administrative and management operation). They basically said that the certificate only contained the account number ... and the account number could be turned-off at the issuing financial institution ... making it redundant and superfluous to also have to have a separate infrastructure for invaliding the certifcate. So they have an online infrastructure with real-time transactions and real-time operation of the real information. It is an extremely trivial additional step to show that then the certificates themselves are redundant and superfluous. The cost of the certificates only become an issue if you are talking about having to pay a trusted third party, $100/annum for every certificate. So we can take this in incremental steps. 1) you have the consumer's financial infrastructure register the public key. they then can generate and issue a relying-party-only certificate to the consumer (containing the consumer's public key and account number). 2) there was work started in X9 financial standards body on compressed certificates. Even the SET relying-party-only certificate overhead ran 4k-12k bytes. The typical iso8583 financial message is on the order of 60-80 bytes. Even the trivial SET relying-party-only certificates represented a payload bloat of one hundred times (besides the RSA-ops inflating processing overhead by 3-4 orders of magnitude). 3) Because of the enormous payload bloat contributed by the certificates, the digital signature processing was being truncated at the internet boundary and a standard iso 8583 message was then generated with a flag turned on indicating that the internet had validated the digital signature. The merchants had an incentive to see that flag turned on since that was the basis on which a lower discount was calculated. At an ISO meeting in europe ... one of the association network people presented statistics on the number of iso 8583 messages that they found with the flag turned on and they could prove that no digital signature technology could have been involved 4) I presented an argument that a valid compressing technology is to eliminate all fields from the (certificate) contents that were known to already be in possession of the relying party. Since it could be proved that all fields in the SET relying-party-only certificate were already on file with at the consumer's financial institutions ... it would be possible to eliminate all fields from the relying-party-only certificates. If they preferred, i would start describing the process of appending zero byte digital certificates as an alternative to describing certificateless digital signature operation http://www.garlic.com/~lynn/subpubkey.html#certless 5) The consumer's financial institution could effectively use the existing business processes for registering PINs as a mechanism for registering public keys. That is not known to be an expensive business process. A consumer's financial institution then could set up a website where the consumer could later retrieve their (redundant and superfluous relying-party-only) digital certifcate. There is some integrity constraints here ... but since the purpose of a digital certificate is to spray it all over the world ... there isn't a lot of confidentiality constraints (i.e. it doesn't hurt a lot if other people pick up your digital certificate). However, since both the public key and the digital certificate would already be on file ... you could require people to perform digital signature authentication before picking up their redundant and superfluous digital certificate. This does have an unfortunate downside since it highlights that consumer digital signatures can be validated by onfile public keys w/o needing digital certificates 6) there were lots of comments that leaving all the PKI gorp in the hands of trusted third parties was a trade-off of the
Blind Signature Patent Expiration Party this Saturday
Forwarded at Lucky's request: Date: Thu, 14 Jul 2005 18:28:40 +0200 From: Lucky Green [EMAIL PROTECTED] Subject: Blind Signature Patent Expiration Party this Saturday Friends, colleagues, and co-conspirators, It has been 17 long years and now the time is finally here to celebrate at the: BLIND SIGNATURE PATENT EXPIRATION PARTY === WHAT: A party to celebrate the expiration of the Blind Signature patent. WHY: U.S. Patent 4,759,063 (Blind Signature Systems) to David Chaum is the core invention enabling privacy-protecting electronic payment systems and credentials. It was a truly ingenious, ground-breaking contribution. Unfortunately the existence of the corresponding patent, which was notoriously difficult to license, prevented this great invention from receiving the wide use that it so very much deserved. For a copy of the patent, see http://www.pat2pdf.org/pat2pdf/foo.pl?number=4759063 Unlike copyrights these days, patents do expire. The blind signature patent will expire on July 19, 2005, next Tuesday. Since weekends tend to fit better with the schedules of potential party goers than weekdays, we are holding the party this Saturday instead. The 17 years that this patent has been in effect has been an awfully long time for the many of us that hoped to make use of this technology to help citizens to maintain privacy in the age of the Internet and the patent's expiration is a much overdue reason for celebration. WHO: If you know what blind signatures are you are invited. WHEN: This Saturday, July 16, starting at 1:00 PM PDT WHERE: Since the number of inquiries I received in response to the party pre-announcement exceed the maximum occupancy limit of my home and since the weather promises to be excellent, we will hold the party in a beer garden instead. Drinks are on me! We will meet at the Alpine Inn (aka Alpine Beer Garden) 3915 Alpine Road, Portola Valley, CA 94028 USA AWARDS: Those that can demonstrate that they have created a full system that makes significant use of the blind signature patent by 4 PM on Saturday will be invited to and receive a free dinner at the afterparty. So get coding! (Pr0duct Cypher, where are you)? A team of judges will determine if a particular system qualifies for the award. AFTERPARTY: A handful of us plan to have dinner at a swanky restaurant on patent-free Tuesday. Email me or talk with me at the party if you are interested in joining. Space is limited. You will have to pay for your own food at the Tuesday dinner unless you qualify for the award above or your name is on the blind signature patent. Looking forward to see you all this Saturday, -- Lucky Green [EMAIL PROTECTED] PGP encrypted email preferred. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
--- Dan Kaminsky [EMAIL PROTECTED] wrote: Bank Of America put my photo on my ATM card back in '97. They're shipping me a new one right now, so I assume they kept it in the DB. My local bank asked me apply for a Visa photo credit card back in 1998. There were two problems though: 1.) Their request really was just that, a request. They told me that I was free to get a regular card if I was in any way uncomfortable with the photo card. In retrospect, it seemed more like a we'd appreciate it if you could do us a big favor thing, and not so much like look, we're doing this for your own protection. The manager I talked to about this also informed me that they were only asking customers with high credit lines (whatever that's supposed to mean) to get credit cards with pictures since they were more expensive (apparently, the bank had to eat the majority of the cost; I recall only paying a $5 one-time fee). 2.) Secondly, checkout clerks just don't care. Well, they actually did notice the picture on the back of the credit card and asked what it was about maybe 6 out of 10 times. In most cases, the question resulted in very pleasant but pointless chit-chat. Noone ever asked me why I didn't look like the guy in the picture (I had since grown a beard and the picture was really grainy and low-quality). Noone ever called a manager to verify my identity despite the fact that it clearly said Please verify cardholder's picture. on the back. (I still have one photo credit card and it no longer says that and has a more up-to-date picture.) The problem here was that most check out clerks these days are teenagers making minimum wage. They care about getting paid, not getting robbed and not getting hassled. And, frankly, I can understand that attitude because I felt the same way when I was in high school. Having too little cash in the register at the end of the shift stands out and is likely to get a cashier in trouble. Having a credit card purchase flagged as fraudulant a week after the fact doesn't cause as much trouble. That's why there's no incentive to check CCs. It's also why the Zug.com credit card prank worked so well back in the day. My gym(!) has quite a different policy - they take a picture of every member when apply. You may bring a guest but the member has to be authenticated first and the guest has to sign in. If you forget your RFID card, they just check the database (or, most likely, they will recognize you). Any employee who lets people in withot an ID check or without signing in, gets a warning. Employees get fired after three warnings. Draconian? Yes. But it does work. And it wouldn't be too hard for the credit card companies to print MUST VERIFY ID onto the back of new credit cards. These days, I am on a first name basis with most of the cashiers at the local grocery stores (which is due to the fact that I'm friends with their parents who pretty much all live in the same neighborhood as we do - suburbia and all). But I do remember when we moved here and back then cashiers really noticed the credit card I had written PLEASE ASK FOR ID. THANK YOU. onto. At that time, it was mostly a social experiment. And, frankly, it didn't work. They noticed (as in huh, that's weird) but they never bothered to ask me for ID (as huh, that's weird, may I see your ID please, Sir?). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
