Public Key Authentication

Public Key Authentication in Nabto Edge is inspired by SSH’s similar concept. This authentication model uses cryptographic keys to identify and authenticate peers instead of e.g. username and passwords. Using cryptographic keys for authentication has the advantage that they are practically impossible to bruteforce crack (corresponds to a very long, random password securely exchanged) and without the need for the user to remember anything.

The cryptographic keys in Nabto Edge are additionally used to ensure end-to-end confidentiality and integrity of the communication between two peers.

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. In practice, in both device and client instead of a list of public keys, a secure hash (checksum) of the public key is used, denoted the public key’s fingerprint (simpler to manage).

The Nabto Edge client application and the Nabto Edge embedded device application each needs their own unique key pair. Our APIs provide functions to create such key pairs or they can be created using standard tools, such as the OpenSSL cli tools.

Nabto Edge uses elliptic curve cryptography as it provides strong security with resource requirements that are suitable for the IoT domain.

In practice, only the private key from the keypair is stored (locally in the respective device) and the public key is derived at runtime from it. Exchanging public key (fingerprints) for the white lists is denoted pairing and is described in the Pairing guide.

Once two peers are paired (ie, either peer knows the public key of the other peer), a secure Nabto Edge Direct connection between the two can be established with mutual authentication. This is implemented as a standard DTLS handshake with the initiator being the Nabto Edge Client application and the server being the Nabto Edge Embedded device application. Once the DTLS handshake is complete, each peer possesses the other peer’s public key and can then validate that it matches the white list of paired public keys.

The Nabto Edge basestation servers facilitates the exchange of information during the DTLS handshake between the two peers if they are not on the same network. If they can communicate directly, e.g. after a BonJour discovery, they perform the handshake directly instead of through the basestation servers.

The Nabto Edge Embedded SDK per default uses Mbed TLS. From SDK version 5.11, the WolfSSL suite is also supported. Both are proven 3rd party DTLS implementation suitable for embedded devices.

Client vs User

When using the Nabto Edge Client SDK to create keys as suggested, each client application instance is granted access to a device. So if a user has the client app for controlling a device installed on both a phone and a tablet, a unique client private key is created on each. This means that each client device has to be individually paired with the target embedded device.

For typical use of residential IoT devices, this is not a problem - the access control list on the embedded device will then typically include “Joe’s iPhone” and “Joe’s iPad”. That is, the unique public key for both client devices are added.

From the Nabto Edge Client and Embedded SDKs perspectives’ there is no problem in using the same private key across a user’s devices to pair a user instead of the user’s client devices. For instance, the vendor can use an existing roaming infrastructure or other means for synchronizing keys between users’ devices. So in this case, the access control list will just contain a single entry “Joe” with a single public key which matches the private key that is identical across all Joe’s client devices.

Taken to the extreme, the Public Key Authentication can be completely bypassed and the vendor can use the cryptographic keys only for confidentiality and integrity: In this case, the vendor must then implement user authentication at the application level - relevant if for instance tunnelling to an existing HTTP or RTSP application that already provides a username/password based authentication implementation.

Summary of Developer Tasks

Create Private Key in Client

Typically the client private key is created the first time the app is used - see API functions for creating private keys (iOS and Android shortcuts). The key is stored on the client device in any location the application developer prefers. Best practice is to store the key in a protected key store such as those available on both iOS and Android.

Or you can use standard tools, e.g. OpenSSL to generate the keypair:

openssl ecparam -genkey -name prime256v1 -out key.pem

Provide the Client Private Key to Nabto Edge Client SDK

After the key is created or loaded, it must be provided to the Nabto Edge Client SDK - see API functions for setting private keys (iOS and Android shortcuts).

Create and Load Private Key on the Embedded Device

On the device, creation of the private key depends on the vendors’ provisioning process. Typically the private key is installed at the factory - that is, created outside the device and installed in the manufacturing process.

The vendor then uploads each derived public key’s fingerprint to the Nabto Edge server infrastructure - to allow the device to come online later for remote access. Each purchased device license correponds to such registered public key.

Alternatively, the private key on the device is created directly on the device - either on the factory or at the user when starting the device for the first time. When doing this, the Nabto Edge Embedded SDK provides an API function to create the key. It is up to the vendor to store the key in an appropriate location.

Regardless of how the key is created and stored, it is subsequently read by the vendor’s application and provided to the Nabto Edge SDK prior to the device coming online.

Configure and use access control

The IAM guide lists the developer tasks necessary to configure and use access control - ie to perform pairing of clients and device and authorize requests on the device.


Full examples that show all necessary implementation and API interaction are available: The CoAP thermostat demo and the TCP tunnel apps.