embedded dropbear

[Rob Landley]

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