Novay did a study for SURFnet on innovations in service provider authenticity and behaviour. This study was done by my colleague Martijn Oostdijk and myself, in collaboration with Roland van Rijswijk-Deij from SURFnet (and Radboud University). We basically explored what innovations there are to better assess trustworthiness of service providers. This can be trust in the server authenticity (is the service provider who he appears to be?) and the behaviour (will the service provider behave as expected?). Trustworthiness of users was out of scope for this study. The goal of the study was to assess the feasibility of deploying these innovative trust mechanisms and their potential impact for SURFnet and its community. We followed a wisdom-of-the-crowd like approach, involving experts from SURFnet, Novay and SIDN in determining what mechanisms are most relevant and most promising.
With respect to server authenticity, most innovations try to improve upon the TLS PKI as we now rely on it, by replacing it or by building on top of it. Much has been written about the weaknesses of our current systems for website certificates (e.g. here and in 2000). As the Diginator hack showed, any of the many Certificate Authorities that exist can be the weakest link and cause trust problem for all service providers. The study discusses different public key pinning mechanisms that make it possible for clients such as web browsers to better check the validity of a certificate. With respect to trust in the behavious of service providers, the trust mechanisms tend to be less technical. The innovations that we explore in the study include reputation-based trust mechanisms and quality marks.
The below figure plots the trust mechanisms we covered in two dimensions:
- the trust authority: a central trusted third party (authority) versus more peer-to-peer/crowd-sourced,
- the problem domain: server authenticity (e.g., against phishing or man-in-the-middle attacks) or behaviour.
I won’t try to summarize the complete study, but briefly describe three of my ‘favourite’ trust mechanisms:
- ToS-DR.info – the abbreviation stand for Terms of Service; Didn’t Read. This is a crowd sourced indicator of the quality of terms-of-service as published by a service provider. Of course, reading all terms of service statements of all service providers one would like to use is simply not possible, and they also tend to change regularly. ToS-DR classifies terms of service of well-known website from very good (A) to very bad (E), and also lists specific good and bad point (e.g., what happens to the copyright of photos you upload). ToS-DR is backed by a small community of critical reviewers that go through the actual terms-of-service documents. The project is young and many websites are not rated yet, and for some websites the resulting rating is inconclusive, but it is an interesting approach.
- Context-based trust (for server authenticity) – The idea is to present dynamic context information to the user that only the legitimate web server should know. For example, show what time you got up this morning (based on an trusted app on your mobile phone), or your last non-public status update on Facebook. This mechanisms can help users to detect phishing sites, but is vulnerable to man-in-the-middle attacks. In the interest of full disclosure, I’m biased here since this mechanisms is covered in a patent application by Lucent of which I’m one of the inventors… Please note that we do the reverse of the more common context-aware user authentication/authorization, since we aim at server authenticity contrary to user authentication/authorization (see here for an example of a project on context-enhanced authorization).
- Pinning in the network – This is a new mechanism that we came up with while doing the study, or at least, we did not find previous work on it. Public key pinning related mechanisms such as Convergence/Perspectives, Tack and DANE attempt to provide extra information about the server certificate to the end-user, while remaining compatible with the existing trust standard (TLS based on the traditional PKI model). What these mechanisms have in common is that they require changes to software on the client, which is a hindrance for large-scale deployment. For example, it requires standardisation and acceptance of this standard for all browser and/or OS vendors (including mobile). The idea about pinning in the network is not do the pinning in the client, but in the network. A way to do this is to inspect TLS connections as they are being set up. This requires control over the network, but that may prove easier for certain organizations, including SURFnet, than controlling clients connected to the network. There are challenges involved, and the feasibility needs to be assessed. I’ll discuss these in a separate blog post.
The study is publically available. Warning: this report assumes some background in internet security and existing trust mechanisms such as PKI.