Lines Matching full:the
6 Provisioning is the process of adding devices to a mesh network. It requires
7 two devices operating in the following roles:
9 * The *provisioner* represents the network owner, and is responsible for
10 adding new nodes to the mesh network.
11 * The *provisionee* is the device that gets added to the network through the
12 Provisioning process. Before the provisioning process starts, the
15 The Provisioning module in the Zephyr Bluetooth Mesh stack supports both the
16 Advertising and GATT Provisioning bearers for the provisionee role, as well as
17 the Advertising Provisioning bearer for the provisioner role.
19 The Provisioning process
23 Bluetooth Mesh network. The Provisioning API provides all the functionality
25 Provisioning is a five-step process, involving the following steps:
36 To start the provisioning process, the unprovisioned device must first start
37 broadcasting the Unprovisioned Beacon. This makes it visible to nearby
38 provisioners, which can initiate the provisioning. To indicate that the device
39 needs to be provisioned, call :c:func:`bt_mesh_prov_enable`. The device
40 starts broadcasting the Unprovisioned Beacon with the device UUID and the
41 ``OOB information`` field, as specified in the ``prov`` parameter passed to
43 may be specified, which can point the provisioner to the location of some Out
44 Of Band information, such as the device's public key or an authentication
45 value database. The URI is advertised in a separate beacon, with a URI hash
46 included in the unprovisioned beacon, to tie the two together.
52 The Uniform Resource Identifier shall follow the format specified in the
53 Bluetooth Core Specification Supplement. The URI must start with a URI scheme,
54 encoded as a single utf-8 data point, or the special ``none`` scheme, encoded
55 as ``0x01``. The available schemes are listed on the `Bluetooth website
74 The provisioner initiates the Provisioning process by sending a Provisioning
75 invitation. The invitations prompts the provisionee to call attention to
76 itself using the Health Server
79 The Unprovisioned device automatically responds to the invite by presenting a
80 list of its capabilities, including the supported Out of Band Authentication
86 Before the provisioning process can begin, the provisioner and the unprovisioned
89 In-band public key exchange is a part of the provisioning process and always
90 supported by the unprovisioned device and provisioner.
92 If the application wants to support public key exchange via OOB, it needs to
93 provide public and private keys to the mesh stack. The unprovisioned device
94 will reflect this in its capabilities. The provisioner obtains the public key
95 via any available OOB mechanism (e.g. the device may advertise a packet
96 containing the public key or it can be encoded in a QR code printed on the
97 device packaging). Note that even if the unprovisioned device has specified
98 the public key for the Out of Band exchange, the provisioner may choose to
99 exchange the public key in-band if it can't retrieve the public key via OOB
100 mechanism. In this case, a new key pair will be generated by the mesh stack
103 To enable support of OOB public key on the unprovisioned device side,
104 :kconfig:option:`CONFIG_BT_MESH_PROV_OOB_PUBLIC_KEY` needs to be enabled. The
105 application must provide public and private keys before the Provisioning
108 and :c:member:`bt_mesh_prov.private_key_be`. The keys needs to be
111 To provide the device's public key obtained via OOB,
112 call :c:func:`bt_mesh_prov_remote_pub_key_set` on the provisioner side.
117 After the initial exchange, the provisioner selects an Out of Band (OOB)
118 Authentication method. This allows the user to confirm that the device the
119 provisioner connected to is actually the device they intended, and not a
122 The Provisioning API supports the following authentication methods for the
125 * **Static OOB:** An authentication value is assigned to the device in
126 production, which the provisioner can query in some application specific
128 * **Input OOB:** The user inputs the authentication value. The available input
130 * **Output OOB:** Show the user the authentication value. The available output
133 The application must provide callbacks for the supported authentication
134 methods in :c:struct:`bt_mesh_prov`, as well as enabling the supported actions
138 When an Output OOB action is selected, the authentication value should be
139 presented to the user when the output callback is called, and remain until the
141 callback is called. If the action is ``blink``, ``beep`` or ``vibrate``, the
144 When an Input OOB action is selected, the user should be prompted when the
145 application receives the :c:member:`bt_mesh_prov.input` callback. The user
146 response should be fed back to the Provisioning API through
148 no user response is recorded within 60 seconds, the Provisioning process is
152 the BT_MESH_ECDH_P256_HMAC_SHA256_AES_CCM algorithm.
157 After the device has been successfully authenticated, the provisioner
158 transfers the Provisioning data:
168 Additionally, a device key is generated for the node. All this data is stored
169 by the mesh stack, and the provisioning :c:member:`bt_mesh_prov.complete`
175 Depending on the choice of public key exchange mechanism and authentication method,
176 the provisioning process can be secure or insecure.
179 a set of vulnerabilities in the Bluetooth Mesh provisioning protocol that showcased
180 how the low entropy provided by the Blink, Vibrate, Push, Twist and
182 attacks. In response, the Bluetooth SIG has reclassified these OOB methods as
183 insecure in the Bluetooth Mesh Profile Specification v1.0.1 `erratum 16350 <https://www.bluetooth.o…