Crypto operations to generate key pair when TFM profile is set to minimal.

[mackz]

Hi, I am using NRF connect sdk 2.6.1 and I am wondering what is the best way to run crypto operations when using TFM profile type minimal and building for nrf9160_ns. TFM_PROFILE_TYPE_NOT_SET takes up too much space but it seems there is no way to generate keys pair without it.

https://docs.nordicsemi.com/bundle/ncs-2.3.0/page/tfm/technical_references/design_docs/profiles/tfm_profile_small.html

This says that the minimal profile supports:
Symmetric cipher only
Cipher suite for symmetric-key algorithms based protocols, such as cipher suites defined in TLS pre-shared key (TLS-PSK) [1].
    Advanced Encryption Standard (AES) as symmetric crypto algorithm
    SHA256 as Hash function
    HMAC as Message Authentication Code algorithm


while the full profile supports:
        Support both symmetric ciphers and asymmetric ciphers
        Asymmetric key based cipher suites defined in TLS 1.2 [5] to support direct secure connection to major CSPs, including
                Authenticated Encryption with Associated Data (AEAD) algorithm
                Asymmetric key algorithm based signature and verification
                Public-key cryptography based key exchange
                Hash function
                HMAC for default Pseudorandom Function (PRF)
        Asymmetric digital signature and verification for Initial Attestation Token (IAT)
        Asymmetric algorithms for firmware image signature verification
        Key derivation


I have tried to generate the key pair using only mbedtls library but it seems like there is a lot missing in the nrf implementation. I am not able to use entropy at all, when i enable it with CONFIG_MBEDTLS_ENTROPY_C=y
i get:

warning: MBEDTLS_ENTROPY_C (defined at
ncs/v2.6.1/nrf/subsys/net/openthread/Kconfig.defconfig:138,
ncs/v2.6.1/nrf/subsys/nrf_security/Kconfig.legacy:350) was assigned the value 'y' but
got the value 'n'. Check these unsatisfied dependencies: (NET_L2_OPENTHREAD ||
(!MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG && MBEDTLS_LEGACY_CRYPTO_C && NRF_SECURITY)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MBEDTLS_ENTROPY_C and/or look up
MBEDTLS_ENTROPY_C in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

and that makes it impossible to use this:
github.com/.../gen_key.c
Is there any other recommended way to do it or samples that i could look at?
Or is there any sample that describes a way to get a minimal working example with the profile set to NOT_SET?

[dejans]

Hi,

Small and full TF-M profiles are not directly supported in NCS. Only minimal and configurable (full) profiles are mentioned in the documentation, first as supported in NCS and second as experimental. You can look at TF-M support in NCS and minimal TF-M configuration. There are also TF-M samples, cryptography samples and TF-M integration samples from Zephyr. Additionally, you can look at supported TF-M profiles and TF-M services. 

Best regards,
Dejan

[mackz]

Yes i meant minimal and full. I am using minimal but i feel like there is no way to get something inbetween not being able to use TFM for anything and it taking up all of the memory for the application. So my questions stands:
Is there any other recommended way to do it or samples that i could look at?
Or is there any sample that describes a way to get a minimal working example with the profile set to NOT_SET?

[dejans]

Hi,

Can you show your project configuration?

Best regards,
Dejan

[mackz]

#PSA PROTECTED STORAGE
CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_CMAKE_BUILD_TYPE_MINSIZEREL=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=n
CONFIG_TFM_PROFILE_TYPE_MINIMAL=y
CONFIG_TFM_SECURE_UART0=y
CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000

#CRYPTO 
CONFIG_NRF_SECURITY=y
CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=16384
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_WANT_AES_KEY_SIZE_128=y
CONFIG_PSA_WANT_KEY_TYPE_AES=y
CONFIG_PSA_WANT_ALG_ECB_NO_PADDING=y

This is what i have related to tfm and crypto

[dejans]

Hi,

Have you tried to use configurable build with Kconfig options shown below? 

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_PROFILE_TYPE_MINIMAL=n

Best regards,
Dejan

[pauleffect]

The guy said "i feel like there is no way to get something inbetween not being able to use TFM for anything and it taking up all of the memory for the application."

Which implies you either go the full route, and that takes up 88 kilobytes of ram out of a measly 256. For minimal functionality - such as, you know, generating 16 bytes.

Is there ANY way of using hardware encryption WITHOUT sacrificing one third of the available ram?

[pauleffect]

did you manage to find a solution?

[dejans]

Hi pauleffect ,

Documentation specifies supported TF-M profiles. NCS documentation lists supported TF-M services and provides information how to configure TF-M build. More information can be found in configurable build.

Best regards,
Dejan

[pauleffect]

The documentation unfortunately doesn't clarify the core issue.

I haven't been able to use hardware-accelerated random number generation or hardware AES encryption because of RAM constraints. Neither of these operations should require dozens of kilobytes of RAM.

As it stands, the choices are:

• TFM_PROFILE_TYPE_NOT_SET: Lose ~88 KB of RAM, get full TF-M functionality
• TFM_PROFILE_TYPE_MINIMAL: Lose ~32 KB of RAM, get effectively nothing usable (no crypto operations work)

There's no middle ground - no way to get basic hardware crypto (AES, RNG) without sacrificing a third of the nRF9160's 256 KB RAM.

I ended up implementing software AES as a workaround. Not even Oberon - a custom AES implementation, because the nRF Security backend also appears to require the full TF-M RAM allocation to function.

The project works now, but I have serious doubts about getting it through compliance/certification without hardware-backed crypto.

[dejans]

Hi,

Configurable build is full TF-M implementation, but it should be possible to enable/disable specific TF-M features and services. 
"To configure the features of the TF-M secure image, you must choose which TF-M partitions and which secure services to include in the build."
There are Kconfig options which can be used for enabling/disabling specific services. You could try to disable those services which are not needed in your build.

Best regards,
Dejan

[mackz]

Hi sorry for the late response but i also went with the software AES (for now), i could not find any other way to get it to work without wasting ram memory. 

[mackz]

But if i use TFM_PROFILE_TYPE_MINIMAL and then set:

CONFIG_TFM_PARTITION_PROTECTED_STORAGE=y
CONFIG_TFM_PARTITION_CRYPTO=y

i get:

warning: TFM_PARTITION_PROTECTED_STORAGE (defined at /home/marcus/ncs/v2.6.1/nrf/modules/trusted-
firmware-m/Kconfig.tfm.defconfig:69, modules/trusted-firmware-m/Kconfig.tfm.partitions:8,
modules/trusted-firmware-m/Kconfig.tfm.partitions:8) was assigned the value 'y' but got the value
'n'. See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_TFM_PARTITION_PROTECTED_STORAGE
and/or look up TFM_PARTITION_PROTECTED_STORAGE in the menuconfig/guiconfig interface. The
Application Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices
sections of the manual might be helpful too.

and this:

psa_status_t status = psa_crypto_init();
psa_set_key_usage_flags(&key_attributes, PSA_KEY_USAGE_ENCRYPT);
psa_set_key_algorithm(&key_attributes, PSA_ALG_ECB_NO_PADDING);  
psa_set_key_type(&key_attributes, PSA_KEY_TYPE_AES);
psa_set_key_bits(&key_attributes, 16 * 8); 
status = psa_import_key(&key_attributes, p_key, 16, &key_id);
    if (status != PSA_SUCCESS) {
        LOG_ERR("Failed to import key: %d", status);
        return;
    }

still returns -134



so what is it that is possible to configure?