Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bundle.bbclass: add support for encrypting bundles #332

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mschwan-phytec
Copy link
Contributor

Add support for encrypting bundles after creating them. This requires the usage of the "crypt" bundle format and a recipient certificate for encrypting the signed bundle manifest. To encrypt the bundle, set RAUC_CRYPT_BUNDLE to 1 and RAUC_CRYPT_CERT_FILE to the path of the recipient certificate:

RAUC_CRYPT_BUNDLE ?= "1"
RAUC_CRYPT_CERT_FILE ?= "path/to/recipient-certs.pem"

The encrypted bundle will be deployed with the prefix "crypt-" in the DEPLOY_DIR. Note, that the bundle with the unencrypted manifest is also still being deployed and can be used for manual encryption for other recipients as well.

Enable the config options DM_CRYPT and CRYPTO_AES to support installing encrypted RAUC bundles.

Add support for encrypting bundles after creating them. This requires
the usage of the "crypt" bundle format and a recipient certificate for
encrypting the signed bundle manifest. To encrypt the bundle, set
RAUC_CRYPT_BUNDLE to 1 and RAUC_CRYPT_CERT_FILE to the path of the
recipient certificate:

  RAUC_CRYPT_BUNDLE ?= "1"
  RAUC_CRYPT_CERT_FILE ?= "path/to/recipient-certs.pem"

The encrypted bundle will be deployed with the prefix "crypt-" in the
DEPLOY_DIR. Note, that the bundle with the unencrypted manifest is also
still being deployed and can be used for manual encryption for other
recipients as well.

Signed-off-by: Martin Schwan <[email protected]>
Enable the config options DM_CRYPT and CRYPTO_AES to support installing
encrypted RAUC bundles.

Signed-off-by: Martin Schwan <[email protected]>
@jluebbe
Copy link
Member

jluebbe commented Jul 22, 2024

We expect that in most scenarios, the manifest encryption (rauc encrypt) would happen outside of the Yocto build, as recipients are added and removed over time. Why would you prefer to do this during the build?

At least, the comment should mention that encrypting via bundle.bbclass is only one of the possible approaches.

@mschwan-phytec
Copy link
Contributor Author

Yes, encrypting may happen outside of the build process, but not always. We see a lot of cases during development and from customers where it would be useful to have signing and encryption streamlined in one process.

The number of recipients may change, that is true. However, I do not see an issue where this would interfere with the build process. Simply changing/adding recipients to the recipient-certs.pem file and rebuilding works nicely.

As the bundle signing already happens during the build process, I do not see much difference when we would also take the additional step and encrypt the bundle, if needed. Either way, even if only signing the bundles, certificates (and private keys) have to be stored on the system building and/or encrypting the bundle. The level of security is the same for signing as well as for encrypting.

This implementation still allows for only generating crypt bundles with unencrypted manifest. I could emphasize this more in the comments of the bundle.bbclass. And maybe also add that unencrypted (only signed) bundles are still possible, as is the default.

@m3harvey
Copy link

In the case where a single key is used to encrypt all upgrade packages, it is helpful to be able to automate that encryption step. My workplace is using meta-rauc, and we're interested in doing this. I've used this branch (cherry-picked back to the mickledore branch, because that's where we are) to generate a package, and it worked.

I'm only commenting to help answer the "is this useful" question. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants