Handling of Data in an Edge Solution

In Nabto Edge all client to device connections are end-to-end encrypted without Nabto knowing the keys. That means Nabto has no way to eavesdrop, ie read and understand the data sent between a Nabto Edge client and a Nabto Edge device.

The servers supporting the Nabto Edge solution have access to some data, for instance IP addresses, when using the Nabto servers for signaling, relaying of data, service invocations and FCM invocations.

When a connection between a Nabto Edge Client and Device uses the Nabto Edge servers for relaying of data, the data is still end-to-end encrypted between the Client and the Device. This means Nabto will only have access to the ciphertext with no means to decipher it.

Data Residency in Nabto Edge Solutions

Data residency describes in which region data related to a solution is accessible. Two different regions are currently supported: EU and Global.

Data residency is configured at the organization level in the Nabto Cloud Console. When data residency has been chosen for an organization, it cannot be changed later on. All products created in the organization inherits the data residency settings from the organization.

If EU data residency is chosen, the data related to products in the organization is stored inside the EU and all connections are made to servers inside the EU.

If Global data residency is chosen, the data related to products in the organization is replicated to all Nabto data centers. Connections from clients and devices can be made to any of the Nabto data centers, typically the nearest one for lowest latency.

Data handled by Nabto Servers

Different kinds of data is handled by the Nabto Servers, these are described below.

Transient data

Transient data is short lived data or data which has a lifetime of as long as a device is online in a given session (ie, until it loses network connectivity, is restarted or shut down). The data is neccessary on the Nabto servers for them to function.

When a device registers with the basestation (ie., when it powers on or network connectivity is re-established), the following information is stored by the Nabto servers until the device goes offline:

  1. timestamp when device came online
  2. Nabto device id
  3. public IP address
  4. device’s public key
  5. Nabto version of device
  6. Any application specific data provided by the device (app name, app version)
  7. Any SCTs uploaded by the device

When a client connects to a device through the basestation, the following information is stored by the Nabto Servers until the connection is closed:

  1. timestamp when connection was created
  2. Nabto device id
  3. public IP address
  4. client’s public key
  5. Nabto version of the client
  6. Any application specific data provided by the client (app name, app version)

When an FCM (Firebase Cloud Messaging) message is sent from the device to FCM, the following data is stored by the nabto servers until the message has been delivered to FCM:

  1. The FCM message

When a device makes a service invocation, the following data is stored by the nabto servers until the service invocation has been handled:

  1. The service invocation message and other related information.

Short term data storage

For diagnostics and statistics purposes, information is logged in the events outlined below. The information is retained for up to 180 days.

When a device/client interacts with the basestation (eg. device registration, client relay, device upload SCT, device service invocation, device FCM send message) we log:

  1. timestamp of event
  2. Nabto device id
  3. public (WAN) IP address and port of the device/client
  4. action performed
  5. Nabto version of device/client
  6. Any application specific data provided by the client (app name, app version)
  7. Any SCTs uploaded by the device
  8. Region of the basestation invoked
  9. Connection id if relevant

Long term data storage

For billing purposes, information is logged in the events outlined below. The information is stored permanently:

When a device registers with the basestation (ie., when it powers on or network connectivity is re-established), the following information is stored centrally. This is overwritten for each registration:

  1. timestamp when device was online
  2. Nabto device id
  3. Region and basestation instances registered to

For each ended relay connection, the following information is stored centrally:

  1. Nabto device id
  2. Connection id
  3. Timestamp when relay was established
  4. Timestamp when relay ended
  5. Amount of relay data transferred