[Bug 3082] New: Add support for deterministically derived keys

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3082

            Bug ID: 3082
           Summary: Add support for deterministically derived keys
           Product: Portable OpenSSH
           Version: 8.1p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-keygen
          Assignee: unassigned-bugs at mindrot.org
          Reporter: nils.rennebarth at googlemail.com

Created attachment 3335
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3335&action=edit
patch for 8.0p1 to support derived keys

In our project we connect a cluster of appliances to a central managing
system via ssh. When a new appliance is deployed, the administrator
provides it with an ip address and a "connection password". Later, the
manager connects to the configured ip address (over a supposedly
untrusted network), and the "connection password" is used as a shared
secret to build a mutual trust and exchange long lived public keys that
secure all future communication.

[Yes, this provisioning procedure is outdated and should be replaced,
e.g. by letting the appliance generate a key pair locally and just
transmitting the public key to the managing system, but for now we
can't change the established procedure]

Connecting to an untrusted machine via ssh with password authentication
will immediately reveal the shared secret to a man-in-the-middle, so
using the shared secret this way is out of the question.

What we came up with instead is to use the shared secret by
deterministically deriving an ssh key pair on both, the appliance and
the manager. Each side installs the public key in its authorized_keys
file, the manager contacts the appliance first, using the key for
pubkey authentication, and transmit its IP address and its (public)
host key. The appliance will respond in the same way and transmit its
(public) host key. As soon as both sides did receive a message from the
other one, they can trust each other and exchange the long lived keys.

To support this method of trust establishment, I wrote the attached
patch for ssh-keygen, to derive a key from a given secret
eterministically (by seeding the PRNG). The patch applies cleanly to
the original 8.0p1 sources.

Would you consider adding this feature to ssh-keygen? Another possible
use case might be human memorizable key pairs, so I think it is not too
tightly bound to our specific use case.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.