Documentation

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 through Nabto Edge IAM.
  • 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.

Concepts

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.

Pairing

Establishing the lists of authorized keys is denoted pairing: When starting from scratch, both lists are blank - somehow authorized keys must be added. Adding the first client public key to a device is conceptually the most complicated, subsequent clients can then be securely added using a secure connection established using the first public key if desired.

Nabto supports various pairing mechanisms as part of the Nabto Edge IAM implementation. Alternatively, all necessary basic primitives are exposed to make it possible to build a custom pairing and authorization solution if this is needed.

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, a client that the basestation has authorized or a local client if the device allows), the device can verify itself that the client is authorized to establish a connection: The IAM module checks if the client is mapped to a configured IAM role.

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. The IAM module is queried by the application code to check if access is allowed.

Server Authentication

The connection between the Nabto Edge embedded device and the Nabto basestation is secured using short lived certificates. A root certificate is automatically configured by the SDK for the Global Nabto Cloud, so nothing to configure or change for most applications.

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.