[107593] in Cypherpunks

home help back first fref pref prev next nref lref last post

Re: ArcotSign Software Smartcard

daemon@ATHENA.MIT.EDU (Ryan Lackey)
Tue Jan 19 00:56:08 1999

Date: Mon, 18 Jan 1999 21:34:19 -0400
From: Ryan Lackey <ryan@venona.com>
To: Robert Hettinga <rah@shipwright.com>, dbs@philodox.com,
        cypherpunks@Algebra.Com, marlin@arcot.com
In-Reply-To: <v04020a03b2c965c26fd8@[139.167.130.247]>; from Robert Hettinga on Mon, Jan 18, 1999 at 05:27:18PM -0500
Reply-To: Ryan Lackey <ryan@venona.com>

(Disclaimer: I see only one real advantage of ArcotSign over other systems I
am an active user of (Kerberos) -- non-forgery by the central authority -- and
I think this is mostly irrelevant in most environments where the application
servers are administrated by the same entity as the authentication server.  
This could be a useful feature in some environments, however.

I however strongly protest assertions of patentability in spite of substantial
prior art (Kerberos, SESAME, etc.) and "software smartcards")


Quoting Robert Hettinga (rah@shipwright.com):
> Doug tells me that there were questions on our
> choice of the term "software smartcard" in our marketing materials.

Interesting way of phrasing that, "some questions".  I wasn't actually
there, and thus can't comment on what was actually said, but in the discussions
on various mailing lists about 2-3 months ago about ArcotSign technology, I
think the issues raised were substantially more than "questions" -- rather,
they were extreme doubts, bordering on suspicions of fraud and snake oil.

> Here is why we believe that it is an appropriate term for our
> technology.
> 
> (a) Security:  Arcot's software smartcard offers the same level of
> protection as the storage smartcard but entirely in software.  Crypto
> smartcards have the additional protection that the private key never
> leaves the card.  However, even crypto smartcards are subject to the
> attack where the user signs documents unwittingly.

Smart cards protect keys from compromise even when used to sign a bogus 
transaction.  The problem of having no secure user I/O conduit is a serious
one, and I believe some smartcard systems solve this by having a tamper
resistant reader with user I/O for PINs and transaction telltales (amount,
payee, etc.).  Additionally, there are many smartcard systems where causing
false signatures would be substantially less of a problem than compromise
of a key -- 

	1) forward and past secrecy is maintained in spite of 
	"forced chosen plaintext" signatures, 
	2)given a secure timestamp
	service the transaction can be pinpointed to a specific time and 
	place (and
	thus terminal) and thus repudiated by the user (and the central 
	authority can track down and kill those responsible for the fraud), 
	3) Costs to back out the transaction are far lower than to change
	keys and back out many transactions, at least in a decentralized key 
	system
	4) Most importantly -- A "forced signature" of a specific string of
	data is only really useful if you can identify ahead of time the users
	you want to compromise (perhaps you could do this with a rule, like
	"all accounts with more than $20k in them should be forced to sign
	a $10k withdrawal").  If you compromise a key, you can *store* the key
	for the long term and then use it later once you find a target you
	wish to attack.  Right now, forcing a signature on my bank account 
	would be pointless (I have $90 or so), but if I ever become wealthy,
	I'll probably have the same bank account, and might have the same key
	protecting it.  Thus, "hoovering" all personal keys is a good idea,
	forcing everyone to sign away $10k transfers is less interesting.
	This argument depends upon at least a coarse granularity trusted
	clock, such that forced transactions can't be used in 5 years, but
	this is a highly reasonable assumption. 

> 
> (b) Portability:  Given the increased level of security offered by
> Arcot's software container, it is possible to support roaming users by
> delivering credentials on demand.  Furthermore, the Arcot software
> container can be placed on any storage medium, including magnetic stripe
> cards.

	However, building a terminal to process ArcotSign software containers
	is more complex/expensive than building one to interface with a
	real ISO smartcard, particularly for retail POS applications, doors,
	etc.

	A good deal of the security of a hardware system comes from the
	hardware being *carried* by the user to the remote location.  For
	arcotsign to match this, you would need to carry your arcotsign
	credentials on a Zip disk or something (which is entirely reasonable),
	install the software on the remote machine, and use it there.

	I'd rather just plug a smartcard into a reader than mess around with
	a bunch of windows configuration, although admittedly it's about as
	easy to install an application as to install a piece of hardware, if
	the machine does not already have a smartcard reader.  Carrying around
	a Dallas Semiconductor iButton (http://www.iButton.com) and blue dot
	reader solves the problem pretty nicely, I think.  Add a laptop
	computer to the mix and you've got *real* security, and convenience.
	Dell now has a 1" thick laptop for $2300 which would be substantially
	easier for me to carry around, preloaded with an iButton reader,
	ArcotSign software, ssh, kerberos, etc., then to do even one install
	on a remote machine.
> 
> (c) Installation/Administrative Cost:  Software smartcards are cheaper
> than their hardware companions.

	In terms of a simple analysis, hardware is certainly more expensive
	than software, but in terms of actual use, hardware has proven time and
	time again to be the cheaper life-cycle system, at least in
	authentication and security.  This is why all the very serious systems
	that use crypto store their keys on removable modules (the 
	Cryptographic Ignition Keys used by STU/STE equipment, nCipher, etc.),
	the iButtons and smartcards used in the banking sector, the "pgp on
	a zip disk" used by some of the more paranoid people I know, to the
	secure (yet heavy and old...) laptop I use.

	One lost key, software or hardware, will dwarf 100 installations of
	hardware or software in lost productivity, administrative cost, etc.
	Since people understand hardware keys, they're substantially less
	likely to lose them than a file on their disk (corrupted by a virus,
	struck by the hand of eris, stolen along with the rest of their
	machine, reformatted by their kids, etc.).  It's substantially easier
	to produce a small number of secure hardware backups than to really
	securely back up a single file, as I've found recently.
> 


I would be very pleased if ArcotSign were to be considered as a very good
implementation of centrally-managed public keys, without the hype about
software smartcards or patentability.  If that were the case, I think I could
recommend it to users for specific applications, such as a central service
authenticating third parties to multiple organizations' web servers, a
corporation with rigid internal trust barriers, etc.  As long as it is
associated with technically inaccurate hyperbole such as "software smartcard",
however, I can't really risk my own reputation by suggesting wholeheartedly 
that others use it -- certainly your own cryptographic community endorsements
from widely known cryptographers are meaningful, but if such an endorsement 
were inaccurate, I think a person like Schneier would have a lot easier time
remaining relatively respected than someone with less renown.  Thus, I'm
unwilling to take such a risk.
> 
> --
> 
> ++++++++++++++++++++++++++++++++++++++++++++
> 
> Marlin Gilbert
> Vice President, Business Development
> Arcot Systems
> 2197 East Bayshore Road
> Palo Alto, CA  94303-3219
> 
> Telephone:  650.470.8210
> Facsimile:  650.470.8208
> Cellular:  650.533.8993
> Pager:  650.849.9131
> Electronic Mail:  mailto:marlin@arcot.com
> Website:  http://www.arcot.com
> 
> ++++++++++++++++++++++++++++++++++++++++++++
> 
> --- end forwarded text
> 
> 
> -----------------
> Robert A. Hettinga <mailto: rah@philodox.com>
> Philodox Financial Technology Evangelism <http://www.philodox.com/>
> 44 Farquhar Street, Boston, MA 02131 USA
> "... however it may deserve respect for its usefulness and antiquity,
> [predicting the end of the world] has not been found agreeable to
> experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
> 


home help back first fref pref prev next nref lref last post