doc: security: rework section structure

Changed the structure of the security section.
Removed the security/security.rst page that duplicated security.rst.
Added an overview table on the landing page to provide info about
components documented elsewhere to reduce duplication of info.
NCSDK-22327.

Signed-off-by: Grzegorz Ferenc <Grzegorz.Ferenc@nordicsemi.no>

doc/_utils/redirects.py

@@ -298,8 +298,8 @@
  ("app_dev/optimizing/memory", "test_and_optimize/optimizing/memory"),
  ("app_power_opt", "test_and_optimize/optimizing/power"), # Power optimization
  ("app_dev/optimizing/power", "test_and_optimize/optimizing/power"),
- ("security_chapter", "security/security"), # Security (landing)
- ("security", "security/security"),
+ ("security_chapter", "security"), # Security (landing)
+ ("security/security", "security"), # Security (subpage -- removed in v2.8.0)
  ("ug_tfm", "security/tfm"), # Running applications with Trusted Firmware-M
  ("app_dev/tfm/index", "security/tfm"),
  ("app_dev/ap_protect/index", "security/ap_protect"), # Enabling access port protection mechanism

doc/_zoomin/ncs.tags.yml

@@ -163,8 +163,8 @@ mapping_topics:
  - nrf/test_and_optimize/optimizing/power_general.html: ["power-profiler-kit"]
  - nrf/test_and_optimize/optimizing/power_nrf91.html: ["power-profiler-kit", "nrf9160", "nrf9161",
  "nrf9151", "nrf9131", "lte"]
- - nrf/security/security.html: ["kconfig"]
- - nrf/security/ap_protect.html: ["kconfig"]
+ - nrf/security.html: ["kconfig"]
+ - nrf/security/*.html: ["kconfig"]
  - nrf/protocols/*.html: ["protocols"]
  - nrf/protocols.html: ["sidewalk", "ble", "blemesh", "esb", "gazell", "matter", "multiprotocol",
  "nfc", "thread", "zigbee", "wifi", "dect-nr+", "protocols"]

doc/nrf/app_dev/board_support/processing_environments.rst

@@ -7,7 +7,7 @@ Processing environments
  :local:
  :depth: 2
 
-The :ref:`boards supported by the SDK <app_boards_names>` distinguish entries according to the CPU to target (for multi-core SoCs) and whether Cortex-M Security Extensions (CMSE) are used or not (addition of the ``*/ns`` :ref:`variant <app_boards_names>` if they are used).
+The :ref:`boards supported by the SDK <app_boards_names>` distinguish entries according which CPU is to be targeted (for multi-core SoCs) and whether Cortex-M Security Extensions (CMSE) are used or not (addition of the ``*/ns`` :ref:`variant <app_boards_names>` if they are used).
 
 When CMSE is used, the firmware is split in accordance with the security by separation architecture principle to better protect sensitive assets and code.
 With CMSE, the firmware is stored in one of two security environments (flash partitions), either Secure Processing Environment (SPE) or Non-Secure Processing Environment (NSPE).

doc/nrf/libraries/security/nrf_security/index.rst

@@ -4,7 +4,8 @@
 nRF Security
 ############
 
-The nRF Security subsystem (nrf_security) provides an integration between Mbed TLS and software libraries that provide hardware-accelerated cryptographic functionality on selected Nordic Semiconductor SoCs as well as alternate software-based implementations of the Mbed TLS APIs.
+The nRF Security subsystem (nrf_security) provides an integration between `Mbed TLS`_ and software libraries that provide hardware-accelerated cryptographic functionality on selected Nordic Semiconductor SoCs as well as alternate software-based implementations of the Mbed TLS APIs.
+These libraries include the binary versions of accelerated cryptographic libraries listed in :ref:`nrfxlib:crypto`, and the open source Mbed TLS implementation in |NCS| located in `sdk-mbedtls`_.
 The subsystem includes a PSA driver abstraction layer to enable both hardware-accelerated and software-based implementation at the same time.
 
 The nRF Security subsystem can interface with the :ref:`nrf_cc3xx_mbedcrypto_readme`.

doc/nrf/protocols/matter/end_product/security.rst

@@ -25,7 +25,7 @@ Depending on the networking backend, the |NCS| Matter samples currently use the
  Support for PSA Cryptography API for the Wi-Fi backend is planned for a future release.
 
 Both APIs are integrated in the :ref:`nrf_security` library.
-This library offers various configuration possibilities and backends that can be employed to implement :ref:`cryptographic operations <cryptographic_operations_in_ncs>`.
+This library offers various configuration possibilities and backends that can be employed to implement :ref:`cryptographic operations <security_index>`.
 You can find an overview of the cryptography layer configuration supported for each |NCS| Matter-enabled platform in the :ref:`matter_platforms_security_support` section.
 
 Trusted storage

doc/nrf/releases_and_maturity/releases/release-notes-changelog.rst

@@ -1084,3 +1084,5 @@ Documentation
 
  * The :ref:`ug_nrf70_developing_debugging` page with the new snippets added for the nRF70 driver debug and WPA supplicant debug logs.
  * The :ref:`programming_params` section on the :ref:`programming` page with information about readback protection moved from the :ref:`ug_nrf5340_building` page.
+ * The :ref:`security` page with a table that provides an overview of the available general security features.
+ This table replaces the subpage that was previously describing these features in more detail and was duplicating information available in other sections.

doc/nrf/security.rst

@@ -1,17 +1,70 @@
+.. _security:
 .. _security_index:
 
 Security
 ########
 
-The |NCS| provides a variety of security features.
-Make sure to check the :ref:`overview of available options <security>` and consider enabling :ref:`access port protection mechanism <app_approtect>`.
+This section provides an overview of core security features available in Nordic Semiconductor products.
+The features are made available either as built-ins in modules, drivers, and subsystems, or are shown in samples or applications in |NCS|.
 
-If you are working with nRF53 Series or nRF91 Series devices, use :ref:`Trusted Firmware-M <ug_tfm>` to increase the security of your end product.
+The following table lists the available general security features.
+Some of them are documented in detail in other parts of this documentation, while others are documented in the subpages in this section.
+
+ .. list-table::
+ :header-rows: 1
+
+ * - Security feature
+ - Description
+ - Configuration
+ - Related components
+ * - Access port protection (AP-Protect)
+ - When enabled, this mechanism blocks the debugger from read and write access to all CPU registers and memory-mapped addresses.
+ - See :ref:`app_approtect`.
+ - ---
+ * - Bootloader and Device Firmware Upgrade (DFU)
+ - The |NCS| supports :ref:`MCUboot and nRF Secure Immutable Bootloader (NSIB) <ug_bootloader_mcuboot_nsib>` for secure boot, and DFU procedures using MCUboot and :ref:`Software Updates for Internet of Things (SUIT) <ug_nrf54h20_suit_dfu>`.
+ - See :ref:`app_bootloaders`.
+ - | - :ref:`nRF Secure Immutable Bootloader (NSIB) <bootloader>`
+ | - :ref:`DFU libraries <lib_dfu>`
+ | - :ref:`Software Updates for Internet of Things (SUIT) <ug_nrf54h20_suit_dfu>`
+ | - :doc:`MCUboot <mcuboot:design>`
+ * - Processing environments (CMSE)
+ - The :ref:`boards supported by the SDK <app_boards_names>` distinguish entries according to which CPU is to be targeted (for multi-core SoCs) and whether Cortex-M Security Extensions (CMSE) are used or not.
+ When CMSE is used, the firmware is split in accordance with the security by separation architecture principle to better protect sensitive assets and code.
+ In the |NCS|, the CMSE support is implemented using Trusted Firmware-M (TF-M).
+ - See :ref:`app_boards_spe_nspe`.
+ - All samples and applications that support the ``*/ns`` :ref:`variant <app_boards_names>` of the boards.
+ * - Trusted Firmware-M (TF-M)
+ - TF-M is the reference implementation of `Platform Security Architecture (PSA)`_.
+ On nRF5340 and nRF91 Series devices, TF-M is used to configure and boot an application with :ref:`CMSE enabled <app_boards_spe_nspe_cpuapp_ns>`.
+ - See :ref:`ug_tfm`.
+ - | - :ref:`tfm_samples`
+ | - :ref:`cryptography samples <crypto_samples>`
+ | - :ref:`https_client` sample
+ | - :ref:`openthread_samples`
+ | - :ref:`TF-M integration samples <zephyr:tfm_integration-samples>` in Zephyr
+ * - Cryptographic operations (:ref:`nrf_security`)
+ - The :ref:`nrf_security` library acts as an orchestrator for the different cryptographic libraries available in the system.
+ HW accelerated libraries are prioritized over SW libraries when both are enabled.
+ - :kconfig:option:`CONFIG_NRF_SECURITY` (:ref:`more info<nrf_security_config>`)
+ - | - :ref:`nrf_security` library with :ref:`nrf_security_drivers`
+ | - :ref:`nrfxlib:crypto`
+ | - :ref:`crypto_samples`
+ * - Trusted storage
+ - The trusted storage library enables you to provide features like integrity, confidentiality and authenticity of the stored data, without using the TF-M Platform Root of Trust (PRoT).
+ - See :ref:`trusted_storage_in_ncs` and :ref:`trusted storage library configuration <trusted_storage_configuration>`.
+ - :ref:`trusted_storage_readme` library
+ * - Hardware unique key (HUK)
+ - Nordic Semiconductor devices featuring the CryptoCell cryptographic accelerator allow the usage of a hardware unique key (HUK) for key derivation.
+ A HUK is a unique symmetric cryptographic key which is loaded in special hardware registers allowing the application to use the key by reference, without any access to the key material.
+ - :kconfig:option:`CONFIG_HW_UNIQUE_KEY`
+ - | - :ref:`HUK library <lib_hw_unique_key>`
+ | - :ref:`HUK sample <hw_unique_key_usage>`
 
 .. toctree::
  :maxdepth: 2
  :caption: Subpages:
 
- security/security
- security/tfm
  security/ap_protect
+ security/tfm
+ security/trusted_storage