Anonymous Authentication With Public Key Cryptography

Posted:   |  More posts about privacy authentication public-key

I was looking at BrowserID which is an awesome decentralised authentication system that allows anybody with an email address to authenticate with a single identity. However, what if you don't want the service you are authenticating with to know your email address? What if you want several "single identities"? What if you want to be anonymous?

I've come up with a system which should help separate your personal identity from the account & data.

The Solution Domain

I pondered the idea of simply removing the email address from the User Certificate, but then I realised that the email address is essential for the RP (Relying Party, the service you are trying to authenticate with) to know which account the certificate relates to.

So then it hit me: just use Public Key cryptography (RSA keypairs, like SSH does) to authenticate. We will rely on the fact that you have the private key (and possibly also a password) to uniquely identify and authenticate you. Sure we could just use usernames and passwords for this (and never ask for an email) but that would be crappy. Why not build a system that supports encrypted messaging and supports secure management of keys from a personal repository?

Users can have complete control over what key repository they use - and users can use a single password for that key repository (or none at all!) to allow access and management for all their keys. Such a repository could be local or remote and could have any number of mangement features (at least key creation and deletion) and perhaps also provide APIs for existing authentication methods such as OpenID and OAuth.

But don't most web services also need your address to send you notifications? The proposed system also deals with that. Your private key could be used to encrypt notifications which can be thrown into a giant anonymous mixing bowl message store, or attached to an API endpoint (or PubSub node?) from which you can retrieve them and decrypt them using your private key.


The authentication process could go like this:

  1. A traditional HTTPS session is intialised.
  2. Client requests token encrypted with Public Key from RP (key selected by username).
  3. Client decodes encrypted token with Private Key and asks RP for validation.
  4. RP Accepts or Denies authentication based on if the decoded token matches the original unencrytped token or not.

Considerations and Supporting Infrastructure

This system has to be manageable and so nice keystore applications need to be made. Obviously, local keystores would be the most secure and anonymous but remote keystore services would be the most convenient. Wherever the keystore is located I think that the RP should not know where it is, as this may help give clues as to your identity (eg. "" would be a dead giveaway).

To keep the location of the keystore anonymous, keys stored in a web application could be fetched for use in the login form using a JSONP AJAX request as a normal AJAX pattern would require CORS which would expose location of the keystore. Alternatively, if users used a browser extension to handle fetching/loading of private keys then the location of the keystore will not be discoverable.

This system also should be able to deal with 2-factor authentication (you have the key and you know a password) and I can't see why private keys can't also be password-protected client side as well. RP accounts could probably support multiple public keys so that users may have a recovery key option available to them. This key could be one which is kept offline for security reasons and off-site for disaster protection.

There are a few problems that I don't have answers for yet - but I know are dealt with in other authentication methods that I can research...

  • What should the token validity restraints (eg. time) be?
  • How long does the private key have to be in memory for? How can we ensure it is flushed?

Why Not?...

I am guessing that some will be wondering Why not use SSL PKI? - well that's because:

  • Users have to install certificates. This is a pain, especially on mobile devices.
  • Users have to secure endpoints containing their precious certificates. This is tricky on shared computers and mobile devices.
  • My method can be easily integrated into existing web applications.
  • My method does not require HTTP server or client support for SSL PKI.
  • RSA encryption keys don't expect personal information like X.509 certificates do.


I am not sure if what I am referring to as "my method" has been proposed before. I wouldn't be surprised if it has because it seems pretty obvious to me. Can you see any glaring holes in this method? Improvements?

Obviously I do not have any tangible experience or education relating to authentication or encryption so I wouldn't be surprised if I am terribly wrong about everything.

A few days later, I found out about SQRL which more-or-less is the same thing but with the idea of your phone as being your out-of-band key store. I still may progress with my idea (if I find time) because there are many factors which decide which solution would get used ;)
Comments powered by Disqus
Contents © 2015 Daniel Devine - Nikola Powered - Flattr Me! Flattr this Source