2

Assume a server and a client that are each on physically secure, uncompromised networks. However, between each network is an attacker that is capable of viewing traffic. For example, two department networks that are linked to a larger corporate network whose router is compromised, or two remote devices where an intervening IXP has been compromised by a state-level adversary.

The adversary is specifically targeting these two devices.

The traffic between the two devices is encrypted with 256-bit AES using a key shared by a physical side channel (thumb drive). The two device's firewalls are set to drop all traffic not from each other's IP address.

What havoc can that attacker wreak? From what I can see, they could redirect traffic so that it does not reach its intended target, or they could spoof one device's IP address in order to effect a DOS attack against the other device. Am I missing anything?

  • Which OSes are running the server and the client? [return] How are protected their other network interfaces (Wi-Fi, Bluetooth, IR) ? [return] How are protected their USB port access? – dan Sep 4 '17 at 6:34
4

Assuming the encryption is properly implemented and the key isn't compromised, all an MITM attacker can achieve by changing the data is turning it into unpredictable garbage. When A and B do any form of plausibility checking on the data, they should notice that.

So what can the attacker do?

  1. Suppress the communication completely by simply filtering it all
  2. Turn the communication into nonsense by making some random changes (countermeasure: Add a hash to each message to detect and discard damaged messages)
  3. Insert even more nonsense into the communication hoping to deplete resources (DOS attack)
  4. Re-send previously observed message ("replay attack"). Even if they couldn't understand a message, if they observed that sending a specific message caused something to happen, sending the exact same message again might cause the same thing to happen again (countermeasure: Add a timestamp to each message and discard messages which are too old. The timestamp should be included in calculating the hash).
  5. Create a copy of the cyphertext in case they somehow manage to obtain the encryption key in the future.
2

To add some possible threats to what @Philipp said. You don't specify which cipher mode is in use.

In case of ECB mode (Absolutely discouraged), as the encrypted blocks are not randomized an attacker will be able to distinguis identical blocks. With certain knowledge of the message being sent an attacker may decrypt the entire communication

In case some malleable mode like CBC is in use, an attacker that knows part of the plaintext may be able to tamper the message.

Certain modes tha use nonces, like CTR, have a limit on how much blocks can you cipher without losing security. If the amount of blocks encrypted exceeds that limit an attacker may recover the plaintext too

Also, even if there is not practical yet with current known hardware, capturing enough traffic will allow the attacker to perform a birthday attacks

  • The amount of traffic should be pretty limited. In reference to your CBC comment, would it work if they knew specific phrases likely to occur in the plaintext, but not their location or frequency? – TBridges42 Aug 6 '17 at 14:37
  • 1
    @TBridges42 Sorry for the late response. In order for an attacker to tamper the CBC mode (Note this is an unauthenticated mode), the attacker needs to know part of the plaintext and it's location, this may be easier knowing the protocol in use. For example, if your message is an email, the ciphertext will look like cipherText = AES.encrypt(key, iv, "From: Bob"). Then, the attacker may spoof the from address doing the following: tampered = ciphertext ^ 'From: Bob' ^ 'From: Eve'. As CBC is not an authenticated method the receiver can't detect that the tamper has been done – Mr. E Aug 9 '17 at 15:15
  • 1
    To prevent the previous attack you should use an authenticated encryption mode (Preferred) or provide an HMAC within your message using a different key. For further reading on how to add an HMAC to your message check this stackexchange question as not all the ways it can be done provide security for malleable encryption modes – Mr. E Aug 9 '17 at 15:19
  • I want to say i really appreciate this answer. The other answer cleanly describes everything conventional crypto like TLS will protect you against, but you went into explaining how it can go wrong, which i think is better for caution and more useful in application. – J.A.K. Sep 4 '17 at 16:54
1

The attacker can alter the data in a malicious way to try and exploit potential vulnerabilities in your decryption code. For example if you're using TLS, there's a chance you're using OpenSSL for that, so the attacker can try to craft packets to exploit OpenSSL bugs, possibly obtaining remote code execution in order to leak your key and decrypt the entire communication, or compromise the machine for later access.

-1

Assume a server and a client that are each on physically secure, uncompromised networks. However, between each network is an attacker that is capable of viewing traffic.

This basically means: "Assume A, the throw A out the window, and stop assuming it."

The traffic between the two devices is encrypted with 256-bit AES using a key shared by a physical side channel (thumb drive).

This makes the rest of your setup irrelevant.

The two device's firewalls are set to drop all traffic not from each other's IP address.

This is pointless and doesn't add much in terms of security. It is trivial to re-write the TCP header and spoof the source.

It seems that you are saying: "Point A and Point B use end-to-end encryption with a symmetric key that is known to A and B, and never transmitted in-band. If an attacker compromises [any portion] of the network between A and B, what can the attacker do versus what can they know?"

Assuming you're using AES256 to encipher your data prior to leaving point A, and point B decrypts it, then the middle man cannot do much.

What they can know - that data transactions and conversations are taking place between the two points along with other metadata.

What they can do - block, re-route, cache, and otherwise tamper with the traffic.

Since your setup does not mention authentication, only encryption, then a MiTM attack could (in this setup) decrypt your data, cache it, then re-encrypt it and send it on. Neither point A or B would be aware of it.

"How do they decrypt my data???" - if this is a state level actor with resources, we can assume they have the resources to social engineer themselves a copy of the key, or had malware pick up a copy of it when it was in a computer's USB drive, etc... ).

Your main problem is you are using encryption without authentication. Now, if you use encryption with message signing and authentication, if the MiTM is tampers with your traffic at all, both endpoints will know. (Well... could know depending on your implementation).

  • If you assume (contrary to the premise of the question) that the key(s) get compromised, authentication doesn't help either, because the attacker could also fake the authentication. That makes your answer more confusing than helpful. Please try to stay within the premise of the question. I also can't follow your reasoning that the question says to "Assume A, the throw A out the window, and stop assuming it". The assumption of the question is that two secure systems communicate through an unsecure network, which is the basic premise of most cryptography scenarios. – Philipp Aug 4 '17 at 23:52
  • Your premise conflates physical network security with messaging security, which is part of why I have a hard time staying within your premise. If you are using AES256 with out of band transfer of keys, then you can run the information over the public internet with impunity. So, yes, using end-to-end encryption renders your network topography inert in terms of the question. – DrDamnit Aug 5 '17 at 17:37
  • Also, message signing (such as HMAC) should use separate keys from the encryption keys. Otherwise, compromise of the encryption key means compromise of the signing keys, which - you state - would render it pointless. – DrDamnit Aug 5 '17 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.