[Bug 3082] New: Add support for deterministically derived keys
bugzilla-daemon at bugzilla.mindrot.org
bugzilla-daemon at bugzilla.mindrot.org
Fri Oct 11 22:46:00 AEDT 2019
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.
More information about the openssh-bugs
mailing list