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
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
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
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
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
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
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]
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
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]
