Re: when a fraud is a sale, Re: Rubber hose attack
>Rick Smith at Secure Computing <[EMAIL PROTECTED]> writes: >>[...] the [SP]EKE stuff is supposed to use the weak >>secret to bootstrap a strong one without opening a crack that might allow a >>dictionary attack on the weak secret. A slick idea. At 07:04 AM 11/11/01 +1300, Peter Gutmann wrote: >... contained within a minefield of patents and IP restrictions, which is >killing its use. What would be necessary is either for someone (presumably >with any army of lawyers to back them up) to state that a particular (sound) >scheme was free of any IP restrictions, or for one or more of the groups with >patents to state they'd allow everyone royalty-free use. As it is at the >moment, it's just too risky to do anything. Even if someone has a technology >which they claim is unencumbered, others may claim that they have some patent >which covers it, or the situation is unclear enough to scare off companies who >are afraid of lawsuits. As a result, no-one can do anything. [?] That's quite the overstatement, easily shown by counter-example. I know of just a few issued patents particularly relevant to this branch of cryptography, not including the announced pending one for SRP. Considering the hundreds of other crypto patents, or the thousands of software patents in general, this little "minefield" seems relatively trivial to navigate. These technologies are readily available. I can only encourage the few bold. or not-so-stingy among us to find their own way or (dare I say) inquire about licensing. -- David - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
Nobody is gonna indemnify the world against infringement, but I thought Stanford's SRP protocol comes as close as realistically possible to what you're asking for. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
Rick Smith at Secure Computing <[EMAIL PROTECTED]> writes: >At 06:48 PM 11/5/2001, David Jablon wrote: >>Yet, strong network-based authentication of people does not require >>complex secret information ... if "complex" means demanding >>at least {64, 80, 128} random bits. >> >>With emerging strong password schemes, your average one-in-a-thousand >>or one-in-a-million kind of secret can do some pretty neat things -- >>in some cases with no need at all for stored secrets, >>as in a [SP]EKE password-encrypted chat session. > >Definitely true. It would be great to see that technology replace the >relatively vulnerable challenge response hashes used by Microsoft and others. >In general I'm skeptical of protocols that rely entirely on a memorized secret >for remote access security, but the [SP]EKE stuff is supposed to use the weak >secret to bootstrap a strong one without opening a crack that might allow a >dictionary attack on the weak secret. A slick idea. ... contained within a minefield of patents and IP restrictions, which is killing its use. What would be necessary is either for someone (presumably with any army of lawyers to back them up) to state that a particular (sound) scheme was free of any IP restrictions, or for one or more of the groups with patents to state they'd allow everyone royalty-free use. As it is at the moment, it's just too risky to do anything. Even if someone has a technology which they claim is unencumbered, others may claim that they have some patent which covers it, or the situation is unclear enough to scare off companies who are afraid of lawsuits. As a result, no-one can do anything. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
At 06:48 PM 11/5/2001, David Jablon wrote: >Yet, strong network-based authentication of people does not require >complex secret information ... if "complex" means demanding >at least {64, 80, 128} random bits. > >With emerging strong password schemes, your average one-in-a-thousand >or one-in-a-million kind of secret can do some pretty neat things -- >in some cases with no need at all for stored secrets, >as in a [SP]EKE password-encrypted chat session. Definitely true. It would be great to see that technology replace the relatively vulnerable challenge response hashes used by Microsoft and others. In general I'm skeptical of protocols that rely entirely on a memorized secret for remote access security, but the [SP]EKE stuff is supposed to use the weak secret to bootstrap a strong one without opening a crack that might allow a dictionary attack on the weak secret. A slick idea. Rick. [EMAIL PROTECTED]roseville, minnesota "Authentication" in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
Authentication of people is an especially subtle engineering problem. Yet, strong network-based authentication of people does not require complex secret information ... if "complex" means demanding at least {64, 80, 128} random bits. With emerging strong password schemes, your average one-in-a-thousand or one-in-a-million kind of secret can do some pretty neat things -- in some cases with no need at all for stored secrets, as in a [SP]EKE password-encrypted chat session. Password-based techniques is one of the subjects being addressed by the IEEE P1363 working group, and the apparently successful job of a number of schemes, some of which are listed here: http://grouper.ieee.org/groups/1363/StudyGroup/submissions.html (But please don't ask me how this relates to "Rubber hoses".) At 11:24 AM 11/5/01 -0600, Rick Smith wrote: >If we look at authentication as an engineering problem, then >you can only 'authenticate' between entities that share some >fairly complex secret information. Anything else can be spoofed >pretty easily. I don't think it's practical to speak of strong, >network based authentication between 'users' unless we tie them >to physical devices that store those secrets (private keys, etc.). (See comments above.) >Of course, this distinction simply illustrates the gap between >our policy objectives (authenticate particular roles and/or >entities) versus the available tools (verify ownership of hard >to forge credentials). I definitely agree that the "gap" is huge in most systems. >Rick. >[EMAIL PROTECTED]roseville, minnesota >"Authentication" in bookstores http://www.visi.com/crypto/ -- David - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
but in the financial case ... you don't have to identify them (aka their DNA) ... you just match them and the account. absolutely no identity needed. If i deposit a large sum of money and want to be the only person authorized to transact on the account ... there is no need to present identity cards at all (fake or otherwise). Supposedly, swiss bank accounts have worked that way in the past totally authenticated transactions, absolutely no identity. There are misc. other issue related to govs. wanting valid identities involved ... but they are extraneous to the issue of authenticating that the entity attempting to transact on the account is actually the entity authorized to transact on the account. There can be a extremely high level of confidence in an authentication system as to the entity attepting a transaction is the entity authorized to do a transaction and absolutely no identity information need to be involved. Identity information may come into play with regard to financial accounts but they can be totally extraneous to authenticating valid transactions. In fact, one of the issues with regard to "relying-party-only" certificates (mentioned in previous post) was 1) institutions not wanting to take 3rd party liability and 2) all identity information was totally eliminated from the certificate ... leaving just the account number. This was specifically because it was an invasion of privacy that extraneous parties (like merchants) that the transaction might pass thru (and its end-to-end route) might examine the information; besides the identity information being totally extraneous and superfulous. That is a separate issue from also being able to show that just attaching such a credential was unnecessary, superfulous, redundant and extraneous (futhermore a credential that doesn't exist is even more private than a credential that has had all the interesting information removed). [EMAIL PROTECTED] on 11/05/2001 11:15 AM wrote: The real trick is identifying the person the first time. The person is a stranger and the person trying to identify them couldn't tell a fake ID from a real one. John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
not completely. except for some of the "know your customer rules" a financial institution doesn't have to identify you ... they only have to authenticate that you are the person authorized to transact with the account; aka 1) I come in and open a brand-new account and deposit a whole lot of money. 2) they give me a card with possibly PIN which is the only way that is enabled for authorized transactions. They may also record some number of shared secrets as a fall-back position (some of the shared-secrets may involve identity information ... but that is more of a memory mnemonic, i know people that register almost random shared-secrets that have no relationship to their identity). No identity is involved. Governments may require identity for other reasons ... but it is possible to establish that it is the entity authorized to make transactions w/o requiring any identification (using purely authentication). That is not to say that there are various kinds of fraud involving things like identity theft ... but it is possible to authenticate transactions w/o requiring identity. There are some other issues with some infrastructures involving trusted third parties (TTPs). I've gone into some length with regard to the discussion of TTPs and domain name web server certificates ... aka http://www.garlic.com/~lynn/subtopic.html#sslcerts where, in effect because of concerns over the integrity of the domain name infrastructure, digital certificates have been introduced. Note however, TTPs normally are not the recognized authoritative entity with regard to domain names TTPs just "certify" that they've checked with with the authoritative entity with regard to whatever they are certifying when they manufactor the digital certificate. Now, who is the authoritative entity for domain name information that TTPs check with when they are manufactoring a domain name web server certificate? It is the domain name infrastructure. As a result of integrity concenrs there are also integrity concerns with regard to the domain name infrastructure from TTPs (because they effectively rely on the same authoritative agencies that people are concerned about with regard to normal operation). Now the interesting part is that there are proposals that would fix the integrity problems of the authoritative domain name agency ... the domain name infrastructure however, if those proposals were implemented, it would also correct integrity concerns regarding the domain name infrastructure for the rest of the world ... elminating the desire they have to have domain name web server certificates as a means of compensating for the integrity issues with the domain name infrastructure (which is also the authoritative agency for domain names that the TTPs check with in order to certify domain names in manufactored certificates). [EMAIL PROTECTED] on 11/05/2001 10:01 AM wrote: I think you have nailed it on the head. When authentication is viewed as the "first link" in the chain instead of identification. The problem with all authentication technologies in use today from biometrics to PKI to digital certs, all finesse the identification process and push it off to some "trusted" third party...all without clearly defining what that third party must bring to the table. John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
At 11:01 AM 11/5/2001, [EMAIL PROTECTED] wrote: >The problem with all authentication technologies in use today from >biometrics to PKI to digital certs, all finesse the identification process >and push it off to some "trusted" third party...all without clearly >defining what that third party must bring to the table. Perhaps this is why I'm expecting PKI to flourish primarily within enterprises that run their own CAs as opposed to third parties, at least in the near term. Although a few third party credit card vendors got things started decades ago, credit cards didn't really blossom until after a period in the '60s and '70s during which many/most individual enterprises issued their own cards. This allowed the enterprises to learn by themselves what the costs, risks, and rewards were. They had the opportunity to decide for themselves what risks to take and directly experience the results. Only after the enterprises developed this internal awareness of the real implications of such cards could they understand the system well enough to know what it meant to sign up with Visa, MC, or one of the other big names. At least, that's my reading of the history, and how it might apply to PKI or other authentication technologies. It seems to me that the concept of identity is application specific (and thus enterprise specific in a sense), which makes it tricky for an 'authentication vendor' to try to provide a general 'identity' solution except maybe through 'AAA' products. Rick. [EMAIL PROTECTED]roseville, minnesota "Authentication" in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
In a message dated 11/5/01 11:28:57 AM, [EMAIL PROTECTED] writes: << then you can only 'authenticate' between entities that share some fairly complex secret information. Anything else can be spoofed pretty easily. >> The information does not have to be secret at all. It can be open, but not capable of being duplicated. Could any of your friends fool your mother that they were you? John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
At 09:49 AM 11/5/2001, [EMAIL PROTECTED] wrote: >I tend to agree with you that we should extend the meaning >of end-to-end to mean user-to-user, instead of device or >token-to-token. I'm not sure what this means. If we get really specific, then a transaction between me and a small used-book seller consists of a transaction between individual humans, but my transactions with Amazon involve an abstract entity represented by teams of humans. Presumably my latest transaction still proceeds even if the first person to process it at Amazon quits before the package is shipped. That's not so clear if the bookseller drops dead. If we look at authentication as an engineering problem, then you can only 'authenticate' between entities that share some fairly complex secret information. Anything else can be spoofed pretty easily. I don't think it's practical to speak of strong, network based authentication between 'users' unless we tie them to physical devices that store those secrets (private keys, etc.). Of course, this distinction simply illustrates the gap between our policy objectives (authenticate particular roles and/or entities) versus the available tools (verify ownership of hard to forge credentials). Rick. [EMAIL PROTECTED]roseville, minnesota "Authentication" in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
In a message dated 11/5/01 10:55:39 AM, [EMAIL PROTECTED] writes: << in the account-based financial transaction ... the requestor is the card-holder/consumer and the authorization or service entity is the card-holder's financial institution. >> I think you have nailed it on the head. When authentication is viewed as the "first link" in the chain instead of identification. The problem with all authentication technologies in use today from biometrics to PKI to digital certs, all finesse the identification process and push it off to some "trusted" third party...all without clearly defining what that third party must bring to the table. John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: when a fraud is a sale, Re: Rubber hose attack
slight aside, in beginning security basics end-to-end typically means that a authorization or service message requiest . originates with the requester and has been secured with authentication and/or encryption of the requester and travels end-to-end from the requester to the service entity ... which first validates the authorization/service request (based on the end-to-end authentication and/or encryption from the requester) and then returns an authorization or some other indication that the service is performed. most beginning security basics teach that if authorization and/or service request does not have end-to-end security and/or integrity then the design is fundamentally flawed and opportunities for fraud is created. An example is that in SET, the card-holder/consumer's authentication information was stripped off at some random internet gateway and a flag inserted in an otherwise normal iso 8583 financial transaction message claiming that digital signature authentication had been performed. A year or so after SET pilots were in operation, somebody from VISA gave a presentation at some ISO meeting in europe detailing the percentage of iso 8583 messages where the "authenticated" flag had been turned on by some entity (and for which the consumer's issuing bank was now suppose to base various business processes and decisions) and they could positively show that no internet payment and/or any other form of digital signature authentication was involved (aka no end-to-end entegrity and/or security). in the account-based financial transaction ... the requestor is the card-holder/consumer and the authorization or service entity is the card-holder's financial institution. JohnE37179@aol. com To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] 11/05/2001 cc: [EMAIL PROTECTED], 08:49 AM[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: when a fraud is a sale, Re: Rubber hose attack In a message dated 11/5/01 9:41:44 AM, [EMAIL PROTECTED] writes: << On one hand I'm tempted to read this as a plea for some absolute notion of security, but somehow I don't think that's really what you're saying. >> Rick, my point is that VISA and to a slightly lesser extent, MC, have built a model just as you describe: send the money, but we don't take any risk. I tend to agree with you that we should extend the meaning of end-to-end to mean user-to-user, instead of device or token-to-token. John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]