I am working on a project with my Internet of Things students relative to ensuring integrity of code (digital transparency) as it is moved through development, testing, and deployment. I realize that Particle has some built-in functionality to ensure security of flashing code OTA. However, this is more a classroom learning exercise to understand how the students can ensure if they manually flash a .bin file that it matches the intended code and, ideally, to validate that the intended code is on a device.
We had a previous issue within our school’s firewall, that if I understand correctly, was related to a hash of the code on the Particle device being sent to the Particle Cloud as part of the connection/authentication process.
Thus, two part question:
If there is indeed a hash of the code on the Particle that is sent to the cloud, is it accessible by the user (i.e., could I obtain that hash from the code running on my device)?
Is there a way to hash a .bin file within the Particle-CLI so I can see that same hash and use it to compare what is on the device to the .bin file that is intended?
Central New Mexico Community College
Colleen - thank you for getting back to me. My purpose for the post was less about the firewall issue and more about the question of can I get the hash of the .bin file that I create. My students are working on a project that includes ensuring providence of the code they generate (i.e., validating that the code on an Argon is actually the code that they created if someone else does the flash). I see a app-hash sent to the particle console events when new code is flashed, but is there a way that I can get that hash directly from the particle so I can compare it to what I expect to be there.
All that said, I would like to fix the issue we are having with the first connect after flashing code. You can look at ticket (104248) to see the history and the assistance Ismael Soleto gave me last year. Updating to 3.0.0 worked for a little while but the issue started again. My current group of students are experiencing the issue. We are running deviceOS 3.2.0.
Here’s a screen shot of the issue. I had simple Hello World code where I changed one delay.
At 10:29 (Mountain) I flashed to code. You can see it try to connect and send the new app-hash.
The device is stuck in blinking cyan.
After the 10:30:07 message (while still blinking cyan), I power cycle the Argon (remove and reconnect the USB cable).
It reconnects a few seconds later, has no trouble going into breathing cyan, and starts blinking Hello World to the D7 LED.
When you flash a device OTA, you’ll notice in the event log a spark/device/app-hash event published by the device. As you might guess, this is a hash. Specifically, a SHA-256, 32 bytes of hash expressed as 64 hexadecimal digits.
Each firmware binary consists of a prefix header, the binary executable, the suffix, and a CRC32. The suffix contains the 32-byte SHA-256 hash of the binary.
It’s theoretically possible to both find the saved hash for the binary currently loaded, as well as verify it, but it’s not something that’s normally ever done so it’s not currently documented anywhere. But it should be possible.
Rick - thank you for your assistance. I did come across the app-hash which I see gets uploaded once when it changes (but not in subsequent Argon boots). So, presumably, there is code somewhere that can pull the hash and send it to the cloud. When you say is <isn’t documented but should be possible> how does one go about asking someone in the know on the DeviceOS development team how to do this?
Rick - thank you. You have answered my questions a few times over the years and I always learn a lot from your solutions. Even better, beyond the problem I am focused on, I learn more about the particle embedded systems in a way that allows me to enhance my class for my students. Thank you.