ID "theft" -- so what?

[John Denker]

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 majordomo at metzdowd.com