Arcot (fwd)

[Ryan Lackey <ryan@systemics.ai>]

(originally to a bunch of places, but I misspelled "cypherpunks" in
the headers...)

(operating on generator power after hurricane georges struck Anguilla...)

The way I see it, there are n separate issues here, which should be
addressed separately.  The following are my summaries of the issues, using
the information I have available -- I have never seen any confidential
Arcot data, so I'm operating entirely from public sources.  It's
entirely possible my data or assumptions are incorrect -- I'd be very
happy to have someone correct me.

1) The Arcot system uses "software smartcard" repeatedly throughout its
marketing literature, and says that it provides similar security to
smartcards.  However, even in the technical paper recently posted to the
web by Arcot, it admits it does not provide resistance to a wide class
of attacks, including the two Stefan Brands mentioned:
	* Resistance to monitoring attacks on the CPU
	* End users reverse-engineering the system
I have issues with this use of the term "smartcard".  In fact, this 
system has *none* of the desirable properties of a smartcard, as users
can freely copy the authenticator.  It is, at best, equivalent to
an encrypted certificate on disk which can only be checked for
validity online (no local checksums, no structure to the cert, just
a raw random string).  The phrase "two factor authentication", used
throughout the marketing literature, is being used improperly -- 
two passwords (one remembered and one stored on disk, since the
ArcotSign authenticator is just a string of data) do not two-factor
authentication make, if two passwords (one remembered and one stored
as an encrypted certificate on disk) do not two-factor make.  It's an
open point whether both systems or neither are two-factor, but it's
pretty clear that the two are equivalent.
 
2) Scott Loftesness, the new CEO of DigiCash, proposed this system as 
potentially a viable alternative to hardware tamper resistance for 
electronic finance systems (DBS systems).  The threat model for real
electronic finance systems (including and especially DBS)
is in fact substantially more serious, as recent Rabobank windows client
attack demonstrates.  Once your customers *can* have money stolen by a
third party, it's up to you to prove they *haven't*, at least according
to US and other law, for small customers.  This means only institutions
capable of absorbing massive fraud (in absolute terms) can field
real electronic cash systems.  This is primarily a debate about
threat models for a specific application, rather than a technical one.

3) The system appears to use PKC for no reason -- it is a closed system,
like Kerberos, and only limits itself by using PKC.  Kerberos, developed
by some list participants *years* ago, appears to solve every problem
Arcot claims to solve.  Additionally, Kerberos (in some form) is now
being integrated into MS Windows NT, so it is widely available.

4) Bruce Schneier, one of the firm's technical advisors, says "it's not
[sufficient for] online real estate [presumably meaning high value
transactions with no recourse]", but that it is for "ninny net users in
chat rooms".  The apps Bruce Schneier seems to propose the Arcot system for
("systems like AOL" (read: porn sites on the WWW)) are more concerned with 
their users not being able to share passwords than anything else.  For
that application, simple IP-based security in addition to passwords is
sufficient, or other means of ensuring an authenticator is linked to
an individual.  The Arcot system does not provide security from this
issue (even though it is intended for closed networks, where such
functionality would be highly possible).

However, the firm's marketing information seems to be selling this to
corporate web sites, for protecting high value corporate data.  I find
it highly unlikely any board of directors would consider their proprietary
corporate data closer to "ninny net users in chat rooms" than something
requiring real security.

(Even people without real security requirements often want high security,
or at least systems with no known limitations -- I use high-grade encryption
to protect my credit card information, even though my liability is limited
to $50, and many other users are unwilling to use 40-bit crypto to protect
their credit card numbers.)

5) The point was raised that in a smartcard system, you don't know what
you're signing.  I agree completely.  However, in a smartcard system, you
can protect the *keys* to a far higher level than protecting the
*use* of the keys when the key is physically present.  This is a substantially
lower level of risk, particularly if a security policy is included in
the smart card, such as only disbursing a limited amount of money per
unit time, or monitoring suspicious transactions, or handling user
authentication through a strong external channel, such as a PIN reader
attached directly to the smartcard reader.

The earlier debate on smartcards vs. tamper-resistant computers with I/O
leads me to believe that for electronic cash in reasonable value ranges 
(>$1000), you most likely want to go with *more* than a smartcard (as in,
a tamper resistant computer), but certainly you don't want to go with *less*.

For many applications, a combination of trusted time (on the smartcard) and
a trusted smartcard (and perhaps location) would be sufficient -- a user
could then be made to prove they were not in a certain location at a certain
time when a transaction were made to absolve themselves of responsibility for
it.

6) "Hardware is expensive"  So is software.  The cost of implementing
any authentication mechanism, particularly in a closed system, is
relatively constant -- passwords through cheap hardware -- as most of the
cost is in administrative overhead, user training, etc.  I'd far rather
go with an $8 Dallas Semiconductor iButton plus $0-$100 software plus
$400/user training/etc. cost than $0 hardware plus $x software plus
the same user training cost.  In many systems, hardware is *cheaper* in
the long run, as users understand it better, are better at doing their
own key management, etc.  It is exactly for closed systems where hardware
solutions *shine* compared to software, even if they provide the *same*
security in absolute terms -- the hardware solution has lower life-cycle costs.

For an open system, or one where you have minimal control over the users
(such as AOL, or a porn WWW site, or whatever), the requirement that
software be added to the local machine is usually prohibitively expensive.
In that kind of application, all of the intelligence needs to go on the
server -- an online password checking system, coupled with standard browser
features like client certificates, is about the most you can expect, and
even that is pushing it (until MIT did cert support for Lynx, many of
my machines were unable to use certificates at all).

7) "The system is patent-pending."

I do not see how the system is provably higher in security or any
other worthwhile features than the following widely deployable, standard, 
free system:
* online password checking of user passwords, optionally changing in
some kind of one-time-pad system, passed through an SSL-encrypted link
to the server, such that if a password guess attempts were made, the
account could be locked out.

* encrypted local certificates, encrypted with optionally a different
passphrase, which do *not* need to be kept secret.

This provides "two factor" authentication to the same extent as the Arcot
system, is easy to implement using standard systems, and is conceptually
simple.

In the event that the Arcot system is no better than the above (which I
believe), which is *not* patentable, I fail to see why the issue of
whether Arcot's system can be patented is important.  The only parts
which could be patented (as far as I can tell) are accidental, not the
essential functionality of quasi-two factor authentication with online
password checking to prevent off-line attacks.


8) The various IP/patent/etc. issues

A company could implement open standards based authentication, in an
open way, publish papers on every detail of their system, etc. and still
make quite a bit of money.  They do this through the quality of their
*software engineering*, not the quality of their idea.  Ideas are expensive
to create, and impossible to keep secret, even with patents.  Once you
come up with an idea, most of what gives it value is the review process
itself, not the initial idea.  That's why the valuable ideas I can think of,
at least in crypto, have mainly come from universities and open research
labs -- they can more cheaply be reviewed.  Only the NSA has the resources
to make an idea valuable and also keep it closed (and if you believe
Payne, even they don't...)


I understand that Arcot is a commercial company, and that it's trying
to make money, but I don't think that actually counters any of the points
presented above -- if anything, it makes them stronger, as Arcot has
a strong desire to increase the value of its assets (the deliverable
authentication system) much more so than a random hacker working on this
as a curiosity.