Verifying the consistency of the firmware and open source code released by OneKey

Currently, the firmware installed on OneKey hardware products classic, mini, and touch are all open source and can be compiled through CI to produce the final firmware to be released. The specific firmware types and open source repositories are as follows:

All firmware releases will be packaged through CI, signed by OneKey internal personnel and released.

When a formal firmware or Bluetooth firmware is ready to be released, we will compile the open source code in CI by executing the corresponding repository action. After successful compilation, it will be uploaded to the Github artifacts storage. Finally, after signing and placing it on OneKey's CDN, the update configuration be updated. Finally, users will be prompted to update on OneKey APP and




OneKey Firmware Verification Method

Verify that the github release is consistent with the code compiled by CI

Take the latest released OneKey Classic v2.9.0 firmware as an example. Firstly, please find the corresponding commit in the warehouse release


Clicking on the image will locate the commit hash at compile time. You can also click on [Compare] to compare all the code and commits between the old and new versions. The signed firmware content to be released will be placed in the release assets.

Click on the CI task in the red box above to find the compilation process of the current firmware (Note: since some firmware is in other branches, it is necessary to confirm whether the checkout task is consistent when verifying the commit hash).

Clicking into the CI task details will show the checkout information, which indicates that the current compilation is based on the commit beginning with 2bd0563, which is consistent with the commit released for the release.


Verify that the CI compilation results are consistent with the release results

The firmware generated by CI will be uploaded to GitHub Artifacts for temporary storage. OneKey will sign the firmware generated by CI (multi-signature) and update the GitHub Release before releasing it to the user terminal. Two files will be generated internally.



Update Timing



It cannot be changed after being burned into the hardware device at the factory

The start-up of verifying firmware signature information, etc.


Users can get access to the device through the tool update

Various business-related logic


For common firmware (Classic, Mini, and Touch are all applicable), after the multi-signature, a 1024-byte signature result will be added in front of the CI version firmware and the bootloader will verify it when the device starts.

In order to facilitate users to download, OneKey will place the signed result in the CDN. Therefore, for theclassic.urlfield in,two-step verification is required to ensure that the published version is consistent.

  • Verify that the firmware downloaded from the Github release is exactly the same as the CDN.6.png

  • Verify that the Github release is obtained after CI multi-signaturetail -c +1024 /path/to/bin | shasum -a 256    7.png                                                                  

For the three .bin file names shown in the screenshot

ci-classic.*.bin represents firmware content downloaded from Github CI (unsigned)

release-classic.*.bin represents firmware content downloaded from Github release (signed)

classic.*.bin represents firmware content (signed) downloaded from OneKey CDN

It can be verified that all firmware released by OneKey is compiled and processed with multi-signature through open source code via Github action (CI).

If the user does not install the multi-signed firmware when downloading and installing, or if the firmware signature is abnormal, there will be a prompt message warning of the risk at startup.

Was this article helpful?
5 out of 5 found this helpful