A software publisher wants customers to be able to verify that an installer genuinely came from the publisher and was not modified after release. Which solution provides both assurances?
Select an answer to reveal the explanation.
Short Explanation
A checksum tells you the file didn't change, but it doesn't tell you who made it. Code signing ties the file to the publisher's private key, so you get both answers at once. That's the difference this question wants you to catch.
Full Explanation
Code signing combines hashing and asymmetric cryptography. The publisher computes a hash of the installer and encrypts that hash with its private key, attaching the resulting signature and the publisher's certificate. When a customer runs or inspects the installer, the operating system recomputes the hash, verifies the signature with the public key from the certificate, and checks that the certificate chains to a trusted CA. A match proves integrity, because any modification changes the hash, and origin, because only the publisher's private key could have produced the signature. Publishing a checksum on the download page provides integrity only if the page itself is trustworthy; an attacker who can replace the file on the same site can usually replace the checksum too, and an older hash algorithm adds collision risk. Encrypting with the publisher's public key would make the installer readable only by the publisher, which is useless for distribution and does not prove origin. Obfuscation makes reverse engineering harder but provides no cryptographic proof of origin or integrity. Exam caveat: a digital signature is a hash encrypted with a private key; it provides integrity, authentication, and non-repudiation, but not confidentiality. Operational check: protect the code-signing private key in a hardware security module, timestamp signatures, and verify that release builds fail if the signature check does not pass.