From IoT identity to user authority
As we move towards the next generation of devices, which communicate increasingly both with each other and with multiple cloud services, this lack of transparency and clarity becomes increasingly a case for concern. If, for example, I buy a health tracker, I may want to associate it with a monitoring service provided by my doctor. This needs to not only ‘work’, but also provide each party with the necessary assurances – that the device belongs to a given user; that the sensor in the device is accurate; and that the user has authorised the association.
Whilst the IoT world seems very new, these problems are not. Fundamentally, they are about access control. Who (which person or device) can do what? Equally importantly: how do a device’s capabilities change over time, as it is installed, uninstalled, sold, rented out or stolen.
These problems were the backdrop to my PhD thesis of 20 years ago. At the time, the focus was on users, clients and servers – not devices – but the principles are the same. My thesis introduced a distributed protocol to allow different systems to work together and for clients of one system to obtain permissions to use services from others. I introduced a formal model for reasoning about access, a flexible implementation scheme and an approach for dynamically granting and revoking access in a cascading manner that scaled. So, for example, changing the owner of a car could revoke all keys issued by the previous owner.
The underlying premise of OASIS, the system introduced in my thesis, is that clients, programs or devices, have an identity which they can prove, on demand, to anyone. This allows a service to confirm, without doubt, which device it is communicating with. For IoT, this identity should be generated on the device and stored securely. It is no accident that I am CTO at Trustonic, a company that understands how to do this better than any other and has provisioned over 1 billion devices at manufacture, with both such an identity and a secure operating system to make use of it.
In OASIS, a “role” is what gives the identity meaning. Roles are bound to identities and assert statements about the associated device. They might represent proof of manufacture: FitnessTracker(model=“swim”), a dynamic state: LoggedIn(userid=“rjh21”) or associations created by combining roles: HeathSensorFor(user=’rjh21’).
OASIS takes care of describing the micro-policy for each service, which roles it can consume and issue and how these are associated. Crucially, this policy indicates how one client can enrol another and how and when a role should be revoked. The underlying implementation means that using a role to authorise access to a service is simple, secure and scalable.
OASIS is quite an old system, but its focus on client identity and dynamic authorisation suits the needs of a rapidly changing population of IoT devices.
It can build on static identity, such as that offered by traditional PKI, to provide a dynamic and flexible means to specify and manage access policy.
The IoT is at a crossroads. The world has woken up to the need for better security and the foundations – trusted boot, isolated secure execution and device identity – are becoming the accepted norm. The next step is to look at the wider picture – how these devices can be flexibly combined without compromising security. I believe OASIS offers a blueprint for achieving this aim.
