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
>>
>

Reply via email to