This commit adds a new feature to generate a salt and verifier pair for a given username and
password during the provisioning process. This is useful in scenarios where the pairing pin is
randomly generated and shown via some interface such as a display or console.
- Uses the provided username and password to generate a salt and verifier pair
- Adds support for dev mode where the pin/password can still be read from flash
- `protocomm` depends on a config option `CONFIG_WIFI_PROV_BLE_FORCE_ENCRYPTION`
from `wifi_provisioning`; however, a lower layer component (`protocomm`) should
not have any `#ifdef` guard dependent on an upper layer component (`wifi_provisioning`).
- Added a new `ble_link_encryption` flag in `protocomm_ble_config_t` to manage the same
Closes https://github.com/espressif/esp-idf/issues/9443
1) Rename srp component to esp_srp
2) Remove dependency on hkdf sha
3) Restructure protocomm component APIs to make them more flexible for allowing multiple security versions
4) esp_srp: convert API return type from int to esp_err_t
5) esp_srp: Formatting changes
6) Added mbedtls_gcm instead of aes_ctr
Co-authored-by: Laukik hase <laukik.hase@espressif.com>
- Add `wifi_prov_scheme_ble_set_mfg_data` API to set custom manufacturer data
in BLE advertisements.
- Run format.sh script on modified files.
- Fix few typos in `protocomm_nimble.c`.
- Incorporate suggestion to remove extra check on protocomm_ble_mfg_data_len
- Remove few unnecessary comments.
List of changes:
* New component esp_local_ctrl added
* Example added under examples/protocols/esp_local_ctrl
* Documentation added under protocols/esp_local_ctrl
* Demo client side app esp_local_ctrl.py added under examples/protocols/esp_local_ctrl/scripts
* protocomm_ble : protocomm_ble_config_t given struct name for allowing forward declaration
* esp_prov/transport_softap renamed to transport_http
* transport_http module supports verification of server certificate
* transport_http module performs name resolution before connection
- Adds NimBLE stack support to existing BLE variant of unified provisioning.
- Uses scan response to send device name, 128 bit custom UUIDs based on service
UUID.
- Minimal changes to `app_prov.c`, component.mk, CMakeLists.txt and
`protocomm_ble.h` to accomodate NimBLE stack for provisioning.
List of changes:
* Use 128 bit characteristic UUIDs when creating GATT table entries
* Change primary service attribute value to 128 bit custom service UUID
* Use raw advertisement data to convey flags and 128 bit primary service UUID
* Use raw scan response to send device name as complete local name
* Increase maximum device name length in relation to maximum scan response length
* Set Characteristic User Description attributes for each characteristic to convey protocomm endpoint names
New APIs:
* protocomm_open_session()
* protocomm_close_session()
This allows external applications using protocomm to manually create and close sessions.
These internally call the new_transport_session() and close_transport_session() APIs implemented by the security scheme in use.
Updated unit tests with usage of new APIs
List of changes:
* Security APIs accept handle to instance created during initialization
* Protocomm internally stores the security instance handle and calls security APIs with this handle as first parameter
This will be useful if a webserver is already running and the application
does not want protocomm to start a new instance.
Signed-off-by: Piyush Shah <piyush@espressif.com>
* This manages secure sessions and provides framework for multiple transports.
* The application can use protocomm layer directly to have application specific extensions for provisioning (or non-provisioning) use cases.
* Following features are available for provisioning :
* Security - Security0 (no security), Security1 (curve25519 key exchange + AES-CTR encryption)
* Proof-of-possession support for Security1
* Protocomm requires specific protocol buffer modules for compilation which can be generated from the `.proto` files in the `proto` directory using make.
Co-Authored-By: Amey Inamdar <amey@espressif.com>
Co-Authored-By: Anurag Kar <anurag.kar@espressif.com>
