RAUC Encrypted Bundle Recipients: Bound Key-Envelope Growth Without Rebuilding the Payload
Partition recipients into bounded subsets, then distribute the correct recipient-specific bundle while reusing the same encrypted payload. The release system needs separate identities for payload content, recipient membership and the complete downloadable object. Treating all three as one filename makes both size budgeting and delivery errors harder to detect.
This article uses RAUC 1.13 crypt bundles. It describes an architecture and qualification plan, not a key-provisioning procedure. No keys were generated, credentials changed, bundles encrypted or installations performed. Product security also depends on signing policy, device key protection, boot verification and operational controls outside this narrow distribution decision.
1. Identify which bytes change for each recipient subset
The 1.13 encryption guide separates payload encryption from recipient encryption. The second stage encrypts the signed manifest, including the payload key, for selected recipients and leaves the encrypted payload unchanged. Recipient certificates need not belong to the signing PKI. The intermediate first-stage bundle still exposes the payload key in its signed manifest and must not be published as the final confidential artifact.
The format reference places the encrypted filesystem and its verity tree before the encrypted CMS structure and its size field. Therefore, reuse of the payload does not make complete subset bundles byte-identical. Maintain an immutable object identity for each finished variant.
Create a release record with a common payload identifier, authenticated manifest identity, recipient-set revision, final bundle digest and size, and the public recipient identifiers used for routing. Never put private keys or the decrypted payload key in that record. The application-specific recipient-set revision is bookkeeping, not a replacement for cryptographic verification.
2. Bound the envelope using finished artifacts
Recipient overhead depends on the actual encoding and certificates. Do not turn a rough per-recipient estimate into an unlimited fleet-size promise. First inspect the exact reader limit. In tagged v1.13 bundle.c, MAX_BUNDLE_SIGNATURE_SIZE is 0x10000, and both local and remote readers reject a recorded CMS size greater than 65,536 bytes. Equality passes that size check only; other format and verification checks still apply.
Choose an internal envelope budget below the deployed reader’s limit, with room for the signed manifest, certificate-chain changes and encoding variation. This margin is a product decision. Measure the complete final CMS structure, not just the extra bytes attributed to recipients, and retain the measured length alongside the exact bundle hash.
Build qualification cases around the largest planned subset and the largest permitted metadata configuration. If the resulting artifact exceeds the budget, split the subset and regenerate the recipient envelopes. Do not silently patch the installer limit or strip verification material merely to make the distribution job pass. Revalidate the limit when changing RAUC versions or downstream patches.
3. Make recipient routing deterministic and reviewable
Assign each public recipient identity to an approved subset revision. The assignment must be explicit enough that a delivery service can return exactly one appropriate finished object for that release. Reject missing or ambiguous mappings rather than searching through every envelope until decryption succeeds.
| Record | Purpose | Incorrect shortcut |
|---|---|---|
| Common payload identity | Recognize reused encrypted payload bytes | Use it as the whole-bundle digest |
| Recipient-set revision | Explain who is included in this envelope | Infer membership from a customer display name |
| Final object identity | Bind download length and digest to one variant | Overwrite a shared release URL in place |
| Device recipient mapping | Select an envelope containing the expected public identity | Assume the signing certificate is the decryption recipient |
Freeze this mapping with the release approval. A later recipient addition creates a new mapping revision and a newly identified finished artifact, even when the payload remains unchanged. Cached responses and offline service packages must carry enough identity to distinguish those variants.
4. Separate storage sharing from access qualification
The guide describes splitting large recipient sets and sharing the unchanged payload storage. Whether a particular object store, filesystem or download service actually saves physical space is an implementation question. A copy with a different filename is not evidence of deduplication.
If a service assembles responses from shared payload storage and a selected envelope, qualify the complete byte representation: total length, tail placement, range reads and consistency across repeated requests. Pin the selected variant for the duration of an operation. A cache that combines the payload of one release with another release’s tail must fail validation; it must never be treated as an acceptable bandwidth optimization.
Use immutable test objects and non-production credentials for this work. Preserve normal TLS and bundle verification. Storage reuse should be invisible to the target’s integrity checks, while the distribution logs still identify which complete variant was supplied.
5. Exercise the missing-recipient matrix
| Controlled case | Required interpretation |
|---|---|
| Expected recipient, trusted signer, compatible bundle | Eligible to continue through the remaining installation checks |
| Device receives another subset’s envelope | Decryption failure or rejection; classify the mapping error |
| Recipient can decrypt, signer is not trusted | Reject authorization; decryption is insufficient |
| Expected private-key provider is unavailable | Report key-access failure separately from absent membership |
| Final CMS exceeds the deployed reader limit | Reject the artifact before rollout, regardless of payload validity |
Run these cases through the intended inspection and installation paths on isolated, recoverable test devices. Record non-secret key identifiers and exact errors, never key contents. A successful inspection does not establish successful boot or health confirmation.
6. A hypothetical three-recipient release
Suppose public identities A and B belong to subset East, while C belongs to West. One encrypted payload P is used in finished objects East-7 and West-7. Delivering West-7 to A should produce a clear routing failure, even though both objects carry the same intended firmware payload. Giving A a fresh URL for West-7 cannot fix missing recipient membership.
Removing A from a future envelope does not erase A’s cached old envelope, recovered payload key or previously decrypted firmware. Reusing the same payload key material across variants means access already obtained cannot be withdrawn by relabeling the recipient list. Treat future confidentiality and historical disclosure as separate questions requiring the product’s security policy.
Close qualification with a bounded envelope budget, immutable variant inventory, reviewed recipient mapping and negative-case results. Those records answer the practical release question: can each approved device obtain the right envelope without making the bundle unreadably large or confusing decryption access with installation authorization?
