feature: extract signatue: add option to extract signature from bundle

[Jarsop]

Many industrialization procedure requires to sign any artifact in a
dedicated secure room with restricted access
(as Public Key Infrastructure aka PKI).

This purpose add a extract-signature command to extract the signature
and allow resigning the signature content externally.

Signed-off-by: Jean-Pierre Geslin jarsop@outlook.com

[ejoerns]

@Jarsop Thanks for your contribution.

The existing intended way for this would be to use the rauc resign command. https://rauc.readthedocs.io/en/latest/advanced.html#resigning-bundles

Did you check this? Or could you describe in how this would not meet your requirements?

How would you ensure that the 'external' signing produces a valid signature format for RAUC?

[Jarsop]

@Jarsop Thanks for your contribution.

The existing intended way for this would be to use the rauc resign command. https://rauc.readthedocs.io/en/latest/advanced.html#resigning-bundles

Did you check this? Or could you describe in how this would not meet your requirements?

@ejoerns Yes I already check that but in an embedded Linux project of a large company for which I am currently working (and others in the past which have the same functioning), they have a PKI which prohibits any external tool to sign artifacts (so no rauc resign possible).

So I had to provide them with the exact format of the desired signature and he provides it to me.

Today I created a tool that allows you to build this kind of bundle and then assemble the CMS in post process.
So that's why I think this functionality should be integrated into RAUC.

This problem is common in large companies which have very strict signature policies.

Hoping to have been clear and thanks for your quick reply.

Regards

[Jarsop]

How would you ensure that the 'external' signing produces a valid signature format for RAUC?

For this point although the signature can be constrained during this request to the signer, I think that a check at the command level which will allow to assemble the unsigned bundle and the CMS will be able to solve this problem

[Jarsop]

@ejoerns Yes I already check that but in an embedded Linux project of a large company for which I am currently working (and others in the past which have the same functioning), they have a PKI which prohibits any external tool to sign artifacts (so no rauc resign possible)

To be more precise about PKI, the official signer don't have a direct access to the private keys but only access to a client which take a signature policies parameter and request to a secure server which contain the official private key.

[Jarsop]

Maybe it's better to will be a part of resign command ? (For bundle extraction and re-assembly)

[jluebbe]

Both rauc bundle and rauc resign already support using PKCS#11 keys, so no direct access to the private key material is needed. Would that be enough for your use-case?

If not, how about this:

• a new rauc extract-signature command which would extract the CMS signature from a bundle and write it to a file
• a new rauc replace-signature command which would create a copy of an existing bundle playload with a CMS signature read from a file

I'd restrict this to verity bundles, as the CMS signature is "self-contained" in that mode (and also I'd like to discourage plain bundles).

In practice, you'd then build bundles as normal (signed with a development/CI key), test and review them. Then you'd use rauc extract-signature to get the CMS structure, process them with you special in-house PKI tools/process to get the release CMS signature. Those would then be used with rauc replace-signature.

I see some benefits:

1. No additional complexity in the normal bundle creation code.
2. Your tools only need to handle standard data formats (CMS) and the bundle format stays internal to RAUC.
3. Future changes to the bundle format (i.e. for encryption) can be handled in RAUC and would not affect your processes.
4. It would also allow multiple people to perform the review and rauc extract-signature step, resulting in multiple CMS files that could be compared in the PKI room to ensure no single person can sign a manipulated bundle.

We'd be happy to discuss this in https://app.element.io/#/room/#rauc:matrix.org (bridged from #rauc on libera.chat), as well.

[codecov]

Codecov Report

Merging #749 (7b044a6) into master (358ac06) will decrease coverage by 0.08%.
The diff coverage is 58.82%.

@@            Coverage Diff             @@
##           master     #749      +/-   ##
==========================================
- Coverage   72.99%   72.91%   -0.09%     
==========================================
  Files          28       28              
  Lines        8720     8771      +51     
==========================================
+ Hits         6365     6395      +30     
- Misses       2355     2376      +21     

Impacted Files	Coverage Δ
include/bundle.h	100.00% <ø> (ø)
src/main.c	76.05% <43.33%> (-0.86%)	⬇️
src/bundle.c	63.44% <80.95%> (+0.35%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 358ac06...7b044a6. Read the comment docs.

[jluebbe]

Just a minor suggestion for simplification. I'll likely do some rewording on the commit message and documentation before merging if that's fine with you.

[Jarsop]

@jluebbe Any ideas why uncrustify failed? Maybe because you requested changes?

[jluebbe]

I've made some small changes and force-pushed the PR. You can check my changes here: https://github.com/rauc/rauc/compare/45c6972431e92d8c062c6e54c9afdebbf2384ede..7b044a64a39541e95ee8a23da0b614973b83b6db

@jluebbe Any ideas why uncrustify failed? Maybe because you requested changes?

This was a the "sightly"/"slightly" typo.

[Jarsop]

@jluebbe Should it be configurable with --no-verify option ?

[jluebbe]

Hmm, probably yes, although I'm not a fan of --no-verify. That could be a separate PR though. I'd prefer to merge this as-is to prepare for the replace-signature command.