nRF54L15 + SRAM + Crypto questions

[SubuMuthu]

Hello,

Platform: nRF54L15, SDK 2.9, VS Code 

Our application is Matter + BLE (like NUS) based door lock application.  A BLE  custom service (adapted from NUS)  is used to exchange info in parallel with Matter. We are not encrypting the BLE transmissions and  the BLE security level is set to  BT_SECURITY_L1.  The reason is due to product requirement that our customers do not want to press the "pairing request" notification in the mobile iOS/Android apps. Setting bonding will eliminate this but Matter standard does not allow bonding. Long story to short, we have taken the approach of encrypting the BLE payload.

For encrypting the payload, we are using the standard ECDH + certificate based authentication to derive a key plus authentication:

1. After BLE is connected  (first time only),  the lock and mobile uses ECDH  to derive a AES-128 symmetric key, which will be used for encryption and decryption of payload.
2. Certificates are exchanged to authenticate further and connection is terminated if certificates are not validated. we plan to use ECDSA which will be next step.
3. Key is stored internally and key derivation is not repeated for subsequent connections
4. We used PSA CRYPTO libraries.
5. Since Matter uses PSA Crypto, we did not include any additional configurations in prj.conf. 

Question #1: is there a solution that will allow us to use encryption that comes with BLE stack than we writing the custom encryption (we would prefer BT_SECURITY_L4) but without the iPhone and Android pairing request notifications?I do not believe one exists but we want to ask Nordic to rule this option out.

Q2: When we look look at the ram_report, the SRAM  needed for our Crypto application is very small - it is the space needed for variables. It looks like MBEDtls library did not take additional space. Does it look alright? From our reading,  the MBEDtls should be a memory hog and should consume large memory while we are not seeing an increase in SRAM usage.. This is the reason for asking this question.

Q3. We tried  TF-M (/ns builds),  however, we are running out of SRAM. Without TF-M, the SRM usage comes to 220KB. When we try to build with /ns, the build complains that region `RAM' overflowed by 4076 bytes.  The TFM configuration is as follows (adapted from DK).

tfm_sram:

address: 0x20000000

inside:

- sram_secure

placement:

after:

- start

region: sram_primary

size: 0xF000

sram_primary:

address: 0x2000F000

region: sram_primary

size: 0x31000

According to the above PM, the tfm takes up only about 8K RAM and we have 30K left. The documentation is sparse so please  help to achieve TFM.

Q4.   We would like to store the resulting AES-128 bit asymmetric key in the KMU. It is little bit confusing from  the readings if it will be possible to store the key in the KMU without TF-M as the documentation is sparse.  Assuming that we won't be able to do TF-M, please provide an example, or provide the necessary guidelines for storing the keys and also the certificate in the KMU.

This post says that keys are stored in ITS not in KMU:  Using PSA function to persist key in kmu AND later restore it for AES encryption 

This post says (1 year old) that KMU has limited functionality:  Usage of KMU and CC3XX drivers It is not possible to change the Keys in a slot. Since it is one year old and nRF54L15 is new, is it applicable?

Thanks.

Subu

Auto Copied

[Amanda Hsieh]

Hi, 

Setting bonding will eliminate this but Matter standard does not allow bonding.

Using CONFIG_BT_PRIVACY makes it non-compliant with the Matter specification, as it will make the device support Random Private Address. The Matter spec requires using static random address for the Matter BLE service advertising purpose and Random Private Address cannot be used. The address has to be rotated on every reboot.

However, this requirement is only for Matter BLE service purposes, so one workaround is to introduce a second Bluetooth identity for the non-Matter services. One of our developers has implemented this in the following commit: https://github.com/nrfconnect/sdk-connectedhomeip/commit/5ae63841a525579afce2c6bb7abcf33692b07a4a.

These changes make the BLEManager work in the following way:

• If bonding is not enabled, a single Bluetooth ID will be used, and it will initialize a static random address before enabling the Bluetooth stack. If this is not initialized before the stack is enabled, it will configure Bluetooth ID itself and assign the default configuration to it, which we need to avoid,
• If bonding is enabled, two Bluetooth IDs will be used. One is used for bonding and the other for Matter. We first have to initialize the Bluetooth stack to recover the persisted bonding configuration (encryption keys, etc.), and then we initialize a static address for the second Bluetooth ID.

You can see the changes that are required in the application here: https://github.com/nrfconnect/sdk-nrf/commit/f84125d62d76fe3dba9b5ae019eb1e66956f6160. To summarize, this Matter implementation allows to enable bonding, and it is necessary to set CONFIG_BT_ID_MAX=2 and enable CONFIG_BT_EXT_ADV on both the application and network cores.

Question #1: is there a solution that will allow us to use encryption that comes with BLE stack than we writing the custom encryption (we would prefer BT_SECURITY_L4) but without the iPhone and Android pairing request notifications?I do not believe one exists but we want to ask Nordic to rule this option out.

Unfortunately, there is no standard BLE security solution that provides encryption without triggering pairing notifications on iOS/Android. Nordic does not offer a built-in solution to avoid the pairing prompts while using BT_SECURITY_L4.

Q2: When we look look at the ram_report, the SRAM  needed for our Crypto application is very small - it is the space needed for variables. It looks like MBEDtls library did not take additional space. Does it look alright? From our reading,  the MBEDtls should be a memory hog and should consume large memory while we are not seeing an increase in SRAM usage.. This is the reason for asking this question.

The small SRAM usage you're seeing for crypto operations is expected when using PSA Crypto APIs. PSA Crypto leverages hardware acceleration provided by the CryptoCell on Nordic devices, which offloads much of the cryptographic processing from the main CPU. This results in lower SRAM usage compared to a pure software implementation like mbedTLS. Your observation is correct and not a cause for concern.

Please be aware that Mbed TLS legacy crypto toolbox APIs are marked as deprecated in the nRF Connect SDK version 2.8.0, and will be removed in a future version. See the Legacy crypto support. 

Q3. We tried  TF-M (/ns builds),  however, we are running out of SRAM. Without TF-M, the SRM usage comes to 220KB. When we try to build with /ns, the build complains that region `RAM' overflowed by 4076 bytes. 

I think you adapted from pm_static_nrf54l15dk_nrf54l15_cpuapp_ns.yml, then the SRAM layout would show like this

There seems to be insufficient space for your application. You can also look at the suggestions under Memory footprint optimization or Check if you can reduce the secure partition size (tfm_sram) without compromising the security features you need. 

Q4.   We would like to store the resulting AES-128 bit asymmetric key in the KMU. It is little bit confusing from  the readings if it will be possible to store the key in the KMU without TF-M as the documentation is sparse.  Assuming that we won't be able to do TF-M, please provide an example, or provide the necessary guidelines for storing the keys and also the certificate in the KMU.

See nRF54L Series cryptography.

Regards,
Amanda H.