[Lecture] IdentityHub: PKI for the Masses

// under lecture surfnet scirt

Today, we present our vision on the SURF Security and Privacy Conference "Crisis? Business as Usual!" We describe the contents of our lecture in this article.

Download the presentation

1. Welcome. Let me explain why it is a good idea to have a globally spanning PKI, and how we believe our project holds just the right cards for it.

2. An example? FileSender is an application that allows the exchange of very large files, simply with an HTTP upload, an email to the recipients, who then download over HTTP. When this kind of service is hosted by a reliable party, your pricacy need not suffer. Through release as open source, anyone can control that aspect.

   Starting with FileSender 2.0, encryption is added. The customary path is followed: a password is exchanged out-of-band, and the operator need not even be trusted.

   But passwords are difficult to manage. If I share it with five people, can I also use it for another project where there are three people? Even when the overlap is complete, how about when a new person is added?

   In a sense, a PKI could simplify and offload the minds of users. Or is a PKI too complex? We believe not. It's just that no single party is interested, or has a realistic plan, for making it available globally.

3. This is how easy a PKI can be. Using plain GnuPG, you can enter this simple command to ask it to lookup a recipient's domain in the DNS, prefixed with an LDAP server reference (protected by DNSSEC), then contact it and STARTTLS (which could perhaps be enhanced with DANE) and ask for the PGP key for the recipient. Download it, encrypt geheim.txt, done. All of this was automatic, thanks to the use of suitable protocols.

   To make this secure, there is one requirement. The owner of the orvelte.nep domain must control the LDAP server, or pay a hosting party to control it so that no external parties can register PGP keys under this domain.

4. Domain hosting in general is the cornerstone of online identity and its security. You do not want to respond to a poll issued by mygov.stats-r-us.com because it may well be a phishing attempt by a party you don't know. It is reliable to respond to stats-r-us.mygov.com if you know you can trust mygov.com to delegate only to parties that are constrained where your privacy is concerned.

   User names are similar to subdomains; adding a bakker@orvelte.nep address requires administrative control over orvelte.nep and can be trusted; and again, this is not the case for a third-party account named bakker-at-orvelte, as anyone can acquire that look-alike naam.

   Domains are not just potent identity providers, they also enable us to run our personal flavour of services. That was the idea of hosting providers, but they grinded down to a halt. What went wrong?

5. When the web was attracting attention, we all wanted a domain name with a website and email. How cool we were to have our own corner on the Internet. And how right we were, this was the model of inidivual expressiveness as it was intended.

   The hosting industry came to standardise on the LAMP stack, and never moved since. As a result, all further services were developed on top of HTTP, which in itself is a protocol with rather poor semantics as is shown by today's market that offers wonderful services but only when we run their software on the client side — most everything over HTTP is a proprietary protocol!

6. Technically inclined people have always withstood this trend, and ran their own servers. Often XMPP and IRC, but also more advanced things like SIP or Git. This model however, requires a lot of knowledge and does not scale up to the general public.

7. So, as a member of the general public, what you are left with is to run off to the GYM — by which I mean large silo's such as Google, Yahoo and Microsoft. They have different ideas about your privacy than you do, and their income is generated thanks to their massive scale. This income greatly outweighs what they could earn by selling hosting — but that does not make the model very stable. Users know this, and you can see a degree of cognitive dissonance with people who claim that they "have nothing to hide" or "have given up their privacy" [and are taking others down with them]. These people simply don't have a choice when it comes to running services that please them.

8. We believe that it takes a paradigm shift for the hosting world to get out of their price-competition. And the way we see this is by dividing the hosting role into two kinds of role: one for identity hosting, another for service providers. You would select an identity host on reliability aspects, like redundance and backups, but also protection of your credentials. A service provider would act as a plugin from anywhere, and would be selected on how well the provided service matches your interest.

   This market, as we see it, benefits from diversity. If you are really good at something, you may attract customers. There will always be price-cutters, but quality has a clear role in this market. And there is no restriction by the package offered by an individual provider, so it is easy for end users to add services.

   The InternetWide project develops a hosting stack to accomplish just that; with IdentityHub, our current project phase, we allow the central management of identities and key material through a hosting provider or perhaps partially under local control; with ServiceHub, the next phase, we design an umbillical cord between a service hoster and identity hoster.

9. So, how do you design an IdentityHub? It would have to be based on open protocols, and certainly more than just HTTP and Email. Open source software should be selected for the initial incarnation, and the pieces should be joined together (which turns out to be quite a lot of work). And our focus would be to centralise control in a cockpit run at the identity provider.

10. Not surprisingly in retrospect, we landed with the protocols that are in widespread use for internal centralisation of the management of large enterprises: LDAP for storage of automation-friendly data, and Kerberos for centralised authentication services. Pull an account out of Kerberos, and the user cannot obtain new rights anymore (after his current ticket expires, which usually takes about one day).

11. So we use LDAP to store public keys (for PGP) and certificates (for X.509). But we also use it to store other data, such as public contact information, references to resources ranging from a single website reference to a complete library of documents and/or media formats.

    The choice for PKCS #11 is less common in this setting, and it is a big innovation in our project. PKCS #11 is an API that conceals private/secret keys. We want to make this into a hosted (and therefore remote) service, and not just for individual secrets, but also for those of the groups of which the client is a member.

    Imagine how powerful this is. A member can use the private keys to decrypt documents, sign email, generally act on behalf of the group. At the moment he leaves the group these rights are withdrawn and, since the private keys remained concealed, gone are the privileges of acting on behalf of the group.

    We really believe that end users can enjoy a PKI, once they get to using it.

12. We use Kerberos as our security foundation, and that is not shocking. It is a single-signon protocol and therefore very user-friendly. And, unlike similar attempts based on HTTP, it is not confined but is in fact already embedded in most other protocols, usually through GSSAPI.

    More innovative is our approach to mobile computing, where we believe short-lived secrets are the only credentials that are secure to carry around. Loose the phone, or control over it, and the risk is manageable. This is another reason for using PKCS #11 as a remote protocol; it shares credentials without storing their sensitive parts on lossy or leaky devices. There is no common standard for Remote PKCS #11 but since we are not corners but instead build on solidly standardised protocols such as ASN.1 and GSSAPI, we believe we hold the cards to get this standardised.

    Other things we are innovating relate to Kerberos. The TLS-KDH project has defined a TLS mechanism based on Kerberos and ECDH; where Kerberos is good for authentication but really needs encryption (preferrably with perfect forward secrecy), ECDH offers just that, but it needs authentication. Joining the two is like a fairytale marriage; it also is bloody fast and can support client-to-client connections. More importantly, it is a nice and general response to the urgent need for a more secure Kerberos method for HTTP. We expect Microsoft, with their AD product based on Kerberos, will be most delighted.

    Another vital extension to Kerberos that we are working on is realm crossover or, as we abbreviate it these days, KXOVER (if you are Dutch, you might say klaar-over). This project uses DANE and DNSSEC technology to exploit the certificates that Kerberos realm controllers can already use, but now to connect between hitherto unrelated realms. This is completely new, but it is possible to perform a secure handshake to exchange a key that will allow clients of one realm to use the services in another. Yes, this is Kerberos at the scale of the entire Internet! And combined with TLS-KDH, the possibilities are almost endless.

    (We are aware that some work is needed on the privacy of the Kerberos tickets as well, and have developer ideas on that too.)

13. It's just a simple though, but incredibly powerful; do not define identities for individual protocols, but keep it general so that all protocols can benefit. Then get carried away with a highly advanced identity system and any service that plugs in can benefit by interpreting the various flavours being offered.

    As an example, consider groups. Central control over groups and ACLs would apply to all protocols, so services need not worry about this; all they need to do is assign a meaning to the ideas of groups, and hope that it captures the imagination of users. For email, a group could be made to function as instant list mail; For WebDAV, a group may be an account under which data is shared; For SIP telephony, a group address can connect members into a conference that needs no explicit configuration but simply sits there as an always-ready-to-go conference room.

14. More about our project can be found in our Tetralogy of a free Internet, missions statement and audiences. If you think you should be part of this growing family, please contact us! We are interested in collaborations where we can assign programmers to the many tasks facing us, while at the same time serving your project with those parts that help you forward. We work strictly in open source, and are generally dependent on external funding to be able to hire skilled developers. Through InternetWide, we acquire such funds that we subsequently use to finance parts of the solution space in individual ARPA2 work projects.

Go Top