SWUpdate: additional AEAD encryption path (early steer before RFC)
Raimar Sandner
Back in 2023 you merged our
CONFIG_ENCRYPTED_IMAGES_HARDEN_LOGGING patch [1]; thanks again
for that, it is still working well in our deployments.
I would like to propose a line of work that could also benefit
SWUpdate more broadly: an *additional* authenticated-encryption
(AEAD) path alongside the existing AES-CBC one. We are building
this path, and I would value your early steer on whether it should
go upstream and in what shape, before we settle the design.
AES-CBC stays exactly as today (behavior, configs, tests); AEAD is
a parallel, per-artifact opt-in.
Signing is untouched: CMS signing of sw-description stays
exactly as today and remains the source-authentication anchor,
the proof that the update comes from a legitimate builder. AEAD
complements the CMS signature by additionally binding the
payload's in-stream integrity to the symmetric key.
The design, with the details left to a later RFC:
- Interface: a single cipher-agnostic registration point on
swupdate's existing Init/Update(block)/final decrypt interface,
with AES-GCM as the first cipher and no GCM specifics leaking
into the generic path. Other AEAD ciphers (ChaCha20-Poly1305,
...) can be added later without touching it.
- Format: a chunked, streaming frame with fixed-size chunks,
one tag per chunk, so each chunk authenticates before any
plaintext reaches a handler. Frame layout and nonce derivation
would be worked out in the RFC.
- Overhead: a fixed header plus one tag per chunk; we size
chunks so the relative overhead stays negligible at rootfs
scale, and the streaming property is preserved.
- ZCK (side benefit): because each chunk authenticates
independently, the layout aligns with ZCK in a way AES-CBC
cannot. We would design it ZCK-aware (no needless cross-chunk
coupling), leaving full ZCK integration as a later step (no
redesign necessary). This is the same block-independence that
makes AES-CTR attractive for delta updates.
A few practical points:
- Driver: our internal crypto guidelines steer us toward
authenticated encryption, so this is funded, scoped work now.
We also have a continuing internal use for the path, so we will
keep using and testing it ourselves.
- Licensing: we are extending a GPL project, so these changes
will be GPL anyway. Mainline is their natural home, so we would
rather get the design right with you while it is still cheap to
change than after the code exists.
- People/process: the implementation will be done by a master
student under close supervision, with the design and the
upstream contribution driven by us. The quality of the work is
our responsibility, the code itself as much as the tests, the
format spec and the docs. We would open with a design-only RFC
(the spec for review, not a patch series) so the direction can
be settled before the implementation work goes in; patches would
follow through the normal review cycles, with nothing landing
before it is ready.
What I would like to ask you, at this stage:
1. Would you in principle be open to an additional AEAD path as
above (parallel to CBC, cipher-agnostic, chunked/streaming,
ZCK-aware) upstream?
2. Are there constraints we should fold in now (process,
compatibility, scope, or anything already settled here that we
should respect)?
3. Any preference on how the RFC should be packaged?
We would appreciate your thoughts, and any input from the list,
on this line of work.
Thanks,
Raimar
[1] https://github.com/sbabic/swupdate/commit/1f57aa7ff59263550104df38a7094a3cf1bd3c76
Mit freundlichen Grüßen / Best regards
i.A. Dr. Raimar Sandner
Expert in Industrial Cybersecurity | Autonomous Perception
_____________________________________________________________________________________
SICK AG | Erwin-Sick-Str. 1 | 79183 Waldkirch | Germany
P +49 7681 202-6404 | raimar....@sick.de | www.sick.de
_____________________________________________________________________________________
SICK AG | Sitz: Waldkirch i. Br. | Handelsregister: Freiburg i. Br. HRB 280355 | WEEE-Reg.-Nr. DE 14165396
Vorstand: Dr. Mats Gökstorp (Vorsitzender) | Jan-H. Eberhardt | Ulrike Kahle-Roth | Nicole Kurek | Markus Scaglioso | Dr. Niels Syassen
Aufsichtsrat: Dr. Robert Bauer (Vorsitzender)
Stefano Babic
On 6/10/26 08:46, 'Raimar Sandner' via swupdate wrote:
> Hello Stefano, all,
>
> Back in 2023 you merged our
> CONFIG_ENCRYPTED_IMAGES_HARDEN_LOGGING patch [1]; thanks again
> for that, it is still working well in our deployments.
>
> I would like to propose a line of work that could also benefit
> SWUpdate more broadly: an *additional* authenticated-encryption
> (AEAD) path alongside the existing AES-CBC one. We are building
> this path, and I would value your early steer on whether it should
> go upstream and in what shape, before we settle the design.
> AES-CBC stays exactly as today (behavior, configs, tests); AEAD is
> a parallel, per-artifact opt-in.
>
> Signing is untouched: CMS signing of sw-description stays
> exactly as today and remains the source-authentication anchor,
> the proof that the update comes from a legitimate builder. AEAD
> complements the CMS signature by additionally binding the
> payload's in-stream integrity to the symmetric key.
I would like to understand the reason behind this. In my understanding,
AHEAD adds a way to verify that the artifact is not only correctly
encrypted, but it wasn't manipulated. Then it is spontaneous to me to
ask which is the added value.
SWUpdate has already a way to verify the integrity of encrypted
artifact. As each artifact has a signed hash, SWUpdate is verifying this
and stops with error if a package can be decrypted but it was
manipulated. This is also if artifact is not encrypted, anyway.
Decryption is running on the fly while hash is also computed. AHEAD
seems to me that just combine the two processes. Can you better explain
the intention ?
Anyway, new algs are well accepted and are described in the
"improvements" in SWUpdate
(https://github.com/sbabic/swupdate/blob/master/doc/source/improvement_proposals.rst).
I have really thought on opther algs like AES-CTR, that can allow toi
use encrypted chunks with delta update, more than AHEAD.
>
> The design, with the details left to a later RFC:
>
> - Interface: a single cipher-agnostic registration point on
> swupdate's existing Init/Update(block)/final decrypt interface,
> with AES-GCM as the first cipher and no GCM specifics leaking
> into the generic path. Other AEAD ciphers (ChaCha20-Poly1305,
> ...) can be added later without touching it.
adapting all currently crypto modules to a new API.
> - Format: a chunked, streaming frame with fixed-size chunks,
> one tag per chunk, so each chunk authenticates before any
> plaintext reaches a handler. Frame layout and nonce derivation
> would be worked out in the RFC.
> - Overhead: a fixed header plus one tag per chunk; we size
> chunks so the relative overhead stays negligible at rootfs
> scale, and the streaming property is preserved.
> - ZCK (side benefit): because each chunk authenticates
> independently, the layout aligns with ZCK in a way AES-CBC
> cannot. We would design it ZCK-aware (no needless cross-chunk
> coupling), leaving full ZCK integration as a later step (no
> redesign necessary). This is the same block-independence that
> makes AES-CTR attractive for delta updates.
AES-CTR. If design is ZCK-aware is already fine with me.
>
> A few practical points:
>
> - Driver: our internal crypto guidelines steer us toward
> authenticated encryption, so this is funded, scoped work now.
> We also have a continuing internal use for the path, so we will
> keep using and testing it ourselves.
> - Licensing: we are extending a GPL project, so these changes
> will be GPL anyway.
> Mainline is their natural home, so we would
> rather get the design right with you while it is still cheap to
> change than after the code exists.
> - People/process: the implementation will be done by a master
> student under close supervision, with the design and the
> upstream contribution driven by us. The quality of the work is
> our responsibility, the code itself as much as the tests, the
> format spec and the docs. We would open with a design-only RFC
> (the spec for review, not a patch series) so the direction can
> be settled before the implementation work goes in; patches would
> follow through the normal review cycles, with nothing landing
> before it is ready.
>
> What I would like to ask you, at this stage:
>
> 1. Would you in principle be open to an additional AEAD path as
> above (parallel to CBC, cipher-agnostic, chunked/streaming,
> ZCK-aware) upstream?
> 2. Are there constraints we should fold in now (process,
> compatibility, scope, or anything already settled here that we
> should respect)?
> 3. Any preference on how the RFC should be packaged?
>
> We would appreciate your thoughts, and any input from the list,
> on this line of work.
Stefano
>
> Thanks,
> Raimar
>
> [1] https://github.com/sbabic/swupdate/commit/1f57aa7ff59263550104df38a7094a3cf1bd3c76
>
> Mit freundlichen Grüßen / Best regards
>
> i.A. Dr. Raimar Sandner
> Expert in Industrial Cybersecurity | Autonomous Perception
>
> _____________________________________________________________________________________
> SICK AG | Erwin-Sick-Str. 1 | 79183 Waldkirch | Germany
> P +49 7681 202-6404 | raimar....@sick.de | www.sick.de
> _____________________________________________________________________________________
>
> SICK AG | Sitz: Waldkirch i. Br. | Handelsregister: Freiburg i. Br. HRB 280355 | WEEE-Reg.-Nr. DE 14165396
> Vorstand: Dr. Mats Gökstorp (Vorsitzender) | Jan-H. Eberhardt | Ulrike Kahle-Roth | Nicole Kurek | Markus Scaglioso | Dr. Niels Syassen
> Aufsichtsrat: Dr. Robert Bauer (Vorsitzender)
>
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com
Raimar Sandner
Thanks for the quick reply and the green light. ZCK-awareness is a hard
design property for us, and it lines up with the priorities you already
list in improvement_proposals.rst. Even though end-to-end support for
encrypted delta updates is out of scope for the current project,
working towards that goal is a strong motivation.
To answer your question about added value: I agree that SWUpdate already
does a very good job safeguarding the integrity of update packages. What
AEAD schemes add on a very general level is better alignment with modern
crypto policies, I'm already facing this at SICK. The shift towards
authenticated encryption is universal in the crypto community, take for
example TLS 1.3. On a technical level (the reason for this shift), AEAD
enables a very powerful design goal: only authenticated plaintext ever
reaches a handler. AEAD makes this cheap because authentication is baked
into the encryption itself. So is the CMS signature check over the whole
image redundant? No, it plays a crucial role, because without it we
regress to a security model where the sender _and_ the receiver can
build a valid firmware package (both know the symmetric key). In
principle, with AEAD alone, every fleet device could "sign" a legitimate
update, and we don't want that.
I'm looking forward to this project together with the student, scoped to
about 12 weeks. He will start in September, and as mentioned before, the
design and RFC work will lead ahead of the implementation. We will bring
it to the mailing list.
Thanks again, and if anything relevant comes up in the meantime, don't
hesitate to contact me.
Best regards,
Raimar
On 6/10/26 15:18, Stefano Babic wrote:
> I would like to understand the reason behind this. [...] it is
> spontaneous to me to ask which is the added value.
>
> SWUpdate has already a way to verify the integrity of encrypted
> artifact. [...] Decryption is running on the fly while hash is also
> computed. AHEAD seems to me that just combine the two processes.
> Can you better explain the intention?
>
> Anyway, new algs are well accepted and are described in the
> "improvements" in SWUpdate. I have really thought on other algs like
> AES-CTR, that can allow to use encrypted chunks with delta update,
> more than AHEAD.
Mit freundlichen Grüßen / Best regards