nRF9160, SLM Firmware behaves incorrectly after activating Native TLS (critical problems)

Question

Hi, We managed to build and flash SLM (SDK 2.1.2) with Native TLS. To be able to download about 5Kb of data at one time (from AWS broker). But not everything works fine, we have several critical problems with this build: 1) First, We can't check certificates, the same we did it before. 
 P reviously, I used commands like this (321, is our internal secure tag): - AT%CMNG=1,321,0 (For check exists the CA certificate); - AT%CMNG=1,321,1 (For check exists the Client certificate); - AT%CMNG=1,321,2 (For check exists the Private Key); But after moving to Native TLC, and generating the new certificates (via commands like the AT#XCMNG=0,321,0...), We see other certificates by AT%CMNG=1 command: %CMNG: 3210,0," AD6FB002E6B34C0559FA8F93A3794F F12C4E3F119BD77290C52525123FB9 EA74" %CMNG: 3211,0," EA89F71E2A945D88A7A71C3C35D2F3 BA5466B0ACEC750270134F511FB0CB 4143" %CMNG: 3212,0," EB569D288E10B1D9D5B1BD45642AD4 B8D063E0C48584A6C3A7A700987D67 1B68" 
 Can I use them to verify the CA, Client and private key? - AT%CMNG=1,3210,0 (For CA); - AT%CMNG=1,3211,0 (For Client); - AT%CMNG=1,3212,0 (For check exist the Private Key). 2) Second: We lost access to nRF Cloud. All commands for working with CMNG had to be changed (was AT%CMNG became AT#XCMNG), and it helped for access to AWS broker, but not to nRF Cloud. Our previous certificates don't work more (with Native TLS). I tried to reinstall them using the #XCMNG AT command, but that didn't work. AT commands and answers look fine. Maybe this is due to the generation and installation of a private key, we use: AT%KEYGEN=16842753,2,0
 
 But after using the AT%KEYGEN=16842753,2,0
, followed by saving the CA/Client certificates, we have the next results (every install certificate command returned OK): [7/12 17:55:04:025] %CMNG: 16842753,2,"7494C435C484599577AB9B04E85DD594C5B5C9676750CA6DA17284E99A93B9C7" [7/12 17:55:04:025] %CMNG: 168427530,0,"AD6FB002E6B34C0559FA8F93A3794FF12C4E3F119BD77290C52525123FB9EA74" [7/12 17:55:04:025] %CMNG: 168427531,0,"D12494EF17B635B10A7511A513CB37B3101D58008ADE0D4BAA381D85A63DA675" 
 But if we tried to connect to nRF Cloud nothing happened. We didn't have some ERROR or Event about the nRF Cloud connection. We received the OK after about 900ms and CSCON: 0 after 6 seconds. What are we doing wrong with nRF Cloud access now? Is it still because of the AT%KEYGEN=16842753,2,0 AT command? 
 3) Third: Something happening with MQTT Disconnect: After AT#XMQTTCON=0 we received a weird answer (
) and nRF Reset. 
 AT#XMQTTCON=0 Ready

Øyvind · Accepted Answer

Stas Jis said: I hope you and your family are doing well. 
 Thank you! 
 Stas Jis said: Into the "nrf9160dk_nrf9160_ns.conf" file we manage UART_0 and UART_2 for work with internal either external MCU. 
 Does this apply to you custom HW as well? 
 Stas Jis said: how I'm supposed to work with UART1 
 UART1 is shared by modem trace and TF-M logs. In order to receive TF-M logs you must disable the modem trace again. In prj.conf you can ensure that you have the following settings: CONFIG_NRF_MODEM_LIB_TRACE=n
CONFIG_TFM_SECURE_UART1=y
CONFIG_TFM_LOG_LEVEL_SILENCE=n
CONFIG_TFM_SPM_LOG_LEVEL_DEBUG=y
CONFIG_TFM_EXCEPTION_INFO_DUMP=y
CONFIG_THREAD_NAME=y
CONFIG_THREAD_ANALYZER=y
CONFIG_TFM_HALT_ON_CORE_PANIC=y 
 Are you using the nRF9160DK during your tests? If so, you can use any terminal to open VCOM2 of DK board with baudrate 115200. From the nRF9160 DK Virtual COM port documentation: 
 
 The virtual COM ports are the following:

VCOM0 – Connected to nRF9160 (default)

VCOM1 – Connected to nRF52840 (nonconfigurable)

VCOM2 – Connected to nRF9160 (default)

In the VS Code extension your board should be visible and you should be able to connect to it. 
 
 In regards to : 
 Stas Jis said: We commented out the slm_tls_unloadcrdl the inside mqtt_thread_fn() function and recheck in with 9160DK board. And for nrf9160DK now connection/disconnection through a broker looks correct. nRF no longer reboots, and AT commands continue to work after being disconnected from the broker. 
 What side effects will we get if we include these changes in our firmware? 
 Our developers point out that the credentials seem to be unloaded twice. In the following .diff file they have added "graceful unloading of credentials" (missing from our first .diff file). This means e.g. #if defined(CONFIG_SLM_NATIVE_TLS)
 (void)slm_tls_unloadcrdl(ctx.sec_tag);
#endif

 should be 
 #if defined(CONFIG_SLM_NATIVE_TLS)
	if (ctx.sec_tag != INVALID_SEC_TAG) {
 (void)slm_tls_unloadcrdl(ctx.sec_tag);
 ctx.sec_tag = INVALID_SEC_TAG;
	}
#endif

Fullscreen 
 native_tls_mqtt_aws_unload.diff 
 Download 
 
 diff --git a/applications/serial_lte_modem/overlay-native_tls.conf b/applications/serial_lte_modem/overlay-native_tls.conf
index c312b9bb2..4004d8007 100644
--- a/applications/serial_lte_modem/overlay-native_tls.conf
+++ b/applications/serial_lte_modem/overlay-native_tls.conf
@@ -24,7 +24,7 @@ CONFIG_MBEDTLS_ENABLE_HEAP=y
 # and CONFIG_MBEDTLS_HEAP_SIZE to 36864
 CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN=5120
 CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN=4096
-CONFIG_MBEDTLS_HEAP_SIZE=36864
+CONFIG_MBEDTLS_HEAP_SIZE=38656
 CONFIG_MBEDTLS_SSL_SERVER_NAME_INDICATION=y
 #Cipher Suite disable
 CONFIG_MBEDTLS_CTR_DRBG_C=n
diff --git a/applications/serial_lte_modem/src/mqtt_c/slm_at_mqtt.c b/applications/serial_lte_modem/src/mqtt_c/slm_at_mqtt.c
index aa7c91f3d..e83b9fbea 100644
--- a/applications/serial_lte_modem/src/mqtt_c/slm_at_mqtt.c
+++ b/applications/serial_lte_modem/src/mqtt_c/slm_at_mqtt.c
@@ -261,6 +261,13 @@ static void mqtt_thread_fn(void *arg1, void *arg2, void *arg3)
 }
 }
 
+#if defined(CONFIG_SLM_NATIVE_TLS)
+	if (ctx.sec_tag != INVALID_SEC_TAG) {
+ (void)slm_tls_unloadcrdl(ctx.sec_tag);
+ ctx.sec_tag = INVALID_SEC_TAG;
+	}
+#endif
+
 LOG_INF("MQTT thread terminated");
 }
 
@@ -328,6 +335,9 @@ static void client_init(void)
 struct mqtt_sec_config *tls_config;
 
 tls_config = &(client.transport).tls.config;
+#if defined(CONFIG_SLM_NATIVE_TLS)
+ tls_config->set_native_tls = true;
+#endif
 tls_config->peer_verify = TLS_PEER_VERIFY_REQUIRED;
 tls_config->cipher_list = NULL;
 tls_config->cipher_count = 0;
@@ -359,9 +369,25 @@ static int do_mqtt_connect(void)
 
 /* Connect to MQTT broker */
 client_init();
+
+#if defined(CONFIG_SLM_NATIVE_TLS)
+	err = slm_tls_loadcrdl(ctx.sec_tag);
+	if (err < 0) {
+ LOG_ERR("Fail to load credential: %d", err);
+ return -EAGAIN;
+	}
+#endif
+
 err = mqtt_connect(&client);
 if (err != 0) {
 LOG_ERR("ERROR: mqtt_connect %d", err);
+#if defined(CONFIG_SLM_NATIVE_TLS)
+ if (ctx.sec_tag != INVALID_SEC_TAG) {
+ (void)slm_tls_unloadcrdl(ctx.sec_tag);
+ ctx.sec_tag = INVALID_SEC_TAG;
+ }
+#endif
+
 return err;
 }
 
@@ -388,6 +414,13 @@ static int do_mqtt_disconnect(void)
 return err;
 }
 
+#if defined(CONFIG_SLM_NATIVE_TLS)
+	if (ctx.sec_tag != INVALID_SEC_TAG) {
+ (void)slm_tls_unloadcrdl(ctx.sec_tag);
+ ctx.sec_tag = INVALID_SEC_TAG;
+	}
+#endif
+
 if (k_thread_join(&mqtt_thread, K_SECONDS(CONFIG_MQTT_KEEPALIVE)) != 0) {
 LOG_WRN("Wait for thread terminate failed");
 }
diff --git a/applications/serial_lte_modem/src/slm_native_tls.c b/applications/serial_lte_modem/src/slm_native_tls.c
index b14a68d2f..3dc7a5573 100644
--- a/applications/serial_lte_modem/src/slm_native_tls.c
+++ b/applications/serial_lte_modem/src/slm_native_tls.c
@@ -10,7 +10,7 @@
 LOG_MODULE_REGISTER(slm_tls, CONFIG_SLM_LOG_LEVEL);
 
 /* max buffer length to load credential */
-#define MAX_CRDL_LEN 4096
+#define MAX_CRDL_LEN 4352
 
 /* pointer to credential buffer */
 static uint8_t *crdl;

nRF9160, SLM Firmware behaves incorrectly after activating Native TLS (critical problems)

Top Replies