Security Updates to Zigbee External Application and Boot Validation #175
Security Updates to Zigbee External Application and Boot Validation #175
Conversation
NCP-1945: Adding new generated dfu_cc_pb2.py with addition of new FwType: EXTERNAL_APPLICATION NCP-NONE: Moving OpCode Init to top-level
…a flag type variable NCP-NONE: Fixing bool expression
NRF-1904: Fixing boolean error for --external_app
* firstguy/feature/zigbee_dfu_image: Add Zigbee DFU image support # Conflicts: # nordicsemi/__main__.py # nordicsemi/dfu/package.py
NRFFOSDK-12436: Making Zigbee packages external-app only
…vice or --bootloader for Zigbee FW upgrade
…e-ota-fw-version (optional)
… small images read, 260KB => 640 bytes) NRFFOSDK-12346: Cleanup of the OTA_file class generation
…ause that is the implementation in the bootloader
Improve CLI of --boot-validation
…futil * 'master' of https://github.com/NordicSemiconductor/pc-nrfutil: Add a warning about overwriting nRF DFU settings backup page Extend unit tests by backup page checks Add setting for DFU settings backup page placement Update DFU settings backup page together with DFU settings BUGFIX: open binary file in a binary mode Remove additional commas inside README.md # Conflicts: # nordicsemi/dfu/package.py
# Conflicts: # nordicsemi/dfu/dfu-cc.options # nordicsemi/dfu/dfu-cc.proto # nordicsemi/dfu/dfu_cc_pb2.py
…dvib/pc-nrfutil * 'settings-page-boot-validation' of https://github.com/andvib/pc-nrfutil: Fixed minor bug in how crc was calculated from IntelHex object Added version 2 for BL DFU Settings page Refactored DFU Settings generation to allow for easier handling of non uint32 values Add documentation and error messages for arguments to --boot-validation Change CLI name from VALIDATE_SHA256 to VALIDATE_GENERATED_SHA256 because that is the implementation in the bootloader protobuf files for boot validation add boot vaidation # Conflicts: # nordicsemi/__main__.py
Add external-app functionality combined with boot validation
…n NO_VALIDATION is used
…s (MBR addresses present in newer bootloaders)
README.md
Outdated
15.3.0 - | 2 | ||
|
||
The Bootloader DFU settings version supported and used by the SDK you are using can be found in `nrf_dfu_types.h` in the `bootloader` library. | ||
The Bootloader DFU settings version supported and used by the SDK you are using can be found in `nrf_dfu_types.h` in the `bootloader` library. Bootloaders compiled from nRF5 SDK 15.3.0 and higher also supports BL Settings Version 1, depending on the project settings. If using version 2, boot validation for SD and APP can be generated with the settings page using the `--sd-boot-validation` and `--app-boot-validation` in the same way as for DFU packages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth it to specify that new bootloaders use only version 2, but it should handle version 1 fine (if configured to). If it boots with a settings page version 1 it will translate it to version 2 before continuing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
README.md
Outdated
@@ -190,7 +190,11 @@ SD + APP | Yes | **See notes 1 and 2 below** | |||
was added in nrfutil 3.1.0 and is required since 3.2.0 in case the package should contain SD (+ BL) + APP. Also, since version 3.2.0 the new ID is copied to `--sd-req` list so that | |||
in case of a link loss during APP update the DFU process can be restarted. In that case the new SD would overwrite itself, so `--sd-req` must contain also the ID of the new SD. | |||
|
|||
The boolean option '--zigbee' enables the generation of Zigbee update file in addition to the zip package. The following example demonstrates the generation of such update file: | |||
Boot validation for a SD or APP update can be activated by setting the `--sd-boot-validation` or '--app-boot-validation' to the preferred validation method. When boot validation is set, the bootloader will store the signature of the SD or APP in the bootloader setting page and verify the signature with the firmware in flash on every boot. This is only supported by bootloaders using bootloader settings version 2, see 'settings' for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe mention that the boot-validation arguments can be used both with package generation and with settings generation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
README.md
Outdated
@@ -187,7 +190,18 @@ SD + APP | Yes | **See notes 1 and 2 below** | |||
was added in nrfutil 3.1.0 and is required since 3.2.0 in case the package should contain SD (+ BL) + APP. Also, since version 3.2.0 the new ID is copied to `--sd-req` list so that | |||
in case of a link loss during APP update the DFU process can be restarted. In that case the new SD would overwrite itself, so `--sd-req` must contain also the ID of the new SD. | |||
|
|||
The boolean option '--zigbee' enables the generation of Zigbee update file in addition to the zip package. The following example demonstrates the generation of such update file: | |||
**Note 3:** When creating update packages of bootloaders compiled from nRF5 SDK 15.3.0 and higher, nrfutil version 4.1.0 (TODO: UPDATE THIS WHEN VERSION IS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already a Note 3, see line 208.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
README.md
Outdated
@@ -187,7 +190,18 @@ SD + APP | Yes | **See notes 1 and 2 below** | |||
was added in nrfutil 3.1.0 and is required since 3.2.0 in case the package should contain SD (+ BL) + APP. Also, since version 3.2.0 the new ID is copied to `--sd-req` list so that | |||
in case of a link loss during APP update the DFU process can be restarted. In that case the new SD would overwrite itself, so `--sd-req` must contain also the ID of the new SD. | |||
|
|||
The boolean option '--zigbee' enables the generation of Zigbee update file in addition to the zip package. The following example demonstrates the generation of such update file: | |||
**Note 3:** When creating update packages of bootloaders compiled from nRF5 SDK 15.3.0 and higher, nrfutil version 4.1.0 (TODO: UPDATE THIS WHEN VERSION IS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider whether this binding between SDK version and nrfutil version should be mentioned in the list at lines 33-35.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
…ged order of arguments for keeping style
README.md
Outdated
will be too large. | ||
|
||
Boot validation for a SD or APP update can be activated by setting the `--sd-boot-validation` or `--app-boot-validation` to the preferred | ||
validation method. When boot validation is set, the bootloader will store the signature of the SD or APP in the bootloader setting page |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A signature will be stored only if the boot validation type is ECDSA. For SHA256, a hash is stored, and for CRC, a checksum is stored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a "common" name for signature, hash and checksum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Validation data.
"When boot validation is set, the bootloader will store the validation data (signature, hash, or checksum) of the SD or APP in the bootloader setting page ..." ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
This PR includes changes to allow updates to be sent from a Zigbee external application, and added boot validation fields to both packages and settings page. Settings page version 2 has been created.