MAC's and Forgery

Question

I'm taking a course in information security and I have many unanswered questions!

I've learned that encryption doesn't guarantee authentication, which makes sense to me, but all the examples in the lecture and the ones I've found on Google seem very artificial or theoretic to me. For example one example was, that the attacker could modify some bits in the cipher text to increase or decrease the amount of money that need to be transfered. But how should anyone know the exact position of the bits representing this amount? Could anyone provide a more realistic example or explain why this is realistic?

A second question is about authentication with hash functions. For example when I download linux mint, I verify it with md5 (why do people still use md5, although it's considered completely broken?). So if anyone would make a MITM attack and forward a malicious distribution to me, I would notice it. But lets assume the adversary could find a collision in any of those secure hash functions. Then it doesn't help him, because he wants to modify the distribution in a special way, not just find another iso image that has the same hash value as the one provided, right?

I know there are already lots of questions regarding this topic, but I haven't found a link that satisfies me :-)

Answer 1

But how should anyone know the exact position of the bits representing this amount?

We must assume they do. That is, the system should be secure even if they happen to know the format.

For common protocols, like HTTP, it's easy to see that everyone knows what is where. The site-specific data might change, but if the attacker can create an account for themselves, they can see legitimate traffic. Even for less common protocols, we can't usually fully guard the protocol specification from an attacker. For interoperability reasons, it might actually be public, or available for money. Or some insider could leak it, etc. Anyone working with the protocol or the systems using it would be in the position to find out what the format is.

Rather than keep the whole protocol secret, it's easier if the security is based on only the security of the keys.

So if anyone would make a MITM attack and forward a malicious distribution to me, I would notice it.

Well, maybe. Unless you got the hash from the same server as the installation image, where the attacker could of course modify both. A pure hash isn't much of authentication, since anyone can calculate a valid hash for a modified file. You should use a (public key) signature system for verifying software downloads. (Or rather, for verifying the hashes.)

As for collisions, creating a collision might be hard if you know the source data is two lines in iambic pentameter, but as @zlk says, an ISO file likely has lots of extra space to work with to create the collision. That is, if the base installer can be modified without you noticing, it doesn't matter much if some optional packages on the image get trashed to accomplish it.

Answer 2

Encryption: The reason encryption isn't authentication is because each party doesn't have a way to determine who they are talking to without authentication. Based on the example, the attacker could impersonate one party and have the money transferred to a different account entirely.

Hash functions: md5 is broken, but it is still difficult to create a forged file that can be used in place of the original one. That said, an iso is one of the easier file formats to forge because the attacker can add arbitrary data to generate the colliding hash without breaking the file format.

Also, many places publish sha1 and sha2 hashes. Use those instead, preferably the sha2 hashes.

Answer 3

First, the property that you're talking about in both cases is not in fact authentication, but integrity. A MAC does provide both authentication and integrity checking, but in the specific instances you've cited, it is integrity that is at issue.

For the example of a using a MAC for authenticated encryption, the example you cite is true...When encrypted data has a well-known structure (as it often does) and the plaintext is known, it ciphertext bits (or the IV) can be tweaked to change the decrypted message. A far more common attack against unauthenticated encryption however, is a padding oracle attack against block mode ciphers. which can lead to complete loss of confidentiality. Properly protecting the integrity of the ciphertext with a MAC in an encrypt-then-MAC construction can completely eliminate the possibility of these attacks.

For the second example of MD5, the reason that MD5 is still used is primarily inertia. It's implemented in a lot of places, been used for decades, and it's hard to motivate change, even though SHA-2 is certainly better. That said, there is no practical attack here. MD5 is broken in respect to collision attacks, but what you need for this particular attack is not a collision, but a second pre-image. This is much harder, because whereas with a collision you only care about finding two inputs, any two inputs, that produce a single output, with a second pre-image attack both the first input (the legitamate file) and the output (the hash of that file) are fixed, and only the second input (the malicious file) can be manipulated. The best known pre-image attack against MD5 right now has a cost of something along the lines of 2¹²³...Far beyond what is technically feasible. So, no matter how hard an attacker may try, they will never be able to produce a file with a signature that matches the existing signature of an existing file.