SHA-256 Checksums and Signed Firmware: Verify the Source

01 /What a sha256 checksum proves

A sha256 checksum is the output of the SHA-256 hash function applied to every byte of a file. FIPS 180-4, the Secure Hash Standard, defines the function; RFC 6234 restates it with reference code. The output is 256 bits, written as 64 hexadecimal characters. No known method finds two files with the same SHA-256 digest, so the digest can stand in for the file.

Comparing a digest answers one question: is this file identical to the one the publisher hashed? A match proves integrity and nothing about who the publisher was, because whoever can change the file can change the digest beside it. Origin needs a second fact: the reference digest came by a path the attacker did not control, or is signed by a key you trust. This page in the lane on proving what the network carried covers both halves, with firmware for switches and routers as the case.

02 /Checksum, HMAC and digital signature

Three mechanisms get confused because all involve a hash. A plain checksum is unkeyed: anyone can compute it, so it detects corruption but not an attacker who replaces both file and digest. An HMAC, defined in RFC 2104, mixes a shared secret into the hash. Only a holder of the secret can produce or check it, but every verifier holds that secret and could have forged it, so an HMAC proves origin only between two parties.

A digital signature signs the hash with a private key; anyone with the public key can check it, nobody with only the public key can forge it, and the proof is portable. RFC 4880 defines the OpenPGP form, including the detached signature shipped as a separate .sig or .asc file. Vendors that sign firmware use the same idea, with the public key held in the boot code.

03 /Computing the digest on Linux, macOS and Windows

Every current operating system has a SHA-256 tool. On Linux, sha256sum -c reads a file of digest filename lines and prints OK or FAILED per entry; macOS ships shasum -a 256 with the same option. On Windows, certutil -hashfile image.bin SHA256 prints the digest, and PowerShell's Get-FileHash image.bin defaults to SHA-256 in upper case. Compare case-insensitively.

$ sha256sum -c SHA256SUMS
FGS07402.bin: OK
FGS07402b.bin: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
$ gpg --verify SHA256SUMS.sig SHA256SUMS
gpg: Signature made Tue 12 Jun 2007 14:02:11 UTC
gpg:                using RSA key 4F1A 8C2E 90B7 3D5E
gpg: Good signature from "Release Engineering <releases@example.com>"

Note the order. The signature covers the digest list; the digest list vouches for the image. Good signature proves nothing unless the key is one you trust, and gpg warns when it is not certified. Import the vendor's key from somewhere other than the download mirror and check its fingerprint first. Whether the bytes arrived intact over HTTP is covered by integrity checks on bytes in transit.

04 /Firmware images for switches and routers

Firmware is where a bad file costs the most. A corrupted image bricks the unit; a tampered one runs an attacker's code below the operating system, where no host tool sees it. NIST SP 800-193, the Platform Firmware Resiliency Guidelines, expects an update mechanism to authenticate an image before applying it. Cisco IOS offers verify /sha512 and signed-image checks at boot; Junos validates a package before installation. Where such a command exists, run it before the reload.

Older platforms have no such check. IronWare units of the Foundry era boot whatever copy tftp flash wrote, so the workstation check before the TFTP transfer is the only gate. A hash on the same page as the download link is weak evidence anywhere: whoever swapped the file also edited the page.

05 /Why this matters for the Foundry and Brocade archive

Brocade acquired Foundry Networks around the end of 2008 and the download portal is long gone. FastIron, BigIron and ServerIron images still circulate on forum threads, personal mirrors and the flash cards of auctioned units, almost never with a vendor digest. They remain usable if the record of where each came from is kept. The archive's practice for manuals, in how captured vendor pages are dated and stored, applies to binaries: record source, capture date and SHA-256 digest, and judge every later copy against that record. Where a release note in the archived Foundry advisory list names a fixed version, the digest shows which image was actually run.

06 /Worked example: one FastIron image from a forum mirror

An engineer needs a FastIron 7.4 image for a FastIron GS bought at auction. A 2011 forum thread links FGS07402.bin on a personal mirror and pastes a hash in the post. The download's digest matches, which proves the file is the one the poster hashed and nothing else.

The vendor's release notes for 7.4.02, in a 2008 web archive capture, list an MD5 and no SHA-256. It matches too. Two independent sources agree, one captured before the forum post existed, so an attacker would have had to plant the file before 2008. The engineer records both digests and sources with capture dates, copies the image to flash, and show version reports 07.4.02. That record, kept beside the console notes from recovering a unit whose password was lost, is what turns "it booted" into evidence.

07 /Procedure: verify the source of a download

1. 01

   Fetch the image and the reference digest separately

   Download the binary, then get the digest from the strongest source available: a signed digest list, an archived release note or a printed manual.

2. 02

   Obtain the signing key by a different path

   Import the publisher's public key from a keyserver or a previously verified release and compare the full fingerprint. Never take it from the same mirror as the file.

3. 03

   Verify the signature over the digest list

   Run gpg --verify SHA256SUMS.sig SHA256SUMS and require Good signature from the expected key. A signature from an unknown key is not a pass.

4. 04

   Compute the local digest and compare

   Run sha256sum -c, shasum -a 256 -c, certutil -hashfile or Get-FileHash and compare all 64 characters. Re-download once on a mismatch; a second mismatch means a bad source.

5. 05

   Run the on-box check and record the result

   After the copy to flash, run the platform's verify command where one exists. Then write the digest, reference source, key fingerprint, date and outcome into the change record.

08 /Pitfalls: weak hashes, forum digests and trusted mirrors

• Treating MD5 or SHA-1 as proof of origin. Both have practical collision attacks. A legacy MD5 still catches corruption, so use it when it is all the vendor left, and say so in the record.
• Copying the digest from a forum post. If file and hash came from the same person, a match proves only that the mirror is self-consistent.
• Trusting one mirror for file, digest and key. One compromise rewrites all three. The key must come from elsewhere.
• Hashing the wrong bytes. A file moved in ASCII mode over FTP or unpacked by a browser no longer matches. Hash the exact file that goes to the device.

The digest is the first rung of a ladder this lane climbs: signed firmware and configuration bundles that prove the publisher add origin to integrity, and the integrity attribute a browser checks on every script tag applies the same hash comparison to content served through a CDN.

A sha256 checksum is a cheap, exact test of whether a file is the one somebody hashed. Turning that into proof of origin takes one more step: get the reference digest, or the signature over it, by a path the download site did not control, and record where it came from. For firmware, that step separates a verified image from a file you hoped was right.