
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.

On Tue, 22 Sep 1998, Anonymous wrote: [On Arcot's virtual smartcard claims]
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.
With Arcot's system, an attacker could determine the key *software only, most likely even by remote*. Extracting keys from a smartcard requires *hardware and physical possesion of the token*. Which touches at the very core of the difference between tokens and software based solutions. The claims made on the vendor's homepage are simply false. There is no other way of putting it. -- Lucky Green <shamrock@cypherpunks.to> PGP v5 encrypted email preferred.
participants (2)
-
Anonymous
-
Lucky Green