Add secure boot support for compile command.

[umbynos]

Please check if the PR fulfills these requirements

• The PR has no duplicates (please search among the Pull Requests
  before creating one)
• The PR follows
  our contributing guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• UPGRADING.md has been updated with a migration guide (for breaking changes)

• What kind of change does this PR introduce?

feature

• What is the current behavior?

• What is the new behavior?

The secure boot is now supported in the compile command

I've added three flags to support the override of the default security keys used to sign and encrypt a binary:

• --keys-keychain allows specifying the directory used to search for the security keys
• --sign-key indicates the name+extension of the sign key to use
• --encrypt-key indicates the name+extension of the encryption key to use

The keys are red from the properties.Map representing the platform.txt file and are overwritten, even if security=sien board option is not used. Because we don't know if it will be the standard for secure boot.

• Does this PR introduce a breaking change, and is
  titled accordingly?

• Other information:

---

See how to contribute

[matthijskooijman]

I have not been involved with any development leading up to this, but at first glance it seems these extra options added are a bit arbitrary. Various platforms support all kinds of options in their platform.txt, and I wonder if it makes sense to make these particular options special and understood by arduino-cli. Going onto this train of development might eventually lead to a ton of different options, each supported by different platforms, each with their own compatibility needs...

IOW, I wonder:

• Are these options really needed? Can the existing --build-property option not be used instead?
• If these are needed, are they generic enough? I.e. will they work for a broad range of platforms and usecases, or will more (similar but not quite the same) options be needed in the future for other platforms?
• Should this PR not include an update for the platform.txt documentation, to clearly document the particular keys updated by this option, with a clear contract about how they are intended to be used and set?

[umbynos]

Hi @matthijskooijman, first off, thanks for the points you brought up.

Are these options really needed? Can the existing --build-property option not be used instead?

• If you are referring to --board-options flag, unfortunately no, because this kind of properties are set along with the fqbn and not by the legacy builder.
  Using arduino-cli compile -b <fqbn> --build-property security=sien just won't work. Instead, adding the option along with the fqbn will work just fine (like before): arduino-cli compile -b <fqbn>:security=sien.
  As @per1234 pointed out I should move this change to another PR though.
• If you are referring to the flags used to override the security keys used, yes, can be overridden with just --build-property but it requires knowledge on the platform:
  In the first platform that we will release shortly, it was decided to use these key names and combinations to specify the security keys used to sign and encrypt the binary.
  As you can see, they depend on the tool-name. It could happen in the future that a new platform comes out and uses a different tool to sign and encrypt. Using these newly introduced flags, we take away responsibility from the user to know exactly what properties to manually override with --build-properties.

If these are needed, are they generic enough? I.e. will they work for a broad range of platforms and usecases, or will more (similar but not quite the same) options be needed in the future for other platforms?

The flags introduced to override the default security keys IMHO are generic enough secureboot-wise. As long as a platform uses this approach of signing and/or encrypting a binary, they should work just fine.

Should this PR not include an update for the platform.txt documentation, to clearly document the particular keys updated by this option, with a clear contract about how they are intended to be used and set?

Yes, an update to the docs is definitely needed. And I'm doing it right now.

If you have further questions/observations/feedback I will be pleased to answer

[umbynos]

--board-options PR created #1688

[umbynos]

Docs updated

[per1234]

My opinion is that we should postpone the merge of this.

Start out by using the existing mechanism, as suggested by @matthijskooijman:

arduino-cli compile --build-property build.keys.sign_key=<some path>  --build-property build.keys.encrypt_key=<some path>

I really don't think it is so much more difficult for the advanced users who will use Arduino CLI and secure boot.

Once the first platform providing "secure boot" capability has been released and in use by the users, any requirements for facilitating its use may become more clear.

[ubidefeo]

In my opinion, as we offer facilities to burn a bootloader, we should enhance arduino-cli with the functionalities we need for secure-boot platforms.
Starting with our choice of MCUboot, which we might use in more upcoming boards, our CLI needs to be able to handle operations such as key generation, binary encryption and upload of such binaries.

Although the use of --build-property is a valid option, semantically I'd like to keep such operations into their respective realms.
Nothing prevents a user to work their way through a convoluted breakdown of properties and use them in the canonical way, but I'd prefer to keep the operations easily documented also through the command line itself (-h).

Once we provide support for our preferred way of doing key generation to support MCUboot, developers of other platforms and boards flavours might decide to implement other secure bootloaders and use the same commands which will leverage their own scripts and tools.

The idea of providing a local keychain is in my opinion valuable as more advanced use cases present themselves, hence we might end up implementing some form of keychain management through the CLI.
As we discussed yesterday in an internal meeting with @facchinm and @umbynos , generation of .pem files using ecdsa-p256 would not be done through imgtool but directly in Go to simplify things and reduce clutter, but we still want to offer platform developers a gateway into writing their own implementation of secure bootloaders or other means of generating keys to be used in yet unspecified contexts

[umbynos]