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.
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.
signy
Making Device Signed URLs Easy with 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!
No comments yet! Start the discussion at forum.golioth.io