EXERCISE 3 — Hashing vs Signing vs Authenticated Encryption (what each proves + auto-update attack) =================================================================================================== THE THREE CRYPTOGRAPHIC TOOLS (what each proves): 1. HASHING (SHA-256, etc.) What it proves: TAMPERING (whether data has been modified). How it works: - Input: any data (file, message, password). - Output: a fixed-size "fingerprint" (256 bits for SHA-256) computed from the input. - Property: ANY change to the input produces a COMPLETELY DIFFERENT hash. The same input always produces the same hash. What it proves: - "This data hasn't been modified since I computed the hash." If someone hands you a file + a hash, you can recompute the hash and compare. Match = untampered. Mismatch = tampered. What it does NOT prove: - WHO created it (attacker can compute hashes too). - Confidentiality (the hash is published; it reveals nothing about the input, but the input itself is visible to anyone). 2. SIGNING (RSA, ECDSA, Ed25519) What it proves: AUTHORSHIP & TAMPERING (who created it + whether it's been modified). How it works: - The signer has a PRIVATE KEY (secret) and a PUBLIC KEY (published). - Signer: computes a hash of the data, encrypts the hash with the private key = SIGNATURE. - Verifier: decrypts the signature with the public key, recomputes the hash of the data, and compares. Match = signed by the holder of the private key + not tampered. What it proves: - "Only the holder of the private key could have created this signature." So you know WHO created it (assuming the key is held securely by one person). - "The data hasn't been modified." (If data is tampered, the decrypted hash won't match the recomputed hash.) What it does NOT prove: - Confidentiality (the data is in plaintext; anyone can read it). 3. AUTHENTICATED ENCRYPTION (AES-GCM, ChaCha20-Poly1305) What it proves: CONFIDENTIALITY (only the holder of the key can read it) + INTEGRITY/TAMPERING (data hasn't been modified). How it works: - Both parties share a SECRET KEY. - Sender: encrypts the data + computes an authentication tag (a keyed hash that binds the ciphertext to the key). - Receiver: decrypts + verifies the auth tag. If tag is invalid (data was tampered), decryption fails. What it proves: - "Only someone with the key can read this data." (Confidentiality.) - "This data hasn't been tampered with." (Integrity via the auth tag.) What it does NOT prove: - Authorship (you don't know WHO encrypted it, only that they had the key). --- COMPARISON TABLE: Tool | Proves Tampering? | Proves Authorship? | Proves Confidentiality? ----------------------|-------------------|-------------------|------------------------ Hashing (SHA-256) | ✓ YES | ✗ NO | ✗ NO Signing (RSA/Ed25519) | ✓ YES | ✓ YES | ✗ NO Auth Encryption (GCM) | ✓ YES | ✗ NO | ✓ YES --- CONCRETE ATTACK: INSECURE AUTO-UPDATE SYSTEM (and how each defence stops it) SCENARIO: A mobile app auto-updates via HTTPS. The server returns a new binary. The client downloads it and installs it. No verification is performed. THE ATTACK (Man-in-the-Middle / Compromised CDN): 1. User initiates auto-update. 2. Attacker intercepts the HTTP/DNS (or compromises the CDN) and replaces the binary with a malicious version (trojaned app that steals credentials). 3. Client downloads and installs the malicious binary. 4. Attacker has achieved RCE / credential theft via the "legitimate" update. WHY IT WORKS WITHOUT VERIFICATION: - The client has no way to tell the malicious binary from the real one. - HTTPS prevents casual eavesdropping but doesn't prevent a compromised server or CDN from serving bad binaries. --- HOW EACH DEFENCE STOPS IT: 1. HASHING: Defence: The app developer publishes the SHA-256 hash of the current version on a trusted website (their homepage). The update mechanism downloads the binary, computes its hash, and compares it to the published hash. How it stops the attack: - Attacker replaces the binary with a trojan. - Client downloads the trojan and computes its hash: different from the published hash. - Client rejects the update and alerts the user. Limitation: Attacker could also compromise the developer's website and change the published hash. So the hash must come from a truly TRUSTED source (e.g. a site you personally visit, a hardcoded hash in the app's source code, or a pinned certificate). 2. SIGNING: Defence: The developer signs the binary with their private key. The client has the developer's public key (hardcoded in the app or downloaded from a trusted source). The update mechanism downloads the binary + signature, verifies the signature, and installs only if valid. How it stops the attack: - Attacker replaces the binary with a trojan. - Client tries to verify the signature: fails (attacker doesn't have the developer's private key). - Client rejects the update and alerts the user. - Also: if attacker modifies the legitimate binary in transit, the signature is invalid. Advantage over hashing: - Attacker CAN'T fix the signature without the private key. - Even if attacker controls the published hash (hashing-only defence), they can't create a valid signature. This is STRONGER than hashing because authorship is cryptographically proven. 3. AUTHENTICATED ENCRYPTION: Defence: Developer encrypts the binary with a shared key (established out-of- band, e.g. via TLS) and authenticates it. Client decrypts + verifies the auth tag. How it stops the attack: - Attacker intercepts the encrypted binary. - Client attempts to decrypt: if the ciphertext is tampered, the auth tag fails and decryption aborts. Limitation: Requires key exchange (both sides must have the same key). For public app updates, signing is more practical because the public key can be published. --- WHICH DEFENCE IS BEST FOR AUTO-UPDATES? SIGNING is the standard for software updates: - Developer's private key is securely held (offline HSM, encrypted key store). - Public key is distributed with the app (or fetched from a pinned certificate authority). - Every update is verified by every client (no trust in the delivery path). - Attacker must steal the private key to forge updates; that's a higher bar. HASHING is a lightweight alternative: - Fast to compute and verify. - Sufficient IF the hash comes from a truly trusted source (not intercepted, not compromised along with the binary). - Used alongside HTTPS + certificate pinning. AUTHENTICATED ENCRYPTION is less common for updates: - Better for point-to-point comms where both sides share a secret. - Requires key exchange, which is more complex for public updates. --- FULL DEFENCE FOR AUTO-UPDATES (layered): 1. Use HTTPS (prevents simple MITM). 2. Pin the certificate (prevents compromised CA from issuing a fake cert). 3. Sign the binary with a private key; verify signature before install. 4. Publish the signature + hash on an independent, secure channel (your website, social media, a blockchain record). 5. Staged rollout: deploy to 1% of users first; monitor for crashes/anomalies. 6. If an update is detected as malicious, remotely revoke it (send a revocation list to clients). This layered approach means an attacker must compromise MULTIPLE systems to succeed, not just intercept the download. --- ONE-LINE TAKEAWAY: Hashing proves tampering (but not authorship); signing proves both authorship and tampering; authenticated encryption proves confidentiality + tampering. For auto-updates, SIGNING is standard because the developer's private key is a single point of trust that attackers must compromise to forge updates.