Bootstrap Sequence

General case

Before being able to bootstrap a device, it is necessary to provision a Bootstrap Entry for the device and link it to a Bootstrap Config.
The Bootstrap sequence starts with the device sending a Bootstrap-Request (preceded by a DTLS Handshake). If the instance IDs to use for the Security Objects are not defined in the Bootstrap Config, a Bootstrap-Discover is sent by LiveObjects to be able to know which Security Object instance holds the Bootstrap server information and avoid it. The Security, Server and OSCORE Objects are deleted. The Security and Server Objects are then written using the parameters defined in the Bootstrap Config and the credentials defined in the Bootstrap Entry.
The Bootstrap sequence ends with LiveObjects sending a Bootstrap-Finish. The device can then register to the LwM2M Run servers.


DeviceLiveObjectsDeviceLiveObjectsCUSTOMERDeviceLiveObjectsCUSTOMERDeviceLiveObjectsProvisioningCreates a new Bootstrap ConfigPOST/api/v1/bootstrap/lwm2m/configs<Bootstrap Config created>Creates a new Bootstrap Entry andassociates it to the Bootstrap Config The Entry can be created before the Configand the association can be done afterwardsPOST/api/v1/bootstrap/lwm2m/entries<Bootstrap Entry created>Bootstrap sequenceDTLS Handshake (PSK)Bootstrap-RequestPOST /bs?ep={Endpoint Client Name}&pct={Preferred Content Format}alt[Accepted]2.04 Changed[problem with credentials]4.00 Bad Request[no Config or Invalid Config]4.00 Bad Requestalt[The instance IDs to use for the Security Objects are not defined in the Bootstrap Config]Bootstrap-Discoveron all Objects The discover makes it possible to knowthe Security Object instance that holdsthe Bootstrap server information in orderto avoid itGET /</>;lwm2m=1.1,</0>,</0/1>;uri="{bootstrapURI}",</1>,</3>,</3/0>2.05 ContentBootstrap-Deleteon Objects Security, Server and OSCOREDELETE /0, /1 and /212.02 DeletedBootstrap-Write Instances of the Objects Security (id=0) et Server (id=1) are written If a Bootstrap-Discover was performed, the instance of the Security Objectrelated to the Bootstrap server is avoidedPUT /0/{i} and /1/{i}2.04 ChangedBootstrap-FinishPOST /bs2.04 ChangedThe device then Registers to the LwM2M server
Figure 1. Bootstrap sequence diagram


The Bootstrap status is visible in the Bootstrap Entry. The status evolves as follows during the Bootstrap sequence:


Bootstrap StatusNEVER_REQUESTEDNo Bootstrap-Request has ever been received for the entryREQUESTEDA Bootstrap session is ongoingFINISHEDAll the Bootstrap Information have been providedFAILED- Unauthorized- No config or invalid config- Unable to automatically provision credentials (if required)- Incorrect manual provisioning (in useLiveObjects mode)- Device-side exception (e.g. inconsistent configuration)- Any other unexpected exceptionuser creation of the Bootstrap Entry (north API)the device sends a Bootstrap-Requestthe server sends a Bootstrap-Finishan error occurs during the Bootstrap session
Figure 2. Bootstrap state machine


Using LiveObjects as Run Server

To use LiveObjects as Run Server, the Bootstrap Config must be created with the parameter useLiveObjects set to true. Refer to this Bootstrap Config creation example.

A device must be created in your account (with the same endpoint name as the Bootstrap Entry) before the bootstrap takes place.

However, if you use the autoProvisionDeviceOnBootstrap.enabled=true setting in the config.RunServer definition, you can skip this device pre-provisioning: the device will be automatically created in the device inventory of the Bootstrap Entry’s customer account.

The device can be declared as being managed by the LiveObjects Bootstrap Server (bootstrap.managed = true and w/o security info) or not (bootstrap.managed = false and w/ security info). Refer to: LwM2M Device or LwM2M Device managed by Bootstrap creation examples.

If the device is created with bootstrap.managed = true (and in the same tenant as the Entry), the security info will be automatically provisioned in the LiveObjects device representation upon bootstrapping. Otherwise, they must be provisioned manually during the device creation, and they will be checked during bootstrap (i.e., do they match the security info that was provisioned in the Bootstrap Entry, and that will be set on the physical device).

If an error occurs during the automatic provisioning of the security info or if there is a security info mismatch, the Bootstrap sequence will fail. After a successful Bootstrap sequence, the device will register with the LiveObjects LwM2M Run server.


DeviceLiveObjectsDeviceLiveObjectsCUSTOMERDeviceLiveObjectsCUSTOMERDeviceLiveObjectsProvisioningCreates a new Bootstrap Configwith useLiveObjects = truePOST/api/v1/bootstrap/lwm2m/configs<Bootstrap Config created>Creates a new Bootstrap Entry andassociate it to the Bootstrap ConfigPOST/api/v1/bootstrap/lwm2m/entries<Bootstrap Entry created>Creates a new Devicewith the same endpoint name as the Bootstrap Entrymanaged by LiveObjects Bootstrap Serveror not (bootstrap.managed = true/false)POST/api/v1/deviceMgt/devices<Device created>Bootstrap sequenceDTLS Handshake (PSK)Bootstrap-RequestPOST /bs?ep={Endpoint Client Name}&pct={Preferred Content Format}alt[bootstrap.managed = false]Check that the security info that weremanually provisioned in the LO devicerepresentation match the one that will beset by the Bootstrap Server[bootstrap.managed = true && the device and entry belong to the same tenant]Provision run credentials in theLiveObjects device representationalt[Accepted]2.04 Changed[Unable to provision security info or security info mismatch]5.00 Internal Server Error The bootstrap sequence proceeds as usual Bootstrap-FinishPOST /bs2.04 ChangedThe device registers with the LiveObjects Run server
Figure 3. Bootstrap sequence using LiveObjects as Run Server


With credentials generated at Bootstrap time

The following diagram describes the sequence when the run credentials are generated at Bootstrap time.
The Bootstrap Config has to be created with the renewSecurityOnBootstrap parameter set to true. Refer to this Bootstrap Config creation example. The Bootstrap Entry should be created without Run credentials (otherwise they will just be ignored).
If the Bootstrap Config does not set autoProvisionDeviceOnBootstrap.enabled=true, a device must be created on LiveObjects with the bootstrap.managed parameter set to true (and with the same endpoint name and on the same account as the Bootstrap Entry). Refer to this Device creation example.
At each Bootstrap new credential will be generated and automatically provisioned in the LiveObjects device representation. If an error occurs during the credentials provisioning, the Bootstrap sequence will fail. After a successful Bootstrap sequence, the device will register with the LiveObjects LwM2M Run server using the generated credentials.


DeviceLiveObjectsDeviceLiveObjectsCUSTOMERDeviceLiveObjectsCUSTOMERDeviceLiveObjectsProvisioningCreates a new Bootstrap Configwith useLiveObjects = trueandrenewSecurityOnBootstrap = truePOST/api/v1/bootstrap/lwm2m/configs<Bootstrap Config created>Creates a new Bootstrap Entrywithout run credentialsand associate it to the Bootstrap ConfigPOST/api/v1/bootstrap/lwm2m/entries<Bootstrap Entry created>Creates a new Devicewith the same endpoint name as the Bootstrap Entrywithbootstrap.managed = truewithout run credentialson the same tenantPOST/api/v1/deviceMgt/devices<Device created>Bootstrap sequenceDTLS Handshake (PSK)Bootstrap-RequestPOST /bs?ep={Endpoint Client Name}&pct={Preferred Content Format}Generate new credentials and provisionthem in the LiveObjects device representationalt[Accepted]2.04 Changed[Unable to provision credentials]5.00 Internal Server Error The bootstrap sequence proceeds as usual Bootstrap-FinishPOST /bs2.04 ChangedThe device registers with the LiveObjects Run serverusing the generated credentials
Figure 4. Bootstrap sequence with credentials generated at bootstrap time


Using a Bootstrap Master Entry

The following diagram describes the sequence when using a Bootstrap Master Entry.

A Bootstrap Master Entry must be created to get a Bootstrap Master Entry ID and a master PSK secret, from which the PSK identity and secret for each endpoint are derived (the key derivation is of course not done by the device, which must not know the master secret).

The Bootstrap Config must be created with the following parameters set to true: useLiveObjects, renewSecurityOnBootstrap, and autoProvisionDeviceOnBootstrap.enabled.

A Bootstrap Entry and a LwM2M device will be automatically created or updated for each endpoint using the Bootstrap Master Entry, (i.e., for each endpoint whose credentials are derived from it) during the Bootstrap sequence. For more details about how credentials are derived for each endpoint, refer to Endpoint Credentials.


DeviceLiveObjectsDeviceLiveObjectsCUSTOMERDeviceLiveObjectsCUSTOMERDeviceLiveObjectsProvisioningCreates a new Bootstrap Configwith useLiveObjects = trueand renewSecurityOnBootstrap = trueand autoProvisionDeviceOnBootstrap.enabled = truePOST/api/v1/bootstrap/lwm2m/configs<Bootstrap Config created>Creates a new Bootstrap Master Entry(with a link to a Bootstrap Config)POST/api/v1/bootstrap/lwm2m/masterEntries<Bootstrap Master Entry created>Saves the Bootstrap Master Entry ID and PSK secret. Provisions endpoints using this information to determinethe PSK identity and secret (derived from the master secret)to use for each endpoint.Bootstrap sequencePSK identity: {Endpoint Client Name}@{Bootstrap Master Entry ID}PSK secret: derived from the master secret and endpoint name (The key derivation is not done by the device, which must not knowthe master secret.)DTLS Handshake (PSK)Bootstrap-RequestPOST /bs?ep={Endpoint Client Name}&pct={Preferred Content Format}Creates a Bootstrap Entry for the endpointProvision the device with some generated credentials(or update the credentials if the device was already created) The bootstrap sequence proceeds as usual Bootstrap-FinishPOST /bs2.04 ChangedThe device registers with the LiveObjects Run serverusing the generated credentials
Figure 5. Bootstrap sequence using a Bootstrap Master Entry