Here is my proposal based on experience doing something similar:

1. Establish the TLS session with a strong DH agreement, but no
certificate or an untrusted unchecked server certificate.  While
establishing the TLS session, hash all the "encrypted" handshake
traffic up to a specific point with a strong hash algorithm such
as SHA256 (the attacker can see these bytes so they are not
secret).

2. On the secure channel, the client sends a short command and
gets back the servers copy of the hash, which it compares.  The
client now knows the forward-secret channel is with the server
with no man-in-the-middle.

3. On the secure channel, the client sends back a short command
saying OK, all verified.  The server now also knows the channel is
with the client with no man-in-the-middle.

4. The TLS session is now secure (within cryptographic limits).

On 11/29/2011 6:36 AM, Fred Testudo wrote:

I'd welcome some advice on using an existing channel as authentication for a new connection.

The client has a narrow authenticated channel to the server; I need to set up a normal TLS connection to the same server authenticated by proof of having the other connection. There is a client identifier associated with the authenticated channel, there can be a few thousand clients. The client should not have any built-in secret or private information, certificates, or similar. Exchanges on the narrow channel are visible to an eavesdropper but can't be modified; the TLS connection will be over an open network so can be observed and interfered with (including man-in-the-middle). I need the TLS connection to be private and authenticated, preferably with forward security; it needs to be "reasonably secure", the preferred cipher is RC4_128.

The authenticated channel is very narrow and awkward to use. Communication is by request and response initiated from the client. The client can send about 12 bits in each request and get 2 octets in reply, or send 5 bits and get 255 octets in reply (and scaling in between). It would be much simpler at the server to use just a single request, but I've not been able to think of anything remotely secure based on so small an exchange; it would be great if someone could come up with something. I'd prefer to keep the number of exchanges small at least.

I've little experience of cryptography, so I've described the problem rather than diving immediately into my ideas for dealing with it. I'll mention my ideas now for amusement, then it would be great if the experts here could give me some good ones.

My basic idea is to do a small Diffie-Hellman agreement over the narrow channel (with pre-arranged modulus and generator), and use the derived secret as the pre-shared key in a TLS_PSK connection. Minimizing the exchanges on the narrow channel would result in a weaker secret, so I need to understand how weak it can be while still reasonably secure.

- I could make the secret be a one-time password and limit its lifetime (say to a couple of minutes). I assume this would allow a fairly weak secret to give reasonably secure authentication.

- I'm not clear how the strength of the PSK affects the strength of the encryption on the connection; if the PSK is only 40 bits, for example, does that mean that a TLS_PSK_WITH_RC4_128_SHA connection would only have 40 bit security? Assuming a weak PSK weakens the encryption, could I correct for that by using TLS_DHE_PSK to incorporate a stronger key in the connection? I see that OpenSSL doesn't currently implement the DHE subset of PSK; could I get an equivalent effect by using TLS_PSK to get an authenticated connection then immediately forcing secure renegotiation to TLS_DH_anon?

With this sort of scheme, could a DH agreement with a 48 bit modulus (or even smaller) give me reasonable security?

I'll be grateful for any comments, both to rip apart my ideas if they're nonsense and to give me any pointers on how to solve this.

Thanks,

            Fred


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to