Thanks Jakob; that's simple and elegant, and a much better fit for how my authentic channel operates.
I'm not quite sure what you mean by the phrase 'all the "encrypted" handshake traffic up to a specific point'. I think it should work if I hash the entire handshake, which I could collect using the message callback functionality looking for handshake messages - or am I missing some subtlety here? One end may not use OpenSSL; is there some other reliable way to collect the appropriate data, perhaps all the raw data stream until connection complete is indicated? On Tue, Nov 29, 2011 at 2:59 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > 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 >> >