Calibration Package

A calibration package was installed shortly before the station's readings became disputed. Review the package inspection, installation log, and vendor policy to decide what the successful hash comparison proves—and what it does not prove about the package's origin.

Objective

By completing this module, you will be able to:

• distinguish file integrity from publisher authenticity;
• evaluate a package verification record against a stated release policy; and
• identify the cryptographic control needed to authorize software provenance.

Before you begin

Open Calibration Package and download all three evidence files. Read SHA-256 and the glossary distinctions among a hash, MAC, and digital signature. Keep a two-column note labeled observed and required.

Concepts

A cryptographic hash summarizes file bytes. Matching expected and observed digests is evidence that two copies have the same content, assuming the expected digest is trustworthy. It does not identify who created or approved those bytes: an unauthorized source can copy both a file and its public digest.

A digital signature binds data to control of a private signing key. Software authorization normally requires the device to verify the signature, the signer identity, the certificate chain or trusted public key, and applicable policy. Successful parsing, target compatibility, and a matching digest answer different questions.

Encoding is reversible. Checksums detect accidental errors. Hashes fingerprint bytes but do not authenticate a source. A MAC provides integrity and origin within a group that shares a secret; any member can create tags. A signature binds bytes to a private-key holder when verification and public-key trust are correct. None of these alone encrypts, proves freshness, or grants authorization.

Suggested tools

• Browser and text editor: Open the package inspection, update log, and bulletin side by side. Search for hash, digest, signature, signer, policy, and verify.
• Comparison table: Paper or a text table can map each required vendor check to the corresponding observed verification field.

Tool practice

Rehearse the worked tool exercise before using challenge data.

Search each text artifact for digest, signature, and policy fields. Build required/observed/source rows. The .pkg.txt file is an inspection report: hashing that report does not recalculate the underlying package digest described inside it.

Investigation

Observe

Inventory the package's digest, target, release channel, publisher fields, and verification results. In the update log, separate the digest result from later warnings and the final installation status. In the bulletin, list every check required before a production package is authorized.

Form a hypothesis

Does the matching hash establish only that the retrieved bytes match an expected value, or does another record authenticate the publisher? Which required verification fields are absent or unresolved? Does a successful installation mean that current policy authorized the package?

Test carefully

Compare the inspection and log fields with the bulletin one requirement at a time. Do not treat ok, compatible, MATCH, or accepted as interchangeable; record the specific property each word describes. Check whether any temporary exception is still valid at the incident date.

Submit the authorization conclusion supported by all three files and name the missing publisher-authentication mechanism. Use the generic mechanism name rather than copying a hash value or certificate subject.

Progressive hints

Troubleshooting and reset

If the records seem contradictory, label each statement as integrity, authenticity, compatibility, policy, or installation outcome. A package can pass one category and fail another. If the finding is rejected, verify that your conclusion addresses publisher authorization and that the mechanism name comes from the bulletin rather than the package digest.

Completing the finding reveals a seal; file it on the River Station incident board to record progress.