Add support for creating self-decrypting binaries, and use 4-way AES key shares instead of just the AES key

[will-v-pi]

This adds support for creating self-decrypting binaries, which can be created using

picotool encrypt --sign --embed hello_world.elf hello_world.enc.elf my_aesfile.bin my_iv_salt.bin my_sigfile.pem my_otp.json

This introduces a breaking change to picotool encrypt to take a 4-way AES key share, rather than just taking an AES key, as this makes it simpler to mask the power signature when decrypting the binary. The only difference from a user perspective is that they now need to use a 1024 bit binary file instead of the 256 bit file used before. The AES key is derived from the 4-way share as follows:

aes_key.words[i] = aes_key_share.words[i*4]
                 ^ aes_key_share.words[i*4 + 1]
                 ^ aes_key_share.words[i*4 + 2]
                 ^ aes_key_share.words[i*4 + 3];

This also introduces a breaking change that picotool encrypt now requires an IV salt binary to be passed to it as the 4th file, so the signing_key is now the 5th file and the OTP JSON is now the 6th file.

This PR should be merged in parallel with raspberrypi/pico-sdk#2315 and raspberrypi/pico-examples#619 to avoid breaking the pico-examples encrypted bootloader compilation

[kilograham]

1. I had forgotten? that encrypt was already an available option. Was that used with the pre-existing pico-example? How does this change affect that example (is the encrypt command now backwards compatible? (edit: i guess i should read the PR description!)
2. I worry about rollback versions (and indeed other versions) - we should probably copy that across to the decrypting header
3. I believe the dealing with TBYB and friends IS handled (due to pico-sdk PR) just wanted to double check with you - i still need to delve into this PR more deeply

[will-v-pi]

1. I had forgotten? that encrypt was already an available option. Was that used with the pre-existing pico-example? How does this change affect that example (is the encrypt command now backwards compatible? (edit: i guess i should read the PR description!)
2. I worry about rollback versions (and indeed other versions) - we should probably copy that across to the decrypting header
3. I believe the dealing with TBYB and friends IS handled (due to pico-sdk PR) just wanted to double check with you - i still need to delve into this PR more deeply

1. I've modified the example to use the new command Encrypted improvements pico-examples#619 - but yes, the SDK CMake function and the picotool command are not backwards compatible.
2. They should have been copied across, along with TBYB - lines 5124-5139 in main.cpp - but this wasn't working as the block choice code would choose the first block to copy data from. I've changed this so it will now choose to copy the last block if it has an IMAGE_DEF, otherwise choose the first block, as the last block will be the better choice.
3. For self-decrypting binaries, TBYB and everything else is handled entirely by the bootrom - the decryption stage shouldn't time out the watchdog, so the user binary can call explicit_buy as usual. The decryption stage just gets loaded into SRAM along with the encrypted binary by the bootrom, and decrypts it in place, so doesn't need any handling for TBYB etc. For encrypted binaries with a separate decrypting bootloader, the handling is improved by the rom_pick_ab_update_partition PR.

[kilograham]

A few other random thoughts

1. I think we should support passing a 256 bit AES key and generating 4 shares (I dont think this tells you much if the AES key is secure random even if picotool does less well -though it should be using dev/random already, right via c++ lib if i reacll)
2. I think we should support passing the AES key and the IV salt as a hex on the command line too. could probably live with just treating anything starting with 0x as hex not filename, and check it is the right length.
3. Can we lose the -t on the AES key and salt unless there are useful different file types

[kilograham]

I wonder if we should explicitly zero unused RAM in the LOAD_MAP of the self-encrypting binary (probably)

[will-v-pi]

See the encrypted-shares-ci branch for passing CI, which now requires different SDK and examples branches due to the examples build test

[lurch]

I see that in main.cpp this has been updated to "JSON file to save OTP to (will edit existing file if it exists)", so I guess you might want to use #220 here? 😀

[will-v-pi]

Yep, I think I'll merge #220 into develop, then merge develop into here again and run it

[lurch]

See the encrypted-shares-ci branch for passing CI, which now requires different SDK and examples branches due to the examples build test

Perhaps the original comment in this PR ought to be updated to say which other pico-sdk and pico-examples PRs ought to be merged before (or in parallel with?) this PR.