In digital forensics, investigators must preserve evidence integrity and demonstrate an unbroken chain of custody. Creating a cryptographic hash (such as SHA-256) of the original drive and then hashing the forensic bitstream image provides a strong mathematical assurance that the copy is an exact, bit-for-bit replica. Because secure hash functions are designed so that any tiny change in data produces a dramatically different digest, matching hashes indicate the image contains identical data to the source at the time of acquisition. This is critical in legal and investigative contexts: analysis is performed on the copy, not the original, to avoid altering evidence. If the hashes match, the investigator can testify that the evidence examined is identical to what was collected, supporting admissibility and credibility.
Hashing does not prove who created files, nor does it directly show whether someone "opened the drive"; it specifically validates the integrity and equivalence of the captured image. Therefore, hashing both artifacts is done to verify that the original and the bitstream copy are identical.

A birthday attack targets hash functions by exploiting the birthday paradox: collisions (two different inputs producing the same hash output) can be found much faster than brute-forcing a specific preimage. For an n-bit hash, the expected work to findanycollision is on the order of 2^(n/2), not 2^n.
The attack is relevant because many security constructions rely on collision resistance-digital signatures, certificate fingerprints, integrity checks, and some commitment schemes. If an attacker can generate two different documents with the same hash, they may trick a signer into signing one version while later presenting the other as "signed," depending on the protocol. Linear cryptanalysis and differential cryptanalysis are primarily techniques against block ciphers, analyzing relationships between plaintext/ciphertext differences or linear approximations across rounds. Algebraic attacks treat the cipher as a system of equations. The description "looking for different inputs that generate the same hash" is the hallmark of collision-finding, and the classic framing for that is the birthday attack.

Bit-flipping exploits target encryption modes or protocols that do not provide strong integrity, allowing attackers to modify ciphertext so that predictable changes occur in plaintext after decryption. To defend against this, protocols add an integrity mechanism that detects tampering. In WPA (including enterprise deployments), TKIP introduced a Message Integrity Check (MIC) called "Michael." The MIC is computed over the frame contents (with additional fields) and verified by the receiver; if an attacker flips bits in transit, the MIC verification fails, and the frame is rejected. While AES (used by WPA2's CCMP) also provides integrity via authenticated encryption, the option presented that directly names the tamper-detection mechanism associated with guarding against bit-flipping is MIC. A pre- shared key is an authentication/keying method (and not enterprise-mode anyway), and a "global encryption key" would be the opposite of what you want-global/static keys worsen security.
Therefore, the intended mechanism that mitigates bit-flipping by detecting unauthorized modifications is the Message Integrity Check.

WPA with TKIP was designed as an interim improvement over WEP while still using the RC4 stream cipher for compatibility with legacy hardware. TKIP addresses WEP's major weaknesses by introducing per-packet key mixing, a message integrity mechanism ("Michael"), and replay protection.
In TKIP, the encryption key used with RC4 is 128 bits. Practically, TKIP derives a per-packet RC4 key from a 128-bit temporal key (TK), the transmitter's MAC address, and a sequence counter (TKIP Sequence Counter, TSC) to avoid the simple IV reuse patterns that made WEP easy to break. Even with these improvements, TKIP has known weaknesses and is deprecated in favor of WPA2/WPA3 using AES-based CCMP/GCMP. But strictly for the question asked, TKIP's RC4 keying material is based on a 128-bit key size, not 40/56-bit legacy sizes and not 256-bit.