Smart Contracts for Identities
In the digitally connected world of Internet-of-Things (IoT), secure identities are crucial to achieve trustworthy generation and management of information. When facing tens of billions of devices, though, we can no longer rely on the means for managing devices and identities that are used today, where a substantial amount of manual intervention is required.
In our latest post in a series on secure identities, we will talk about smart contracts and digital identities and show how identity brokering facilitates identity and trust management for IoT devices.
By using the idea of smart contracts implemented with blockchain technology, we can introduce dynamic management of trust.
In our previous blog posts – Secure IoT identities and Secure brokering of digital identities – we discussed identities for IoT and showed how these can be managed at the device level as well as how trust is handled through blockchain technologies. Now we want to explore the third step: how to manage identities and trust relations through smart contracts, with a concrete example of using the Calvin framework for IoT. Before digging deeper into smart contracts, we will revisit the concept of dynamic trust relations between entities:
Figure 1: Illustration of how an identity link can be dynamically added and removed.
Two neighboring families have houses with smart cat flaps, that is, the cat flaps can identify cats based on RFID chips on the cat collars. Based on the identity, the flap either stays closed or opens to let the cat in. The families – Family Blue and Family Orange, see Figure 1 – each owns one cat, Cat Blue and Cat Orange. As Family Blue is going away on a vacation, Family Orange has agreed to let Cat Blue into their kitchen for cat food and water during the duration of the vacation. To achieve this, Family Orange adds an identity link to Cat Blue in the identity management system. Similarly, when Family Blue comes home from their vacation, Cat Blue can be locked out again from Family Oranges house by removing the identity link to Cat Blue.
A smart contract is the interface and logic that controls the access to the application state stored in the blockchain ledger. This state is associated with a smart contract instance. The smart contract is typically used to enforce specific protocols or rules agreed upon between the users of an application. The contracts are stored in, and executed by, the blockchain system, making it possible to have a very high trust in the result compared to a non-distributed execution environment.
A smart contract exposes one or more public methods that are invoked by sending a transaction to the blockchain system, which forms an immutable ledger. The transaction specifies the contract instance, contract method and any input parameters to the method. The transaction is signed by the invoker, which enables authorization of the invoked method.
When the nodes in the blockchain system reach consensus as a result of the request, the application state is updated and the transaction is permanently appended to the blockchain. Exactly how the contract code is executed and how consensus is reached varies between different blockchain ledger architectures. The blockchain ledger lies at the heart of the ID-brokering, and the smart contracts allow us to describe and manage the trust relations for the identities as described in our previous blog post.
Example of a rudimentary domain concept implemented in Solidity. The owner (creator) of the domain can add and remove members with the setMember function. With the query function it is then possible to check if an address is a member or not.
Identity and trust management using smart contracts
The main task of a Public Key Infrastructure (PKI) system is to facilitate identification and delegation of trust to perform further identification of entities. In our PKI, each entity identity is associated with an asymmetric key pair. An identity may not only be associated with a physical entity or a user, but may also be used for a logical aspect of a system, such as a Certificate Authority (CA). The problem with the commonly used certificate based PKIs, is that the different certificate trees are isolated, which makes the interaction of devices/applications associated with different PKI setups very cumbersome.
Let’s look how identities are organized and used. Two essential notions that we will use are domains and trust stores. A domain is the set of identities that have direct identity links to the anchor ID, or derived links of the anchor identity, that is, it is the set of all trusted identities when the graph (see, for example, Figure 2) is traversed starting from the anchor identity. The entity having the anchor identity assumes a role similar to a Certificate Authority in an X.509 certificate chain. A trust store is a list of domains that are trusted for a particular task, for example, for access control to a resource or for secure communication using Transport Layer Security (TLS). We developed a PKI brokering solution which simplifies the handling of identities for the dynamic nature of IoT applications.
In our solution four contracts are used to realize the PKI brokering:
- PKI contract – the top-level contract in the brokering system that keeps track of all deployed domains as well as trust stores. It also provides the interface to create and parametrize domain contracts, domain constraints contracts as well as trust store contracts.
- Domain contract – an instance of this contract represents an identity and its connections to other domains/identities. The owner of the keypair used to create the domain contract instance is the domain owner.
- Domain constraints contract – this contract allows a domain to set constraints on the trust relationship towards other domains, that is, it sets rules that must be fulfilled for a trust relationship to be valid.
- Trust store contract – an instance of this contract lists a number of domain identities that are trusted. Note that an entity may use one or many such trust stores and they can be selectively chosen, for example, by device owner or a runtime administrator.
These contracts relate to some extent to ordinary certificates together with the verification procedures that check and interpret certificates into actions.
Figure 2: Example brokering PKI. Circles are single identities. Arrows indicate that a node has a link to another node, and a double directional arrow indicates that both nodes have links to each other.
Using the contracts, it is easy to describe trust relations. For example, a Domain A can identify and delegate trust to Domain B, see Figure 2, by adding that particular domain to its list of linked domains. Similarly, the identity link can easily be removed by removing Domain B from Domain A’s list of linked domains, without the need to revoke any certificates.
The trust store contract is an object containing domain identities that are explicitly trusted by the entity, for example, a device. In comparison with web browsers, the trust store contract corresponds to the list of trusted Certificate Authorities (CAs) that are explicitly trusted by the browser.
To realize the mentioned example with cat flaps, see Figure 2, each family need to setup a domain contract instance with links to the respective cat identities. They can each create a trust store that can be used as a basis for access control to the cat flap. In their respective trust store, they each list their owner identity. When the orange family adds the blue cat identity in the domain contract, the blue cat will become a trusted identity and be allowed to open the cat flap. Similarly, the access can be revoked by removing the blue cat identity from the orange domain contract instance.
By using the domain constraints contract, it is also possible for a domain, to express how the trust is delegated to another domain via the trust link, for example, in Figure 2, how much trust can identity A put in the identities C, E and F given that B has links to these identities. The usage of the domain constraints contracts can be exemplified by realizing the same constraints as the X.509 extension BasicConstraints do for certificates, that is, restricting the capabilities to certify further domains by setting the number of trusted sublevels. But domain constraints contracts are more flexible and could be used to additionally realize trust delegation similar to PGPs Web of Trust.
Calvin is a framework for developing and deploying IoT solutions,that has been developed by Ericsson and is open source. Read more about Calvin in other Ericsson blog posts. A Calvin system consists of runtimes, applications and application users. These need identities to describe ownership and access control to resources. Calvin is an example of a system that initially used a traditional PKI technology to implement identities for services and devices. The smart contract-based identity management has been implemented and tested in Calvin for secure communication between Calvin runtimes via TLS. We have primarily structured domains as sovereign sets of runtimes with a logical CA entity with identity links to runtimes in a domain. The CA identity is incorporated in a trust store contract instance that is used by all runtimes in the domain. Hence, runtimes will only communicate with other runtimes that have links from the CA identity. The smart contract based ID management system makes it easy to create multi-domain trust delegation and overcome the silo effect of certificate trees.
Altogether, the contracts give a secure way to express certificate-like relations like in an ordinary PKI but with several advantages. The ID-brokering PKI is much more flexible and we can accommodate other credential types. Also, it is easy to make the ID-brokering work more or less like an ordinary PKI or like a web of trust. The flexibility of the ID-brokering is still something we are experimenting with to see what are the best setups and to explore how coexistence with an ordinary PKI can be implemented. Stay tuned for more results from our research om ID-brokering.
Read more about IoT Security at Ericsson.