Re: ArcotSign

[Anonymous <nobody@replay.com>]

Greg Broiles writes:
> I'm certainly not a cryptographer, but I'm somewhat at a loss in trying to
> understand the purpose of using public-key (or asymmetric key)
> cryptography within a policy/technology system which won't allow the use
> of the strengths of asymmetric key crypto. As I understand the paper you
> reference above, to implement this system the public key must be kept
> confidential, and signed documents must also be kept confidential, or the
> system of the security as a whole is at risk. With those constraints, why
> bother with the overhead (computationally/technically/legally) of
> asymmetric key crypto at all? 

Based on http://www.arcot.com/camo2.html, the idea is to defend against
an attacker who manages to steal a copy of the secret key file, and who
then tries to guess the passphrase which protects it.  The file data
is encrypted in an unstructured generic manner so that all decryptions
look like random data, even the correct one.  This gives the attacker
no information about when he has guessed the correct passphrase.

For this to work, the public key has to be kept secret(!).  Otherwise the
right passphrase could be discovered by testing the decrypted private key
against the public key.  Arcot suggests that this would be appropriate
for an environment where only one or a few trusted servers need to
authenticate users.  These servers would be the only ones which have
copies of the public keys.  (It is not necessary that signed documents be
kept confidential, however a randomized signing algorithm must be used.)

As Greg points out, much the same could be accomplished simply by having
the servers share secret 3DES keys with their users, each user having his
own private 3DES key.  The users could encrypt messages using their 3DES
key and the server would decrypt using the appropriate key, which would
also serve to authenticate the user.

The Arcot people suggest that an advantage over this scheme is that
servers don't have to store information on all clients.  But much the same
thing could be done with symmetric cryptography.  In the Arcot system,
the client sends his public key certificate, encrypted to the server,
along with his request.  The server receives the cert and uses it to
verify/decrypt the message.  With symmetric cryptography, the client
could have the shared 3DES key encrypted using the server's public key,
and send that along with his message in a similar way.

The confusing thing about the Arcot system is this: how sensitive is the
public key?  Is it as sensitive as a shared secret key?  Superficially
not, since in order to exploit the public key you also have to steal the
private key file and then guess the passphrase.  But on the other hand,
if this is more than security through obscurity, you have to treat
it in many ways as equally sensitive.  Users of the Arcot system,
believing that they are safe because their public keys are secret,
may become casual about revealing their private key files and choosing
easy to guess passphrases.  They might even send the files around via
insecure channels.  With this kind of usage, the public key does become
just as sensitive as a shared secret key would be.

In that case, not only the servers, but all parts of the PKI must be
brought inside the trust boundary.  They are all holding material which,
if revealed, would compromise the security around which the system
is built.  You end up with trust relationships more similar to those in
a system like Kerberos than in a normal PKI.

> Is it really necessary/useful to call the scheme "software smart cards"?
> If it were called "An improved system for user authentication", I don't
> think it would make people nearly so suspicious. From my perspective, one
> of the advantages of smart card technology is that I can carry my
> authentication material with me; a system which puts it on my hard disk is
> less attractive. Floppies are portable, but not durable. 

The analogy with smart cards is that these cards protect your private key.
With a perfect smart card, an attacker can't do any better than chance
guessing of your private key.  With the Arcot system, the same is true.
Decrypting the private key file gives no information about its content,
because pure random data is encrypted.  Therefore with their system the
attacker also can't do better than chance guessing.

However this ignores the cost of the system, discarding many of the
advantages of public key cryptography.  You don't have to do that if you
use smart cards.

> I didn't understand the relationship between this scheme and Rivest's
> chaffing and winnowing which you note was cited as a reference in the SSC
> paper - would you (or someone else) mind explaining the connection?

Yes, this seems obscure.