Security in Nabto Edge

Security in an IoT solution is of paramount importance: Device owners must be able to trust that only users they authorize can access devices - to e.g. view a surveillance camera feed in their home or control a smart alarm.

Communication with devices must happen in confidentiality and without anybody being able to manipulate the exchanged data.

Users must be able to trust that they connect to the actual device they intend; for instance, if invoking a smart lock to lock your door, you must be able to trust it is indeed your door and not just an impersonating device you lock.

The Nabto Edge platform makes it possible for device vendors to implement such measures in a simple and robust way:

  • High level API support and useful default configurations to make it easy to follow best practices
  • Public key authentication similar to SSH
  • Under the hood: DTLS with elliptic curve cryptography (ECC) enables strong authentication of clients towards embedded devices and vice versa as well as confidentiality and integrity of communication.

Access control is supported at different levels and with alternative options to fit the individual solution:

  • Coarse grained centralized access control: Only clients with a valid token are allowed by the Nabto basestation servers to connect to devices
  • Fine grained access control on the embedded device
  • Support for JWT token based access control using external JWT providers
  • Built-in turnkey token based centralized access control for a simpler solution without dependency on external services (as alternative to JWT): Nabto Server Connect Tokens (SCT)
  • Optional delegation of access decisions to vendor’s own access control system on embedded device

Centralized coarse grained access control prevents denial of service attacks on devices:

The default access control configuration for the standard apps, examples and demos is simple to use and extend - and robust and secure, so no need to worry e.g. about JWT if no inherent need in the existing system architecture.


Public Key Cryptography

Nabto Edge uses public key cryptography for authentication and end-to-end encryption of communication between client and embedded device. This means the Nabto basestation servers do not have to be trusted; each peer has their own unique private key and derived public key. The Nabto basestation servers only need to know the public key fingerprint of the device public key to allow a device to register with the services.

Public Key Authentication

Nabto Edge does not rely on signed certificates for authenticating peers. Instead, Public Key Authentication is used: The device has a white list of public keys that are allowed to access the device - only clients with a matching private key are allowed access to the device. And vice versa: The client has a list of known devices and their public keys. See the Public Key Authentication guide.


Establishing the lists of authorized keys is denoted pairing. Exactly how pairing is implemented is up to the specific solution - Nabto provides various mechanisms to support pairing. But anything that makes sense in the given application scenario to (securely) put a public key in the access control list will work. See the Pairing guide.

Access Control

Access control is enforced at several levels:

At connect time - centrally: Through one of the supported token based mechanisms (JWT or SCT), only authorized clients are allowed to proceed towards the device with a connect request. This prevents denial of service attacks on devices from attackers who may know the device identity. See the Token Based Access Control guide.

At connect time - on device: Once a client is authorized to attempt to connect to the device (ie, one that the basestation has authorized or a local client), the device verifies that the client is authorized to establish a connection. The device verifies that the client’s public key matches the local access control list. Or the specific application validates the client’s JWT claim.

At operation time - on device: The connected client may now use the established connection - for instance, a CoAP request can be invoked or a tunnel can be requested to be established. In either case, the Nabto Edge embedded application receives an authorization callback - if the client is authorized to request the given CoAP resource or open a tunnel towards the requested target, the application signals to the Nabto Edge framework that the operation may proceed.

Server Authentication

The Nabto Embedded SDK authenticates the Nabto Basestation servers using a certificate signed by a trusted public root certificate authority. Revocation status is checked using OCSP stapling. The only task for the application developer is to install a root certificate.

Getting Started

All SDK example applications demonstrate public key based authentication and pairing - for instance see the tunnel quickstart guide.

To study just security aspects of Nabto Edge, the tunnel example is good as you don’t need any code adaptation - you can just insert the Nabto Edge tunnel between an existing TCP client and TCP server by using the standalone tunnel binaries. The tunnel application also demonstrates SCT coarse grained access control.

Separate guides describe Pairing and Token Based Access Control in more detail.