mirror of
https://github.com/espressif/esp-idf.git
synced 2024-10-05 20:47:46 -04:00
docs: remove WiFi related documentation for ESP32-H2
This commit is contained in:
Linda
parent
c8c7f999ef
commit
bd1825f9b1
@ -66,7 +66,9 @@ WIFI_DOCS = ['api-guides/wifi.rst',
|
||||
'api-reference/network/esp_now.rst',
|
||||
'api-reference/network/esp_smartconfig.rst',
|
||||
'api-reference/network/esp_wifi.rst',
|
||||
'api-reference/network/esp_dpp.rst']
|
||||
'api-reference/network/esp_dpp.rst',
|
||||
'api-reference/provisioning/provisioning.rst',
|
||||
'api-reference/provisioning/wifi_provisioning.rst']
|
||||
|
||||
NAN_DOCS = ['api-reference/network/esp_nan.rst']
|
||||
|
||||
|
||||
@ -28,8 +28,11 @@ Protocomm provides the framework for various transports:
|
||||
:SOC_WIFI_SUPPORTED: - Wi-Fi (SoftAP + HTTPD)
|
||||
- Console, in which case the handler invocation is automatically taken care of on the device side. See Transport Examples below for code snippets.
|
||||
|
||||
Note that for protocomm_security1 and protocomm_security2, the client still needs to establish sessions by performing the two-way handshake.
|
||||
|
||||
Note that for protocomm_security1 and protocomm_security2, the client still needs to establish sessions by performing the two-way handshake. See :doc:`provisioning` for more details about the secure handshake logic.
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
See :doc:`provisioning` for more details about the secure handshake logic.
|
||||
|
||||
.. _enabling-protocomm-security-version:
|
||||
|
||||
@ -43,7 +46,7 @@ The protocomm component provides a project configuration menu to enable/disable
|
||||
* Support ``protocomm_security2`` with SRP6a-based key exchange + AES-GCM encryption/decryption: :ref:`CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_2`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
Enabling multiple security versions at once offers the ability to control them dynamically but also increases the firmware size.
|
||||
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
:orphan:
|
||||
|
||||
Unified Provisioning
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -14,7 +12,7 @@ The unified provisioning support in the ESP-IDF provides an extensible mechanism
|
||||
|
||||
The protocol is completely flexible and it offers the ability for the developers to send custom configuration in the provisioning process. The data representation is also left to the application to decide.
|
||||
|
||||
2. **Transport Flexibility**
|
||||
2. **Transport Flexibility**
|
||||
|
||||
The protocol can work on Wi-Fi (SoftAP + HTTP server) or on Bluetooth LE as a transport protocol. The framework provides an ability to add support for any other transport easily as long as command-response behavior can be supported on the transport.
|
||||
|
||||
@ -22,7 +20,7 @@ The protocol can work on Wi-Fi (SoftAP + HTTP server) or on Bluetooth LE as a tr
|
||||
|
||||
It is understood that each use case may require different security scheme to secure the data that is exchanged in the provisioning process. Some applications may work with SoftAP that is WPA2 protected or Bluetooth LE with the "just-works" security. Or the applications may consider the transport to be insecure and may want application-level security. The unified provisioning framework allows the application to choose the security as deemed suitable.
|
||||
|
||||
4. **Compact Data Representation**
|
||||
4. **Compact Data Representation**
|
||||
|
||||
The protocol uses `Google Protobufs <https://developers.google.com/protocol-buffers/>`_ as a data representation for session setup and Wi-Fi provisioning. They provide a compact data representation and ability to parse the data in multiple programming languages in native format. Please note that this data representation is not forced on application-specific data and the developers may choose the representation of their choice.
|
||||
|
||||
@ -233,8 +231,8 @@ Details about the Security 2 scheme are shown in the below sequence diagram:
|
||||
Verifier v = g^x where x = H(s | I | p)"];
|
||||
DEVICE -> DEVICE [label = "Generate\nKey Pair", leftnote = "b (dev_privkey) = 256 bit random value
|
||||
B(dev_pubkey) = k*v + g^b where k = H(N, g)"];
|
||||
DEVICE -> DEVICE [label = "Shared Key", leftnote = "Shared Key K = H(S) where,
|
||||
S = (A * v^u) ^ b
|
||||
DEVICE -> DEVICE [label = "Shared Key", leftnote = "Shared Key K = H(S) where,
|
||||
S = (A * v^u) ^ b
|
||||
u = H(A, B)"];
|
||||
DEVICE -> CLIENT [label = "SessionResp0(dev_pubkey B, dev_rand)"];
|
||||
CLIENT -> CLIENT [label = "Shared Key", rightnote = "shared_key(K) = H(S) where,
|
||||
@ -243,7 +241,7 @@ Details about the Security 2 scheme are shown in the below sequence diagram:
|
||||
k = H(N, g),
|
||||
v = g^x,
|
||||
x = H(s | I | p).
|
||||
|
||||
|
||||
"];
|
||||
CLIENT -> CLIENT [label = "Verification\nToken", rightnote = "client_proof M = H[H(N) XOR H(g) | H(I) | s | A | B | K]"];
|
||||
CLIENT -> DEVICE [label = "SessionCmd1(client_proof M1)"];
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
:orphan:
|
||||
|
||||
Wi-Fi Provisioning
|
||||
==================
|
||||
|
||||
|
||||
@ -197,18 +197,20 @@ UART Download Mode
|
||||
Product Security
|
||||
----------------
|
||||
|
||||
Secure Provisioning
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
Secure Provisioning refers to a process of secure on-boarding of the ESP device on to the Wi-Fi network. This mechanism also allows provision of additional custom configuration data during the initial provisioning phase from the provisioning entity, e.g., Smartphone.
|
||||
Secure Provisioning
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
ESP-IDF provides various security schemes to establish a secure session between ESP and the provisioning entity, they are highlighted at :ref:`provisioning_security_schemes`.
|
||||
Secure Provisioning refers to a process of secure on-boarding of the ESP device on to the Wi-Fi network. This mechanism also allows provision of additional custom configuration data during the initial provisioning phase from the provisioning entity, e.g., Smartphone.
|
||||
|
||||
Please refer to the :doc:`../api-reference/provisioning/wifi_provisioning` documentation for details and the example code for this feature.
|
||||
ESP-IDF provides various security schemes to establish a secure session between ESP and the provisioning entity, they are highlighted at :ref:`provisioning_security_schemes`.
|
||||
|
||||
.. note::
|
||||
Please refer to the :doc:`../api-reference/provisioning/wifi_provisioning` documentation for details and the example code for this feature.
|
||||
|
||||
Espressif provides Android and iOS Phone Apps along with their sources, so that it could be easy to further customize them as per the product requirement.
|
||||
.. note::
|
||||
|
||||
Espressif provides Android and iOS Phone Apps along with their sources, so that it could be easy to further customize them as per the product requirement.
|
||||
|
||||
Secure OTA (Over-the-air) Updates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -28,8 +28,11 @@ Protocomm 为以下各种传输提供框架：
|
||||
:SOC_WIFI_SUPPORTED: - Wi-Fi (SoftAP + HTTPD)
|
||||
- 控制台：使用该传输方案时，设备端会自动调用处理程序。相关代码片段，请参见下文传输示例。
|
||||
|
||||
请注意，对于 ``protocomm_security1`` 和 ``protocomm_security2``，客户端仍需要执行双向握手来建立会话。
|
||||
|
||||
请注意，对于 ``protocomm_security1`` 和 ``protocomm_security2``，客户端仍需要执行双向握手来建立会话。关于安全握手逻辑的详情，请参阅 :doc:`provisioning`。
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
关于安全握手逻辑的详情，请参阅 :doc:`provisioning`。
|
||||
|
||||
.. _enabling-protocomm-security-version:
|
||||
|
||||
@ -40,10 +43,10 @@ Protocomm 为以下各种传输提供框架：
|
||||
|
||||
* 支持 ``protocomm_security0``，该版本无安全功能：:ref:`CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_0`，该选项默认启用。
|
||||
* 支持 ``protocomm_security1``，使用 Curve25519 密钥交换和 AES-CTR 加密/解密：:ref:`CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_1`，该选项默认启用。
|
||||
* 支持 ``protocomm_security2``，使用基于 SRP6a 的密钥交换和 AES-GCM 加密/解密：:ref:`CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_2`。
|
||||
* 支持 ``protocomm_security2``，使用基于 SRP6a 的密钥交换和 AES-GCM 加密/解密：:ref:`CONFIG_ESP_PROTOCOMM_SUPPORT_SECURITY_VERSION_2`。
|
||||
|
||||
.. note::
|
||||
|
||||
.. note::
|
||||
|
||||
启用多个安全版本后可以动态控制安全版本，但也会增加固件大小。
|
||||
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
@ -241,7 +244,7 @@ Protocomm 为以下各种传输提供框架：
|
||||
|
||||
使用 Security 0 的低功耗蓝牙传输方案示例
|
||||
-------------------------------------------
|
||||
|
||||
|
||||
示例用法请参阅 :component_file:`wifi_provisioning/src/scheme_ble.c`。
|
||||
|
||||
.. highlight:: c
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
:orphan:
|
||||
|
||||
统一配网
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -18,11 +16,11 @@ ESP-IDF 支持统一配网，提供可扩展的机制，支持开发者使用不
|
||||
|
||||
该协议可以作为 Wi-Fi（SoftAP + HTTP 服务器）或低功耗蓝牙上的传输方式，并且可轻松应用于任何支持请求—响应行为的传输方式。
|
||||
|
||||
3. **安全方案灵活**
|
||||
3. **安全方案灵活**
|
||||
|
||||
配网过程中，各使用场景可能需要不同安全方案来保护传输的数据。部分应用程序可能使用 WPA2 保护的 SoftAP 或具有“即插即用 (just-works)”安全方案的低功耗蓝牙。亦或者，应用程序可能认为传输不安全，需要应用层的安全方案。统一配网框架支持应用程序根据需要选择合适的安全方案。
|
||||
|
||||
4. **数据格式紧凑**
|
||||
4. **数据格式紧凑**
|
||||
|
||||
该协议使用 `Google Protobufs <https://developers.google.com/protocol-buffers/>`_ 作为会话设置和 Wi-Fi 配网的数据格式。该方案提供紧凑的数据格式，并可以使用不同编程语言进行数据解析。请注意，该配网的应用数据格式并不只局限于 Protobufs，开发者可以自行选择自己想用的数据格式。
|
||||
|
||||
@ -97,7 +95,7 @@ ESP-IDF 支持统一配网，提供可扩展的机制，支持开发者使用不
|
||||
|
||||
有两种安全方案层级可供选择，开发者可以根据需求选择其中一种或结合使用。
|
||||
|
||||
1. **传输层安全**
|
||||
1. **传输层安全**
|
||||
|
||||
对于 SoftAP 配网，可以使用 WPA2 保护的安全方案，则每个设备都会有唯一密码，且该密码也可以用作 PoP。对于低功耗蓝牙配网，在考量其支持的安全层级后，可以使用“即插即用”方案保护传输层的安全。
|
||||
|
||||
@ -152,8 +150,8 @@ ESP-IDF 支持统一配网，提供可扩展的机制，支持开发者使用不
|
||||
|
||||
基于 SRP6a 的共享密钥派生和 AES256-GCM 模式的数据加密。
|
||||
|
||||
.. note::
|
||||
|
||||
.. note::
|
||||
|
||||
要启用相应安全方案，需要设置项目配置菜单，更多详情请参考 :ref:`enabling-protocomm-security-version`。
|
||||
|
||||
Security 1 方案
|
||||
@ -233,8 +231,8 @@ Security 2 方案基于 Secure Remote Password (SRP6a) 协议，详情请参阅
|
||||
验证器 v = g^x，其中 x = H(s | I | p)"];
|
||||
DEVICE -> DEVICE [label = "生成密钥对", leftnote = "b (dev_privkey) = 256 位随机值
|
||||
B(dev_pubkey) = k*v + g^b，其中 k = H(N, g)"];
|
||||
DEVICE -> DEVICE [label = "共享密钥", leftnote = "共享密钥 K = H(S)，其中
|
||||
S = (A * v^u) ^ b
|
||||
DEVICE -> DEVICE [label = "共享密钥", leftnote = "共享密钥 K = H(S)，其中
|
||||
S = (A * v^u) ^ b
|
||||
u = H(A, B)"];
|
||||
DEVICE -> CLIENT [label = "SessionResp0(dev_pubkey B, dev_rand)"];
|
||||
CLIENT -> CLIENT [label = "共享密钥", rightnote = "shared_key(K) = H(S)，其中
|
||||
@ -243,7 +241,7 @@ Security 2 方案基于 Secure Remote Password (SRP6a) 协议，详情请参阅
|
||||
k = H(N, g),
|
||||
v = g^x,
|
||||
x = H(s | I | p).
|
||||
|
||||
|
||||
"];
|
||||
CLIENT -> CLIENT [label = "验证令牌", rightnote = "client_proof M = H[H(N) XOR H(g) | H(I) | s | A | B | K]"];
|
||||
CLIENT -> DEVICE [label = "SessionCmd1(client_proof M1)"];
|
||||
|
||||
@ -1,5 +1,3 @@
|
||||
:orphan:
|
||||
|
||||
Wi-Fi 配网
|
||||
====================
|
||||
|
||||
@ -121,7 +119,7 @@ Wi-Fi 配网
|
||||
|
||||
此外，由于管理器内部使用了 ``protocomm``，可以选择其提供的任一安全功能：
|
||||
|
||||
* Security 1 是安全通信，该安全通信需要先握手，其中涉及 X25519 密钥交换和使用所有权证明 ``pop`` 完成身份验证，随后使用 AES-CTR 加密或解密后续消息。
|
||||
* Security 1 是安全通信，该安全通信需要先握手，其中涉及 X25519 密钥交换和使用所有权证明 ``pop`` 完成身份验证，随后使用 AES-CTR 加密或解密后续消息。
|
||||
* Security 0 是纯文本通信，会直接忽略 ``pop``。
|
||||
|
||||
关于安全功能的更多详情，请参阅 :doc:`provisioning`。
|
||||
|
||||
@ -180,18 +180,20 @@ UART 下载模式
|
||||
产品安全
|
||||
----------------
|
||||
|
||||
安全配网
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
安全配网是指将 ESP 设备安全接入 Wi-Fi 网络的过程。该机制还支持在初始配网阶段从配网实体（如智能手机等）获取额外的自定义配置数据。
|
||||
安全配网
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
ESP-IDF 提供了多种安全方案，可以在 ESP 设备和配网实体之间建立安全会话，具体方案请参阅 :ref:`provisioning_security_schemes`。
|
||||
安全配网是指将 ESP 设备安全接入 Wi-Fi 网络的过程。该机制还支持在初始配网阶段从配网实体（如智能手机等）获取额外的自定义配置数据。
|
||||
|
||||
关于该功能的更多详情和代码示例，请参阅 :doc:`../api-reference/provisioning/wifi_provisioning`。
|
||||
ESP-IDF 提供了多种安全方案，可以在 ESP 设备和配网实体之间建立安全会话，具体方案请参阅 :ref:`provisioning_security_schemes`。
|
||||
|
||||
.. note::
|
||||
关于该功能的更多详情和代码示例，请参阅 :doc:`../api-reference/provisioning/wifi_provisioning`。
|
||||
|
||||
乐鑫提供了 Android 和 iOS 手机应用程序及其源代码，以便进一步根据产品需求定制安全配网方案。
|
||||
.. note::
|
||||
|
||||
乐鑫提供了 Android 和 iOS 手机应用程序及其源代码，以便进一步根据产品需求定制安全配网方案。
|
||||
|
||||
安全 OTA 更新
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Loading…
Reference in New Issue
Block a user