Subject: [Mathmesh] Configure SSH with UDF key...

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Sep 2019 18:16:23 -0400

I am just writing a series of presentations on the Mesh to put out to
podcast to explain the concepts and the technology. The Mesh presents four
technologies that in combinations can solve a large number of difficult
problems.

UDF is the one Mesh technology that does not depend on any other and I keep
finding new uses. And the latest of these is to configure SSH.

The biggest hassle with SSH is how to install your private key on each of
the devices that you want to use it from. In theory of course, you want to
have an independent key for each device so that you are not completely
hosed if you lose one of them or you are passing through an airport and
someone demands you login to your laptop.

But most people have one private key and they move it from one machine to
another in email. Oh and 'most people' probably isn't most of the people
here. It only takes one pinhead to bust a hole in your corporate defenses.

So I have been looking at recovery mechanisms for Mesh profiles. And one
very promising approach is to use a KDF and a strong password to generate
them.

KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_signature")
KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_escrow")

So the encryption and signature keys are generated from Z
AR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA

All we need to do now is to escrow ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ which
we can do by Shamir Secret sharing.

What if we could also do

KDF ("ZAA5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN-AQQE", "ssh_client")

Now we have a really quick way to reconstitute the authentication key on
each of the user's devices.

What I was thinking of for implementation is to define a new type code,
probably 200 which gives an initial letter of Z. Then make the following
two bytes a 16 bit registry code saying what the key is to be used for
(Mesh, SSH, etc.)

Comments?

As with passwords, we might well need to help people follow their current
workflow in a not quite so stupid fashion before we try to change it.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Sep 2019 18:37:38 -0400

> here. It only takes one pinhead to bust a hole in your corporate defenses.

So you have a fairly reasonable use case.

I also observe the 90% of people don't use ssh private keys or understand how
to use ssh-agent, or understand that they can keep their private key in some
central place and use ssh -A/ssh-keyadd to gain access to it for the current
session.  This turns SSH into a far more KRB5-like ticket system with limited
lifetimes, and so the private key on the laptop only lets one get to the
"home cloud"(owncloud) machine that holds the master key.

But MMM should let us do other things with SSH keys.  Since 1996, I've wanted
to do signed statements about logins, rather than hacking
~/.ssh/authorized_keys files.

    > each of the user's devices.

If I understand you correctly, you are trying to find a way to generate the
private key(s) in a deterministic way from a master secret which can be
split?

This way, the user doesn't use email to distribute their private key, but
rather can just recover it each time they might need it after a dangerous
situation. (Such as going through a border control, etc.)

    > two bytes a 16 bit registry code saying what the key is to be used for

Seems like a useful thing.

    > workflow in a not quite so stupid fashion before we try to change it.

An illustrative video would help.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-