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
