On 07/13/05 12:15, Perry E. Metzger wrote:
However, I would like to make one small subtle point. ... the use of widely known pieces of information about someone to identify them.
Yes, there are annoying terminology issues here. In the _Handbook of Applied Cryptography_ (_HAC_) -- on page 386 they say "The terms _identification_ and _entity authentication_ are used synonymously throughout this book" (which in fact they are :-) -- on page 24 they say the term _authentication_ is often abused. It seems to me that the term _identification_ is even more ambiguous and open to misunderstanding than "authentication" is. Overall, it's a quagmire. In some circles, the notion of _identifying information_ is quite a weak notion, meaning sufficient information to pick the desired entity out of a crowd. More-or-less synonymous notions include *) characterization *) description (sufficiently detailed to be unique) *) unverified _claim_ of identity *) pointer, indicator, index *) name, call-sign, handle *) record-locator, database-key -- used as an index into the database, -- *not* a key in the sense of lock-and-key -- example: LOGNAME i.e. the first field in each record in the /etc/passwd database In other circles, _identification_ refers to a much stronger notion. When the military speaks of IFF (identification, friend or foe) they don't consider it sufficient for you to be able to _describe_ a friend, they actually want you to _be_ a friend. As to whether the word _identity_ should refer to full-blown entity authentication, or to a mere characterization or call-sign ... that seems like an unanswerable question. ==> My recommendation: Avoid using terms like "identity" and "identification" entirely. -- If you mean "entity authentication", use that term in preference to "indentification". -- If you mean a mere description, handle, record-locator, etc. use those terms. It would be nice to have a convenient catch-all term for the whole category of notions like description, handle, record-locator, et cetera. I don't recommend calling them "weak" identification, because the term "weak authentication" has already been taken, and means something else, namely passwords and the like (_HAC_ page 388). The only time that you can even dream of using a detailed description as a means of entity authentication is when meeting face to face. Somebody who fits my description in full detail "probably" is me, although even that isn't entirely certain. On the other side of that coin, in a typical e-commerce situation, allowing a description or a call-sign to serve in place of entity authentication is ludicrous. It means that anybody who can describe me can impersonate me. The vulerability to replay attacks and MITM attacks is unlimited. Typically a full-blown entity authentication starts with one party making a _claim_ of identity which the other party then _verifies_. Unix login is a familiar example: first I give my LOGNAME and then I give the corresponding password. The notion of "theft" of my LOGNAME is vacuuous. My LOGNAME (jsd) is known to everybody, good guys and bad guys alike. As Spike said, so what? My LOGNAME is nothing more than a handle, a call-sign, a record-locator, used to look up the appropriate record in places like /etc/passwd. If you want to impersonate me, my computer requires you to know not just my LOGNAME but also my password. The way we should treat passwords is verrry different from the way we should treat call-signs. Using this refined terminology, I can clarify what I was trying to say yesterday: 1) Being able to _describe_ me (height, weight, date of birth, SSN, LOGNAME, and great-great-grandmother's maiden name) does not mean you _are_ me. 2) Even fully identifying and authenticating me as me doesn't suffice to prove that wish to authorize this-or-that financial transaction. Who I *am* and what I wish to *happen* are dramatically different notions. Authenticating me as an entity is not a proper substitute for authenticating the transaction itself. These notions are not unrelated, but they are not identical, either. In present-day practice, SSNs, credit card numbers, and various bits of personal description are suspended in some weird limbo: they are not nearly as secret as passwords should be, yet they are still treated by some parties as if they had magical entity-authenticating power and even transaction-authenticating power. So where do we go from here? In general: -- When we think and when we speak, always distinguish handle versus entity authentication versus transaction authentication. -- Don't entrust our money to institutions that can't reliably make that distinction. -- Obtain legislation so that Muggles are protected, not just us. Also: A critical step that phishers must take in order to exploit phished information is to check its validity. Therefore banks *must* be required to perform entity-authentication on everyone who validates charging info. This simple step would AFAICT greatly suppress phishing, since phishers would become super-vulnerable to sting operations. ========================= The foregoing seems pretty much obvious and non-controversial. Now let me start a new sheet of paper and discuss a half-baked idea. Refinements would be welcome. Scenario: I'm shopping online. Using browser window #1, I have found a merchant who sells what I want. in the checkout phase. Now, in browser window #2, I open a secure connection to my bank. The bank and I authenticate each other. (This is two-way authentication; one possible method is SSL certificate on the bank's part, and a password or some such on my part.) In the simplest case, I simply ask the bank to generate a single-use "credit card" number. I cut-and-paste this number from the bank (window #2) to the merchant (window #1). The merchant has an incentive to use this number properly, and not mishandle it ... and as soon as they do use it, it becomes worthless to anybody else. As a refinement, I could ask the bank to issue a number that was not only restricted to a single use, but also restricted as to dollar amount. As a further refinement, it could be restricted to a particular merchant. Everything to this point is upward-compatible with existing systems. The merchant doesn't even need to know there's anything special about this card number; the charge moves through existing processing channels just like any other. As a further refinement, once the system is established, the merchant could provide, on the checkout page, a number that encodes in some standard format various details of the transaction: merchant ID, date, dollar amount, and maybe even a description of the goods sold. I cut-and-paste this code from the merchant to the bank, and let the bank site decode it. If it looks correct, I click OK and then the bank generates a response that the merchant will accept in payment. If necessary I can cut-and-paste this from the bank to the merchant ... but it would make more sense for the bank to transmit it directly to the merchant. This further increases security, and also saves me from having to enter a lot of billing detail. This doesn't solve all the world's problems. As SMB pointed out, if your PC has been trojanized you're in big trouble, and this certainly won't help with that. Browser #2 could be your cell phone. To the extent that the phone is "something you have", this further enhances security. (Although I expect to see phone trojans become common pretty soon.) This requires having the bank be online at all times when I might be e-shopping, but the internet has become sufficiently reliable that this shouldn't be much of a problem (unless you're in Pakistan :-). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]