[ntp:questions] Re: Cryptography

David L. Mills mills at udel.edu
Thu Dec 25 04:33:50 UTC 2003


Dale,

In your original scenario host D trusts C, B and A using a hash party
and all party players are honest and never cheat. The bad guys haven't
crashed the hash party, so can't fool the players. This model is
identical to the Autokey TC scheme, except that the TC uses a
certificate trail and you use a hash party. As pointed out in the report
and documentation, schemes like this are vulnerable to a middleman
attack where, in your scenario, say C is a terrorist with evil intent
who has joined the hash part unknown to the other players. The terrorist
then can lie, cheat and remain undetected.

Like very many other schemes like this, there needs to be a formal way
of picking out the good guys from the bad guys before signatures or
hashes are exchanged, since only the good guys are guaranteed never to
lie, cheat and steal. So, we add to your scheme some way for A to trust
that each hash operation was securely authenticated even if the ultimate
client D in your case was a bad guy. We don't care if D is or is not a
bad guy, just that all hashes were computed by trusted entities.

I have other problems with your scheme, which would seem to require
servers keep state about individual clients, which Autokey is forbidden
to do. But, I'm more concerned about the identity scheme which
determines, at least in the Autokey model, the group members. Much more
about this is said in the report and documents on the NTP project page.

To reduce the identity model to barest essentials, assume a trusted
agent (trusted primary server) rolls a secret value, performs some
opaque mathematical operation on it and sends the resulting group key
via secure means to all group members. A group member verifies another
host is a group member using a zero-knowledge proof algorithm in which
niether party knows the secret value and a bad guy cannot determine the
group key, even if overhearing the values of many algorithm exchanges.
The group key is of course encrypted by a secret key known only to the
holder and decrypted only as part of the identity exchange, so is hard
to steal and use successfully.

In principle, the group key could be used for a symmetric cryptosystem,
so there would be no need for a certificate trail. However, a host might
belong to more than one group where each group has a different group
key. Furthermore, group keys and/or certificates might have been
refreshed and invalidated old ones. This is why Autokey uses a
certificate trail to validate the servers on the path to the primary
server and verify identities along the way.

The bottom line is life is a lot more complicated than just running
certificate trails and hash parties.

Dave 

Dale Worley wrote:
> 
> "David L. Mills" <mills at udel.edu> writes:
> > In your scheme good guy B is assassinated and replaced by terrorist B'
> > who proceeds just like B but tells terrible lies.
> 
> I understand the concept of the man-in-the-middle attack, but I don't
> see how the scheme I proposed is vulnerable to it (other than in a
> denial-of-service sense).
> 
> E.g., using the notation of my original post, B' cannot "fake" a VB
> value, it can generate VB only after receiving the VC value in
> question (because it is a cryptographic hash of a string containing
> VC).  And the only property of B's behavior that the protocol depends
> on is that VB is generated after VC.
> 
> Dale



More information about the questions mailing list