psa_generate_key failed! with Error: -134

[vipin das]

Hi nordic team, 

I am working on an application which uses crypto cell feature, wifi capability of nrf7002DK, mbedTLS etc. I proceeded my development after individually verifying each features on nrf7002dk (crypto cell, wifi, mbedTLS etc). 

My current problem is that, psa_generate_key() failed to generate key and returns error code of -134. This is happening only if I integrate my complete application(crypto cell, wifi, mbedtls etc). If I run crypto cell specific changes alone it works and if I run  along with wifi + mbedTLS changes it fails. I am not sure what causes this problem. 

Just sharing my prj.conf below. 

With below configuration crypto cell feature for private key generation is working as expected. 

#
#   Application project specific configuration
#
CONFIG_SOC_SERIES_NRF53X=y
CONFIG_SOC_NRF5340_CPUAPP_QKAA=y
# Target memory specific options
CONFIG_HW_UNIQUE_KEY=y
CONFIG_HW_UNIQUE_KEY_RANDOM=y
CONFIG_PM_SINGLE_IMAGE=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y
CONFIG_RESET_ON_FATAL_ERROR=y
CONFIG_REBOOT=y
CONFIG_NRF_SECURITY=y
CONFIG_FPU=y
CONFIG_FP_HARDABI=y
CONFIG_KERNEL_MEM_POOL=y
# System settings
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_NANO=n

# Enable nordic security backend and PSA APIs
CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_MBEDTLS_ENABLE_HEAP=y

CONFIG_TRUSTED_EXECUTION_SECURE=y
CONFIG_BUILD_WITH_TFM=n

# For hardware crypto accelerator
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y

# Memories
CONFIG_MAIN_STACK_SIZE=16384
# Below section is the primary contributor to SRAM and is currently
# tuned for performance, but this will be revisited in the future.
CONFIG_HEAP_MEM_POOL_SIZE=153600
CONFIG_MBEDTLS_HEAP_SIZE=120000

# Enable logging using RTT and UART
CONFIG_CONSOLE=y
CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BUFFER_SIZE=15360

# General
CONFIG_POSIX_CLOCK=y
CONFIG_POSIX_MAX_FDS=8
CONFIG_HW_STACK_PROTECTION=y
CONFIG_HW_ID_LIBRARY_SOURCE_NET_MAC=y
CONFIG_DK_LIBRARY=y
CONFIG_PM=y

# Kernel options
CONFIG_ENTROPY_GENERATOR=y

# Memory support
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y

But when I add below configuration for enabling wifi & network, spa_generate_key fails with -134.

# WiFi driver 
CONFIG_WIFI=y
CONFIG_WIFI_NRF700X=y
# WPA supplicant
CONFIG_WPA_SUPP=y

# NET sockets
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y
CONFIG_NET_SOCKETS_POLL_MAX=8
CONFIG_NET_L2_ETHERNET=y
CONFIG_NET_IPV4=y
CONFIG_NET_TCP=y
CONFIG_NET_SOCKETS_OFFLOAD=n
CONFIG_NET_NATIVE=y
CONFIG_NET_DHCPV4=y
CONFIG_NET_CONTEXT_SNDTIMEO=y

CONFIG_NET_TCP_ISN_RFC6528=y
CONFIG_NET_MGMT_EVENT_INFO=y
CONFIG_NET_IF_UNICAST_IPV4_ADDR_COUNT=1
CONFIG_NET_MAX_CONTEXTS=5
CONFIG_NET_CONTEXT_SYNC_RECV=y

# Network address config
CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_NEED_IPV4=y
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.168.1.99"
CONFIG_NET_CONFIG_MY_IPV4_NETMASK="255.255.255.0"
CONFIG_NET_CONFIG_MY_IPV4_GW="192.168.1.1"

# Server IPV4/IPV6 address config
#Mainnet.Incubed
CONFIG_NET_CONFIG_PEER_IPV4_ADDR="167.86.94.248"

Can some one please tell me what should be the problem with key_generation and wifi network configuration. 

Thanks 

Vipin Das

[vipin das]

Hi Einar, 

Is there any other option, I can try to proceed with my current development. I have nrf5340dk and nrf7002dk with me. My final goal is to key derivation and management for message signing/verification operation and transmit the signed message to remote network. 

Is it possible to proceed without TF-M? Without TF-M is there any other option to derive key and store the generated key in crypto cell? 

What about using Legacy Nordic solution SPM? Can I use it in my current integration? 

Regards

Vipin Das 

[Einar Thorsrud]

Hi Vipin,

You don't need TF-M for using CryptoCell if you whole application runs in secure mode. That mean you are not utilizing security by separation, though. So if you are making a product where security is important I would try to avoid skipping that. Regarding SPM that is legacy as you write, and no longer present in nRF Connect SDK 2.3.0. It also supported a very limited feature set.

However, the real issue with combinding wpa_supplicant with the PSA crypto libraries is incompatible APIs, and this remains the same regardless if you use TF-M or not.

As the one of the main problems is combining the use of PSA Crypto and wpa_supplicatant and you will need both (unless you want to put together you own custom thing based partially on legacy APIs), I would try to keep the cryoto work or wifi_work in a separate project for now and combine later. If not, I suspect you will essentially be doing a similar work as we are currently doing in parallel, which doesn't seem efficient.

I will try to update you whenever we have something usable in a PR.

(Here is another thread with a similar issue where we gave essentially the same advice.)

[vipin das]

Thanks for the detailed information. I completely got your point and agree with you. 

We are focussing on developing secure product. But right now, we wanted to utilise the key derivation and management feature and try to communicate securely with remote server/devices. 

As I mentioned, we already have our crypto portion working and wifi portion working. Only the wpa_supplicant one is making the psa key derivation to fail. 

Let me ask you one thing, is there any way I can connect to wifi with disabling wpa_supplicant?. I mean wifi connect using part terminal etc. That is also fine for time being to progress my further development. 

Thanks 

Vipin Das

[Einar Thorsrud]

Hi Vipin,

The Wi-Fi stack depends on wpa_supplicant for other tasks as well (see Supplicant), so I think it will be difficult to do much useful - even with open networks - without wpa_supplicant. (You can do some things without it though, like scanning).

[vipin das]

Hi Einar, 

So it is not at all possible to have wifi connection without wpa_supplicant right.

In that case is there any other crypto api options I can use to generate key pairs other than  psa_generate_key() and store the private key securely in KMU. But those api shouldn't fail with wpa_supplicant. If you have any suggestions please share the information.

Regards

Vipin Das