Bluetooth Mesh key generetion and handling?

RE: Bluetooth Mesh key generetion and handling?

SørenHN — Wed, 20 Dec 2017 14:08:42 GMT

After working more with this and reading the other answer, I think i understand it this better and write this for others who would like a better understanding.

Network Keys: Network keys is generated and distributed by the provisioner, the main network key is shared by all nodes in the network and the config client and server uses this subnetwork to communicate.

The netkey_index is used for avoiding sending the whole network key every time a model should use a subnetwork. Instead the network key is sent once and when the key is to be used again later, it is just referenced by its index.

Application Key: The application key is used the same way as the network. It is just used by another layer in the bluetooth mesh stack.

Device Keys: The device key is a specific key for each device. It is used by the config_client for configuring a device.

Server Handles: The server handles is maybe no given the best name in the example as they reefer to the element in which the light server models exist. I have renamed them to element_handle in my own project for clarity.

Group Handle: The group handle reefers to the group address for all the light servers in the example.

For being able to use a group address, the config_client should first tell the model to listen for messages to this group address, also known as adding the model to a group.

RE: Bluetooth Mesh key generetion and handling?

SørenHN — Wed, 13 Dec 2017 15:23:01 GMT

Hi Bjørn, thank you for you answers. I think I finally have figured out how the group address work. I thought the node was somehow added to the group. But it is more like the group being added to a node by being sent the group ID.

I do still not completely understand how the subnetworks work, but I will look the dsm source code and see if i can figure it out.

RE: Bluetooth Mesh key generetion and handling?

Bjørn Kvaale — Tue, 12 Dec 2017 12:41:31 GMT

Hi SørenHN. Sorry for the delayed response. I hope my updated answer answers all of your questions. Let me know if something doesn't make sense.

RE: Bluetooth Mesh key generetion and handling?

Bjørn Kvaale — Thu, 07 Dec 2017 10:36:23 GMT

I am pretty sure subnetworks are connected to the network (see Bluetooth Mesh Glossary, search for subnet). The definition posted there is: "Networks may contain one or more subnets". Therefore, the subnetwork must be a part of the bigger main mesh network.

RE: Bluetooth Mesh key generetion and handling?

SørenHN — Wed, 06 Dec 2017 09:45:58 GMT

Yes, i think it makes sense.

The thing I don't understand about subnetworks is, are a subnetwork somehow connected to the network or are a subnetwork just another network, which the node also is a part of?

RE: Bluetooth Mesh key generetion and handling?

Bjørn Kvaale — Tue, 05 Dec 2017 11:41:11 GMT

The definition of subnet is: "Networks may contain one or more subnets. Subnets are intended to allow secure isolation of different areas such as, for example, individual rooms in a hotel. A Node is a member of a subnet by virtue of it possessing the subnet's Network Key. A Node may belong to one or more subnets by possessing one or more subnet NetKeys." (see this link here).

From my understanding a network is made up of multiple subnetworks. I believe a node can be a part of one or multiple subnetworks. For example, take the hotel room example (i.e. the node). The whole network is the entire hotel, while a subnetwork could be the second floor of the hotel. Another subnetwork could be the first two floors of the hotel. Therefore, a hotel room on the second floor is a part of two different subnetworks. Does that make sense?

RE: Bluetooth Mesh key generetion and handling?

SørenHN — Tue, 05 Dec 2017 10:35:14 GMT

Yes, that makes sense. But how is subnet related to the network then? Or is it more about a node being part of more than one network, one of them being the overall network and one being a subnetwork?

RE: Bluetooth Mesh key generetion and handling?

Bjørn Kvaale — Tue, 05 Dec 2017 10:06:32 GMT

I believe you can use the dsm_subnet_add() function to add the overall network to the DSM bit by bit (or subnet by subnet). I guess you could use this function to add a subnetwork to a very small mesh network for example. Thereby, the whole network will be added to the dsm. Does that make sense?

RE: Bluetooth Mesh key generetion and handling?

SørenHN — Tue, 05 Dec 2017 09:28:19 GMT

Hi Bjørn. If dsm_subnet_add() does not add the overall network to the DSM, then how is it done?

RE: Bluetooth Mesh key generetion and handling?

Bjørn Kvaale — Fri, 01 Dec 2017 15:18:06 GMT

Hi SørenHN,

Network Key Question: the dsm_subnet_add() function is used for "adding a subnetwork & associated network key indexes to device state storage" (see link). So I don't think it adds the overall mesh network to the device state manager, but instead adds the subnetwork to device state manager.

And yes, the network key is generated by the provisioner & distributed to the provisionee that is being provisioned to the mesh network (see link & this link, section: Adding A New Device To The Network).

Application Key Question: The application key is used to generate & store application security material used for the mesh Rx & Tx. It secures communication at the access layer & is shared with every node in the mesh application network. It is up to the provisioner to generate & distribute the application keys (see link).

Device Keys Question: The device itself generates a device key, which is then shared only with the provisioner (see link, search for device key).

Edit: I previously said that the provisioner generates the device key, but this is incorrect.

Server Handle Question: Each element is a handle ID of the address of the server in the dsm address database. The server handles are added using dsm_address_publish_add() inside the provisioner_prov_complete_cb() function.

Group Handle Question: The group handle is the handle id of the group address (OXCAFE) , which is the address which states that you send a packet when you press button 4 to turn on all of the light switch servers. You said correctly that it is acquired using dsm_address_publish_add() inside the access_setup() function.