Security protocols often support not just a community of users but a business community, and evolve with it. It should be obvious that if a protocol is designed by Alice, we might expect it to suit her strategic purposes. But this can make Bob unhappy, and the protocol eventually needs to be redesigned. A mature discussion of security needs to take account of how protocols evolve. However, we rapidly get out of the space of two-player games.
Previous workshops on security protocols have discussed several examples of protocols acquiring new features until eventually they broke, as a result of feature interaction or implementation complexity. The system designed by IBM and others to encrypt PINs in a bank’s ATMs was extended by Visa and others to support worldwide networks of banks, ATMs and point-of-sale devices. That led to API attacks which arose from unanticipated feature interactions. It was extended further to deal with EMV smartcards, leading to further vulnerabilities and attacks. The same holds for SSL/TLS protocol suite, which is now more than 20 years old; it has accumulated options (such as export ciphersuites) and features (such as heartbeat) which have led to significant vulnerabilities. Because of the enormous number and diversity of users, fixes usually have to be applied at one end only; simultaneous upgrades to both clients and servers are hard.
This much is reasonably well known. At previous protocols workshops we have touched on economic models of protocols , asked whether in a democratic system there should be a ‘loyal attacker’, inspired by the ‘loyal opposition’ in parliament and discussed crowdsourcing social trust. In this paper we apply concepts from institutional economics to provide a framework for discussing the ways in which protocols evolve at different scales of organisation and time, and the effects on innovation.
The rest of the paper is organised as follows. Section 2 describes John Groenewegen’s model of innovation in the electricity industry, and our proposed simplification of it for protocol analysis. Section 3 looks at protocol creep, bugfixes and tussles. Section 4 considers protocol complements and the scaling of innovation. Section 5 attempts to draw some conclusions – for the ‘Internet of Things’, for dispute resolution, and for the kinds of online conflict we have seen around recent elections on social media. Finally, we present our conclusions in section 6.
Read the complete article at https://www.cl.cam.ac.uk/~rja14/Papers/reconciling-multiple-objectives.pdf
Read more at Woods LLP