kludge@panix.com Fri Mar 4 10:14:28 2005 wrote:
> Dan Lanciani <ddl@danlan.com> wrote:
>> I think you've missed the point. In spite of what the banks may tell
>> you, there is no reason for the information required by an entity to
>> verify your identity to also be sufficient for that entity to
>> impersonate you. The attitude of, 'we need to know all about you so
>> we can be sure who you are' (and consumers' acceptance of that
>> attitude) is exactly the problem.
> Then how can it be complete to verify your identity?
The currently fashionable approach would be for the credit agency (or
equivalent) to hold the consumer's public key and deliver it to the
bank or other entity desiring to verify the consumer's identity. The
consumer could then sign the credit application (or whatever) with her
secret key, proving her identity. (There are details, of course, and
the application should probably be encrypted with the bank's
well-known public key.) An advantage of using public key crypto is
that even the credit agency doesn't have enough information to
impersonate the consumer.
If you don't like public key crypto and you don't mind that the credit
agency (but not the bank) has enough information to impersonate the
consumer then take a look at Kerberos's model. It can provide mutual
authentication of two parties without giving either enough information
to impersonate the other, all using traditional symmetric crypto.
One nice thing about both approaches is that they could be phased in
in such a way that they were completely optional both for consumers
and banks. Let consumers register their public keys with the credit
agencies who could then deliver them along with all the other personal
data. Let banks use them for verification if they so choose. (Maybe
provide a little incentive by saying that if a consumer registers a
key and the bank decides not to use it and there is fraud the bank is
strongly presumed to be at fault.)
Another feature is that unlike biometric and SecureID schemes, these
approaches do not require the deployment of esoteric hardware. More
importantly, since the required computing equipment on the consumer's
end is working only for the consumer (i.e., it is not attempting to
conceal something from its owner) it can be implemented as software on
general purpose machines, e.g., desktops and PDAs. Chances are that
the majority of consumers interested in registering their keys already
have the required hardware. (This is not to say that the banks
couldn't develop a nice easy-to-use crypto appliance for those who
don't want to use general-purpose machines.)
To extend the approach to frequent transactions it would be a good
idea to add an IrDa port to ATMs so they could talk to PDAs directly.
(You don't want the consumer to have to copy long strings of digits by
hand.) Again this does not require the bank to issue special "secure"
hardware to the consumer because the PDA works for its owner, not for
the bank.
> The information that verifies that you are who you are is exactly the
> same information that verifies that someone else is who you are.
That's true, and it is why there is ultimately no solution for the
simple duress problem. The best we can do with something known is
prove that that something is indeed known. However, we can contrive
to do this in such a way that the something known is not disclosed in
the process. And the entity to whom we are making the proof does not
itself need to know the something at any time. That solves the
phishing problem and the unintentional-disclosure-by-central-agency
problem.
Dan Lanciani
ddl@danlan.*com
Dan Lanciani (ddl@danlan.com)