[Cryptography] Follow up on my password replacement idea

[Bill Cox]

On Tue, Sep 22, 2015 at 1:35 PM, Phillip Hallam-Baker <phill at hallambaker.com
> wrote:

>
>
> On Tue, Sep 22, 2015 at 11:59 AM, Bill Cox <waywardgeek at gmail.com> wrote:
>
>> On Mon, Sep 21, 2015 at 12:28 AM, Ilya Kasnacheev <
>> ilya.kasnacheev at gmail.com> wrote:
>>
>>> What do you think of that? Because current situation with passwords on
>>> the internet is unmanageable and replacement is needed - waterproof enough
>>> to do users more good than harm.
>>>
>>
>>
>> I agree that a replacement, or at least a significant upgrade, is needed
>> to passwords.
>>
>
> I disagree.
>
>
> I think what is needed is a mechanism for managing a personal PKI so that
> there is no need for device authentication.
>

This effort sounds like a ton of work requiring a lot of good engineering.
If it did work out, it could be pretty huge.  Is it possible to sign up for
an account, yet?  I would be interested in kicking some tires.


> So what I do with the mesh right now.
>
>
> * Every user has their own profile with a master signing key.
> * Fingerprint of the profile is the fingerprint of the master signing key.
> * Every device has a device profile
> * Every device profile contains a unique signature key.
>
> So if Alice has a master signature key with the fingerprint:
>
> MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ
>
>
> Anyone can go to the Mesh and pull the profile for that fingerprint. That
> contains a collection of device profiles which are signed under an
> intermediary key which is in turn signed by the master signature key.
>
> So from a protocol point of view, I think it is obvious that we can very
> easily set up a scheme so that the device can prove that it has knowledge
> of a private key that has a credential chain under MB2GK... to authorize
> use as an authentication key. Further I think we all know good ways to
> ensure that the private key can only be unlocked if a passphrase is entered
> into the device to give a second factor (e.g. x = y + H(passphrase))
>

Protecting those private keys is difficult.  Malware might sniff them when
the user unlocks them.  A co-worker and I would like to build an
open-source a hardware-backed signing library with a common API on the
major platforms.  For example, the new SGX Intel extensions can enable more
secure rapid key signing.  Some operations have to be super-fast, like
Token Binding signature operations, while others, such as unlocking a key
when a user enters a password, can be slower, and may rely on signing in
secure hardware, such as a TPM.


> What I need to show then is how easy it is for Alice to add and remove
> devices from her profile published in the mesh.
>
> To add a device like a cell phone Alice has to do the following
>
> 1) Post a connection request to her mesh profile through her chosen portal
> (e.g. alice at cryptomesh.org).
>
> 2) Check that the request is posted to the right profile by verifying that
> the profile tool returns the correct fingerprint.
>
> 3) Confirm the connection request from a device that is authorized for
> administration and has the right key.
>
> At this point the profile manager on the admin device adds the new device
> to the profile and posts the update to the mesh.
>

I read some of your IETF document on the Mesh
<https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00>, and also
your email announcement
<https://www.mail-archive.com/endymail@ietf.org/msg00135.html>.  Your
project sounds ambitious.  However, secure authentication is a complex
problem.  One criticism I'm sure you hear is that the Mesh publishes
private keys to the world that can be used to "track" users.  There is a
trade-off here between privacy and security.  Algorithms can be used to
enhance privacy, but at some reduction in security.  It kills me that we
work so hard on anonymity, when most users are willing to click "Yes, let
this web site use my location data" when asked (including me).  I suspect
most users would be willing to use a potentially anonymous public profile
with a list of public keys to gain security, at least if it took zero
effort on their part.


> Removing devices is trickier because it amounts to revocation of an
> assertion. That means that the portal has to be trusted to actually post
> updates to the mesh.
>
> And that is a known hard problem. We can bound it in time by requiring
> Alice to log into one of her admin devices once a month so that an updated
> profile gets pushed. We can also use blockchain/CT like techniques to make
> default visible. I have several solutions that work, it is a question of
> how much effort is required for how much security.
>

Yep, these are tough problems.  To take this to the next level, the Mesh
may want to consider more than just signatures.  For example, if suddenly a
device is correctly authenticating to the Mess from Russia when all the
other user's devices remain in Idaho, that's a signal that maybe more
authentication factors are needed.  This can be more devices, answering
security questions, or sending an email to the user's default account
asking for confirmation.

However, anything that works is likely to be better than the mess we have
now :)

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150922/48b71d69/attachment.html>