doc/../device_guide/nrf54l: added KMU basics info page

Added page for provide bare-minimum info on KMU key provisioning
knowledge, terms, good practices  and limitation.

Signed-off-by: Andrzej Puzdrowski <[email protected]>

doc/nrf/app_dev/device_guides/nrf54l/index.rst

@@ -69,4 +69,5 @@ Ensure to check the revision of your nRF54L15 device to see if it is supported:
    building_nrf54l
    nrf54l_signing_with_payload
    fota_update
+   kmu_basics
    kmu_provision

doc/nrf/app_dev/device_guides/nrf54l/kmu_basics.rst

@@ -0,0 +1,50 @@
+.. _:
+
+KMU Key provisioning – basics, good practices and limitations
+#############################################################
+
+. contents::
+   :local:
+   :depth: 2
+
+nRF54l devices are equipped with KMU which supports storing keys secretly and securely.
+This is valuable even for public keys as KMU is able to push a key directly to Cracken RAM, and even in case a key is supposed to be transferred through addressable RAM it limits possibility for attacking at the key secret a loot.
+Therefore, whenever possible KMU usage is recommended for managing secrets.
+
+Revocable keys
+**************
+
+keys can be invalidating for further use. RPOLICY for such key is ‘revoked’.
+For some technical solutions a few keys of the same kind might be provisioned – these are generations (0, 1, 2 …) of the same key.
+If a given moment only one generation should be used. If given key generation is compromised – it shall be removed from being used by revocation.
+It is technical detail of given technical solution on how revocation scheme works, however it is recommended to provision one of generation as not revocable (‘locked’)
+to make impossible DoS on availability of the key for given technical solution (if desirable).
+
+Locked keys
+***********
+
+keys which are supposed to be permanently available for usage. RPOLICY for such key is ‘locked’.
+
+
+Provisioning keys for the bootloader
+************************************
+
+The bootloader supports usage of a few key generation for an image verification (up to 3 for nRF54lxx SoCs). All key generations should be provisioned to the device in order to protect against malicious provisioning by an attacker.
+Key generation count used for the application verification by MCUboot can be configured via CONFIG_BOOT_SIGNATURE_KMU_SLOTS.
+
+Limitation of not using TEE (TF-M)
+**********************************
+
+KMU accesses is limited to the secure code. So when SoC runs such application it has some control over KMU.
+A provisioned key couldn’t been overwrite an the key content might be blocked against being used in run-time (`push block`) by unexpected routine.
+However the application could revoke a revocable key on nRF54l15/05/10:
+
+KMU keys are not protected against being revoked by the user application which is running in secure mode.
+Users should provision locked keys if they can't trust the application running in secure mode.
+This note is especially valid for applications which misses TEE setup - It is role of the user to consider security aspect of their application.
+In the end user might consider two options:
+
+1. Support key generations with revokable keys. Upside, the application can revoke a key generation if the private key is at risk (or lost).
+Downside, a malicious application could revoke the key.
+
+#.Support one locked key. Upside, cannot be deleted by application. Downside, no support for multiple generations of keys.