On Tue, Jun 16, 2009 at 9:11 AM, Daniel Kahn Gillmor<[email protected]> wrote: > On 06/16/2009 06:44 AM, Brian Mearns wrote: >> Are there any known vulnerabilities associated with an attacker who >> can provide plaintext and receive a signature for it? I'm planning a >> simple computer-auth system where a client sends a random token to the >> server, and then the server signs and returns it to prove that the >> server has the private key. I'm wondering if a malicious client could >> provide a certain plain text such it could learn something about the >> private key based on the returned signature. > > The client may or may not be able to learn anything about the private > key directly, but there are other serious attacks that such a scheme > could be vulnerable to. > > For example, a relay or man-in-the-middle attack is possible: > > Alice wants to bob.example.org, a server run by Bob. Mallory happens to > have a machine (mallory.example.net) on the network path between Alice > and bob.example.org. > > mallory.example.net intercepts the traffic, and answers to Alice as > though it were bob.example.org. > > Alice asks mallory.example.net to prove that it is bob.example.org by > supplying it a random token to sign. > > mallory.example.net in turn opens a connection to the real > bob.example.org, pretending to be Alice, and hands it the same token, > which bob.example.org signs and returns to mallory.example.net > > mallory.example.net replays bob.e.o's signature to Alice to establish > its fake identity. > > ---- > > If the bob.example.org uses the same key for other purposes (e.g. > identity certification, or more generally as a primary key), there are > still other attacks that are possible. > > Why design your own protocol? There are several public-key-based > network authentication protocols (using OpenPGP or not) which already > exist and have been vetted, many of which have free implementations you > can use! For example, you could use RFC 5081 (TLS with OpenPGP > certificates). This is not widely adopted at the moment, but it is > implemented in recent versions of GnuTLS. > > As a rule of thumb, any asymmetric key which is set up to automatically > sign arbitrary plaintext provided by possible attackers is opening the > door to potential compromise. > > --dkg > >
Thanks for the response, Daniel. The man-in-the-middle attack isn't a concern for me because the server is behind a firewall. The setup here is that the client is a laptop and I'm looking for a simple, automatic way to determine whether or not it's on a particular network by sending a string to a certain LAN IP address (192.168.*.*), and confirming that it comes back signed with the correct key. This isn't actually for secure communications, so a man in the middle who's also behind the firewall is no big deal: the "attack" will only work if we're all on the same LAN, so it will still confirm what I want it to. The attack I'm worried about (which I've learned is called a "chosen plain-text attack") is that a malicious client on the LAN will send particular strings to the server and be able to learn about the server's key based on the response. To avoid this, I thought I could have the server concat it's own random string to the one sent by the client, then send back a digest of the combined string along with a signature. That way, the client can guarantee (more or less) that it's a unique string (so someone couldn't spoof the response from the server), but cannot reasonably choose the plain text. I think this is pretty much how the TLS handshake works, anyway. The reason I'm rolling my own is, well for one I have a bad habit of doing exactly that (reinventing wheels), plus I want something simpler than a full TLS session, specifically, I want to use UDP instead of TCP to reduce network traffic, and I want it to just be a two-transmission operation, also to reduce network traffic. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
