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]

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.

[lurch]

How hard would it be to modify the line-wrapping to prevent a line-break getting inserted in the middle of e.g. [-t <type>] ?

[will-v-pi]

I think that's handled by the CLIPP library, so probably a question for @kilograham whether we want to change that code?

picotool/clipp/clipp.h

Lines 317 to 363 in c56c005

	/** @brief handle line wrapping due to column constraints */
	template<class Iter>
	void write_line(Iter first, Iter last)
	{
	if(first == last) return;
	if(only_whitespace(first, last)) return;
	if(right_of_text_area()) wrap_soft();
	if(at_begin_of_line()) {
	//discard whitespace, it we start a new line
	first = std::find_if(first, last,
	[](char_type c) { return !std::isspace(c); });
	if(first == last) return;
	}
	const auto n = int(std::distance(first,last));
	const auto m = columns_left_in_line();
	//if text to be printed is too long for one line -> wrap
	if(n > m) {
	//break before word, if break is mid-word
	auto breakat = first + m;
	while(breakat > first && !std::isspace(*breakat)) --breakat;
	//could not find whitespace before word -> try after the word
	if(!std::isspace(*breakat) && breakat == first) {
	breakat = std::find_if(first+m, last,
	[](char_type c) { return std::isspace(c); });
	}
	if(breakat > first) {
	if(curCol_ < 1) ++totalNonBlankLines_;
	fix_indent();
	std::copy(first, breakat, std::ostream_iterator<char_type>(os_));
	curBlankLines_ = 0;
	}
	if(breakat < last) {
	wrap_soft();
	write_line(breakat, last);
	}
	}
	else {
	if(curCol_ < 1) ++totalNonBlankLines_;
	fix_indent();
	std::copy(first, last, std::ostream_iterator<char_type>(os_));
	curCol_ += n;
	curBlankLines_ = 0;
	}
	}

[lurch]

Okay, sounds like There Be Dragons 🐉

[kilograham]

Not convinced that's much more helpful. Really thinking about something that helps the user know what happened and what to do - in the RP2040 case it doesn't really make sense to be signing anyway, no?

[will-v-pi]

Not convinced that's much more helpful. Really thinking about something that helps the user know what happened and what to do - in the RP2040 case it doesn't really make sense to be signing anyway, no?

It is a valid use case to be sealing an RP2040 binary, as an RP2350 may want to hash/signature check an RP2040 binary before loading it onto an RP2040. Would this error message be clearer:

No metadata block found when sealing RP2040 binary - either use RP2350, or set PICO_CRT0_INCLUDE_PICOBIN_BLOCK=1