Ability™ Developer Portal
Try Sandbox for free
Get a month of free access to ABB Ability™ Platform to learn and experiment!
API Playground
Play with ABB Ability™ Platform APIs (no time limits)

# Device ID Management

# ​Device ID Requirements

Device IDs are used to identify the devices and associated data in the ABB Ability™ platform. For managing device identities, the following requirements apply:

  • Device ID must be unique within the tenant.
  • Device ID must be a GUID.
  • IoT Hub Device ID must match the Ability Object Model objectId field
  • Device ID must be bound to the device, which means if the device is replaced, the older ID is not re-used.
  • Device ID must be securely retired when
    • A device is de-commissioned (EOL)
    • A device is replaced (Ex. due to RMA)
  • Device ID is used to identify and address the device in
    • DPS and IoT hub (Only the EDGE/Direct Connected Devices)
    • Information Model Service (All Devices)

This page refers to the management of the IDs allocated to EDGE/Direct connected devices as they also participate in the authentication to IoT Hub via an X.509 certificate containing the device ID as the common name. Henceforth, the EDGE device also refers to any Direct Connected Devices to the Ability cloud.

# Life Cycle Management

# ID Generation

The ID can be generated either in the device itself or generated in the Global ID Generator Service (GIG Service) and configured in the device. Additionally, the ID must be mapped to a device identity (e.g., EK of a TPM if available or a device serial number) to ensure that the ID is bound to the device.

# Generation Mechanism

The use of UUID generators reasonably assures that the UUIDs generated are unique. There is a very small chance of collision that is mitigated by the fact that the ID generated can be checked against collision before the ID is bound to the device. Both in the GIG service as well as the local generation, UUID Version 4 (Random UUIDs) should be generated.

For devices, there are multiple UUID generators available, e.g., Linux provides libuuid for the UUID generation. There is also a Node.JS providing an NPM package for UUID generation.

# Device ID Length

The length of the ID should be constant irrespective of the source. The current proposal is to fix the length of the ID to 128 bits and represent it in UUID format.

Note that the maximum length of the ID can be 512 bits (64 bytes) as this is the limit imposed for a common name in an X.509 certificate.

# ID Lifecycle

ID Management consists of:

  • ID Generation/Factory Process
    • It is recommended that the identity of the device is assigned in the factory in which the device is manufactured. In cases where the device is procured as a COTS equipment, the ID shall be assigned as a pre-commissioning step.
  • ID Uniqueness Check
    • As a part of the factory process or pre-commissioning process, the ID must be checked for uniqueness with the GIG Service. If the ID is found to be a duplicate, then go back to generating a new ID.
    • The duplicate check can be an automated or a manual process. If the device has connectivity, an automated check should be done by the software.
    • If the ID is found to be a duplicate, then start with a new ID generation.
  • Binding the ID of the device with the device certificate
    • Using the ID as the Common Name, a certificate is issued for the device.
  • Registering the ID in GIG service along with Device meta data and marking the ID as "assigned" in GIG Service
  • Publishing the device ID in Information model
    • The ID is used as the Object ID for the device and its associated models in the information model.
  • ID Retirement
    • Certificate is deleted and the ID is marked as "Obsolete" in the GIG Service.

# Edge Device Features

  1. Derive the device ID based on:
    • A pre-configured ID in a well known location (e.g., /var/ability/device/ID)
    • If a pre-configured ID is not available, generate a UUID (v4)
  2. Check with the GIG service to verify that the ID is unique and register the ID with the GIG service (along with meta data e.g., EK from TPM, device serial number).
  3. Initiate CSR with CN as the ID.
  4. Securely store the ID in the device secure storage (protected from a factory reset of the device).
  5. During end-of-life or RMA, contact the GIG Service to mark the ID as "Obsolete".

# Global ID Service Features

The Global ID Service is a global service that can generate ID numbers for devices which are maintained in a database of "Active" IDs as well as "Obsolete" IDs. The Global Id Service also provides a couple API endpoints for:

  1. Requesting a new ID
  2. Checking if an ID is Duplicate
  3. Marking an ID as Obsolete along with (optional) Meta Data that helps identifying the mapping of an ID to a device
  4. Updating an ID as Active along with (optional) Meta Data that helps identifying the mapping of an ID to a device

As with any of the other Ability Platform endpoints the endpoints associated with the Global ID Service can be protected by the Roles Based Access Controls of the Ability Platform. It is the responsibility of the BL user to set these RBAC controls, as the Platform does not assign a default configuration. The Global ID Service has the following security features:

  1. All API requests are access controlled. Interface for requesting a new ID is be controlled with special "Roles" from the Principal Manager Service
  2. Performs roles based access control functionality based on special roles in the Principal Manager Service (Ex. Which role can request for ID, which role can mark an ID as assigned/Obsolete)
  3. Updating an ID as "Active" or "Obsolete" is allowed only to users having a special "Role" in the Principal Manager Service or authenticated devices (Authentication via the X.509 certificate containing the device ID as the Common Name)
  4. Checks and imposes limits on messages coming from one IP address for loading(ex. More than 1000 requests for new IDs coming from the same IP address).
  5. For the endpoint that checks uniqueness of the ID, whitelisting a range of IP addresses from which these requests can be received (Ex. ABB IP Address ranges, Factory IP Addresses) must be implemented to prevent Denial of Service attacks on this endpoint.

# Device De-registration

A device (Edge or directly connected) is required to be de-commissioned for:

  1. End of life
  2. End of contract (The device could be re-used for another contract)
  3. RMA (Return Merchandise authorization - Defective device)

In any of the above cases, secure decommissioning is required to ensure that:

  • Information in the device does not get into the wrong hands
  • The device cannot be re-used by attackers to connect to the ABB Ability™ Platform
  • Secrets such as identity and keys, information such as logs and configuration are securely erased

# De-registration Process

In cases where the device has been de-commissioned due to EOL or RMA, usually the device will be torn apart and recycled. Alternately, a device can be refurbished for a resale. In either of these cases, the contents of the device should be securely erased. The following process should be used for de-registration of the device:

  1. Close all connections to the Ability platform and stop sending telemetry.
  2. Mark the device ID as obsolete in the GIG Service.
  3. Securely erase (see the following section on Secure Erase).
    • log files, audit information
    • configuration files
    • ID of the device and digital certificates
    • private key in the TPM (Clear and reset the TPM.)
    • mounted storage - additional disks, volumes, NAS, etc. (Secure erase and format.)
    • operating system and full disc reformat
  4. Revoke the certificate issued to the device to prevent spoofing of the device. In rare cases, a private key can be stolen.

Note that in many cases, formatting a disk would still allow for data to be retrieved. Further, the method of secure erase varies between different storage mechanisms (Hard Disk Vs Flash Vs SSD). A suitable secure erase mechanism should be employed based on the storage media used.

# Secure Erase

Secure erase ensures that a stolen disc cannot be used to retrieve files/data. Secure Erase usually employs overwriting the disc sectors with random data or with a sequence of 0's and 1's multiple times to ensure that previous data cannot be recovered.

It is recommended that secure erase be employed instead of just deleting the files from the operating system. Various tools are available to securely erase or format a disc.

# Other Notes

  1. Using multiple sources increases the chance of collision and duplicate IDs.
    • Checking for ID duplication is mandatory every time a new ID is generated.
    • In case of a duplication, the ID is discarded and a new ID is generated.
  2. Management of the IDs for devices beyond the EDGE
    • For devices that are not directly connected to the IoT Hub, IDs can either be generated by modules or retrieved from the GIG Service
    • The IDs generated for these devices must be checked for duplicate IDs and replaced when duplicates are identified
  3. A device can attempt to retrieve its ID in cases of accidental erasure/loss of Certificate if
    • It has saved the ID in its local hardware based secure storage
    • The device has stored meta-data along with the ID in the GIG Service
  4. While most of the ID Management can be automated, error situations require manual interventions, so appropriate roles defined in the Principal Manager Service should allow for manual management of error situations
Last updated: 7/7/2021, 8:54:52 AM

← Device Registration With DPS →

Feedback