You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Improvements from testing
Some of the code is a bit confused - tidy it up a bit.
Make the configuration of the client runtime configurable.
Add host scripts which makes testing / experimentation easier.
* Update to server
The server uses different contraints for the secrity setting.
I think this was to account for the fact that certain combinations
won't work. But it's confusing, so make the client and server
behave the same.
Add a menu for the security setting to the server (like the client).
Update the readme about WSL issues.
* Remove redundant code
HCI_EVENT_LE_META / HCI_SUBEVENT_LE_CONNECTION_COMPLETE is not received
when ENABLE_LE_ENHANCED_CONNECTION_COMPLETE_EVENT is set in config
This example uses BLE to communicate temperature between a pair of pico Ws. This example is a variant of temp sensor, using LE secure to provide a secure connection.
3
+
This example uses BLE to communicate temperature between a pair of Pico Ws. It is a variant of
4
+
the temp sensor example, using LE Secure Connections to provide a secure connection.
4
5
5
-
secure_temp_server is a peripheral or server that transmits its temperature to another device
6
-
secure_temp_client is a client that reads a temperature from another device
6
+
`secure_temp_server` is a peripheral/server that transmits its temperature to another device.
7
+
`secure_temp_client` is a central/client that reads temperature from another device.
7
8
8
-
In server.c and client.c there is a define SECURITY_SETTING which you can change to explore different security options:
9
+
## Security settings
9
10
10
-
security setting 0: Just works (pairing), no MITM (Man In The Middle) protection
11
-
client and server have no input or output support
11
+
In `server.c` and `client.c` there is a `SECURITY_SETTING` define which you can change to explore
12
+
different BLE security options. Both ends must be built with the same setting unless you are
13
+
deliberately testing an asymmetric combination (see the table below).
12
14
13
-
security setting 1: Numeric comparison with MITM protection
14
-
client can query yes or no from the user, server has a display only
15
-
server displays passkey
16
-
client displays passkey and user can select Yes or No if they agree the passkey is from the server
15
+
The settings map to Bluetooth IO capabilities as follows:
17
16
18
-
security setting 2:
19
-
client has a keyboard and display, server has a display only
20
-
server displays passkey
21
-
client user enters the passkey displayed by the server
17
+
| Setting | IO capability | Description |
18
+
|---------|--------------|-------------|
19
+
| 0 |`NO_INPUT_NO_OUTPUT`| Just Works - no MITM protection |
| 3 |`DISPLAY_ONLY`| Display Only - MITM protection |
22
23
23
-
security setting 3:
24
-
client has a display only, server has a display and keyboard
25
-
Client displays passkey
26
-
server user enters the passkey displayed by the server
24
+
The actual pairing method used depends on the IO capabilities of *both* devices, not just one.
25
+
The Bluetooth SIG defines a matrix of initiator × responder capabilities that determines the
26
+
method. Setting `SM_AUTHREQ_MITM_PROTECTION` requests MITM protection but does not guarantee it —
27
+
if the negotiated method cannot provide it, pairing will fail.
27
28
28
-
You will need to use the console with both devices to see the passkeys and answer security prompts. Both stdio over UART and USB are enabled so you can use either.
0 commit comments