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