Hey Bruce, doesn't this response of yours imply that the OS is what is comprimised?, that either the access models and control of the File System on the target system (that is the one with the million PW's strewn about the disk file system) is setup wrong or is just not functional. Otherwise why would I want to take up critical disk space with a management process that had to manage a million disk-based entities. Oh and BTW - a simple runtime profiler (i.e. most of the runtime debuggers will suffice if they have trace capability) will crack which password is the right one, and I don't even need physical access to the machine to run it in Microsoft Land. Now if they used the CertCo model and split the key/pw into several sections and signed or encrypted them separately so that essentially you have a holographic PW its harder, but the Runtime Profiler is still capable of creating havoc in this model, I think. That is exactly the point why SW alone solutions cannot provide the levels of trust that some forms of commerce require. If the OS is untrustworthy and you have to replicate the components of the system to confuse an intruder as to which is the "active entitiy"... then whats to stop the same person from building a sleeper or coopting the User Memory Space. It seems to me that this effort will just stop people that are cruising through others filespaces in search of gold. As far as commercial trust models are concerned this solution, IMHO, is less than desirable and in some instances covers up but does not fix, various liability models for a complete system. It seems to me (standard disclaimers apply here), that in the real world, the best way to operate is to trust no one, not your OS, not your ISP, and especially not your own people. What that mandates is that there is some "anchor process" that binds both policy and the systems that implement it to the firmament. I believe that this is the key to making tools like CDSA and others (OpSec) more functional. Besides, Imagine the strength of an audit process based upon one of these immutable policy anchors. Todd
-----Original Message----- From: dbs@philodox.com [mailto:dbs@philodox.com]On Behalf Of Bruce Schneier Sent: Monday, September 21, 1998 3:27 AM To: Adam Shostack; Lucky Green; Ryan Lackey Cc: scott@loftesness.com; dbs@philodox.com; coderpunks@toad.com; cryptography@c2.net; cypherpunks@algebra.com Subject: Re: ArcotSign (was Re: Does security depend on hardware?)
On Sun, Sep 20, 1998 at 06:45:06PM +0200, Lucky Green wrote: | On Sat, 19 Sep 1998, Ryan Lackey wrote: | | > | > [from a discussion of tamper-resistant hardware for payment systems | > on dbs@philodox.com, a mailing list dedicated to digital bearer systems,
| o ArcotSignTM technology is a breakthrough that offers smart card tamper | resistance in software. Arcot is unique in this regard, and WebFort is the | only software-only web access control solution on the market
At 06:27 AM 9/21/98 -0400, Adam Shostack wrote: that offers
| smart card security, with software convenience and cost. [We have now | entered deep snake oil territory. Claims that software affords tamper | resistance comparable to hardware tokens are either based in dishonesty or | levels of incompetence in league with "just as secure pseudo-ontime | pads"]. | | In summary, based on the technical information provided by Arcot System, | the product is a software based authentication system using software based | client certificates.
I have no knowledge of Arcot's systems and can't comment on them. Hoever, there are ways to make software hard o disassmeble and/or tamper with. Given that Arcot is probably going to attack smartcards as being easily attacked, 'smartcard level' security is not that high a target, the claim may not be so outlandish.
They're not looking to do tamperproof software. Their business model can be best described as: "better than passwords, cheaper than SecurID."
Here's the basic idea: Strew a million passwords on your hard drive, and make it impossible to verify which is the correct one offline. So, someone who steals the password file off the client cannot run a cracking tool against the file.
Be intestesting to see how fast the code is. If they're embedding certs in complex code that needs to run to sign, then theft of the cert may be difficult.
It isn't bad.
Bruce ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com