Golioth Firmware SDK v0.16.0

Yesterday we released v0.16.0 of the Golioth Firmware SDK. This release includes a number of improvements, which are described in the following sections. Importantly, this release also introduces the Golioth Root X1 root CA certificate, which Golioth device services will start using 1 year from today. Golioth users are encouraged to update to their firmware to the v0.16.0 release at their earliest convenience.

For the full set of changes in this release, see the changelog.

Golioth Root X1

Note: this update does not impact devices that are using pre-shared keys (PSKs) for authentication. Golioth does not recommend the use of PSKs in production.

Golioth device services have always relied on Let’s Encrypt for server certificates. Let’s Encrypt is a fantastic service that has contributed to making a more secure internet for all. We plan to continue using Let’s Encrypt for the foreseeable future for the Golioth Management API and all of our web properties.

Let’s Encrypt is a public Certificate Authority (CA). The benefit of using certificates issued by a public CA is that its root certificates are widely trusted. That trust is what allows your browser to securely connect to this website. Operating systems, browsers, and other applications include a set of root CA certificates in their root store (see Chromium’s list for example), meaning that they will trust leaf certificates that have a chain of trust rooted in one of those root CA certificates. When someone wants to serve content on the public internet, they can request a leaf certificate from a service like Let’s Encrypt after completing an ACME challenge verifying ownership of their domain. Because Let’s Encrypt’s root CA certificates are included in almost all root stores, clients will automatically trust that site without requiring any manual intervention.

While this system underpins the security of the entire internet, the value of widely trusted certificates is less applicable to embedded devices. Typically, root CA certificates are loaded into a secure element or baked into firmware by the manufacturer of the device or the developer of its firmware. This is in stark contrast to buying a PC with a pre-installed operating system or downloading a web browser.

Embedded devices also differ in their constraints. With limited flash and memory, every root CA certificate and supported cipher suite cuts into precious resources. Furthermore, many of the devices are deployed in hard-to-access locations, meaning that losing remote connectivity can be fatal. Extreme care must be taken to ensure that devices are designed to continue communicating securely in perpetuity. One key aspect of developing a strategy is ensuring robust support for Over-the-Air (OTA) updates, which Golioth makes simple and straightforward.

As part of our ongoing commitment to our users we have evaluated all the ways in which changes in the trust chain for certificates used by Golioth device services could negatively impact devices in the field. For example, a slight change in the cipher suite leveraged by an intermediate certificate could render a device unable to securely connect to the platform if the new cipher suite was not enabled in its firmware. While public CAs like Let’s Encrypt typically communicate changes with ample lead time, by using their certificates we, and in turn our users, are subject to their policies and procedures (as well as any future changes to them). This constitutes a level of risk that we are not comfortable with.

For this reason, the v0.16.0 release of the Golioth Firmware SDK includes the Golioth Root X1 root CA certificate alongside Let’s Encrypt’s ISRG Root X1 root. It also formally starts the transition period for devices connecting to the Golioth platform to move to including Golioth Root X1 in their root store. The simplest way to accomplish this is by upgrading to the v0.16.0 release for your next firmware update. We have set the transition period to 1 year from today, but as always, we will work with all current and future users to ensure that the transition process is seamless.

If you have any questions please do not hesitate to reach out to us on the forum.

Asynchronous Callback Status Handling

All asynchronous callbacks now have both a status member and a coap_rsp_code member to replace the response member. All of the same information remains accessible, but the updated structure supports more granular error handling in callbacks, such as performing operations when a request is unable to be sent. These callbacks are now also invoked when requests are canceled prior to receiving a response, which may be the case if the Golioth client is manually stopped or connection is lost.

Callback function signatures must be updated and accesses to response->status should be updated to status.

OTA Download Resume

golioth_ota_download_component() has a new uint32_t *next_block_idx parameter. This parameter can be used to specify an offset when downloading an artifact. This is particularly useful if an artifact download was interrupted and it is desirable to resume from the last successful transfer.

Set next_block_idx to NULL to use previous functionality in existing code.

Zephyr and NCS Version Updates

This release also includes an update to Zephyr’s new major version release, v4.0.0. There is also corresponding support for v2.8.0 of the Nordic Connect SDK (NCS).

What’s on the Horizon?

Recent updates in the Golioth Firmware SDK have focused on improved OTA stability, and that focus will continue into the coming releases. We are also excited about coming support for new Golioth device services, which will greatly expand the capabilities of devices communicating with the platform.