nRF9160 with Microsoft Azure, x509 certificates and provisioning methods, TLS store write wear

Question

I am currently working on a project involving passing sensor data to Microsoft Azure. 
 I am looking at the sample application v1.4.99-dev1/nrf/samples/nrf9160/azure_iot_hub currently. 
 I just got v1.5.0 installed, had to delete and restart the install a few times (MacOS) due to incomplete/incomplete downloads/installs, but finally have a full install and will switch over to v1.5.0 as time permits. Download and install takes about 4 hours (each attempt). 
 I have been digging through the documentation and the forums for a bit and would like a little clarification on a few points. 
 Currently we use a Raspberry Pi to upload data to Azure, the Raspberry Pi is automatically provisioned by downloading an X509 certificate from a self developed PHP server that generates and signs device certificates with the CA that is registered with the Azure device provisioning service. Provisioning a Raspberry Pi is as easy as booting it with a special provisioning SD card and it automatically downloads it's unique device certificate and stores it locally in an EEPROM chip. 
 I am attempting to create a similar kind of auto provisioning system for the nRF9160 is it is time consuming to do this provisioning by hand. This has brought up a few questions. 
 1. From looking at the sample source I am under the impression that this uses the MQTT library. This also appears to use the TLS certificate store as the function "tls_credential_add" is called. Is it possible to use a certificate loaded into SRAM? As the certificate is quite a few bytes long this may not be exactly efficient. 
 2. I am planning on storing the certificates on an external SD card as they are downloaded from the automatic provisioning server, but ultimately they may need to be stored in the nRF9160's TLS certificate store. I am concerned about write wear on the EEPROM memory used for the certificate store, is there any concern? Has there been any testing as to what kind of endurance there is for this memory? I am sure it is somewhere in the nRF9160 datasheet but I have not been able to locate the information as of yet. I am always a little paranoid about write endurance on things like EEPROM, SD cards, and SSD memory devices since they will be out in the field where failure is a really bad thing. The above mentioned Raspberry Pi SD card root filesystem is setup in a read-only mode for this reason. 
 3. If the X509 certificate is stored in the TLS store, is it possible to read back, or compare it to what is stored on the SD card, if I go with using the SD card as the primary storage location for the X509 certificates I would like to rewrite the certificate stored in the TLS store on startup, but don't want to rewrite it if unnecessary to avoid wear on the EEPROM memory. Is there logic in the TLS writing logic that would compare what is in EEPROM and only erase/write bytes that have changes (to avoid wear)? I incorporate similar logic in the Raspberry Pi EEPROM writing logic. 
 4. I believe this is not a question of possibility, but development time, but I would like to add in the ability in this project for the nRF9160 to directly download the X509 certificates using HTTP (HTTPS). Concerning the HTTPS, does the server certificate or root CA need to be registered for an HTTPS connection to be established? Concern with this is the server's SSL certificate is renewed every 3 months. 
 5. This is outside of the scope of Azure, but I will need to store APN information (authentication included) for the SIM cards that will be used, the MVNO SIM cards that I have been using do not really cooperate with the automatic APN feature of the nRF9160 and therefore will be storing this information on the SD card anyway, so figured I might as well store the X509 certificates as well on the SD card. 
 6. In the event that Azure does not connect, an automatic download of a new X509 certificate and connection attempt might be made each time power is cycled, in this case I don't want to cause write wear on the TLS certificate store, if it can be avoided. If the certificate must be in the TLS certificate store to be used by Azure this might not be avoidable so after some failed attempts a flag might have to be set for service. Again concerned about the EEPROM wear. 
 7. I guess what I am really looking for is some advice on a smooth method to auto provision the nRF9160 for Azure, with the possibility that the X509 certificates will need some method to be updated in the field when the device is in the customer's hands. As seen from the Raspberry Pi scenario auto downloading of device specific X509 provisioning certificates has been implemented and looking for a smooth provisioning method for the nRF9160 so any advice on this would be helpful.

Håkon Alseth · Accepted Answer

Hello,

1. From looking at the sample source I am under the impression that this uses the MQTT library. This also appears to use the TLS certificate store as the function "tls_credential_add" is called. Is it possible to use a certificate loaded into SRAM? As the certificate is quite a few bytes long this may not be exactly efficient. 
 tls_credential_add() is a zephyr component that we do not have any port for (atleast at this time), so you need to use our API directly. 
 Loading certificates from the MCU can be done via the modem key management API: 
 https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.5.0/nrf/include/modem/modem_key_mgmt.html 
 
 You can also use the AT%CMNG AT command: 
 https://infocenter.nordicsemi.com/index.jsp?topic=%2Fref_at_commands%2FREF%2Fat_commands%2Fmob_termination_ctrl_status%2Fcmng.html 
 
 2. I am planning on storing the certificates on an external SD card as they are downloaded from the automatic provisioning server, but ultimately they may need to be stored in the nRF9160's TLS certificate store. I am concerned about write wear on the EEPROM memory used for the certificate store, is there any concern? Has there been any testing as to what kind of endurance there is for this memory? I am sure it is somewhere in the nRF9160 datasheet but I have not been able to locate the information as of yet. I am always a little paranoid about write endurance on things like EEPROM, SD cards, and SSD memory devices since they will be out in the field where failure is a really bad thing. The above mentioned Raspberry Pi SD card root filesystem is setup in a read-only mode for this reason. 6. In the event that Azure does not connect, an automatic download of a new X509 certificate and connection attempt might be made each time power is cycled, in this case I don't want to cause write wear on the TLS certificate store, if it can be avoided. If the certificate must be in the TLS certificate store to be used by Azure this might not be avoidable so after some failed attempts a flag might have to be set for service. Again concerned about the EEPROM wear. 
 Once provisioned to the nRF9160, either via modem key management API, or AT command; it will be stored in non-volatile memory inside the modem, and used via setting a security tag where you originally provisioned keys when connecting. 
 We do have a maximum ratings on our flash wrt. endurance (note, it's minimum cycles, its highly unlikely that devices start failing at 10k + 1 cycles): 
 https://infocenter.nordicsemi.com/topic/ps_nrf9160/abs_max_ratings.html?cp=2_0_0_11 
 
 3. If the X509 certificate is stored in the TLS store, is it possible to read back, or compare it to what is stored on the SD card, if I go with using the SD card as the primary storage location for the X509 certificates I would like to rewrite the certificate stored in the TLS store on startup, but don't want to rewrite it if unnecessary to avoid wear on the EEPROM memory. Is there logic in the TLS writing logic that would compare what is in EEPROM and only erase/write bytes that have changes (to avoid wear)? I incorporate similar logic in the Raspberry Pi EEPROM writing logic. 
 You can read back Root CA, but not any secret keys. Here's an example where I read back the CA root written by https_client sample: 
 
 4. I believe this is not a question of possibility, but development time, but I would like to add in the ability in this project for the nRF9160 to directly download the X509 certificates using HTTP (HTTPS). Concerning the HTTPS, does the server certificate or root CA need to be registered for an HTTPS connection to be established? Concern with this is the server's SSL certificate is renewed every 3 months. 
 Yes, it is strongly recommended that you verify the host you're connecting to. 
 If the server certificate is rotated, you need to ensure that the nRF9160 has the correct certs to verify the hostname correctly: 
 https://github.com/nrfconnect/sdk-nrf/blob/master/samples/nrf9160/https_client/src/main.c#L116-L124 
 
 5. This is outside of the scope of Azure, but I will need to store APN information (authentication included) for the SIM cards that will be used, the MVNO SIM cards that I have been using do not really cooperate with the automatic APN feature of the nRF9160 and therefore will be storing this information on the SD card anyway, so figured I might as well store the X509 certificates as well on the SD card. 
 APN can be issued using this kconfig: 
 https://github.com/nrfconnect/sdk-nrf/blob/master/lib/lte_link_control/Kconfig#L112-L118 
 The lte_lc library will then use this AT command to set the APN details: 
 https://github.com/nrfconnect/sdk-nrf/blob/master/lib/lte_link_control/lte_lc.c#L219 
 
 7. I guess what I am really looking for is some advice on a smooth method to auto provision the nRF9160 for Azure, with the possibility that the X509 certificates will need some method to be updated in the field when the device is in the customer's hands. As seen from the Raspberry Pi scenario auto downloading of device specific X509 provisioning certificates has been implemented and looking for a smooth provisioning method for the nRF9160 so any advice on this would be helpful. 
 Unfortunately, we do not have any examples for a provisioning service for certificates via a 2nd server, but it is indeed theoretically possible to do it like you envision. 
 
 Kind regards, 
 Håkon

nRF9160 with Microsoft Azure, x509 certificates and provisioning methods, TLS store write wear

Top Replies