embedded dropbear

Ed Sutter ed.sutter at alcatel-lucent.com
Fri Apr 12 19:59:50 WST 2013


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



More information about the Dropbear mailing list