Capability Tokens for Wireless Sensor Network Security

exploded_lockUnlike most user-to-computer access scenarios today, the internet of things will see very large numbers of smart devices needing to talk securely to very large numbers of smart devices. Typical Access Control List (ACL) based authorisation schemes don’t scale well in this situation, particularly where those devices are resource constrained, such as in many wireless sensor (/actuator) networks.

ACL (Access Control Lists) and even role based authorisation relies on being able to identify an accessing entity, or at least its role, then lookup its access rights in a database. This means that either the authorising device itself must contain an ACL database or else must hand-off the authorisation decision to a specialist server. The database must kept up to date with details to enable the identity or the role of each accessing entity to be authenticated and consequently their access rights determined.

With current technology it is impractical for each IoT device to implement its own access control database, let alone keep perhaps thousands of those synchronised. Whilst hand-off schemes to specialist authorisation servers are communications intensive, a significant disadvantage when there are potentially hundreds or even thousands of nodes involved in a single transaction. With resource constrained wireless sensor networks (WSN) in particular, this kind of communications overhead is likely to be prohibitive.

Capability-based access control can largely eliminate the above drawbacks. As described by Dennis and Van Horn in the mid 1960s, ”A capability is a token, ticket, or key that gives the possessor permission to access an entity or object in a computer system” (Dennis and van Horn, Plessey system, CTSS, 1966).

A capability is implemented as a data structure that contains:

  1. An identity of the resource that is attempting to be accessed.
  2. An indication of the access right to that resource, typically read, update, execute.

Consequently a device being accessed only needs to check that the named resource is available and that an attempted operation is permitted by the token.

The significant advantage of capability-based access control for the IoT is that the identity or role of accessors don’t need to be authenticated, nor do records of access rights of identities or roles need to be immediately available. The only requirement is to prove the validity of the token.

Access control for a prototype WSN

Our prototype wireless sensor, mesh network, enables each node and potentially each sensor or actuator controlled by a node to have its own IPV6 address that can be accessed from the Internet. It is currently being used to control lights, water heating and irrigation valves, consequently we wanted to be very sure that only authorised access was enabled, which was an opportunity to develop and trial capability-based access control. Although much of the popular press talks about wireless sensor networks, the reality is that many IoT systems will actuate stuff, which is likely to be far more sensitive to unauthorised access than sensor readings.

Our simple token based access control prototype has been written largely in Python and operates as follows:


Authorisation tokens are generated by manual requests to a token server using the following web form:
Details to be supplied are:

  1. The issuers e-mail address
  2. A token expiry date
  3. An identifier that indicates which private key is to be used to sign the token.
  4. The address of the WSN node being accessed (which can be either an IPV4 or IPV6 numeric or non-numeric address).
  5. An identifier for a resource at that address.
  6. An operation permitted on the resource (currently GET , POST or PUT)

More than one resource and/or operation can be added to the token.

An example of a completed form is shown below.


In this case a non-numeric address is being provided (which resolves to an IPV6 address).

The identifiers of two different resources at this address are indicated, each with a permitted operation. One of these is a sensor (a max 31855 temperature sensor), whilst the other is an ‘actuator’, or in this case a temperature ‘setpoint’ for a hot water controller.

When this form is submitted a token (in JSON format) is generated as follows:


cur – is the current date/time

dev – the address of the device being accessed

dig – a SHA 256 signature digest of the entire token less the digest itself

exp – the token expiry date

iss – an issuer e-mail address

kid – an identifier of the private key that was used to sign the token

res – a list of resources

for each resource:

opr – a permitted operation

rsc – a resource identifier

tid – a unique token identifier

A future enhancement will be a wild card naming scheme, which could use regular expressions, for example to enable a single token to be used to access multiple devices and classes of resource. This is important for conducting operations on groups or sets of large numbers of sensors.

The token is included as a header in each REST request that is made to a WSN node.

In our case the token itself isn’t encrypted, rather each request is made via an HTTP/S link, which prevents token eavesdropping and also ‘man in the middle’ type of attacks.

Border Router

In our current implementation, token validation is carried out by a WSN border router rather than by each WSN node. A border router at the very least acts as a wireless gateway between a wired network and a wireless network. In our case it provides several other services.

  1. HTTP/S termination and load balancing (as needed)
  2. Validation of tokens
  3. Acts as a CoAP-HTTP proxy
  4. AnchorSecures packets travelling from the border router to the WSN node via DTLS