Great explanation Rob,
Thanks much..
Ed
On 04/11/2013 04:56:54 PM, Ed Sutter wrote:
Hi,
I managed to get dropbear-ssh running under a uC/OS-II thread.
Obviously had to do a lot of hacking to make this work, and
I'm sure its not the most efficient way of doing it.
Not being an ssh/cryptography wizard by any stretch of the
imagination, I have two questions that may be trivial...
1..
Because I'm not on a Unix-ish system, I don't have any of
the /proc stuff or /dev/urandom for seedrandom(). Is it
essential that this function have *that* much random
input? How does this affect the security of the connection?
If you can predict the random seed, you can decrypt the entire
connection. All the other cryptography is based on exchanging
unguessable numbers in both directions.
Public key cryptography does a one-way mathematical trick on a really
big number to split it into two smaller numbers, so that each one is
the antidote to the other's poison. You scramble a message with one,
you need the OTHER to unscramble it. (You can't undo it with the one
that created it, that's the clever bit.)
You keep one of this pair of numbers secret (doesn't matter which,
they're symmetrical) as your private key and give the other out as
your public key. Anybody can use your public key to send you a message
which only you can read with your private key. And anyone can read
messages you send with your private key but only you could have sent
them. So in one direction it provides authentication, in the other it
provides privacy.
When you want a bidirectional connection providing both, each side
produces a pair of of keys (four keys total), then exchanges one and
keeps the other. Then you encrypt each packet TWICE, with your private
key and with the other guy's public key. At the other end they decrypt
with your public key (so the message could only have been created with
your private key, so it came from you) and their own private key (so
only they can read it). Doesn't matter what order the two
encryption/decryptions occur in as long as both sides agree.
Public key cryptography is really computationally expensive (I.E.
slow) so what they do is exchange symmetrical keys with it, which are
another unguessable secret number that's much faster to use, but which
requires both sides to know the _same_ unguessable secret. (The poison
is its own antidote, the key that encrypted is also the key that
undoes it. Simpler/faster math that way, but it means you need an
established relationship to use it.)
The rest of the connection is then encrypted with the symmetric keys.
(Well, it generates and exchanges fresh symmetric keys every once in a
while so that listeners won't have TOO much of the same kind of data
to try various clever attacks with to guess that key.) The public key
cryptography is just used to establish and verify the connection at
the start.
2..
I essentially hard-coded the -r option (ssh server) to use a
pre-established rsa_host_key file. Should this file be built
once for a given system, and then reused or is this something
that should be recreated each time the server is started?
The host key uniquely identifies the host. It's what gives you the
"host key has changed!" warning when somebody reinstalls the server.
Otherwise, anybody could intercept the connection, insert their own
ssh server, have you log into it, forward the credentials use use to
the other server to log into that, and pass data through in both
directions while logging all of it. This is called a "man in the
middle" attack, and you prevent it by giving each server a unique way
to identify itself that only itknows. (Basically you encrypt a packet
at it using its public key, and it decrypts it using its private key
and sends back the correct response based on its contents.)
And that's cryptography 101. :)
Rob
