Signed URLs for Embedded Devices

Today we are launching support for device signed URLs, which is now available for Golioth projects in Teams or Enterprise tier organizations. The feature is off by default, but can be enabled on the settings page for a project. We are also releasing signy, an open source firmware library for generating signed URLs on embedded devices.

Signed URLs Background

Signed URLs are typically used on the web to grant time-limited access to private resources. The most common use is with Content Delivery Networks (CDNs), where a client may request a large private media asset from an origin server that is geographically far away, then be redirected to a closer CDN server with a signed URL to speed up the download of the asset.

In order to avoid complex authentication and authorization logic across a large, geographically distributed CDN, the origin server can determine whether the client can access the asset, then generate a signed URL that the CDN server is able to verify as issued by the origin. When the client uses the signed URL, the CDN server verifies the signature in the URL, and ensures that the URL is not being used outside of any time restrictions included in URL parameters.

Bringing Signed URLs to Embedded Devices

While device signed URLs use a similar technique to traditional signed URLs, the device, which would usually be thought of as a client, is acting more like an origin server. But if the device is the origin server, then who is the client? To be more precise, a component on a device is acting like an origin server, and the client may be another component on the same device, or an external system that is communicating with the device.

One motivating use case for this functionality is embedded devices with multiple communication interfaces. For example, many devices that connect to the Golioth platform leverage both cellular and Wi-Fi, with a separate microcontroller (MCU) managing each. Most modern MCUs support the ability to leverage a secure processing environment (SPE) for private key storage and cryptographic operations. The network stack running on the MCU is typically able to interact with the SPE in order to securely connect to an external server using (D)TLS or some other secure transport. However, the device manufacturer is responsible for generating private keys in the SPE and issuing certificates from their PKI during initial provisioning. If there are multiple components that need credentials to communicate over the network, the provisioning process and ongoing credential management becomes more complex. Furthermore, it may be the case that one component lacks sophisticated security features that are present on the other.

Diagram of Multi-Protocol Device with Credentials on Each MCU

 

With device signed URLs, a single component on a device can be provisioned with credentials, and can use its private key to issue time-limited signed URLs that may be distributed to other components over local communication interfaces (e.g. UART, SPI, etc.). Doing so grants the less secure component narrowly scoped access to a resource without transmitting any long-lived credentials.

Diagram of Multi-Protocol Device with Multiple MCUs but a single set of credentials.

Making Device Signed URLs Easy with signy

Generating signed URLs on embedded devices can be complex, which is why we have also built signy. signy takes care of crafting signed URLs in the format supported by Golioth, and makes use of the Arm Platform Security Architecture (PSA) Crypto API for all signing operations. This ensures that private keys can be stored and accessed securely, and that any cryptographic acceleration support on underlying hardware can be leveraged.

int err = signy_init(priv_key, device_crt_der, device_crt_der_len);
if (err != 0)
{
    LOG_ERR("Failed to initialize signy: %d", err);
    return -1;
}

err = signy_sign_url(CONFIG_BASE_URL,
                     strlen(CONFIG_BASE_URL),
                     signed_url,
                     sizeof(signed_url),
                     &signed_url_len);
if (err != 0)
{
    LOG_ERR("Failed to sign URL: %d", err);
    return -1;
}

The signy repository is also a Zephyr module, meaning that it can easily be pulled into existing Zephyr applications with minimal configuration.

Looking Forward

We are excited about the new use cases that device signed URLs enable. Outside of the multi-MCU scenario described in this post, device signed URLs can also be leveraged to allow other devices without Golioth credentials, such as a smartphone connected to a Bluetooth Low Energy peripheral using Golioth Managed Connectivity, to download assets. Stay tuned for future posts, and let us know how you are using device signed URLs on the forum!

Dan Mangum
Dan Mangum
Dan is an experienced engineering leader, having built products and teams at both large companies and small startups. He has a history of leadership in open source communities, and has worked across many layers of the technical stack, giving him unique insight into the constraints faced by Golioth’s customers and the requirements of a platform that enables their success.

Post Comments

No comments yet! Start the discussion at forum.golioth.io

More from this author

Related posts

spot_img

Latest posts

Zephyr for Hardware Engineers: GDB Debugging

Debugging a Zephyr program with GDB can be tough for newcomers, especially if they're used to more vertically integrated IDE solutions. Let's get hardware engineers (and others!) started digging into a command-line based solution.

How to Flash a Pre-Loaded Filesystem During Production

Creating a filesystem separates your everyday firmware from other data like machine learning models, images, and binaries. In this post we discuss how you can set up the filesystem to speed up your production and create a flexible system that can be updated on-demand using Golioth's OTA service.

How to build a Bluetooth-connected digital signage fleet

Use Golioth Connectivity to create Bluetooth-enabled Digital Signage fleets. This demo shows how you can create an LED matrix that shows different informational callouts. We also show how you can easily provision a new device onto your fleet with certificates.

Want to stay up to date with the latest news?

Subscribe to our newsletter and get updates every 2 weeks. Follow the latest blogs and industry trends.