Plaintext attack vulnerabilities?
Brian Mearns
bmearns at ieee.org
Wed Jun 17 14:37:25 CEST 2009
On Tue, Jun 16, 2009 at 9:11 AM, Daniel Kahn
Gillmor<dkg at fifthhorseman.net> 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
More information about the Gnupg-users
mailing list