4

In the process of building a device that will utilise LWM2M protocol. Referring to the protocol specification here we have made a good stab at laying out the uplink and downlink packet specification.

One of the remaining to do items is to figure out how to deal with the Bootstrap process. As I understand it we have 4 options:

  • Factory Bootstrap
  • Bootstrap from Smartcard
  • Client Initiated Bootstrap
  • Server Initiated Bootstrap

We have a COAP server up and running with LWM2M server support and Bootstrap Server support.


Figure: 4.-1 The overall architecture of the LwM2M Enabler


What I am trying to do now is understand how to utilise the LWM2M Bootstrap-Server as a LWM2M Client and document the workflow.

The easier option appear to be "Factory Bootstrap" process.

"In this mode, the LwM2M Client has been configured with the necessary bootstrap information prior to deployment of the device. The configured information may be the LwM2M Bootstrap-Server Bootstrap Information and/or the LwM2M Server Bootstrap Information."

Ok so under "Factory Bootstrap" device has the "necessary bootstrap information prior to deployment".

This information appears to be:

  • LwM2M Server Account (required)
  • Additional Object Instances (optional)
  • LwM2M Bootstrap-Server Account (optional)

Questions re Factory Bootstrap

So at the very least for a Factory Bootstrap and from the Server, I need to generate an LWM2M Server Account for the factory to write to the device. Is this correct ?

And does this "LWM2M Server Account" need to be unique per client at this stage ?

Questions re Client Initiated Bootstrap

If we dont go down the Factory Bootstrap route then the second option would be the Client Initiated Bootstrap. Does anyone have experencie of the process that can advise on the benefits of this method?

Thank you

1 Answer 1

1

I am no further forward on this part of the question "Questions re Factory Bootstrap"

But answer to this "questions re Client Initiated Bootstrap" can be found here I think.

Why not “hardcode” final server URL and credentials at factory?

Well it’s possible, it’s called “factory bootstrap”, but it’s not a good practice: if you need to change the server URL or credentials (passwords) you will need to have physical access to the device.

Here come the so-called “device initiated bootstrap”.

  • During the factory flashing you just put “bootstrap credentials” for reaching a bootstrap server.
  • The bootstrap server only feature is to answer bootstrap request (POST on /bs) and to configure the device with servers URL and credentials (private key, certificate, pre-shared-keys, etc..).

The parameters configured during bootstrap are:

Server security credentials:

  • pre-shared keys for secure DTLS PSK communications
  • or private key and certificate for DTLS RPK or X.509 communications
  • URLs for reaching the server like “coaps://my.server.com:5684"
  • SMS security parameters for communicating with the device or the server

Communication parameters:

  • communication frequency (lifetime)
  • binding mode: does the device is always connected or not, does it uses UDP and/or SMS

Access Control Lists:

  • which server can read/write which objects, like firmware update or connectivity parameters, (only when you have more than one device management server)

The device can trigger a bootstrap when:

  • when the device contains only bootstrap credentials and no device-management server credentials,
  • when the device, for any reason, fails to start a communication with the configured device management servers (server not responding, authentication failure, etc..).

Why doing security configuration in two steps? Why not putting the key in the factory and wait for the need to change it for triggering a device bootstrap?

The first advantage: you are sure configuring device credential “over-the-air” is working because you use it at least once during the device lifetime.

You want to change the credentials in the device because you had a breach in your servers or because you want to rotate your keys/certificate? It’s easy, tested and running! Just invalidate the previous credentials on the server, the device will trigger a re-bootstrap and get the new credentials from the bootstrap server. This procedure can also be used for re-configuring a device for connecting to another server.

Once past the initial bootstrap, the factory doesn’t know the final secrets used for communicating. So someone breaking into the factory and gathering bootstrap credentials won’t be able to eavesdropping final device-management communications. At least, they could observe the bootstrap communications and discover the device management key for few devices, but they won’t directly have access to your whole fleet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.