When encrypting, allow some info in clear in the manifest

[BrunoVernay]

RAUC supports encryption: https://rauc.readthedocs.io/en/latest/advanced.html#bundle-encryption This is great.
Currently, the whole manifest is encrypted https://rauc.readthedocs.io/en/latest/reference.html?highlight=manifest#sec-ref-formats
It would be nice to encrypt only the symmetric key used to (de)crypt the payload.  That would leave the meta-data (Compatible targets, Version, Description, Signature, ...) in clear, allowing tools to manage the bundle without requiring the key.

[jluebbe]

In the current design, the encrypted CMS wraps the (plain-text) signature CMS completely, which allows keeping the existing bundle structure and doesn't require an additional (rauc-specific) container to keep the encrypted and plain-text parts separate. Any such container would have to be unsigned and so the code to handle it in RAUC would be additional attack surface. One of the sponsors of this feature also had a use-case where the bundle meta-data should be encrypted as well.

So, to keep the overall complexity as low a possible, we decided to only support the fully encrypted approach.

One additional reason of this design is the following (see also https://rauc.readthedocs.io/en/latest/advanced.html#scalability):
To allow management of a bundle collection on a server, I'd suggest adding the encryption only at the last step, in a automated process. This could be done on-demand in a web service, as only the device's public key is needed, not the very sensitive private bundle signing key.

That tool would take the CMS signature part (which contains the manifest) from the unencrypted bundle and use openssl cms -encrypt (or the API equivalent) to generate the encrypted CMS. This could be done on-demand by the service, individually for each requesting client and without storing the resulting encrypted CMS on the server. Alternatively, the full payload of the bundle can be shared between multiple bundles pre-encrypted to different devices, i.e. with reflinks (if on-demand CMS encryption doesn't fit your use-case).

This way, there is some additional complexity in the management tooling, but as it's outside of the signed/authenticated path, it's not as critical.

[BrunoVernay]

Thanks for the explainations. I get your point (and I never doubted about the usefulness of the use-case).

If we wanted to envision and design a solution where:

1. the bundle is encrypted
2. information are added ("appended") like name, version, model, compatibility...
3. the whole thing is signed.

For what I understand:

• CMS format allows such construction
• The signature would be checked first. The attack surface is reduced to "internal attacker having access to signature ..."

Now:

• does it sound like a good idea? Is there other way to access clear text authenticated info about the FW without internet access.
• How much addition would that require to RAUC code and is there ways to minimize these code changes?

[jluebbe]

I can see some use-cases, but I'm not sure if it's a good idea. A detailed design would probably allow us to decide that.

Some things that would need to be ensured:

• The plaintext information is signed and bound to the bundle contents (not necessarily the recipients)
• It's worth the additional complexity
• Keep the bundle creation (including symmetric payload encryption) separate from adding recipients (asymmetric encryption)

We currently don't have a project that requires this, so (for now) please don't expect us to push this.

[BrunoVernay]

After some investigation, it looks like adding clear, signed information would have a big impact on the current solution. Both the code and the bundle would be modified a lot. (Mostly because currently the secret key, in clear text, is signed.)

As this RFE seems to get no traction, an alternative solution could get the job done without modifying RAUC. Simply adding the metadata (Model, Version, ...) to the encrypted CMS as un-encrypted, un-signed attributes.
It is not ideal, attackers could encrypt anything and add any attributes. But we expect anything before the signature verification anyway. (Intermediate tools could even check a hash from a trusted URL if that extra security is needed)

The question is: would RAUC be interested in adding extra attributes to the final CMS?

• Do we try to add this feature to rauc encrypt ... --with-cms-attributes attr.yml ... and do a push request ?
• Do we develop our own separate tool to add attributes to the CMS and just keep you informed ?

[ejoerns]

The question is: would RAUC be interested in adding extra attributes to the final CMS?

Personally I would answer this with a clear 'yes and no'.
If there is good argumentation that there are valid use cases that require this and if the pros outweigh the cons: yes.
Otherwise: (probably temporary) no

• Do we try to add this feature to rauc encrypt ... --with-cms-attributes attr.yml ... and do a push request ?

I would prefer this solution since I assume that your are not the only one with such a use case.

But, currently I do not have a good feeling about what kind of information should be exposed and which not.
Maybe knowing more details about what you require and how you need to access it would give us a better understanding of the use case and about what we should protect in which way.
Because, as you already said you yourself, there is not obvious and straight-forward solution to this I fear.

So for example, what kind of decisions would you base on verified/unverified information if they were available?
And why can this not be done on the decrypted bundle?
The tools you noted (that require access to the meta information), are these tools on the generation/build host? Or are these tools on the target?

• Do we develop our own separate tool to add attributes to the CMS and just keep you informed ?

If in the end it turns out that this is the only way for now, keeping us informed would be really helpful indeed.
Maybe then later others can pick this up again when having similar use cases and we can distill the common requirements.

[multiple1]

@BrunoVernay any update on this? Have you found a solution to add some clear text?

It looks like the crypt bundle does not have any special header/trailer struct. It simply has a 8 trailing bytes (uint64) defining the signature size. The signature size is used to calculate the signature offset (seekend(file) - signature size)
Simply adding a cleartext trailer is therefore not possible.

But would it be ok if a cleartext trailer is added before the last 8 bytes and the signature size is increased accordingly?
Initial tests showed no problems.
Is this safe and future prove to add some custom trailing payload?
Or should the custom payload be added between the squashfs and the signature?