Cannot create a large amount of device keys for encrypted bundles

[phishstang65]

I am using Yocto ( Kirkstone ) to create an image for an embeded Linux device with Linux Kernel version 5.15.

I have implemented encrypted bundles with rauc using this guide:
https://www.pengutronix.de/en/blog/2022-03-31-tutorial-rauc-bundle-encryption-using-meta-rauc.html

Everything works great with the resulting bundle and on the end device, unless I try to create a number of device keys greater than 256.

I use this bit of code to create the device keys:

# Create X number of key/certs
for i in $(seq 1 256); do
    echo "*** Generating this key: $i ..."
    openssl ecparam -name prime256v1 -genkey -noout -out ${OUTPUT_DIR}/private/private-key-$i.pem
    openssl ec -in ${OUTPUT_DIR}/private/private-key-$i.pem -pubout -out ${OUTPUT_DIR}/public-key-$i.pem
    openssl req -new -x509 -key ${OUTPUT_DIR}/private/private-key-$i.pem -out ${OUTPUT_DIR}/recipient-cert-$i.pem -days 365250 -subj "/O=RAUC/CN=RAUC Test $i"
done

I then do a Yocto build, and encrypt the resulting *.raucb bundle with commands like this on the build machine:

# Encrypt bundle
echo "*** Encrypting this bundle: $LATEST_RAUCB_BUNDLE ..."
oe-run-native rauc-native rauc encrypt \
  --keyring=$RAUC_CA_KEYRING \
  --to $RECIPIENTS_FILE $LATEST_RAUCB_BUNDLE \
  $ENCRYPTED_RAUCB

# Define keys location
KEYS_DIR="/workspaces/keys/rauc/rauc-device-keys"

# Check bundle
echo "*** Checking this bundle: $ENCRYPTED_RAUCB ..."
oe-run-native rauc-native rauc info \
  --keyring=$RAUC_CA_KEYRING \
  --key=${KEYS_DIR}/private/private-key-1.pem --dump-recipients \
  $ENCRYPTED_RAUCB

If I generate only 256 keys initially, this whole process works and the encrypted bundle can be used for updates. If I generate more than 256 keys, I get the following error - both on the build machine during the 'rauc info' stage, and also on the device if I try to update with the bundle.

Signature size [..] exceeds bundle size

I've seen this issue which references the same error - however the file md5sums match what I expect and without changing anything else, if I create less keys, then it works:

rauc/meta-rauc#235

I would greatly appreciate any help in resolving this - thanks.

[ejoerns]

Hm, this looks like you run into a sanity check that existed before we introduced 'crypt' bundles.

When the signature (i.e. all your encryption keys together + the CMS structure) is larger than the payload (i.e. the squashfs), you would actually run into this.
I am not sure why this happens exactly at 256 keys, but maybe it's just a coincidence.

What kind of payload do you have? Is it an actual image?

However, I would see this as a bug in RAUC since it prevents using a large number of recipients together with small payloads, which is not intentional.

[phishstang65]

The payload is a root file system and Linux Kernel - the total size of the bundle is about ~200 MB.

I do agree that this probably belongs under the RAUC repository.

[ejoerns]

When the signature (i.e. all your encryption keys together + the CMS structure) is larger than the payload (i.e. the squashfs), you would actually run into this. I am not sure why this happens exactly at 256 keys, but maybe it's just a coincidence.

Re-checking this again I have to admit that my initial assumption about the sanity check was wrong. The sanity check is fine as it is. Thus I have no clue why you see

 Signature size [..] exceeds bundle size

in that case. I have re-tested encrypting and calling rauc info with > 256 keys (and a small payload) and it works as expected.

On the other hand, when using notably more keys, I can reproduce running into another sanity check:

Invalid bundle format: Signature size (5827693) exceeds 64KiB

This should be addressed but is not an explanation for the exceeds bundle size error where I have no other clue than that the bundle might be corrupted.

@phishstang65 Could you provide an output log from the corresponding rauc encrypt and rauc info calls that caused the failure?

[ejoerns]

@phishstang65 Have you been able to get more information about the problem or any logs that we could have a look at?

[jluebbe]

@phishstang65 Do you have more information? Otherwise, we'll have to close this issue.