In the lifecycle of a deployed IoT fleet, security is not a static feature you ship; it is a continuous state of operation. Or at least it should be. While many developers are familiar with securing web traffic via HTTPS, the requirements for IoT mutual authentication and Over-the-Air (OTA) updates are significantly more complex.
Trust is currency. To maintain it, you must manage the keys to your kingdom. This means implementing rigorous Key Rotation strategies. While there are various architectures available to secure fleet updates, The Update Framework (TUF) represents a proven, standardized model to ensure resilience even in the face of an inevitable breach.
Whether you are managing a small fleet of 10 devices or millions of industrial gateways, here is why you need a rotation strategy and how to implement it using the FoundriesFactory™ platform production standards.
Trust should be a two-way street
To understand where IoT security challenges begin, we must first look at the industry standard for moving data: Transport Layer Security (TLS).
TLS is the cryptographic protocol designed to provide secure communication over a network. It creates a private tunnel between two points, ensuring that data cannot be read or tampered with while in transit. In standard web implementations (HTTPS), this is implemented to create a one-way trust model. For example; you visit a banking website, your browser (the client) verifies the bank's certificate (the server) to ensure it is safe to send credit card data. The bank does not need to cryptographically verify your browser; it just needs to know your password.
For connected devices, one-way trust is insufficient. The Internet of Things demands Mutual TLS (mTLS), where both parties must prove their identity before a single byte of data is exchanged:
- Server Identity: The device must confirm it is connecting to the legitimate update server, not a man-in-the-middle.
- Device Identity: The server must cryptographically confirm the device is authorized, active, and hasn't been cloned or spoofed.
However, even mTLS has limits. It protects the connection, but it relies heavily on the keys used to establish that connection. If those keys remain static for the life of a device (which can be 10+ years in embedded systems), the probability of them being compromised rises exponentially. This is where we must move beyond securing the pipe and start securing the payload via key rotation and update frameworks.
Symmetric vs. Asymmetric Encryption in Embedded Systems
To understand key rotation, we must distinguish between the two primary encryption models used in embedded development.
1. Symmetric Encryption
A single secret key is used to both encrypt and decrypt data.
- The Risk: Key distribution is a nightmare. If the key is extracted from one device (e.g., via a side-channel attack), the entire fleet is potentially compromised.
- Use Case: Local storage encryption or ephemeral session keys.
2. Asymmetric Encryption (PKI)
Uses a pair of keys: a Public Key (shared openly) and a Private Key (kept secret).
- The Benefit: Offers confidentiality, authenticity, and non-repudiation. You can verify who sent a message without ever knowing their private key.
- Use Case: Secure Boot, OTA updates, and device identity.
At Foundries.io we utilize asymmetric encryption for digital signatures. When you push an update, it is signed with a private key. The device, holding the public key, verifies the signature before applying the update.
What is TUF (The Update Framework)?
The Update Framework (TUF) is an IETF standard designed to protect software repositories. Its primary goal is Compromise Resilience. TUF assumes that hackers will eventually steal a key or compromise a server. It provides a mechanism to recover from that breach without visiting the device physically.
The TUF Hierarchy of Trust
TUF divides responsibility among multiple roles, preventing any single point of failure. In FoundriesFactory, we implement these roles to separate online (automated) convenience from offline (high-security) trust.
| TUF Role | Function | Key Storage & Best Practice |
|---|---|---|
| Root | The anchor of trust. Signs the keys for all other roles. | OFFLINE. Kept in cold storage (e.g., YubiKey, air-gapped USB). Should be rotated annually. |
| Targets | Signs the actual software update artifacts. | Hybrid. online keys for CI builds; offline keys for Production releases. |
| Snapshot | Verifies the consistency of the repository. | Online. Managed by FoundriesFactory to ensure repo integrity. |
| Timestamp | Indicates when the snapshot was created. | Online. Rotated frequently (e.g., daily) to prevent freeze attacks. |
Key Rotation: Best Practices for Production
Key rotation is the practice of retiring an encryption key and replacing it with a new one. This limits the cryptoperiod or the lifespan during which a specific key is valid.
1. First Rotation
When you create your Factory with the FoundriesFactory platform, an initial online Root key is generated for you.
Best Practice: You must rotate this key to an offline key as soon as possible. This transfers ownership of the Root of Trust from our servers to your secure physical storage.
- Command: fioctl keys tuf rotate-offline-key
2. 3-to-5 Redundancy
Never rely on a single offline key. If you lose your only offline Root key, you lose control of your factory forever.
Best Practice: Generate 3 to 5 offline keys and set a signature threshold of 2. This means you need at least two keys to sign a root rotation, protecting you against both rogue employees and lost hardware.
3. CI vs. Production Separation
In development (CI), speed is priority. You want every git push to build and deploy.
- CI: Uses online Targets keys managed by the platform.
- Production: Should always use offline Targets keys.
Best Practice: When promoting a build to production, use FoundriesFactory Waves. This process requires you to sign the release with your offline keys, ensuring that no compromised cloud server can ever force a malicious update to your production fleet.
4. 1-Year Rotation Cycle
Even offline keys should not live forever.
Best Practice: Rotate your offline Root key at least once a year. This serves two purposes:
- Security Hygiene: Invalidates any potential unseen compromises.
- Process Verification: Ensures your team remembers how to perform the rotation and knows where the keys are stored.
Hardware Root of Trust
Software security ultimately relies on hardware. Your TUF keys verify the software, but what verifies the keys?
- Secure Boot: The device SoC (System on Chip) verifies the initial bootloader using a key burned into the silicon fuses.
- Secure Elements: For maximum security, we recommend integrating a hardware secure element. This allows the device to store its private identity keys in a tamper-resistant vault that is physically isolated from the main processor.
Automating Trust with FoundriesFactory
Implementing TUF from scratch is notoriously difficult. Managing the metadata, key storage, expiration dates, and rotation policies requires significant DevOps overhead.
The FoundriesFactory platform integrates these best practices by default:
- Policy-Based Rotation: Automated rotation for online keys (Timestamp/Snapshot).
- Fioctl CLI: Simple commands to handle complex offline key rotation and re-signing.
- Recoverability: If a Targets key is compromised, you can revoke it using your Root key and push a new trust map to the fleet instantly.
Is Your Fleet Secure?
Don't wait for a breach to test your key management strategy. If you are still using the default keys generated at factory creation, or if your Production updates are signed by the same keys as your Dev builds, it is time to upgrade your security posture.
Whether you're evaluating platforms or ready to build, we recommend starting with our free Community Edition to explore what's possible with the FoundriesFactory platform.
FoundriesFactory Community Edition (Free) – Start building your embedded Linux solution today.
Learn More About Developer Edition – Unlock advanced features and dedicated support.
Book a Demo – See how FoundriesFactory can accelerate your development.