AES GCM Sample Not Working

I'm attempting to build the aes_gcm sample using NCS 2.4.2 for a custom board with an nRF9160. However, I can just build the project for the nrf9160dk_nrf9160_ns target since no peripherals are required. The project builds properly as is and runs, but the operation to generate a random key (psa_generate_key) fails with error PSA_ERROR_NOT_SUPPORTED. This makes sense since I've read in other support threads that having CONFIG_TFM_PROFILE_TYPE_MINIMAL or CONFIG_TFM_PROFILE_TYPE_NOT_SET set in prj.conf essentially gets the project to build with tfm but crypto operations will be significantly limited or unavailable. When I attempt to set CONFIG_TFM_PROFILE_TYPE_MEDIUM, nothing is printed out to the console. Any suggestions as to what could be going wrong?

  • Ok I'll try that. Can you give me an example of disabling crypto services? It's confusing to me which config variables actually enable/disable various crypto operations

  • I have experimented with this but have been unable to reduce it to the required size. Below are the configurations I tried, but the FLASH footprint was still around 66kB.

    CONFIG_TFM_LOG_LEVEL_SILENCE=y
    CONFIG_TFM_SECURE_UART=n
    
    CONFIG_PSA_WANT_ALG_TLS12_PSK_TO_MS=n
    CONFIG_TFM_CRYPTO_KEY_DERIVATION_MODULE_ENABLED=n
    CONFIG_TFM_CMAKE_BUILD_TYPE_MINSIZEREL=y
    CONFIG_TFM_EXCEPTION_INFO_DUMP=n
    CONFIG_TFM_NRF_PROVISIONING=n
    
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CBC_NO_PADDING_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CBC_PKCS7_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CCM_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CHACHA20_POLY1305_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CMAC_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_CTR_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_DETERMINISTIC_ECDSA_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_ECB_NO_PADDING_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_ECDH_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_ECDSA_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_GCM_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_RSA_OAEP_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_RSA_PKCS1V15_CRYPT_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_RSA_PKCS1V15_SIGN_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_RSA_PSS_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_SHA_224_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_SHA_256_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_SHA_384_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_SHA_512_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_TLS12_PRF_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_TLS12_PSK_TO_MS_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_STREAM_CIPHER_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ECC_MONTGOMERY_255_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ECC_SECP_R1_224_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ECC_SECP_R1_256_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ECC_SECP_R1_384_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_HKDF_OBERON=n
    CONFIG_PSA_CRYPTO_DRIVER_ALG_HMAC_OBERON=n

    $ arm-zephyr-eabi-size build/tfm/bin/tfm_s.elf
     text    data     bss     dec     hex filename
      66044     392   52100  118536   1cf08 build/tfm/bin/tfm_s.elf

    I have asked the developers if there are additional optimizations we can do and I'm awaiting their feedback.

  • Hi,

    Sorry for the delayed response. Unfortunately, even with help from R&D, I haven't been able to reduce the flash footprint of the TF-M image enough to fit into your existing SPM partition. That said, since the TF-M and app binaries are uploaded as a single image, you should be able to allocate more flash to the TF-M without affecting the memory layout of the MCUboot slots.

  • That's great news Vidar! I have one more question so that I can understand how everything works correctly. My understanding is that MCUBoot is the first application run since it's at memory address 0x0. Then, MCUBoot boots into TF-M which prepares secure peripherals if they're enabled and secure regions of memory. Then, TF-M boots into my application, and any time my application makes a crypto call, the context switches to the TF-M application so that it can perform the crypto operation securely. Is that all correct? And because MCUBoot only jumps into TF-M and not my application, the main thing that matters in my pm_static.yml file is that TF-M is placed at the same address that SPM was?

Related