Skip to content

nRF Cloud Identity Service

The nRF Cloud Identity Service lets you verify Nordic Semiconductor SiPs by UUID and authenticate the device in your application service.

The follow diagram shows the identity and secure provisioning process:

Identity and provisioning overview

Every Nordic Semiconductor nRF91 series device has a cryptographically provable unique identity based on an ECC key pair. During Nordic Semiconductor's SiP manufacturing process, the device exports its public identity key. This key is stored in a trusted device database in the nRF Cloud Identity Service.

The private key is generated using the device's trusted firmware and securely stored on the device. The private key never leaves the device. It cannot be read or wiped from the device, even through firmware updates. Nordic Semiconductor stores the public key in nRF Cloud and uses it to authenticate attestation tokens verifying the device UUID.

Token verification through the Identity Service is available through the nRF Cloud portal and APIs. Tokens are generated separately for each device.

The Identity Service supports nRF9161 devices. Contact Support to ask about compatibility with nRF9160 devices.

Process

The following diagram shows the sequence of steps in the token verification process:

Identity process overview

Each device has an identity that can be proven at any time using the ECDSA (Section 6) signature scheme. Nordic Semiconductor ensures that no unverified identities can be added to the device database.

After SiP production, the device signs responses to any attestation requests and provisioning commands. These ECDSA signatures do not contain the public key.

Identity Service

The Identity Service verifies signatures with the public key stored in the Nordic Semiconductor trusted database. A device is identified as authentic if the following criteria are met:

  • The signature is verified.
  • The public key that verifies the signature is one that the Identity Service knows and trusts.

The device identity key is never used to connect the device to a cloud service. It is used to sign identity and provisioning messages, referred to as attestation tokens.

The signature proves the identity and the authenticity of the device. The identity key is an intrinsic property of the device, which does not change with firmware updates.

Access

Token verification through the Identity Service is available to Editor, Admin, and Owner roles in a team with any plan.

Attestation

Attestation happens when a device signs a variable message with the ECDSA-signed device identity private key. The message always includes the device's internal UUID and is always concatenated with a random 128-bit nonce. In some cases, the message contains sensitive information, such as the device endorsement key or customer-specific device keys. The attestation function digests the message using SHA-256 before actually signing it.

Attestation tokens

The output of the attestation function is an identity attestation token (COSE_Sign1 object) or JWT. The identity attestation token does not contain a creation time or expiry, so the token can be stored and checked later. For operational device authentication, use a JWT, which contains creation and expiry times.

The Identity Service can verify the authenticity of a device based on the following token types:

  • Identity attestation, where the message contains the device type and the firmware UUID.
  • Public key attestation, where the message contains the SHA-256 digest of a public key. The full token contains the public key and the COSE signature, separated by a dot . character. With the full token, the Identity Service can verify the public key hash in the message as well, but it can verify the signature without the public key.
  • Device certificate signing request attestation, where the message contains the SHA digest of a certificate signing request (CSR). The full token contains the CSR and the COSE signature, separated by a dot . character. With the full token, the Identity Service can verify the CSR hash in the message as well, but it can verify the signature without the CSR.
  • Device claim token, where the message contains the device type, the firmware UUID and the SHA-256 digest of the ownership key.

JSON Web Token (JWT)

The device can generate a JWT signed with the identity key to connect to cloud services, which the Identity Service can then verify. See Verifying device authenticity for more information. For background information on JWTs, see JWT authentication.

See next

See the guide to Verifying device authenticity for instructions for the nRF Cloud portal and APIs.