1

I am developing a hardware device that utilizes AWS IoT OTA via FreeRTOS. On this AWS web page, it says

We recommend that you purchase a code-signing certificate from a company with a good reputation for security. Do not use a self-signed certificate for any purpose other than testing.

A) If the credentials are hard-coded on the device for future OTA code-checking, what's the problem of using a self-signed certificate if a CA isn't normally consulted during the OTA process anyway (or is it)?

B) And if a CA IS normally consulted, why does it matter where the OTA update is coming from if it's not going to be accepted by the device anyway when the certificates don't match?

Improve this question
2
  • You forgot the to cite the last sentence, which explains the recommendation: "Encouraging your users to trust arbitrary certificates with no reputational backing is a poor security practice." . So this recommendation is clearly addressed for code which gets shipped to others ("your users") and were others want to understand where this code comes from and make trust decisions based on this.
    – Steffen Ullrich
    Commented Jun 6 at 19:53
  • Thanks @Steffen Ullrich. I thought about that, but since IoT is usually "plug-and-play", such stuff is invisible to the end user so I didn't see the relevance. Do you know whether (FreeRTOS') OTA code-verification typically involves a public CA?
    – kackle123
    Commented Jun 6 at 20:03

1 Answer 1

Reset to default
3

The recommendation doesn't necessarily apply to OTA updates. It seems to be more about cases where a user is involved (like when a firmware update is installed manually).

How exactly the OTA agent checks the firmware signature depends on the implementation you use on your IoT devices, so it's ultimately up to you which certificates are involved. Common agent implementations like the one from the AWS IoT Device SDK for Embedded C only use a single certificate to check the signature. They do not build any certificate chains, so it's irrelevant whether the code signing certificate has been issued by a particular CA or is self-signed.

In general, the OTA agent only has to implement the OTA Platform Abstraction Layer (PAL) interface, as explained in the design documentation. The function responsible for the signature check has the type OtaPalCloseFile_t with the following definition:

typedef OtaPalStatus_t(* OtaPalCloseFile_t) (OtaFileContext_t *const pFileContext)

The OtaFileContext_t struct has a pCertFilepath member which is documented as follows:

Pathname of the certificate file used to validate the receive[d] file.

So the interface only specifies that the signature is checked against some certificate. It doesn't say anything about CA certificates. In principle, you could implement a trust store with specific root CAs on your IoT devices and have the agent verify that the code signing certificate has been issued by one of those CAs, but this isn't mandatory.

When you look at the implementation from the C-SDK, you can see that it simply extracts the public key from the certificate located at pCertFilepath (or alternatively a hard-coded certificate in the header file) and checks the firmware signature against this key.

So in the context of OTA updates, the recommendation to purchase a code signing certificate from a well-known CA doesn't make a lot of sense. However, if the updates are obtained through other means (e.g., manually by the user), then having a certificate which has been issued by a trusted CA is definitely recommended.

Improve this answer
1
  • I agree with your assessment, in this context it doesn't make a lot of sense. In fact, I later saw another AWS page where they didn't recommend a paid "service" for OTA stuff. Thank you.
    – kackle123
    Commented Jun 7 at 13:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .