[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diffie's comments on Photuris

Ashar,

Thanks for forwarding that note from Whit. In thinking about it and
similar comments from you and others, I've tentatively decided to modify
Photuris to sign the shared secret.

I've been thinking about a related problem for some time: finding a
safe way to use my PGP key on my workstation at work.  If I were to
type my PGP passphrase into a machine I don't fully trust, I'd risk
compromising *all* of the traffic I have ever received or will receive
with that PGP key, including personal mail read only at home.

Using separate keys is one possible approach, but that's clumsy.

The ideal answer seems to be a smart-card that I can plug into the
workstation that safely holds my RSA secret key and uses it to perform
operations on behalf of the host without ever letting the secret key
leave the card.  For maximum safety, the card could log all operations
and possibly even require a manual "go" button press to approve each
operation.  Even in the smartcard the RSA secret key would exist in
plaintext only when it is in active use. At all other times it would
be encrypted in a symmetric algorithm; before use the user would have
to enter the key for the symmetric algorithm on a keypad on the card.
One might even store the encrypted secret key on the host, eliminating
the need for stable storage on the card. But this would place total
reliance on the secrecy of the key for the symmetric algorithm, which
is probably a bad idea given our experiences with badly chosen user
passwords.

A palmtop plugged into a serial port might make a good prototype
smartcard.

Well, you've made me realize that Photuris has to solve this same
problem. (Especially since I plan to use the existing PGP key
database.)  How can I limit the damage that can be done by hacked
workstation software to the compromise of the actual IPSP traffic I
send or receive on that workstation?

One approach already discussed is for the trusted signature function
to enforce a maximum lifetime on the signatures of DH public
halves. Kerberos does this, but it still leaves you vulnerable for a
time. Imagine a public workstation at Interop or IETF.  Somebody could
hack its "kdestroy" command to secretly squirrel away my tickets
before seeming to destroy them. I get up and walk away, and the attacker
sits down and continues to access my home system.

I'd like to prevent this in Photuris. If I sign the DH shared secret,
then it should suffice to destroy it along with all associated SAIDs
on just one end when I'm done (e.g., on my home system when I'm
accessing it from IETF). A locally snarfed {DH public value, DH secret
value, signature on shared secret} triple would then be useless if the
remote machine initiates a new DH exchange with a new DH public value.

Now this would seem to require that the remote system generate a new
DH key pair for every SAID. But this isn't really necessary. It would
be easy to add a message to Photuris to ask the other side to discard
its existing DH key pair ahead of schedule. I could send that message
whenever I log off and leave my local workstation to ensure that any
locally snarfed keying material would become completely useless. But I
could still rapidly generate a series of SAIDs from the same DH shared
secret for just the cost of an MD5 hash.

Comments?

Phil
References: