ArcotSign (was Re: Does security depend on hardware?)

[Ryan Lackey <rdl@MIT.EDU>]

[from a discussion of tamper-resistant hardware for payment systems
on dbs@philodox.com, a mailing list dedicated to digital bearer systems,
where Scott Loftesness, of DigiCash and Arcot Systems, mentioned ArcotSign.]

You mentioned the URL for Arcot, and I looked at the site.  It seems
rather lacking in technical details, and makes a very strong claim --
that it can provide tamper resistance in software on a hardware/OS/etc.
platform which is generally hostile (a general purpose computer).

I noticed that there are some big name cryptographers signed 
on as advisors -- Hellman and Schneier, who make some pretty 
glowing comments about the product.  I'm not generally swayed by anything 
but mathematics, physics, and logic when it comes to cryptography and 
security, despite generally agreeing with the analyses of those 
cryptographers.

I can see a couple of ways you could approximate real security using 
untrusted hardware -- either a one time password system retained by
the user (I've investigated this in the past, and it generally ends
up being a hardware token or a printed book of codes), or a remote
system like Kerberos where there exist out of band key protection 
mechanisms, or it's not real security.  I'd love to be convinced
otherwise, particularly if the technology will be available for
others to license.

I also noticed that the system is patent pending -- this would seem
to rule out the existing hardware token/one time pad system, or the
Kerberos-style central authentication server releasing security credentials
when presented with a passphrase system, as there are decades of prior
art in each encompassing all reasonable variations.  I guess this means it's
something new and interesting -- I'm sure everyone would be interested
in details.

Of course, in any system where all you do is authenticate yourself
to a remote system, but you're not provided with a link directly
between the user and the remote authority guaranteeing 
Confidentiality, Integrity, and Authentication, you can't really
make any claims other than that the user has authenticated herself
to some server -- any transactions the user could do are subject to
a man in the middle attack, so while the user has successfully authenticated
themselves to a remote server, and signed that *some* transaction
is acceptable, there's really no legal assurance that the user has signed
*any particular transaction*.  This is far weaker than the promise
of trusted hardware, where you could have a guarantee that as long as
the protocol hasn't been violated, the user has authorized a *particular*
transaction.  This may be acceptable for authenticating access to
an online retail banking web site, or corporate information, but it
would not be sufficient for an actual payment system (DBS, account
based, or other).

Always interested in learning something new which would chance my assumptions,
Ryan
rdl@mit.edu