Re: the limits of crypto and authentication

2005-07-19 Thread Jaap-Henk Hoepman
Only problem is that cell phones have become so utterly complex (hosting several processors and a plethora of software components) that it will never become the trusted device that we once thought it could be... Personal it is though Jaap-Henk On Sat, 09 Jul 2005 18:56:22 -0700 James A.

Re: the limits of crypto and authentication

2005-07-19 Thread Jaap-Henk Hoepman
Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. Jaap-Henk On Sat, 09 Jul 2005

Re: the limits of crypto and authentication

2005-07-19 Thread Anne Lynn Wheeler
ref: http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication one of the issues raised in the x9.59

Re: the limits of crypto and authentication

2005-07-19 Thread Anne Lynn Wheeler
Jaap-Henk Hoepman wrote: Actually, Dutch banks already give users the option to recieve one-time pass-codes by SMS to authenticate internet banking transactions (instead of sending a list of those codes on paper by ordinary mail in advance). So it's less unrealistic than you think. there is

Re: the limits of crypto and authentication

2005-07-16 Thread Anne Lynn Wheeler
the spring of 1995. http://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication a trivial side-note ... since the SET specification wasn't issued by a sanction standards body ... it wasn't a Standard in the official sense. one of the operational differences between SET

Re: the limits of crypto and authentication

2005-07-15 Thread Rich Salz
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? I was told that one of the reasons SSL took off was because Visa and/or MC told

Re: the limits of crypto and authentication

2005-07-15 Thread Aram Perez
On Jul 14, 2005, at 8:13 PM, Rich Salz wrote: 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? I was told that one of the

Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
Rich Salz wrote: I was told that one of the reasons SSL took off was because Visa and/or MC told merchants they would for the time being treat SSL as card-present, in terms of fraud penalties, etc. If this is true (anyone here verify? My source is on the list if s/he wants to name themselves),

Re: the limits of crypto and authentication

2005-07-15 Thread Ben Laurie
Perry E. Metzger wrote: 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

Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
a harder problem for early stage web merchants was getting a merchant financial institution the merchant financial institution that sponsors a merchant for payment transactions ... takes financial responsibility for that merchant. the standard procedure was to send somebody out to the retail

Re: the limits of crypto and authentication

2005-07-15 Thread Ram A Moskovitz
On 7/14/05, Anne Lynn Wheeler [EMAIL PROTECTED] wrote: remember what Verisign was called before it was renamed Verisign? Digital Certificates International, Inc. Did you consult for First Data Corp. at the time?

Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
Aram Perez wrote: One other point, SET did NOT require certs for the consumers. The client-merchant protocol supported clients without certs. there was a later set-lite w/o certs for clients ... but the original specification had client certs as part of the core process. note that the SET

Re: the limits of crypto and authentication

2005-07-15 Thread Anne Lynn Wheeler
Ram A Moskovitz wrote: Did you consult for First Data Corp. at the time? some reference: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 little later, we got to review chaum and brand stuff. brand had done a take-off on chaum's stuff so that if somebody

Re: the limits of crypto and authentication

2005-07-14 Thread Rich Salz
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

Re: the limits of crypto and authentication

2005-07-14 Thread Perry E. Metzger
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

Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
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

Re: the limits of crypto and authentication

2005-07-14 Thread Aram Perez
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

Re: the limits of crypto and authentication

2005-07-14 Thread Amir Herzberg
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

Re: the limits of crypto and authentication

2005-07-14 Thread Pat Farrell
On Thu, 2005-07-14 at 18:43 +0200, Amir Herzberg wrote: Pat Farrell wrote: 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

Re: the limits of crypto and authentication

2005-07-14 Thread Perry E. Metzger
Aram Perez [EMAIL PROTECTED] writes: 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

Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
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

Re: the limits of crypto and authentication

2005-07-14 Thread Anne Lynn Wheeler
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

Re: the limits of crypto and authentication

2005-07-13 Thread R.A. Hettinga
At 2:48 PM -0700 7/12/05, Bill Stewart wrote: It'd be nice if good crypto and authentication methods could create a market for improved products It can, it does, and it's called significantly reduced risk-adjusted transaction cost in financial econ-speak. Maybe the marketing droids need to come

Re: the limits of crypto and authentication

2005-07-12 Thread dan
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

Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie
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

Re: the limits of crypto and authentication

2005-07-12 Thread Perry E. Metzger
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

Re: the limits of crypto and authentication

2005-07-12 Thread Mads Rasmussen
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

Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie
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

Re: the limits of crypto and authentication

2005-07-12 Thread Anne Lynn Wheeler
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

Re: the limits of crypto and authentication

2005-07-12 Thread Anne Lynn Wheeler
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

Re: the limits of crypto and authentication

2005-07-12 Thread Perry E. Metzger
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

Re: the limits of crypto and authentication

2005-07-12 Thread Bill Stewart
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

Re: the limits of crypto and authentication

2005-07-12 Thread Adam Shostack
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

RE: the limits of crypto and authentication

2005-07-11 Thread Scott Guthery
as always. Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, July 09, 2005 6:32 PM To: cryptography@metzdowd.com Subject: Re: the limits of crypto and authentication Nick Owen writes: | I think that the cost

Re: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the failure of Amex Blue is due to poor timing and the requirement for hardware on the end-user's PC. At the time of it's introduction ecommerce and online banking were just getting started and consumers were more worried about whether the store was real or not than having their card

Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Perry E. Metzger wrote: Far better would be to have a token with a display attached to the PC. The token will display a requested transaction to the user and only sign it if the user agrees. Because the token is a trusted piece of hardware that the user cannot install software on, it provides

Re: the limits of crypto and authentication

2005-07-11 Thread Amir Herzberg
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

Re: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the difference now is the number of vendors entering the market, the variety of solutions ( and their relative security), and demand outside of Europe. When we started in mid-2001, we were looking at the existing hardware guys and that is it. Now there a handful of venture-backed

Re: the limits of crypto and authentication

2005-07-11 Thread Florian Weimer
* 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

Re: the limits of crypto and authentication

2005-07-11 Thread Florian Weimer
Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com In the foreseeable future, this approach won't stop fraudulent transactions because the one-time password does not depend on the

Re: [Anti-fraud] Re: the limits of crypto and authentication

2005-07-11 Thread Ka-Ping Yee
On Sun, 10 Jul 2005, Amir Herzberg wrote: But... crypto and authentication, imho, are the best tools to prevent such malware from being installed. I disagree. Limited authority is the best way to prevent such malware from being installed (and, if installed, from causing harm). The premise

Re: the limits of crypto and authentication

2005-07-11 Thread Peter Gutmann
[EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it

Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Nick Owen wrote: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address

Re: the limits of crypto and authentication

2005-07-11 Thread Ian Grigg
On Saturday 09 July 2005 23:31, [EMAIL PROTECTED] wrote: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex

Re: the limits of crypto and authentication

2005-07-11 Thread Perry E. Metzger
[EMAIL PROTECTED] writes: Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard

Re: the limits of crypto and authentication

2005-07-11 Thread Perry E. Metzger
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

Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
another characteristic of the PKI x.509 identity certificate activity (besides attempting to create mass world-wide confusion regarding the difference between identification and authentication ... and trying to get govs. to mandate that x.509 identity certificates, grossly overloaded with personal

Re: the limits of crypto and authentication

2005-07-11 Thread Ben Laurie
Peter Gutmann wrote: [EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic

Re: the limits of crypto and authentication

2005-07-11 Thread Anne Lynn Wheeler
Perry E. Metzger wrote: However, you need both the end to end communication and the hardware token with built in display and keyboard. there is two issues for digital signatures ... 1) something you have authentication and 2) proof to the relying party as to the integrity level of the

the limits of crypto and authentication

2005-07-09 Thread Steven M. Bellovin
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

Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
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. Steven M. Bellovin wrote: There's been a lot of discussion about how to strengthen cryptography and

Re: the limits of crypto and authentication

2005-07-09 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Nick Owen 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. How does the user know which transaction is really being

Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
To validate the transaction, a receipt could be sent to the user encrypted by the server's public key. If the receipt is correct, the user enters their PIN to 'sign' the transaction. I'm assuming an asymmetric authentication system here outside the browser. The attacker would have to steal the

Re: the limits of crypto and authentication

2005-07-09 Thread Lance James
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

Re: the limits of crypto and authentication

2005-07-09 Thread Florian Weimer
* Steven M. Bellovin: In message [EMAIL PROTECTED], Nick Owen 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. How does the user know which transaction

Re: the limits of crypto and authentication

2005-07-09 Thread Ian Grigg
FTR, e-gold were aware of the general makeup of this threat since 1998 and asked someone to look at it. The long and the short was that it was more difficult to solve than at first claimed, so the project was scrapped. This was a good risk-based decision. The first trojans that I know of for

Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique

Re: the limits of crypto and authentication

2005-07-09 Thread 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

Re: the limits of crypto and authentication

2005-07-09 Thread dan
Florian Weimer 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. | | | How does the user know which transaction is really being

Re: the limits of crypto and authentication

2005-07-09 Thread dan
Nick Owen writes: | I think that the cost of two-factor authentication will plummet in the | face of the volumes offered by e-banking. Would you or anyone here care to analyze what I am presuming is the market failure of Amex Blue in the sense of its chipcard and reader combo? --dan

Re: the limits of crypto and authentication

2005-07-09 Thread Florian Weimer
* Nick Owen: I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. I doubt this is true. In Germany, we already use some form of two-factor authentication for Internet banking transaction (account number/password and a one-time

Re: the limits of crypto and authentication

2005-07-09 Thread James A. Donald
-- Ian Grigg [EMAIL PROTECTED] In the payments world we've known how to solve all this for some time, since the early 90s to my knowledge. The only question really is, have you got a business model that will pay for it, because any form of token is very expensive, and the form of token