nRF Cloud Identity Service¶
The nRF Cloud Identity Service lets you authenticate the device in your application service. You can use the secure identity in your own application service, to which the devices connect. If you select to connect devices to nRF Cloud Device management services, you do not necessarily need to use the Identity Service as authentication to nRF Cloud is handled automatically.
Process¶
Every Nordic Semiconductor nRF91x1 device has a cryptographically provable unique identity based on an ECC key pair. During the SiP manufacturing process, a UUID is injected to the device and the device generates a protected identity key pair. The public key is stored in a trusted device database in the nRF Cloud Identity Service. Nordic Semiconductor ensures that no unverified identities can be added to the device database.
The following diagram shows how trust is established and used:
The private key is generated using the device's trusted firmware and securely stored in 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 for the authentication.
Each device has an identity that can be proven at any time using the ECDSA (Section 6) signature scheme. The identity attestation token and JWT are generated at runtime in the device's trusted firmware and do not reveal the public key.
You can verify the tokens using the Identity Service in the nRF Cloud portal or the APIs.
The Identity Service supports nRF91x1 devices. For information about compatibility with nRF9160 devices, contact Support.
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. The tokens can also include your own sensitive information if needed. 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.