Mirrors/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2026-09-22 13:01:16 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs(security): fix typos in security guides

Browse Source 
- security.rst: remove duplicated word in OTA encryption note
- tee.rst: remove duplicated word in memory allocation note
- flash-encryption.rst: drop redundant phrase and fix subject-verb agreement
This commit is contained in:
Mahavir Jain
2026-06-10 13:09:09 +05:30
parent 839352f836
commit fbee2bc027
3 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/en/security/flash-encryption.rst
View File

@@ -621,7 +621,7 @@ To use a host generated key and program it into the eFuses of the device, take t
.. only:: SOC_KEY_MANAGER_SUPPORTED
To use a host generated key and deploy it into the device's Key Manager of the device, take the following steps:
To use a host generated key and deploy it into the device's Key Manager, take the following steps:
1. Ensure that you have an {IDF_TARGET_NAME} device with default flash encryption eFuse settings as shown in :ref:`flash-encryption-efuse`.
@@ -1204,11 +1204,11 @@ Manually Encrypting Files
.. only:: SOC_KEY_MANAGER_SUPPORTED
Manually encrypting or decrypting files require the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
Manually encrypting or decrypting files requires the flash encryption key to be deployed in the Key Manager or pre-burned in eFuses (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
.. only:: not SOC_KEY_MANAGER_SUPPORTED
Manually encrypting or decrypting files require the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
Manually encrypting or decrypting files requires the flash encryption key to be pre-burned in eFuse (see :ref:`pregenerated-flash-encryption-key`) and a copy to be kept on the host. If the flash encryption is configured in development mode, then it is not necessary to keep a copy of the key or follow these steps. The simpler :ref:`encrypt-partitions` steps can be used.
The key file should be a single raw binary file (example: ``key.bin``).

2
docs/en/security/security.rst
View File

@@ -311,7 +311,7 @@ Please see more information to enable this feature in the :ref:`anti-rollback` g
Encrypted Firmware Distribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application.
Encrypted firmware distribution during over-the-air updates ensures that the application stays encrypted **in transit** from the server to the device. This can act as an additional layer of protection on top of the TLS communication during OTA updates and protect the identity of the application.
Please see working example for this documented in :ref:`ota_updates_pre-encrypted-firmware` section.

2
docs/en/security/tee/tee.rst
View File

@@ -76,7 +76,7 @@ ESP-TEE divides the memory into separate regions for the TEE and REE, allocating
Internal Memory (SRAM)
^^^^^^^^^^^^^^^^^^^^^^
Internal memory is allocated to the the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration <esp-tee-trusted-execution-environment--enable-the-esp-tee-framework-memory-configuration>` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE.
Internal memory is allocated to the TEE based on the Kconfig options that are available under the :ref:`Memory Configuration <esp-tee-trusted-execution-environment--enable-the-esp-tee-framework-memory-configuration>` section in the :ref:`esp-tee-trusted-execution-environment-` menu. All remaining memory is allocated to the REE.
.. warning::