
Pioneers of web cryptography on the future of authentication - jeremiahlee
https://spectrum.ieee.org/tech-talk/telecom/security/pioneers-web-cryptography-future-authentication
======
bredren
When I founded Gliph, which ultimately became focused on privacy, secure
message and bitcoin, I was actually after identity. I even tried pitching it
as an "identity management platform."

Identity felt like hot idea back then ~2011, this concept of owning your own.
There was another company that raised a lot of money that was working on it,
Personal.com.

I was able to meet with Larry Drebes at the time who was involved early with
OpenID, and at the time was growing Janrain which was helping big companies
handle user federation.

That year, Chris Poole of 4Chan controversially said Facebook and Google had
it wrong: "Google and Facebook would have you believe that you are a mirror,
that there's one reflection that you have; one idea of self," Poole added.
"What you see in that mirror is what everybody else sees. But in fact, we're
more like diamonds: you can look at people from any angle and see something
totally different." [0]

Anyhow, a decade has passed and it feels like very little has happened with
identity, the ability to control identity away from centralized structures.

My advice to any of them would be that "identity" is not a product.
Authentication and federation to specific systems, useful features (i.e.
sharing photos of grandkids), these can be made into products.

[0] [https://mashable.com/2011/10/18/chris-poole-4chan-
web-2/](https://mashable.com/2011/10/18/chris-poole-4chan-web-2/)

~~~
chrisco255
What are your thoughts on [https://3box.io](https://3box.io) ? It's built on
Ethereum, but sounds like it might be similar to the vision for Gliph.

~~~
bredren
From my personal viewpoint, I think this is a cool idea and I like the ethos
that it seems to come from.

However, anything that does not delight a user is a mistake to build for a
startup.

"Reducing the risk" and "building trust" with users means nothing to users
when there is no useful product. So instead of integrating this and trying to
use this choice to market your product, you should be building a better
product and marketing that.

Because this won't sell any product.

Only a fraction of a fraction of people care where data is stored.

So if you have VC capital you should not be spending your time integrating
stuff like this you should be building something that people want to use.

Apple is able to play the long game on security and privacy cause they have
the cash and market position to do so. It is also the right thing to do, but
again they are in a special position to invest in these areas.

See also "choose boring technology"
[https://news.ycombinator.com/item?id=23444594](https://news.ycombinator.com/item?id=23444594)

Also, this is perhaps not directly related but more context for my parent
comment, Larry Drebes' email in 2013 about shutting down Janrain's openID
service:
[https://news.ycombinator.com/item?id=6328182](https://news.ycombinator.com/item?id=6328182)

------
motohagiography
Worked on this precise root of trust problem some years ago. Basic issue is,
fragmentation in the device marketplace means you can't have an endogenous
hardware root of trust on each device. Apple can do this because they own the
whole device stack. Providing this outside that closed ecosystem will have
hard limits foreseeably. That said, the only tech I am aware of that could
conceivably change the balance of this device fragmentation equation is FHE
that is sophisticated enough to perform nested standard encryption operations
for authentication.

Otherwise, your options are a separate yubikey-like token that you buy and
"personalize," with new keys and linking identity attributes to it, or some
weak variation of obfuscated code to store and process your root of trust key.

Business wise, the threat model has a catastrophic failure mode, where a
compromise likely exposes all users simultaneously, which becomes both worse
and more likely as you scale. Then there are the use cases for strong identity
proofing and authentication, where they all reduce to some powerful party
wanting someone else to adopt sufficiently strong identity to use as recourse
against them. Strong identity is for institutions to manage populations
interchangeably, and nobody signs up for that, it's regulated down onto them.

The conceptual test I use is, if it interferes with your ability to consume
drugs or pornography, it's not a viable consumer product.

Strong identity proofing without commensurately strong anonymity fails that
heuristic. Self sovereign identity is only viable if it's either anonymous and
disposable, or enforced downwards by a de-facto monopoly.

When I looked at the related startup company's site, I thought, "clearly the
VC investment triad decision was based on 'team+market', with 'product' to be
figured out later." I'm definitely not smarter than anyone involved there, but
the product hurdles in front of them are expensive, political, and complex.

~~~
lifeisstillgood
I may be very dumb but are you suggesting that Fully Homomorphic encryption
(FHE) could perform client authentication _in the cloud_?

Is it possible that I FHE-wrap my own private key, send it to you, and you can
sign with my key without the plain text? that sounds crazy? Am I missing
something?

~~~
motohagiography
The reason I suggested FHE might change this was the a few of the solutions
people have tried so far fall into the so-called "white box cryptography,"
bucket of key based obfuscators on your mobile/endpoint device. Depending on
the authentication scheme or security protocol, you need a secure place to
store your private key, a shared or derived secret, key encryption keys, or a
certificate, etc. We have to assume that the OS of that client device is going
to get rooted at some point and the security of those keys is gone - and with
it, the identity assurance they provided. (again, the secure element and
diversified initialization keys on apple devices is different, think of it as
a little client side hsm)

Instead of using WBC, in this hypothetical case FHE becomes the scheme for
performing a verification step without yielding information about the key to
an attacker with root on the device. It's another handwavey blackbox, but it's
a such a change in how we do security protocols that it's worth mentioning as
plausibly having consequences for authN. It's a hard problem that gets
addressed in areas like authenticated encryption, direct anonymous
attestation, and other more use case specific protocols. Someone working in
the field today would have more insight into it.

~~~
lifeisstillgood
Hmm, I was asking as a few days back the IBM FHE release provoked me to ask
what were the use cases for FHE? This seems to be, tantalisingly, the most
interesting so far.

~~~
motohagiography
If FHE has a practical internal xor operation, the idea of iterating a key and
diversification component/counter, e.g. like a FHE implementation of HOTP or
OCRA becomes really interesting. Even if it's slow, you could probably stack
the slow operations into the initialization/personalization phases.

Security and authN protocols are really just about using crypto to diffuse and
distribute risk, so it's conceivable there are use cases where FHE facilitates
shifting risk for key security onto the end user, like payment cards, etc.

~~~
lifeisstillgood
So, just checking in case I am being dumb, HOTP (like TOTP) works where both
parties have shared secret key (common in corporate remote logins).

The value here being that I can make my own secret key, and via FHE send the
server a "cloaked" key that they will get the right answer without knowing my
secret.

So apart from the initial key sharing, it's down to me to keep the key safe
(as you say, pushing risk into the consumer like debit cards)

Feels like it where FIDO goes next.

------
jeffbee
They give little regard to the actual history of "secure enclave" devices in
encryption. Smart cards with private keys generated on-device have been around
for decades. This is either the present or the near-past of authentication,
not the future.

------
lifeisstillgood
>>> What is authentication going to look like in 10 years?

>>> Jermoluk: Full sovereign identity. You should be in charge of your own
identity.

Yes. I mean this seems so obvious but it is refreshing to see someone, anyone,
say it.

Even I have a plan for a gravataar-like service for client certificates, so
it's not like this is hard stuff.

------
pwdisswordfish2
As internet users we are provided with a folder or a file full of
"certificates" by some item of software, e.g., an operating system, a web
browser, etc. In some cases, we have the choice of removing certain
certificates if we do not trust them or adding certificates that we choose to
trust. People online like to make assertions and argue about a so-called
"chain of trust". What if that "chain of trust" began with the user, not a
third party? In other words, the user created her own certificate (the root),
then selected and signed the "trusted" ones provided to her that _she_ deemed
trustworthy? The software would not be able to bypass the user's trust. Just
because an "approved" third party signed a certificate does not in and of
itself consitute trustworthiness by the user.

~~~
vbezhenar
Basically that's called web of trust and was implemented by GPG for decades.
It seems that even geeks don't really use that.

~~~
tialaramex
The Web of Trust approach can only scale by treating Trust as Transitive.

If your trust is confined to a few dozen co-conspirators it all works fine.

But when you try scale up it breaks badly because human trust is not actually
transitive.

PGP tries to fix that by asking you about two things, in the process further
worsening the UX. PGP asks Alice if she believes this key is Bob, and then
also if she _trusts_ Bob to decide who other people are for her.

Very quickly Alice will discover that unless she agrees to allow multiple such
transitive trust steps the "Web of trust" doesn't do much for her. Hopefully
she gives up at this point.

But if she keeps using it, then eventually the other shoe drops. Alice sends a
message to "Frank" which she intends to keep secret. But unfortunately it
doesn't actually go to Frank, the "Frank" identity was vouched for by Edgar.
Alice trusted Bob, who trusted Carol, and Carol trusted Dana, and
unfortunately Dana is a poor judge of character and trusted Edgar who isn't
very reliable.

~~~
pwdisswordfish2
Human trust is not actually transitive.

Is this like saying human trust cannot be 100% delegated?

If so, that seems to be the model of the third party CA system. As a user I
really have little say in "who", e.g., the web browser, should trust. I have
(unintentionally) delegated trust to third parties. They decide who I should
trust. As a user, I am not supposed to care about or understand this process.
This really does not sound like "authentication" to me because I have not
authenticated anything. Everything is being handled by third parties.

~~~
tialaramex
A conventional PKI ("the third party CA system") separates out this authority.
You trust Trent to discern who Bob, Carol, Dana, Edgar _and_ Frank are.

In choosing to engage in conversation with Dana, or even Edgar, you are not
obliged to accept their word as to the identity of Frank, that's always
Trent's job. And so Edgar's unreliability and Dana's poor character judgement
aren't a problem.

~~~
pwdisswordfish2
What if I already know "Carol"? Should a web browser block me from "conversing
with Carol" because I did not get "Trent's" approval first? Seems like I
should be the one who decides whether I approve of Carol or not. I am the one
taking the risk of "having the conversation".

------
rvz
Maybe they should next interview, Daniel J. Bernstein, Jason A. Donenfeld and
Ross Anderson on the recent developments and the future of authenticated
encryption.

------
kissgyorgy
From this:

    
    
        Spectrum: Where do we go next? What is authentication going to look like in 10 years?
        Jermoluk: Full sovereign identity. You should be in charge of your own identity. It is yours after all.
    

I have a new startup idea "My Identity" (or something like that), which would
work like this:

\- This needs a mobile app, which stores identity information.

\- A website shows it's QR code for registration.

\- Users scans the QR code with the mobile app, and checks which information
is requested and Approves or Deny.

\- When pressing Approve, the identity is sent to the website, which use it
for registering the user.

\- User should be able to fully control logins from the app, e.g. show a list
on logged in websites, force logout.

~~~
close04
> the identity is sent to the website

So it's more or less glorified autofill? It should at most give the site a
token. Imagine how signing in with Apple, Facebook, or Google works right now
but instead of having your identity with those 3, you have it in that app (or
somewhere) and it's all your own. Which means you have to replicate on the
user side some of the functionality that they offer and package it in a "fit
for a user" format. I mean in the end you're holding on to your whole online
identity so extra caution is needed.

------
troquerre
Handshake.org is a another project that’s giving users control of their
identity — specifically web identity. It’s an experimental new DNS protocol
that uses private keys to determine ownership of domains. This lets users
truly own their domains instead of renting names from TLD owners as the
existing system requires.

When users have completely sovereign identity they’ll also need some way to
share it. I could see Handshake being the solution here (keybase was another
viable alternative but they sold to zoom...)

------
patrickdet
Related to
[https://news.ycombinator.com/item?id=23459815](https://news.ycombinator.com/item?id=23459815)

------
staycoolboy
I'm bummed that authentication wasn't discussed until the last 2 paragraphs.
And then only topically.

> We figured out how to make a personal certificate authority on your own
> computer,

This isn't entirely true. I can make a self-signed cert, but there's no root
of trust exdcept my computer: someone else can make their own self-signed cert
claiming to be me.

I recently bought an SMIME cert from Sectigo for $20. There needs to be a
personal CA and commensurate tooling, but it is still not widely available for
non-miliatry.

Is there a way for me to get a personal cert that can be authenticated with a
CA? Because I've been looking for some time. MozillaZine has a page on SMIME
certs, but 80% of the names are crossed off.[1]

> muse of cryptography

Definitely Melpomone. ;)

[1]
[http://kb.mozillazine.org/Thunderbird_:_FAQs:_Get_an_SMIME_c...](http://kb.mozillazine.org/Thunderbird_:_FAQs:_Get_an_SMIME_certificate)

~~~
vbezhenar
My country (Kazakhstan) issues certificates to its citizens. They are signed
by a government CA. So if you want to authenticate a Kazakhstan citizen, you
can ask him to sign something and check his certificate. I've heard that many
other countries are issuing similar certificates. So it's possible to build an
universal service which would work for many countries.

~~~
Brian_K_White
Sounds like a great hammer to hold over any/all citizens. That government can
invalidate your cert any time. You won't be able to conduct any action which
requires it. I bet they aim for it to be required for everything sooner or
later, and merely _today_ it's probably not yet needed to buy milk.

~~~
vbezhenar
It's not any different from any other government ID.

------
doggydogs94
... How many things could you think of in technology that 40 plus years later
are still being used in essentially exactly the same form as it was created?
It’s not some niche thing that nobody has touched. It’s the heart of the
entire way the Internet works ...

That about says it all.

------
alexmingoia
The “one identity key management system to rule them all” seems like a problem
in search of a solution.

Why does every app have to use the same key management system?

What’s the problem with identity, exactly?

I already own my identity on every app I use. I know the password (or my
password manager does).

Take HN for example. There’s no significant difference between HN asking for a
password on a form, and asking a browser API for a certificate. Except the
latter is more complex and prone to error.

~~~
aj3
There is also the question of multiple accounts on the same service for
compartmentalization purposes. Right now you can do that in most places,
although it might require multiple phone numbers and might violate TOS.
Obviously, this could either provide privacy benefits or potential for abuse
depending on service.

It's not clear whether the "one identity" system is meant to prevent or
empower that. Looking at beyondcorp I'd guess it's meant to prevent.

------
shane256
Sounds like something related to passwords?
[https://beyondidentity.com/blog/sorry-about-all-
passwords](https://beyondidentity.com/blog/sorry-about-all-passwords)

~~~
atrilumen
[Meta] god damn it why is scrolljacking still a thing?

( And if they fail at this, why would I trust them with anything else? )

Shame!

------
jiveturkey
meh. this is an ad (after all, it's spectrum) for a new high profile
passwordless company. by focusing on the technology (certs) instead of the
user-visible benefit (passwordless), they are doing ... something.

if it were someone ordinary, i would write it off as another poorly conceived
and poorly run wannabe startup. but given the people involved, instead i find
it puzzling.

------
hannob
Not sure if I'm missing something, but have they interviewed two people who
were extremely influential in cryptography and a third guy who... once worked
at Bell Labs and is the CEO of a startup company?

~~~
nmelo
TJ Jermoluk used to be CEO of @Home Networks, President and COO at Silicon
Graphics and General Partner at KPCB.

~~~
cryptonector
So why is he relevant to "the Future of Authentication"?

I could see Martin Hellman being relevant, maybe. But there's no real
substance in this piece, certainly not from Jermoluk. What I got out of it is
that PKI is the answer. As I think DNS-based PKI is the answer, I think he's
not too far, but he's probably selling something I don't need or want.

~~~
nick-garfield
What do you mean by DNS-based PKI? That sounds interesting, but I can't quite
visualize what that is.

~~~
cryptonector
There are two options:

    
    
      - registries and registrars run name-constrained CAs
    
      - DNSSEC/DANE (RFC 6698 https://tools.ietf.org/html/rfc6698)

