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
