two factor authentication

[Jefferson Ogata]

On 2006-07-26 07:00, Alon Bar-Lev wrote:
> On 7/26/06, William Ahern <william at 25thandclement.com> wrote:
>> But I argue that they do provide a critical, heretofore absent link in
>> end-to-end security across the network. And significantly a link whose
>> properties allow it to become a dependable component in a coherent,
>> parameterizable security system. To say any password-based system--employed
>> within a network--is comparable sounds like, pardon me, a joke.
> 
> OK.
> This summerize this thread correctly.
> I hope it I will stop here.

Alon, I'll try to spell this out for you one more time. I don't want to
resurrect a discussion of the minutiae of this issue--this is intended
as a big-picture overview.

There is, cryptographically speaking, no difference between a one-time
password system and a smartcard. To see this, imagine the following two
scenarios:

1. Admin generates a keypair on a smartcard, and adds the public key to
his authentication system. At authentication time, the system challenges
the user, and the smartcard uses the challenge and private key to
calculate a response.

2. Admin generates a keypair in software. No part of the keypair is
divulged to the user. The keypair is used to generate a list of n
challenge-response pairs; these are given to the user on a piece of
paper. At authentication time, the system challenges the user, and the
user locates the response on the piece of paper.

The algorithmic difference between these two scenarios is whether the
crypto is being done at authentication time in hardware on a
smartcard--i.e. the smartcard calculates the response using the
challenge and the private key--or at some earlier time when the
challenge-response pairs are pre-generated.

In other words, a smartcard /is/ a one-time password system, where the
responses are related to the challenges by a cryptographic operation
that depends on the private key stored in the smartcard.

The smartcard has the advantage (or disadvantage, depending on your
requirements) that you don't need to distribute a new set of
challenge-response pairs to the user when the old set is exhausted,
since calculation of a response can be performed by the smartcard an
unlimited number of times. And it's convenient for the user, because he
doesn't have to type a long one-time password. But because the smartcard
is a sealed device, there is no way to know whether it will also
calculate responses at the request of a sufficiently well informed
attacker sitting nearby in the coffee shop, either because of
incompetent or deliberate design flaw. The essential properties of a
smartcard--it incorporates cryptographic algorithms and is difficult to
disassemble without destruction--make it an ideal place to hide a back door.

The piece of paper has the advantage that it is more flexible because
the challenge-response pairs don't actually have to be cryptographically
related--they can be completely random, so long as the system performing
authentication has access to the same list that was given to the user.
Even if a cryptographic algorithm is used, the user doesn't carry a
device on which the underlying secret resides. (A smartcard with these
properties could be built, but this is not the traditional approach.) Of
course the piece of paper has a number of disadvantages of convenience
and physical security, but from a theoretical standpoint it is no
different from a smartcard--it relates unique challenges to responses in
a way that may be made entirely opaque to the user, and access to the
challenge-response relation, rather than knowledge of some fixed secret,
is the authenticator.

In both cases, the question is how you protect access to the
challenge-response relation, whether it exists as an infinite
cryptographic function in silicon, or as ink on a finite piece of paper
in the user's pocket, against unauthorized users. And in both cases,
whatever method is chosen may fail. Estimating the probability of this
failure's occurring in a smartcard is practically impossible, since it
may be due to either incompetence or deliberate design of the vendor or
manufacturer. This is why if you use smartcards and you want to have any
confidence in your security, it is /necessary/ to combine them with
another, completely independent, authentication factor; even a lowly
fixed password is better than nothing.

Now before you respond again, please go back and read the entire thread
thoroughly. Also, note that I am not the original poster, nor does the
White House memo that I excerpted completely encompass the principles
that are at work in this discussion; it is merely an example of some
people's requirements.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service