Skip to content

Releases: tendervault/assureloop

AssureLoop v0.3.0 Hardware Alpha

15 Jun 08:54
@tendervault tendervault
v0.3.0-hardware-alpha
34c83a7

Choose a tag to compare

View all tags
AssureLoop v0.3.0 Hardware Alpha Pre-release
Pre-release

v0.3 Hardware-Alpha Release Notes

Summary

AssureLoop v0.3 hardware-alpha packages the first hardware-backed release
assurance milestone for one physical Zephyr board: ST NUCLEO-H563ZI.

This release is still simulator-first and development-key based. It is not
production OTA, not production secure boot, not a cloud update service, and not
a safety or cybersecurity certification claim.

In short: not production OTA, not production secure boot, and not a safety or cybersecurity certification claim.

Included

  • Host-side release, manifest, evidence bundle, update package, and OTA
    simulator tooling.
  • Zephyr qemu_cortex_m3 simulator workflow.
  • ST NUCLEO-H563ZI board build workflow.
  • ST NUCLEO-H563ZI signed-image evidence workflow with SBOM generation.
  • MCUboot sysbuild verification for ST NUCLEO-H563ZI.
  • Local direct-flash MCUboot lifecycle investigation for staged update,
    confirm, rollback, tamper rejection, and downgrade rejection.
  • Release manifest schema validation and end-to-end evidence bundle
    verification.

Supported Board

  • Board: ST NUCLEO-H563ZI
  • Zephyr target: nucleo_h563zi
  • Serial console used during validation: COM4 at 115200 baud
  • Programmer used during validation: STM32CubeProgrammer v2.22.0
  • Zephyr SDK path used during validation: D:\zephyr-sdk

No broad board support is claimed in v0.3.

Verified Hardware Proof Points

  • Basic Zephyr hardware build, flash, and serial logging.
  • AssureLoop application boot markers on COM4.
  • Board-specific signed image artifacts.
  • Board-specific release manifest, trace report, evidence bundle, SBOM, and
    update package generation.
  • MCUboot bootloader execution and signed application chainload.
  • Secondary-slot signed update staging at 0x08102000.
  • MCUboot swap-using-offset update flow.
  • Confirmed update remains active after reset.
  • Unconfirmed test update rolls back after reset.
  • Tampered secondary-slot update is rejected by MCUboot validation.
  • Lower-version secondary-slot update is rejected by MCUboot downgrade
    prevention.

Commands To Reproduce

Run host tests:

.\scripts\test-tools.ps1

Run the full simulator flow:

.\scripts\full-demo.ps1 -Python py

Build the NUCLEO-H563ZI application:

.\scripts\hardware-build-nucleo-h563zi.ps1 -Python py

Generate board-specific signed image evidence:

.\scripts\signed-image-demo-nucleo-h563zi.ps1 -Python py

Build MCUboot plus the signed application:

.\scripts\mcuboot-verify-nucleo-h563zi.ps1 -Python py

Build lifecycle investigation artifacts:

.\scripts\mcuboot-update-lifecycle-nucleo-h563zi.ps1 -Python py

Prepare the local v0.3 release output:

.\scripts\prepare-v0.3-release.ps1 -Python py

Git Bash equivalents:

PYTHON=py bash scripts/full-demo.sh
PYTHON=py bash scripts/hardware-build-nucleo-h563zi.sh
PYTHON=py bash scripts/signed-image-demo-nucleo-h563zi.sh
PYTHON=py bash scripts/mcuboot-verify-nucleo-h563zi.sh
PYTHON=py bash scripts/mcuboot-update-lifecycle-nucleo-h563zi.sh
PYTHON=py bash scripts/prepare-v0.3-release.sh

Hardware negative-update checks require a connected board and intentionally
flash the device:

.\scripts\mcuboot-update-lifecycle-nucleo-h563zi.ps1 -Python py -TamperUpdate -EraseBeforeFlash -Flash
.\scripts\mcuboot-update-lifecycle-nucleo-h563zi.ps1 -Python py -DowngradeUpdate -EraseBeforeFlash -Flash

Sample Logs Included

  • samples/logs/nucleo_h563zi_boot.log
  • samples/logs/nucleo_h563zi_mcuboot_update_confirm.log
  • samples/logs/nucleo_h563zi_mcuboot_update_rollback.log
  • samples/logs/nucleo_h563zi_mcuboot_tamper_reject.log
  • samples/logs/nucleo_h563zi_mcuboot_downgrade_reject.log
  • samples/logs/qemu_controller_boot.log

Known Limitations

  • Development signing keys are generated locally under ignored keys/ paths.
  • Private keys are not part of the release output.
  • Images are staged on hardware by direct flashing, not by real network OTA.
  • The workflow does not include MCU hardware key custody, fuses, or production
    rollback counters.
  • Downgrade rejection is based on MCUboot image-version comparison.
  • Serial evidence is captured manually.
  • Tamper validation mutates one signed image byte and proves that corruption
    pattern is rejected; it is not an exhaustive fault campaign.
  • Only ST NUCLEO-H563ZI has hardware validation.
  • Generated evidence and update package outputs are sample development
    artifacts, not production deployment artifacts.

What Not To Claim

Do not claim that v0.3 provides:

  • production OTA,
  • production secure boot,
  • certified safety or cybersecurity compliance,
  • cloud update management,
  • broad board support,
  • hardware-backed private key custody,
  • protection against every possible image corruption pattern.

Next Planned Milestones

  • Decide whether mcumgr/SMP should become the next local update transport.
  • Add board-safe automation for serial capture if it proves reliable.
  • Improve version propagation between sysbuild image headers and application
    release logs.
  • Continue toward a physical-board update workflow without adding cloud
    services or production certification claims.
Loading