bundle.bbclass: add support for encrypting bundles

[mschwan-phytec]

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.

[jluebbe]

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]

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]

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!