RIOT-OS/RIOT
RIOT-OS/RIOT
1
0
Fork 0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
Code Releases Activity
fbf1cd16a6
RIOT/makefiles/suit.base.inc.mk

58 lines
1.6 KiB
Makefile
Raw Normal View History

sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
#
# path to suit-tool
dist/tools/suit: Update suit tooling to IETF-v7 compliance
2020-06-29 15:42:47 +02:00
SUIT_TOOL ?= $(RIOTBASE)/dist/tools/suit/suit-manifest-generator/bin/suit-tool
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
#
# SUIT encryption keys
#
# Specify key to use.
# Will use $(SUIT_KEY_DIR)/$(SUIT_KEY).pem as combined private/public key
# files.
SUIT_KEY ?= default
makefiles/suit: place keys in $XDG_DATA_HOME Placing the SUIT key in the RIOT repository folder is dangerous as a repo checkout is by most people considered a volatile location. Since all important files are stored in git, deleting the entire folder or it's contents is not an uncommon cleanup operation. If the user is at that point unaware that SUIT key material is stored in that folder, that key will then be lost. Another workflow may involve multiple checkouts of the RIOT repository to multiple folders to work on several features at the same time, or for easy cross-referencing or splitting of off features from an integration into a feature branch. In that case each checkout would use it's own incompatible SUIT key. To avoid all these pitfalls, place the SUIT keys outside the RIOT repository in the $XDG_DATA_HOME directory.
2022-06-02 00:02:26 +02:00
XDG_DATA_HOME ?= $(HOME)/.local/share
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
ifeq (1, $(RIOT_CI_BUILD))
SUIT_KEY_DIR ?= $(BINDIR)
else
makefiles/suit: place keys in $XDG_DATA_HOME Placing the SUIT key in the RIOT repository folder is dangerous as a repo checkout is by most people considered a volatile location. Since all important files are stored in git, deleting the entire folder or it's contents is not an uncommon cleanup operation. If the user is at that point unaware that SUIT key material is stored in that folder, that key will then be lost. Another workflow may involve multiple checkouts of the RIOT repository to multiple folders to work on several features at the same time, or for easy cross-referencing or splitting of off features from an integration into a feature branch. In that case each checkout would use it's own incompatible SUIT key. To avoid all these pitfalls, place the SUIT keys outside the RIOT repository in the $XDG_DATA_HOME directory.
2022-06-02 00:02:26 +02:00
SUIT_KEY_DIR ?= $(XDG_DATA_HOME)/RIOT/keys
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
endif
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
# we may accept multiple keys for the firmware
SUIT_SEC ?= $(foreach item,$(SUIT_KEY),$(SUIT_KEY_DIR)/$(item).pem)
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
# generate a list of the public keys
SUIT_PUBS ?= $(SUIT_SEC:.pem=.pem.pub)
makefiles/suit: allow multiple SUIT_SECs
2022-08-15 19:32:19 +02:00
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
SUIT_PUB_HDR = $(BINDIR)/riotbuild/public_key.h
SUIT_PUB_HDR_DIR = $(dir $(SUIT_PUB_HDR))
CFLAGS += -I$(SUIT_PUB_HDR_DIR)
BUILDDEPS += $(SUIT_PUB_HDR)
makefiles/suit: avoid unwanted key creation trigger This fixes a trigger of re-creation of an already existing SUIT key when combining a build target with the clean target, e.g. `make clean all`.
2022-07-20 12:35:33 +02:00
$(SUIT_SEC): | $(CLEAN)
makefiles/suit*: use $(Q) to silence output
2021-08-16 11:23:50 +02:00
$(Q)echo suit: generating key in $(SUIT_KEY_DIR)
$(Q)mkdir -p $(SUIT_KEY_DIR)
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
$(Q)$(RIOTBASE)/dist/tools/suit/gen_key.py $@ $(SUIT_SEC_PASSWORD)
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
%.pem.pub: %.pem
$(Q)openssl ec -inform pem -in $< -outform pem -pubout -out $@
# Convert public keys to C headers - only last 32 bytes are key material
#
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
# set FORCE so switching between keys using "SUIT_KEY=foo make ..."
# triggers a rebuild even if the new key would otherwise not (because the other
# key's mtime is too far back).
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
$(SUIT_PUB_HDR): $(SUIT_PUBS) FORCE | $(CLEAN)
makefiles/suit*: use $(Q) to silence output
2021-08-16 11:23:50 +02:00
$(Q)mkdir -p $(SUIT_PUB_HDR_DIR)
makefiles/suit: allow multiple SUIT_SECs
2022-08-15 19:32:19 +02:00
$(Q)( \
echo "const uint8_t public_key[][32] = {"; \
makefiles/suit: store public keys This makes it easier to work with encrypted keys and multiple keys. The firmware binary can contain multiple public keys that are used to verify the manifest. The use case is that we want to include the production public key in the debug build, so we can seamlessly update to the production version without re-flashing the device. If the public keys is always generated on the fly, this would still require the production key password even for the debug build. Instead if we store the (unencrypted) public key, we can always include it in the debug build.
2024-09-09 19:28:59 +02:00
for i in $(SUIT_PUBS); do \
echo " {"; \
openssl ec -inform pem -pubin -in $$i -outform der | tail -c 32 | xxd -i; \
echo " },"; \
makefiles/suit: allow multiple SUIT_SECs
2022-08-15 19:32:19 +02:00
done; \
echo "};" \
) | '$(LAZYSPONGE)' $(LAZYSPONGE_FLAGS) '$@'
sys/suit: Add SUIT draft ietf-v3 firmware upgrade module Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
2020-02-26 14:48:24 +01:00
suit/genkey: $(SUIT_SEC)
Copy Permalink