Add support for creating self-decrypting binaries #2315
Conversation
This file contains hidden or 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
will-v-pi
force-pushed
the
self-decrypting-only
branch
from
e684dcc to
4c7b909
Compare
For now, this function embeds the decrypting bootloader, but probably better to integrate (or replace) existing pico_encrypt_binary function
Add newlines for readability, and explain why MbedTLS version is insecure
will-v-pi
force-pushed
the
self-decrypting-only
branch
from
4c7b909 to
fd83496
Compare
will-v-pi
added a commit
to raspberrypi/picotool
that referenced
this pull request
Apr 22, 2025
…e examples compilation passes
lurch
reviewed
Apr 24, 2025
lurch
reviewed
Apr 24, 2025
Comment on lines
408
to
+409
| # Encrypt the target binary with the given AES key (should be a binary | ||
| # file containing 32 bytes of a random key), and sign the encrypted binary. | ||
| # This sets PICOTOOL_AESFILE to AESFILE, and PICOTOOL_ENC_SIGFILE to SIGFILE | ||
| # if present, else PICOTOOL_SIGFILE. | ||
| function(pico_encrypt_binary TARGET AESFILE) | ||
| # file containing 128 bytes of a random key), and sign the encrypted binary. |
There was a problem hiding this comment.
I guess this is now a 128-byte file (key share) OR a 32 byte file (key) OR a 64-character hex string (key) ?
lurch
reviewed
Apr 24, 2025
Comment on lines
+410
to
+411
| # Salts the public IV with the provided IVFILE (should be a binary file | ||
| # containing 16 bytes of a random IV), to give the IV used by the encryption. |
There was a problem hiding this comment.
And similarly I guess this is now a 16-byte file OR a 32-char hex string?
There was a problem hiding this comment.
...although I guess if you tried specifying a hex-string here that'd mess up the later pico_add_link_depend step!
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 ${CMAKE_CURRENT_LIST_DIR}/ivsalt.bin EMBED OTP_KEY_PAGE 29)The main non-backwards-compatible change is the addition of a new IV salt bin file which is required and must be passed as the second argument. This will break any uses of
pico_encrypt_binary, and has been added for security purposes, as we now salt the public IV with a salt stored in OTP.The other 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 after that.