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!

[jluebbe]

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.

From my perspective, bundle encryption is more related to the deployment/distribution process that the build process. Why would you want to rebuild a release only to encrypt it to additional devices (which have been produced after the initial release was created)?

If you rebuild, you'd likely get small differences in the images (except if you have 100% reproducible builds). So then you have two (or more) slightly different filesystems in the field for what it supposed to be a single release, which makes management and analysis more complex than it needs to be. Future enhancements related to delta/patch updates would also be much more difficult, as the number of different images in the field increases.

This PR deploys both bundles, so you could re-encrypt layer if you've archived both, though.

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.

No: security wise, there are two completely independent considerations.

Authenticity is provided by signing, the secret key must be accessible to the build system (or to a separate system when using rauc resign). The target only needs to know which public key to trust for authenticating bundles. Note that if you encrypt the manifest during building, you cannot use rauc resign.

Confidentiality is provided by encryption. For this, the build/deployment system only needs to know the public keys for the target systems. As the corresponding secret keys need to be on the target systems, they have a much higher risk of being compromised. This means that you want to be able to retire any compromised encryption key without affecting the ability to install to other target systems. So, you need per-device encryption keys.

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.

From my perspective, this mode should only be used you don't intend to react to compromised encryption keys and don't care about having a single set of images per release. We should warn about this clearly.

[jluebbe]

@ejoerns Do you have comments on the implementation?