nRF cloud provisioning for nrf9160

Hello, I started working with the nRF Cloud and have been trying to understand the authentication procedure. 

From my understanding, the create_credentials script creates the private and public key, and the CA. 
This is CA, which is then used to sign the device certificate. In the end the sec_tag has three types of data:
type 0: the Amazon CA - used by the device to authenticate the server. 
type 1: our device certificate - used by the server to authenticate the device when using MQTT and MTLS.
type 3: our private key that signs the JWT token, its public key pair is inside the certificate that is inside the onboard.csv file that we upload.

I have a few questions:

1. I understand that our device certificate is used in the MTLS for the server to trust the device, but I don't understand why a device certificate that is signed by a CA that I created with a simple script is what does the trick. In other words, why am I a trusted authority? What security problem does this solve?
Furthermore, when I checked the onboard.csv contents, I saw that the CA public key isn't present, only the device credentials that are flashed in type 1 of the sectag, which means that the device certificate contents isn't even verified. The authentication in this case is only that the server sees that the device certificate is the same one that was uploaded to it? why then did we need a device certificate that is signed with a private key if it isnt even used?

2. chating with Claude, he said something about the type 1 being used for some kind of JITP but I couldnt find any documentation for that, is that true?


thanks in advance,
shlomo

Parents
  • Hello!

    Thanks for reaching out.

    1. The device certificate is not used in a root-of-trust model. The documentation on Certificates and security tags explains how trust is established for nRF Cloud.
      
    2. We have been supporting use of JITP earlier, but it's now deprecated and was removed in the 3.1.0 release of our SDK.

    Please reach out if you wonder about anything else!

    Best regards,
    Carl Richard

  • ok, thanks! 
    I have another question, I have seen it being stated here that the nRF cloud is more optimized for IOT devices in comparison with SUPL. 
    When I inspected the bytes that were being passed back and forth between SUPL and nRF cloud, I saw that the response size was comparable between the two, with even a slight edge for SUPL, 3.2 kb vs 3.6 kb. On the request side, the nRF cloud was larger because of the JWT token and body, which only these two amount to 0.6 kb, SUPL is less than 100 bytes.
    From what standpoint is the nRF cloud more optimized for IOT devices than SUPL? 
    Is it because of the SUPL chattiness? The fact that it has SUPL START -> SUPL RESPONSE -> SUPL POS INIT -> SUPL POS -> SUPL END sequence?

  • shlomots said:
    From what standpoint is the nRF cloud more optimized for IOT devices than SUPL? 

    Hi! 

    Thanks for your question. nRF Cloud may have slightly higher overhead than SUPL, but the data returned from nRF Cloud is a specifically formatted for the onboard GNSS modem. SUPL would require additional formatting. This makes nRF Cloud AGNSS more optimized for Nordic devices specifically.

    Best regards,
    Cole

Reply
  • shlomots said:
    From what standpoint is the nRF cloud more optimized for IOT devices than SUPL? 

    Hi! 

    Thanks for your question. nRF Cloud may have slightly higher overhead than SUPL, but the data returned from nRF Cloud is a specifically formatted for the onboard GNSS modem. SUPL would require additional formatting. This makes nRF Cloud AGNSS more optimized for Nordic devices specifically.

    Best regards,
    Cole

Children
No Data
Related