Add support for creating self-decrypting binaries #2315
+54
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For now, this function embeds the decrypting bootloader, but probably better to integrate (or replace) existing pico_encrypt_binary function
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds extra functionality to the
pico_encrypt_binaryfunction to allow creating self-decrypting binaries, including specifying the OTP page to use for the AES key.pico_encrypt_binary(hello_encrypted ${CMAKE_CURRENT_LIST_DIR}/privateaes.bin EMBED OTP_KEY_PAGE 29)The only non-backwards-compatible change it that if you previously called:
you now need to call
due to the new argument parsing. I think that this is fine, because the only time you'd pass a separated
SIGFILEtopico_encrypt_binaryis when you're using a different signing key for the binary vs the encrypted blob, which is not a common use case.This PR requires use of the picotool encrypted-shares branch (raspberrypi/picotool#207), so should be merged at the same time as that.