Subject: [perpass] Stopping password sniffing

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Nov 2013 11:05:09 -0500

The biggest weakness in Internet protocols is relying on passwords for
authentication. What can we do to make the password mechanisms more secure
and to wean the Internet off passwords?

I don't want to start an NSA rathole here, but I need evidence to support
the above assertion and until the GRU or MOSSAD or PLA or whatever have
their Snowden event, I am limited to using the NSA.

1) NSA using Password sniffing in Attack:
http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html

2) The NSA gets rolled by Snowden using password sharing:
http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108?irpc=932

I don't think this problem is as insoluble as many imagine. What I think
has been the show stopper is that strong authentication techniques are an
all or nothing proposition that require both the site and the user to adopt
before the scheme is useful. This double ended adoption requirement
invariably leads to deployment deadlock in my experience.

What I suggest as an alternative is the following:

1) The user decides to unilaterally use a password in the cloud scheme that
allows them to store their passwords on one machine and access them from
any of their browsers.

2) The password in the cloud scheme uses randomly generated passwords that
are unique for each site and have 128 bits of randomness (min).

3) The browser implementing the password in the cloud scheme alerts the
site being contacted to the fact that it can support a direct user
authentication exchange that would make the user experience seamless and
support single sign on.

Note that this almost describes where we are right now. Pretty much every
browser already offers password in the cloud service. They are forced to by
market forces. But they don't support an interoperable, standards based
password in the cloud service which is the requirement for us to get to
step 3.

Interoperability is also a requirement to get to step 2.

I am not going to lock myself into one browser no matter how much the
management of Google or Firefox or Apple or Microsoft want that. It is not
going to happen and that is why I can't let the browser generate the
password for me.

I believe that we can make cloud log in a more secure option than current
single factor authentication. Remember that 95% of Internet accounts are
not financially sensitive. An authorization in the cloud service is
completely acceptable to me as a means of storing my Slashdot username and
password.

The remaining 5% have important security concerns but the real issue is
confirming critical transactions rather than access control to view the
site info. A simple cloud log in scheme is more than sufficient for access
to view my account details but I want a strong second factor to verify
transfers out of my account place stock trades, etc.

I plan to return to this after I get email security on a solid track with
some code.

-- 
Website: http://hallambaker.com/

---

From: Watson Ladd <[email-masked]>
Date: Tue, 12 Nov 2013 08:14:31 -0800

> and to wean the Internet off passwords?
Passwords are fine provided they are not reused, and transmitted over
secure channels.
> I don't think this problem is as insoluble as many imagine. What I think has
> been the show stopper is that strong authentication techniques are an all or
> nothing proposition that require both the site and the user to adopt before
> the scheme is useful. This double ended adoption requirement invariably
> leads to deployment deadlock in my experience.
Client certificates are already supported and widely deployed. The DOD
uses them on smartcards
for just about everything. The big problem is a UI issue.
> allows them to store their passwords on one machine and access them from any
> of their browsers.
>
> 3) The browser implementing the password in the cloud scheme alerts the site
> being contacted to the fact that it can support a direct user authentication
> exchange that would make the user experience seamless and support single
> sign on.
And we still have passwords being used. The direct exchange=autofill.

> single factor authentication. Remember that 95% of Internet accounts are not
> financially sensitive. An authorization in the cloud service is completely
> acceptable to me as a means of storing my Slashdot username and password.
So why does it need a 128-bit strong password? The issues you raised
involve much stronger
issues.
> confirming critical transactions rather than access control to view the site
> info. A simple cloud log in scheme is more than sufficient for access to
> view my account details but I want a strong second factor to verify
Somehow my mother's bank sent her a smart card and reader to validate
transactions. Other banks
use lists of one-time passwords, etc. This can be done today if the
customers care.
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Tue, 12 Nov 2013 16:28:23 +0000

> allows them to store their passwords on one machine and access them from any

I already do this with LastPass[1].

If we want to move forward with authentication for things like websites though, I'd rather see the cloud storing encrypted client certificates that are synchronized and then decrypted client side by a password.

> exchange that would make the user experience seamless and support single

LastPass can do an "auto-login", but this would be completely seamless with TLS client certs. If the site has to be changed anyway, why not do it properly?

This also leaves the option of having my certs on a smartcard, USB dongle, floppy disk, etc. instead of just in the "cloud".

Of course, if you wanted to build a system that syncs client certs, you could also add synchronizing of passwords into it, but I think that would only really discourage the adoption of the client certs.

Iain.

[1]: https://lastpass.com/

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683

________________________________________
From: [email-masked] <[email-masked]> on behalf of Watson Ladd <[email-masked]>
Sent: 12 November 2013 16:14
To: Phillip Hallam-Baker
Cc: perpass
Subject: Re: [perpass] Stopping password sniffing

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Nov 2013 08:29:13 -0800

In terms of minimizing password pain/insecurity, you should check out the
work of the Fido Alliance, which seems very promising to me.  They are
trying to cook up a protocol to describe the use of various 2-factor
hardware such as smart cards, USB keys, number dongles, biometrics, and so
on, so that you can use that stuff without getting tied to a particular
vendor/implementation. Yubikey has some very slick demos.

On Tue, Nov 12, 2013 at 8:05 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> 1) The user decides to unilaterally use a password in the cloud scheme
> that allows them to store their passwords on one machine and access them
> from any of their browsers.
>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 12 Nov 2013 08:37:25 -0800

On Nov 12, 2013, at 8:05 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> The biggest weakness in Internet protocols is relying on passwords for authentication. What can we do to make the password mechanisms more secure and to wean the Internet off passwords?
> 
> I don't want to start an NSA rathole here, but I need evidence to support the above assertion and until the GRU or MOSSAD or PLA or whatever have their Snowden event, I am limited to using the NSA.
> 
> 1) NSA using Password sniffing in Attack: http://boingboing.net/2013/11/11/gchq-used-fake-slashdot-linke.html

Thats false.  They didn't use password sniffing in this attack.  And overall reporting on that was pretty dismal.  

This was targeting information for a QUANTUMINSERT attack [1], aka packet injection/Man-on-the-Side for exploitation.  And there was no fake slashdot page, just fake packets.  I wish they were just password sniffing.

The goal is victim browser exploitation, using one of the two following possibilities (i'd bet the former, but both mechanisms effectively do the same thing):

a)  The NSA identifies those individuals it wants to target (in this case, technical employees at telco/internet firms in allied countries.)

b)  The NSA's wiretap waits for a Slashdot or LinkedIn page [1] indicating that the intended victim is logged in by examining page contents.  Once it has identified an intended victim, it now has the cookies for the victim. 

c)  On the next fetch from the victim to the targeted site (ideally for some inconsequential element, but with some tricks you can do it for a main-page), "shoot" a packet injection attack to have some inconsequential element redirect the victim to an exploit server (NSA calls this FOXACID, we civilians can do the same thing with Metasploit's HTTP server).

OR

b)  Look for DNS requests for Slashdot or Linkedin from possible victims, and packet inject a DNS reply to your proxy server...

Packet injection in either case is used instead of a traditional MITM because its effectively as powerful for anything w/o cryptography, yet much safer to install and use, since failures don't result in communication cuts, if you can't keep up you don't disrupt the network, its easier to install both with and without consent (after all, its 'just' a wiretap), etc.

The NSA has now created a world where any plaintext traffic isn't just an information leakage, but a potential vehicle for exploitation!

And by attacking allies as well as enemies, using a mechanism that is available (albeit without quite as much targeting precision) to effectively any adversary with a tap (France, China, Russia, Brazil, Israel, pretty much anybody can play these games [3]), the network backbone just became an incredibly hostile place.

If you are lucky, your adversary is any country your traffic passes through you other than your own.  If you are lucky.

[1] QUANTUM is the code-word/program for packet injection, and this is confirmed by Schneier's analysis of Snowden documents.  In Schneier's analysis he specifically linked to public speculation I made months earlier.

[2] ANY cleartext site which identifies logged in users will do, as long as the NSA has a sufficient parser to map page reply to user identification.

[3] Please contact your local Gamma International, hackingteam.it, and Vulpen sales representatives for details.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Robin Wilton <[email-masked]>
Date: Tue, 12 Nov 2013 16:50:07 +0000

Hi Iain,

> If we want to move forward with authentication for things like websites though, I'd rather see the cloud storing encrypted client certificates that are synchronized and then decrypted client side b…

This sounds interesting and rational, but it contains a lot of implied detail. Can you unpack it a little, e.g. explaining what's in the certificate, why it needs to be stored in that form, why it's encrypted, which steps of the protocol are assumed to depend on session-level encryption, and so on?    

Thx,
Robin

---

From: Robin Wilton <[email-masked]>
Date: Tue, 12 Nov 2013 16:56:01 +0000

For once, I am delighted that the LinkedIn authentication URL embedded in their emails to me never works...
(the redirect to LinkedIn seems to work, but then the site goes into a tight loop for some reason I am really not motivated to figure out).

Incidentally, if I understood Nick's analysis correctly, steps (b) and ( c ) are a good example of why I distrust app-based clients for services like LinkedIn - because it seems far harder to stop them using replayable long-term tokens than it is to stop a browser from doing so.

R
 
Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 12 Nov 2013 09:04:24 -0800

> (the redirect to LinkedIn seems to work, but then the site goes into a tight loop for some reason I am really not motivated to figure out).

Doesn't matter.  Their goal is to exploit you, not the server.  So as long as you log into A site which examining page content in the clear can identify you as you, this One Simple Trick (tm) works.

There are also tons of other targets if you don't mind being a little less discriminate.  E.g. advertising elements in the clear.

> Incidentally, if I understood Nick's analysis correctly, steps (b) and ( c ) are a good example of why I distrust app-based clients for services like LinkedIn - because it seems far harder to stop…

A bigger reason to not use app-based clients is the advertisement libraries, which tend to also run in the clear and introduce their own horrid suite of vulnerabilities which are also ripe targets for packet injection, either from the blackbone or on the local WiFi:

http://www.fireeye.com/blog/technical/2013/10/ad-vulna-a-vulnaggressive-vulnerable-aggressive-adware-threatening-millions.html

Overall, IMO, Android is only secure if you never install any applications.  As soon as you install too many random applications (especially advertisement-sponsored applications) from the Google Play store, your phone should be assumed to be vulnerable to network-based attacks from any adversary who can see your traffic.

iOS is much better in this respect, simply because without escalating to root (a jailbreak exploit), even a corrupted app can't do all that much, since apple provides a MUCH more limited API and privacy-sensitive items are prompt on first use.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 12 Nov 2013 18:26:24 +0100

>and to wean the Internet off passwords?

When I started learning about web development in the late 1990s it came
a bit as shock to me that other people can know my passwords. They are
supposed to be secret! Later I learned it isn't even necessary for any-
one other than me to know my passwords, except for convenience maybe. I
also learned implementations of mechanisms like HTTP Authentication are
so bad users cannot know whether they are logged in and cannot log out!
These days it is normal and expected that devices and operating systems
steal your passwords and passwords that have been entrusted to you. Not
to mention this web forms + cookie madness.

As far as web browsers are concerned, whether you are identifying to a
web site, using which identity, including login and logout, is clearly
a browser user interface concern, not a web site concern. My passwords
are only needed on my devices so they can prove that I have them. These
days I can easily synchronise them myself by holding my smartphone in
front of a webcam if copying files over a wireless network is too hard.
I can also easily back them up by printing a protected version of them.
Beautifully, I can also use other people's devices to use services that
I identify to without risking that my passwords are compromised. As far
as theory is concerned anyway. That is what I would be interested in.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tim Bray <[email-masked]>
Date: Tue, 12 Nov 2013 09:27:15 -0800

On Nov 12, 2013 9:04 AM, "Nicholas Weaver" <[email-masked]>
wrote:

> Overall, IMO, Android is only secure if you never install any
applications.  As soon as you install too many random applications
(especially advertisement-sponsored applications) from the Google Play
store, your phone should be assumed to be vulnerable to network-based
attacks from any adversary who can see your traffic.

I disagree. A rooted/jailbroken device is obviously a bomb waiting to go
off, but the Android and iOS security models are both pretty good otherwise.

The discussion of when to prompt is tricky. Arguably, prompt on first use
penalizes good apps, because the bad guys ask for everything at install
time... people rarely actually look at those prompts. There are points on
the other side too, but it's not a slam dunk.

>
> iOS is much better in this respect, simply because without escalating to
root (a jailbreak exploit), even a corrupted app can't do all that much,
since apple provides a MUCH more limited API and privacy-sensitive items
are prompt on first use.

---

From: Robin Wilton <[email-masked]>
Date: Tue, 12 Nov 2013 17:42:02 +0000

+1  -  Stating Björn's position slightly differently: we need to acknowledge explicitly, as a design point, that many passwords are used by "password-aware proxies", not by the end-user.

R

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Nov 2013 10:41:53 -0800

On Tue, Nov 12, 2013 at 8:37 AM, Nicholas Weaver
<[email-masked]>wrote:

> > I don't want to start an NSA rathole here, but I need evidence to
> support the above assertion and until the GRU or MOSSAD or PLA or whatever
> have their Snowden event, I am limited to using the NSA.
> >
> Thats false.  They didn't use password sniffing in this attack.  And
> overall reporting on that was pretty dismal.
>

> This was targeting information for a QUANTUMINSERT attack [1], aka packet
> injection/Man-on-the-Side for exploitation.  And there was no fake slashdot
> page, just fake packets.  I wish they were just password sniffing.
>

The cookie stealing attack is easier to prevent:

https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/

Basically the protocol is as follows:

1) Client tells server 'I accept strong cookies'

2) Server sends an algorithm and shared secret in the HTTP channel

3) Client presents the usual cookie plus a MAC value calculated over some
of the request and the shared secret exchanged earlier.

4) Server authenticates response in the same way.

The mechanism can be optionally bound to the TLS channel and the request
content.

The initial exchange is preferably protected by TLS but this is not
essential. The main objective is to avoid repeated transfer of a bearer
credential.

If plaintext exchange is going to be frequent, a DH exchange should be
available as an option.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Wed, 13 Nov 2013 10:24:29 +0000

I'm talking about storing TLS client certificates encrypted in the cloud and synchronising them across browsers, decrypting them client side with a symmetric key generated from a password.

This removes a lot of the password specific problems like simply replaying a password that the NSA saw you type through a CCTV camera.

RFC2246 contains details about how clients can authenticate to servers using TLS. The fact that TLS is being used would also mean the connection is encrypted, avoid sniffing of the wires being a problem (unless the server's priv key is compromised or unless there's a downgrade attack and a NULL cipher is used or a poor cipher is used).

It's encrypted to prevent the cloud provider from being able to hand over the certificate.

It doesn't necessarily have to encrypted and synchronised in the cloud, an alternative is smartcards for storage or USB dongles. These devices are already readily available[1].

Iain.

[1]: http://g10code.com/p-card.html

Tel: +44 1224 27 2799

________________________________
From: Robin Wilton <[email-masked]>
Sent: 12 November 2013 16:50
To: Learmonth, Iain Ross
Cc: Watson Ladd; Phillip Hallam-Baker; perpass
Subject: Re: [perpass] Stopping password sniffing

Hi Iain,

Thx,
Robin

Iain.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Nov 2013 11:54:25 +0000

On 13 November 2013 10:24, Learmonth, Iain Ross
<[email-masked]> wrote:
> I'm talking about storing TLS client certificates encrypted in the cloud and
> synchronising them across browsers, decrypting them client side with a
> symmetric key generated from a password.

http://www.links.org/files/nigori/nigori-protocol-01.html

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Wed, 13 Nov 2013 13:26:59 +0000

I don't know enough about crypto to make a decision as to whether or not enough protection is provided, but if the abstract is an accurate representation, then Nigori would fit perfectly for this task.

A quick web search doesn't seem to show any method of installing client certificates in Firefox with an extension, but there are ways of doing it quite easily with Internet Explorer (using the Windows Certificate Store).

Currently Nigori only seems to support the storage of passwords and RSA keys but I imagine it wouldn't be hard to define a new type for X.509 certificates and keys.

If Nigori can be standardized and then integrated into client applications (like web browsers, mail clients, anything that uses or can use TLS) then I believe we'd have half the solution. The other half would be convincing service providers to allow TLS authentication.

Another thought though - How would a service provider get the public TLS cert? Typically, I've had to copy and paste the cert into a box or a config file.

Another another thought - Is it a good idea to use multiple certs for different services or just one for all? Reuse shouldn't be a problem here but there may be cases I'm not thinking of. It would probably be a good idea to allow for switching "profiles" which would use a different cert store (in case of multiple accounts on one service provider).

If I'm logged into my email but then want to post on a different Twitter account and switch store to log into that Twitter account, I'd not have my email anymore. Do we need a method of selecting a cert to serve to different websites and then remembering it for that session until the browser is told to use a different one?

Iain.

Tel: +44 1224 27 2799

________________________________________
From: Ben Laurie <[email-masked]>
Sent: 13 November 2013 11:54
To: Learmonth, Iain Ross
Cc: Robin Wilton; perpass
Subject: Re: [perpass] Stopping password sniffing

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 09:43:24 -0500

> I'm talking about storing TLS client certificates encrypted in the cloud and synchronising them across browsers, decrypting them client side with a symmetric key generated from a password.

Why use cloud sync and shared keys?   Why not have a different cert on each browser, signed by my master key, and then certify the master key?   Granted this leaves open a pretty big hole if the master key is compromised, and we don't really care this much about most of our web logins, but storing the client key in the cloud seems chancy, particularly if it's protected by a password.   Of course, storing the master key on a virus-infected PC is no better, but if your PC is infected with a virus, your cloud-stored cert will be revealed anyway.   A custom rPI that serves as your key master and never does anything else would be a good, cheap option.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Nov 2013 14:47:45 +0000

> Another another thought - Is it a good idea to use multiple certs for different services or just one for all? Reuse shouldn't be a problem here but there may be cases I'm not thinking of. It would…

The problem with re-use is that it introduces a pretty big privacy
problem. So, I'd say a cert per service.

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Wed, 13 Nov 2013 14:56:55 +0000

I was about to say signing client keys with a master key was a good idea. It would remove the need for a cloud sync as once set up, the browsers would inherit the access from the master key without the need for synchronization.

Then, yes, re-use would allow for tracking across websites. So maybe not such a great idea.

Maybe the compromise is not a cert per service, but a cert per identity (in the loosest possible sense of the word). Maybe your social media accounts where you are you are under one, and your reddit and slashdot accounts under another, etc. 

If it's possible to have the keys available on the devices you need without having anything on a server not controlled by the owner of the keys, that is the best case scenario, but if new identities are created "at runtime" (i.e. after the inital setup of the device) then those keys need to find their way into the other devices.

With a smartcard, this is as easy as plugging the smartcard into the device you're using, but - another thought - would probably mean requiring multiple smartcards as I am logged into my email on about 4 different devices at a time.

I'm not sure with TLS client authentication if it just tries all the personal keys it has or if the server advertises which keys would be accepted. I'm guessing it'll be the former so even if there is one key per service, the other certs would still become known to the server when authentication using them is attempted?

Iain.

Tel: +44 1224 27 2799

Sent: 13 November 2013 14:47

---

From: "Learmonth, Iain Ross" <[email-masked]>
Date: Wed, 13 Nov 2013 16:30:11 +0000

> What would be ideal would be for the site to provide a site ID that can be validated using existing PKI.

combined with

>  one master key per site

does sound good. This is going to require modifications (an extension) to TLS though, which is possible but does mean developing new technology, not just new ways of leveraging existing ones. I'm not against this, just pointing it out.

> single-purpose key server

How would this key server work? Looking at X.509 key servers, they only ever seem to store the public key, which the website would already have anyway. I know with gpg-agent you can forward that to remote servers, but I've never seen anyone pulling it from somewhere.

A privacy bonus: if you have a key for each site you have an account on, you know where you have accounts and don't have old inaccessible accounts leaking information (unless you lose the keys).

Iain.

Tel: +44 1224 27 2799

________________________________________
From: Ted Lemon <[email-masked]>
Sent: 13 November 2013 16:12
To: Learmonth, Iain Ross
Subject: Re: [perpass] Stopping password sniffing

> Then, yes, re-use would allow for tracking across websites. So maybe not such a great idea.

Yeah, that's a flaw.

> Maybe the compromise is not a cert per service, but a cert per identity (in the loosest possible sense of the word). Maybe your social media accounts where you are you are under one, and your reddi…

There's no particular reason not to have one key per site, other than that it's hard to define what "site" means.   This could generalize to one master key per site, so you preserve privacy but still get the nice properties of a master key versus a cloud keychain.   Of course now you need to generate keys more frequently, so that places some new pressure on the key server.

> With a smartcard, this is as easy as plugging the smartcard into the device you're using, but - another thought - would probably mean requiring multiple smartcards as I am logged into my email on a…

I don't think the smartcard works, because your devices may not have a convenient way to connect to it other than over the network.   And in that case, why not just have a single-purpose key server?

> I'm not sure with TLS client authentication if it just tries all the personal keys it has or if the server advertises which keys would be accepted. I'm guessing it'll be the former so even if there…

What would be ideal would be for the site to provide a site ID that can be validated using existing PKI.   Once the site ID has been validated, you look in your key cache for an identity that is associated with that site ID.   If you find one, you use the cert to log in.   If you don't fine one, you don't have an account on that site.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Nov 2013 13:06:12 -0500

> How would this key server work? Looking at X.509 key servers, they only ever seem to store the public key, which the website would already have anyway. I know with gpg-agent you can forward that to…

The key server would have a collection of public/private key pairs.   When you establish an account at a new site, your browser contacts the server and asks it to generate a new master key pair for the site.   The browser generates a per-site key pair and sends the public half to the server; the server hands back a cert signing that key with the new per-site master key it generated.   Your other devices are notified asynchronously of the new relationship, and generate their own keys, which are signed with the same per-site master key.   No secret key ever crosses the network.

> A privacy bonus: if you have a key for each site you have an account on, you know where you have accounts and don't have old inaccessible accounts leaking information (unless you lose the keys).

Yup.   And if you lose your key server, the usual strategies for recovering your password would still work.   And your key server can do live certificate revocation.   So if someone manages to associate a device with your key server that you didn't intend, you can see it on the list of devices and revoke all its keys.   Which means that the compromise of the key store on one of your devices need not require that you re-key all your accounts—only the compromise of the server would require that.

Of course, live certificate revocation loses you the privacy win of using separate keys, since the IP address would be the same for all queries, so maybe that part isn't such a good idea.   A distributed revocation service would prevent that, but it probably wouldn't be possible to notice keys quite as easily.

And of course if all your HTTP queries come from the same IP address, sites that communicate can do correlation that way anyway, which means that the per-site master key isn't that useful without a scheme for obfuscating IP addresses.

Sigh.

Privacy is hard.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Nov 2013 15:18:35 -0500

On Wed, Nov 13, 2013 at 1:06 PM, Ted Lemon <[email-masked]> wrote:

> > How would this key server work? Looking at X.509 key servers, they only
> ever seem to store the public key, which the website would already have
> anyway. I know with gpg-agent you can forward that to remote servers, but
> I've never seen anyone pulling it from somewhere.
>
> The key server would have a collection of public/private key pairs.   When
> you establish an account at a new site, your browser contacts the server
> and asks it to generate a new master key pair for the site.   The browser
> generates a per-site key pair and sends the public half to the server; the
> server hands back a cert signing that key with the new per-site master key
> it generated.   Your other devices are notified asynchronously of the new
> relationship, and generate their own keys, which are signed with the same
> per-site master key.   No secret key ever crosses the network.

That is essentially the CardSpace model but taking account of roaming needs.

My view is that either you should use one public keypair per device or if
the authentication keys are going to be per site then you should use a
strong (non user chosen) symmetric key and a proof of possession scheme.

There is really no value to a public key scheme for authentication if there
are only two parties to the conversation and no need for non repudiation.